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, який регулює черговість ходів у великих ансамблях.

Основна ідея полягає у тому, що автори називають «програмуванням розмов» (conversation programming): замість того, щоб прописувати логіку оркестрації в коді вручну, ви вказуєте, що повинен робити кожен агент за допомогою системних підказок (prompts) природною мовою, а передача повідомлень бере на себе управління потоком виконання. Стаття демонструє це на прикладах розв'язання математичних задач, QA з розширеним пошуком (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 рядків.
• Інтерактивний пошук: у завданнях QA агент-асистент міг запитувати додатковий контекст, надсилаючи сигнал UPDATE CONTEXT; це спрацьовувало приблизно у 19,4% випадків у наборі Natural Questions, а загальний показник F1 склав 23,40%.
• Композитність за дизайном: будь-який агент AutoGen сам по собі є валідним «інструментом», який може викликати інший агент, тому ієрархічні конвеєри збираються без спеціального сполучного коду.

Що витримує критику, а що ні

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

Слабким місцем є аналіз вартості та затримок (latency), точніше його відсутність. Кожен хід у GroupChat ініціює повний виклик LLM з накопиченою історією розмови. Робочий процес із чотирьох агентів і десяти раундів означає мінімум сорок викликів LLM, кожен з яких має контекстне вікно, що постійно зростає. У статті жодного разу не повідомляється про вартість токенів або затримку для будь-якого з додатків. У реальному конвеєрі обліку, що обробляє тисячі транзакцій, це упущення не є академічним — воно визначає, чи життєздатна така архітектура взагалі.

Метафора «програмування розмов» також виявляється крихкішою, ніж здається в демо-версіях. GroupChatManager обирає наступного спікера, просячи LLM вибрати зі списку агентів. Цей вибір сам по собі є етапом імовірнісної генерації тексту, а отже, потік керування може піти не так у ледь помітний спосіб, який не викликає помилок (exceptions). Для агента запису в реєстр, де порядок операцій має критичне значення, а помилковий виклик інструменту може пошкодити запис у журналі, недетермінований вибір спікера є серйозним ризиком.

Нарешті, усі оціночні завдання є односесійними та короткостроковими. Немає експериментів, де агенти накопичують стан протягом днів, обробляють суперечливі інструкції або потребують розв'язання конфліктів між старою пам'яттю агента та новим записом у реєстрі. А це саме ті сценарії, що виникають у реальних робочих процесах бухгалтерського обліку.

Чому це важливо для ШІ у фінансах

Аргументи на користь мультиагентних систем у фінансовому ШІ очевидні: звірка, проведення операцій та звітність — це природно розділені завдання. Конвеєр Beancount міг би мати LedgerReaderAgent для читання реєстру, ReconcilerAgent для порівняння транзакцій із банківськими виписками, WriterAgent для пропозиції нових записів та ReviewerAgent для їх перевірки на відповідність правилам плану рахунків перед фіксацією запису. Патерн UserProxyAgent в AutoGen — це правильна абстракція для WriterAgent: він може виконати фактичний запис у гросбух і повернути результат як повідомлення, яке перевірить ReviewerAgent.

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

Проблема недетермінованого вибору спікера вирішується: ви можете перевизначити GroupChatManager детермінованою функцією на Python, яка направляє потік на основі вмісту повідомлень. Але про це потрібно знати, а стаття не висуває це питання на перший план.

Що почитати далі

• AgentBench: Evaluating LLMs as Agents (Liu et al., arXiv:2308.03688, ICLR 2024) — оцінює LLM у восьми різних агентних середовищах, включаючи веб-серфінг, кодування та маніпуляції з базами даних. Ключовим висновком є розрив між комерційними та відкритими моделями, що безпосередньо впливає на вибір базових моделей для фінансових агентних конвеєрів.
• 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. Це корисна противага припущенню, що більша кількість агентів завжди допомагає.