Sur cette page
Une réponse au sujet d’une commande retournée semble prête à envoyer : grammaticalement correcte, aimable et concise. Dans cet exemple, un score automatisé lui attribue la note maximale. Pourtant, l’assistant annonce au client que le remboursement a été effectué, sans que personne ait vérifié le système de paiement.
Le problème n’est pas une phrase maladroite. C’est une définition défaillante du « travail bien fait ».
Dans une démonstration d’évaluation retranscrite, une équipe construit des scores pour un agent qui rédige de la documentation logicielle. Le moment intéressant survient quand la personne qui connaît le travail décrit la qualité, puis qu’un outil transforme cette description en critères. Plus tard, un score faible suscite le bon doute : faut-il corriger l’agent, ou l’évaluation ?
La grille est une théorie de la tâche. Il faut la tester.
Commencez par l’erreur éliminatoire
Les équipes commencent souvent par les dimensions faciles à noter : clarté, ton, structure, exhaustivité. Elles sont utiles, mais rarement suffisantes.
Pour la réponse illustrative sur le remboursement, « ne jamais déclarer un remboursement effectué sans justificatif de paiement » prime sur la qualité rédactionnelle. Pour une synchronisation de données, « ne pas mapper l’adresse de facturation vers l’adresse e-mail du titulaire du compte » compte davantage que la qualité de l’explication du mappage.
Demandez à l’expert métier trois types de cas : un résultat manifestement bon, un résultat clairement erroné et un cas où des personnes compétentes pourraient ne pas être d’accord. Conservez les données sources et la raison de chaque jugement. Si un cas dépend d’une règle susceptible d’évoluer, versionnez cette règle avec l’étiquette.
La première série peut être réduite. Elle ne peut pas être vague.
- Responsable de la tâche
cas bons, mauvais et discutables
- Contrôles exacts identité · autorisation · destination
le code vérifie les faits
- Grille sémantique
le juge interprète seulement ce qui l’exige
- Examen des désaccords
corriger les étiquettes et les critères
| Vérification | Responsable le mieux placé | Pourquoi |
|---|---|---|
| Autorisation requise présente | Code et sources de référence | Le fait est exact et lourd de conséquences |
| Identifiant de destination conforme à l’identité source | Code et fiche de test | Un modèle ne doit pas deviner un identifiant |
| La réponse traite la question du client | Grille relue par une personne, éventuellement un modèle juge | Le sens demande une interprétation |
| Le ton convient à la situation | Grille relue par une personne, éventuellement un modèle juge | Plusieurs formulations peuvent convenir |
Notre guide d’intégration de l’IA dans les workflows existants situe aussi les décisions automatisées dans un processus contrôlé : le code reprend les valeurs d’origine et vérifie les contraintes après le choix du modèle. La confiance du modèle ne vaut pas autorisation.
Une note hérite des angles morts de la grille
L’objection est légitime : « Une personne ne peut pas relire chaque exécution d’un agent. Il nous faut un juge évolutif. » C’est vrai. La question est de savoir ce que le juge fait passer à l’échelle.
Si la grille récompense une réponse soignée sans vérifier que la commande a été remboursée, l’automatisation amplifie l’omission. Un nombre à deux décimales semble précis. Il peut tout de même mesurer la mauvaise chose.
La documentation de Google Cloud sur l’évaluation d’un juge décrit un contrôle pratique : préparer des cas évalués par des personnes, lancer la métrique basée sur le modèle et comparer les notes. L’idée n’est pas qu’un avis humain soit infaillible. Le modèle a besoin d’une référence externe avant que sa note ne puisse compter.
Examinez les désaccords, pas seulement l’accord moyen. Si le juge valide une réponse rejetée par un responsable du support, cherchez le critère manquant. Si deux experts divergent, conservez les deux étiquettes et identifiez la règle qu’ils interprètent différemment. Ne faites pas disparaître le désaccord dans une moyenne.
L’échantillonnage compte autant que la formulation d’un critère. Une collection de réussites courantes peut donner une apparence de fiabilité au juge tout en laissant les cas difficiles de côté. Incluez des fiches incomplètes, des consignes contradictoires et des cas où la bonne réponse consiste à s’arrêter et demander. Gardez un jeu distinct de cas que les auteurs de la grille n’ont pas utilisés pour la régler, afin qu’une amélioration sur les exemples familiers doive aussi faire ses preuves ailleurs. Quand la règle métier change, actualisez les étiquettes et résultats attendus : un jeu de test figé peut récompenser la politique d’hier.
Gardez le résultat au cœur de l’évaluation
Une grille pour un agent de synchronisation doit suivre le résultat client. Le bon contact a-t-il changé ? Le consentement a-t-il été respecté ? Peut-on relancer une fiche en échec sans répéter une action lourde de conséquences ?
Le guide du connecteur Brevo explique qu’un appel d’API réussi peut coexister avec un attribut manquant. Une évaluation qui vérifie uniquement si l’agent a appelé le point de terminaison manque le résultat. Une évaluation qui ne regarde que la destination peut manquer une voie interdite ayant abouti par hasard à la bonne valeur. Les deux comptent lorsque le parcours comporte un risque.
Commencez par une tâche limitée et quelques modes d’échec. Faites étiqueter les cas par la personne responsable. Placez les contrôles exacts dans le code et utilisez un modèle juge uniquement quand la langue ou le jugement l’exige. Relancez les mêmes cas après tout changement de prompt, de modèle ou d’outil. Consignez ce que les échecs ultérieurs révèlent sur la grille.
Le coût se paie en temps d’expertise au départ. En retour, chaque note ultérieure a un sens défendable.
Un tableau de bord peut afficher une note. Seule la grille dit ce que vous avez compté.
Questions fréquemment posées
Qui doit définir les critères d’évaluation d’un agent IA ?
Les personnes qui connaissent la tâche et ses conséquences doivent définir les résultats acceptables et les erreurs éliminatoires. Les ingénieurs peuvent transformer ces jugements en contrôles reproductibles et mesurer l’accord d’un modèle juge avec les évaluations humaines.
Une note élevée du juge prouve-t-elle que l’agent fonctionne ?
Non. Une note mesure l’accord avec une grille sur les cas testés. Une grille faible, des cas peu représentatifs ou un juge mal calibré peuvent attribuer une bonne note à un résultat nuisible.
Que faut-il vérifier avec du code plutôt qu’avec un modèle juge ?
Dans la mesure du possible, vérifiez par code les autorisations, les identifiants de fiche, les appels d’outils nécessaires et l’état de destination. Un modèle juge aide à évaluer les qualités sémantiques qu’une règle exacte ne peut trancher.