Un préprint propose de vérifier si les agents d’IA méritent leurs scores

Un score ne raconte pas toute l’histoire

Un agent peut obtenir un score de réussite à un benchmark. Ce résultat confirme que le système a reçu les points prévus par la procédure d’évaluation appliquée, mais il n’explique pas nécessairement ce qu’il a fait pour les obtenir, si sa déclaration de réussite est exacte ni s’il parviendrait au même résultat lors d’une nouvelle tentative. Cette différence entre recevoir des points et démontrer de façon vérifiable une capacité est le problème abordé par Trust Layer, un cadre présenté dans un préprint.

La proposition ne remplace pas le score et ne vise pas à le modifier. Elle ajoute des vérifications a posteriori et indique si le résultat satisfait à quatre contrôles de confiance. L’objectif est de distinguer deux questions souvent réunies dans un seul chiffre : quel score l’agent a-t-il obtenu, et quels éléments permettent de croire que ce score correspond à une performance réelle et reproductible ?

Les auteurs appliquent le cadre à cinq configurations d’agents sur 108 tâches d’Agents’ Last Exam. Les chiffres décrivent donc cette expérience précise ; ils ne doivent pas être interprétés comme une estimation universelle de la fiabilité de tous les agents, modèles ou benchmarks. Ils ne prouvent pas non plus que le cadre a été adopté comme norme ou validé de manière indépendante.

Quatre questions différentes à propos d’une réussite

La première vérification consiste à déterminer si le résultat est étayé par la logique de notation propre au benchmark. Il ne suffit pas de regarder la note finale : il faut examiner si la réponse enregistrée satisfait aux conditions que le correcteur devait appliquer. La question porte sur le lien entre les éléments disponibles et le critère de notation, et non sur la capacité du critère, à lui seul, à mesurer une aptitude utile dans le monde réel.

La deuxième vérification cherche à savoir si une réponse ayant obtenu la moyenne a été produite au moyen d’un processus informatique traçable. Elle vise à distinguer un résultat accompagné d’étapes ou d’éléments vérifiables d’un résultat pour lequel on ne dispose pas de traces suffisantes sur la manière dont il a été obtenu. « Non traçable » ne signifie pas automatiquement « incorrect » : cela indique que les artefacts analysés ne permettent pas de vérifier le processus requis.

La troisième vérification compare la déclaration d’achèvement de l’agent avec ce qui s’est effectivement passé. Par exemple, le système peut déclarer avoir terminé une tâche alors que les éléments enregistrés ne montrent pas que l’action a bien été menée à terme. Le résumé du préprint fait état de fausses déclarations d’achèvement confirmées, mais ne donne pas de taux précis pour cette catégorie ; il ne convient donc pas de lui attribuer une fréquence.

La quatrième vérification porte sur la stabilité du résultat lorsqu’on relance l’agent. Une seule exécution ne suffit pas à mesurer cette stabilité. Dans l’expérience décrite, il faut relancer l’agent et comparer les scores obtenus. Une réussite isolée et une performance constante sont donc deux signaux distincts.

Ce qui peut être vérifié dans les enregistrements et ce qui exige de relancer le test

D’après la description du préprint, les trois premières propriétés sont évaluées à partir d’artefacts enregistrés. En pratique, l’audit suppose donc que les éléments pertinents existent — par exemple, les réponses, les résultats du correcteur et les traces des actions — et qu’ils puissent être reliés à la tâche. Le résumé ne permet pas de préciser quels formats sont exigés pour chaque vérification ni quels artefacts manquaient dans les cas étudiés.

La stabilité impose une autre exigence : il faut relancer l’agent. Les auteurs l’ont mesurée au moyen de cinq exécutions et indiquent que, selon la configuration évaluée, 18 % à 46 % des tâches ne sont pas restées dans la même tranche de score. Cette fourchette témoigne de variations entre les configurations étudiées ; elle ne signifie pas que ces proportions s’appliquent à tout agent ou à tout benchmark.

Le cadre associe également des jugements de modèles à des règles déterministes. Les jugements des modèles servent à étiqueter les éléments probants par vote majoritaire, tandis que les verdicts finaux suivent des règles déterministes. Cette distinction est importante : la méthode ne présente pas les jugements auxiliaires comme une preuve concluante à eux seuls et précise que les vérifications ne modifient pas le score enregistré.

