TL;DR
Метод состоит из двух вызовов модели: первый выдаёт решение, второй — проверяет его. Но перед вторым вызовом стоит фильтр (гейт): если модель уже уверена в ответе — второй вызов пропускается, ответ остаётся как есть.
Главная находка исследования: просьба «перепроверь и исправь» может сломать уже правильный ответ. На задачах с кодом, где модель и так решала 95 из 100 задач верно, принудительная перепроверка обвалила точность до 66% — модель начинала переписывать рабочий код «на всякий случай», хотя её не просили находить конкретную ошибку, а просили обязательно выдать финальную версию.
Решение простое: критик должен иметь право сказать «всё верно, ничего не меняю» вместо того, чтобы каждый раз переписывать заново. И запускать проверку стоит только там, где модель реально ошибается часто (при низкой точности первого ответа), а не там, где она почти всегда права.
Схема метода
ВЫЗОВ 1: Модель решает задачу обычным способом → черновой ответ
[ГЕЙТ]: Оцени — модель неуверена/задача сложная?
ЕСЛИ ДА → идти к ВЫЗОВУ 2
ЕСЛИ НЕТ → оставить ответ ВЫЗОВА 1, стоп
ВЫЗОВ 2: Модель проверяет черновик.
Промпт критика: «Если всё верно — ответь CORRECT.
Переписывай только если нашёл конкретную ошибку» → финальный ответ
Оба вызова — отдельные запросы (не один промпт).
Пример применения
Задача: Разработчик просит Claude написать функцию на Python для парсинга CSV-файла, а потом просит её проверить.
Промпт (вызов 1):
Напиши функцию на Python, которая читает CSV-файл и возвращает список словарей.
Обработай случай пустых строк и неправильного разделителя.
Промпт (вызов 2, после получения кода):
Вот код выше. Проверь его на ошибки логики, обработки исключений и краевых случаев.
Если код полностью корректен — ответь только словом CORRECT, ничего не переписывай.
Если нашёл конкретную ошибку — укажи её и перепиши ТОЛЬКО то место, где она есть.
Не переписывай весь код заново без причины.
Результат: Если код действительно рабочий, модель ответит "CORRECT" и не тронет исходник. Если есть реальная ошибка — покажет её точечно, без "капитального ремонта" рабочих частей. Это снижает риск, что модель "улучшит" код до состояния с новым багом.
Почему это работает
LLM склонна выполнять инструкцию буквально, даже если это вредит. Если промпт говорит «всегда перепиши финальную версию» — модель перепишет, даже когда переписывать нечего. Это создаёт риск случайно испортить то, что уже было правильным — просто из желания «отработать» задачу.
Сильная сторона LLM — она неплохо оценивает уверенность в своём ответе, если её явно спросить («это точно верно?» вместо «перепиши это»). Гейт использует эту способность: не заставляет модель переписывать всё подряд, а даёт ей возможность честно сказать «менять нечего».
Рычаги управления: - Убери слово «обязательно перепиши» из промпта критика → модель реже портит правильные ответы - Добавь условие «отвечай CORRECT, если ошибок нет» → экономия токенов и меньше случайных правок - Если задача простая и модель почти всегда права с первого раза → второй вызов вообще можно пропустить - Если задача сложная (модель часто ошибается) → второй вызов почти всегда помогает, гейт менее критичен
Шаблон промпта
ВЫЗОВ 1:
{твоя задача}
ВЫЗОВ 2 (после получения ответа):
Вот решение выше. Проверь его на {критерии проверки: ошибки/логика/полнота}.
Если всё верно — ответь только словом CORRECT, ничего не меняй.
Если нашёл конкретную проблему — укажи её и исправь только это место.
Не переписывай весь ответ заново без причины.
Подставь в {твоя задача} — исходный запрос, в {критерии проверки} — что именно проверять (грамматику, логику, расчёты, код).
🚀 Быстрый старт — вставь в чат:
Вот шаблон gated self-refinement (проверка ответа с защитой от лишних правок).
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какая у тебя задача и по каким критериям проверять ответ — потому что от этого зависит формулировка промпта-критика. Она возьмёт паттерн из шаблона и подгонит под твой случай.
Ограничения
⚠️ Модель исследования: Эксперимент проводили на маленькой локальной модели (7 миллиардов параметров). ChatGPT и Claude — модели гораздо крупнее, они надёжнее держат контекст и реже "паникуют" от сложных инструкций. Эффект гейта может быть слабее на мощных моделях, но сам принцип (не заставлять модель переписывать без причины) логически применим к любой LLM.
⚠️ Не работает как универсальное правило: Если задача действительно сложная и модель часто ошибается — второй вызов почти всегда полезен, гейт менее важен. Если задача простая — второй вызов рискует испортить хороший ответ.
⚠️ Часть про многоагентные пайплайны и JSON-формат мало применима: Основная находка статьи про то, что 5-агентные конвейеры с JSON-обменом ломаются на маленьких моделях — это специфично для локальных 7B моделей. ChatGPT и Claude надёжно генерируют JSON и держат контекст между шагами, так что этот вывод не переносится напрямую на них.
Как исследовали
Исследователи взяли локальную модель Qwen2.5-7B и прогнали её через три подхода: прямой промпт, пятиролевой конвейер (Refiner → Planner → Worker → Checker → Judge, назвали систему Parishad) и двухвызовный self-refinement. Тестировали на 500 математических задачах (GSM8K) и 164 задачах на код (HumanEval).
Самое интересное — конвейер с JSON-обменом между ролями рухнул до 45% точности на математике (при базовых 75% на прямом промпте), просто потому что маленькая модель не может стабильно генерировать валидный JSON, а сломанный JSON превращает передачу контекста между ролями в кашу. Замена JSON на обычный текст вернула точность почти к исходному уровню — 82%.
Но ключевое открытие для self-refinement: на коде, где модель и так решала 95% задач правильно, второй "проверочный" вызов с инструкцией "всегда перепиши финальную версию" обвалил точность до 66%, потому что модель переписывала рабочие решения без причины. Убрав принудительную переписку и заменив её на "скажи CORRECT если всё верно" — точность вернулась к исходным 95%. Это противоречит интуиции "чем больше проверок — тем лучше" и показывает, что формулировка промпта критика важнее самого факта проверки.