Агент-критик: зачем ставить второго ИИ проверять первого

Промпт «сначала ответь, потом проверь себя» работает хуже, чем два раздельных вызова: модель, которая только что уверенно выдала ответ, редко признаёт в нём дыру в том же контексте. Отсюда паттерн, который за последние два года стал почти обязательным в продакшене на LLM: один агент генерирует, второй — критикует, а первый переписывает по замечаниям. Anthropic в своих материалах по построению агентов и OpenAI в кукбуке описывают ровно эту связку. Цена вопроса прямая: два-три вызова модели вместо одного, то есть в два-три раза больше токенов и денег за каждый ответ.

Что делает агент-критик

Критик — это отдельный вызов модели с собственной задачей: не решить проблему, а найти в чужом решении ошибки. Ему на вход подаётся исходный запрос и ответ первого агента, а на выходе он даёт список претензий: где факт не подтверждён, где логика хромает, где нарушено требование задачи, где код упадёт на пустом массиве.

Ключевая идея — разделение ролей. Генератор оптимизирован на «дай ответ», и его награда — правдоподобие. Критик оптимизирован на «найди изъян», и правдоподобие для него — красная тряпка. Разные системные промпты создают разный настрой, и это меняет поведение одной и той же модели.

Генератор хочет выглядеть правым. Критик хочет поймать генератора на ошибке. Их конфликт — это и есть механизм проверки.

Почему не хватает одного самопроверяющегося агента

Приём «reflection» — когда модель в одном диалоге сначала отвечает, а потом просят «проверь и исправь» — тоже даёт эффект. Но он слабее по двум причинам. Первая: в едином контексте модель видит собственный ответ как данность и склонна его защищать, а не ломать. Вторая: если генератор ошибся из-за пробела в знаниях, тот же пробел останется и на этапе самопроверки — он просто не знает, чего не знает.

Отдельный критик с чистым контекстом и другим промптом (а иногда и другой моделью) частично снимает обе проблемы. Он не привязан к цепочке рассуждений генератора и подходит к ответу со стороны.

Как выглядит цикл

Минимальная рабочая петля из трёх шагов:

1. Генерация. Первый агент отвечает на запрос.
2. Критика. Второй агент получает запрос и ответ, возвращает структурированный список замечаний или вердикт «всё в порядке».
3. Правка. Первый агент переписывает ответ с учётом замечаний. Цикл повторяется, пока критик не одобрит результат или пока не исчерпан лимит итераций.

Лимит итераций обязателен. Без него два агента способны гонять ответ по кругу, каждый раз находя новую придирку, и счёт за токены растёт линейно с числом кругов. На практике ставят потолок в две-три итерации: большая часть выигрыша приходится на первый проход критика, дальше отдача резко падает.

Критик должен быть конкретным

Общая инструкция «проверь ответ» даёт общую критику вроде «можно добавить деталей». Толку от неё мало. Критику задают чёткие критерии проверки под конкретную задачу:

• для фактов — «каждое утверждение должно опираться на предоставленный контекст, помечай всё, чего в нём нет»;
• для кода — «проверь граничные случаи, обработку ошибок, соответствие сигнатуре функции»;
• для юридических или финансовых текстов — «отметь любую цифру, дату или ссылку на норму, которую нельзя подтвердить источником».

Чем уже область проверки, тем полезнее замечания. Универсальный критик «на всё» проигрывает специализированному.

Что это даёт и что стоит

Схема «генератор плюс критик» относится к семейству test-time compute¹ — способов улучшить качество за счёт большего объёма вычислений на этапе ответа, а не дообучения модели. Она не бесплатна, и решать, окупается ли она, нужно по задаче.

Точные цифры выигрыша сильно зависят от задачи и модели — не переносите чужие бенчмарки на свой продукт без собственного замера. Общий ориентир из практики: критик заметно помогает там, где ошибку дорого пропустить (генерация кода, извлечение фактов, подготовка документов) и почти не окупается на задачах, где «примерно правильно» уже достаточно.

Когда критик не нужен

Если ответ и так проверяется дешёвым детерминированным способом — компилятором, линтером, тестами, валидацией схемы — сначала стройте эти проверки, а не второго агента. Запустить тесты стоит копейки и даёт однозначный вердикт, тогда как второй вызов LLM стоит денег и сам может ошибаться. Разумный порядок: сначала автоматические проверки, критик — только там, где формальную проверку написать нельзя.

Практические грабли

• Критик слишком мягкий. Если в промпте нет установки «твоя задача — найти проблемы», модель по инерции хвалит. Просите не оценку, а список конкретных дефектов.
• Критик слишком въедливый. Обратная крайность: он бесконечно требует улучшений и не даёт одобрения. Спасает жёсткий критерий «одобряй, если нет ошибок уровня блокера» и лимит итераций.
• Одна модель — общие слепые зоны. Если генератор и критик — одна и та же модель, они разделяют одни и те же пробелы. Иногда критику ставят другую модель, чтобы взгляды не совпадали.
• Раздувание контекста. С каждой итерацией в диалог добавляются ответы и замечания. Следите за длиной, иначе упрётесь в лимит контекста и заплатите за лишние токены.

¹ Test-time compute — вычисления, которые тратятся в момент ответа модели, а не на этапе обучения. Несколько прогонов, разбор вариантов, критика и переписывание — всё это способы «докупить» качество прямо на инференсе.