UniMASO: подбор модели под роль каждого агента вместо «сильнейшей везде»

ШАГ 1: Берём цепочку агентов (кто кому передаёт результат) и пул моделей от дешёвых до сильных
ШАГ 2: Идём по агентам в порядке цепочки → для каждого предлагаем варианты «промпт + модель»
ШАГ 3: Оцениваем каждый вариант на 3 уровнях:
        • локально (справился ли агент со своей ролью)
        • вниз по цепочке (стало ли лучше следующему агенту)
        • глобально (стал ли лучше финальный ответ)
ШАГ 4: Отсекаем всё, что дороже и не лучше. Оставляем «лучшие по качеству при данной цене»
ШАГ 5: Смотрим на цепочку целиком → согласуем выбор моделей между агентами (голосование нескольких «взглядов»)
ШАГ 6: Записываем в память, какие изменения были удачными, дорогими или конфликтными → подсказки для следующего раунда
Повторяем 3 раунда

Всё выполняется кодом, это отдельные запуски оптимизатора. В чате это не воспроизвести одним промптом.

Метод сильнее всего там, где цепочка из нескольких агентов гоняет много однотипных запросов, и счёт за API заметен. Он слабее на единичных сложных задачах, где одна ошибка критична.

Задача: Селлер на Ozon и Wildberries собирает автоматизацию в n8n для обработки отзывов. Приходит около 3000 отзывов в месяц. Цепочка из четырёх агентов: классификатор тональности, аналитик причин жалоб, автор ответа покупателю и ревьюер, который проверяет, что ответ не обещает лишнего (возврат, компенсацию). Сейчас на всех четырёх стоит самая дорогая модель, и счёт растёт.

Промпт (ручная версия идеи, для чата):

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



Агент_1 «Классификатор»: определяет тональность отзыва (позитив/нейтрал/негатив) и тему. Передаёт Агенту_2.
Агент_2 «Аналитик»: находит причину жалобы (брак, доставка, размер, ожидания). Передаёт Агенту_3.
Агент_3 «Автор ответа»: пишет ответ покупателю в тоне бренда. Передаёт Агенту_4.
Агент_4 «Ревьюер»: проверяет, что ответ не обещает возврат или компенсацию вне политики магазина.



Лёгкая (дёшево, быстро), Средняя, Сильная (дорого, лучше рассуждает)



Для каждого варианта «промпт + модель» оцени:
1. Локально: справляется ли агент со своей ролью?
2. Вниз по цепочке: хватает ли его вывода следующему агенту?
3. Глобально: даст ли это хороший итоговый ответ покупателю?



Пока есть что улучшать (максимум 3 раунда):
  Для каждого агента по порядку цепочки:
    - предложи 2-3 варианта «промпт + модель»;
    - для каждого оцени качество (по уровням выше) и относительную стоимость;
    - отбрось варианты, которые дороже и не лучше текущего;
    - оставь те, которые нельзя улучшить по качеству, не потеряв в цене.
  Затем посмотри на цепочку целиком: не конфликтуют ли выбранные модели?
  Если локальное улучшение ухудшило соседа — откати.



Веди список: (а) дешёвые изменения, которые не ухудшили итог; (б) улучшения у одного агента, которые навредили итогу; (в) дорогие изменения, которые помогли. Используй его в следующем раунде.



Таблица: агент → модель → причина выбора → риск. В конце — итоговая оценка «качество / стоимость» относительно варианта «сильная модель везде».


Мои данные: {примеры 5-10 реальных отзывов, политика возвратов, тон бренда}

Результат: Модель выдаст пошаговый разбор по раундам: что предлагается каждому агенту, какие варианты отброшены как «дороже и не лучше», где локальное улучшение ломает соседа. В конце придёт таблица «агент → модель → обоснование → риск» и сравнение с вариантом «сильная везде». Это гипотеза для проверки: модели в чате не запускают ваши агенты. Проверять придётся на 10–20 реальных отзывах.

Слабость: «Лучшая модель везде» кажется безопасной, но роли в цепочке разные по сложности. Классификатору тональности не нужен флагман, а ревьюеру политики возвратов нужен. А оптимизация промптов сама по себе не добавляет способностей: если роли не хватает рассуждения, формулировка не поможет. К тому же оптимизатор склонен удлинять промпты и ответы, поэтому стоимость растёт.

Сильная сторона: Для многих ролей в цепочке нужна аккуратность, а не глубина рассуждения: разметить, перефразировать, собрать, отформатировать. Средние и малые модели тянут это на уровне больших. В таблице статьи Qwen3.5-27B во всех пяти задачах почти догоняет DeepSeek-V4-Pro (66.8 против 68.2) при стоимости в четыре раза ниже.

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

Рычаги управления: - Число раундов и вариантов → меньше для простой цепочки, экономия токенов. - Пул моделей → сузь до двух (дешёвая и сильная), если выбор из трёх-пяти избыточен. - Вес цены (в статье λ = 0.2) → в промпте формулируй как «стоимость важна умеренно» или «стоимость не важна, если качество выше». - Уровни оценки → убери «вниз по цепочке», если агенты независимы (параллельные). - Память неудач → не выбрасывай, она предотвращает повтор откатов.

Авторы не приводят готовый промпт в доступной части статьи (шаблоны в Приложении F), поэтому ниже ручная версия логики метода, а не оригинал.

Ты — оптимизатор мультиагентной цепочки. Цель: назначить каждому агенту
модель и уточнить промпт так, чтобы качество финального ответа не упало,
а стоимость была минимальной.



