Résumé technique : Quand une évaluation d'agent est-elle terminée ?

Énoncé du problème

Les cadres actuels d'évaluation d'agents évaluent généralement les modèles en se basant sur l'état visible au moment où l'exécution est interrompue (le « point de terminaison » ou endpoint). Cette approche suppose que le point de terminaison établit simultanément deux conditions critiques : la finalité du résultat (outcome finality) et la séparation entre les unités (cross-unit separation).

L'article soutient que ces deux conditions sont indépendantes et souvent non remplies au point de terminaison.

1. Finalité du résultat : Une exécution peut s'arrêter alors que des opérations asynchrones (par exemple, des écritures différées, des processus en arrière-plan) sont encore en attente. Évaluer l'état avant que ces opérations ne soient terminées peut conduire à des étiquetages incorrects (par exemple, marquer une tâche comme échouée alors qu'une écriture différée aurait réussi, ou vice versa).
2. Séparation entre les unités : Si l'environnement conserve un état entre les exécutions (par exemple, bases de données partagées, comptes persistants ou artefacts non nettoyés), une exécution précédente peut modifier les conditions de départ ou le résultat d'une exécution ultérieure. Cela viole l'hypothèse selon laquelle les essais sont indépendants et identiquement distribués (i.i.d.), rendant invalides les métriques agrégées (comme le $pass@k$).

Les audits existants vérifient souvent les défauts de benchmark ou les mécanismes de réinitialisation, mais ne parviennent pas à distinguer un résultat simplement « inachevé » d'un cas où la connexion entre les exécutions n'est pas prise en compte.

Méthodologie

L'auteur emploie une approche en trois volets pour étudier ces questions :

1. Cadre théorique (L'argument de l'achèvement) :
   L'article développe un cadre logique distinguant le point de terminaison (quand l'interaction s'arrête) de l'achèvement (quand le résultat est établi et les limites sont sécurisées). Il définit les preuves requises pour justifier un étiquetage final par opposition au traitement des exécutions comme des essais distincts.

2. Expérience de rejeu contrôlé :
   En utilisant AgentDojo 0.1.35, l'auteur a construit un système pour isoler les choix de limites.

   • Configuration : Un exécuteur autonome a rejoué des appels d'outils et des calendriers d'opérations fixes. Un service HTTP local a simulé des délais asynchrones (0, 25, 100, 250 ms) et la persistance d'état.
   • Variables : L'étude a fait varier le moment de l'évaluation (instantané au point de terminaison vs attente de l'état terminal) et la gestion de l'état (état partagé vs état avec espace de noms vs réinitialisation vérifiée).
   • Métriques : L'expérience a mesuré le désaccord entre les étiquettes du point de terminaison et les étiquettes terminales (finalité) ainsi que la fréquence de l'exposition entre les exécutions (séparation).

3. Revue de la documentation :
   L'auteur a examiné la documentation publique et les articles de dix benchmarks d'agents de premier plan : WebArena, WorkArena, OSWorld, SWE-bench, tau-bench, ToolSandbox, TheAgentCompany, RE-Bench, Cybench, et AgentCanary.

   • Critères : Ils ont codifié les déclarations explicites concernant les définitions d'exécution, les règles d'arrêt, la persistance de l'état, les mécanismes de réinitialisation et les preuves de traitement des exécutions comme des essais séparés.
   • Limites : La revue s'est concentrée sur ce qui était explicitement rapporté, et non sur l'inférence de propriétés non déclarées.

Contributions clés

1. Distinction conceptuelle : Finalité du résultat vs Séparation entre les unités

Le papier établit que ces deux exigences sont distinctes et nécessitent des preuves différentes :

• Finalité du résultat : Nécessite que chaque opération ou événement pertinent susceptible de modifier le résultat soit résolu, limité ou confirmé comme annulé.
• Séparation entre les unités : Nécessite qu'aucune voie pertinente (état partagé, identifiants, artefacts) ne permette à une exécution d'influencer les conditions ou le résultat d'une autre.
• Implication : On peut atteindre la finalité sans la séparation (par exemple, attendre la fin d'une écriture, mais laisser le fichier accessible à l'exécution suivante) et la séparation sans la finalité (par exemple, isoler les exécutions, mais évaluer avant qu'une opération différée ne se termine).

2. L'argument de l'achèvement

L'auteur propose un cadre de décision pour les évaluateurs :

• Pour les étiquettes finales : Un étiquetage de succès/échec n'est justifié que si toutes les voies susceptibles de modifier le résultat sont bloquées, suivies jusqu'à l'achèvement ou strictement limitées. Sinon, le résultat doit être rapporté comme non résolu.
• Pour les essais séparés : Les exécutions ne peuvent être comptées comme des unités d'analyse distinctes que si toutes les voies entre elles sont bloquées ou prouvées incapables d'affecter le résultat. Si une connexion subsiste, les exécutions doivent être modélisées comme une unité connectée ou regroupées.

3. Le registre des effets ouverts (Open-Effects Record)

Le papier propose une nouvelle norme de rapport : un registre des effets ouverts. Ce registre doit lister les opérations ou ressources qui restent pertinentes après le point de terminaison, leur statut actuel, et s'ils pourraient changer le résultat évalué ou affecter une autre exécution.

Résultats expérimentaux

Conclusions du rejeu contrôlé

• Finalité : À des délais non nuls, les étiquettes du point de terminaison divergeaient des étiquettes terminales dans 100 % des cas (150/150 essais). L'évaluation par instantané a enregistré 50 succès, tandis que la réconciliation (attente de l'achèvement) en a enregistré 200. L'annulation vérifiée a correctement identifié les écritures en attente comme des échecs.
• Séparation : Sous état partagé, 75 % des paires (150/200) ont montré une exposition où l'Exécution A a modifié le résultat de l'Exécution B. Cette exposition a été éliminée (0/200) sous état avec espace de noms, réinitialisation vérifiée, ou lorsque l'Exécution B tournait avant l'Exécution A.
• Conclusion : Le point de terminaison seul ne peut justifier l'étiquette finale ou l'unité d'analyse. Le moment de l'évaluation et la politique de gestion d'état déterminent directement la validité du résultat.

Conclusions de la revue de la documentation

• Réinitialisation/Rétention : Documenté explicitement dans 8/10 des protocoles ; partiellement dans 2/10.
• Opérations inachevées : Rapportées de manière beaucoup moins cohérente. 6/10 des protocoles exposaient des shells, des navigateurs ou des services sans préciser si les processus descendants ou les effets différés étaient terminés, annulés ou vérifiés avant l'évaluation.
• Preuve de séparation : Seuls 3/10 des protocoles fournissaient une preuve explicite pour traiter les exécutions comme des observations séparées. Sept décrivaient des procédures de réinitialisation mais échouaient à énoncer pleinement la portée des ressources couvertes ou la manière dont la réussite de la restauration était vérifiée.
• Lacune : Aucun protocole n'a documenté de manière cohérente les périodes de temps sur lesquelles des effets pertinents pouvaient modifier le résultat.

Signification et affirmations

Le papier affirme que les pratiques d'évaluation actuelles confondent souvent la fin de l'interaction avec la fin de la chaîne causale de la tâche. Sa signification réside dans :

1. Correction de la validité des métriques : Il démontre que sans vérifier la finalité et la séparation, les métriques agrégées (comme les taux de réussite) peuvent mesurer un mélange de performance de la tâche et d'artefacts environnementaux.
2. Affinement des limites d'évaluation : Il soutient que la « limite d'évaluation » n'est pas un moment unique, mais un ensemble de décisions concernant quand s'arrêter, quand évaluer et comment séparer les exécutions.
3. Proposition d'une norme de rapport : En introduisant le « registre des effets ouverts », le papier fournit un mécanisme concret permettant aux évaluateurs de rapporter de manière transparente les états non résolus et les ressources persistantes, permettant ainsi aux lecteurs d'évaluer la validité des résultats revendiqués.

L'auteur maintient une position modeste, notant que sa revue de documentation est limitée à dix protocoles et que ses décomptes expérimentaux reflètent des conditions construites plutôt que la fréquence de ces problèmes dans le paysage plus large des benchmarks publiés. L'argument central est qu'une étiquette finale n'est justifiée que lorsque tout ce qui pourrait encore modifier le résultat revendiqué est résolu, limité ou conservé comme une incertitude.