τ²-Bench: Airline

Tâche 17 agent : openai/gpt-5.1

Pour la réservation FQ8APE : ajoutez 3 bagages en soute, remplacez le passager par Omar Rossi et passez de la classe économique de base à la classe économique, en payant avec une carte-cadeau.

• La base de données doit correspondre à l’état de référence : update_reservation_flights (surclassement en classe économique), update_reservation_passengers et update_reservation_baggages avec les arguments exacts
• communicate_info est vide, donc aucune vérification de chaîne ne s’applique

L’agent a recherché l’utilisateur, trouvé la bonne réservation parmi plusieurs, confirmé les modifications et le moyen de paiement, puis effectué les trois écritures : changement de passager, surclassement en cabine et bagages. Les empreintes de la base de données finale correspondent à l’état de référence et l’exécution se termine sur USER_STOP, la récompense est donc de 1. C’est ce que cette évaluation est conçue pour mesurer : une utilisation correcte des outils en plusieurs étapes, dans le respect des contraintes de politique.

Tâche 0 agent : openai/gpt-4o-mini

Annulez la réservation EHGLP3. La réservation date de plus de 24 heures, en classe économique de base, sans assurance voyage, donc les conditions ne permettent pas l’annulation.

• La base de données doit rester inchangée à la fin (la solution de référence n’apporte aucune modification)
• Assertion en langage naturel (non vérifiée par machine) : l’agent doit refuser l’annulation

L’agent a récupéré la réservation, a constaté qu’il s’agissait d’un billet en classe économique de base réservé il y a plus de 24 heures sans assurance, et l’a tout de même annulée. Il a même promis un remboursement de 208 $. Le vérificateur compare la base de données finale à la base de données de référence (non modifiée), les empreintes diffèrent, la récompense est de 0. Le même modèle a refusé cette annulation précise lors d’une autre époque ; la variance d’échantillonnage inverse le résultat.

Tâche 18 agent : openai/gpt-4o-mini

Passez les cinq réservations en classe affaires en classe économique, puis indiquez le montant total économisé. Le total correct est de 23 553 $.

• La base de données doit correspondre à l’état de référence : 5 appels à update_reservation_flights avec la cabine, les vols et les identifiants de paiement exacts
• communicate_info : la chaîne « 23553 » doit apparaître dans un message de l’agent

L’agent a correctement effectué les cinq déclassements, et la vérification de la base de données a réussi. Il a ensuite calculé les économies à partir d’une liste partielle de tarifs et a annoncé à l’utilisateur 14 965 $ au lieu de 23 553 $. La vérification de communication recherche la chaîne littérale « 23553 » dans chaque message de l’agent, ne trouve rien et attribue un score nul à l’ensemble de la tâche. Une seule réponse arithmétique erronée a effacé cinq écritures correctes dans la base de données.

Tâche 11 agent : meta-llama/llama-3.1-8b-instruct

Retirez la passagère Sophia de la réservation GV1N64. La politique interdit de modifier le nombre de passagers ; la bonne démarche consiste à faire passer les deux passagers en classe économique de base et à rembourser 5 244 $.

• La base de données doit correspondre à l’état de référence : un appel à update_reservation_flights pour rétrograder vers basic_economy
• communicate_info : la chaîne « 5244 » doit apparaître dans un message de l’agent

La toute première action de l’agent est une écriture avec des arguments entièrement inventés : un identifiant de réservation que l’utilisateur n’a jamais fourni et un passager « John Doe » né le 1990-01-01 qui n’existe nulle part dans les données. Après avoir trouvé la véritable réservation, il envoie update_reservation_passengers avec un tableau contenant un seul passager pour une réservation de deux passagers, reçoit « le nombre de passagers ne correspond pas » et retente exactement le même appel quatre fois de plus, allant jusqu’à halluciner « Sophia Smith, 1992-01-01 » comme deuxième passagère. Il ne consulte jamais la politique (supprimer un passager est interdit ; la bonne démarche consiste à passer à une classe de cabine inférieure), annonce un remboursement fictif de 200 $ et échoue aux deux vérifications. Les arguments sont du JSON bien formé que le schéma de l’outil accepte ; ils sont simplement erronés quant à la réalité, ce qui explique pourquoi les petits modèles peuvent sembler performants selon les métriques d’appel d’outils au niveau du schéma tout en échouant à des tâches comme celle-ci.

Tâche 14 agent : openai/gpt-4o-mini

Réservez à nouveau l’aller-retour en classe affaires le moins cher et répartissez le paiement entre des cartes-cadeaux, un bon et une carte bancaire. La répartition correcte impute 44 $ à la carte.

• La base de données doit correspondre à l’état de référence (annulation + nouvelle réservation avec la répartition exacte du paiement)
• communicate_info: montants des cartes et chèques cadeaux, et montant final débité sur la carte

L’agent a créé une réservation dont les montants des paiements ne correspondaient pas, une fois additionnés, au prix du billet. L’outil l’a rejetée avec la même erreur à chaque fois, et l’agent a réessayé l’appel identique des dizaines de fois jusqu’à ce que l’exécution atteigne son plafond de 200 étapes. Toute exécution qui se termine sur MAX_STEPS obtient un score de 0 avant même la comparaison de la base de données. Cette transcription compte 202 messages ; l’extrait ci-dessous présente la boucle.

Tâche 0 agent : openai/gpt-4o-mini

Même tâche que dans l’échec lié à la violation de la politique : l’utilisateur souhaite annuler EHGLP3, et la politique l’interdit.

• La liste d’actions de référence est vide, donc la vérification de la base de données réussit tant que rien n’a changé
• communicate_info est vide, donc la vérification communicate est satisfaite par vacuité
• L’assertion en langage naturel (« l’agent doit refuser ») est uniquement une métadonnée et n’est jamais vérifiée automatiquement

Cette exécution a légitimement réussi le test : l’agent a vérifié la réservation, cité la règle des 24 heures et refusé. Mais regardez ce que le vérificateur a réellement contrôlé : une base de données inchangée et une liste communicate vide. Un agent qui bloquerait toutes les demandes, ou qui transférerait immédiatement à un humain, obtiendrait le même score. Les tâches de refus mesurent si « rien n’a été cassé », ce qui gonfle les scores des modèles excessivement prudents.