{список агентов: имя, роль, что получает на вход, кому передаёт результат}



{список доступных моделей с пометкой «дёшево/средне/дорого»}



1. Локально: справляется ли агент со своей ролью?
2. Вниз по цепочке: достаточно ли его вывода следующему агенту?
3. Глобально: насколько хорош итоговый ответ?



Пока есть что улучшать (максимум {число_раундов} раундов):
  Для каждого агента в порядке цепочки:
    - предложи {число_вариантов} вариантов «промпт + модель»;
    - оцени качество по трём уровням и относительную стоимость;
    - отбрось варианты, которые дороже и не лучше текущего;
    - оставь те, которые нельзя улучшить по качеству, не потеряв в цене.
  Затем оцени цепочку целиком: не конфликтуют ли соседи?
  Локальное улучшение, ухудшившее соседа или итог, откати.



Веди список: дешёвые удачные изменения; локальные успехи, навредившие итогу; дорогие, но эффективные. Опирайся на него в следующих раундах.



Таблица «агент → модель → причина → риск». Итог: качество и стоимость относительно «сильная модель везде».


Тестовые данные: {5–10 реальных примеров входа}
Критерий качества: {что считать хорошим ответом}

Что подставлять: цепочку (кто что делает и кому передаёт), пул моделей, реальные примеры входа и критерий хорошего результата. Без критерия и примеров оптимизатор будет гадать.

🚀 Быстрый старт — вставь в чат:

Вот шаблон UniMASO для подбора моделей и промптов в цепочке агентов. 
Адаптируй под мою задачу: [твоя цепочка агентов]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, какие агенты в цепочке, какие модели доступны и что считать хорошим результатом. Это нужно, потому что метод строится на сравнении «качество против цены» для каждой роли. Без этих данных сравнивать нечего.

⚠️ Метод не запустить в чате: Оригинал — автоматический поиск на коде: запуски на выборке, подсчёт токенов, три раунда оптимизации. Ручная версия выше — не проверенная авторами адаптация. Она помогает думать о ролях, но не заменяет реальные прогоны.

⚠️ Сложные задачи любят сильную модель: На задачах с вызовом функций, программированием и научными вопросами части уровня GPQA однородная сильная конфигурация местами выигрывала. Для критичных ролей экономия на модели вредит.

⚠️ Выигрыш в качестве мал, выигрыш в цене велик: Рост качества около 0.6 пункта. Это не «лучше», это «так же, но дешевле».

⚠️ Нужны примеры для проверки: Оптимизатору нужна выборка (в статье 50 примеров) и измеримый критерий успеха. Для творческих задач без чёткой оценки метод ненадёжен.

⚠️ Узкая база проверки: Модели из двух семейств (Qwen и DeepSeek), стоимость пересчитана по их прайсу. На других моделях и при другой ценовой разнице всё может сдвинуться.

⚠️ Децентрализованная схема: Там качество чуть упало при падении цены. Вывод «всегда не хуже» не универсален.

Команда собрала пул из пяти моделей: от Qwen3.5-4B до DeepSeek-V4-Pro. Проверяли на пяти наборах задач: сложная математика, научные вопросы, вызов функций, код и вопросы с несколькими источниками. Агенты соединялись в пяти разных схемах: независимо, через центрального координатора, по цепочке, децентрализованно и динамически. Главное сравнение: лучший из «однородных» вариантов (все агенты на DeepSeek-V4-Pro с лучшей оптимизацией промптов) против UniMASO с разными моделями на разных ролях. Итог: 69.79 при стоимости 208 условных единиц против 70.40 при 31 единице, то есть экономия 85%.

Любопытнее всего два факта. Во-первых, оптимизаторы одних промптов стабильно поднимали стоимость. У флагмана цена выросла с 184 до 208 единиц ради прироста в полпункта: промпты и ответы распухали. Во-вторых, абляции (отключение компонентов) показали, что важно всё. Сначала промпты, потом модели — 66.39 вместо 70.40, цена вдвое выше. Без согласования между агентами — 68.49. Без учёта цены в поиске — 69.42 при удвоенной стоимости. Вывод для практики: промпт и модель — связанные решения. Меняя одно, перепроверяй другое и смотри на цепочку, а не на отдельного агента.

🔧 Техника: добавить правило выбора модели в инструкции оркестратора.

Если вы работаете в Claude Code или похожем агенте с субагентами, можно закрепить в файле инструкций (CLAUDE.md / AGENTS.md) логику из статьи. Это не проверено в самой работе, это перенос идеи:

Copy

Правила выбора модели для субагентов:
- Рутинные роли (форматирование, сбор результатов, классификация, поиск по файлам) — самая лёгкая модель.
- Роли с рассуждением (планирование архитектуры, ревью безопасности, сложный дебаг) — самая сильная модель.
- После любой замены модели прогони 3–5 тестовых примеров и сравни итог со старым вариантом.
- Не оптимизируй промпт отдельного агента, не посмотрев на то, как его вывод использует следующий.

• Работа: Not Every Agent Needs the Strongest Model: Unified Prompt–Model Optimization for Heterogeneous LLM-based Multi-Agent Systems (UniMASO)
• Авторы: Mingxiu Cai, Haoyang Xian, Xinyu Ma, Yutong Wang, Zhenxi Song, Jing Li, Xuebo Liu — Harbin Institute of Technology, Shenzhen
• Код: https://github.com/Achilles008/UniMASO_main
• Опорные работы: MASPO (Wang et al., 2026), MASPOB, MIPRO, FrugalGPT, RouteLLM, MasRouter, Hetero-Designer