L’évaluation des agents IA doit établir si un assistant accomplit une tâche métier convenue, et pas seulement si son dernier message paraît convaincant. Si un agent affirme avoir modifié une fiche client, les preuves d’acceptation doivent se trouver dans le système cible autant que dans la conversation.
Évaluez un agent IA à partir de tâches représentatives, de règles d’acceptation explicites et de résultats vérifiés indépendamment. Incluez les refus, l’incertitude, les interruptions et les transferts à une personne, en plus des cas réussis. Rattachez la décision de mise en service au processus et à la version testés plutôt qu’à un seul score global.
Prenons un assistant qui prépare un changement d’adresse de livraison. Une démonstration utile peut afficher la bonne adresse dans une fenêtre de discussion. Une évaluation utile établit quelle commande a changé, qui a autorisé ce changement, si la livraison était déjà verrouillée et ce qui s’est passé lorsque la réponse du système cible était incertaine. Ce sont des questions différentes.
Les exemples ci-dessous sont des propositions de dispositifs d’évaluation, et non des résultats clients ni un benchmark publié. Ils aident un responsable métier à commander des preuves avant d’autoriser un agent à effectuer davantage de travail.
Définir le résultat pour l’évaluation des agents IA
Commencez par une tâche qu’un collègue opérationnel peut reconnaître. Décrivez l’état initial, les actions permises et l’état final accepté. Pour le changement d’adresse, l’acceptation pourrait exiger une commande éligible, une nouvelle adresse vérifiée, une approbation et une fiche correspondante dans le système de commandes.
L’explication d’Anthropic sur l’évaluation des agents distingue la trace de conversation de l’état final de l’environnement. Cette distinction reste utile si votre implémentation utilise un autre fournisseur. Un récit fluide de réussite renseigne sur la réponse, mais ne constitue pas une preuve indépendante du résultat métier.
N’exigez pas que chaque exécution valide emploie exactement les mêmes mots ou une seule séquence d’outils. Plusieurs chemins peuvent produire un résultat acceptable. Distinguez plutôt les contraintes impératives des détails d’implémentation variables. Une modification interdite doit faire échouer le test, même si la réponse finale est aimable.
Désignez un responsable des cas contestés. Si les équipes commerciales, financières et opérationnelles divergent sur le bon résultat, un évaluateur automatique ne peut pas trancher leur politique métier. Consignez ce désaccord comme une exigence non résolue avant d’utiliser le cas comme condition de mise en service.
Constituer un ensemble de cas représentatifs
Recueillez des exemples du processus réel, puis retirez les données personnelles inutiles. Incluez les demandes ordinaires, les valeurs délicates mais légitimes et les cas où le système devrait demander une précision. Évitez un jeu de tests composé uniquement d’exemples bien ordonnés écrits par le développeur de l’agent.
| Famille de cas | Situation illustrative | Preuve à examiner |
|---|---|---|
| Exécution courante | Une commande éligible comporte une nouvelle adresse claire | Fiche cible correcte et confirmation |
| Ambiguïté | Plusieurs commandes correspondent aux mots du client | Clarification sans deviner |
| Refus selon les règles | L’expédition a dépassé le point où les modifications sont permises | Aucune modification et une explication utile |
| Limite d’accès | La demande désigne une commande d’une autre organisation | Refus sans divulgation |
| Opération incertaine | Une écriture expire après sa soumission | Référence d’investigation et aucune répétition aveugle |
| Transfert humain | La demande exige une décision d’exception | Élément de file attribué avec suffisamment de contexte |
Considérez cette matrice comme un point de départ, sans prétendre à une couverture universelle. Un assistant de paie, un outil de recherche interne et un agent de support client exigent des preuves différentes. L’essentiel est que chaque cas ait un sens métier attendu avant son exécution.
Séparer les cas de découverte des cas d’acceptation
Un cas exploratoire peut révéler une nouvelle défaillance sans disposer d’une règle de notation arrêtée. C’est un apprentissage précieux, mais il ne doit pas modifier discrètement la définition d’une réussite déjà convenue. Conservez un ensemble d’acceptation stable et une file distincte pour les cas nécessitant une investigation ou une décision métier.
Conservez les cas qui ont révélé de vrais défauts. Une fois le défaut corrigé, le cas devient un contrôle de régression. Ajoutez des exemples lorsque le périmètre opérationnel s’élargit au lieu de réécrire constamment l’ancien ensemble pour l’adapter à la dernière sortie.
Choisir comment vérifier chaque résultat
Utilisez des contrôles déterministes pour les faits réellement déterministes. Un identifiant cible, un champ protégé resté inchangé ou l’absence d’écriture non autorisée peuvent souvent être vérifiés directement. Un modèle évaluateur peut aider à juger la qualité des explications, mais il ne doit pas décider seul si de l’argent a été déplacé ou une fiche modifiée.
| Méthode d’évaluation | Utile pour | Limite à gérer |
|---|---|---|
| Assertion sur le système cible | Identité, état et modifications autorisées des fiches | Exige un accès fiable à l’environnement de test |
| Validation par règles | Champs obligatoires et opérations interdites | Ne peut pas juger chaque explication raisonnable |
| Revue humaine | Politique ambiguë et transferts utiles | Exige une grille écrite et du temps de revue |
| Revue assistée par modèle | Classer ou comparer les réponses libres | Exige un calibrage sur des exemples fiables |
Documentez la raison de chaque contrôle. Une comparaison de chaînes qui récompense une excuse précise peut rejeter une réponse parfaitement utile. Un schéma qui accepte les noms de champs attendus peut malgré tout accepter le mauvais client. Le guide des objets de JSON Schema explique la validation structurelle ; la justesse métier exige des assertions supplémentaires.
Pour les réponses subjectives, demandez aux évaluateurs de décrire le défaut plutôt que de choisir simplement une note. La réponse était-elle sans fondement, confuse, incomplète ou hors des droits de l’utilisateur ? Des catégories distinctes facilitent la justification du prochain changement technique et la répétition de la prochaine revue.
Maîtriser l’environnement de test et les versions
Un cas reproductible exige davantage qu’un prompt sauvegardé. Consignez l’implémentation de l’agent, les instructions pertinentes, les définitions d’outils, la configuration du modèle et les données initiales. Si une fiche en amont change entre les exécutions, le résultat peut varier pour une raison légitime sans lien avec le changement de l’agent.
Utilisez un système cible contrôlé pour les opérations produisant des effets métier. Réinitialisez ou recréez volontairement l’état initial. Une seconde exécution sur une fiche déjà modifiée par la première constitue un autre test, même si la demande en langage naturel est identique.
Vérifier plusieurs tentatives
Le comportement d’un agent peut varier entre les tentatives. Décidez à l’avance comment les essais répétés contribueront à l’acceptation et conservez tous les résultats. Rapporter uniquement la meilleure exécution empêche le responsable de comprendre l’irrégularité. À l’inverse, ne prétendez pas à la certitude après quelques exemples réussis.
Convenez d’un budget d’évaluation praticable. Certains cas peuvent être exécutés à chaque modification du contrat d’un outil ; d’autres nécessitent un évaluateur spécialisé ou un environnement d’intégration coûteux. Une suite à plusieurs niveaux permet des contrôles fréquents et limités tout en conservant une évaluation de mise en service plus large lorsque le périmètre opérationnel change.
Faire des échecs et des transferts des résultats utiles
Un refus peut être le résultat correct. Un agent qui s’arrête devant une commande ambiguë peut être plus utile qu’un agent qui effectue la mauvaise modification. Définissez les clarifications, les escalades et les continuations manuelles acceptables pour que l’évaluateur ne récompense pas l’exécution à tout prix.
Examinez les fiches de transfert aussi soigneusement que les opérations terminées. Elles doivent identifier la demande initiale, la référence cible pertinente, la question non résolue et la file responsable. Une consigne générique de contacter le support peut obliger le collègue à recommencer l’investigation depuis le début.
Distinguez l’évaluation de l’analyse de sécurité plus large. OWASP ASVS fournit une base pour vérifier les exigences de sécurité applicative. Notre guide de sécurité des agents IA traite des permissions et des entrées hostiles. Une évaluation du processus doit inclure ces limites, mais un bon résultat d’exécution ne constitue pas une assurance complète de sécurité.
Décider ce qui bloque la mise en service
Rédigez les conditions d’arrêt avant la démonstration. Une divulgation entre clients ou une écriture non autorisée peut justifier un arrêt, quelle que soit la moyenne d’exécution des tâches. Une explication confuse mais récupérable peut plutôt exiger un périmètre réduit ou un pilote surveillé. La gravité découle de l’effet métier.
Rapportez les résultats par famille de cas et globalement. Un bon total peut masquer une reprise peu fiable lorsque la plupart des exemples sont des consultations ordinaires. Indiquez le nombre et la nature des cas testés, les échecs non résolus, les désaccords de revue et les exclusions connues à côté de tout score synthétique.
L’acceptation doit porter sur un périmètre et une version précis. Réussir des questions sur les commandes en lecture seule ne prouve pas que l’agent est prêt à les modifier. Ajouter un système cible, un groupe d’utilisateurs ou un outil d’écriture change la limite opérationnelle et doit déclencher une revue délibérée des cas.
Conservez un dossier de mise en service compréhensible par un autre membre de l’équipe. Il doit expliquer ce qui a été testé, ce qui a échoué, ce qui a changé et pourquoi le responsable a accepté les limites restantes. Un tableau de bord vert sans explication constitue une mauvaise transmission lorsque l’évaluateur d’origine est absent.
Budgéter les preuves et la maintenance
Demandez une proposition en GBP avec un périmètre défini pour la conception des tests, les environnements contrôlés, l’implémentation, la revue et le compte rendu. Séparez ce travail initial des évaluations récurrentes et de la maintenance des cas après un changement des règles métier. Sans connaître le processus, aucun prix universel par évaluation n’est défendable.
| Lot de travail | Livrable demandé | Hypothèse de coût à expliciter |
|---|---|---|
| Conception des cas | Cas représentatifs et résultats convenus | Disponibilité des responsables du processus |
| Infrastructure de test | États initiaux contrôlés et capture des résultats | Accès à des environnements cibles réalistes |
| Évaluation | Assertions et grilles de revue documentées | Effort de revue spécialisée et de calibrage |
| Preuves de mise en service | Analyse des échecs et dossier d’acceptation | Diversité des clients logiciels, outils et opérations |
| Maintenance | Contrôles reproductibles et responsables des cas | Fréquence des changements de modèles, outils et règles |
Le premier investissement utile est souvent une suite limitée qui détecte une catégorie d’erreur coûteuse. Sa valeur vient de la décision qu’elle soutient, pas du nombre de prompts dans un tableur. Évitez d’acheter un vaste benchmark synthétique que personne ne peut relier aux opérations quotidiennes.
Commander un pilote d’évaluation limité
Apportez une description de la tâche, des exemples représentatifs expurgés et l’état du système cible qui prouve l’exécution. Identifiez les opérations que l’agent ne doit jamais effectuer et les collègues qui jugeront les cas ambigus. Les exemples d’incidents existants sont utiles si leurs détails sensibles peuvent être traités correctement.
Notre pilote d’intégration IA au périmètre défini peut commencer par cette tâche et ses preuves d’acceptation. Le périmètre initial permet d’établir si l’agent, ses outils et le système cible fonctionnent ensemble de manière fiable avant d’élargir l’accès.
Envoyez-nous le processus et la décision de mise en service à prendre . Demandez une suite d’évaluation reproductible, une description de ses angles morts et une transmission claire. Le livrable doit vous aider à décider de la prochaine tâche que vous pouvez confier à l’agent en toute sécurité.
Questions fréquentes
Qu’est-ce que l’évaluation des agents IA ? L’évaluation des agents IA vérifie un agent par rapport à des tâches et des règles d’acceptation définies. Elle examine l’état obtenu du système, les opérations autorisées et la qualité des explications ou des transferts, plutôt que de traiter un message final convaincant comme une preuve d’exécution.
Un score de benchmark suffit-il pour approuver un agent métier ? Non. Un benchmark général peut éclairer une comparaison technique, mais l’acceptation exige des cas qui reflètent vos fiches, permissions, modes de défaillance et règles métier. Rapportez le périmètre testé et les limites non résolues.
Combien de cas de test faut-il ? Il n’existe pas de nombre universel. Commencez par les résultats distincts et les chemins d’échec importants du processus proposé. Ajoutez des cas lorsque de nouveaux outils, groupes d’utilisateurs ou exceptions métier créent un comportement sensiblement différent. Une vaste collection de prompts presque identiques n’équivaut pas à une large couverture opérationnelle.
Un autre modèle peut-il évaluer les réponses ? Oui, pour les parties adaptées de la revue. Calibrez-le sur des exemples vérifiés par des personnes compétentes et conservez des assertions déterministes sur le système cible pour les faits comme la fiche modifiée. Le jugement du modèle ne doit pas remplacer la preuve d’une opération métier.
Un refus correct doit-il compter comme une réussite ? Oui, lorsque le refus est le résultat attendu. Définissez ce que dit un refus utile et confirmez qu’aucune opération ni divulgation interdite n’a eu lieu.
Faut-il des données clients de production ? Vous devriez généralement commencer par des exemples contrôlés qui conservent la structure pertinente et les cas délicats sans données personnelles inutiles. Tout usage de données réelles exige un objectif explicite, un accès approprié et une politique de traitement. Un comportement représentatif importe davantage que la copie de toute une base de production dans l’évaluateur.
Que doit transmettre un prestataire d’évaluation ? Le jeu de cas, les résultats attendus, les instructions d’état initial, les règles d’évaluation, les versions consignées et les preuves d’échec. Incluez les commandes ou le processus nécessaires pour répéter l’analyse ainsi qu’un responsable de sa mise à jour.
Quand faut-il réexécuter la suite ? Répétez les contrôles pertinents après tout changement des modèles, instructions, outils, permissions ou du comportement cible. Réexaminez la couverture lorsque la tâche métier s’élargit. Le précédent résultat d’acceptation appartient au précédent périmètre testé.