TL;DR
В многошаговых задачах на исправление текста или решения модель может проигнорировать критику, даже если критика верна. Проблема не в качестве критики — а в том, куда она попадает. Если критика существует как отдельный сигнал (отдельное сообщение, отдельная роль), а не встроена в контекст того, кто исправляет — она теряется.
Проверяли на математических олимпийских задачах два подхода. В первом (PER) есть специальный reviewer, чья критика отправляется в отдельное поле. В нём точность reviewer выше (86% vs 64%), но полезная критика реально меняла ответ только в 33% случаев. Во втором (broadcast) вся критика видна всем участникам сразу, встроена в общий candidat — и полезная критика меняла ответ в 93% случаев. Итог: менее точный reviewer + правильная архитектура > более точный reviewer + плохой маршрут.
Практическое следствие: где находится критика в контексте важнее, чем насколько она точна. Если просишь модель сначала "найди проблемы", а потом "исправь" — это два разных сообщения, и второй запрос часто не действует на первый так, как ты ожидаешь. Встраивай критику прямо в запрос на исправление.
Схема метода
Исследование сравнивает два паттерна работы с критикой:
❌ PER-паттерн (не работает):
ШАГ 1: Solver создаёт вариант → отдельный блок
ШАГ 2: Reviewer критикует → попадает в отдельное поле "advice"
ШАГ 3: Solver может проигнорировать → отправляет исходный вариант
✅ Broadcast-паттерн (работает):
ШАГ 1: Все видят → один общий текущий вариант
ШАГ 2: Любой участник критикует → критика встраивается в общий контекст
ШАГ 3: Новый вариант принимается → только если все одобрили
Ключевое отличие: критика в broadcast — это часть общего рабочего контекста,
не отдельный канал. Её нельзя обойти, не приняв во внимание.
Пример применения
Задача: Ты написал описание своего продукта для лендинга и хочешь улучшить его через несколько итераций с помощью Claude.
❌ PER-паттерн (как делать не надо):
Сообщение 1: "Проверь это описание, найди слабые места."
[Модель выдаёт критику]
Сообщение 2: "Теперь перепиши с учётом замечаний."
Вторая модель "видит" критику где-то в истории, но она уже не в её рабочем фокусе — и часто игнорирует часть замечаний.
✅ Broadcast-паттерн (правильно):
Текущий вариант для доработки:
[Вставь текст описания]
Команда из трёх экспертов работает над улучшением:
- Эксперт-маркетолог: оценивает убедительность и CTA
- Эксперт по UX-тексту: оценивает ясность и структуру
- Потенциальный клиент: оценивает понятность и желание купить
Каждый эксперт даёт конкретную критику текущего варианта.
Затем все трое вместе создают улучшенный вариант, в котором
учтены все замечания.
Новый вариант принимается только если все трое согласны,
что он лучше исходного по всем трём критериям.
Покажи:
1. Критику каждого эксперта (2-3 пункта)
2. Финальный улучшенный вариант
3. Что изменилось и почему
Результат: Модель покажет конкретную критику от каждой роли, а затем финальный текст, в котором все замечания уже встроены в контекст создания нового варианта — не отдельный совет, а часть процесса. Финальный текст будет ощутимо отличаться от исходного.
Почему это работает
Слабость LLM: Модель отвечает на то, что прямо перед ней в рабочем контексте. При раздельном подходе "сначала покритикуй, потом исправь" критика уходит в историю чата — она существует, но уже не в фокусе генерации нового варианта. Это не "лень модели" — это архитектурная особенность: внимание слабеет с расстоянием в тексте.
Сильная сторона LLM: Если вся нужная информация — текущий вариант, критика, инструкция ревизии — находится в одном запросе, модель обрабатывает её с равным вниманием. Ничего не теряется между сообщениями.
Как метод использует это: Broadcast-паттерн убирает "маршрутизацию" критики. Критика не "передаётся" от одной роли другой — она часть одного контекста. Модель, создающая следующий вариант, физически не может его проигнорировать — он лежит прямо рядом с заданием.
Рычаги управления: - Количество ролей → 2-4 эксперта достаточно. Больше 5 — начинают повторяться - Критерий принятия → "все трое согласны" можно заменить на "большинство" или "хотя бы один нашёл критическую проблему" - Конкретные роли → чем конкретнее роль ("B2B-директор по продажам с 10 летами опыта"), тем острее критика - Инструкция на вывод → добавь "покажи шаги рассуждения" если хочешь проверить логику критики
Шаблон промпта
Текущий вариант:
{вставь текст, решение или черновик}
Три эксперта анализируют его с разных позиций:
- {Роль 1}: оценивает {критерий 1}
- {Роль 2}: оценивает {критерий 2}
- {Роль 3}: оценивает {критерий 3}
Каждый эксперт находит {число_проблем} конкретных проблемы в текущем варианте.
Затем все трое совместно создают улучшенный вариант,
в котором устранены все найденные проблемы.
Финальный вариант принимается только если все эксперты
согласны, что он лучше исходного.
Формат ответа:
1. Критика каждого эксперта (по пунктам)
2. Финальный улучшенный вариант
3. Список изменений
Плейсхолдеры:
- {вставь текст} — что улучшаем: описание продукта, план, черновик письма, стратегия
- {Роль 1-3} — конкретные роли под задачу: клиент, конкурент, инвестор, редактор, юрист
- {критерий} — что именно оценивает каждая роль
- {число_проблем} — 2-3 оптимально; больше — начнётся поиск незначительного
🚀 Быстрый старт — вставь в чат:
Вот шаблон broadcast-ревью. Адаптируй под мою задачу: {твоя задача}.
Задай вопросы, чтобы заполнить все поля — роли, критерии, формат вывода.
[вставить шаблон выше]
LLM спросит какой текст улучшаешь и что важно оценить — чтобы подобрать правильные роли и критерии под твою конкретную задачу, а не абстрактные "эксперт 1, эксперт 2".
Ограничения
⚠️ Не для простых задач: На лёгких запросах разница между паттернами исчезает. Broadcast-подход стоит применять там, где правки действительно нетривиальны и важны — сложные тексты, многокритериальный анализ, ревью бизнес-логики.
⚠️ Принудительное "подтверди критику" вредит: Исследование показало — если просить модель сначала явно "подтвердить" замечания (ACK-required), точность финального результата падает. Не нужно добавлять шаг "подтверди, что понял замечания" — это создаёт лишний слой между критикой и ревизией.
⚠️ Тестировали на математических задачах: Все мерки — олимпийская математика. Для субъективных задач (творческий текст, стратегические решения) паттерн работает по той же логике, но исследователи не проверяли это напрямую.
⚠️ Больше токенов: Broadcast-подход генерирует больше текста за один запрос. В длинных сессиях это может упираться в лимиты контекстного окна.
Как исследовали
Команда из Аргоннской национальной лаборатории взяла 4181 олимпийскую задачу по математике с десятью уровнями сложности. Идея была простой: взять одну и ту же модель, поменять только то, как устроена коммуникация между ролями — и посмотреть, что изменится.
Четыре протокола тестировали на одинаковой модели (gpt-oss-120b): одиночный агент без итераций, одиночный с итерациями, PER-пайплайн с reviewer, broadcast с коллективным одобрением. Главная находка удивила: PER-reviewer точнее определяет ошибки (86% точность), но полезная критика меняла следующий ответ только в 33% случаев. Broadcast-reviewer менее точен, но его критика меняла ответ в 93% случаев — и broadcast в итоге решал больше задач.
Чтобы понять причину, добавили два варианта PER: один с обязательным подтверждением критики (ACK-required) — результат стал хуже (33% → 17% uptake). Второй встраивал критику прямо в контекст solver-а (EMB) — стало лучше, но до уровня broadcast не дотянул. Оба варианта указывают в одну сторону: близость критики к месту генерации важнее её качества. Отдельно проверили на модели Gemma 3 — общий вывод сохранился, хотя ранжирование протоколов немного сдвинулось.
Оригинал из исследования
PER: critique is routed, but can remain non-binding
Planner → Executor → Reviewer
Reviewer signal enters a separable "advice" field
Solver can acknowledge the signal yet preserve the candidate
Submission decision is role-local after routed review
Broadcast: critique is shared, and approval is collective
Peer discussion ↔ shared candidate
Critique enters the shared deliberation state
Every peer sees the same candidate before submission
Submission requires collective re-approval
Контекст: Это исходная схема из статьи — ключевое различие двух протоколов. В PER reviewer-сигнал входит в отдельное поле и не обязывает solver его применять. В broadcast критика — это часть общего состояния кандидата, и обойти её невозможно.
Адаптации и экстраполяции
💡 Для итеративной правки в диалоге — без ролей:
Тот же принцип применим даже без симуляции ролей. Когда просишь модель доработать что-то, не делай это двумя сообщениями. Объедини критику и запрос в одном:
Вот текущий вариант:
{текст}
Конкретные проблемы, которые нужно устранить:
— {проблема 1}
— {проблема 2}
— {проблема 3}
Перепиши, учитывая каждый пункт. Не убирай ничего рабочего.
Критика встроена — модель видит её прямо перед заданием на ревизию.
🔧 Техника: конкретные персонажи вместо безликих ролей → острее критика
Замени "Эксперт по маркетингу" на живого персонажа:
- Михаил Токовинин (основатель amoCRM): как он оценил бы этот питч?
- Скептичный клиент из Казани, который уже пробовал аналоги и разочаровался
- Автор канала "Капитал" — что он напишет в разборе?
Модель генерирует намного более острую и специфическую критику, когда роль имеет конкретный голос и историю.
🔧 Техника: убрать требование финального вывода → чистый процесс дискуссии
Если убрать "покажи финальный вариант" и оставить только критику от ролей — получаешь диагностику без давления на консенсус. Полезно когда не знаешь что именно слабое, и хочешь услышать разные углы до того, как решать.
Ресурсы
Название работы: Precise but Uncoupled: Reviewer Precision Does Not Guarantee Critique Uptake in Multi-Agent Math Reasoning (2025, Preprint)
Авторы: Chih-Hsuan Yang, Jingyan Jiang, Vikram Vasudevan, Cheng-Hau Yang, Huihuo Zheng, Le Chen, Eliu A. Huerta, Venkatram Vishwanath, Ian T. Foster, Rajeev Thakur
Организации: Argonne National Laboratory, University of Chicago, Oregon State University
Контакт: bellayang@anl.gov
Бенчмарк: Omni-MATH 2 — olypiad-level математика, 4181 задача, 10 уровней сложности