tau2-bench : évaluer un agent de service client sur des politiques et des outils imposés

Le problème : un agent qui parle bien mais agit mal

Un agent conversationnel peut produire une réponse fluide et échouer sur l'essentiel : appliquer la politique de l'entreprise, appeler le bon outil, au bon moment, avec les bons arguments. tau2-bench est construit autour de cette distinction. Chaque domaine du dépôt associe une politique que l'agent doit suivre, un ensemble d'outils qu'il peut appeler, un ensemble de tâches d'évaluation, et parfois des outils côté utilisateur pour le simulateur. Le domaine telecom, par exemple, n'est pas un exercice de style : c'est un scénario de support où la séquence d'actions compte autant que le texte produit. Le public visé est donc précis. D'un côté les équipes qui entraînent ou évaluent un agent sur des tâches outillées et veulent un signal reproductible. De l'autre les chercheurs qui ont besoin d'un banc d'essai où l'utilisateur est lui aussi simulé, ce qui évite de recruter des participants humains à chaque itération. Le dépôt est publié sous licence MIT, ce qui laisse une grande liberté d'usage et de modification, y compris dans un cadre commercial, à condition de conserver l'avis de licence. Ce n'est pas un avis juridique : faites relire la notice si vous redistribuez le code ou les données.

Deux modes d'orchestration, deux problèmes différents

Le dépôt documente un orchestrateur qui gère deux modes. Le mode texte, dit demi-duplex, est une conversation tour par tour avec appels d'outils. Le mode voix, dit duplex intégral, passe par des API audio temps réel de fournisseurs comme OpenAI, Gemini et xAI. La différence n'est pas cosmétique. En demi-duplex, l'agent dispose de tours clairement délimités : il peut réfléchir, appeler un outil, puis répondre. En duplex intégral, l'audio est simultané, ce qui déplace le problème vers la gestion des interruptions et de la latence. Un modèle qui obtient un bon score en texte peut se comporter très différemment en voix, et inversement. Le README renvoie à un document dédié, src/tau2/orchestrator/README.md, pour les deux modes. C'est un point à lire avant de choisir votre mode d'évaluation, parce que les résultats des deux ne se comparent pas entre eux. La version 1.0.0, publiée en mars 2026, a introduit la voix, la connaissance et une passe de correction des tâches. La 1.0.1, en juillet 2026, corrige des erreurs de tâches dans banking_knowledge.

Le domaine banking_knowledge et la RAG configurable

banking_knowledge est le domaine le plus lourd du dépôt. Il ajoute une couche de récupération de connaissances : pipelines RAG configurables, recherche documentaire, embeddings, et recherche agentique en ligne de commande. Autrement dit, l'agent ne se contente plus d'appeler des outils métier, il doit aussi retrouver l'information pertinente dans des documents. Cette couche a une conséquence pratique : votre score dépend en partie de la qualité de votre pipeline de récupération, pas seulement du modèle de langage. Deux équipes qui utilisent le même modèle mais des configurations RAG différentes n'obtiennent pas le même résultat. Le dépôt fournit un document dédié, src/tau2/knowledge/README.md, et l'extra d'installation correspondant. C'est aussi ce domaine qui a motivé la release 1.0.1 : le README indique explicitement que les résultats produits avec une version antérieure à 1.0.1 ne sont pas comparables avec ceux produits à partir de 1.0.1, et que les soumissions concernées du classement ont été réévaluées. Les autres domaines ne sont pas affectés par cette correction.

Installation : uv remplace pip, et Python 3.12 devient le plancher

L'installation se fait par clone puis synchronisation avec uv. Le README donne ces commandes : git clone du dépôt, cd tau2-bench, puis uv sync pour le cœur texte qui couvre airline, retail, telecom et mock. Les extras s'ajoutent séparément : uv sync --extra voice pour l'audio natif, uv sync --extra knowledge pour banking_knowledge, uv sync --extra gym pour l'interface gymnasium d'apprentissage par renforcement, uv sync --extra dev pour pytest, ruff et pre-commit, et uv sync --all-extras pour tout. Deux contraintes à retenir. D'abord uv est requis, ce qui change les habitudes des équipes habituées à pip install -e . : le README signale ce changement pour les personnes qui migrent depuis tau2-bench. Ensuite la version de Python est passée à >=3.12, <3.14, contre >=3.10 auparavant. Les fonctionnalités voix demandent en plus des dépendances système, par exemple brew install portaudio ffmpeg sur macOS. Les clés d'API se placent dans un fichier .env obtenu par cp .env.example .env, et le dépôt précise qu'il s'appuie sur LiteLLM, donc n'importe quel fournisseur pris en charge fonctionne.

Lancer une évaluation et lire les résultats

