Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Многоагентную систему научили выбирать, когда базовой LLM нужны дополнительные роли и обмен сообщениями, а когда координацию можно сократить. На сильных моделях подход поднял среднюю точность на 2,75 процентного пункта и одновременно уменьшил расход токенов на 36,26%; поскольку препринт The Hong Kong Polytechnic University не прошёл рецензирование, все числа в нём — замеры самих авторов. Для продуктовой команды это превращает состав агентов и связи между ними из постоянной схемы в настройку для каждого запроса.
Как система оценивает компетентность базовой модели
Обычная динамическая оркестрация смотрит на содержание запроса и подбирает под него роли. Новый метод добавляет второй сигнал: насколько хорошо именно эта базовая LLM должна справляться с текущей задачей без развитой координации.
Сначала для каждой модели один раз строят профиль возможностей. LLM отвечает на общий набор проверочных вопросов из нескольких областей, расположенных от простых к сложным. Результаты сохраняют как двоичную матрицу: правильный ответ означает единицу, неправильный — ноль. Один и тот же набор позволяет сопоставлять разные базовые модели.
Для нового запроса система определяет, какие области знаний ему ближе, и выбирает соответствующие части профиля. Это представление объединяют с содержанием задачи и обучают предсказывать вероятность самостоятельного успеха модели. Цель для обучения получают из повторных запусков базовой LLM на том же запросе.
Оценка управляет двумя частями оркестрации. Первая решает, какие роли из заранее заданного набора стоит подключить. Роль получает больший вес, если соответствует задаче, но общий бюджет ролей уменьшается, когда базовая модель и так часто отвечает правильно.
Вторая часть строит направленный граф, то есть схему обмена сообщениями между выбранными ролями. Обучение вознаграждает правильный итоговый ответ и штрафует лишние связи. Чем увереннее базовая модель справляется сама, тем дороже для оптимизатора становится дополнительная коммуникация.
Профиль модели улучшил результат и сократил лишние сообщения
На шести наборах задач средний показатель метода достиг 93,81% против 90,10% у G-Designer, ближайшего из представленных конкурентов. В этот итог входят вопросы на знания, математические задачи и генерация кода, поэтому среднее объединяет точность ответов и Pass@1 — долю задач по программированию, решённых с первой попытки.
Проверка отдельных компонентов показывает, что системе нужен не только текст запроса. После удаления профиля базовой модели расход токенов вырос на 154,64%, а средний результат на HumanEval, AQuA и MMLU снизился на 3,02 процентного пункта. Свободное текстовое описание модели тоже оказалось хуже структурированного профиля: оркестратору полезнее видеть, какие задачи LLM действительно решила, а не знать её общие характеристики.
Метод проверяли на GPT-4o, GLM 5.1, Gemini 3.1 Pro, Qwen3-14B, Llama3.1-8B и Gemma-3-12B. Сравнение охватывало одиночные рассуждения, фиксированные цепочки и деревья агентов, дебаты, обрезку связей и динамические схемы. Тенденция сохранилась на GLM 5.1 и Gemini 3.1 Pro, которые не использовали при построении проверочных заданий и сборе данных для оценки компетентности.
Что меняется в планах команд с многоагентной архитектурой
Работа меняет планы прежде всего там, где команда собирается закрепить один состав агентов для всех запросов. Постоянная плотная схема оказывается не нейтральным запасом надёжности: сильная базовая модель может получать от неё мало пользы, но всё равно оплачивать сообщения, задержку и повторную обработку контекста.
Практическая архитектура из этой работы состоит из трёх слоёв. Сначала команда измеряет возможности каждой поддерживаемой LLM на стабильном наборе заданий. Затем отдельная модель оценивает пару «запрос — базовая LLM». После этого оркестратор выбирает роли и связи, учитывая одновременно ожидаемое качество и стоимость общения.
Разовый прогон проверочных задач добавляет расходы при подключении новой модели. В эксперименте экономия на сильных моделях покрывала их примерно после 28 запросов. Такой порог делает подход особенно уместным для сервисов с повторяющимися классами задач и заметным потоком, но менее убедительным для редких сценариев, где каждая задача устроена по-новому.
Это не готовый универсальный маршрутизатор. Компоненты обучали последовательно и отдельно для используемых наборов данных, а модуль построения графа получал по 40 обучающих запросов из каждого набора. Команде придётся подготовить собственные проверочные задания, определить роли, собрать оценки самостоятельного успеха и выбрать функцию полезности, которая отражает качество продукта, а не только правильность ответа.
Главный инженерный вывод не требует переносить весь метод. Даже более простое правило, которое перед запуском оценивает трудность запроса для выбранной LLM и ограничивает число агентов, может заменить схему «все общаются со всеми». Препринт даёт основание тестировать такую маршрутизацию раньше, чем наращивать постоянную многоагентную структуру.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
