Un benchmark d’agents doit faire deux choses : exécuter l’agent, puis raconter fidèlement ce qui s’est passé. Nous nous passionnons pour la première et traitons la seconde comme de la plomberie. Dès que le résultat influence le choix d’un modèle, c’est une erreur.

J’ai lu les notes de version d’Inspect AI 0.3.284, publiées le 25 octobre, ainsi qu’une étude récente sur la fiabilité des classements d’agents. Inspect corrige plusieurs défauts de la chaîne de preuve : une erreur inattendue d’un sous-agent en arrière-plan fait désormais échouer l’échantillon ; les échantillons récupérés conservent l’entrée, la cible, les scores, la sortie et le texte des messages ; les entrées et sorties consignées ne changent plus quand un agent modifie ensuite un message. Un prompt dupliqué lors de la compaction native a aussi été corrigé. Ce sont des réparations de l’instrument de mesure, pas de nouvelles capacités du modèle. [1]

Un sous-agent en échec ne vaut pas une réussite

Imaginez qu’un agent délègue une partie d’une tâche, rédige une conclusion convaincante, puis qu’un travailleur en arrière-plan échoue sans que le résultat final en tienne compte. Si l’échantillon passe parce que la réponse paraît crédible, le benchmark récompense une exécution incomplète. La propagation des erreurs documentée par Inspect vise précisément ce défaut comptable. Elle ne garantit pas que chaque tâche dispose d’une vérification indépendante de son résultat concret. [1]

Un agent peut affirmer avoir lu une source qu’il n’a pas consultée ou annoncé une modification qui n’a jamais pris effet. Ce sont des exemples illustratifs, pas des incidents signalés par Inspect. Un évaluateur qui juge le récit plutôt que l’effet risque d’attribuer une meilleure note à un échec bien raconté qu’à une réussite mal formulée.

Les reprises compliquent encore le tableau. Un premier essai peut échouer, puis un second réussir. Le taux de réussite au premier essai, après reprises, le coût total et la stabilité entre essais indépendants sont des mesures distinctes. Si la récupération perd la cible ou les scores initiaux, elle peut aussi effacer la preuve de l’échec. Les corrections apportées aux champs et aux textes récupérés ont donc une importance réelle pour les comparaisons. Je n’ai toutefois pas reproduit ces défauts moi-même. [1]

Davantage de tâches ne réparent pas une mauvaise inférence

L’étude analyse 22 benchmarks d’agents et distingue deux conclusions : classer une combinaison fixe modèle plus environnement d’exécution n’est pas classer le modèle indépendamment de cet environnement. Pour les évaluations étudiées individuellement dans le résumé, la fiabilité estimée du classement est de 0,935 à 0,994 pour les systèmes fixes, mais de 0,148 à 0,841 pour les modèles sous-jacents. Il s’agit d’estimations issues d’une décomposition bayésienne de la variance, pas d’une loi universelle des benchmarks. [2]

Dans les conditions étudiées, une infinité de tâches construites de façon semblable n’améliorerait la fiabilité du classement des modèles que de 0,097 au maximum si la faible diversité des environnements domine l’incertitude. Les auteurs estiment qu’agréger divers benchmarks pourrait faire passer la fiabilité entre tâches de 0,44 à 0,75 avec le même budget de tâches. Ce sont leurs projections statistiques, pas une garantie offerte par un nouveau logiciel. [2]

J’y vois deux façons distinctes de se tromper. Les traces peuvent décrire incorrectement l’exécution d’un système fixe. Et des traces parfaites peuvent soutenir une conclusion bien plus étroite que le titre du classement. De meilleurs journaux répondent au premier problème ; varier les tâches et les environnements répond au second.

Le problème encore ouvert

Cette version ne prouve pas que les traces sont désormais infaillibles. Un ticket Inspect toujours ouvert décrit comment une réévaluation avec streaming et écrasement peut remplacer un journal complet par un instantané partiel en cas d’erreur ou d’interruption. Le ticket propose de renoncer au streaming ou d’écrire ailleurs. Je n’ai pas exécuté cette reproduction ; il s’agit d’un signalement documenté. La leçon : préserver l’original avant toute transformation. [3]

La correction des entrées de modèle modifiées rétrospectivement mérite aussi attention. Si la trace d’une entrée change après la réponse, impossible de reconstruire avec certitude ce qui a été évalué. Un classement reproductible réclame des observations stables, pas seulement une colonne de scores présentable. Corriger ce défaut ne prouve pas pour autant que le barème soit juste. [1]

Les preuves que je demanderais

Il faut d’abord définir l’affirmation : compare-t-on une configuration modèle-environnement précise sur ces tâches, ou les modèles à travers plusieurs environnements ? Publions l’environnement, les permissions des outils, les prompts, la gestion du contexte, la politique de reprises, la version de l’évaluateur et celle des tâches. Un nom de modèle seul sur un tableau ne suffit pas.

Ensuite, rendons les échecs visibles. Une erreur inattendue d’un enfant doit faire échouer l’échantillon ou devenir un résultat distinct. Conserver ensemble les entrées initiales, la cible, les appels d’outils, les messages, les règles de notation et la preuve de l’état final. Avant de renoter ou convertir un journal, garder l’original intact. Après une reprise, indiquer quel essai a produit le score.

Enfin, testons la chaîne de preuve : provoquer une erreur d’un sous-agent, modifier un message en mémoire après son enregistrement, interrompre une reprise, puis comparer les traces à l’exécution observée. Je propose ce protocole ; je ne prétends pas l’avoir exécuté. Si la conclusion vise le modèle en général, ajoutons plusieurs environnements d’exécution.

Je n’ai benchmarké ni Inspect ni un modèle pour cet article. Ma conclusion est volontairement limitée : versionner l’évaluateur avec le modèle, conserver les exécutions brutes et formuler le classement au niveau que le dispositif mesure réellement. Le benchmark fait partie de l’expérience. S’il consigne mal les échecs, les reprises et les entrées, davantage d’échantillons produisent simplement davantage de confusion bien formatée.

Sources

[1] https://github.com/UKGovernmentBEIS/inspect_ai/releases/tag/0.3.284 [2] https://arxiv.org/abs/2610.00651 [3] https://github.com/UKGovernmentBEIS/inspect_ai/issues/5914