Évaluation des agents avec un bot de voyage : résultats versus trajectoire, portes et pass^k

Les agents ne se contentent pas d’appeler des API. Ils raisonnent, choisissent des outils au fur et à mesure, élaborent des plans en plusieurs étapes et s’attaquent à des tâches ouvertes qui prenaient autrefois des heures de travail humain. Cependant, dès que l’un d’eux entre en production, une question gênante se pose : comment savoir s’il fonctionne ?

Ce n’est pas avec le prompt de démonstration que vous préférez aujourd’hui, mais la semaine prochaine, après que quelqu’un ait modifié les instructions du système, ajouté un outil, remplacé le modèle de base ou ajusté le prompt. Ce changement a-t-il résolu un problème tout en endommageant discrètement trois autres ?

Les logiciels ordinaires disposent de tests unitaires déterministes, tels que assert add(2, 2) == 4. Les agents sont probabilistes et peuvent emprunter des chemins différents pour atteindre le même objectif, ce qui rend insuffisante une simple comparaison de chaînes de caractères sur le texte final. Agent eval comble cette lacune.

L’analogie avec l’examen de mathématiques

Imaginez un enseignant qui note un examen en se contentant de jeter un coup d’œil au score final. Deux choses vont mal :

1. La devinette chanceuse. La méthode est absurde, deux erreurs arithmétiques s’annulent mutuellement, et la réponse apparaît par hasard.
2. L’erreur de dernière minute. La méthode est irréprochable et le théorème bien compris, mais une faute de frappe à la fin fait apparaître 41 à l’endroit où devrait se trouver 42.

Un bon enseignant évalue à la fois la méthode et la réponse. Il en va de même pour les agents, car un agent produit une série d’étapes : appels d’outils, recherches, objets formatés et décisions concernant l’état. Évaluer de manière équitable signifie mesurer deux choses :

• Résultat : le résultat business qu’il a obtenu.
• Trajectoire : le chemin qu’il a suivi pour y parvenir.

En termes simples, l’évaluation d’un agent consiste en une évaluation du résultat combinée à une évaluation de la trajectoire, mesurées lors de la même tentative au moyen d’une combinaison de vérifications par code fixe et d’évaluations subjectives flexibles.

Deux axes pour l’évaluation

Tout agent peut être examiné selon deux dimensions indépendantes.

Qu’est-ce qui est évalué ?

• Les vérifications de résultat s’assurent que le bon résultat final est obtenu, par exemple le vol correct, le tarif d’hôtel adéquat ou le bon enregistrement de réservation.
• Les vérifications de trajectoire vérifient que l’agent est parvenu à son but de manière fiable : les outils sont appelés dans un ordre logique, des paramètres valides sont transmis, et il n’y a pas de boucles infinies.

Comment est-il noté ?

• Les vérifications déterministes couvrent les faits ayant une réponse objective. Un prix est soit de 150 $, soit il ne l’est pas, et un outil a été appelé ou non. Les assertions de code simple gèrent ces cas.

Les vérifications basées sur le jugement couvrent tout ce qui nécessite un contexte, une intention ou des nuances. Le mot « budget » a-t-il été interprété comme « économie » ? L’hôtel choisi correspond-il bien à ce que l’utilisateur avait réellement en tête ? Un LLM agissant en tant qu’évaluateur neutre évalue ces éléments.

Un exemple concret : un agent de réservation de voyages

Prenons un agent qui gère les itinéraires. La demande : un vol pas cher, trois nuits d’hôtel à New York et un transfert depuis l’aéroport. Pour cela, il peut utiliser des outils tels que search_flights, search_hotels, book_flight, book_hotel et book_airport_transfer.

Métriques de trajectoire : elles analysent le journal d’exécution, l’ordre des appels, les arguments des outils et les traces de raisonnement. Questions typiques : a-t-il établi un plan avant d’agir ? Les recherches ont-elles été effectuées avant les réservations ? Les dates de l’hôtel correspondent-elles aux dates du vol ? A-t-il évité des appels redondants ?

Métriques de résultats : elles examinent les objets de réservation réellement créés par l’agent : le tarif, le prix par nuit, le transfert, la monnaie et les dates.

Les critères avant les moyennes

Une leçon souvent apprise à ses dépens : toutes les métriques ne doivent pas être intégrées dans une seule note moyenne. Imaginez un agent qui obtient 95 % de score global grâce à un raisonnement élégant et à un ordre parfait des outils, mais qui réserve le vol pour 1 500 $ au lieu de 150 $. En conditions réelles, ce n’est pas une performance de premier ordre : c’est un désastre en matière de facturation.

