TL;DR
OSVerify — двухступенчатая проверка текста или решения. Сначала один запрос ищет подозрительные места: сначала в целом документе, потом в его частях, потом в отдельных шагах. Затем каждое найденное подозрение проверяется отдельным запросом с вердиктом: «не существует», «мелочь» или «существенная ошибка». Решение отклоняется, если нашлась хотя бы одна существенная ошибка.
Когда просишь модель «проверь, всё ли верно», она выдаёт общий вердикт, и он шумный. На одну и ту же работу она то пропускает ошибку, то бракует нормальное. Причина в том, что искать изъян по всему тексту сразу тяжело. А вот проверить одно конкретное утверждение «в шаге 4 неверно посчитан НДС» та же модель умеет заметно лучше. В статье качество разделения на уровне отдельной ошибки (AUROC, мера «насколько вердикт отличает плохое от хорошего») выросло с 0,68 до 0,90. Это та же модель, на тех же данных.
Метод превращает трудную задачу «оцени всё» в две лёгкие: «накидай подозрения» (можно щедро, с лишними) и «проверь одно подозрение» (строго, с контекстом). Лишние и выдуманные ошибки отсеивает второй этап. Реальные находки остаются.
Схема метода
ШАГ 1 (предложитель): разбей решение на части →
ищи ошибки в целом, в половинах, в мелких кусках →
список «подозрений» (где, что не так, почему это ломает решение)
ШАГ 2 (валидатор, ОТДЕЛЬНЫЙ запрос на каждое подозрение):
получает задачу + решение + ОДНО подозрение →
NOT-REAL (выдумка) / MINOR (мелочь) / SUBSTANTIAL (ломает решение)
ШАГ 3 (вердикт): есть хотя бы один SUBSTANTIAL → отклонить / на ручной разбор
нет → пропустить дальше
(опционально: валидатор запускается несколько раз, смотрим долю голосов «SUBSTANTIAL»)
Шаги 1 и 2 — разные запросы (разные чаты или разные вызовы), чтобы валидатор не подхватывал уверенный тон предложителя.
Пример применения
Задача: Основатель сервиса быстрой доставки в Казани через ChatGPT собрал юнит-экономику для питча инвесторам: средний чек 1 150 ₽, стоимость доставки, маржа, окупаемость точки за 11 месяцев. Таблицу на 40 строк никто не проверял. Перед встречей нужно убедиться, что в расчётах нет дыр, которые инвестор найдёт за пять минут.
Промпт (шаг 1, предложитель):
Ты — жёсткий аудитор финмоделей. Твоя задача — найти места,
где расчёт может быть неверным. Лучше предложить лишнее подозрение,
чем пропустить настоящую ошибку.
Ниже юнит-экономика сервиса быстрой доставки в Казани.
{вставить расчёт}
1. Разбей расчёт на две смысленные половины (граница — по логике, не по длине).
2. Каждую половину раздели ещё раз на две части.
3. Проверь ошибки на трёх уровнях: весь расчёт целиком (логика, допущения),
половины, отдельные куски (арифметика, единицы, источники цифр).
Промпт (шаг 2, новый чат, по одному подозрению):
Ты — независимый рецензент. Тебе дали расчёт и одно утверждение
о том, что в нём есть ошибка. Проверь именно это утверждение.
<Расчёт>{вставить расчёт целиком}
<Подозрение>{одно подозрение из шага 1}
1. Проверь, верно ли утверждение вообще. Если нет — ответ NOT-REAL.
2. Если ошибка настоящая — оцени, меняет ли она итоговый вывод
(окупаемость, маржу, решение инвестировать).
Меняет существенно — SUBSTANTIAL. Не меняет — MINOR.
Результат: Шаг 1 даст список из нескольких подозрений, часть из них будет натянутой. Шаг 2 для каждого подозрения вернёт один из трёх вердиктов с коротким обоснованием. Выдуманные претензии отсеются как NOT-REAL, мелочи уйдут в MINOR. Останутся те, что реально меняют окупаемость. Их основатель правит до питча.
Почему это работает
Слабость: когда модель оценивает целиком, ей нужно одновременно держать весь текст и искать, что в нём не так. Вердикт получается размытым. Одна и та же ошибка то замечена, то нет. Если запустить проверку 64 раза, результат улучшается, но быстро упирается в потолок. Просто «больше проверок» не помогает.
Сильная сторона: модель хорошо проверяет узкое конкретное утверждение, когда ей показали, куда смотреть. В статье опираются на наблюдение: модели часто не находят ошибку сами, но исправляют её, если место указано. Поиск и проверка — разные по сложности задачи.
Как метод это использует: этап поиска намеренно щедрый, с высоким охватом, пусть и с ложными срабатываниями. Этап проверки строгий и узкий и отсеивает лишнее. Так общая ошибка снижается: нужное находится, а лишнее выбрасывается.
Рычаги управления: - Глубина разбиения → в статье большая часть выигрыша приходит при двух уровнях (целое → половины → четверти). Для коротких текстов хватит одного. - Число запусков валидатора → чем строже требование «не потерять хорошее решение», тем больше повторов на одно подозрение нужно. Для обычной работы хватит 3–5. - Определение «существенной ошибки» → пропиши в промпте, что для твоей задачи мелочь, а что критично. В доказательстве мелкие неточности допустимы, в продакшене они могут стоить аварии. - Повторный поиск на корне → если запустить предложителя на всём документе два-три раза, охват растёт.
Шаблон промпта
Предложитель:
Ты — придирчивый рецензент. Найди места, где {тип_материала}
может быть ошибочным. Лучше лишнее подозрение, чем пропущенная ошибка.
{задача_или_цель}
Материал для проверки: {текст}
1. Раздели материал на две логические части (граница по смыслу).
2. Каждую часть раздели ещё на две.
3. Ищи ошибки на всех уровнях: целое (логика, допущения),
части (согласованность), мелкие куски (факты, цифры, формулировки).
Валидатор (новый чат, по одному подозрению):
Ты — независимый рецензент. Проверь ТОЛЬКО указанное утверждение
об ошибке.
<Материал>{полный текст}
<Задача>{задача_или_цель}
<Подозрение>{одно подозрение}
1. Верно ли утверждение? Нет → NOT-REAL.
2. Верно → меняет ли это {критерий_успеха}?
Да, существенно → SUBSTANTIAL. Нет → MINOR.
Правило итога: есть хотя бы одно SUBSTANTIAL → материал не проходит.
Что подставлять: {тип_материала} — расчёт, договор, отчёт, код; {критерий_успеха} — что делает ошибку существенной (деньги, юридический риск, работоспособность).
🚀 Быстрый старт — вставь в чат:
Вот шаблон OSVerify (двухэтапная проверка: поиск подозрений → отдельная проверка каждого).
Адаптируй под мою задачу: {что проверяю}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что проверяем и что считается существенной ошибкой в твоём случае. Без этого валидатор не отличит мелочь от дыры. Она возьмёт структуру двух запросов из шаблона и подстроит под твою задачу.
Ограничения
⚠️ Проверено только на математических доказательствах: все бенчмарки — олимпиадные и исследовательские математические решения. Перенос на финмодели, договоры, код и тексты в статье не проверяли. Это разумная, но догадка.
⚠️ Полный метод требует многих вызовов: авторы делали 16 повторов проверки на каждое подозрение и подбирали порог на калибровочной выборке. Вручную в чате этого не повторить, нужен скрипт или автоматизация. В чате доступна упрощённая версия.
⚠️ Человек остаётся в контуре: метод не заменяет эксперта. Он сокращает число плохих кандидатов, которые доходят до человека, но не гарантирует правильность тех, что прошли.
⚠️ Щедрый поиск рождает выдуманные ошибки: без строгого второго этапа метод превращается в генератор ложных тревог. Валидатор с размытым определением «существенного» пропустит их.
⚠️ Гарантия «не потерять хорошее» требует калибровки: чтобы почти не отбраковывать верные решения, порог подбирают по набору заведомо верных образцов. Без них такой настройки нет.
⚠️ Дообучение валидатора (RL) читателю недоступно: оно поднимает выигрыш с 46% до 57%, но без обучения модели это не повторить. Результаты ниже описаны без дообучения.
Как исследовали
Исследователи из Стэнфорда проверяли метод на трёх математических наборах: Putnam100 (олимпиадные задачи), Hard2Verify (решения с разметкой шагов экспертами) и FirstProof-Eval (исследовательский уровень с ручной разметкой). Проверяющими нарочно взяли относительно слабые модели, gpt-oss-120b и gpt-5-mini. Так имитируется ситуация, когда задача сложнее, чем модель может решить сама. Эталонные решения и формальные проверяющие программы от проверяющего скрыли.
Сравнивали с тремя подходами: обычный «модель-судья», голосование (16 независимых вердиктов), а также многоагентные дебаты и ещё один метод проверки. Мерили две вещи: сколько плохих решений отсеяно и сколько хороших потеряно. На практике это сводится к вопросу: сколько неверных кандидатов придётся показывать человеку, если терять не более 5% верных.
Результат: при 5% потерь верных решений доля отсеянных плохих у gpt-oss-120b выросла с 38% до 70% на Putnam100 и с 36% до 58% на FirstProof-Eval. Число плохих кандидатов, доходящих до человека, сократилось в среднем на 46%. Дообучение валидатора подняло это до 57%.
Любопытная деталь: простое увеличение числа голосований быстро упирается в потолок. Выигрыш дало другое: проверять конкретную ошибку, а не решение целиком. Углублять разбиение дальше двух уровней почти не нужно.
Метод проверили и на реальных работах. В статье из Annals of Mathematics он нашёл 45 подтверждённых проблем, в свежем препринте — 88. Авторы работ признали ошибки и принятые исправления. Он также помог закрыть три открытые гипотезы из программы Ленглендса, эксперты подтвердили доказательства.
Адаптации и экстраполяции
🔧 Техника: убрать «лучше лишнее» → меньше ложных тревог, но выше риск пропуска
Если перебор подозрений утомляет, замени в роли предложителя «Лучше предложить лишнее подозрение, чем пропустить» на «Предлагай только подозрения, в которых уверен хотя бы наполовину». Подозрений станет меньше, но часть реальных ошибок не попадёт в список. Для критичных документов оставляй оригинал.
Экстраполяция: правило для агента-ревьюера в файле инструкций
Это моя идея, в статье её нет. Если у тебя Claude Code или Cursor делает код или документ, добавь в CLAUDE.md:
## Ревью перед сдачей
Перед тем как сообщить, что работа готова:
1. Составь список конкретных подозрений на ошибки (где, что не так, чем это ломает результат), отдельно для всего изменения, для каждого файла и для каждой функции.
2. Каждое подозрение проверь отдельно, как независимый рецензент: NOT-REAL / MINOR / SUBSTANTIAL.
3. Если есть хотя бы одно SUBSTANTIAL — исправь и повтори. Если нет — сдавай.
Ресурсы
- One-Sided Verification Under Limited Expert Review — Fan Nie, Haotian Ye, Shurui Liu, Zihao Wang, Stefano Ermon, James Zou, Stanford University
- Сайт проекта: https://osverify.github.io/
- Код: https://github.com/OSVerify
- Бенчмарки: Putnam100, Hard2Verify, First Proof (FirstProof-Eval)