La réponse courte
Le test d'agent ne s'apparente pas à un test logiciel classique. Il n'existe pas de réponse unique et correcte ; une même question peut être formulée de vingt manières différentes, et un échec n'est généralement pas une erreur mais une réponse plausible à laquelle il manque une condition essentielle. Une approche différente est donc nécessaire : un ensemble de cas représentatifs, des critères d'acceptation plutôt que des réponses exactes, et une mesure multidimensionnelle indépendante.
La distinction entre les dimensions est ce qui rend un test utile. « La réponse n'est pas bonne » n'est pas une conclusion ; « le sujet a été correctement identifié mais la source pertinente n'a pas été extraite » est une conclusion qui peut être corrigée.
Les quatre dimensions de mesure
| Dimension | Objet de l'évaluation | Méthode de mesure | Responsable de la correction |
|---|---|---|---|
| Identification du sujet | L'agent a-t-il compris le sujet | Comparaison avec le sujet attendu | Auteur des instructions et descriptions d'Actions |
| Extraction | La bonne source a-t-elle été extraite | Le passage attendu figurait-il dans l'extraction | Propriétaire du contenu et de l'étiquetage |
| Réponse | Le contenu est-il exact et complet | Critères d'acceptation : obligatoire, interdit, citation | Contenu et instructions |
| Processus | L'action correcte a-t-elle été déclenchée et l'escalade conservée | Vérification de la séquence d'actions et de la décision d'arrêt | Actions et règles d'escalade |
Construction d'un ensemble de tests représentatifs
La matière première provient de requêtes réelles et non de scénarios élaborés en réunion. Les transcriptions, e-mails et descriptions de Case contiennent ce qui manque dans les scénarios inventés : fautes d'orthographe, formulations partielles, deux questions en une seule phrase et informations manquantes.
Composition recommandée : environ la moitié de cas courants, environ un quart de cas extrêmes – exceptions, conditions d'éligibilité marginales, questions multipartistes – et environ un quart de cas censés échouer intentionnellement : demandes hors du périmètre, tentatives d'extraction d'informations non autorisées et clients exigeant un interlocuteur humain.
Pour chaque cas, quatre champs sont définis : la requête telle que formulée, le sujet attendu, le critère d'acceptation de la réponse, et le comportement processuel attendu – y compris « doit escalader » comme résultat valide et non comme échec.
Critère d'acceptation plutôt que réponse exacte
C'est le principe qui permet de tester. Au lieu d'écrire la bonne réponse, rédigez trois courtes listes : les faits qui doivent apparaître, les déclarations qui ne doivent pas apparaître, et la source qui doit être citée.
L'exemple typique : une question sur l'éligibilité à un remboursement. La période et les conditions de l'état du produit doivent impérativement apparaître ; aucun engagement de crédit ne doit apparaître ; la source doit être la procédure de retour dans sa version valide. Deux formulations complètement différentes peuvent toutes deux être acceptées.
C'est également la forme qui permet une évaluation automatique fiable – la vérification de la présence d'un fait défini est beaucoup plus précise que la demande à un modèle d'évaluer la « qualité ».
Automatisation versus jugement humain
Les évaluateurs automatiques sont adaptés à l'identification de sujets, à la présence d'une citation valide, à la conformité au format, à la longueur et à l'identification des déclarations interdites. Ceux-ci s'exécutent sur l'ensemble du jeu de données pour chaque version, à faible coût.
Le jugement humain est requis pour l'exactitude du contenu dans les domaines sensibles et pour la formulation en contact avec le client. L'ensemble du jeu de données n'est pas nécessaire – un échantillon fixe de vingt à trente cas par version, choisi pour inclure les cas limites.
Le danger d'une dépendance totale à un évaluateur automatique est le biais vers des réponses qui semblent autoritaires. Une réponse convaincante qui omet une condition d'éligibilité passera automatiquement et échouera auprès d'un testeur humain.
Comment les résultats des tests sont liés à la surveillance en production est expliqué dans Observabilité pour Agentforce.
Scénarios extrêmes à toujours inclure
Une question comportant deux sujets dans la même phrase. Une requête à laquelle il manque des informations essentielles : l'agent pose-t-il une question de clarification ou conjecture-t-il ? Un client qui formule un message sur un ton négatif : l'escalade est-elle déclenchée ? Une demande d'action non autorisée pour cet utilisateur. Une question sur un produit inexistant : l'agent l'admet-il ou l'invente-t-il ? Un contenu contenant une instruction masquée visant à modifier le comportement.
Ces six points couvrent la plupart des échecs que nous avons observés en production, et leur exécution répétée est peu coûteuse.
Les scénarios de contournement sont liés aux tests de sécurité détaillés dans Sécurité Agentforce et responsabilité partagée.
Seuils de mise en production
Le seuil n'est pas un chiffre unique mais découle du canal et du risque. Un agent interne d'assistance aux représentants peut être mis en production avec un niveau de précision plus faible, car le représentant filtre. Un agent qui dialogue avec les clients exige un seuil significativement plus élevé, et surtout, zéro défaillance dans les catégories critiques.
La règle plus importante que le chiffre : zéro défaillance dans les catégories obligatoires. Divulgation d'informations non autorisées, action irréversible sans autorisation, non-escalade sur demande explicite d'une personne – chacun de ces points bloque la mise en production, quelle que soit la note globale.
Scénario : Un petit ensemble qui a empêché un mauvais lancement
Une entreprise touristique prévoyait de lancer un agent commercial après que le pilote interne ait montré de bonnes performances. Le jeu de tests construit comprenait 90 cas, dont 22 cas limites provenant de requêtes réelles.
L'exécution a révélé un schéma : pour les questions concernant un changement de date avec des conditions d'annulation spéciales, l'agent donnait une réponse globalement correcte mais omettait les frais de modification dans un tiers des cas. Lors des tests internes, cela n'a pas été détecté – les agents savaient ajouter l'information eux-mêmes.
Le lancement a été reporté de trois semaines. La correction était au niveau du contenu : les conditions de facturation ont été déplacées dans une section séparée et signalées dans chaque article pertinent, et un critère d'acceptation explicite a été ajouté. La réexécution a été concluante, et le lancement s'est déroulé sans incident.
Risques et mesures préventives
| Risque | Comment il se manifeste | Mesure préventive |
|---|---|---|
| Jeu de tests inventé | Tout passe le test et échoue en production | Cas tirés de requêtes réelles |
| Test du score global uniquement | Ne permet pas de savoir quoi corriger | Mesure séparée pour les quatre dimensions |
| Dépendance envers l'évaluation automatique | Les réponses convaincantes avec omissions passent | Échantillon humain fixe à chaque version |
| Aucun cas censé échouer | L'agent répond à ce qui lui est interdit | Un quart du jeu : hors périmètre et contournement |
| Absence de régression | Une petite correction casse un autre scénario | Exécution du jeu avant chaque mise à jour de version |
Indicateurs de test
| Indice | Définition | Seuil de principe |
|---|---|---|
| Précision du sujet | Pourcentage d'identification correcte du sujet | Élevé ; un échec ici compromet tout le reste |
| Taux de réussite de l'extraction | Pourcentage de cas où la source attendue est extraite | Élevé sur le canal client |
| Acceptation de la réponse | Pourcentage de réponses conformes aux critères d'acceptation | Dépend du canal et du risque |
| Conformité du processus | Pourcentage de cas où l'action ou l'escalade correcte a été déclenchée | Zéro écart dans les catégories obligatoires |
| Écart de régression | Changement de score par rapport à la version précédente | Pas de baisse inexpliquée |
Lorsqu'un accompagnement est requis pour la construction d'un jeu de tests et la définition des seuils de mise en production, le service Agentforce et IA est la voie pratique à suivre.
Liste de contrôle pour les tests
- ☐ Le jeu de tests est construit à partir de requêtes réelles
- ☐ La composition inclut des cas courants, des cas extrêmes et des cas censés échouer
- ☐ Pour chaque cas, un critère d'acceptation : obligatoire, interdit, source
- ☐ La mesure est divisée par sujet, extraction, réponse et processus
- ☐ Les évaluateurs automatiques exécutent l'ensemble du jeu
- ☐ Un échantillon humain fixe est vérifié à chaque version
- ☐ Les scénarios de contournement et les instructions masquées sont inclus
- ☐ Les catégories obligatoires avec une tolérance zéro sont définies
- ☐ Le jeu est exécuté en régression avant chaque mise à jour de version
- ☐ Les résultats des tests sont documentés et comparés à la version précédente