Afin d’empêcher que de bons scores en termes de raisonnement masquent des échecs cruciaux pour l’entreprise, l’évaluation peut se dérouler en deux étapes.

Étape 1 : les contrôles de filtrage. Des vérifications déterministes sont d’abord effectuées sur les champs critiques : prix, dates, monnaie, identifiants de facturation et déclencheurs de frais. Si l’un de ces contrôles échoue, toute la tentative échoue immédiatement. Aucun raisonnement solide ne peut y remédier.

Étape 2 : la grille de notation pondérée. Seules les tentatives qui réussissent tous les contrôles de filtrage reçoivent un score de qualité, calculé à partir des autres indicateurs tels que l’efficacité outil, la qualité du raisonnement, le respect du plan et la correspondance sémantique. La règle est simple : avoir réussi les contrôles de filtrage et obtenir un score pondéré égal ou supérieur au seuil, disons 0,85, signifie réussite.

Diagnostic des échecs à l’aide d’une matrice 2x2

Un simple taux de réussite de « 82 % » ne vous apporte aucune information utile pour le débogage. Vous devez savoir pourquoi les exécutions ont échoué, afin de décider s’il faut corriger la requête, les outils ou l’ensemble des données. En représentant le résultat en fonction de la trajectoire, quatre quadrants apparaissent :

• Voie correcte, résultat correct : l’objectif atteint.
• Voie incorrecte, résultat correct : une chance, mais aussi un risque potentiel.
• Voie correcte, résultat incorrect : une erreur à la fin du processus, souvent due à un problème d’outil ou de données.
• Voie incorrecte, résultat incorrect : une défaillance fondamentale nécessitant un travail de révision.

Un suivi du début à la fin

C’est ainsi que le pipeline gérerait une tentative du agent de réservation. Il commence par la demande de l’utilisateur et le suivi de l’agent, qui débute par un plan (rechercher des vols, rechercher des hôtels, réserver les deux, ajouter le transfert), puis enregistre chaque réflexion et chaque appel d’outil dans l’ordre.

// Step 1: Upfront Plan Formulation
Thought: "I need to book budget travel to NYC for 3 days. Plan: 1) Search economy flights, 2) Search budget hotels in NYC, 3) Book flight, 4) Book hotel for matching dates, 5) Book airport transfer."

// Step 2: Tool Call - search_flights
→ call: search_flights({ origin: "SFO", destination: "JFK", cabin_class: "economy", date: "2026-10-10" })
← return:
[
  {
    flight_id: "fl_eco_9921",
    airline: "BudgetAir",
    price: 150.00
  }
]

// Step 3: Tool Call - search_hotels
→ call: search_hotels({ city: "New York", checkin: "2026-10-10", nights: 3, max_rate: 150 })
← return:
[
  {
    hotel_id: "ht_manhattan_pod",
    name: "Pod Midtown NYC",
    rate_per_night: 120.00
  }
]

// Step 4: Tool Call - book_flight
→ call: book_flight({ flight_id: "fl_eco_9921", passenger: "Chris Dias", price: 150.00 })
← return:
{
  booking_ref: "BK-FL-7701",
  status: "confirmed"
}

// Step 5: Tool Call - book_hotel
→ call: book_hotel({ hotel_id: "ht_manhattan_pod", nights: 3, rate_per_night: 120.00, guest: "Chris Dias" })
← return:
{
  reservation_id: "RSV-HT-8832",
  status: "confirmed"
}

// Step 6: Tool Call - book_airport_transfer
→ call: book_airport_transfer({ pickup: "JFK", dropoff: "Pod Midtown NYC", fee: 35.00 })
← return:
{
  ride_id: "TX-4402",
  status: "confirmed"
}

// Step 7: Final Synthesized Output Payload
Final Output:
{
  flight: {
    id: "fl_eco_9921",
    cabin: "economy",
    price: 150.00,
    status: "confirmed"
  },
  hotel: {
    id: "ht_manhattan_pod",
    nights: 3,
    rate_per_night: 120.00,
    status: "confirmed"
  },
  transfer: {
    service: "JFK Pickup Shuttle",
    fee: 35.00,
    status: "confirmed"
  },
  total_billed: 545.00
}

Ensuite, le système examine les champs critiques pour la mission : le prix du vol, le tarif de l’hôtel par nuit et le coût du transfert. Supposons que ces trois valeurs correspondent aux valeurs attendues, soit 150 $, 120 $ par nuit et 35 $. Le système valide la demande, et l’essai passe à l’étape 2.

