Почему производственным ИИ-агентам нужно больше, чем просто хороший запрос.

В демонстрации ИИ-агент кажется почти слишком простым в использовании. Даёте большой языковой модели цель, подключаете несколько инструментов, добавляете немного памяти и оборачиваете всё это в цикл. Внезапно агент начинает рассуждать, вызывать API, искать документы и выполнять задачи, и первая версия кажется чем-то вроде магии. Настоящая инженерная работа начинается в производственной среде.

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

Больше, чем просто большая языковая модель с инструментами

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

Возьмем агента для анализа документов. Пользователь загружает файл и просит провести анализ. За этим одним запросом системе может потребоваться выполнить следующее:

1. Проверить корректность запроса.
2. Извлечь информацию из документа.
3. Получить соответствующий контекст.
4. Сформировать подходящий промпт.
5. Заставить модель проанализировать полученные данные.
6. Проверить результат, возвращенный моделью.
7. Использовать дополнительные инструменты.
8. Рассчитать результаты, которые должны быть точными.
9. Сохранить итоги.
10. Доложить о ходе работы интерфейсу.
11. Повторно выполнить операции, которые завершились неудачей.

Записывайте логи и трейсы для последующей отладки.

На этом этапе речь уже не идет о быстрой разработке дизайна. Речь идет о проектировании распределенной системы, в которой случайно присутствует LLM. Четкое разделение обязанностей помогает.

Входные данные и контекст

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

Слой рассуждений

Именно здесь LLM демонстрирует свою полезность. Он может интерпретировать неоднозначную информацию, читать документы, сравнивать доказательства, выбирать инструменты, писать объяснения, классифицировать объекты и планировать следующий шаг. Существует одно важное правило: не поручайте модели принимать решения, которые обычный код может принять надежно.

Допустим, бизнес-правило выглядит так: разница <= 5% → УСПЕХ. Никому не нужен LLM для определения того, является ли 3,8% меньше 5%. Достаточно просто произвести вычисления. Используйте модель там, где требуется логическое мышление, а код — там, где возможен детерминизм. Такое разделение значительно упрощает тестирование систем агентов.

Инструменты делают агентов полезными

LLM без инструментов в основном описывает действия. Обладая инструментами, он выполняет их. Типичные инструменты — поиск, базы данных, API, извлечение документов, выполнение кода, внутренние сервисы и системы рабочих процессов. Обычный поток работы начинается с запроса пользователя, после чего агент выбирает инструмент, выполняет его, анализирует полученные результаты и продолжает работу.

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

Каждый инструмент также является источником возможных сбоев. API может выйти из строя из-за истечения времени ожидания, учетные данные могут стать недействительными, база данных может перестать работать, инструмент может возвращать некорректные данные, а модель — неверные аргументы. Обращение к инструменту никогда не должно означать просто отправки запроса большой языковой модели в API в надежде на лучшее решение. Для работы в производственных условиях необходимы проверка данных, ограничения по времени, повторные попытки, обработка ошибок, настройки прав доступа и четко определенные сценарии сбоев.

Память — это не способ накопления

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

Полезно мыслить по слоям:

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

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

Будьте осторожны с большим количеством агентов

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

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

Работоспособным правилом является начало с самого простого дизайна, способного решить задачу, и добавление агента только тогда, когда его необходимость в независимом мышлении или ответственности может быть четко сформулирована. Дизайн многоагентных систем должен решать архитектурные проблемы, а не создавать впечатление красоты.

Планирование на случай сбоев

Представьте себе рабочий процесс, который загружает документ, извлекает содержимое, получает контекст, анализирует его, вызывает соответствующий инструмент и генерирует отчет. Однако агент сразу после анализа выходит из строя. Начинается ли весь процесс заново? Были ли уже какие-то данные записаны в базу данных? Безопасно ли выполнять операцию дважды? Показывает ли интерфейс, что задание все еще выполняется? Может ли другой работник взять его на себя?

Здесь традиционная инженерия бэкенда становится необходимой. Агенты в производственной среде требуют:

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

Защитные механизмы и ограничения на количество итераций, вызовы инструментов, затраты ресурсов и время выполнения.

Явные состояния, такие как QUEUED → RUNNING → COMPLETED или QUEUED → RUNNING → FAILED → RETRYING.

Всё это звучит не так уж и захватывающе, как инжиниринг промптов, но именно это делает агентов надёжными.

Просмотр действий агента

Обычные приложения уже нуждаются в журналах событий и метриках. Агентам нужно ещё больше. Когда агент даёт плохой результат, информация о том, что HTTP-запрос вернул код 200 OK, почти ничего не говорит. Важен весь процесс: запрос, полученный контекст, составление промпта, вызов модели, выбор инструмента, его выполнение, оценка результата и окончательный ответ.

Для каждой запуска команда должна иметь возможность восстановить следующее:

• Контекст, предоставленный агенту
• Модель, которая была использована
• Инструменты, которые применялись, и в каком порядке
• Время, затраченное на каждый шаг
• Потребление токенов
• Причина сбоя — инфраструктура или процесс рассуждений
• Результат оценки

Это одна из причин, по которым отслеживание и оценка стали настолько важными элементами экосистемы агентов. Того, что невозможно наблюдать, нельзя улучшить.

Тестирование неоднозначного поведения

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

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

Автономность должна учитывать риски

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

• Низкий риск: выполнение автоматически.
• Средний риск: выполнение, затем логирование или проверка.
• Высокий риск: необходимо человеческое одобрение перед выполнением.

Цель — не максимальная автономия, а полезная автономия с контролируемым риском.

В целом картина ясна, и оказывается, что LLM — это относительно небольшая часть этой системы. Это сделано намеренно.

Вопросы перед выбором фреймворка

Прежде чем выбрать фреймворк или составить сложный запрос, стоит задать несколько вопросов:

1. Какое решение действительно требует ИИ? Один шаг вывода не делает весь рабочий процесс интеллектуальным.
2. Что может оставаться детерминированным? Вычисления, проверка, разрешения и критические бизнес-правила должны находиться в коде.

Какой контекст действительно нужен агенту? Получайте информацию избирательно и пропускайте полный вывод запроса.

Что произойдет, если он сорвется на полпути? Разработайте механизмы повторных попыток и восстановления до того, как проблема возникнет в реальных условиях.

Как будет оцениваться качество? Определите критерии оценки еще до того, как отпраздновать первую удачную демонстрацию.

Как его будут отлаживать через шесть месяцев? С самого начала внедряйте трекинг и структурированную логгирование.

Оправдано ли использование нескольких агентов? Если причина этого не может быть четко обоснована, вероятно, пока еще нет.

Инжиниринг промптов, выбор моделей и технология RAG по-прежнему имеют важное значение. Однако для производственного использования требуется более широкий подход: архитектура программного обеспечения, основанная на вероятностном интеллекте. Самый сильный дизайн — это не тот, в котором больше всего агентов, самая мощная модель или самая сложная система оркестрации. Это тот дизайн, при котором можно четко определить, что знает агент, что он может и не может делать, как оценивается корректность его действий, что происходит при сбое и как система восстанавливается. Именно тогда ИИ-агент перестаёт быть просто красивой демонстрацией и становится программным обеспечением, заслуживающим доверия.