TL;DR
LLM-модели плохо исправляют сами себя: стандартная просьба «проверь и улучши» либо ломает правильные части ответа, либо вообще игнорирует реальные ошибки. DISC решает это через принципиально другую структуру — вместо одного запроса «найди и исправь» метод запускает цикл из трёх ролей: верификатор задаёт точечные вопросы к конкретным утверждениям, судья выносит строгий вердикт по доказательствам, корректор переписывает только то, что прямо помечено как ошибка.
Главная боль при самопроверке в LLM — модель исправляет то, что уже правильно. Попросите Claude «перепроверь свой ответ» — и она начнёт переформулировать верные утверждения, добавлять оговорки, менять структуру. В итоге ответ меняется, но качество падает. Это происходит потому что у модели нет «тормоза» — она не спрашивает себя «а нужно ли вообще что-то менять?».
DISC добавляет этот тормоз — «ворота суждения» (judgment gate): прежде чем исправлять, судья должен найти конкретное доказательство ошибки. Нет доказательства — нет исправления, цикл останавливается. Нашёл — цикл повторяется до 3 раз, каждый раз «снимая» один слой ошибок, как в обработке шумного сигнала.
Схема метода
ИСХОДНЫЙ ОТВЕТ (уже готов)
↓
РАУНД 1 (из максимум 3):
ВЕРИФИКАТОР → задаёт 3-10 точечных вопросов к конкретным
утверждениям в ответе → отвечает на них независимо
↓
СУДЬЯ → сравнивает доказательства (ответы верификатора)
с исходным ответом → выносит вердикт:
НЕТ_ОШИБКИ? → немедленная остановка, ответ не трогается
ОШИБКА? → указывает точное место и доказательство
↓
КОРРЕКТОР → переписывает ТОЛЬКО помеченное место,
остальное не трогает
↓
РАУНД 2 (если был вердикт ОШИБКА) → повтор цикла
↓
РАУНД 3 (если снова ОШИБКА) → последний повтор
↓
ФИНАЛЬНЫЙ ОТВЕТ
Все шаги выполняются в одном промпте — модель последовательно играет роли верификатора, судьи и корректора.
Пример применения
Задача: Вы попросили Claude составить коммерческое предложение для клиента — небольшой кофейни в Москве — на поставку кофемашин. Важно: условия кредита, сроки гарантии, сравнение с конкурентами — всё должно быть точным, не выдуманным.
Промпт:
Провери следующий текст коммерческого предложения. Действуй строго по ролям.
ИСХОДНАЯ ЗАДАЧА: коммерческое предложение для кофейни на поставку кофемашин
ТЕКСТ ДЛЯ ПРОВЕРКИ:
"""
Предлагаем профессиональные кофемашины La Marzocco GB5 по цене 380 000 ₽.
Гарантия — 2 года. Доставка по Москве — 3 рабочих дня.
Рассрочка на 12 месяцев без переплат. Бесплатное обучение баристы (2 часа).
"""
РОЛЬ 1 — ВЕРИФИКАТОР:
Сформулируй 4-5 точечных вопроса к конкретным утверждениям выше.
Затем ответь на каждый вопрос самостоятельно — как будто ты не видел текст выше.
Формат:
Q1: [вопрос]
A1: [ответ]
(и так далее)
РОЛЬ 2 — СУДЬЯ:
Сравни каждый A с соответствующим утверждением в тексте.
Есть ли конкретное противоречие между доказательствами и текстом?
Вынеси один из двух вердиктов:
НЕТ_ОШИБКИ — верни текст без изменений, кратко объясни почему
ОШИБКА — укажи точное место ошибки и какое доказательство её подтверждает
РОЛЬ 3 — КОРРЕКТОР (только при вердикте ОШИБКА):
Исправь ТОЛЬКО помеченное место. Остальной текст оставь дословно.
Выведи финальный текст.
Результат:
Модель последовательно выведет три блока: вопросы верификатора с независимыми ответами, вердикт судьи с указанием конкретного противоречия (или остановку с объяснением), и — если нашлась ошибка — исправленный вариант только в помеченном месте. Если первый раунд нашёл ошибку, можно попросить «повтори цикл ещё раз для нового текста» — до трёх раундов.
Почему это работает
Слабость LLM: модель генерирует текст по паттерну продолжения, а не по логике «что здесь точно правда». Когда её просят «проверь себя», она снова входит в режим «продолжи текст» — и начинает переписывать, потому что переписывание само по себе выглядит как ожидаемое продолжение запроса.
Сильная сторона LLM: модель хорошо работает с конкретными вопросами. «Какова стандартная гарантия на La Marzocco?» — это другой режим, чем «скажи что-то про гарантию в этом тексте». Независимые точечные вопросы заставляют модель ответить «по существу», а не «в контексте».
Как метод использует это: DISC разрывает порочный круг тем, что верификатор отвечает на вопросы независимо от исходного текста. Потом судья сравнивает два независимых источника. Если они совпадают — никаких изменений. Если расходятся — есть конкретное доказательство, корректор работает точечно. Это не «оцени и улучши» — это «сравни два источника и реши, есть ли противоречие».
Рычаги управления: - Число вопросов (3–10) — меньше вопросов для коротких текстов, больше для сложных многошаговых расчётов - Строгость судьи — добавьте «требуй прямое цитирование доказательства» для максимальной точности; уберите для более мягкой проверки - Число раундов (1–3) — один раунд для простых задач, три для цепочек рассуждений - Роль верификатора — попросите его «задавать вопросы как скептически настроенный конкурент» для более острой проверки
Шаблон промпта
Провери следующий {тип_текста}. Действуй строго по ролям — не пропускай ни одну.
ИСХОДНАЯ ЗАДАЧА: {задача}
ТЕКСТ ДЛЯ ПРОВЕРКИ:
"""
{текст}
"""
РОЛЬ 1 — ВЕРИФИКАТОР:
Сформулируй {число_вопросов} точечных вопроса к конкретным утверждениям выше.
Отвечай на каждый вопрос самостоятельно — как будто ты не видел текст выше.
Формат вывода:
Q1: [вопрос]
A1: [ответ]
...
РОЛЬ 2 — СУДЬЯ:
Сравни каждый ответ (A1-A{число_вопросов}) с соответствующим утверждением в тексте.
Требуется прямое противоречие, а не субъективная оценка качества.
Вынеси один из двух вердиктов:
НЕТ_ОШИБКИ — верни текст без изменений, одним предложением объясни вывод
ОШИБКА — процитируй точное место ошибки + укажи какое доказательство её подтверждает
РОЛЬ 3 — КОРРЕКТОР (только при вердикте ОШИБКА):
Исправь ТОЛЬКО процитированное место.
Остальной текст скопируй дословно без изменений.
Выведи финальный текст.
Плейсхолдеры:
- {тип_текста} — «коммерческое предложение», «юридическую формулировку», «финансовый расчёт», «технический план»
- {задача} — исходная постановка, которую решал текст
- {текст} — сам текст для проверки
- {число_вопросов} — 3 для коротких текстов, 5-7 для сложных
🚀 Быстрый старт — вставь в чат:
Вот шаблон DISC для проверки текстов. Адаптируй под мою задачу: [опиши свою задачу].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про тип текста, задачу и сколько вопросов задавать — потому что без контекста судья не знает, что считать ошибкой. Она возьмёт структуру ролей из шаблона и подставит твои данные.
Ограничения
⚠️ Слабый судья блокирует всё: Если модель недостаточно сильная, судья будет выносить вердикт НЕТ_ОШИБКИ даже при очевидных противоречиях. Верификатор найдёт ошибку, судья её проигнорирует — коррекция не запустится. Это «пол компетентности»: ниже него метод не работает.
⚠️ Косметика против логики: Метод отлично ловит фактические ошибки — неверные числа, противоречивые утверждения, пропущенные условия. Логические ошибки в цепочках рассуждений исправляет хуже — особенно если ошибка в предпосылке, а не в следствии.
⚠️ Субъективные задачи: Не подходит для оценки стиля, тона или «соответствия бренду» — судья не может вынести объективный вердикт там, где нет однозначного доказательства.
⚠️ Больше токенов: Один раунд DISC примерно в 5 раз дороже обычного запроса «проверь и улучши». Для коротких текстов с очевидными ошибками это избыточно.
Как исследовали
Команда из Thomson Reuters Labs построила систему так, чтобы проверить именно архитектурный вклад каждого элемента — а не просто «лучше или хуже». Они взяли три принципиально разных набора задач: BIG-Bench Mistake (готовые цепочки рассуждений с намеренными ошибками — начальная точность ~15%), HotpotQA (7405 вопросов с поиском по двум статьям Википедии) и GPQA Diamond (198 вопросов уровня аспирантского экзамена по физике, химии, биологии).
Самый интересный эксперимент — пять конфигураций на GPQA, где роли верификатора, судьи, генератора и корректора распределялись между слабой моделью (gpt-4.1-nano) и сильной (gpt-5.2). Результат удивил: сильный верификатор без сильного судьи давал +0 улучшений (судья говорил НЕТ_ОШИБКИ в 100% случаев). Сильный судья без сильного верификатора — +3. А оба вместе — +34. Эффект не суммируется, он умножается. Это значит: в паре «проверяющий + оценивающий» слабейший определяет результат всей цепочки.
Ещё один чистый эксперимент — отключение «ворот»: те же промпты, та же модель, но судья всегда выносит вердикт ОШИБКА и всегда запускает исправление. Результат: количество деградаций (ломаем правильное) выросло в 2-3 раза. Это доказывает — именно тормоз, а не сами промпты, останавливает перекоррекцию.
Адаптации и экстраполяции
1. Симуляция кросс-модельной проверки в одном чате
Исследование показало: главная проблема самопроверки — подтверждение собственных предубеждений (self-confirmation bias). Модель проверяет ответ теми же «глазами», которыми его писала. В реальном исследовании это решают заменой модели. В чате можно симулировать смену точки зрения:
🔧 Техника: смена роли верификатора → острее проверка
Замени в шаблоне начало РОЛИ 1 на:
РОЛЬ 1 — ВЕРИФИКАТОР: Ты — скептичный редактор, который видит этот текст впервые и не доверяет ни одной цифре. Ты никогда не писал этот текст. Сформулируй вопросы как человек, который хочет поймать автора на неточности.Это не программирование — это смена угла зрения. Модель начинает генерировать вопросы в другом паттерне: не как продолжение исходного текста, а как внешний аудит.
2. DISC для проверки промптов перед отправкой
Принцип верификации через независимые вопросы работает не только для финальных ответов, но и для самих промптов.
Проверь следующий промпт перед тем, как я отправлю его в работу.
ПРОМПТ ДЛЯ ПРОВЕРКИ:
"""
{мой_промпт}
"""
РОЛЬ 1 — ВЕРИФИКАТОР:
Задай 4 вопроса к конкретным инструкциям в промпте:
- Какой результат ожидается?
- Что считается успехом?
- Есть ли противоречивые инструкции?
- Что модель сделает, если встретит неоднозначность?
Ответь на каждый вопрос самостоятельно.
РОЛЬ 2 — СУДЬЯ:
Есть ли конкретное противоречие между ожидаемым результатом
и формулировками промпта?
НЕТ_ОШИБКИ — промпт чёткий, отправляй
ОШИБКА — укажи конкретную неоднозначность
РОЛЬ 3 — РЕДАКТОР (только при ОШИБКА):
Исправь только помеченное место.
Ресурсы
Название работы: Denoising Iterative Self-Correction: Structured Verification Loops for Reliable LLM Reasoning
Авторы: Shen Yin, David Ken, Joel Stremmel — Thomson Reuters Labs
Связанные работы из статьи: - Chain-of-Verification (CoVe) — Dhuliawala et al., 2023 - Self-Refine — Madaan et al., 2023 - GPQA Diamond benchmark — Rein et al., 2023 - Критика самокоррекции — Huang et al., 2024; Kamoi et al., 2024