TL;DR
Role-Specialized Mixture-of-Agents — техника, где два агента отдельно сравнивают целевой случай с двумя противоположными примерами-эталонами (один — «плохой» исход, другой — «хороший»), а третий агент-интегратор сводит оба вывода в финальное решение. Главная механика: каждый агент видит только ОДИН эталон и не спешит с выводом — только собирает сходства и различия.
Если дать модели сразу оба примера (хороший и плохой) в одном промпте и попросить оценить риск — модель размывает сигнал. Она либо слишком уверенно говорит «всё нормально», либо начинает видеть риск везде. Модели плохо удаётся держать в голове два противоречивых сценария одновременно и честно взвешивать их — она либо сваливается в одну сторону, либо усредняет до бесполезного «средне».
Решение — разбить сравнение на два отдельных, узких запроса (каждый агент сверяет с одним эталоном), а свести противоречивые выводы в одно решение — задача третьего агента-интегратора. Неожиданный бонус: если интегратор — «слабая» простая модель, она чаще ошибается в сторону «лучше перебдеть», что полезно для задач скрининга, где важнее не пропустить риск, чем не наврать по мелочи.
Схема метода
ШАГ 1 (агент "риск-аналитик", отдельный запрос):
Целевой случай + пример с ПЛОХИМ исходом → список сходств/различий, без вывода
ШАГ 2 (агент "защитный аналитик", отдельный запрос):
Целевой случай + пример с ХОРОШИМ исходом → список сходств/различий, без вывода
ШАГ 3 (интегратор, отдельный запрос):
Вывод агента 1 + вывод агента 2 + целевой случай → финальная оценка риска (в %)
Все три шага — это либо три отдельных запроса в одном чате, либо три разных чата (можно копировать текст между ними вручную).
Пример применения
Задача: Оценить риск, что клиент отменит подписку на сервис (например, стриминговую платформу или подписочный SaaS).
Промпт (агент 1 — «риск-аналитик»):
Вот профиль клиента: {данные клиента: как часто заходит, сколько платит,
сколько обращений в поддержку}.
Вот похожий клиент, который отменил подписку через месяц:
{профиль клиента с плохим исходом}.
Сравни их. Найди сходства и различия, которые могут говорить о риске отмены.
Не делай финальный вывод — просто перечисли наблюдения.
Промпт (агент 2 — «защитный аналитик»):
Вот профиль клиента: {тот же клиент}.
Вот похожий клиент, который остался лояльным больше двух лет:
{профиль клиента с хорошим исходом}.
Сравни их. Найди сходства и различия, которые говорят о низком риске отмены.
Не делай финальный вывод — просто перечисли наблюдения.
Промпт (интегратор):
Вот анализ риска: {ответ агента 1}.
Вот анализ защитных факторов: {ответ агента 2}.
На основе обоих анализов оцени вероятность, что клиент отменит подписку
в ближайший месяц (в процентах). Объясни решение в 2-3 предложениях.
Результат: два развёрнутых, узких сравнения — что роднит клиента с «отвалившимся» и что роднит с «лояльным» — и финальная оценка риска с коротким объяснением. Такая трёхшаговая структура даёт более осторожную (высокочувствительную) оценку риска, чем если спросить модель напрямую «какой риск у этого клиента» с обоими примерами в одном сообщении.
Почему это работает
Модель плохо справляется с одновременным взвешиванием противоречивых сигналов в одном контексте — она либо усредняет их до нейтрального ответа, либо цепляется за один из них случайным образом. Зато модель отлично справляется с узкой, сфокусированной задачей: «найди сходства между этими двумя записями». Метод разбивает сложную задачу на две простые сверки, а свод противоречивых выводов в решение — выносит в отдельный шаг. Это как поручить сравнение с плюсами одному человеку, с минусами — другому, а решение — третьему: каждый шаг проще, чем всё сразу.
Рычаг управления: модель на роли интегратора меняет баланс. «Слабая» модель на этом шаге даёт больше срабатываний (выше recall, находит больше реальных рисков, но и больше ложных тревог). «Сильная» модель даёт более точный, но консервативный результат — может пропустить реальный риск. Выбирай в зависимости от того, что дороже — пропустить риск или получить ложную тревогу.
Шаблон промпта
АГЕНТ 1 — АНАЛИТИК РИСКА
Целевой случай: {данные о целевом объекте/клиенте/кандидате}
Похожий случай с ПЛОХИМ исходом: {пример негативного эталона}
Сравни их. Найди сходства и различия, которые могут говорить о риске.
Не делай финальный вывод — только перечисли наблюдения.
---
АГЕНТ 2 — АНАЛИТИК ЗАЩИТЫ
Целевой случай: {тот же целевой объект}
Похожий случай с ХОРОШИМ исходом: {пример позитивного эталона}
Сравни их. Найди сходства и различия, которые говорят о низком риске.
Не делай финальный вывод — только перечисли наблюдения.
---
ИНТЕГРАТОР
Анализ риска: {ответ агента 1}
Анализ защитных факторов: {ответ агента 2}
На основе обоих анализов оцени вероятность {нежелательного исхода}
в процентах. Объясни решение в 2-3 предложениях.
{данные о целевом объекте} — то, что оцениваешь (клиент, кандидат, проект, ситуация). {пример негативного/позитивного эталона} — реальные прошлые случаи с известным итогом, максимально похожие по профилю на целевой.
🚀 Быстрый старт — вставь в чат:
Вот шаблон трёхагентной системы для оценки риска. Адаптируй под мою задачу:
{твоя задача}. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой именно риск ты оцениваешь и есть ли у тебя реальные примеры прошлых случаев с известным исходом — потому что без качественных эталонов метод не работает. Она возьмёт структуру трёх ролей и подставит твою задачу.
Ограничения
⚠️ Нужны реальные эталоны: метод работает только если у тебя есть конкретные прошлые случаи с известным исходом (не абстрактные «типичный плохой клиент», а реальная запись). Без качественных примеров сравнение бессмысленно.
⚠️ Не работает при слабом сигнале в данных: если сами исходные данные плохо предсказывают исход (в статье — так было с повторной госпитализацией через 15 дней), никакая структура промпта не поможет. Проблема не в промпте, а в том, что нужной информации просто нет в исходных данных.
⚠️ Trade-off чувствительность/точность: более простая модель на финальном шаге найдёт больше реальных рисков, но выдаст больше ложных тревог. Нужно осознанно выбирать баланс под свою задачу — скрининг (лучше перебдеть) или точечное решение (важна каждая тревога).
Как исследовали
Исследователи взяли реальные медицинские записи из баз MIMIC-III и MIMIC-IV и учили систему предсказывать смерть пациента в больнице и повторную госпитализацию. Сравнивали разные варианты: какая модель (большая или маленькая) стоит на каждой из трёх ролей, нужен ли поиск медицинских знаний (RAG), нужны ли контрастные примеры пациентов.
Главный неожиданный результат: поиск дополнительных знаний почти не влиял на качество — а вот то, какая модель стоит на роли финального интегратора, менял всё. Пара «большие модели-аналитики + маленькая модель-интегратор» находила почти в 5 раз больше реальных случаев смерти, чем система из одних больших моделей, подбираясь по точности к закрытым моделям типа Claude.
На задаче с повторной госпитализацией трюк не сработал — команда проверила это отдельно, обучив простой классификатор прямо на «сырых» медицинских кодах: даже без всякого LLM он предсказывал повторную госпитализацию с точностью чуть выше случайной. Вывод: если в исходных данных физически нет нужного сигнала, никакая архитектура промпта не вытащит его оттуда.