τ-bench : Mesurer la fiabilité des agents IA dans des domaines réels d'utilisation d'outils

Après avoir passé des semaines à retracer la lignée du raisonnement sur les tableaux et du text-to-SQL, j'ai voulu prendre du recul et poser une question différente : dans quelle mesure les agents IA actuels sont-ils réellement performants une fois placés dans une boucle opérationnelle en direct avec un utilisateur réel ? τ-bench apporte la réponse la plus honnête que j'aie vue, et les chiffres sont saisissants.

L'article

Yao, Shinn, Razavi et Narasimhan — tous de Princeton et Sierra Research — ont publié τ-bench (arXiv:2406.12045, juin 2024) pour combler une lacune évidente avec le recul : la plupart des benchmarks d'agents confient une tâche au modèle et évaluent sa réponse finale de manière isolée. Les déploiements réels ne ressemblent pas à cela. Un agent de service client est interrompu, on lui pose des questions de suivi, on lui transmet des informations contradictoires, et on attend de lui qu'il applique la politique commerciale tout au long d'une conversation ouverte avant d'effectuer tout changement dans la base de données.

τ-bench enveloppe deux domaines de service client du monde réel — la vente au détail et l'aérien — dans un simulateur où un modèle de langage joue l'utilisateur et un autre joue l'agent. L'agent a accès à des API spécifiques au domaine (annuler une commande, changer un siège, appliquer un coupon) et à un document de politique écrite spécifiant quelles actions sont autorisées sous quelles conditions. L'évaluation ne note pas les étapes intermédiaires : elle compare l'état final de la base de données par rapport à un état cible annoté. Les auteurs introduisent également pass^k, une métrique de fiabilité qui demande quelle fraction des essais un agent réussit de manière cohérente sur k tentatives indépendantes pour la même tâche.

Idées clés

• pass^k comme métrique honnête : un score pass@1 unique est trop bruité. pass^k expose la probabilité qu'un agent réussisse sur chacune des k exécutions de la même tâche — un indicateur de la confiance qu'on pourrait lui accorder en production.
• La chute de cohérence : GPT-4o dans le commerce de détail obtient 0,604 au pass@1 mais tombe à 0,383 au pass@4. Cela signifie que sur environ 60 % des tâches, il échoue au moins une fois sur quatre tentatives — ce qui n'est guère un agent sûr pour la production.
• L'aérien est plus difficile que le détail : le pass@1 de GPT-4o chute de 0,604 (détail) à 0,420 (aérien). Claude 3.5 Sonnet (version d'octobre 2024) fait mieux — 0,692 (détail) / 0,460 (aérien) au pass@1 — mais son pass@4 n'atteint encore que 0,462 et 0,225 respectivement.
• L'appel de fonction surpasse ReAct : la variante de l'agent GPT-4o utilisant l'appel de fonction (pass@1 = 0,420 dans l'aérien) surpasse à la fois Act (0,365) et ReAct (0,325) sur le même moteur, ce qui suggère que les API d'outils structurés réduisent les échecs induits par le format.
• La simulation d'utilisateur est une variable : les auteurs utilisent un modèle de langage pour simuler l'utilisateur, ce qui introduit sa propre variance. Un simulateur d'utilisateur plus faible peut gonfler ou dégonfler les scores de l'agent selon la fidélité avec laquelle il représente un comportement d'utilisateur adverse.
• L'évaluation par l'état de la base de données évite les jeux de crédits partiels : comparer l'état final plutôt que les étapes du dialogue signifie qu'un agent qui prend une action correcte puis l'annule par inadvertance ne reçoit aucun crédit — ce qui est la bonne approche pour un système d'écriture.

Ce qui tient la route — et ce qui ne la tient pas

Le cadrage pass^k est véritablement utile et je m'attends à ce qu'il survive à ce benchmark spécifique. La décision d'évaluer sur l'état de la base de données plutôt que sur la similitude au niveau des jetons (tokens) est correcte — elle mesure directement si l'agent a accompli la tâche, et non s'il a dit les bonnes choses.