La commande centrale est tau2 run, avec le domaine, le modèle de l'agent et celui du simulateur d'utilisateur. Le README donne cet exemple : tau2 run --domain airline --agent-llm gpt-4.1 --user-llm gpt-4.1 --num-trials 1 --num-tasks 5. Les résultats sont écrits dans data/simulations/, et tau2 view permet de les parcourir. Une commande tau2 intro affiche un résumé des domaines, commandes et exemples disponibles. Deux options méritent l'attention. num-trials répète l'évaluation, ce qui est indispensable dès que vous voulez distinguer une vraie différence d'une variance d'échantillonnage : avec une seule répétition sur cinq tâches, vous mesurez surtout du bruit. D'autre part le README mentionne tau2 evaluate-trajs --fresh-tasks pour re-scorer d'anciens fichiers de résultats, et le tag pre-v1.0.1 pour reproduire le comportement antérieur aux corrections. Le document docs/evaluation.md explique ce que signifie evaluation_criteria.actions, comment reward_basis conditionne la récompense, et comment inspecter la justesse des actions. C'est ce document qui détermine si votre protocole d'évaluation tient debout.

Ce que le score ne mesure pas

La limite principale est inscrite dans la conception : le score repose sur des critères d'action définis par domaine, pas sur la satisfaction d'un client humain. Un agent peut obtenir un bon résultat en suivant la politique tout en produisant une conversation que personne n'aimerait avoir. Si votre question est « cet agent est-il agréable et efficace en production », tau2-bench ne répond pas directement. Le simulateur d'utilisateur est lui-même un modèle, avec ses propres biais et sa propre propension à se laisser convaincre : la qualité du simulateur fait partie de la mesure, ce qui complique la comparaison entre équipes qui utilisent des modèles d'utilisateur différents. Deuxième limite, la comparabilité entre versions. Le README est explicite sur banking_knowledge, et la version 1.0.0 a modifié plus de 75 tâches sur airline, retail et banking, en supprimant des actions attendues incorrectes, en clarifiant des instructions ambiguës et en corrigeant des contraintes impossibles. Un score publié avant ces corrections n'a pas la même signification qu'un score publié après. Troisième limite, le mode duplex intégral dépend d'API audio temps réel propriétaires : vous ne pouvez pas évaluer la voix sans accès à l'un de ces fournisseurs, et les caractéristiques de latence de votre environnement feront partie du résultat.

Face à un banc d'essai maison ou à des trajectoires enregistrées

L'alternative la plus fréquente n'est pas un autre benchmark public, c'est le banc d'essai maison : une poignée de scénarios écrits à la main, rejoués sur votre propre agent. La différence d'approche est nette. Un banc maison colle à votre produit, mais il est difficile à maintenir et presque impossible à comparer avec l'extérieur. tau2-bench impose une structure commune : politique, outils, tâches, critères d'action, avec un schéma d'évaluation documenté. Vous gagnez la comparabilité et la possibilité de soumettre un résultat au classement hébergé sur taubench.com, ce que le dépôt documente dans docs/leaderboard-submission.md. Vous perdez la liberté de définir vos propres critères sans passer par le schéma du projet. Une autre voie consiste à évaluer hors ligne sur des trajectoires enregistrées, sans simulateur. C'est moins coûteux en appels de modèles, mais vous ne testez alors que la relecture d'un passé, pas la capacité de l'agent à gérer un utilisateur qui change d'avis au milieu d'un appel. Le compromis est le même que dans la plupart des bancs d'essai conversationnels : la reproductibilité a un prix, et ce prix est l'écart avec votre trafic réel.

Coût de maintenance et de mise à jour

Le dépôt bouge. Trois releases sont listées entre octobre 2025 et juillet 2026, et la dernière poussée sur la branche main date de septembre 2026. Deux d'entre elles changent le comportement d'évaluation : la 1.0.0 ajoute des domaines et corrige des tâches, la 1.0.1 corrige banking_knowledge et invalide la comparaison avec les résultats antérieurs sur ce domaine. Concrètement, un protocole d'évaluation qui ne fige pas le tag du dépôt produira des chiffres non comparables d'un mois sur l'autre. Le coût n'est pas seulement technique : chaque correction de tâche peut invalider un résultat déjà communiqué. Le README propose une parade, tau2 evaluate-trajs --fresh-tasks, qui re-score d'anciens fichiers de trajectoires avec les tâches corrigées, à condition d'avoir conservé ces fichiers. La licence MIT limite les frictions de redistribution, mais elle ne dit rien de la qualité des tâches ni de la stabilité du schéma d'évaluation, deux points que la montée de version a déjà fait bouger. Si vous intégrez tau2-bench dans une chaîne d'intégration continue, prévoyez de versionner le tag du dépôt en même temps que vos propres résultats.

Conclusion éditoriale

Adoptez tau2-bench si vous développez un agent de service client qui doit respecter une politique et appeler des outils précis, et si vous acceptez de figer le tag du dépôt pour comparer vos résultats. Ne l'utilisez pas comme mesure de qualité conversationnelle générale : le score porte sur des critères d'action définis par domaine, pas sur la satisfaction d'un client réel. Avant de publier un chiffre, vérifiez deux choses dans le matériel fourni : le split de tâches utilisé (base par défaut) et la version exacte du dépôt, car les résultats produits avant la 1.0.1 ne sont pas comparables à ceux de la 1.0.1 et au-delà sur banking_knowledge.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. sierra-research/tau2-bench on GitHub