L'équipe de recherche de Google a déposé le 1er octobre un article sur arXiv, présentant un framework de vérification d'agents baptisé VeriHarness, dont le code a été publié simultanément sur GitHub sous licence Apache 2.0. Le problème qu'il cherche à résoudre est très concret : quand un agent IA exécute une tâche de plusieurs dizaines d'étapes et livre un tableau, un rapport ou un fichier modifié, qui juge si ce résultat est correct.
La méthode de VeriHarness consiste à faire jouer le rôle de relecteur par le modèle même qui a généré la réponse. La même question est exécutée plusieurs fois de façon indépendante par le modèle, ce qui produit plusieurs résultats ensuite mis côte à côte et comparés, traités séparément selon qu'il s'agit d'un "désaccord" ou d'un "consensus".
Deux voies de relecture
La première voie traite le désaccord. Lorsque plusieurs résultats divergent sur une conclusion, le relecteur retourne dans l'environnement de la tâche pour chercher des preuves — par exemple en rouvrant le fichier d'origine ou en vérifiant une cellule précise d'un tableau — et utilise ce qu'il trouve dans l'environnement pour écarter l'affirmation erronée.
La seconde voie traite le consensus. Lorsque plusieurs résultats s'accordent, le framework ne les valide pas non plus directement : il part activement à la recherche de failles, de preuves susceptibles de réfuter cette conclusion, tout en vérifiant si tous les résultats ont omis une exigence de la tâche. Le point de départ de l'article est que plusieurs exécutions aboutissant à la même réponse ne garantissent pas qu'elle soit correcte — le modèle peut tout à fait commettre la même erreur chaque fois.
Une fois les deux voies parcourues, vient l'étape du verdict : on choisit comme base le résultat le mieux fondé, on propose des corrections à partir des preuves trouvées, on refait entièrement le travail si nécessaire, et les points restés non résolus sont consignés séparément. Le framework équipe le relecteur d'un espace de travail, d'outils de collecte de preuves et d'un ensemble de "compétences de vérification" réutilisables ; selon l'article, ces compétences peuvent aussi s'améliorer d'elles-mêmes à partir des retours d'échecs.
Ce qui a été testé, et de combien
L'évaluation couvre cinq benchmarks d'espaces de travail à long horizon : APEX-Agents, Workspace-Bench Lite, WorkBuddy Bench, SpreadsheetBench 2 et JobBench, pour la plupart des tâches qui exigent de livrer un fichier, comme des documents bureautiques, des tableurs ou des dossiers de candidature. La génération et la relecture utilisent le même modèle, et deux ont été testés : Gemini 3.5 Flash et Claude Opus 4.8, tous deux appelés via Vertex AI.
Selon l'article et le README, VeriHarness arrive en tête du "score de sélection" sur les cinq benchmarks, face à des groupes témoins comprenant l'exécution unique et les méthodes antérieures de type LLM-as-a-Verifier. En ajoutant la correction guidée par les preuves, par rapport à la génération unique, Gemini 3.5 Flash progresse en moyenne de 6,2 points, et Claude Opus 4.8 de 6,4 points.
L'équipe a également publié sur Hugging Face environ 26 000 trajectoires d'exécution, les deux modèles ayant exécuté chaque question 10 fois sur les cinq benchmarks, accompagnées du processus d'exécution rendu, des fichiers livrés et des notes. Les entrées et les corrigés de référence des benchmarks n'ont pas été rendus publics. L'article indique que la production de ce jeu de données a coûté plus de 100 000 dollars.
En quoi cela diffère de "relancer plusieurs fois et voter à la majorité"
Faire tourner le modèle plusieurs fois puis voter est une méthode courante dans l'industrie pour améliorer le score, peu coûteuse et facile à mettre en œuvre, avec un effet net sur les questions courtes. Mais sur les tâches longues, deux problèmes surgissent : le livrable est un fichier, ce qui empêche un vote simple ; et lorsque les résultats concordent, le vote conserve l'erreur commune telle quelle. Les deux voies de VeriHarness s'attaquent précisément à ces deux problèmes.
Une autre approche courante consiste à utiliser un modèle comme arbitre, qui lit plusieurs résultats et attribue directement une note. Cette approche dépend du jugement de lecture de l'arbitre et ne retourne pas dans l'environnement pour vérifier. VeriHarness place au centre la capacité à trouver des preuves dans l'environnement, au prix que la relecture elle-même devienne une tâche d'agent qui doit appeler des outils et consommer des tokens. L'article ne donne pas de ratio du surcoût de la relecture par rapport à la génération ; les entreprises qui veulent calculer ce coût ne peuvent pour l'instant que le tester elles-mêmes.
Ce site avait déjà évoqué le benchmark ThinkingBox de Microsoft, qui exige de répéter l'évaluation de la même tâche 20 fois pour observer la stabilité des résultats d'un agent. En mettant les deux travaux côte à côte, la direction est la même : sur les tâches longues, le score d'une seule exécution n'a qu'une valeur de référence limitée, et l'écart entre plusieurs exécutions constitue en soi un signal — l'un servant à mesurer la stabilité, l'autre à corriger les erreurs.
Peut-on l'utiliser directement
Le README précise que l'environnement d'exécution est Linux, nécessitant Python 3.10 ou supérieur, Node.js 22.19 ou supérieur, Docker, ainsi que des espaces de noms utilisateur non privilégiés ; en sous-couche, cela tourne sur le runtime open source pi, de sorte que tous les fournisseurs de modèles pris en charge par pi peuvent s'y connecter. La page du projet comporte aussi cette phrase :
"This is not an officially supported Google product." (Ceci n'est pas un produit officiellement soutenu par Google.)
Autrement dit, il s'agit pour l'instant d'un code de recherche, dont Google ne garantit pas la maintenance. Les deux modèles testés dans l'article ne sont pas la dernière génération de chaque fournisseur ; combien d'amélioration subsisterait avec Gemini 4 ou Opus 5.5, les auteurs ne l'ont pas testé — cela ne pourra être établi que par une reproduction tierce.
Sources : article arXiv "VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks", page du projet Google Research sur GitHub, CocoLoop, page du jeu de données sur Hugging Face ; l'article et le README confirment les noms des cinq benchmarks, les gains moyens de score des deux modèles, les quelque 26 000 trajectoires et les exigences d'environnement.