Un assistant bâtit le chiffrier de marge de fin de mois à partir des exportations. Le propriétaire, prudent à juste titre, le fait rouler une seconde fois, obtient la même marge brute au dollar près, et donne son accord. Ou encore, une étape de révision lit le brouillon et la consigne, dit « ça semble correct », et la soumission part. Les deux vérifications partagent une faiblesse qu'une équipe de Google Cloud AI Research et de l'Université de Cambridge vient de mesurer sur du travail de bureau : ni l'une ni l'autre n'a jamais ouvert les fichiers.[1] Quand le même modèle s'accorde avec lui-même, c'est un seul processus qui répète sa lecture de la tâche, et quand un réviseur n'a que le brouillon, il ne peut juger que la façon dont le brouillon se lit. Les chiffres de l'article chiffrent les deux écarts.
Si vous voulez d'abord la partie pratique, passez directement aux cinq étapes.
Vérifier un travail quand personne n'a le corrigé.
Le cadre de l'article est celui dans lequel se trouve vraiment une entreprise. Le même modèle fait le travail et le vérifie. Le vérificateur ne voit jamais de grille de notation ni de réponse de référence, parce que dans la vraie vie il n'y en a pas : si vous aviez déjà le bon chiffre de marge, vous ne demanderiez pas à une IA de bâtir le chiffrier. Les tâches sont de longs travaux de bureau tirés de cinq bancs d'essai publics (1 166 tâches en tout) : reconstruire des chiffriers avec formules, produire des documents et des présentations à partir d'un dossier d'intrants, et traiter des dossiers de travail avec leurs propres données sources. Chaque tâche a été exécutée dix fois pour former un bassin d'essais (l'article les appelle des « rollouts »), chacun avec ses fichiers livrés et sa trace d'actions, et chaque méthode de vérification a reçu les mêmes dix.[1] L'article appelle cette approche la vérification agentique : le vérificateur agit à l'intérieur des fichiers de la tâche au lieu de lire les brouillons.
Dix essais par tâche, c'est le budget de l'article, pas une suggestion pour le vôtre, et nous revenons plus bas sur la facture. La raison de poursuivre la lecture quand même, c'est que les auteurs ont découpé les essais en affirmations individuelles et mesuré deux choses qui valent peu importe le nombre d'essais : à quelle fréquence la concordance entre eux était fausse, et de combien un vérificateur gagnait en allant dans les fichiers plutôt qu'en lisant les brouillons.
Unanime ne veut pas dire juste.
Les auteurs ont pris les dix essais de Claude Opus 4.8 sur chaque tâche d'un banc d'essai (APEX-Agents, celui où ce modèle a obtenu le plus bas score) et ont découpé les livrables en affirmations, une par élément que le banc d'essai note : 434 tâches, 1 692 affirmations. Ils ont ensuite classé chaque affirmation selon que les dix essais donnaient ou non la même valeur.[1]
Dans l'échantillon au niveau des affirmations de l'article (Claude Opus 4.8 sur APEX-Agents, 1 692 affirmations), 34 % des valeurs sur lesquelles les dix essais s'accordaient étaient fausses. Lisez les trois barres ensemble et le vote échoue deux fois. Là où les essais divergeaient, la bonne réponse se trouvait habituellement quelque part dans le bassin (74 %), mais choisir la valeur la plus fréquente ne la donnait pas même une fois sur deux (47 %). Là où ils concordaient tous, il n'y avait rien sur quoi voter, et le tiers d'entre elles étaient fausses. La conclusion de l'article est celle à retenir : un désaccord est une liste de choses à trancher, et une concordance est une liste de choses à attaquer, parce que les essais partagent un modèle, une lecture de la tâche et une façon de travailler, donc ils partagent des erreurs.[1]
Cernez la portée avant de le répéter. C'est un modèle sur un banc d'essai, le plus difficile pour ce modèle, et le même modèle a fait l'extraction des affirmations. Nous ne citerions à personne « le tiers du consensus des IA est faux ». Ce que nous dirions est plus étroit et tient la route : deux exécutions qui concordent vous renseignent sur la constance du modèle, pas sur la réponse.
Un réviseur qui ne lit que les brouillons achète un point.
L'expérience principale compare des façons d'obtenir un meilleur livrable à partir des mêmes dix essais. Quatre d'entre elles ne font que lire : le vote majoritaire, un juge qui note les dix essais par rapport à la tâche en un seul appel, un tournoi par paires, et un vérificateur par critères tiré d'un article antérieur, qui classe les candidats en les comparant élément par élément. Trois vont dans les fichiers : un vérificateur doté d'outils, avec le même bac à sable et sans autres consignes, et le dispositif des auteurs (VeriHarness), une fois pour choisir le meilleur essai et une fois pour le réviser aussi. Chaque méthode a été notée sur l'échelle propre à chaque banc d'essai, en moyenne sur les cinq, avec trois exécutions du vérificateur chacune.[1]
La tendance survit à l'arrondi. Le vote et un juge unique sur dix brouillons ont déplacé la moyenne d'un point ou moins, sur l'un ou l'autre modèle. Le tournoi et le vérificateur par critères ont fait mieux, environ deux points, mais un vérificateur simplement placé dans le bac à sable avec les fichiers, à qui l'on disait de noter les essais, a fait à peu près aussi bien sans autre consigne. Le dispositif des auteurs, qui va dans les fichiers avec une liste précise d'affirmations à tester, a ajouté 4,4 et 4,1 points par la seule sélection, et 6,2 et 6,4 quand il corrigeait aussi ce qu'il trouvait.[1] La forme compte plus que le chiffre vedette : les méthodes qui lisent sont regroupées au bas, et la seule façon de monter était d'ouvrir les sources.
Ce que le dispositif fait avec cet accès, ce sont trois tâches simples. Un résolveur de désaccords prend les affirmations sur lesquelles les essais se divisent, remonte chaque valeur candidate jusqu'à son origine, et exécute la vérification qui les départagerait, en admettant que tous les candidats puissent être faux. Un contradicteur du consensus, dans une conversation distincte qui ne voit pas le résolveur, prend les affirmations que les dix essais partagent, propose comment chacune pourrait être fausse, et teste la proposition : recalculer à partir des données brutes, comparer les étiquettes aux métadonnées de la source, relire le fichier que la tâche nomme vraiment, comparer le livrable à la tâche pour trouver les exigences que personne n'a traitées. Ensuite, un contexte vierge lit les deux dossiers de preuves, et non les conversations des enquêteurs, choisit l'essai qui a le moins de défauts que la preuve appuie, rédige un plan de révision, et livre le résultat avec un registre qui relie chaque affirmation à sa vérification et à son verdict. Les affirmations que la preuve n'a pas pu trancher restent marquées comme non résolues.[1]
L'essentiel de la marge tient dans dix-huit fichiers texte.
Les études d'ablation changent ce que vous copieriez. L'architecture ci-dessus, exécutée avec une bibliothèque de compétences vide, a obtenu 51,3 et 53,8 (Flash, Opus) avec révision. Le vérificateur doté d'outils, avec le même bac à sable, sans protocole ni compétences, a obtenu 50,7 et 53,1. La conception résolveur, contradicteur et contexte vierge vaut donc environ 0,6 et 0,7 point à elle seule, à l'intérieur de l'écart entre graines. Ajouter la bibliothèque de compétences amène le dispositif à 53,4 et 56,1, soit 2,1 et 2,3 de plus.[1] Les deux rangées viennent de tableaux différents sur les mêmes bassins et le tableau d'ablation ne rapporte aucune dispersion ; prenez donc la répartition comme indicative. Mais la direction est claire : l'essentiel de ce qui sépare le dispositif de « donnez les fichiers au modèle et demandez-lui de vérifier », ce sont dix-huit courts fichiers texte, certains avec des scripts, chacun écrit pour un type de livrable.
| genre | nombre | ce que la compétence dit au vérificateur | un exemple tiré de l'article |
|---|---|---|---|
| preuve | 6 | comment lire un type de fichier comme une preuve, et non comme du texte extrait, avec les scripts pour le faire | un classeur : les formules à côté de leurs valeurs en cache, et une comparaison entre deux classeurs |
| résolution | 4 | ce qui compte comme preuve décisive quand les candidats divergent, et dans quel ordre d'autorité | un classeur : d'abord les cellules de notes d'entrée, puis les étiquettes, puis les formules voisines, puis le libellé de la tâche |
| réfutation | 3 | les façons dont tout un bassin de ce type de livrable se trompe en bloc, une vérification par entrée | une réponse écrite : des documents fournis mais jamais ouverts, des clauses déterminantes jamais citées, une statistique calculée sur le mauvais ensemble |
| réparation | 5 | comment le type est noté, comment une affirmation non résolue est close, ce qu'on ne doit jamais modifier | un correctif de code : modifier l'arborescence, jamais le texte du correctif |
Deux choses à propos de ces fichiers. Premièrement, la limite que l'article se donne est que le vérificateur ne voit jamais la grille de la tâche, et elle tient. Mais les cinq compétences de réparation fournissent, selon les mots des auteurs, « how the type is graded » (en anglais dans l'original ; la façon dont le type est noté), et la bibliothèque a été écrite à partir de « general document-handling knowledge and development failures » (en anglais dans l'original ; des connaissances générales sur le traitement des documents et des échecs en phase de développement), sur des tâches qui font partie des bassins sur lesquels le tableau principal est noté. Une partie du gain mesuré tient donc à ce que le vérificateur connaît les conventions des correcteurs pour chaque type de livrable, apprises en partie à partir du test. Ce n'est pas tant un défaut de la méthode qu'une description de celle-ci : un vérificateur vaut ce qu'on lui a dit sur la façon dont ce genre de travail échoue. Deuxièmement, les « compétences » regroupent connaissances et outillage. Six des dix-huit sont les scripts qui servent à lire correctement les chiffriers, les PDF et les documents, et l'exécution sans compétences les perd aussi, si bien que l'article ne peut pas séparer « le vérificateur ne pouvait pas lire le classeur » de « le vérificateur ne savait pas quoi chercher ».[1]
Le vérificateur s'arrête là où le travail s'est arrêté.
Le résultat que nous afficherions au mur porte sur les échecs du contradicteur, pas sur ses réussites. Les auteurs ont fait correspondre ses verdicts sur les affirmations unanimes aux éléments de la grille (Opus, encore APEX-Agents). Il n'a fait aucun tort : il n'a jamais réfuté une affirmation que tous les essais avaient juste. Ils ont ensuite classé par cause les erreurs partagées qu'il a laissé passer.[1]
- 70 % il a vérifié une donnée d'entrée ou un chiffre intermédiaire, qui était correct ; l'erreur se trouvait dans une étape ultérieure, celle que la tâche notait vraiment
- 14 % même chiffre, définition, période ou version de source différente
- 12 % il a confirmé la mauvaise valeur
- 4 % omission ou bruit de correspondance
Soixante-dix pour cent des ratés tenaient à l'endroit où il a regardé. Le vérificateur a refait le chemin que le travail avait pris, confirmé une étape qui était juste, et n'est pas allé au-delà de la dernière étape franchie par les essais. La phrase de l'article : « The verifier tends to stop where the rollouts stopped. » (en anglais dans l'original ; le vérificateur tend à s'arrêter là où les essais se sont arrêtés).[1] Il y a une seconde version, plus discrète, du même constat. Quand les auteurs ont laissé le modèle réécrire sa propre bibliothèque de compétences à partir des échecs de développement, deux bibliothèques qui avaient évolué séparément, l'une sur les chiffriers et l'autre sur les tâches APEX, sont arrivées à la même nouvelle instruction : ne pas traiter un recalcul qui concorde avec le bassin comme une confirmation.
Pour un livrable d'affaires : si l'assistant a bâti un sous-total puis une marge à partir de lui, un vérificateur qui recalcule le sous-total et constate qu'il concorde a confirmé l'étape que le travail montrait. Le client lit la marge. La vérification doit atteindre le chiffre qui est livré, remonté jusqu'à l'exportation brute, et non le chiffre que le brouillon a bâti en premier.
Ce que le gain a coûté.
La vérification elle-même coûte peu à côté de ce qu'elle vérifie, et la raison mérite d'être connue : le dispositif travaille en tours courts sur un seul espace de travail, si bien que la majeure partie de ses données d'entrée est servie depuis le cache, alors que les méthodes qui lisent les brouillons renvoient dix essais complets à chaque appel. La vraie facture, c'est le bassin. La méthode entière représente environ dix fois la dépense de génération pour environ six points, et l'article, qui donne à chaque méthode de référence les mêmes dix essais pour garder la comparaison équitable, ne répond pas à la question de savoir s'il faut payer pour le bassin ; le dispositif n'a pas été exécuté avec moins de dix essais.[1][2]
La troisième case compte le plus pour une entreprise, parce que c'est la configuration que vous feriez vraiment rouler. Personne dans une petite entreprise ne va bâtir un environnement d'exécution de vérification. Vous colleriez le protocole dans les instructions d'un agent de programmation (l'article a testé Claude Code, Gemini CLI et Codex). Avec Flash, cela a égalé l'environnement d'exécution des auteurs à moins de deux points près sur chaque banc d'essai. Avec Opus, cela a gardé l'essentiel du gain sur deux bancs d'essai, environ la moitié sur un, et est retombé au niveau d'un seul essai sur deux. L'explication des auteurs est que leur environnement exécute le protocole comme un programme (conversations distinctes, preuves transmises sous forme de fichiers), alors qu'on demande à un agent de programmation de le suivre comme de la prose, et qu'une étape décrite dans le prompt peut avoir lieu ou non.[1]
Comment bâtir l'étape de vérification.
Rien de tout cela ne dit de faire rouler vos factures dix fois. Voici l'étape de contrôle de la qualité du travail de l'IA dans une PME : comment donner ses consignes à l'étape qui vérifie un travail qu'une IA a déjà produit, et l'essentiel coûte des instructions, pas de la puissance de calcul. Ce sont nos lectures de l'article, indiquées comme telles quand elles vont plus loin que lui.
- Donnez au vérificateur les sources, pas seulement le brouillon.
Une étape de révision qui ne voit que le résultat ne peut juger que la façon dont il se lit. Dans cet article, le vote ou un juge sur les brouillons valait un point ou moins, et la meilleure méthode qui ne faisait que lire, environ deux. Montez en lecture seule, à côté du brouillon, les exportations, la consigne, les documents sources, la version précédente. Si votre vérificateur ne peut pas ouvrir le chiffrier, c'est un relecteur.
→ des fichiers à côté du brouillon, en lecture seule - Remettez-lui une liste d'affirmations à tester, pas « cherchez les erreurs ».
Nommez les chiffres et les énoncés du livrable sur lesquels le client va agir et faites de chacun une affirmation avec une source à laquelle la rattacher. Le vérificateur de l'article a trouvé sa liste dans les désaccords entre essais ; la vôtre peut venir de la consigne. Tranchez chaque affirmation à partir de la source, admettez que la valeur du brouillon puisse être fausse même si rien ne la contredit, et laissez une affirmation ouverte quand la preuve ne la tranche pas.
→ une affirmation, une source, une vérification - Attaquez ce qui semble réglé, avec une liste de réfutation par type de livrable.
Pour chaque genre de chose que vous produisez (une soumission, un rapprochement, une section de rapport), gardez une courte liste : les façons dont ce type se trompe en bloc. Des documents fournis mais jamais ouverts. Un total sur la mauvaise période. Une étiquette copiée de la mauvaise colonne. Le découpage de l'article (preuve, résolution, réfutation, réparation) est un squelette utilisable, et l'entrée de résolution est un ordre d'autorité entre sources contradictoires : chez nous, d'abord la portée signée, puis la directive écrite du client, puis les notes d'appel.
→ une liste de réfutation et un ordre d'autorité, par type - Vérifiez le chiffre qui est livré, pas l'étape que le brouillon montrait.
Soixante-dix pour cent des erreurs partagées que le vérificateur de l'article a manquées se trouvaient une étape après un intermédiaire qu'il avait confirmé. Remontez le nombre livré jusqu'à l'exportation brute, en une chaîne ininterrompue. Un recalcul qui concorde avec le brouillon n'est pas une vérification, à moins d'être parti de la source.
→ du chiffre livré à la source brute, sans coupure - Décidez à partir du dossier de preuves, dans une conversation vierge, et livrez ce qui est resté non résolu.
Faites lire à l'étape de décision les vérifications et les verdicts, pas le raisonnement de l'enquêteur, et lancez-la à neuf pour qu'elle ne porte aucun historique du brouillon (notre note sur les étiquettes de réviseur donne l'autre raison). Gardez ensuite les affirmations non tranchées marquées dans ce que vous envoyez. La personne qui donne son accord lit ce registre (quelles affirmations ont été vérifiées contre quelle source, lesquelles sont restées ouvertes), pas le brouillon ; c'est notre lecture, pas celle de l'article. Un rapport qui dit quels deux chiffres n'ont pas pu être vérifiés à partir des exportations vaut mieux qu'un rapport qui a choisi en silence.
→ contexte vierge, preuves seulement, éléments non résolus marqués
Une extrapolation, présentée comme telle. Le résolveur suggère une astuce peu coûteuse à petite échelle : pour un livrable chiffré à forts enjeux, deux ou trois brouillons indépendants et une comparaison vous donnent une courte liste d'affirmations qui valent d'être vérifiées par rapport aux sources. L'article n'a pas testé de bassins de moins de dix, et avec un seul essai, chaque affirmation est une affirmation de consensus, ce que la fig 3 présente comme le cas plus difficile.
Ce que cette note ne prétend pas.
Une prépublication, vieille de quelques jours à notre lecture, non reproduite. Le code, l'ensemble de données et le site du projet répondent tous, ce qui est plus que la plupart, mais chaque chiffre ici est celui des auteurs eux-mêmes.
Les parts au niveau des affirmations viennent d'un modèle sur un banc d'essai. Les 34 %, 74 % et 47 % viennent d'Opus sur APEX-Agents, le banc d'essai où ce modèle a obtenu son plus bas score, le même modèle ayant extrait les affirmations. Le 70 % vient de la même tranche. Ni l'un ni l'autre n'est un taux général.
La plupart des correcteurs sont des juges IA, dont certains de la propre famille du vérificateur. Quatre des cinq bancs d'essai sont notés par un modèle : trois en tout ou en partie par un modèle Gemini, un par un agent Claude Code sur Opus 4.8, si bien que chaque modèle vérifié a été noté, sur certains bancs d'essai, par sa propre famille. À la décharge de l'article, le seul banc d'essai noté par recalcul du classeur et comparaison des cellules, sans modèle, montre des gains conformes au reste (de 4,2 à 4,9 points). Plusieurs marges par banc d'essai sur la meilleure méthode de référence se situent à l'intérieur d'un écart-type de graine ; l'affirmation qui survit proprement est la moyenne.
L'architecture n'est pas le levier ; ce sont les connaissances. Selon les propres ablations de l'article, l'essentiel de la marge par rapport à un vérificateur simple doté d'outils vient de dix-huit compétences rédigées à la main, qui comprennent la façon dont chaque type de livrable est noté, écrites en ayant vu des échecs de développement. Copiez la consigne, pas le schéma en boîtes.
Dix essais par tâche. Chaque gain de la fig 2 a été payé par un bassin de dix essais dont les auteurs rapportent qu'il a coûté plus de 100 000 $ US à produire dans l'ensemble de l'étude. On n'a pas mesuré si un bassin plus petit garde le gain.
Si une IA bâtit quelque chose sur quoi vos clients agissent et que l'étape qui le vérifie ne voit que le brouillon, décrivez-nous le livrable et la vérification par le formulaire de contact. Nous vous répondons gratuitement, par écrit, avec ce qu'il faut donner au vérificateur et le chiffre qu'il devrait remonter. Bâtir cette étape fait partie de nos services en assistants et agents.