Reflection: агент, который критикует сам себя
Агенты слишком доверяют своему первому ответу — и ошибаются ровно там, где человек бы перечитал и поправил. Reflection заставляет модель сначала написать черновик, затем критиковать его, затем переписать — и качество резко растёт.
СреднийAI-агенты20 минClaude API, Any LLM, Prompt chaining
1
Черновик → критик → правка: три стула одного агента
Представьте писателя, который сначала быстро пишет первую версию, затем пересаживается на стул редактора и жёстко размечает проблемы, затем возвращается за стол и переписывает. Один человек, три роли, три разных режима мышления. Reflection делает то же самое с LLM: одна и та же модель играет генератора, критика и редактора по очереди.
Почему это работает: LLM гораздо лучше находит проблемы в готовом тексте, чем избегает их заранее. Генерация и оценка — разные когнитивные задачи, и когда вы разделяете их в промпте, модель получает шанс увидеть свою же работу свежим взглядом. Первый черновик обычно средний — и это фича, а не баг.
Запрос
Черновик
Критика
Правка
Готово
Первый черновик всегда плохой — и это нормально. Задача reflection — не написать идеально с первого раза, а систематически улучшить.
2
Когда рефлексия помогает, а когда сжигает токены
Reflection не бесплатна — каждый цикл критики и правки — это дополнительные вызовы модели. Окупается там, где «правильный» ответ нельзя формализовать заранее: код, длинные эссе, аналитика, сложные рассуждения. Для задач с коротким или жёстко заданным ответом — классификация, да/нет, извлечение полей — рефлексия только тратит деньги и время.
Самый надёжный критерий: можно ли проверить результат программно? Если да — пишите eval или unit-тест, они дешевле и надёжнее. Если «правильно» определяется только человеческим вкусом — reflection ваш инструмент. Между этими полюсами есть серая зона (креативный текст), где критик субъективен, и итерации могут не сходиться к лучшему.
Где рефлексия окупается?
Генерация кода с неочевидной логикой
Длинный анализ или исследовательский отчёт
Классификация "да/нет" или в один класс
Извлечение полей по фиксированной схеме
Короткая сводка в одно-два предложения
Креативный текст — помогает, но критик субъективен
Если задачу можно проверить программно — рефлексия избыточна, используйте eval. Reflection — для задач, где «правильно» нельзя формализовать.
3
Критиком должна быть другая модель — или хотя бы другой промпт
Контринтуитивный момент: та же модель с тем же контекстом редко находит свои ошибки. Она привязана к своему ответу и склонна подтверждать собственные решения — confirmation bias в чистом виде. Наивный цикл «а теперь проверь себя» обычно возвращает «всё ок».
Есть два рабочих пути. Первый — другая модель как критик (генерирует Haiku, критикует Sonnet или наоборот). Свежая перспектива, другой training data, меньше совпадений в слепых зонах. Второй — та же модель, но в новом сеансе без истории: промпт не «проверь свой ответ», а «ты строгий ревьюер, вот чужой текст, найди проблемы». Роль + свежий контекст обманывают confirmation bias настолько, насколько это возможно с одной моделью.
❌ Тот же промпт, тот же контекст
- Модель уже привязана к ответу
- Confirmation bias — "всё выглядит нормально"
- Находит косметику, пропускает суть
✅ Свежий контекст, роль критика
- Нет привязки к предыдущему ответу
- Явная установка искать проблемы
- Находит реальные баги и логические дыры
4
Бесконечный цикл — главный враг рефлексии
Без жёсткого ограничения цикл превращается в спираль: критик находит три проблемы, редактор правит, новый критик находит ещё три в свежем тексте, редактор снова правит, и так бесконечно. Хуже всего, что каждая итерация выглядит осмысленной — критик всегда что-то скажет, если его попросить. А качество перестаёт расти после 2-3 проходов: кривая выходит на плато, но счётчик токенов летит вверх.
Эмпирическое правило: 2-3 итерации для кода и саммаризации, до 4 для глубокого анализа. Дальше вы платите за стилистические перестановки. Три механизма остановки работают вместе. Hard cap — жёсткий лимит итераций, без вариантов. Quality threshold — критик возвращает структурированный ответ со счётчиком проблем, и когда high-severity issues = 0, цикл останавливается. Time/token budget — общий лимит на задачу, чтобы один сложный вопрос не съел дневную квоту.
Отдельная ловушка: если на третьем проходе критик всё ещё находит «проблемы» — это обычно означает, что промпт критика слишком строгий, а не что текст плох. Логируйте каждую итерацию: что нашёл критик, что изменил редактор, стало ли лучше.
Логируйте каждую итерацию. Если на 3-й проходе критик всё ещё находит «проблемы» — значит промпт критика слишком строгий, а не код плохой.
5
Промпт критика — не «проверь», а «найди ровно 3 проблемы»
Главный рычаг качества рефлексии — это промпт критика, а не редактора. Размытое «проверь этот код» даёт размытый ответ: «выглядит нормально», «вроде работает», «можно улучшить читаемость». Ничего из этого не превращается в правку. Структурированное требование — «найди ровно N проблем с severity и указанием строки» — вынуждает модель конкретизировать, и вы получаете actionable-список.
Два приёма работают особенно хорошо. Первое — заранее зафиксировать формат вывода (JSON со списком issues, каждая с severity и fix-предложением). Второе — явно разрешить критику сказать «проблем нет»: без этого модель будет выдумывать мнимые проблемы, чтобы «выполнить задачу».
❌ Плохо:
"Проверь этот код. Есть ли ошибки?"
→ Claude: "выглядит нормально"
✅ Хорошо:
"Найди до 3 конкретных проблем в этом коде.
Для каждой: [строка] [severity: low/med/high] [как исправить].
Если проблем нет — верни {"done": true, "issues": []}."
→ Claude: структурированный список с severity и fix-предложениемВозвращайте критику как JSON со severity. Reflection-цикл останавливайте при нулевом количестве high-severity issues, а не когда critic просто замолчал.
Результат
Вы понимаете, когда reflection окупается, а когда это дорогой способ получить тот же ответ. Знаете, что критик должен быть в свежем контексте, цикл — с жёстким лимитом, а промпт критика — структурированным и с явным escape-путём.