VerifierBench : 19 LLM ont écrit des vérificateurs, le meilleur n'obtient que 62,1 points

Les agents ont besoin d'un moyen de savoir qu'ils ont correctement résolu une tâche. Sans cela, ils ne peuvent ni mener leur travail à terme, ni filtrer des données synthétiques destinées à l'entraînement. L'équipe derrière VerifierBench a mesuré dans quelle mesure les LLM y parviennent seuls : à partir d'une instruction et d'un environnement accessible, l'agent écrit un vérificateur exécutable, qui doit accepter toute solution correcte et rejeter toute solution incorrecte. Le benchmark réunit 222 tâches issues de six benchmarks agentiques et 4993 cas de test cachés. Sur 19 modèles, la précision équilibrée normalisée s'établit entre 10,6 et 62,1.

Ce que VerifierBench évalue exactement

La consigne est stricte. Le vérificateur reçoit la même information que l'agent chargé de résoudre la tâche : l'énoncé et l'environnement. Il doit ensuite en tirer un programme qui rend un verdict sur la solution d'un autre. Les tâches couvrent trois types de vérification : les appels d'outils (tool-call), le contrôle de l'état final de l'environnement (state-based) et la vérification de code.

Les tests cachés sont conçus pour détecter plus que les erreurs évidentes. Chaque tâche compte en moyenne environ 22 cas. Parmi eux figurent des solutions valides alternatives, c'est-à-dire d'autres façons d'arriver au bon résultat, ainsi que des attaques qui cherchent à tromper la vérification. Les auteurs soumettent les vérificateurs de référence et les jeux de tests eux-mêmes à un audit Verifier4Verifier (V4V) en six contrôles. L'étalon ne devient ainsi pas une source d'erreurs.

Paramètres clés de l'étude :

• 222 tâches issues de six benchmarks agentiques
• 4993 cas de test cachés, dont des solutions alternatives et des attaques
• 19 modèles évalués dans un harness agentique unique
• normalized balanced accuracy : de 10,6 à 62,1
• la page du projet et le dataset sont publics

Le vérificateur qui ne laisse entrer personne

Le point le plus intéressant des résultats est un déséquilibre. Les vérificateurs générés rejettent systématiquement mieux les solutions fausses qu'ils n'acceptent les solutions correctes. À première vue, cela passe pour une qualité : un contrôle strict semble plus sûr. Les auteurs montrent que la réalité est différente. Dans les enregistrements analysés, la plupart des faux rejets proviennent de vérificateurs qui n'acceptent aucune des solutions testées pour la tâche. Un tel vérificateur remplit formellement bien la moitié du travail et échoue totalement à l'autre.

Pour les pipelines, c'est un problème sérieux. Si le vérificateur sert à filtrer des données synthétiques, un excès de rigueur écarte silencieusement des trajectoires correctes. S'il sert de signal de réussite à l'agent en phase d'exécution, ce dernier peut refaire indéfiniment un résultat déjà bon.

L'analyse de cas individuels montre d'où vient cette rigueur. Les vérificateurs intègrent des hypothèses non vérifiées sur le format de la solution, sur les outils à appeler et sur l'aspect que doit avoir le code après modification. Toute solution construite autrement que ne l'imaginait l'auteur du contrôle est écartée, même si elle résout la tâche.

Pourquoi l'autotest ne détecte pas l'erreur

On pourrait s'attendre à ce que l'agent repère lui-même le défaut en lançant son vérificateur sur des solutions d'essai. En pratique, les erreurs survivent à l'autotest, et les auteurs avancent deux raisons. La première : l'agent teste des solutions qui partagent les mêmes hypothèses erronées que le vérificateur lui-même. Il écrit un contrôle pour un seul modèle de réponse, génère ensuite une réponse selon ce même modèle, et tout concorde. La seconde : une partie des agents rendent leur vérificateur sans même s'être assurés qu'au moins une solution correcte le franchit.

Comment tester les vérificateurs eux-mêmes

La conclusion des auteurs est pragmatique : il ne suffit pas de vérifier que le vérificateur accepte une solution correcte. Il faut aussi tester s'il accepte les autres solutions que la tâche autorise. Pour les équipes qui construisent des pipelines agentiques ou assemblent des datasets synthétiques, cela implique plusieurs étapes.

Premièrement, chaque vérificateur généré a besoin d'au moins un exemple manifestement correct qui passe le contrôle, faute de quoi il risque de devenir un « mur infranchissable ». Deuxièmement, le jeu de tests doit contenir des solutions correctes alternatives, avec un autre format, un autre ordre d'appels et une autre manière de modifier le code. Troisièmement, il faut suivre séparément la part de faux rejets plutôt que la seule précision globale : un déséquilibre vers la rigueur se dissimule facilement dans une métrique agrégée. Enfin, l'étalon lui-même doit être audité, et l'approche V4V fournit pour cela un schéma prêt à l'emploi.

L'écart de 10,6 à 62,1 montre aussi que la génération de vérificateurs est encore loin d'être un problème résolu. Même le meilleur résultat laisse une marge d'erreur notable. Il est donc trop tôt pour se fier à une évaluation agentique sans contrôle indépendant, et le dataset public offre aux équipes un moyen pratique de comparer les modèles sur cette compétence précise.