Métriques des agents IA : réussite et couverture

Choisissez l’unité avant de calculer un taux

Une trace est une interaction enregistrée. Un résultat de test évalue un scénario sur une exécution. Une assertion vérifie une attente dans ce test. Une trace peut correspondre à plusieurs scénarios, et un test peut contenir plusieurs assertions. Ces décomptes ne sont pas interchangeables.

Les calculs ci-dessous sont des exemples synthétiques pour votre rapport d’évaluation, pas des résultats mesurés dans Mibo ni la promesse que chaque métrique existe sous forme de widget. Gardez les résultats comportementaux, l’applicabilité et la qualité des preuves dans des colonnes distinctes.

Calculez le taux de réussite des assertions sans compter les vérifications ignorées comme des réussites

Supposons qu’un rapport contienne 50 enregistrements d’assertions : 15 réussites, 5 échecs et 30 vérifications ignorées, car une dépendance a empêché leur évaluation. La population évaluée contient 20 assertions.

• Taux de réussite : 15 / (15 + 5) = 75 %.
• Taux d’échec : 5 / (15 + 5) = 25 %.
• Vérifications ignorées : 30 / 50 = 60 % des enregistrements. Recherchez pourquoi ces vérifications n’ont jamais été évaluées.

Présenter 5 / 50 = 10 % comme taux d’échec diluerait les échecs dans les vérifications non évaluées. Indiquez « 15 réussites, 5 échecs, 30 vérifications ignorées » à côté du score. Une vérification dépendante ignorée diffère aussi d’un scénario non applicable.

Le score d’exécution de Mibo divise les assertions réussies par les assertions pouvant être notées et exclut celles ignorées en raison d’une dépendance. Sa métrique de qualité agrégée calcule la moyenne des scores enregistrés. Ces agrégations diffèrent : un résultat de 1/1 et un autre de 1/9 donnent une moyenne de 55,6 %, tandis que regrouper leurs assertions donne 2/10 = 20 %. Précisez l’agrégation utilisée.

Lorsqu’aucune assertion ne peut être notée, l’évaluateur actuel renvoie un score de 1,0. Cela arrive aussi lorsque toutes les assertions sont ignorées. Examinez les nombres d’assertions réussies, en échec et ignorées avant de considérer le score comme la preuve d’une évaluation réussie.

Définissez les métriques de résultat et d’outils autour de contrats explicites

• Taux de réussite du scénario : exécutions satisfaisant tous les résultats requis / exécutions applicables avec des preuves suffisantes. Définissez les résultats requis à l’avance et indiquez séparément les exécutions exclues. Un score moyen d’assertions n’est pas automatiquement ce taux.
• Exactitude du routage : demandes correctement routées / demandes annotées dont le routage est observable. Annotez les parcours attendus à partir de l’entrée ; ne sélectionner que les traces déjà correctement routées masque les erreurs de routage.
• Exactitude des arguments d’outils : appels avec les arguments requis validés / appels examinés nécessitant ces arguments. Comptez aussi les exécutions où l’appel requis n’a jamais eu lieu ; elles disparaissent d’un dénominateur limité aux appels.
• Taux de confirmations sans preuve : réponses évaluées affirmant qu’une action a réussi sans preuve à l’appui / réponses évaluées affirmant qu’une action est terminée. Utilisez des critères sémantiques explicites et examinez les jugements contestés.
• Nombre d’actions non autorisées : modifications interdites observées, regroupées par scénario et gravité. Gardez ce nombre visible même lorsque le taux global de réussite est élevé.

Utilisez le workflow de test en six cas pour définir ces contrats avant de recueillir les scores. Un statut HTTP de succès ne suffit à établir aucun d’entre eux.

Mesurez la couverture des scénarios séparément de la qualité

Imaginez 100 traces de production capturées : 60 correspondent à au moins un scénario configuré, 25 n’en trouvent aucun, 10 n’ont pas d’entrée exploitable et 5 ne peuvent pas être classifiées. Dans cet exemple, ces groupes de traces sont mutuellement exclusifs.

