«Богатство агентов»: масштабирование ИИ без увеличения модели

Представьте, что вместо одного огромного универсального ИИ-ассистента у вас есть сотни маленьких специализированных агентов от разных разработчиков, и вместе они решают задачи лучше, чем любая отдельная система, созданная даже при бюджете в несколько раз больше. Именно эту идею исследуют авторы научной работы The Wealth of Agents: Scaling Agentic AI Across Developers ^[1].

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

Один разработчик — один потолок

Сегодня агентные системы (те, что сами планируют, вызывают инструменты, ищут в интернете и работают с файлами) почти всегда строит одна компания-разработчик (OpenAI, Anthropic, Google и т. д.). Естественно, она полностью контролирует всех агентов, их поведение ^[2] и оркестрацию, и такие системы получили название SDA (single-developer agentic systems).

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

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

Мульти-разработческая агентная система (MDA)

В качестве альтернативы авторы научной статьи предлагают MDA (multi-developer agentic system). Это система, которая при каждом запросе будет координировать агентов от многих независимых разработчиков, объединяя их комплементарные способности.

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

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

Но здесь важно отличать MDA от классических мульти-агентных систем (MAS). В MAS один разработчик контролирует всех агентов, но в MDA он не может указывать третьим лицам, что им развертывать. Значит, нужен механизм стимулов, то есть «невидимая рука», которая побуждает эгоистичных разработчиков публиковать агентов, полезных всей системе.

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

Теперь давайте поговорим о том, как же устроена система MDA. На рисунке ниже представлены три варианта взаимодействия с ИИ. В первом случае Single Developer Agent (SDA) решает задачу целиком самостоятельно.

В случае использования Routed-SDA (rSDA) маршрутизатор выбирает одну систему из пула на весь запрос. Так, к примеру, сегодня работают пользователи, выбирая Claude или ChatGPT под конкретную задачу, но победитель все равно будет решать все в одиночку.

Но при использовании δ-MDA — запрос декомпозируется на подзадачи, каждая независимо маршрутизируется к наиболее подходящему для нее агенту, а полученные ответы композируются. В этом объединении и заключается суть полноценной MDA.

Различие между этими вариантами взаимодействия принципиально. В SDA и rSDA агент должен уметь все сразу — иначе он проиграет. В то время как δ-MDA агент может быть силен в одном и слаб в другом, при этом его сильную сторону извлекут, а слабину закроют другие. Платой за это являются накладные расходы на декомпозицию, коммуникацию и композицию. А вот ответ на вопрос, окупаются ли они будет зависит от задачи и квалификации группы разработчиков.

Как проверяли работу MDA

Авторы научной работы честно написали, что реальных разработчиков в эксперименте не было, но вместо этого они построили мета-агентный пайплайн, который симулирует работу разработчиков и автоматически строит агентов под фиксированный бюджет:

Входные данные формировались в виде JSON-описаний целевой функциональности из неразмеченного датасета. Одна спецификация означала универсал (k=1), группа специалистов (k>1).

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

Гетерогенность обеспечивалась с помощью разных LLM с различными ресурсными возможностями. Также в качестве агентов применялись универсальные single-agent, специализированные и мульти-агентные SDA с оркестратором.

За маршрутизацию отвечал самообучающийся LLM-роутер. Он видит описания агентов (часто приукрашенные — модель конкуренции за трафик!) и накапливает опыт ^[3] взаимодействий, строя глобальные и контекстные ранжирования.

В качестве датасетов использовались:

• GAIA для широкого ассистентского бенчмарка: веб-поиска, работы с аудио/изображениями, файлами docx/.pptx/.pdf/.xlsx и комбинированными навыками.

• SealQA — узкий QA-бенчмарк про веб-поиск.

Проверка эффективности работы MDA производилась с помощью метрик точности, стоимости API, доли участия разработчиков и координационных издержек.

Что же в итоге получилось

Результат эксперимента оказался довольно интересен, так как коалиция «маленьких» смогла обогнать «больших». На GAIA медианная отдельная SDA дала результат 21%, лучшая отдельная SDA — 35%, а вот δ-MDA дала более 70%. То есть объединение дало +35 п.п. к лучшему специалисту. Лучшая мульти-агентная SDA достигла 67%, но стоила $29 — более чем вдвое дороже δ-MDA.

Важную роль играет обучение ^[4] роутера, так как разработчики приукрашивают возможности своих агентов, и только опыт взаимодействия вскрывает реальные сильные и слабые стороны. Так, при использовании необученного σ-агента (только по описаниям) точность падает до 61% (−9.1 п.п.). 

Еще одной интересной особенностью MDA является то, что она лучше использует «средних» разработчиков. Модифицированная δ-MDA без high-tier агентов достигла 67% при стоимости $9 — против 60% при $8 у лучшей medium/low-tier SDA. Роутер в MDA выбирает medium-tier агентов 56% времени против 33% в rSDA. Специализация снижает требуемую широту компетенций и средний разработчик начинает выигрывать. В целом этот результат вполне соответствует реальной жизни, где зачастую дешевле использовать двух-трех милдов вместо одного сеньора. 

Отдельно авторы провели эксперимент с «добавлением агента». Для этого брали пул с одной задачей и добавляли агента, заточенного под другую задачу.

В итоге получали:

– GAIA → SealQA: +5 п.п. (53.2% → 58.2%); a_AUG в изоляции — 35.4%.

– SealQA → GAIA: +12 п.п. (40.4% → 53.2%); a_AUG в изоляции — всего 19.1%.

Получается, что точность в изоляции недооценивает пользу агента в экосистеме. Вопрос «оптимального распределения ресурсов» надо ставить не для отдельного разработчика, а для системы целиком.

Но результаты также выявили случаи, когда MDA проигрывает. Так, при использовании узкого домена задач или только веб-поиска δ-MDA стабильно хуже rSDA при более высокой стоимости. Декомпозиция добавляет ошибки ^[5] и задержки, а извлекать разнородные преимущества при этом не из чего.

А что все это значит на практике?

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

Также основная проблема здесь заключается в том, как стимулировать ^[6] и поддерживать широкое сообщество разработчиков строить системы, продвигающие взаимодействие по принципу MDA? Здесь основные требования к экосистеме заключаются в необходимости согласовать интересы разработчиков с коллективным прогрессом, поддержании вклада разработчиков с разными ресурсами и способностями и возможности фокусироваться на собственных сравнительных преимуществах.

Но некоторые вопросы у нас все-таки остаются открытыми. Так, авторы в своей работе честно написали, что координационные издержки могут съесть теоретический выигрыш и реальная применимость зависит от задачи (кейс SealQA). Также масштабирование маршрутизации и действия по композиции/декомпозиции являются открытой инженерной задачей, требующей детальной технической проработки.

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

Еще одной нерешенной проблемой является вопрос доверия к сторонним агентам. Архитектура MDA предполагает, что задача может уходить агентам, поддерживаемым сторонними компаниями, и здесь без четко сформулированного соглашения о нераспространении (NDA) и соответствующего контроля не обойтись. Важно понимать, что один вредоносный агент не должен вызывать каскадный отказ.

Ну и конечно, настоящая проверка возможна только в «дикой природе».

Итог

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

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

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