Les domaines, cependant, sont étroits par conception. Le commerce de détail et l'aérien sont procéduralement propres : les documents de politique sont finis et écrits pour le benchmark, les API sont petites et bien spécifiées, et le simulateur d'utilisateur est coopératif par défaut. Dans le monde réel, les documents de politique sont ambigus ; les vrais utilisateurs mentent, se souviennent mal et contestent les refus. Les auteurs du benchmark le reconnaissent — l'existence même de τ²-bench (arXiv:2506.07982) en tant que suite, qui s'étend à un modèle Dec-POMDP à double contrôle où l'utilisateur manipule également l'état de l'environnement, est un aveu que l'évaluation à contrôle unique sous-estime la difficulté.

Il y a aussi la question de ce que pass^k mesure réellement. Si la simulation d'utilisateur est elle-même stochastique, la variance sur k essais mélange l'incohérence de l'agent avec celle du simulateur. L'article le note mais ne sépare pas complètement les deux sources de variance. Pour des applications critiques en matière de sécurité, on voudrait pouvoir attribuer les échecs — l'agent ignore-t-il la politique, interprète-t-il mal l'intention de l'utilisateur, ou choisit-il simplement le mauvais format d'appel d'outil ?

Le classement sur llm-stats.com montre maintenant des modèles comme Step-3.5-Flash à 0,882, ce qui ressemblerait à un progrès spectaculaire si l'on ne remarquait pas que la configuration de l'évaluation a probablement dérivé : les nouvelles entrées semblent être notées sous différentes versions de simulateurs d'utilisateurs et possiblement différentes répartitions de tâches. La comparaison entre entrées sur des benchmarks en évolution est toujours suspecte.

Pourquoi c'est important pour l'IA financière

L'agent d'écriture Beancount que j'ai en tête est structurellement identique aux agents évalués par τ-bench : il dispose d'outils spécifiques au domaine (ajouter une transaction, corriger un solde, recatégoriser une écriture), de contraintes de politique (ne pas modifier les périodes clôturées, ne pas créer de soldes négatifs, suivre le plan comptable), et d'un utilisateur qui donne des instructions en langage naturel au cours d'une conversation pouvant s'étendre sur plusieurs tours.

Le résultat pass^k est le point le plus exploitable pour nous. Si un modèle de pointe comme Claude 3.5 Sonnet n'atteint un pass@4 que de 0,462 dans le commerce de détail — un domaine relativement indulgent — nous devrions nous attendre à une cohérence similaire ou pire sur l'écriture dans un grand livre, où les erreurs se cumulent à travers les transactions et où les violations de politique peuvent ne pas être immédiatement visibles. Concevoir pour une cohérence sur k essais dès le départ — et pas seulement optimiser le pass@1 — change l'architecture : cela plaide pour une utilisation conservatrice des outils (demander avant d'écrire, pas après), des étapes explicites de vérification de la politique avant tout appel d'API, et un agent vérificateur séparé qui audite le diff de base de données proposé avant qu'il ne soit validé (commit).

La méthodologie d'évaluation par l'état de la base de données est également directement transposable. Le format de fichier structuré de Beancount permet de comparer facilement l'état attendu du grand livre avec l'état réel après une session d'écriture, nous donnant le même type de signal d'évaluation objectif que celui utilisé par τ-bench.

Lectures complémentaires

• τ²-bench (arXiv:2506.07982) : la suite qui s'étend aux environnements à double contrôle où les utilisateurs invoquent également des outils ; directement pertinent si nous modélisons l'utilisateur comme un participant actif aux corrections du grand livre plutôt que comme un demandeur passif.
• AgentEval / GAIA (arXiv:2311.12983) : le benchmark GAIA évalue les assistants IA généraux sur des tâches du monde réel nécessitant la navigation web et l'utilisation d'outils ; un complément utile à l'approche par domaine de τ-bench.
• WorkArena (arXiv:2403.07718) : évalue les agents sur des tâches réelles de logiciels d'entreprise dans ServiceNow ; le domaine est plus proche des flux de travail comptables que le commerce de détail ou l'aérien et mérite d'être lu pour les leçons sur la conception des tâches.