Pourquoi mesurer un agent autrement qu’un chatbot ?
Un chatbot se juge sur la pertinence d’une réponse. Un agent se juge sur la justesse d’une action, parce qu’il écrit dans votre logiciel. Une action fausse ne se corrige pas en relisant : elle se corrige dans la base.
Il faut donc mesurer ce que l’agent fait, pas seulement ce qu’il dit. Et le mesurer avant la production, sur des cas dont on connaît la bonne réponse, puis après, sur ce qui se passe réellement.
Comment construire un jeu d’évaluation ?
C’est la première étape d’un projet, avant le modèle et avant le code. Le jeu d’évaluation est une liste de cas réels, chacun avec le résultat attendu, produite avec les experts métier :
- les cas courants, ceux qui font le volume ;
- les cas ambigus, ceux qui décident si l’agent est utilisable ;
- les cas hors périmètre, où la bonne réponse est de refuser ou de passer la main.
Le jeu de test est séparé de ce qui sert à configurer l’agent. Sinon on mesure sa mémoire, pas sa justesse. La méthode complète est dans comment créer un agent IA.
Quels indicateurs suivre ?
Six indicateurs couvrent l’essentiel. Les quatre premiers se mesurent sur le jeu d’évaluation, les deux derniers en production.
| Indicateur | Ce qu’il mesure |
|---|---|
| Précision des appels d’outils | L’agent a-t-il appelé le bon outil, avec les bons paramètres ? |
| Fidélité | La réponse s’appuie-t-elle sur les sources, sans rien inventer ? |
| Cohérence | La même question donne-t-elle la même réponse ? |
| Taux d’escalade | Quelle part des demandes l’agent passe-t-il à un humain, et à raison ? |
| Coût par action | Combien coûte une action réussie, appels au modèle compris ? |
| Indicateur métier | Ce que l’agent doit déplacer : tickets, délais, heures, revenu |
Le taux d’escalade se lit dans les deux sens. Trop bas, l’agent prend des décisions qu’il ne devrait pas prendre. Trop haut, il ne rend pas le service attendu. La cible se fixe par usage, sur le coût d’une erreur.
À quoi ressemblent ces mesures sur un projet livré ?
Chez OOTI, éditeur d’un ERP pour les cabinets d’architecture, l’agent transforme les questions en langage naturel en requêtes sur les données de l’ERP. Les mesures publiées :
- 92 % de précision des appels d’outils ;
- 97 % de score de fidélité ;
- 100 % de cohérence des réponses ;
- moins de 0,10 $ par question.
Chaque chiffre répond à une question différente. La précision des outils dit si l’agent interroge les bonnes données. La fidélité dit s’il rapporte ce qu’il a trouvé sans l’embellir. La cohérence dit qu’un associé et un chef de projet qui posent la même question obtiennent le même chiffre. Le coût dit si l’usage est tenable à l’échelle. Le détail est sur la fiche client.
Comment comparer deux configurations ?
Sur le même jeu de test, avec le même protocole, en publiant l’écart. Chez VAL Software, le matching CV-emploi a gagné 17 points de précision par la comparaison de 28 configurations sur le même jeu de test. Sans protocole commun, on aurait comparé des impressions.
Le système est livré avec plus de 109 tests, ce qui permet de vérifier qu’une amélioration à un endroit n’a rien cassé ailleurs.
Que mesurer une fois en production ?
Ce que le jeu d’évaluation ne voit pas : les questions que personne n’avait prévues, la dérive quand votre logiciel change, le coût réel à l’usage. Le journal de chaque action sert ici de matière première. Une erreur trouvée en production devient un cas de plus dans le jeu d’évaluation, et la mesure suivante la couvre.
Et l’indicateur métier, celui qui justifie le prix. C’est lui qui permet de facturer au résultat plutôt qu’à la licence, comme l’explique le modèle à crédits. Si vous voulez savoir par où commencer sur votre propre logiciel, le scan ci-dessous donne un premier diagnostic.
