Идея на первый взгляд кажется банальной, но мультиагентные системы ещё не стали стандартом для многих приложений. Если конкретнее, то если один агент на базе LLM может выполнять задачи, то несколько агентов должны решать задачи лучше. Можно разделить работу, можно создать «совет», чтобы они проверяли друг-друга. На практике команды агентов часто работают медленнее, с большими затратами и зачастую глупее, чем один. В статье исследователей из Google и MIT "Towards a Science of Scaling Agent Systems" рассматривается интересная инженерная проблема: «когда мультиагентная система более эффективна, чем один агент?».
Что именно сравнивали и почему это важно
Авторы разделяют «агентные» задачи, где нужна не разовая генерация, а многошаговое взаимодействие со средой, добывание недостающей информации, корректировка плана по обратной связи и удержание модели мира в голове (она же будет меняться и уточняться). Именно для таких задач мультиагентные системы выглядят наиболее перспективно, но именно тут они и теряют большую часть эффективности из-за проблем с координацией.
Чтобы не размениваться на частные случаи, исследователи сделали большую и аккуратную серию экспериментов: 180 конфигураций на четырёх бенчмарках и с тремя семействами LLM (OpenAI, Google, Anthropic). Здесь сравнением важно доверять, потому что у разных систем соблюден паритет в инструментах, а также промтах и бюджетах на токены. То есть что командным системам дали больше ресурсов использовании любых асов, которых нет у других систем.
Пять способов «организовать команду»
В этом исследовании сравниваются пять разных архитектур: индивидуальное использование большой языковой модели (SAS) и четыре мультиагентных архитектур. В независимой архитектуре каждый агент решает задачу отдельно, а затем их ответы агрегируются. В централизованной архитектуре есть оркестратор, который делит задачу на подзадачи для агентов, а затем оценивает и агрегирует их выводы. В децентрализованной архитектуре агенты обмениваются сообщениями в общем чате. Гибридная архитектура сочетает в себе централизованное и горизонтальное общение между агентами. Описания этих архитектур основаны на организационных терминах, например, "агенты", "оркестратор". Однако важно не метафорическое описание, а конкретное измерение того, как задачи решаются при этих организационных подходах. Мультиагентные архитектуры дают разным моделям разные задания, но не похоже, чтобы эти архитектуры оптимизировали использование ресурсов, подвергая несколько моделей значительным перекрывающимся вычислениям. В некоторых сценариях ошибки могут усиливаться, и неясно, когда использование ресурсов в несколько раз выше.
Где команда справляется, а где нет
Мультиагентные системы показали наибольший прирост в Finance-Agent при централизованной координации (до +80.9%), что напоминает задачу, в которой полезна командная работа: задачу можно разбить на подзадачи и проверить решения агентов, при этом ошибку можно обнаружить на уровне системы оркестратора. В BrowseComp-Plus (динамическая веб-навигация) лучшая мультиагентная система -декомпозиция дает +9.2% к SAS. Возможно, обсуждение между равными полезно в более хаотичной среде: один агент может заметить путь решения, другой - проверить его, а третий заметить, что мы ушли с нужной страницы. Результаты в PlanCraft (планирование в Minecraft) были неожиданно плохими для всех изученных мультиагентных систем (-39%-70%). Это кажется очевидным, если мы подумаем о последовательном планировании в реальной жизни, где каждый шаг зависит от предыдущего. Любая дополнительная координация увеличивает затраты времени и токенов, не предоставляя никакой новой информации. Мы не увидели прироста, потому что задачу нельзя эффективно распараллелить.
Две главные проблемы координации: токены и ошибки
Первое неприятное последствие - координация почти всегда дорого обходится. В среднем накладные расходы на координацию составили по токенам около +58% у независимых агентов, +263% у децентрализованных, +285% у централизованных и до +515% у гибридных. При фиксированном бюджете это означает одну вещь - система тратит значимую долю ресурса на переговоры, а не на размышления о задаче. Второй риск - усиление ошибок. Если один агент совершил ошибку, другой агент может не только повторить ошибку, но и встроить ошибку в свою цепочку рассуждений и еще больше усилить ошибку. В архитектуре Independent это было наиболее заметно - ошибки усиливались в 17,2 раза по сравнению с базовой системой SAS. Централизованные, напротив, лучше справлялись с каскадными ошибками - до 4,4 раза, поскольку все решения проходили через узкое место оркестратора, которое обеспечивало некоторую детерминированную проверку.
Можно ли заранее угадать, какой подход выбрать
Самая полезная часть статьи — где авторы пытаются превратить свои наблюдения в прогноз. Они берут некоторые измеримые свойства координации (эффективность на токен, накладные расходы, избыточность, усиление ошибок) и строят показатель, который объясняет значительную часть разброса (R² = 0.513) и, кажется, переносится на новые домены без подгонки.
Самое главное — это правило «порога полезности команды»: если хороший одиночный агент уже решает задачу на уровне хотя бы 45% успеха, дальнейшая координация часто дает убывающую, а то и отрицательную отдачу. То есть «помочь сильному агенту командой» является не самой универсальной стратегией.
Также чем больше в задаче применяется инструментов, тем более большими являются накладные расходы координации, если мы держим бюджет на токены фиксированным. Думаю, это потому, что инструменты уже истощают бюджет — они требуют много контекста, и их нужно использовать осторожно. Добавление координации просто слишком распыляет бюджет.
Что это меняет в разработке агентных систем
В этой работе утверждается, что команда агентов не всегда эффективна. Если задача декомпозируется и допускает независимую верификацию, то координация (особенно централизованная) дает огромный выигрыш в качестве. Если задача строго последовательная и требует согласования модели мира, избыточные переговоры между агентами быстро дают обратный эффект.
Хочется отметить, что в работе показывается не только «кто кого», но и почему: через токен-экономику, каскады ошибок, наблюдаемые показатели координации. Это приближает проектирование мультиагентных систем к инженерному подходу, а не перебору систем методом баранего тыка.
***
Если вам интересна тема ИИ, подписывайтесь на мой Telegram-канал — там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.
