τ²-bench : mesurer le coût du double contrôle dans les agents IA conversationnels

J'ai suivi la lignée τ-bench au cours des dernières semaines et τ²-bench (arXiv:2506.07982) est l'article que j'attendais de voir : il pose enfin la question de savoir ce qui se passe lorsque l'utilisateur n'est pas un simple fournisseur passif d'informations, mais un participant actif disposant de son propre ensemble d'outils. Pour quiconque construit un agent de comptabilité conversationnel, ce fossé a toujours été flagrant.

L'article

Victor Barres, Honghua Dong, Soham Ray, Xujie Si et Karthik Narasimhan (Sierra AI et Université de Toronto) présentent τ²-bench comme une extension directe du τ-bench original. Le constat principal est que les évaluations précédentes pour les agents IA conversationnels sont à contrôle unique : seul l'agent peut invoquer des outils ; l'utilisateur est confiné aux messages en langage naturel. Le support technique en conditions réelles brise cette hypothèse. Lorsqu'un agent du service client vous demande de « désactiver le mode avion », vous effectuez un appel d'outil sur votre propre appareil, et non une simple narration de vos préférences.

Les auteurs modélisent cela comme un processus de décision markovien partiellement observable décentralisé (Dec-POMDP), où l'agent et le simulateur d'utilisateur disposent d'espaces d'action distincts (appels de fonctions et messages) sur un état du monde partagé et dynamique. Le côté agent ressemble à un CRM standard : il peut consulter les dossiers clients, activer l'itinérance ou remplacer une carte SIM. Le côté utilisateur est un téléphone simulé avec des outils de lecture (get_status_bar, get_sim_status) et des outils d'écriture (toggle_airplane_mode, toggle_data, reseat_sim_card). L'évaluation est livrée avec un nouveau domaine de télécommunications (114 tâches échantillonnées à partir de 2 285 variantes générées par programme) aux côtés des domaines vérifiés de la vente au détail (115 tâches) et de l'aérien (50 tâches) du τ-bench original.

Idées clés

• Formalisme du double contrôle : La représentation Dec-POMDP sépare clairement ce que chaque acteur observe et quels outils chacun peut appeler. C'est plus rigoureux que l'approche ad hoc de l'« utilisateur avec un téléphone » que l'on pourrait greffer sur un harnais mono-agent existant.
• Générateur de tâches compositionnel : Les tâches sont assemblées à partir de 15 groupes de sous-tâches atomiques couvrant trois types d'intentions (service_issue, mobile_data_issue, mms_issue) avec une mise à l'échelle explicite de la difficulté par le nombre d'étapes de résolution requises.
• Performance sur les télécoms (pass¹) : GPT-4.1 n'atteint que 34 % ; o4-mini 42 % ; Claude 3.7 Sonnet 49 % ; GPT-4.1-mini environ 50 %. Tous les modèles obtiennent des scores nettement inférieurs ici par rapport à la vente au détail ou à l'aérien.
• Pénalité du double contrôle : Une ablation compare le mode Par défaut (l'utilisateur a des outils) au mode Sans utilisateur (l'agent contrôle lui-même chaque outil). GPT-4.1 chute de 18 points de pourcentage ; o4-mini chute de 25 points. Cet écart représente le coût de la coordination avec un utilisateur actif, dissocié de la pure difficulté de raisonnement.
• Écart par rapport au plan oracle : Même lorsque l'agent reçoit la séquence d'actions complète à l'avance, la performance n'atteint pas 100 %, ce qui nous indique que l'exécution et la coordination avec l'utilisateur ajoutent des erreurs en plus de la planification.
• Les outils utilisateur structurés réduisent considérablement le bruit du simulateur : Le simulateur d'utilisateur télécom ne produit que 16 % d'erreurs (6 % critiques), contre 40 % d'erreurs (12 % critiques) pour la vente au détail dans le τ-bench original. L'amélioration provient du remplacement des invites utilisateur en langage naturel par une interface d'outils étroitement contrainte qui suit l'état de l'appareil.

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

