Суть эксперимента: от 3 до 30 вызовов
Авторы проанализировали 8 архитектур оркестрации агентов на базе 5 инструкционно-настроенных моделей размером 7–9B. Цель — понять, помогает ли масштабирование команды (увеличение количества вызовов LLM) и при каких условиях. Тестирование проводилось на пяти бенчмарках с короткими ответами и одном с исполняемым кодом.
Ключевые цифры: разрыв в эффективности
Результаты показали резкую зависимость от типа задачи. Увеличение бюджета вызовов с 3 до 30 дало колоссальный прирост в математических задачах, но минимальный — в задачах на общие знания и логику.
| Бенчмарк | Тип задачи | Прирост точности (3→30 вызовов) |
|---|---|---|
| GSM8K, GSMHard | Арифметические задачи | До +17 пунктов |
| ARC, GPQA, MMLU | Множественный выбор / Общие знания | Максимум +4 пункта |
Победитель и проигравшие: Proposer-Critic
Архитектура Proposer-Critic (предложение-критика) показала самый крутой рост в арифметике и обошла остальные решения при максимальном бюджете. Однако она же оказалась одной из самых слабых в других категориях. Ни одна архитектура не выиграла по всем фронтам одновременно.
Механика: Generate-Transform Decomposition
Авторы ввели точную декомпозицию «Генерация-Трансформация» для объяснения результатов. Любая рабочая схема делится на покрытие (coverage) и трансформацию (transform). В математике есть пространство для покрытия, которое критик эффективно преобразует в точность. В задачах с множественным выбором покрытие быстро насыщается, а в генерации кода восстановление точности почти исчезает — результат идет параллельно с количеством кандидатов.
Экономика вызовов
Даже при равном количестве вызовов стоимость токенов варьируется в 2.1 раза в зависимости от архитектуры. Масштабирование команды — это не универсальный рычаг, а специфическая ставка, зависящая от задачи и выбранной архитектуры.
Источник: arXiv cs.AI ↗