• Part correspondante des traces capturées : 60 / 100 = 60 %. Ce taux décrit l’échantillon capturé, pas tout le trafic de production si l’export ou l’échantillonnage a omis des interactions.
• Part correspondante des traces classifiables : 60 / (60 + 25) = 70,6 %. Nommez explicitement ce dénominateur plus restreint.
• Sans correspondance : examinez les 25 demandes pour repérer des scénarios manquants ou des erreurs de classification. Ce ne sont pas 25 tests réussis.
• Non classifiables : examinez séparément les 10 traces sans entrée exploitable et les 5 dont la classification est indisponible. Ne les transformez pas en réussites et ne les retirez pas silencieusement.

Mibo distingue les résultats de classification matched, no_match, empty_input et unavailable. Les vérifications invariantes peuvent s’exécuter même sans correspondance avec un scénario conditionnel. Puisqu’une trace peut correspondre à plusieurs scénarios, additionner les décomptes par scénario peut compter plusieurs fois une trace ; dédupliquez avant de calculer la couverture du trafic.

Séparez les preuves manquantes des erreurs de l’évaluateur

Un span manquant peut signifier qu’une action n’a jamais eu lieu ou que l’instrumentation l’a perdue. Vérifiez la complétude de la trace avant d’interpréter les assertions négatives. Le traitement des données manquantes varie selon la vérification ; un champ absent ne reçoit pas toujours un statut distinct de problème d’instrumentation.

Pour les vérifications sémantiques, conservez un petit ensemble d’exemples annotés comme acceptables ou inacceptables par des ingénieurs. Comparez l’évaluateur à ces annotations, examinez les désaccords et précisez les critères ambigus. Revérifiez cette calibration lorsque le modèle ou le prompt de l’évaluateur change.

Le taux d’hallucination de Mibo repose sur les échecs parmi les assertions hallucination_check configurées. Sans de telles assertions, aucun taux n’est mesuré. Ce taux ne mesure pas toutes les affirmations potentiellement non étayées sur l’ensemble du trafic.

Comparez latence et coût sur la même charge de travail

Présentez la latence de bout en bout séparément des durées du modèle et des outils. Choisissez une convention de calcul des percentiles, indiquez la taille de l’échantillon et signalez les délais d’attente dépassés et les durées manquantes. Un p95 plus faible n’est pas une amélioration de qualité si l’agent ignore désormais des outils requis.

Les tokens mesurent un usage, pas un montant monétaire. Les estimations de coût nécessitent les tarifs applicables aux modèles, les catégories de tokens, les nouvelles tentatives et les frais d’outils. Comparez le coût par tâche terminée si l’achèvement est votre objectif, et gardez visibles les coûts des tentatives échouées.

Pour comparer deux versions, gardez autant que possible la même répartition de scénarios, les mêmes données de test, le même évaluateur et la même fenêtre de mesure. Sinon, une hausse de la proportion de demandes faciles peut ressembler à une amélioration. Examinez les résultats par scénario avant d’accepter un gain agrégé.

Rédigez un rapport de publication qui permet de décider

• Périmètre : versions de l’agent, de la suite et de l’évaluateur, scénarios, nombre d’exécutions et conditions des données de test.
• Comportement : nombres de réussites et d’échecs, règle d’agrégation, échecs critiques et liens vers les preuves pertinentes dans les traces.
• Angles morts : vérifications ignorées, traces incomplètes, trafic sans correspondance et classification indisponible.
• Exploitation : distribution des latences, délais d’attente dépassés, hypothèses d’usage ou de coût et tailles des échantillons.
• Décision : quel scénario bloque la publication, ce qui doit être corrigé et ce qui nécessite davantage d’exécutions ou une revue humaine.

Cinq exécutions réussies n’établissent pas une probabilité de réussite de 100 % en production. Indiquez « 5/5 avec ces données de test » et élargissez les tests autour des échecs importants. Choisissez les seuils selon les conséquences d’une erreur, pas selon un score sectoriel arbitraire.

Reliez les métriques à un test examinable

Partez d’un scénario de la bibliothèque de cas de test d’agents, définissez ses vérifications et examinez une exécution réussie comme une exécution échouée. Le workflow d’évaluation de Mibo relie les vérifications configurées aux preuves d’exécution pour que le résultat mène à une correction concrète.

Pour les détails d’implémentation, utilisez la référence des assertions et le guide d’ingestion OpenTelemetry. Ne choisissez vos métriques qu’après avoir confirmé que votre instrumentation fournit les champs nécessaires.