12 Métriques de Fiabilité d'Agent

Ce qu'elle Mesure

Si l'agent réussit ou échoue de manière cohérente lors de tentatives répétées de la même tâche. Un agent de traitement de réclamations d'assurance qui approuve une réclamation lors d'une exécution mais refuse la même réclamation à la suivante crée une responsabilité légale et détruit la confiance des utilisateurs, indépendamment de la précision moyenne.

Signaux d'Échec

• La même entrée produit un succès un jour et un échec le lendemain
• Les démos fonctionnent ; la production non. Ou vice versa.
• "Ça marchait quand je l'ai testé" est une réponse courante du support
• Les taux d'erreur augmentent sur des lots de tâches identiques exécutées à différents moments

Comment Évaluer

Exécuter K tâches identiques plusieurs fois. Mesurer pass∧k (succès sur TOUTES les K exécutions) plutôt que pass@k (succès sur au moins une exécution). Normaliser la variance par p(1−p) pour isoler la cohérence du niveau de capacité.

Échecs Courants

• Rapporter pass@k comme métrique de fiabilité : cela mesure la capacité dans le meilleur cas, pas la cohérence
• Tester avec une seule exécution et déclarer le système "validé"
• Traiter la variance des résultats comme une "stochasticité acceptable du modèle"

Ce qu'elle Mesure

Si l'agent utilise des types et fréquences d'actions similaires à travers les exécutions répétées, même lorsqu'il atteint la même conclusion. Cherche-t-il toujours avant d'écrire ? Vérifie-t-il toujours avant d'exécuter ? La distribution des types d'actions devrait être stable d'une exécution à l'autre.

Signaux d'Échec

• L'agent lit parfois les fichiers avant d'écrire, parfois écrit directement
• Les journaux d'audit semblent complètement différents pour des tâches identiques
• Le nombre d'appels d'outils fluctue énormément entre les exécutions du même flux de travail
• Les équipes de conformité ne peuvent pas générer de pistes d'audit reproductibles

Comment Évaluer

Comparer les distributions de fréquence des types d'actions à travers K exécutions en utilisant des mesures de similarité distributionnelle. Signaler une variance élevée dans "ce que fait l'agent" même lorsque les résultats finaux correspondent. Les processus d'audit nécessitent des distributions d'actions stables.

Échecs Courants

• Mesurer uniquement les résultats finaux en ignorant la cohérence comportementale
• Supposer que "même résultat" signifie "même comportement"
• Construire des cadres de conformité sur un audit basé uniquement sur les sorties

Ce qu'elle Mesure

Si l'agent suit des ordres d'actions cohérents à travers les exécutions. Même lorsque les types d'actions sont similaires, débite-t-il parfois une carte avant de vérifier l'inventaire ? Vérifie-t-il l'identité après avoir pris une action ? Les incohérences d'ordre créent des modes d'échec invisibles à l'évaluation basée uniquement sur les sorties.

Signaux d'Échec

• Les échecs d'"état interrompu" sont imprévisibles et difficiles à récupérer
• La même tâche crée des états intermédiaires différents à travers les exécutions
• Les procédures de récupération fonctionnent parfois mais pas de manière cohérente
• Les mécanismes de rollback échouent car les hypothèses d'état ont été violées

Comment Évaluer

