TL;DR
Схема Generator-Critic (два агента: один предлагает, второй атакует) работает противоположно интуиции. На задачах проверки — резко улучшает качество. На задачах генерации — стабильно его ухудшает. Суть: модель симулирует двух участников дискуссии в одном диалоге. Генератор выдаёт ответ, Критик ищет дыры, Генератор правит — и так несколько раундов.
Проблема в том, что Критик тоже галлюцинирует. Когда задача открытая — "напиши", "придумай", "сгенерируй" — Критик не может проверить свои возражения по источнику. Он выдаёт ложную критику, Генератор послушно её принимает и заменяет правильный ответ на неправильный. Авторы называют это CIC — critique-induced confusion. Вместо улучшения — деградация. При этом токенов тратится в 4–7 раз больше.
Из этого вытекает правило выбора: дебаты помогают, когда Критик может проверить каждый свой довод против конкретного источника. Задача с ограниченным пространством ответов — "это ошибка или нет?" — Критик сверяется с источником, критика точная. Задача открытая — "что написать?" — Критик гадает, отравляет Генератора. Плюс авторы нашли Fix: evidence-gating — Критик принимается только тогда, когда цитирует конкретное место в источнике.
Схема метода
ШАГ 1: Генератор предлагает структурированный список результатов
→ JSON / нумерованный список с конкретными утверждениями
ШАГ 2: Критик проверяет КАЖДЫЙ пункт по источнику
→ Обязательно цитирует место в источнике
→ Выдаёт: принять / исправить + доказательство
→ Без цитаты из источника — пункт не трогается (evidence-gate)
ШАГ 3: Генератор правит ТОЛЬКО пункты с доказанной критикой
→ Возвращает исправленный список
Повторить до N раундов или до отсутствия принятых правок.
Всё — в одном промпте, один запрос к модели.
Когда запускать: задачи с ограниченным пространством ответов — проверка, поиск ошибок, факт-чекинг, сверка на противоречия.
Когда НЕ запускать: генерация текста, планы, стратегии, творческие задачи — там одиночный агент точнее.
Пример применения
Задача: Артём — основатель EdTech-стартапа, готовит инвестиционный тизер для встречи с ФРИИ. Просит ChatGPT проверить тизер на внутренние противоречия и фактические нестыковки перед отправкой.
Ты — двухагентная система для проверки документов.
Роль: аналитик, который находит конкретные проблемы в тексте.
Задача: прочитай документ и составь нумерованный список проблем.
Для каждой проблемы: укажи номер, тип проблемы, цитату из текста.
Роль: адвокат дьявола, который проверяет каждую найденную проблему.
Правило: для КАЖДОГО пункта из списка Generator — либо подтверди проблему
с цитатой из источника, либо отклони как ложную тревогу.
ВАЖНО: если не можешь процитировать источник — отклоняй пункт,
не принимай на веру.
Generator принимает правки от Critic ТОЛЬКО если Critic привёл
точную цитату из исходного документа.
Без цитаты — пункт остаётся без изменений.
Проведи 2 раунда. Итог: финальный список подтверждённых проблем
с цитатами и объяснением каждой.
Документ для проверки:
{вставь текст тизера}
Результат: Модель покажет работу в два раунда: сначала Generator выдаст список потенциальных проблем с цитатами из тизера, затем Critic пройдётся по каждому пункту и либо подтвердит с доказательством, либо отклонит как ложную тревогу. В финале — только те проблемы, которые прошли двойную проверку. Ложные срабатывания будут отсеяны. Ожидай 5–10 реальных нестыковок вместо длинного списка галлюцинированных придирок.
Почему это работает
Слабость LLM — она соглашается. Когда один агент критикует другого, второй склонен принять критику даже если та неверная. Это называют сycophancy (угодливость). В обычном сценарии дебатов Критик галлюцинирует возражение → Генератор принимает → правильный ответ заменяется на неправильный. Результат хуже, токенов потрачено в 5 раз больше.
Сильная сторона LLM — она хорошо работает с конкретными якорями. Когда Критику нужно не просто "придраться", а сослаться на конкретное место в тексте, круг галлюцинаций сужается. Нет цитаты — нет правки. Это evidence-gate: фильтр, который отсекает ложную критику на входе.
Как метод использует это — разделяет задачи по принципу верифицируемости. Если на каждый вывод можно найти доказательство в источнике, Критик работает как врач на рентгене: видит конкретное место, говорит конкретно. Если источника нет и ответ открытый — Критик гадает и отравляет Генератора. Рычаги управления:
- Число раундов (
2в шаблоне) → уменьши до1для коротких текстов, экономия токенов - Evidence-gate (обязательная цитата) → это ключевой предохранитель, не убирай для верификационных задач
- Тип задачи → переключись на одиночного агента если задача творческая или генеративная
- Формат вывода Критика (
принять / отклонить + цитата) → можно добавить уровень уверенности
Шаблон промпта
Ты — двухагентная система проверки {тип_документа}.
Роль: аналитик, ищущий {тип_проблем} в тексте.
Задача: составь нумерованный список из максимум {макс_число} проблем.
Формат каждого пункта: [номер] [тип проблемы] — [цитата из текста]
Роль: скептик, проверяющий каждый пункт Generator.
Для каждого пункта — одно из двух:
- ПОДТВЕРЖДАЮ: [цитата из источника, доказывающая проблему]
- ОТКЛОНЯЮ: [почему это ложная тревога]
Правило: нет цитаты из источника — только ОТКЛОНЯЮ.
Generator принимает исправления ТОЛЬКО при наличии цитаты от Critic.
Бездоказательная критика игнорируется.
Раундов: {число_раундов}
Итог: финальный список подтверждённых проблем с цитатами.
{тип_документа}:
{текст}
Что подставлять:
- {тип_документа} — договор, статья, техническое задание, отчёт, резюме
- {тип_проблем} — противоречия, фактические ошибки, логические дыры, юридические нестыковки
- {макс_число} — 10–15 для средних документов
- {число_раундов} — 2 для большинства задач, 1 для коротких текстов
🚀 Быстрый старт — вставь в чат:
Вот шаблон двухагентной проверки с evidence-gate.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит тип документа, какие проблемы искать и сколько раундов — потому что без этого не знает, как настроить роли Generator и Critic под конкретную верификационную задачу. Она возьмёт структуру XML и evidence-gate из шаблона и адаптирует под твой контекст.
Почему это работает: формальное условие
Авторы выводят три числа, которые определяют решение:
| Параметр | Что означает | Когда высокий |
|---|---|---|
| pg | Насколько точен Генератор сам по себе | Задача простая, модель уже хороша |
| pc | Насколько точен Критик при проверке | Есть конкретный источник для сверки |
| pr | Если Критик прав — насколько вероятно, что Генератор исправит верно | Задача бинарная (есть ошибка / нет ошибки) |
Дебаты помогают когда: (1 − pg) × pc × pr > pg × (1 − pc)
Простыми словами: выгода от поимки ошибок > риск порчи правильных ответов.
Для пользователя чата это звучит так: "Может ли Критик проверить каждый свой довод по источнику — и даст ли правильный ответ однозначная замена?" Если да на оба → запускай дебаты. Если нет хотя бы на одно → одиночный агент точнее.
Ограничения
⚠️ Задачи генерации: Дебаты стабильно вредят на открытых задачах — написание текстов, планирование, заполнение пропусков, стратегические предложения. Одиночный агент работает лучше.
⚠️ Расход токенов: Дебаты стоят в 4–7 раз больше токенов. На коротких задачах или при большом объёме документов это существенно.
⚠️ Дисперсионный усилитель, не средний улучшатель: Дебаты не поднимают средний результат — они делают лучшее лучше, а худшее хуже. Если задача критичная и цена ошибки высокая — учитывай, что провалы становятся глубже.
⚠️ Самопроверка не работает: Один агент с инструкцией "проверь себя сам" — не работает. И голосование большинством (ask the same question 5 times, pick the most common answer) тоже не заменяет отдельного Критика с доступом к источнику.
⚠️ Изоляция задач вредит: Если Критику намеренно скрыть часть контекста "чтобы был независимее" — результат ухудшается. Критик должен видеть тот же источник, что и Генератор.
Как исследовали
Команда поставила прямой вопрос: "Когда именно дебаты помогают, а когда вредят?" — и проверила это на трёх разных бенчмарках, которые покрывают весь спектр задач с данными. 142 задачи по очистке таблиц (AutoDCWorkflow), 200 вопросов по пониманию таблиц (MMTU) и 100 реальных таблиц с ошибками (MaTElDa). Итого — больше 6000 пар задача-условие по четырём моделям: Claude 4 Sonnet, Gemini 3.1 Pro, Qwen3 235B, DeepSeek R1.
Самый показательный результат — контраст между двумя задачами на одних и тех же таблицах. На задаче "найди ошибочные ячейки" (detection) дебаты подняли F1 с 0.19 до 0.46 — это огромный скачок. На задаче "сгенерируй инструкцию по очистке" (generation) дебаты снизили качество у трёх из четырёх моделей. У DeepSeek падение составило 15 процентных пунктов при семикратном расходе токенов.
Особенно интересный момент: исследователи специально проверили гипотезу о дисперсии. Для Claude дебаты не изменили среднее — они перераспределили результаты. Доля идеальных ответов выросла (22 → 28), но появились полные провалы (0 → 2). Это паттерн усилителя дисперсии, а не улучшателя качества — и он подтвердился на всех четырёх моделях. Авторы также проверили самопроверку и голосование большинством — оба метода проиграли одиночному агенту, что ставит точку в вопросе "а вдруг просто нужно переспросить несколько раз".
Оригинал из исследования
Generator–Critic debate with evidence-gated generation:
You are a data cleaning workflow generator. Given a dirty table T and
cleaning purpose p, propose a cleaning workflow W = [w1, ..., wk]
as structured JSON. Each operation must specify: column (must exist
in T), operation type, and parameters.
You are an adversarial critic. For each operation wi in W:
1. Verify the target column exists in T (cite the column header)
2. Verify the operation is appropriate given the data (cite ≥1 cell value)
3. Return: ACCEPT | REVISE [specific evidence from T] | REJECT [reason]
Evidence gate: if you cannot cite specific evidence from T, return ACCEPT.
Do not critique based on general knowledge alone.
Generator: accept Critic revisions ONLY when accompanied by
specific evidence citations from T. Ignore unsupported critiques.
Rounds: up to 3 (stop early if no revisions accepted).
Контекст: Авторы тестировали эту конфигурацию на задачах генерации инструкций по очистке данных. Это единственная конфигурация, которая превзошла одиночного агента на генеративных задачах (+5.3 процентных пункта, статистически значимо). Все остальные конфигурации дебатов без evidence-gate проиграли.
Адаптации и экстраполяции
1. Адаптация контекста: юридическая проверка договора
💡 Адаптация для проверки юридических документов: Generator ищет спорные пункты, Critic проверяет каждый против конкретных формулировок договора.
Найди в договоре пункты, которые могут создать риски для {сторона}.
Формат: [номер пункта] — [цитата] — [риск]
Для каждого риска — подтверди или отклони.
Правило: только цитата из договора = подтверждение.
Общие юридические соображения без цитаты = отклонение.
Раундов: 2.
2. Адаптация техники: персонализированный Критик
🔧 Техника: именованный Критик → острее критика
Вместо безликого "Critic" дай роль конкретного персонажа:
Ты — Герман Греф на совете директоров.
Твоя задача: найти дыры в каждом тезисе презентации.
Требование: ссылайся на конкретные цифры или факты из документа.
Персонаж с характером работает острее абстрактного критика — модель сильнее "входит в роль" и выдаёт более конкретные возражения.
3. Экстраполяция: принцип "детектор vs. генератор" за пределами дебатов
Главный инсайт исследования работает даже без многоагентной схемы:
Если просишь модель что-то проверить — давай как можно больше конкретных источников для сверки. Если просишь создать — источники помогают меньше, важнее чёткое ТЗ.
Практическое правило выбора режима:
Задача = проверка/поиск ошибок/факт-чек →
"Проверь каждый пункт против [источника].
Цитируй место в источнике для каждого вывода.
Без цитаты — не включай в итог."
Задача = написать/придумать/разработать →
Одиночный агент + чёткое ТЗ + примеры.
Добавление критика только навредит.
Ресурсы
Название работы: When Helping Hurts and How to Fix It: Multi-Agent Debate for Data Cleaning
Связанные техники: Generator-Critic debate (Du et al., 2024), sycophancy mitigation (Sharma et al., 2024), anonymization (Choi et al., 2025), self-consistency (Wang et al., 2023)
Бенчмарки: AutoDCWorkflow (Li et al., 2024), MMTU (Xing et al., 2025), MaTElDa (Ahmadi et al., 2025)