Des résultats marquants, mais limités à l’expérience

Dans les cinq configurations analysées, le résumé fait état d’exécutions réussies sans calcul traçable. La fréquence variait d’un facteur dix entre les modèles. Ce résultat révèle des différences importantes au sein de l’ensemble étudié, mais il ne permet pas, à lui seul, d’en déterminer les causes ni de conclure quelle configuration serait la plus fiable sur d’autres tâches.

Les auteurs ont également relevé des cas confirmés de fausses déclarations d’achèvement et des variations entre exécutions. Au total, seuls 22,6 % des résultats enregistrés comme réussites ont satisfait aux quatre vérifications. L’intervalle de confiance à 95 % indiqué va de 15,0 % à 32,6 %, avec n=84. Ce chiffre concerne les réussites incluses dans le calcul, et non toutes les exécutions possibles ni une population générale de benchmarks.

Il ne faut pas en conclure que les agents ne sont capables de réaliser correctement qu’une fraction déterminée des tâches. Le résultat indique combien de réussites de l’expérience ont passé simultanément ces quatre vérifications. En cas d’échec à l’une d’elles, l’interprétation dépend du contrôle concerné : le correcteur peut être en cause, la traçabilité peut manquer, la déclaration de réussite peut ne pas être étayée ou le résultat peut varier d’une exécution à l’autre.

En quoi cette approche se distingue d’autres évaluations d’agents

Les tests d’agents portent souvent sur des aspects tels que la planification, les actions, l’utilisation d’outils et les réponses du système. Trust Layer ne supprime pas ces formes d’évaluation : le cadre propose d’ajouter un examen des éléments qui étayent les points accordés. Au lieu de se demander uniquement si l’agent a produit la réponse attendue, il demande aussi si le résultat peut être vérifié et s’il se reproduit de manière stable.

Il existe également un problème lié, mais distinct : celui de savoir si un benchmark reflète réellement la capacité qu’il prétend mesurer. Un travail indépendant consacré à l’audit des benchmarks d’agents analyse des traces dans 15 benchmarks et étudie dans quelles conditions leurs scores étayent des affirmations sur les capacités. La validité du benchmark n’est pas la même question que celle de savoir si un résultat particulier est traçable ou si la déclaration d’achèvement correspond à ce qui s’est passé. Ces deux pistes peuvent se compléter, mais l’une ne démontre pas automatiquement l’autre.

Les informations disponibles ne permettent pas d’affirmer que Trust Layer surpasse les méthodes d’audit existantes ni qu’il améliore la qualité des benchmarks. Le résumé décrit les vérifications et les résultats d’une application, mais ne présente pas de comparaison systématique avec d’autres méthodes. Pour déterminer si le cadre apporte un avantage, il faudrait examiner et comparer les protocoles, les critères et les résultats dans des conditions équivalentes.

Ce qui reste à établir pour juger son utilité au-delà de l’étude

La proposition fournit une manière structurée d’accompagner un score de questions vérifiables, mais les informations disponibles ne permettent pas de confirmer si le code, les artefacts ou les données nécessaires à la reproduction des vérifications ont été publiés. Elles ne permettent pas non plus de déterminer précisément quelles décisions opérationnelles requiert chaque règle. Sans ces éléments, il est difficile pour d’autres équipes de vérifier si elles obtiendraient les mêmes verdicts.

L’évaluation décrite se limite à cinq configurations, 108 tâches d’un benchmark et cinq exécutions pour mesurer la stabilité. Appliquer le cadre à d’autres types de tâches, de correcteurs et d’agents aiderait à vérifier si les propriétés se maintiennent et à comprendre l’influence des différences de qualité des enregistrements. Il serait également important d’étudier ce qui se passe lorsque des artefacts manquent ou lorsque la logique de notation ne permet pas une vérification sans ambiguïté.

Pour l’instant, Trust Layer doit être considéré comme une proposition méthodologique étayée par les résultats d’une application précise, et non comme une norme établie ou une garantie qu’un score est exact. Son apport central consiste à demander que les points attribués par un benchmark soient accompagnés d’éléments montrant comment ils ont été accordés, ce qui s’est passé pendant la tâche et si le résultat résiste à une nouvelle exécution. L’utilité de cette approche dépendra de sa reproductibilité et de sa mise à l’épreuve dans d’autres contextes.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.