Искусственный интеллект · Агенты · LLM · Архитектура ПО · Оркестрация · Data Science · Python24 сентября в 16:02 · 4 мин

Как превратить простого ИИ-агента в надёжную операционную систему

Базовый цикл взаимодействия LLM с инструментами часто оказывается недостаточно надёжным для реальных задач. Статья Бруно Гонсалвеса описывает методологию трансформации простого агента в сложную, типизированную и управляемую систему. В её основе лежат концепции DAG-планирования, многоуровневой памяти, разделения ролей и детерминированной верификации, что позволяет создавать системы, способные к самокоррекции и доказательству правильности выполнения.

# От пилота к воздушной операции: архитектура продвинутого агента

Фундаментальная модель агентов на базе больших языковых моделей (LLM) строится на простом цикле: модель получает инструкцию, выбирает действие, вызывает инструмент, получает результат и решает следующее шаг. Этот подход работает для узкоспециализированных задач, но становится хрупким при масштабировании. Автор статьи Бруно Гонсалвесе предлагает рассматривать развитие агентной системы не как линейную эволюцию, а как создание полноценной инфраструктуры, аналогичной тому, что окружает пилота в реальной авиации. Если один пилот может вести воздушный бой, то управление сложной операцией требует планировщиков, эскадрилий, контроля топлива и бортовых самописцев.

Цель данной разработки — ответ на вопрос: как превратить наивный цикл в систему, способную планировать, восстанавливаться от ошибок и формально доказывать корректность своих действий.

Типизированные инструменты и абстракция провайдера

Первый критический этап улучшения архитектуры — переход от ручного управления к строгой типизации. В простых реализациях аргументы для инструментов часто валидируются вручную, что приводит к дублированию логики и трудностям для модели при генерации запросов.

В предложенной архитектуре аргументы каждого инструмента описываются с помощью моделей Pydantic. Это решение решает сразу несколько задач:

* Автоматическая валидация: Ошибки аргументов выявляются до запуска инструмента, что особенно важно для дорогих операций или действий с побочными эффектами. * Единая схема: Одно определение используется и для документации, и для построения JSON Schema, понятного API провайдеров (например, Anthropic или OpenAI). * Учёт стоимости: Каждому инструменту присваивается относительный вес (cost_hint), позволяющий эффективно управлять бюджетом токенов.

Также вводится базовый интерфейс для взаимодействия с LLM-провайдерами. Это позволяет абстрагироваться от конкретных SDK и использовать для тестирования детерминированные мок-функции (mock-объекты). Такой подход разделяет проблемы оркестрации и качества генерации модели, обеспечивая воспроизводимость экспериментов без зависимости от конкретных версий языковых моделей.

Ориентированный ациклический граф (DAG) и параллельное выполнение

Простой последовательный цикл, выполняющий действия по одному, неэффективен для задач, состоящих из множества независимых шагов. Классический пример — сравнение характеристик нескольких городов: получение населения и часового пояса для каждого из них не требует ожидания завершения предыдущего запроса.

Вместо линейного списка шагов используется Oриентированный ациклический граф (DAG). Планировщик (Planner) запрашивает у модели полный план выполнения задачи в виде графа, где узлы представляют операции, а ребра — зависимости между ними. Это позволяет выполнить все независимые узлы одновременно.

Реализация использует асинхронное выполнение с ограничениями на количество параллельных процессов (через семафор). Это предотвращает исчерпание лимитов запросов (rate limits) и резкий рост расходов. Критическим моментом здесь является валидация самого графа перед запуском: проверка циклических зависимостей и корректности ссылок на инструменты. Если план содержит ошибку, система не тратит ресурсы на его выполнение, а сразу переходит к перепланированию.

Многоуровневая память и верификация

Накопление всей истории диалогов и результатов в контексте модели приводит к двум проблемам: перерасходу токенов и деградации качества ответов из-за «помех» от нерелевантных данных. Вместо этого используется подход многоуровневой памяти:

1. Рабочая память: Содержит текущую цель и краткие промежуточные результаты, всегда находясь в контексте. 2. Эпизодическая память: Хранит результаты похожих прошлых задач. При возникновении новой задачи система ищет наиболее релевантные воспоминания (top-k) и добавляет их в контекст. 3. Семантическая память: Содержит общие факты, используемые при необходимости.

Важно, что контекст собирается динамически и не превышает заданный лимит символов. Если бюджет исчерпан, происходит явное усечение, а не скрытое затенение информации.

Для обеспечения качества результата внедряется двухступенчатая система верификации:

* Детерминированная проверка: Первая и наиболее быстрая стадия. Проверяет структурную корректность ответа (например, наличие всех запрошенных городов в отчёте). Если проверка не пройдена, процесс останавливается без привлечения языковой модели. * LLM-судья: Вторая стадия. Запускается только для ответов, прошедших первую проверку. Она оценивает субъективное качество и стилистику текста.

Такая иерархия позволяет избежать дорогостоящих вызовов к LLM для очевидных ошибок и обеспечивает прозрачность причин отказа при проверке.

Разделение ролей и оркестрация

Финальным шагом становится интеграция всех компонентов в единый оркестратор. Система разделяет функции на роли:

* Planner (Планировщик): Создаёт структуру выполнения задачи в виде графа. * Worker (Исполнитель): Реализует узлы графа, вызывая инструменты и управляя памятью. * Critic (Критик/Судья): Осуществляет валидацию и оценку результатов.

Оркестратор соединяет эти роли, управляя потоком данных, распределением бюджета и обработкой ошибок. Благодаря такой архитектуре система становится не просто набором инструментов, а единым комплексом, способным адаптироваться к изменениям, масштабироваться и демонстрировать предсказуемое поведение даже в условиях неопределённости.

Таким образом, создание надёжного агента требует смещения фокуса с генерации одного «хорошего» ответа на построение устойчивой инфраструктуры, где каждый компонент контролируется, проверяется и оптимизируется.

Первоисточники

Habr AI
← Вернуться в эфир