Я прогнал шесть мультиагентных паттернов на трёх бенчмарках и трёх моделях. Под командой агентов тут понимаются связки вроде критика-актора или оркестратора с подчинёнными. Почти везде такая команда проиграла одиночному агенту. Проиграла и по точности, и по цене, а по цене иногда вчетверо.
Это была бы скучная заметка в духе «МАС не нужен, расходимся». Но нашлось исключение. Чем труднее задача для модели, тем больше у команды появляется шанс на выигрыш. Так что вопросов у меня два. Влияет ли вообще топология системы на результат? И если влияет, можно ли автоматически выбирать подходящий паттерн под конкретную задачу? Ответ на второй вопрос пока отрицательный, и самое любопытное здесь именно почему.
Примеры я показываю на мультиагентном фреймворке FEDOT.MAS, а весь код экспериментов с паттернами, прогонами и графиками лежит в репозитории. Я меряю инструмент, который сам и пишу. Но и выводы выйдут в основном не в пользу мультиагентности, так что это скорее самокритика, чем реклама.
Паттерны МАС
Каждый паттерн это способ собрать в одну систему несколько вызовов модели в определённом порядке. Для сравнения я использовал следующие:
single. Один агент, один проход. Бейзлайн, с которым сравниваем всё остальное.
chain. Цепочка из двух шагов. Один агент раскладывает задачу, другой решает по разложенному.
voting. Два агента решают задачу независимо, а третий судья сводит их ответы в один.
eval_optimizer. Генератор предлагает ответ, критик принимает его или возвращает на доработку.
orchestrator. Координатор на каждом шаге решает, кто из подчинённых работает дальше, и так пока не скажет «готово».
blackboard. Агенты пишут на общую доску. Это исследователь, скептик-проверяющий и компоновщик.
Фреймворк поддерживает все эти паттерны и их комбинации, а система собирается из примитивов через перегруженный оператор +. Пример паттерна eval_optimizer:
from fedotmas.adapters.pydantic_ai import PydanticAI
from fedotmas.sdk import agent, Condition
llm = PydanticAI("openrouter:openai/gpt-oss-20b")
gen = agent(
"gen", takes=dict,
prompt="Реши задачу; если есть замечание критика, учти его.",
input="Задача: {task}\nЗамечание (если есть): {verdict}"
)
critic = agent(
"critic", takes=dict, labels=["approve", "revise"],
prompt="Проверь решение: approve, если верно, иначе revise.",
input="Задача: {task}\nРешение: {draft}"
)
system = gen.into("draft") + critic.into("verdict")
# черновик -> вердикт, и так по кругу, пока критик не скажет approve
loop = system.loop(until=Condition(key="verdict", op="eq", value="approve"))
# стартовая точка и запуск
start_point = {"task": task, "draft": "", "verdict": ""}
answer = await loop.run(start_point, llm=llm)Остальные пять собираются похожим образом. Из интересного хочу отметить, что узлом системы может выступать как один LLM-агент, так и целая МАС или обычная механическая функция на Python.
Сетап эксперимента
Для тестов взял несколько стандартных бенчмарков разной сложности из разных областей. GSM8K это школьная математика. MMLU это вопросы в виде теста из областей от химии до истории. LogiQA это логические задачи. В качестве моделей-исполнителей взял gpt-oss-20b, ministral-8b и llama-3.1-8b. Брал не весь бенчмарк, а его подвыборку из 100 вопросов. В бенчах с разными областями делал бустрап-выборку с фиксированным сидом. Оговорка: на этом этапе рассматривались бенчмарки, не требующие инструментов для агентов.
Каждой роли давал простой и прямой промпт без специальной подгонки под паттерн и держал промпты на одном уровне во всех бенчмарках. Это было сделано, чтобы измерять архитектуру системы, а не промпт-инжиниринг.
Понадобятся ещё ориентир в виде оракула на задачу. Это если бы под каждую задачу кто-то всеведущий выбирал идеальный паттерн. Это потолок, который показывает, сколько в принципе можно выжать выбором.
Важная оговорка. Оракул выбирает задним числом, по уже посчитанным прогонам. Поэтому здесь есть допущение, что на повторном запуске выбранный паттерн дал бы примерно ту же точность. Поэтому выбор берётся по среднему из трёх прогонов, а не по одному, чтобы он отражал устойчивое поведение паттерна на задаче, а не разовую удачу.
Первый результат. Простые задачи
Начнём с лёгкого. На GSM8K и MMLU картина одинаковая. Одиночный агент сидит на границе «стоимость/точность», и сдвинуть его оттуда некуда.
На GSM8K у gpt-oss-20b single даёт 0.94 за 398 токенов на задачу. Лучший мультиагентный паттерн даёт 0.95, но уже за 1692 токена. Разница в один пункт лежит внутри шума, а платишь вчетверо больше. На MMLU всё то же самое. Любые «умные» надстройки над одним проходом либо не помогают, либо чуть мешают, и при этом всегда стоят в 2-4 раза дороже.
Отдельная поучительная история это оркестратор на слабой модели. У ministral-8b на GSM8K он умудрился сжечь 277 тысяч токенов на задачу. Координатор не может вовремя сказать «готово» и крутит цикл, скармливая растущую историю каждому вызову. Часть задач при этом просто упирается в лимит шагов.
Вывод: на коротких задачах, которые модель решает за один проход, команда агентов превращается в чистый оверхед.
Чем труднее задача, тем больше смысла в выборе
А теперь интересное. Если бы дело было только в том, что «МАС не нужен», статья бы тут и закончилась. Но посмотрим на ту же gpt-oss-20b на бенчмарках по нарастанию трудности.
Модель одна и та же, но зазор между лучшим фиксированным паттерном и оракулом-на-задачу растёт. На GSM8K он равен +3 пунктам, на MMLU уже +6, а на LogiQA +9. То есть чем труднее задача для модели, тем больше выигрыш можно было бы получить, выбирая паттерн под каждую конкретную задачу.
Запас показывает трудность задачи для модели, а не размер модели. Маленькая ministral-8b на лёгком GSM8K даёт всего +1 пункт запаса, потому что она там сильна. А llama-3.1-8b того же класса, но слабая на этих задачах (0.63-0.80), даёт уже +11…16 пунктов. Дело не в числе параметров, а в том, насколько задача трудна именно для этого исполнителя. Где-то выручает критик, а где-то хватает и одного прохода.
Вот и появляется что выбирать.
Раз выбор важен, давайте выбирать автоматически
Напрашивается простое решение. Поставить перед системой селектор в виде агента, который по тексту задачи выбирает паттерн. В FEDOT.MAS селектор это один агент с ограниченным выбором из меню паттернов. Получилось ли с ним повысить качество?
Нет.
Вот цифры на LogiQA у gpt-oss-20b. Одиночный агент даёт 0.77, случайный выбор паттерна 0.73, селектор только 0.71, а оракул 0.89. Селектор не просто не дотянулся до потолка. Он оказался хуже и одиночного агента, и случайного тыка. И так везде. Ни в одной из колонок селектор не обыграл одиночного агента. Случайный выбор он обходил только там, где в выборе была явный выброс по типу зацикливающегося оркестратора.
Дело не в том, что селектор «глупый». Дело в информации. Какой паттерн решит именно эту задачу на этой модели, это эмпирический факт, который лежит в матрице результатов, а не в тексте задачи. По одной формулировке его не вывести. Задачи на вид одинаковые, а решаются разными паттернами по причинам, которых в тексте просто нет. Поэтому и более умный судья тут не спасёт. Проблема не в уме, а в отсутствии сигнала на входе.
Что с этим делать? Как вариант, учить селектор на примерах вида «такую задачу на такой модели лучше всего решает такой паттерн». Это уже файн-тюн, и это тема для отдельного разговора.
Выводы и что дальше
Что удалось узнать и что может быть полезно на практике?
Оркестратор на слабой модели опасен. Без жёсткого лимита шагов он зацикливается и сжигает токены.
Выбор паттерна окупается только на трудных для модели задачах.
Стоит честно отметить слабое место замера. В паттернах с проверкой верификатором работает та же модель, что и генератор, так что она по сути судит сама себя, без независимого сигнала. Поэтому и честный следующий шаг ведёт туда, где у мультиагентности есть принципиальный способ победить. Это код с реальным прогоном тестов вроде HumanEval, где критик перестаёт быть «вторым мнением» и становится запускалкой тестов с настоящим сигналом. Либо же сложные бенчмарки по типу GAIA2, требующие инструментов и взаимодействия с внешним миром.
А пока все результаты лежат на GitHub и могут быть воспроизведены на других моделях.