Testez votre agent avant sa mise en service

Un agent qui répondait bien le mois dernier peut se mettre à mal répondre après une modification du prompt ou de ses connaissances. La page Evaluation le détecte avant vos visiteurs : vous conservez un jeu de questions de test, vous les posez au brouillon de l’agent et vous décidez de l’effet d’une exécution en échec sur un déploiement.

Constituez le jeu de référence#

Ouvrez Evaluation dans la console et choisissez un agent. Chaque cas est une question assortie d’au moins une attente :

• la réponse attendue, jugée sur le sens plutôt que sur la formulation exacte,
• une réponse que l’agent ne doit jamais répéter (une erreur passée confirmée),
• ou la façon dont il doit se comporter : citer vos documents, passer à un humain ou refuser de répondre.

Un cas sans attente ne peut pas échouer : l’éditeur refuse donc de l’enregistrer.

Le chemin le plus rapide vers un jeu utile : appuyez sur Import confirmed-wrong reports. Chaque réponse que vos relecteurs ont confirmée erronée sur la page Answer feedback devient un cas que l’agent ne doit jamais répéter, accompagné de la question d’origine du visiteur. Importer deux fois est sans risque : les cas existants sont ignorés, jamais écrasés, de sorte que vos modifications sont préservées.

Exécutez-le#

Run the set pose chaque question au brouillon de l’agent, avec ses propres instructions et connaissances, et un juge automatique note chaque réponse. L’exécution enregistrée indique une réussite ou un échec pour chaque cas, la raison de l’échec et ce qui a changé depuis l’exécution précédente : quels cas se sont mis à échouer, lesquels se sont rétablis, lesquels ont été ajoutés.

Les exécutions sont conservées indéfiniment : « qu’est-ce que cette version réussissait avant sa mise en service » trouve donc toujours une réponse.

Décidez de ce que signifie un échec#

Le verrou de déploiement est un réglage qui s’applique à tout le projet et comporte trois positions :

• Off : les exécutions sont informatives.
• Warn : un déploiement effectué malgré une exécution en échec aboutit, mais vous indique quelle exécution a échoué.
• Block : le déploiement est refusé tant que l’exécution n’est pas réussie ou que le verrou n’est pas abaissé.

Seule une exécution réellement en échec déclenche le verrou. Une exécution qui a produit une erreur parce que le mécanisme de test lui-même a rencontré un problème ne bloque jamais votre déploiement.

Surveillez la qualité en production#

La même page héberge les alarmes de qualité du projet : un plafond pour le taux d’hallucinations (réponses qui ne s’appuient pas sur vos documents, mesurées par un juge automatique sur un échantillon de conversations réelles) et un plafond pour le taux de reprise par un humain. Lorsqu’un taux dépasse son plafond, un événement d’alerte est envoyé aux canaux que vous avez configurés, et un autre lorsqu’il revient à la normale. Le tableau de bord affiche les mêmes chiffres : réponses étayées, retours négatifs et conversations résolues sans intervention humaine.

Le rapport d’exploitation périodique#

Operations report, dans la console, est le même rapport de qualité pour une période calendaire entière, conservé comme archive plutôt que comme indicateur en temps réel.

Activez la planification, choisissez tous les mois ou tous les trimestres, et ajoutez les adresses qui doivent le recevoir. À la fin de chaque période, le rapport est généré et envoyé par e-mail sous forme de feuille de calcul. Il est également conservé ici, afin que vous puissiez le lire ou le télécharger sans attendre l’e-mail. Sans adresse, il est tout de même généré et conservé, simplement il n’est envoyé à personne.

Chaque rapport s’ouvre sur l’indicateur principal autour duquel il est construit : la part des conversations du site web qui se sont terminées sans que personne ne demande un interlocuteur humain, avec l’objectif à côté, atteint ou non. En dessous vient l’ensemble du projet, puis la même série de chiffres par agent : conversations traitées, combien ont été résolues sans escalade, combien de réponses s’appuyaient sur vos documents, évaluations négatives, le ressenti des conversations du début à la fin, le sujet le plus fréquent, combien de demandes d’appelants correspondaient à une intention que vous avez configurée, et les exécutions d’évaluation de la période.

Vous n’avez pas à attendre la fin d’une période. Generate produit à la demande un rapport pour n’importe quel mois ou trimestre passé, et propose deux boutons : le générer sans l’envoyer, pour le lire d’abord, ou le générer et l’envoyer aux adresses de la planification.

La génération à la demande est limitée à quelques rapports par heure. Chacun d’eux lit toutes les conversations, évaluations et exécutions d’évaluation de la période avant de répondre, et envoie une feuille de calcul par e-mail sauf si vous avez demandé le contraire ; cette limite est donc ce qui empêche quelques clics de devenir une charge sur les mêmes enregistrements que ceux qu’utilisent vos conversations en cours. Traiter les trois mois d’un trimestre en une seule fois reste largement en deçà de la limite. Si vous l’atteignez, la console vous le signale et vous demande de patienter quelques minutes ; votre rapport planifié n’est jamais affecté, car la limite ne porte que sur la génération à la demande.

Chaque chiffre du rapport provient du même calcul que celui que lisent le tableau de bord et votre propre supervision. Une période qui a atteint une limite de lecture l’indique sur sa propre ligne : les chiffres constituent alors une borne inférieure portant sur les conversations les plus récentes plutôt que sur la période entière.

Quand le score bouge et que personne n’a touché à l’agent#

Activez Drift detection à côté du verrou de déploiement et votre jeu de référence est réexécuté pour vous : selon une fréquence que vous définissez, et de nouveau chaque fois que changent les modèles qui font tourner vos appels. Chaque exécution est comparée à la précédente pour le même agent, et vous êtes alerté lorsque le score chute au-delà de la limite que vous avez fixée.

Elle alerte sur une baisse, pas sur un seuil plancher, et c’est cette différence qui la rend utilisable. Un agent qui a toujours obtenu 60 pour cent sur un jeu délibérément difficile ne dérive pas. Celui qui obtenait 92 hier et 84 aujourd’hui dérive, et seul le second mérite de réveiller quelqu’un.

L’alerte part vers les mêmes canaux que vos alarmes de qualité et nomme les cas qui réussissaient la fois précédente et échouent maintenant. Une réexécution indique dans la liste des exécutions pourquoi elle a eu lieu : selon la planification, ou parce que les modèles ont changé.

Elle est désactivée par défaut, car chaque réexécution coûte une réponse de l’agent et une passe de notation par question de votre jeu.