TL;DR
Когда модель проверяет свой же ответ, она находит ошибок больше, чем кто угодно — но это не помогает. Она с той же щедростью бракует и правильные ответы, поэтому итоговая точность почти не растёт. Проверка другой моделью среднего уровня работает наоборот: отклоняет реже, но почти всегда права — и точность решений заметно растёт, без единого испорченного правильного ответа.
Модель, которая перепроверяет саму себя, отклоняет каждый третий свой же верный ответ — находит повод для критики там, где всё было в порядке. При этом она выглядит "безопасной" (мало испорченных ответов), но это иллюзия: она просто в 85% случаев игнорирует свою же критику. Как только исполнитель слушается собственной критики — почти всегда становится только хуже: из трёх случаев, где модель поправила себя по своему же замечанию, все три ответа стали неверными.
Решение простое: для проверки важного ответа не проси ту же модель или чат перепроверить себя. Дай ответ на проверку другой модели, желательно среднего уровня, из другой компании-разработчика. Она реже поднимает ложную тревогу и чаще реально исправляет ошибку, когда бракует ответ. А слишком слабый ревьюер, который сам не решил бы задачу, просто бесполезен — только жжёт токены, ничего не меняя.
Схема метода
ШАГ 1: Модель А решает задачу → черновой ответ
ШАГ 2 (отдельный запрос, другая модель/чат): Модель Б смотрит на задачу и ответ модели А,
не видя правильного решения → "принять" или "отклонить" + письменная критика
ШАГ 3 (если отклонено, запрос обратно к модели А): Модель А получает свой ответ + критику
→ пересматривает один раз → финальный ответ
Все три шага — отдельные запросы, шаг 2 лучше выполнять в другом чате или другой модели, не в том же диалоге, где рождался ответ.
Пример применения
Задача: Предприниматель считает в ChatGPT сложный налоговый расчёт — например, сколько выгоднее платить по УСН «доходы» против «доходы минус расходы» при переходе бизнеса на другой оборот, с кучей условий и вычетов.
Промпт (в другом чате или другой модели, например Claude, если считали в ChatGPT):
Вот задача: [условие расчёта — оборот, ставки, вычеты, условия перехода]
Вот решение, которое дала другая модель:
[вставить полный расчёт из первого чата]
Проверь это решение самостоятельно, шаг за шагом, не доверяя автору на слово.
Если найдёшь ошибку — укажи, в каком именно шаге она и почему это ошибка.
Если ошибки нет — прямо напиши "решение верное". Не выдумывай проблему,
чтобы что-то написать.
Результат: Вторая модель либо подтвердит расчёт коротко, либо укажет конкретный шаг с ошибкой и объяснит её. Если нашла ошибку — стоит вернуться в первый чат, показать критику и попросить пересчитать один раз, а не гонять по кругу.
Почему это работает
Модель, проверяющая своё же решение, не видит его "со стороны" — она читает свой текст как продолжение собственной цепочки рассуждений. Когда её просят найти ошибку, она находит повод для критики почти всегда, даже если ошибки нет: ей проще согласиться с ролью "проверяющего" и что-то найти, чем честно признать "всё верно".
Другая модель не привязана к ходу мыслей первой. Она смотрит на задачу заново и оценивает решение как внешний наблюдатель — поэтому её критика точнее целится в реальные ошибки, а не в мнимые.
Разделение ролей между разными моделями снижает число ложных тревог и повышает долю действительно полезных правок. При этом важно не путать это с "чем умнее проверяющий, тем лучше" — в исследовании ревьюер среднего уровня сработал не хуже (а по некоторым метрикам лучше), чем самая мощная модель, проверяющая саму себя.
Рычаги управления: - Уровень модели-проверяющего — не обязательно брать самую мощную модель для проверки; средний уровень справляется эффективно и дешевле. - Что показывать проверяющему — если ответ длинный, давай проверяющему сокращённую версию (финальный расчёт/вывод), а не весь черновик рассуждений — это снижает шум и путаницу. - Число раундов пересмотра — ограничивайся одним пересмотром на основе критики, чтобы не зациклить модель в бесконечном "исправлении" уже верного ответа.
Шаблон промпта
Для проверяющей модели:
Вот задача: {задача}
Вот решение этой задачи, полученное от другой модели:
{ответ_первой_модели}
Проверь это решение самостоятельно, шаг за шагом, не доверяя выводам автора.
Если найдёшь ошибку — укажи точно, в каком шаге она и почему это ошибка.
Если ошибки нет — прямо напиши: "решение верное". Не придумывай проблему,
чтобы что-то написать.
Для пересмотра (возврат к исполнителю, если отклонено):
Вот твоё решение задачи: {ответ_первой_модели}
Другая модель дала критику: {критика}
Проверь, обоснована ли эта критика. Если да — исправь решение.
Если критика ошибочна — оставь решение как есть и объясни, почему критика неверна.
🚀 Быстрый старт — вставь в чат:
Вот принцип проверки ответов через другую модель. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какую именно задачу и решение подставить — потому что без конкретного ответа первой модели проверка не имеет смысла.
Ограничения
⚠️ Масштаб исследования: всего 100 математических задач, один исполнитель, один шаблон промпта для проверяющего. Это пилотное исследование, а не общее правило для всех типов задач и моделей.
⚠️ Слишком слабый проверяющий бесполезен: модель, которая сама не способна решить задачу, ничего не меняет в финальных ответах — только удваивает расход токенов впустую.
⚠️ Проверено только на задачах с точным численным ответом. Для творческих или субъективных задач (тексты, стратегии, дизайн), где нет "правильного ответа" для сверки, результат может отличаться.
⚠️ Разница по итоговой точности между "чужим" ревьюером и самопроверкой не полностью статистически подтверждена — авторы сами отмечают, что для однозначного вывода нужно больше данных.
Ресурсы
Faizan Tanveer, "Reviewer Capability Governs Rejection Targeting, Not Repair Skill: Evidence from LLM Execute–Review–Revise Pipelines", National University of Computer and Emerging Sciences (FAST NUCES). Код и логи: github.com/faizan-tnvr004/llm-reviewer-capability