Как заставить ИИ-судью меньше ошибаться в сложных агентных задачах

Когда LLM учится не только отвечать, но и проверять

У больших языковых моделей есть странная слабость. Они все лучше генерируют решения, но все еще не очень хорошо понимают, какое из решений действительно правильное. А это уже не мелочь. Если у вас ИИ-агент пишет код, ходит по терминалу, управляет манипулятором или работает с медицинскими данными, то главный вопрос не «может ли он выдать вариант?», а «можем ли мы надежно выбрать хороший вариант среди нескольких?».

Именно на этом построена статья LLM-as-a-Verifier от исследователей из Стэнфорда, Беркли и NVIDIA Research. Авторы предлагают смотреть на проверку не как на вспомогательную функцию, а как на отдельную ось масштабирования. То есть модели можно улучшать не только за счет предобучения, дообучения и большего бюджета на инференс, но и за счет более умной верификации.

Звучит просто. Но за этим стоит важная идея: если модель умеет неплохо проверять, то она может лучше выбирать среди собственных попыток. А значит, качество системы растет даже без дополнительного обучения.

В чем проблема обычных ИИ-судей

Сегодня популярный подход такой: мы просим LLM выступить «судьей» и поставить решению оценку. Например, от 1 до 5 или от 1 до 10. Потом берем лучший вариант.

Проблема в том, что это слишком грубо. Если два решения оба «почти правильные», модель часто выдает им одну и ту же оценку. Возникают ничьи. А когда задача длинная и сложная — например, агент 20 шагов правил код, устанавливал пакеты, запускал тесты и исправлял ошибки, — грубая шкала начинает ломаться.

Авторы предлагают перейти от идеи «судьи» к идее верификатора. Судья выносит итоговый вердикт. Верификатор пытается аккуратно оценить, насколько решение похоже на правильное и где в нем есть признаки успеха или провала.

Ключевой ход здесь очень изящный. Вместо того чтобы брать один самый вероятный токен оценки, авторы смотрят на все распределение вероятностей по токенам оценки и считают ожидаемое значение. Иначе говоря, модель не просто говорит «это 4 из 5», а показывает более плавный сигнал: что-то вроде «это 4.37».

Это сразу дает более тонкое разделение кандидатов.

Одна схема для разных модальностей: верификатор дает тонкую обратную связь для кода, видео, медицины и обучения с подкреплением.

Что именно предлагают авторы

Их схема называется LLM-as-a-Verifier. Она не требует дополнительного обучения. Это важно. Авторы не обучают отдельную модель награды под каждую область, а используют уже готовую LLM или зрительно-языковую модель как универсальный проверяющий модуль.

Метод держится на трех идеях.

Первая — более мелкая шкала оценок. Не 1–5, а до 20 уровней. Причем важно не только число уровней, но и то, что используется распределение вероятностей по ним.

Вторая — повторная проверка. Один прогон может быть шумным. Несколько независимых оценок снижают разброс.

Третья — разложение критериев. Вместо одного вопроса «это правильно?» модель отдельно смотрит, например:

Это похоже на здравый человеческий процесс проверки. Когда мы оцениваем сложную работу, мы ведь тоже не ставим балл «на глаз». Мы раскладываем ее на части.

Точность верификации растет сразу по трем направлениям: более мелкая шкала оценок, повторные проверки и разложение критериев.

Результат выглядит убедительно. На Terminal-Bench V2 точность попарного сравнения выросла:

Это не косметическое улучшение. В задачах выбора лучшей траектории даже несколько процентов сверху — очень много.

Почему это важно на практике

Главный посыл статьи такой: у многих моделей уже есть скрытый запас качества. Они часто могут решить задачу хотя бы в одной из нескольких попыток. Но системе не хватает хорошего механизма, чтобы эту удачную попытку распознать и выбрать.

Авторы показывают это на Terminal-Bench. Если бы существовал идеальный «оракул», который всегда выбирает лучший ответ из набора кандидатов, то точность доходила бы почти до 99%. Это огромный запас. Значит, проблема часто не в генерации как таковой, а в выборе.

Чтобы сделать выбор не слишком дорогим, авторы добавляют еще один компонент — алгоритм ранжирования кандидатов с ограниченным бюджетом проверок. Он называется вероятностный турнир с опорными кандидатами. Идея простая: не сравнивать все со всеми, что дорого, а сначала быстро отобрать сильных кандидатов, а потом тратить основной бюджет на сравнение вокруг лидеров. Это снижает стоимость с квадратичной до почти линейной по числу кандидатов с небольшим множителем.

Схема вероятностного турнира: как выбрать лучший вариант из многих, не сравнивая все пары напрямую.

