LLM — плохой судья себе
Языковая модель генерирует ответ и тут же считает его хорошим — у неё нет встроенного шага сомнения. Хуже того, ошибки в её рассуждении ей не видны изнутри: тот же ход мысли, что породил ошибку, мешает её заметить. Спросишь «всё верно?» — модель чаще подтвердит своё, чем оспорит (склонность соглашаться, sycophancy). Галлюцинированный факт выглядит для неё так же уверенно, как настоящий.
Поэтому самопроверка слаба: агент перечитывает свой текст в том же контексте, с теми же предпосылками — и пропускает ровно то, что уже пропустил. Нужен свежий взгляд: отдельный агент, который читает работу без привязки к рассуждениям автора и оценивает её по своим критериям.
В разработке автор не аппрувит свой PR сам — его смотрит коллега. Не потому, что автор плох, а потому, что свежий взгляд видит то, что замылилось у автора. Мультиагентная критика — ровно этот приём, перенесённый на агентов: разделить «делать» и «проверять» между разными исполнителями.
Почему отдельный критик сильнее самопроверки
В модуле 03 мы делали Reflection — там одна модель критиковала сама себя через другой промпт. Это уже помогает. Но отдельный агент-критик сильнее по нескольким причинам:
Паттерны проверки
«Агенты ревьюят друг друга» реализуется в нескольких формах — от мягкой критики до состязания.
- Reviewer (критик) — оценивает работу и даёт замечания; автор дорабатывает. Цикл «сделал → раскритиковали → переделал», но критик — отдельный агент.
- Verifier (верификатор) — не «мнение», а объективная проверка: прогнать тесты для кода, сверить факт с источником, провалидировать формат. Опирается на инструменты, а не на вкус.
- Debate (дебаты) — несколько агентов отстаивают разные позиции/решения и спорят; в споре всплывают слабые аргументы, а итог выбирает судья. Хорошо для спорных вопросов.
- Jury / голосование — несколько независимых ревьюеров оценивают, решение — по большинству. Снижает влияние ошибки одного критика.
Если у задачи есть объективная проверка — тесты, схема, факт в источнике — предпочитай верификатор простому критику. «Код проходит тесты» надёжнее, чем «код выглядит правильным». Критик-на-мнении хорош для субъективного (стиль, ясность), верификатор — для проверяемого (корректность, факты).
Пример: писатель, факт-чекер, редактор
Соберём цепочку проверки для подготовки статьи. Каждая роль ловит свой класс проблем:
writer пишет черновик │ ▼ fact-checker сверяет утверждения с источниками (verifier + поиск) │ ✗ нашёл выдуманную цифру → вернуть на правку ▼ editor проверяет ясность и структуру (reviewer) │ ✓ замечаний нет ▼ готово
Заметь разделение: fact-checker — это верификатор (объективно, с инструментом поиска), editor — ревьюер (субъективно, про стиль). Разные виды проблем ловятся разными проверяющими, и ни один из них не писал исходный текст — поэтому видят свежо.
Что делает критику полезной
Плохая критика бесполезна или даже вредна. Чтобы ревью реально поднимало качество:
- Конкретность. «Можно лучше» ничего не даёт. Нужны точечные замечания: что именно не так и как исправить.
- Действенность. Обратная связь должна быть применимой — автор по ней понимает, что переписать.
- Обоснованность. Лучшая критика опирается на проверку (тест упал, факт не подтвердился), а не на «мне кажется».
- Сигнал готовности. Критик должен уметь сказать «достаточно хорошо» — иначе цикл не остановится (придирки бесконечны).
- Независимость. Если критик «дружит» с автором (один контекст, одинаковый промпт-настрой) — он будет соглашаться. Разводи их по ролям и контекстам.
Пределы и риски
Проверка — не бесплатная панацея:
- Стоимость и задержка. Каждый ревьюер — дополнительные вызовы LLM. Применяй критику там, где цена ошибки выше цены проверки.
- Критик тоже ошибается. Ревьюер — такая же LLM, он может пропустить ошибку или придраться к верному. Verifier с инструментами надёжнее «мнения».
- Сговор и подхалимство. Если критик настроен «соглашаться», он бесполезен. Промпт должен поощрять находить проблемы, а не хвалить.
- Бесконечные придирки. Без критерия остановки и лимита итераций цикл «правка → критика» крутится вечно (мы это видели в Reflection).
Не всегда нужен отдельный агент. Self-reflection (одна модель, два промпта) дешевле и часто достаточно для лёгкой доработки. Отдельный критик оправдан, когда важны независимость и объективная проверка: высокая цена ошибки, факты, код, безопасность. Чем критичнее результат — тем больше смысла в независимом ревьюере (а то и в нескольких).
Типичные ошибки
«Проверь себя» в том же контексте ловит мало — модель пропускает свои же ошибки. Для надёжности нужен независимый критик/верификатор.
Если промпт критика не нацелен искать проблемы, он будет хвалить. Явно проси находить недостатки и давать конкретные правки.
Там, где есть объективная истина (тесты, факты), «выглядит правильно» ненадёжно. Давай критику инструменты и делай из него верификатор.
Без сигнала готовности и лимита итераций цикл правок не останавливается. Критик должен уметь сказать «годится».
Шпаргалка
ИДЕЯ: разделить «делать» и «проверять» между РАЗНЫМИ агентами
LLM — плохой судья себе: не видит свои ошибки, склонна соглашаться
свежий взгляд независимого критика ловит больше
ПОЧЕМУ отдельный критик > самопроверки:
• независимый контекст (нет общих ошибочных предпосылок)
• роль/критерии заточены под поиск проблем
• свои инструменты → может ПРОВЕРЯТЬ (тесты, факт-чек)
• можно другую/сильнее модель
ПАТТЕРНЫ:
reviewer — критика + доработка (субъективно: стиль, ясность)
verifier — объективная проверка (тесты, факты, формат) ← если есть «истина»
debate — агенты спорят, судья выбирает
jury — несколько ревьюеров, решение по большинству
ХОРОШАЯ КРИТИКА: конкретная · действенная · обоснованная ·
с сигналом «достаточно» · независимая
РИСКИ: стоимость · критик тоже ошибается · подхалимство · вечные придирки
self-reflection (дёшево) vs отдельный критик (важна независимость/факты)
Практическое задание
Спроектируй контур проверки (упражнение на дизайн ролей):
Задание: добавь ревью в пайплайн
- Возьми агента, который пишет ответ на запрос пользователя по документации. Перечисли классы ошибок, которые он может допустить (выдуманный факт, неверная ссылка, плохой тон, неполнота).
- Для каждого класса реши: его ловит verifier (есть объективная проверка) или reviewer (субъективно)? Обоснуй.
- Спроектируй цепочку из 2–3 проверяющих агентов с разными ролями. Для каждого: что проверяет, какими инструментами, что возвращает.
- Опиши, как критик возвращает работу на доработку: что должно быть в его обратной связи, чтобы автор смог исправить.
- Задай критерий остановки и лимит итераций — чтобы цикл «правка → критика» завершался.
- Со звёздочкой: добавь дебаты — два агента предлагают разные ответы на спорный вопрос, третий-судья выбирает. Когда это лучше одиночного критика, а когда — лишнее?