TL;DR
EDS (Experience-Driven Suppression) — метод, который учит модель не перепроверять промежуточные результаты там, где это почти никогда не находит ошибок. Работает через базу "опыта": собирает случаи самопроверки из прошлых рассуждений, смотрит какие проверки были полезны (нашли ошибку), а какие бесполезны (просто подтвердили правильность). Во время reasoning детектирует начало проверки, ищет похожие случаи в базе опыта и если раньше такие проверки редко что-то исправляли — вставляет текст типа "это не требует проверки, двигайся дальше".
Исследователи обнаружили системную проблему в reasoning-моделях: 85-95% всех самопроверок бесполезны — они только подтверждают уже правильные шаги, но не находят ошибок. При этом такие проверки (recheck) составляют 40-58% всех рефлексивных шагов и съедают треть токенов рассуждений. Модели особенно много перепроверяют на простых задачах, где это меньше всего нужно. Проблема в том, что LLM не умеет оценивать когда проверка действительно нужна — она проверяет всё подряд: и сложные выводы, и очевидные вычисления типа "2+2=4". Это как студент, который перерешивает таблицу умножения перед каждым следующим шагом.
Метод решает через "опыт": если на конкретных математических операциях (взятие производной, проверка ограничений) модель раньше 100 раз проверяла и 95 раз просто подтверждала правильность — значит в 101-й раз проверка скорее всего тоже не нужна. Система детектирует момент начала проверки, смотрит в базу похожих случаев, считает процент бесполезных проверок и если он высокий — вставляет сигнал подавления. Модель видит этот текст и переходит к следующему шагу вместо перепроверки.
Схема метода
ОФЛАЙН (подготовка базы опыта):
ШАГ 1: Собрать reasoning-роллауты модели на задачах
ШАГ 2: GPT-5 размечает где модель делает recheck (самопроверку)
ШАГ 3: GPT-5 аннотирует каждый recheck: необходимый (нашёл ошибку) или лишний (просто подтвердил)
ШАГ 4: Сохранить → база опыта {контекст проверки, метка нужна/не нужна}
ОНЛАЙН (inference с подавлением):
ШАГ 1: Модель генерирует reasoning → классификатор детектирует начало recheck
ШАГ 2: Взять контекст перед проверкой → найти топ-k похожих случаев в базе опыта (BM25)
ШАГ 3: Посчитать % лишних проверок среди найденных → если >порога
ШАГ 4: Вставить в генерацию: "Это не требует проверки, перехожу к следующему шагу" → модель пропускает recheck
Ключевая находка исследования
Исследователи разделили рефлексию (reflection) в LLM на два типа:
Rethink (переосмысление) — модель меняет стратегию решения, пробует другой подход, переформулирует проблему. Это полезно и нужно.
Recheck (самопроверка) — модель перепроверяет уже выведенный промежуточный результат: пересчитывает, проверяет ограничения, тестирует на корректность. Может быть двух видов: - Corrective (корректирующая) — находит ошибку и исправляет → полезна - Confirmatory (подтверждающая) — просто подтверждает правильность → бесполезна
Главная находка: 85-95% всех recheck — confirmatory. Модель тратит токены на проверки, которые почти никогда не меняют результат.
Примеры измерений (Qwen3-8B): - MATH500: 58% рефлексий это recheck, из них 95% confirmatory - AMC23: 52% рефлексий это recheck, из них 92% confirmatory - AIME24: 40% рефлексий это recheck, из них 85% confirmatory
Парадокс: на простых задачах (MATH500) модель делает больше рефлексии, чем на сложных (AIME). Но эта рефлексия почти вся — бесполезная самопроверка.
Почему это работает
Слабость LLM: Модель не умеет оценивать нужна ли проверка. Она работает по паттерну "сделал шаг → проверь" безусловно, даже когда проверять очевидно правильные вещи. Модель не помнит что "взятие производной x² уже 100 раз работало корректно" — каждый раз для неё как первый. Результат: треть токенов тратится на перепроверку таблицы умножения и простых формул.
Сильная сторона LLM: Модель хорошо следует текстовым директивам внутри reasoning. Если в процессе генерации появляется фраза "это не требует проверки" — модель склонна согласиться и продолжить дальше, не тратя токены на recheck.
Как метод использует это: Система накапливает статистику успешности проверок для конкретных математических операций (производные, проверка чётности, минимизация). Когда модель начинает проверять что-то, что раньше проверялось 100 раз и 95 раз было correct — система понимает: "это confirmatory паттерн". Вставляет текстовый сигнал подавления → модель переходит к следующему шагу. Механика: не меняем модель, меняем входной поток reasoning через инъекцию текста.
Рычаги управления (для полной системы с кодом): - Порог _τ_ (процент лишних проверок) → уменьши для агрессивного подавления, увеличь для осторожного - Топ-k (сколько похожих случаев искать) → больше k = стабильнее оценка, меньше = быстрее retrieval - Размер базы опыта → больше данных = точнее оценка необходимости - Текст сигнала подавления → можно варьировать формулировку ("не проверяй" vs "доверяй результату")
Применимый принцип для чата
⚠️ Полная система EDS требует код (классификатор, retriever, база данных). НО из исследования можно извлечь ручной принцип для работы в чате:
Принцип: Когда видишь что модель начинает перепроверять очевидное — останови её директивой и направь дальше.
Пример применения
Задача: Ты просишь модель рассчитать юнит-экономику для онлайн-школы. Модель считает LTV, CAC, находит payback period в 4 месяца. Потом начинает: "Давай проверю расчёт LTV ещё раз: 5000₽ × 12 месяцев..."
Ты видишь что это confirmatory recheck простой арифметики.
Действие:
Стоп. Базовые вычисления LTV и CAC корректны,
не трать время на их перепроверку.
Переходи к выводам: при каких условиях payback
можно сократить до 2 месяцев?
Результат: Вместо того чтобы пересчитывать 5000×12 три раза, модель сразу перейдёт к анализу — какие рычаги улучшат экономику (увеличить retention, снизить стоимость привлечения, поднять средний чек).
Другой пример — код:
Модель пишет функцию обработки платежей. После каждого блока кода начинает: "Давай проверю что эта часть работает правильно. Если amount > 0, то..." и пересказывает очевидную логику.
Действие:
Логика проверки amount и обработки ошибок понятна
и корректна. Не нужно перепроверять каждый if-блок.
Переходи к edge cases: что если платёж отменяется
во время processing?
Модель пропускает confirmatory rechecks базовых условий и фокусируется на сложных сценариях.
Ограничения
⚠️ Требует инфраструктуру: Полная система EDS нужен код — классификатор для детекции recheck, retriever (BM25), база опыта, API с streaming для инъекции текста. В обычном чате невозможно автоматически детектировать и подавлять.
⚠️ Субъективная оценка вручную: Когда применяешь принцип руками — сложно определить confirmatory vs corrective. То что кажется "очевидной проверкой" может найти ошибку. Риск остановить полезную рефлексию.
⚠️ Не для новых/сложных операций: Метод подавляет проверки на основе прошлого опыта. Если операция новая или нестандартная — базы опыта нет, система не знает нужна ли проверка. На таких случаях лучше дать модели проверить.
⚠️ Зависит от качества базы: Если база опыта собрана на простых задачах — система будет агрессивно подавлять проверки на сложных, что может навредить. База должна покрывать разнообразие задач.
⚠️ Не подавляет rethink: Метод работает только для recheck (локальная проверка результатов). Не трогает rethink (смена стратегии). Это правильно, но означает что метод решает только часть проблемы избыточной рефлексии.
Результаты из исследования
Тестировали на Qwen3-8B, QwQ-32B, DeepSeek-R1-Distill-Qwen-7B на математических бенчмарках (AIME24, AIME25, AMC23, MATH500, Olympiad Bench).
Эффект: - Сокращение токенов: до 20.3% меньше reasoning tokens при сохранении accuracy - На некоторых датасетах улучшение точности на 1-2% (меньше шума от лишних шагов) - Паттерн: чем проще задачи → тем больше сокращение (MATH500: -18%, AIME: -12%)
Механика работы: - Детектор recheck: >97% accuracy на валидации - Топ-5 retrieval из базы опыта (BM25) - Порог τ=0.8 (если 80%+ похожих проверок были лишние → подавить)
Ресурсы
Self-Verification Dilemma: Experience-Driven Suppression of Overused Checking in LLM Reasoning
Relatable work: Kang et al. (2025) про то что проверки после финального ответа редко его меняют
Авторы: Quanyu Long, Kai Jie Jiang, Jianda Chen, Xu Guo, Wenya Wang (Nanyang Technological University), Leilei Gan (Zhejiang University)