TL;DR
Петля Генератор-Критик — техника, в которой одна роль создаёт ответ, вторая его оценивает по шкале 1–10 и даёт конкретную обратную связь, а первая дорабатывает только если оценка ниже порога. Цикл повторяется максимум 3 раза — этого достаточно, чтобы поймать большинство грубых ошибок без бесконечного пережёвывания.
Главная находка: критик без примеров — бесполезен. Когда у судьи нет образцов "плохого" и "хорошего" ответа, он ставит одинаковую оценку всему подряд — грубые ошибки и точные ответы получают одинаковый балл. Модель просто не знает, что считать "7" а что "9". Без якорей — нет дифференциации, нет смысла в цикле.
Метод решает это так: генератор работает в Zero-shot (без примеров), а критик получает Few-shot примеры с образцами ошибок и правок. Именно такая комбинация — Zero-shot генератор + подготовленный критик — выигрывает у простого Few-shot без критика. Добавление примеров в оба конца пайплайна не даёт выигрыша — потолок создаёт качество критика, не генератора.
Схема метода
Все шаги — в одном чате, последовательно:
ШАГ 1 (Генератор):
Сгенерируй {задачу} по описанию {входные данные}
→ Структурированный ответ
ШАГ 2 (Критик):
Оцени предыдущий ответ по шкале 1–10.
Укажи конкретные ошибки и что нужно исправить.
Учти примеры: {пример_плохого} → {пример_хорошего}
→ Оценка + список правок
ШАГ 3 (Условие):
Если оценка < 8.5 → передай правки генератору, повтори шаги 1–2
Если оценка ≥ 8.5 или прошло 3 итерации → ответ финальный
→ Финальный результат
Пример применения
Задача: Ты продакт в команде Авито. Нужно структурировать требования к новой фиче — раздел "Профессиональные продавцы". Есть только грубое описание от бизнеса.
Промпт:
Ты работаешь в двух ролях: Генератор и Критик.
ОПИСАНИЕ ФИЧИ:
Авито хочет выделить профессиональных продавцов — тех, кто продаёт регулярно и зарабатывает на этом.
Нужен специальный статус, инструменты и аналитика. Пока непонятно что именно.
=== ШАГ 1 — ГЕНЕРАТОР ===
Роль: Эксперт по продуктовым требованиям.
Задача: Выдели из описания:
1. Акторов (кто взаимодействует с фичей — роли пользователей)
2. Высокоуровневые цели (зачем им это нужно — "почему")
3. Низкоуровневые цели (конкретные действия в интерфейсе — "как")
Формат: JSON, три блока.
=== ШАГ 2 — КРИТИК ===
Роль: Старший продакт-менеджер, эксперт в JTBD.
Оцени результат Генератора по шкале 1–10.
Критерии оценки (с примерами):
ПЛОХИЕ цели (оценка 1–5):
- "Сделать продажи удобными" → слишком расплывчато, нет действия
- "Разработать интерфейс" → это задача разработки, не цель пользователя
ХОРОШИЕ цели (оценка 8–10):
- "Продавец хочет видеть сколько объявлений активно прямо сейчас" → конкретно, одно действие
- "Покупатель хочет проверить рейтинг продавца до покупки" → понятный сценарий
Что нужно проверить:
— Все ли роли пользователей указаны?
— Высокоуровневые цели отвечают на "зачем", а не "как"?
— Каждая низкоуровневая цель — одно конкретное действие?
Выдай: оценку (цифру) + список конкретных правок.
=== ШАГ 3 — УСЛОВИЕ ===
Если оценка Критика < 8.5 → передай правки Генератору и повтори шаги 1–2.
Если оценка ≥ 8.5 или прошло 3 итерации → выдай финальный структурированный список требований.
Результат: Модель пройдёт 1–3 раунда: сначала выдаст черновые требования, потом Критик укажет что расплывчато или пропущено, Генератор уточнит. В финале — структурированный список акторов, целей и конкретных функций, готовый для передачи в команду разработки.
Почему это работает
Когда просишь LLM сгенерировать структурированный ответ сразу — она оптимизирует под "выглядит правдоподобно". Нет внешней проверки, нет давления на качество. Первый черновик уже считается финальным.
Роль Критика создаёт давление на доработку. Но без примеров критик — тоже LLM с той же проблемой: он не знает где граница "хорошо" и "плохо". Добавив образцы ошибок, ты даёшь ему конкретные якоря — теперь он может точно указать что именно не так.
Рычаги управления: - Порог (8.5) → снизь до 7 для быстрых задач, подними до 9 для критически важных - Число итераций (3) → уменьши до 1 для экономии, оставь 3 для сложных задач - Примеры в Критике → чем точнее примеры под твою задачу, тем острее оценка - Разбивка на подзадачи → чем больше подшагов (акторы → цели → подцели), тем точнее финал
Шаблон промпта
Ты работаешь в двух ролях: Генератор и Критик.
ВХОДНЫЕ ДАННЫЕ:
{описание_задачи}
=== ШАГ 1 — ГЕНЕРАТОР ===
Роль: {роль_генератора}
Задача: {что_нужно_создать}
Формат вывода: {формат}
=== ШАГ 2 — КРИТИК ===
Роль: {роль_критика}
Оцени результат Генератора по шкале 1–10.
Используй эти примеры для калибровки оценки:
ПЛОХОЙ пример (оценка 1–5):
{пример_плохого_результата}
ХОРОШИЙ пример (оценка 8–10):
{пример_хорошего_результата}
Критерии оценки:
- {критерий_1}
- {критерий_2}
- {критерий_3}
Выдай: оценку (цифру) + конкретные правки.
=== ШАГ 3 — УСЛОВИЕ ===
Если оценка < {порог} → передай правки Генератору, повтори шаги 1–2.
Если оценка ≥ {порог} или прошло {макс_итераций} итерации → финальный результат.
Плейсхолдеры:
- {описание_задачи} — твои входные данные: текст, описание, задание
- {роль_генератора} — кто создаёт (эксперт по требованиям, копирайтер, аналитик)
- {роль_критика} — кто оценивает (старший редактор, ментор, строгий клиент)
- {пример_плохого_результата} / {пример_хорошего_результата} — твои образцы под конкретную задачу
- {порог} — рекомендую 8 или 8.5
- {макс_итераций} — рекомендую 3
🚀 Быстрый старт — вставь в чат:
Вот шаблон техники Generator-Critic Loop. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про роли генератора и критика, попросит примеры хорошего и плохого результата, уточнит критерии оценки — потому что именно они определяют качество критики. Она возьмёт паттерн из шаблона и адаптирует под твою задачу.
Ограничения
⚠️ Цикл без хороших примеров бессмысленен: Если не дать Критику образцы плохого и хорошего результата — он будет давать одинаковые оценки и никакой итерации не произойдёт. Без якорей нет дифференциации.
⚠️ Комбинация Few-shot + Критик не улучшает результат: Добавление примеров и в генератор, и в критика одновременно не даёт выигрыша по сравнению с Zero-shot генератором + подготовленным критиком. Не стоит усложнять обе стороны.
⚠️ Слабо работает на субъективных задачах: Если нет чёткого критерия "правильно/неправильно" — Критик начинает придираться к несущественным деталям. Метод лучше работает там, где есть структурные требования (требования, план, список функций), а не там где нужна оценка стиля или эмоций.
⚠️ 61% точности на сложном финальном шаге: На задаче извлечения детальных требований из документации метод достигает точности около 60%. Это хорошо как инструмент-ускоритель для черновика, но не замена ручной работе.
Как исследовали
Команда Политехнического университета Турина взяла документацию четырёх реальных open-source проектов — от системы управления больницей до сервиса скорой помощи Лондона — и вручную разметила "эталонные" требования. Потом запустили пайплайн из GPT-4 (генератор) и Llama 3.3 70B (критик) в разных конфигурациях: Zero-shot, One-shot, Few-shot — и с петлёй обратной связи и без.
Интересная деталь дизайна: похожесть примеров для Few-shot и тестовых проектов измерили через косинусное сходство — оказалось, что все примеры были примерно одинаково непохожи на тест (около 0.5 из 1.0). Это значит, что эффект Few-shot не объяснялся удачным совпадением примеров.
Главный сюрприз: исследователи ожидали, что Few-shot + критик даст лучший результат, чем Zero-shot + критик. Не дал. Добавление примеров в генератор при наличии хорошего критика не помогает — потолок создаёт качество критика, а не генератора. Это переворачивает интуицию многих пользователей, которые тратят силы на улучшение основного промпта, игнорируя механизм проверки.
Адаптации и экстраполяции
🔧 Техника: убрать порог → режим ревизионного редактора
Если убрать числовой порог и заменить условие выхода на "пока Критик не скажет 'одобрено'", получаешь открытый редакторский цикл. Полезно для текстов, где нет чёткой метрики — эссе, письмо клиенту, пост в Телеграм:
=== ШАГ 2 — РЕДАКТОР ===
Роль: Строгий главред Кашин / голос Максима Ильяхова.
Оцени текст. Если есть канцелярит, вода или неточности — укажи конкретно что заменить.
Если правок нет — напиши "ОДОБРЕНО".
=== ШАГ 3 — УСЛОВИЕ ===
Если получил правки → исправь и покажи Редактору снова.
Если получил "ОДОБРЕНО" → выдай финальный текст.
🔧 Техника: дать критику острую личность → жёстче критика
Безликий "Критик" — мягкий критик. Если дать имя с характером:
Роль: Павел Дуров проверяет продуктовую документацию.
Он ненавидит расплывчатость, ценит конкретику и сразу видит когда требование нельзя реализовать.
Модель симулирует более острую оценку — потому что у этого архетипа есть узнаваемый стиль мышления.
Ресурсы
Название: Evaluating LLM-Based Goal Extraction in Requirements Engineering: Prompting Strategies and Their Limitations
Авторы: Anna Arnaudo, Riccardo Coppola, Maurizio Morisio, Flavio Giobergia, Andrea Bioddo, Angelo Bongiorno, Luca Dadone — Политехнический университет Турина (Politecnico di Torino)
Конференция: EASE 2026 (30th International Conference on Evaluation and Assessment in Software Engineering), Glasgow
Репликационный пакет (данные и промпты): https://zenodo.org/records/18919525