Le cadrage Dec-POMDP est l'une des formulations de problème les plus soignées que j'ai vues dans l'évaluation des agents. Le générateur de tâches programmatique est véritablement utile : il fournit des tâches prouvables et une complexité explicitement contrôlable, contrairement aux collections de tâches artisanales qui polluent la plupart des bancs d'essai. Les chiffres de fiabilité du simulateur utilisateur sont convaincants — réduire les erreurs critiques de 12 % à 6 % est crucial lorsque l'on cherche à faire confiance à son signal d'évaluation.

Cependant, le domaine des télécommunications est étroit. Quatre clients, neuf lignes, cinq forfaits : c'est un laboratoire contrôlé, pas un système d'entreprise. Les chiffres pass¹ pour gpt-4.1-mini et Claude 3.7 Sonnet (~50 %) semblent étonnamment élevés compte tenu de la difficulté annoncée par les auteurs, ce qui me fait me demander si 114 tâches suffisent pour éviter que des séries chanceuses ne gonflent les scores. Les auteurs reconnaissent que leur ensemble de tâches est un sous-échantillon. Je trouve également l'analyse des personas utilisateurs superficielle : l'article montre que le persona « Difficile » (retraité de 64 ans avec peu de confiance technique) est plus difficile que le persona « Facile », ce qui n'est pas surprenant. Ce que j'aimerais voir, c'est si le type d'échec de coordination diffère — un persona plus difficile produit-il plus d'erreurs de raisonnement ou plus d'erreurs de communication ?

L'article n'explore pas non plus ce qui se passe lorsque le document de politique de l'agent est erroné ou incomplet, ce qui est un scénario réaliste pour les déploiements en production. Chaque résultat suppose que l'agent reçoit des politiques exactes.

Pourquoi cela est important pour l'IA financière

L'hypothèse de contrôle unique intégrée dans τ-bench, WorkArena et la plupart des évaluations de dialogue orientées tâches s'adapte mal au scénario réel du support Beancount. Un utilisateur demandant à un agent Beancount de corriger son grand livre ne se contente pas de raconter un problème — il peut simultanément modifier le fichier dans son éditeur de texte, exécuter bean-check ou télécharger un nouvel export CSV de sa banque. C'est un environnement à double contrôle exactement au sens de τ²-bench.

La chute de 18 à 25 points de pourcentage lors du passage du mode Sans utilisateur au mode Par défaut est le chiffre auquel je reviendrai sans cesse. Cela suggère que même si nous construisions un agent Beancount presque parfait pour la manipulation autonome de grands livres, l'introduction d'un utilisateur actif partageant l'accès en écriture réduirait les taux de réussite d'environ un quart. Les conceptions d'écriture en retour sécurisées que nous avons envisagées (GuardAgent, ShieldAgent, MCP vérifiable) ont été conçues pour des environnements à contrôle unique ; elles doivent être repensées si l'utilisateur est également un agent appelant des outils sur le même environnement.

L'amélioration de la fiabilité du simulateur d'utilisateur est également directement exploitable. Si je veux effectuer des évaluations hors ligne d'un agent Beancount sans recruter de comptables humains, coupler étroitement l'utilisateur simulé à un environnement de grand livre déterministe — plutôt que de s'appuyer sur un jeu de rôle LLM de forme libre — est la bonne décision d'ingénierie.

Que lire ensuite

• τ-bench (Yao et al., arXiv:2406.12045) : La base de référence que cet article étend — il vaut la peine de lire la construction originale des tâches et la conception de la métrique pass^k avant d'interpréter les résultats de τ²-bench.
• ToolSandbox (Lu et al., arXiv:2408.04682) : Introduit des outils à état pour une évaluation fine des agents ; l'architecture la plus pertinente pour concevoir un banc d'essai Beancount à double contrôle.
• TheAgentCompany (Xu et al., arXiv:2412.14161) : 175 tâches au sein d'une entreprise logicielle simulée avec de réels outils internes ; l'évaluation de l'automatisation en entreprise la plus réaliste actuellement disponible et le prochain article sur ma liste de lecture.