Construire un harnais d'évaluation pour les tâches d'agent

Objectif

Décider si un changement de prompt, d'ensemble d'outils ou de modèle rend un agent meilleur ou pire sur les tâches pour lesquelles il est réellement utilisé, avec un chiffre comparable d'une exécution à l'autre plutôt qu'une impression tirée de quelques transcriptions.

Prérequis

Une liste de tâches avec un état final vérifiable par tâche (une ligne de base de données, un fichier, une valeur renvoyée) ; un environnement réinitialisable entre les exécutions (conteneur, base de données de montage, réponses HTTP enregistrées) ; un budget pour des exécutions répétées. τ-bench est un exemple documenté de cette forme : l'agent travaille avec des outils de domaine et des règles de politique face à un utilisateur simulé, et l'article évalue en comparant l'état de la base de données à la fin de la conversation avec un état-objectif annoté. Des frameworks comme Inspect (UK AI Security Institute) décrivent une évaluation comme des blocs de construction composables (jeux de données, agents, outils et évaluateurs) et fournissent un bac à sable pour le code de modèle non fiable et l'approbation des outils.

Étapes

1. Recueillir des tâches à partir de l'usage réel : sessions échouées, tickets de support, cas limites, pas seulement des succès faciles. Écrire chacune comme une entrée plus un oracle (état final attendu ou vérification déterministe), jamais comme une transcription attendue.
2. Figer l'environnement : verrouiller les versions d'outils, les données d'amorçage et les réponses externes enregistrées, afin qu'une exécution en échec puisse être rejouée avec des entrées identiques.
3. Noter l'état final en code. N'utiliser une grille d'évaluation notée par modèle que là où aucune vérification déterministe n'existe, et la calibrer contre un échantillon d'annotations humaines.
4. Exécuter chaque tâche k fois. L'article τ-bench propose pass^k, la probabilité que les k essais réussissent tous, à côté du pass@k habituel ; rapporter les deux, car l'écart entre eux traduit l'inconsistance de l'agent.
5. Consigner le coût, les étapes et les jetons par exécution avec le score, afin qu'une amélioration qui double le coût soit visible.
6. Conserver un ensemble mis de côté qui n'est jamais utilisé pendant l'ajustement des prompts ; rapporter séparément les résultats d'ajustement et les résultats mis de côté.
7. Stocker la configuration (modèle, version de prompt, ensemble d'outils, graine) avec chaque résultat et exécuter le harnais à chaque changement de prompt ou de modèle.

Résultat attendu

Un score par tâche et par exécution avec une bande de confiance, une liste des tâches qui basculent entre succès et échec d'un essai à l'autre, et un coût par tâche accomplie, le tout reproductible à partir de la configuration stockée.

Limites et base de vérification

L'article cité rapporte que les agents à appel de fonction de pointe de l'époque réussissaient moins de 50 % de ses tâches et étaient inconsistants (pass^8 sous 25 % dans son domaine de vente au détail) ; aucun chiffre n'est ici revendiqué pour d'autres agents ou tâches. La notation par modèle hérite des biais de l'évaluateur, les petits ensembles de tâches donnent des bandes de confiance larges, et le harnais ne mesure que ce que ses tâches couvrent.