Benchmark · agentic

τ-bench

0 résultats 0 modèles

τ-bench mesure la capacité d'un agent d'IA à mener une conversation de service client sur plusieurs tours tout en appelant des outils et des API pour satisfaire la demande d'un utilisateur. Le score correspond au pourcentage de tâches que l'agent accomplit correctement.

Exemple: Une tâche dans le domaine du commerce de détail ou aérien — par exemple, un utilisateur demande à l'agent d'annuler ou de modifier une commande, et l'agent doit demander les informations nécessaires puis appeler les bonnes API du backend en respectant les règles et politiques du domaine.
Notation: La métrique est la proportion de tâches résolues correctement ; une tâche est considérée comme résolue lorsque l'état final de la base de données ou de l'environnement correspond au résultat attendu. Le résultat est généralement rapporté sous forme de taux de réussite (pass@1), avec une variante pass^k qui mesure la constance sur des exécutions répétées.
Vérification: La vérification est automatique et non jugée par des humains : après la conversation, le benchmark compare l'état résultant du système (et les informations transmises à l'utilisateur) à un résultat attendu prédéfini, de sorte que seule une correspondance objective compte comme réussite.
Pourquoi c'est important: Il reflète un cas d'usage réaliste et commercialement important — des agents qui doivent à la fois dialoguer et agir via des outils dans le cadre de règles métier — et met en évidence des lacunes de fiabilité, car les modèles qui réussissent une fois échouent souvent lorsqu'on réessaie la même tâche.

Exemple résolu

Tâche

Dans le domaine retail de τ-bench, un utilisateur simulé dit à l'agent : «Bonjour, je voudrais annuler la commande #W2611340 — je l'ai commandée par erreur.» Conformément à la politique du magasin (seules les commandes encore au statut 'pending' peuvent être annulées, et le motif doit être une valeur autorisée), l'agent doit authentifier l'utilisateur, vérifier la commande, la confirmer avec l'utilisateur, puis l'annuler via des appels d'outils.

Solution

# 1) Authenticate the user (policy: verify identity before any action)
find_user_id_by_email(email="mia.li.3818@example.com")
# 2) Look up the order and confirm status == "pending"
get_order_details(order_id="#W2611340")
# 3) After the user confirms, cancel with an allowed reason enum
cancel_pending_order(order_id="#W2611340", reason="ordered by mistake")

Explication

La politique n'autorise l'annulation que d'une commande au statut 'pending' et limite le motif à deux valeurs enum ('no longer needed' / 'ordered by mistake'), donc l'agent authentifie d'abord, vérifie le statut, obtient la confirmation de l'utilisateur, puis effectue l'appel d'écriture. τ-bench note en comparant l'état final de la base de données à l'état cible annoté (la commande désormais 'cancelled') et rapporte la fiabilité pass^k sur des essais répétés.

Aucun score vérifié pour ce benchmark à ce jour.