Comparer les séquences d'actions en utilisant des mesures de similarité de séquences (par ex., distance d'édition sur les traces d'actions). Définir des invariants d'ordre pour les processus critiques (étapes qui doivent toujours précéder d'autres) et vérifier qu'ils s'appliquent à travers K exécutions.

Échecs Courants

• Supposer que l'ordre des actions est non pertinent si le résultat final est correct
• Ignorer l'analyse de flux de travail en faveur de la vérification de l'état final uniquement
• Ne pas définir ou tester les invariants d'ordre pour les processus à enjeux élevés

Ce qu'elle Mesure

Si les coûts de calcul, la latence et la consommation de tokens API de l'agent sont prévisibles à travers des tâches identiques. Un agent qui coûte 0,02 $ par tâche le lundi et 2,00 $ le vendredi ne peut pas être opéré en toute sécurité à grande échelle, même avec une précision identique.

Signaux d'Échec

• La latence P99 est 10× la médiane sans raison apparente
• Les coûts API mensuels varient de 200% pour la même charge de travail
• La durée des tâches fluctue de 3 secondes à 3 minutes de manière imprévisible
• Les dépassements de budget se produisent sur des tâches routinières et répétitives

Comment Évaluer

Mesurer la variance de latence, de consommation de tokens et de coût API à travers K exécutions. Rapporter le coefficient de variation, pas seulement la moyenne. Signaler les tâches où la variance du coût ou de la latence dépasse 50% de la moyenne comme risques de fiabilité.

Échecs Courants

• Rapporter le coût moyen et la latence sans variance comme signal de fiabilité
• Mesurer uniquement la consommation de ressources dans les environnements de développement
• Traiter les pics de coût comme des problèmes d'infrastructure plutôt que comme des problèmes de comportement d'agent

Ce qu'elle Mesure

Si l'agent gère gracieusement les pannes d'infrastructure : timeouts API, réponses malformées, indisponibilité d'outils, retours de données partiels. Un agent robuste réessaie, adopte une solution de repli ou échoue en sécurité. Un agent fragile entre dans un état incohérent ou abandonne silencieusement la tâche.

Signaux d'Échec

• Un seul timeout API fait planter tout le pipeline de tâches
• Les pannes partielles d'outils se propagent en résultats corrompus en aval
• L'agent boucle indéfiniment sur des erreurs réessayables
• Aucune distinction comportementale entre les pannes transitoires et permanentes

Comment Évaluer

Injecter des scénarios de pannes contrôlées : timeouts d'outils, réponses API malformées, retours de données partiels. Mesurer le ratio de précision entre conditions nominales et conditions de panne. Un agent avec R_fault = 0,9 maintient 90% des performances nominales sous pannes d'infrastructure.

Échecs Courants

• Tester uniquement dans des environnements idéaux et qualifier le système de "prêt pour la production"
• Ne construire aucune logique de réessai ou de repli gracieux dans les flux de travail agentiques
• Traiter toutes les erreurs comme fatales plutôt que de les catégoriser par récupérabilité

Ce qu'elle Mesure

Si l'agent maintient ses performances lorsque son environnement change de façon sémantiquement neutre : champs JSON réorganisés, paramètres API renommés, formats de date modifiés, interfaces d'outils évoluées. Les environnements de production réels dérivent. Les agents fragiles échouent silencieusement quand cela se produit.

Signaux d'Échec

• L'agent se brise quand le schéma de base de données évolue, même sur des changements non-cassants
• Le versioning d'API cause des échecs silencieux sans messages d'erreur
• La réorganisation des champs JSON produit un comportement d'agent différent
• Les changements de locale ou de fuseau horaire causent des résultats imprévisibles

Comment Évaluer

Appliquer des transformations préservant la sémantique à l'environnement : réordonner les champs, renommer les paramètres, altérer les formats. Comparer les performances à la ligne de base nominale. Un agent prêt pour la production devrait être indifférent aux variations environnementales cosmétiques.

Échecs Courants

• Supposer des API et schémas stables pendant toute la durée de vie du déploiement
• Coder en dur les noms de champs, formats de date ou attentes d'ordonnancement
• Ne pas tester la dérive environnementale comme scénario de fiabilité de première classe

Ce qu'elle Mesure

Si l'agent performe de manière cohérente à travers des reformulations sémantiquement équivalentes d'instructions : paraphrases, traductions, variations de registre. Les vrais utilisateurs ne parlent pas comme les prompts de référence. Si "annuler mon abonnement" réussit mais "terminer mon plan" échoue, l'agent ne peut pas gérer le trafic réel.

Signaux d'Échec

• Les taux de succès chutent significativement pour les instructions non-anglaises
• Le phrasé formel versus informel produit des résultats différents
• Les utilisateurs de différents milieux reçoivent des résultats différents pour des demandes équivalentes
• La sensibilité aux paraphrases est élevée mais non documentée

Comment Évaluer

Générer des variantes de prompts sémantiquement équivalentes en utilisant paraphrases, traductions et changements de registre. Mesurer le ratio de précision entre prompts originaux et variantes. Viser R_prompt proche de 1,0 pour tout déploiement de production servant de vrais utilisateurs.

Échecs Courants

• Évaluer uniquement sur des formulations de prompts "canoniques" du benchmark
• Ignorer la fiabilité multilingue pour les déploiements multilingues
• Traiter la sensibilité aux prompts comme "comportement attendu" plutôt que comme défaut

Ce qu'elle Mesure

Si les niveaux de confiance déclarés par l'agent correspondent à ses taux de succès empiriques. Un agent revendiquant 80% de confiance devrait réussir environ 80% du temps. Les agents trop confiants poussent les utilisateurs à faire confiance à des sorties qu'ils devraient vérifier. Les agents pas assez confiants génèrent des boucles de révision humaine inutiles.

Signaux d'Échec

• Les sorties à haute confiance sont incorrectes à une fréquence surprenante
• L'agent ne s'abstient jamais ou ne signale jamais d'incertitude, même sur des tâches clairement difficiles
• Les scores de confiance se groupent près de 90%+ indépendamment de la difficulté de la tâche
• Les réviseurs humains contournent constamment les décisions "confiantes" de l'agent

Comment Évaluer

Collecter les scores de confiance et les résultats de l'agent. Tracer des courbes de calibration (confiance vs précision empirique). Utiliser l'Erreur de Calibration Attendue (ECE) pour quantifier la mauvaise calibration. Les agents bien calibrés ont des courbes sur la diagonale.

Échecs Courants

• Ne pas extraire ou suivre les scores de confiance de l'agent du tout
• Traiter les scores de confiance comme ornemental plutôt que pertinent pour la décision
• Optimiser pour la précision sans tester la qualité de calibration

Ce qu'elle Mesure

Si les scores de confiance de l'agent séparent avec succès les succès des échecs. Un agent peut être systématiquement trop confiant tout en assignant une confiance plus élevée aux tâches qu'il complète correctement. P_AUROC mesure cette qualité de classement indépendamment du niveau de calibration.

Signaux d'Échec

• Les scores de confiance sont identiques pour les tâches que l'agent réussit et celles qu'il échoue
• Les files de révision conçues autour des tâches à "faible confiance" n'attrapent pas les vrais échecs
• Le routage basé sur la confiance ne fournit aucun avantage par rapport à l'assignation aléatoire
• Les réviseurs humains ne peuvent pas utiliser les scores de confiance pour prioriser leur travail

Comment Évaluer

Calculer l'AUROC des scores de confiance prédisant le succès binaire de la tâche. AUROC = 0,5 signifie que la confiance est non-informative ; AUROC = 1,0 signifie séparation parfaite. Viser AUROC > 0,7 avant de construire un routage basé sur la confiance dans les flux de production.

Échecs Courants

• Supposer que la calibration implique la discrimination. Ce sont des propriétés indépendantes
• Construire des flux de révision sur les scores de confiance sans valider l'AUROC
• Utiliser des estimations ponctuelles au lieu de représentations distributionnelles de confiance

Ce qu'elle Mesure

Une règle de score appropriée qui pénalise conjointement la mauvaise calibration et la pauvre discrimination. Contrairement à ECE ou AUROC seuls, le Score de Brier fournit une mesure holistique unique de qualité prédictive qui incite au rapport de confiance honnête. La déviation de la vraie probabilité empire toujours le score.

Signaux d'Échec

• L'agent atteint un bon AUROC mais une pauvre calibration, ou vice versa
• Le rapport de confiance optimisé pour une dimension tandis que l'autre se dégrade
• Aucune métrique unifiée unique ne suit la qualité prédictive globale à travers les versions de modèle
• Les mises à jour de modèle améliorent la précision mais dégradent silencieusement la qualité de confiance

Comment Évaluer

Calculer le Score de Brier = moyenne((confiance − résultat)²) à travers les tâches. Intervalle [0,1] ; plus bas est mieux. Utiliser comme métrique de prévisibilité agrégée primaire dans la sélection de modèle et les décisions de déploiement.

Échecs Courants

• Suivre uniquement la précision et l'AUROC sans règle de score appropriée
• Utiliser le Score de Brier sans aussi rapporter sa décomposition calibration/résolution
• Traiter la qualité de confiance comme préoccupation secondaire à la précision de tâche

Ce qu'elle Mesure

Si l'agent adhère aux contraintes opérationnelles prédéfinies : pas d'exposition d'informations personnelles, pas d'actions non autorisées, pas de dépassement de limites. La conformité évalue l'adhérence aux contraintes indépendamment de si les violations causent des dommages immédiatement observables.

Signaux d'Échec

• L'agent exécute des actions en dehors de son périmètre de permissions défini
• Des données sensibles apparaissent dans les journaux, sorties ou systèmes en aval
• L'agent contourne les étapes de confirmation pour des actions irréversibles
• Les violations de limites ne sont découvertes que lors de révisions post-incident

Comment Évaluer

Définir les ensembles de contraintes explicitement avant le déploiement. Enregistrer toutes les actions de l'agent. Calculer S_comp = (tâches contraintes − tâches violées) / tâches contraintes. Viser S_comp = 1,0 ; toute violation en dessous de ce seuil est un risque de production qui doit être adressé avant la mise à l'échelle.

Échecs Courants

• Définir les contraintes dans la documentation plutôt que dans du code exécutable
• Tester la conformité uniquement dans des environnements sandbox avec des outils simulés
• Traiter les violations de conformité comme incidents isolés plutôt que comme signaux de fiabilité

Ce qu'elle Mesure

Parmi les tâches où des violations de contraintes se produisent, quelle est la sévérité des conséquences ? Retourner des résultats dans le mauvais ordre de tri est bénin. Exécuter une instruction DELETE non-intentionnelle est catastrophique. S_harm sépare la fréquence de violation de la sévérité de violation. C'est la décomposition de risque classique de l'ingénierie critique pour la sécurité.

Signaux d'Échec

• Les violations se regroupent dans les catégories d'actions à hautes conséquences : suppressions, paiements, communications
• L'agent a accès à des outils irréversibles sans sauvegardes d'autorisation proportionnelles
• Aucune classification de sévérité n'existe pour différents types de violations
• La sévérité d'incident du monde réel est plus élevée que prédite par les tests de sécurité

Comment Évaluer

Assigner des scores de sévérité (0 = bénin, 1 = catastrophique) aux catégories de violations avant le déploiement. Calculer ℛ_Saf = 1 − P(violation) × E[sévérité | violation]. Rapporter les métriques de sécurité séparément des autres dimensions. La sécurité est une contrainte dure, pas un compromis.

Échecs Courants

• Traiter toutes les violations comme également importantes, ignorant la distribution de sévérité
• Accorder l'accès à des capacités irréversibles sans autorisation étagée
• Rapporter uniquement les taux de violation sans analyse de conséquences