AutoGen: Фреймворки многоагентного диалога для ИИ в финансах

После того как Gorilla показала, что одна LLM способна научиться точно вызывать тысячи API, возник закономерный вопрос: что произойдет, если дать нескольким LLM разные роли и позволить им общаться друг с другом? AutoGen (Wu et al., 2023) отвечает на этот вопрос, создавая фреймворк для многоагентного диалога. Сегодня его изучение кажется крайне своевременным — большинство производственных систем ИИ для финансов, которые я вижу, по умолчанию включают как минимум три агента.

Статья

AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (Wu, Bansal, Zhang et al., Microsoft Research, 2023) предлагает фреймворк, в котором «диалогоспособные агенты» (conversable agents) — каждый из которых базируется на комбинации LLM, инструментов и человеческого ввода — отправляют друг другу сообщения до завершения задачи. Фреймворк вводит два встроенных типа агентов: AssistantAgent (управляется LLM) и UserProxyAgent (может выполнять код и передавать ввод человека), а также GroupChatManager, который координирует очередность ходов в больших группах.

Основная идея заключается в том, что авторы называют «диалоговым программированием»: вместо того чтобы вручную прописывать логику оркестрации в коде, вы указываете задачи каждого агента через системные промпты на естественном языке, и позволяете передаче сообщений управлять потоком выполнения. В статье это демонстрируется на примерах решения математических задач, поиска ответов на вопросы (RAG), принятия решений в ALFWorld и приложении для исследования операций OptiGuide.

Ключевые идеи

• Рост точности на бенчмарке MATH: двух-агентная конфигурация AutoGen (ассистент LLM плюс прокси для выполнения кода) достигает 69,48% на тестовом наборе MATH по сравнению с 55,18% при использовании одной GPT-4 — прирост в 14 пунктов благодаря обратной связи от выполнения кода.
• Человек в цикле управления как стандарт: UserProxyAgent имеет настраиваемый режим human_input_mode — ALWAYS (всегда), NEVER (никогда) или TERMINATE (при завершении), что позволяет менять уровень контроля без изменения логики агента.
• Динамический групповой чат: GroupChatManager выбирает следующего говорящего на основе состояния диалога, а не фиксированного циклического порядка, что позволяет рабочим процессам ветвиться в зависимости от промежуточных результатов.
• Повышение безопасности в OptiGuide: добавление агента SafeGuard в процесс оптимизации цепочки поставок улучшило показатель F1 обнаружения небезопасного кода на 8 процентных пунктов для GPT-4 и на 35 пунктов для GPT-3.5, при этом сократив кодовую базу пользователя с 430 до 100 строк.
• Интерактивный поиск: в задачах ответов на вопросы агент-ассистент мог запрашивать дополнительный контекст, отправляя сигнал UPDATE CONTEXT; это срабатывало примерно в 19,4% вопросов в наборе Natural Questions, а итоговый показатель F1 составил 23,40%.
• Компонуемость по умолчанию: любой агент AutoGen сам по себе является валидным «инструментом», который может вызвать другой агент, поэтому иерархические конвейеры собираются без специального связующего кода.

Что работает, а что — нет

Результаты MATH и ALFWorld выглядят убедительно — это контролируемые, воспроизводимые сравнения с известными базовыми показателями на реальных бенчмарках. Цифра в 69,48% значима, поскольку она изолирует преимущество обратной связи от выполнения кода в рамках структурированного диалогового цикла.

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

Метафора «диалогового программирования» также более хрупка, чем кажется в демо-версиях. GroupChatManager выбирает следующего говорящего, промптя LLM выбрать из списка агентов. Этот выбор сам по себе является шагом вероятностной генерации текста, а значит, поток управления может пойти не так тонкими способами, которые не вызывают исключений. Для агента обратной записи в книгу учета, где порядок операций важен, а ошибочный вызов инструмента может повредить журнал, недетерминированный выбор говорящего — это серьезный риск.

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

Почему это важно для ИИ в финансах

Аргументы в пользу многоагентных систем в сфере финансов очевидны: сверка, проводки и отчетность естественным образом являются отдельными задачами. Конвейер Beancount мог бы включать LedgerReaderAgent для чтения книги в режиме read-only, ReconcilerAgent для сравнения транзакций с банковскими выписками, WriterAgent для предложения новых записей и ReviewerAgent для их проверки на соответствие правилам плана счетов перед фиксацией записи. Паттерн UserProxyAgent в AutoGen — это правильная абстракция для WriterAgent: он может выполнить фактическую запись в книгу и вернуть результат в виде сообщения для проверки ReviewerAgent.

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

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

Что почитать дальше

• AgentBench: Evaluating LLMs as Agents (Liu et al., arXiv:2308.03688, ICLR 2024) — бенчмарк для LLM в восьми различных агентных средах, включая веб-серфинг, кодинг и манипуляции с базами данных; разрыв между коммерческими и open-source моделями является ключевым выводом и напрямую влияет на выбор базовых моделей для финансовых агентных конвейеров.
• TradingAgents: Multi-Agents LLM Financial Trading Framework (arXiv:2412.20138) — прямая реализация паттерна AutoGen для финансовых рынков со специализированными агентами аналитика, исследователя, трейдера и риск-менеджера; результаты коэффициента Шарпа и максимальной просадки дают первые реальные показатели производительности многоагентных финансовых систем.
• AGENTLESS: Demystifying LLM-based Software Engineering Agents (Xia et al., arXiv:2407.01514) — утверждает, что простой «безагентный» двухфазный подход (локализация, затем исправление) превосходит сложные многоагентные фреймворки на SWE-bench; полезный противовес предположению, что большее количество агентов всегда помогает.