À l’étape 2, chaque métrique restante reçoit une note comprise entre 0 et 1, qui est multipliée par son poids, les poids additionnant au total 1. À titre d’exemple, supposons que cinq métriques aient des poids de 0,20, 0,20, 0,15, 0,15 et 0,30, et des notes de 1,0, 1,0, 0,8, 1,0 et 0,95 respectivement. La somme pondérée est de 0,20 + 0,20 + 0,12 + 0,15 + 0,285, soit 0,955. Compte tenu du seuil de 0,85 défini avant le lancement, cela correspond à une validation.

Le verdict enregistre alors trois éléments : la demande a été validée, la note pondérée dépasse le seuil, et la matrice de diagnostic place ce lancement dans la catégorie « bon parcours, bon résultat ».

Mesurer la variance avec pass@k et pass^k

Un seul essai ne permet pas de connaître l’ensemble de la réalité, car les agents sont non déterministes. En exécutant la même requête avec les mêmes outils dix minutes plus tard, le modèle peut d’abord rechercher des hôtels, formater un argument différemment ou suivre une autre logique de raisonnement. Un test qui a réussi aujourd’hui peut échouer demain avec les mêmes données d’entrée.

Le document technique d’Anthropic sur l’évaluation des agents décrit deux statistiques permettant de maîtriser cette variabilité : pass@k et pass^k.

pass@k : capacité

Ici, la question est de savoir si au moins une des k tentatives distinctes aboutit à un succès. À mesure que k augmente, la note s’élève, car plus d’essais augmentent les chances de réussite. Cette métrique est devenue populaire grâce aux travaux d’OpenAI sur HumanEval en matière de génération de code, où un système produit plusieurs programmes candidats et vérifie s’il y en a qui réussissent les tests unitaires.

Cela convient aux configurations avec intervention humaine et aux systèmes dotés de validateurs automatisés : trois itinéraires provisoires à choisir pour un gestionnaire de voyages, ou cinq requêtes SQL candidates dont un moteur sélectionne la première valide.

pass^k : cohérence

C’est la probabilité que l’agent réussisse à chaque tentative sur k essais, soit le taux par essai p élevé à la puissance k. À mesure que k augmente, ce score diminue rapidement. Supposons que l’agent réussisse 75 % des essais individuels :

• une tentative : 75,0 %,
• trois tentatives consécutives : environ 42,2 %,
• cinq tentatives consécutives : environ 23,7 %,
• dix tentatives consécutives : environ 5,6 %.

C’est la norme pour une utilisation en production autonome et critique. Lorsque l’agent de réservation est connecté aux cartes de paiement et aux API des fournisseurs, les utilisateurs ne se soucient pas du fait qu’il puisse réussir une fois sur cinq essais. Ils ont besoin qu’il fonctionne de manière fiable à chaque fois.

Pourquoi ce choix est important

Lorsque k vaut 1, les deux métriques sont identiques et égales au taux de succès de base. À partir de k égal à 10, elles donnent des résultats opposés : pass@k tend vers 100 %, car suffisamment d’essais finiront par aboutir à un succès, tandis que pass^k tend vers zéro, car dix exécutions parfaites sans aucune hallucination ni panne d’outil sont difficiles à atteindre. Choisir la métrique qui correspond aux promesses de votre produit permet de distinguer les indicateurs superficiels des véritables critères de fiabilité.

Leçons pratiques

1. N’essayez pas uniquement la réponse finale. Un agent qui parvient à la bonne réponse grâce à un raisonnement erroné représente un risque en environnement de production.
2. Mélangez code et juges basés sur des LLM. Utilisez du code déterministe pour les prix, les identifiants et les vérifications de présence, ainsi que des juges basés sur des LLM pour évaluer la qualité du raisonnement, le respect du plan et la correspondance avec l’intention.
3. Vérifiez ce qui ne doit absolument pas être erroné. Un raisonnement élégant ne devrait pas permettre d’atténuer un prix incorrect, une monnaie défectueuse ou une date fausse dans la moyenne.
4. Traitez les évaluations comme des tests de qualité continue. Exécutez l’ensemble de tests chaque fois qu’un prompt ou un modèle change, afin que les dérives soient détectées avant que les utilisateurs ne les remarquent.

Les agents fiables ne proviennent pas de l’espoir que le modèle se comporte bien aujourd’hui. Ils proviennent d’un système qui vérifie, chaque jour, qu’il le fait bien.