VerifierBench: 19 LLM написали верификаторы, лучший набрал лишь 62,1 балла

Агентам нужен способ понимать, что они сделали задачу правильно. Без этого нельзя ни довести работу до конца, ни отфильтровать синтетические данные для обучения. Команда авторов VerifierBench проверила, насколько хорошо LLM справляются с этим сами: по инструкции и доступной среде агент пишет исполняемый верификатор, который обязан принять любое корректное решение и отклонить любое некорректное. Бенчмарк включает 222 задачи из шести агентских бенчмарков и 4993 скрытых тестовых кейса. На 19 моделях нормализованная сбалансированная точность оказалась в диапазоне от 10,6 до 62,1.

Что именно проверяют в VerifierBench

Задача сформулирована жёстко. Верификатор получает ту же информацию, что и агент-решатель: текст задания и окружение. Дальше он должен превратить это в программу, которая выносит вердикт по чужому решению. Задачи охватывают три типа проверки: вызовы инструментов (tool-call), проверку итогового состояния среды (state-based) и проверку кода.

Скрытые тесты построены так, чтобы ловить не только очевидные промахи. На каждую задачу в среднем приходится около 22 кейса. Среди них есть альтернативные валидные решения, то есть другие способы прийти к правильному результату, и атаки, которые пытаются обмануть проверку. Сами исходные верификаторы и тестовые наборы авторы пропускают через аудит Verifier4Verifier (V4V) из шести проверок. Так эталон не становится источником собственных ошибок.

Ключевые параметры работы:

• 222 задачи из шести агентских бенчмарков
• 4993 скрытых тестовых кейса, включая альтернативные решения и атаки
• 19 моделей в едином агентском харнессе
• normalized balanced accuracy: от 10,6 до 62,1
• публичны страница проекта и датасет

Верификатор, который никого не пускает

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

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

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

Почему самопроверка не ловит ошибку

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

Как тестировать самих проверяющих

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

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

Разброс от 10,6 до 62,1 говорит и о том, что генерация верификаторов пока далека от решённой задачи. Даже лучший результат оставляет заметный запас ошибок. Поэтому доверять агентской оценке без независимого контроля рано, а публичный датасет даёт командам удобный способ сравнивать модели именно по этому навыку.