TL;DR
Когда модель сама проверяет свой же ответ в том же диалоге, она почти никогда с собой не спорит — меньше 1% случаев самопроверка находит проблему. Но если тот же ответ отдаёт на проверку отдельному запросу без истории рассуждений («независимому аудитору»), он ловит проблему в 7–62% случаев, в зависимости от типа ошибки. Разница не в качестве модели — она одна и та же. Разница в том, видит ли проверяющий контекст, в котором решение родилось.
Боль знакома каждому, кто просил ChatGPT «а теперь перепроверь себя»: модель почти всегда отвечает «всё в порядке», даже если решение было предвзятым или ошибочным. Причина проста: модель, которая только что сформулировала ответ, склонна его защищать, а не искать в нём дыры — ей не хватает взгляда «с нуля». Отдельная проблема всплывает, когда проверок много, а времени мало: аудитор не начинает судить хуже — он просто успевает проверить меньше кейсов, и до 4 из 10 ошибок остаются незамеченными вообще.
Решение — не пытаться «улучшить» самопроверку, а физически разорвать контекст: создавать решение в одном промпте/чате, а проверять — в другом, где модель не знает, как решение было принято, и оценивает только его результат. Если проверок много и время ограничено — сортировать очередь на проверку не по порядку поступления, а по риску (сначала самые подозрительные случаи): это восстанавливает почти всё потерянное покрытие без увеличения нагрузки.
Схема метода
ШАГ 1: Создание решения → отдельный промпт/чат, обычная задача (оценка, решение, текст)
ШАГ 2: Независимая проверка → НОВЫЙ чат, роль "аудитор", без истории Шага 1 — только итоговый результат
ШАГ 3 (если проверок много, а времени/лимита мало): Приоритизация очереди → сначала проверяй кейсы с признаками риска (отказ, спорная мотивировка, упоминание защищённого признака), а не по порядку поступления
Шаг 1 и Шаг 2 — обязательно разные запросы, иначе эффект пропадает. Шаг 3 — опционален, нужен только при нехватке ресурса на проверку всего.
Пример применения
Задача: HR-менеджер просит ChatGPT оценить резюме кандидатов на вакансию и решить, звать ли на собеседование.
Промпт (Шаг 1 — создание решения, чат №1):
Оцени кандидата на позицию {название вакансии}.
Резюме: {текст резюме}
Дай вердикт: звать на собеседование или нет, и объясни почему.
Промпт (Шаг 2 — независимая проверка, НОВЫЙ чат, без истории первого):
Ты — независимый аудитор кадровых решений. Тебе дано ГОТОВОЕ решение по кандидату
и его мотивировка. Ты не знаешь, как именно рассуждал тот, кто это решение принял,
и не пытайся угадывать его логику.
Твоя задача — проверить: не основано ли решение (полностью или частично)
на факторах, не относящихся к профессиональным качествам — пол, возраст,
национальность, имя, внешность, семейное положение.
Решение и мотивировка: {вставить вердикт и объяснение из чата №1}
Ответь:
1. Есть риск предвзятости — да/нет
2. Если да — на что именно указывает мотивировка
Результат: Модель в отдельном чате даст структурированный вывод — риск предвзятости (да/нет) и конкретную зацепку в тексте мотивировки, если она есть. Если попросить ту же модель в исходном чате «а теперь проверь себя» — она с высокой вероятностью просто подтвердит своё решение без реальной проверки.
Почему это работает
Модель, которая только что сформулировала ответ в диалоге, находится «внутри» своей же логики — при повторном вопросе в том же контексте она склонна подтверждать сказанное, а не оспаривать. Это похоже на то, как человеку тяжело найти ошибку в тексте сразу после того, как он его написал.
Сильная сторона LLM — она отлично выполняет роль «с чистого листа»: если дать ей только результат без истории рассуждений, она оценивает его объективно, без обязательства защищать прежнюю логику.
Метод использует это через разрыв контекста: создание и проверка физически разделены на разные запросы. Аудитор видит только результат — и это превращает его в независимого проверяющего, а не в соавтора решения.
Рычаги управления: - Давать аудитору контекст рассуждения первого чата → убери, чтобы сохранить независимость (это критично, не опционально) - Несколько параллельных проверок разными формулировками роли аудитора → выше надёжность через своеобразный "консенсус" - Приоритизация очереди по риск-признакам → добавь, если проверяешь много кейсов и ограничен по времени/лимиту запросов
Шаблон промпта
Ты — независимый аудитор {тип решений}. Тебе дано ГОТОВОЕ решение и его мотивировка.
Ты не знаешь, как рассуждал тот, кто его принял — не пытайся восстановить его логику.
Твоя задача: проверить решение на {критерий проверки, например: предвзятость по
демографическим признакам / логические ошибки / несоответствие фактам}.
Решение и мотивировка: {вставить результат из первого запроса}
Ответь:
1. Есть проблема — да/нет
2. Если да — что конкретно в тексте на неё указывает
Подставь {тип решений} (кадровое, кредитное, редакторское) и {критерий проверки} под свою задачу. Главное правило — этот промпт должен идти новым чатом, без истории первого запроса.
🚀 Быстрый старт — вставь в чат:
Вот принцип независимого аудита. Помоги мне применить его к моей задаче: {твоя задача}.
Задавай вопросы, чтобы понять контекст.
[вставить шаблон выше]
LLM спросит, какое решение нужно проверять и на какие именно риски — потому что без этого нельзя сформулировать конкретный критерий проверки.
Ограничения
⚠️ Разделение на роли само по себе не помогает: если просто добавить в пайплайн «агента-проверяющего», но не разорвать контекст между созданием и проверкой (или дать проверяющему полную историю рассуждений первого агента), эффект пропадает — частота ошибок не снижается.
⚠️ Ограниченный ресурс на проверку — скрытая дыра: если проверок много, а времени/лимита мало, аудитор не начинает судить хуже, а просто успевает проверить меньше. Без приоритизации по риску большая часть проблем пройдёт вообще незамеченной — и это будет выглядеть так, будто «система работает», хотя она просто не успевает смотреть.
⚠️ Проверено на одной модели, небольшая выборка: выводы получены на GPT-4o-mini с умеренным числом наблюдений — числовые доли (7–62%) не переносить буквально на другие модели, но сам механизм («независимость важнее качества суждения») стоит проверять и в других контекстах.
Как исследовали
Исследователи построили симуляцию распределения больничных коек во время катастрофы: каждый пациент генерировался парой «близнецов» — идентичных по тяжести состояния, но отличающихся одним демографическим признаком (национальность, религия, телосложение). Сравнивали одну модель, которая сама оценивала, распределяла и проверяла своё решение, против пайплайна из девяти агентов (assessor → allocator → auditor) на тех же самых кейсах. Прогнали 192 эпизода — 2304 пары решений — на GPT-4o-mini под разной операционной нагрузкой (поток пациентов, дефицит коек, ограничение числа проверок у аудитора).
Главный сюрприз: частота предвзятых решений оказалась одинаковой в обоих условиях (~6–7%) — сам факт разделения задачи на роли ничего не меняет. Но разница была огромной в том, ловит ли система эту предвзятость: самопроверка почти никогда не находила проблему (<1%), а независимый аудитор — в 7–62% случаев в зависимости от типа нарушения. Когда аудитора перегрузили (одна проверка за такт вместо неограниченного числа), качество его суждений на рассмотренных случаях почти не изменилось (81,6% против 85,7%, разница не значима) — но покрытие рухнуло с 100% до 65,6%. То есть аудитор не стал хуже думать, он просто перестал успевать смотреть на всё. Изменение порядка очереди — сначала кейсы с признаками риска, а не по порядку поступления — вернуло почти всё потерянное покрытие (65,6% → 91,7%).
Ресурсы
Paul-Peter Arslan, Institute for Future Technologies (2026). Опирается на KillBench (White Circle) — оригинальный бенчмарк предвзятости одноагентного триажа. Также ссылается на PBSuite (NVIDIA), GovSim (ETH Zürich) и MAST — таксономию сбоев мультиагентных систем. Код и данные: github.com/Polpii/policy-town