Для ИИ-агентов это особенно важно. Агент для программирования, как правило, может сделать несколько заходов к одной задаче. Если у вас есть надежный верификатор, система начинает работать в режиме «сгенерируй несколько решений и выбери лучшее». Это очень практичный путь к росту качества.

Результаты: код, робототехника, медицина

Самое сильное место статьи — широта экспериментов. Авторы не ограничились одним бенчмарком и одной областью. Они проверили метод на коде, видео из задач робототехники и медицинских сценариях.

Итоговые числа такие:

Итоговые результаты: метод показывает лучший на данный момент результат сразу в программировании, робототехнике и медицинских задачах.

Особенно показателен пример с RoboRewardBench. Там нужно понять, какая из двух видеотраекторий робота лучше продвигается к цели. То есть модель должна по кадрам понять физический прогресс задачи. И здесь предложенный подход обходит не только обычного LLM-судью, но и специализированные модели награды, обученные именно на данных из робототехники.

Это важный момент. Мы привыкли думать, что без узкоспециального обучения в такой области никуда. Авторы показывают, что сильный универсальный верификатор иногда может оказаться даже лучше.

Не только выбор ответа, но и отслеживание прогресса

Еще одна интересная часть статьи — идея использовать сигнал верификатора как оценку прогресса по ходу длинной траектории.

Если агент решает задачу шаг за шагом, можно подавать верификатору не только финальный результат, но и промежуточные префиксы траектории. Тогда мы видим: движется ли агент к цели или блуждает.

Авторы показывают красивый пример с задачей по запуску инференса для MNIST. Успешная траектория идет по понятной цепочке шагов, и оценки верификатора постепенно растут. Неудачная — сворачивает не туда, устанавливает лишние пакеты, упирается в нехватку места на диске, и ее оценки заметно ниже.

Оценка верификатора растет по мере движения успешной траектории и помогает отличать прогресс от блуждания.

Это уже не просто инструмент выбора «лучшего из пяти ответов». Это почти приборная панель для ИИ-агента. Можно наблюдать, когда он реально продвигается, а когда застрял. Для долгих запусков агента для программирования такая штука может быть очень полезной: остановить процесс раньше, откатить неудачные действия, переключиться на другой вариант.

Польза для обучения с подкреплением

Самый неожиданный кусок работы — применение верификатора в обучении с подкреплением.

В таких задачах одна из вечных проблем — разреженная награда. Агент часто узнает, что он молодец, только в самом конце. А как понять, какие именно шаги помогли к успеху? Это тяжело.

Авторы используют сигнал верификатора как плотную награду. То есть не только «успех/провал», а более плавную оценку прогресса на промежуточных этапах.

В экспериментах это ускорило обучение:

Плотная награда от верификатора ускоряет обучение с подкреплением и помогает раньше выходить на тот же уровень качества.

Это не выглядит как магический скачок, но выглядит как очень практичная вещь. Если вы можете без отдельного обучения получить осмысленный сигнал прогресса, то это серьезно удешевляет настройку систем.

Где у подхода слабые места

Работа сильная, но не без ограничений.

Во-первых, методу удобно, когда модель отдает логарифмы вероятностей токенов. А многие закрытые API этого не делают. Авторы предлагают обходной путь: одна модель пишет рассуждение, а другая, более открытая, превращает его в непрерывную оценку. Это рабочий костыль, но все же костыль.

Во-вторых, критерии проверки здесь часто задаются вручную. Для кода это еще нормально: требования, вывод, ошибки. Но для новых областей придется продумывать такие разложения отдельно. Напрашивается следующий шаг: чтобы сама модель умела строить критерии динамически.

В-третьих, повторные проверки и более тонкая шкала улучшают ситуацию, но не убирают систематические смещения модели. Если верификатор в каком-то типе задач рассуждает неверно, простое усреднение не спасет.

И все же эти ограничения не портят главный вывод статьи.

Вывод

Статья предлагает очень своевременный сдвиг оптики. Мы привыкли обсуждать, как сделать генерацию сильнее. Авторы напоминают: не менее важно научить систему хорошо проверять.

И это не философия, а рабочая инженерная идея. Вместо грубого «судьи» — вероятностный верификатор с непрерывной оценкой. Вместо одной оценки — масштабирование по трем осям: зернистость, повторение, критерии. Вместо дорогого полного турнира — более экономный отбор лучших кандидатов.

Главное, что все это уже дает практический эффект: лучшее качество в задачах программирования, в робототехнике, в медицине и даже более эффективное обучение с подкреплением.

Если коротко, то мысль статьи такая: следующий прирост качества ИИ-агентов может прийти не только от того, как они думают, но и от того, как они себя проверяют. И похоже, это одна из самых полезных идей для систем, которые должны не просто красиво говорить, а надежно действовать.