Documentation / Guides

Reconnaître ce que demandent les appelants, voir ce qu’ils ont ressenti et protéger les deux côtés

Définissez les demandes que votre agent reconnaît, voyez comment s’est passée chaque conversation, et conservez les filtres de sécurité.

Dernière mise à jour:

Trois choses se produisent désormais autour de chaque conversation : la demande est reconnue au moment où elle est formulée, puis orientée ; la conversation terminée est évaluée sur le ressenti de l’appelant et sur son objet ; et aussi bien ce que dit l’appelant que ce que répond l’agent passent par un filtre de sécurité.

Indiquez à l’agent ce que les gens demandent#

Ouvrez un agent et rendez-vous dans Requests. Chaque entrée comporte un nom, quelques exemples formulés avec les mots qu’emploient réellement vos appelants, et ce que l’agent doit faire lorsqu’il reconnaît cette demande :

  • répondre à partir de vos documents, pour tout ce que couvre votre base de connaissances,
  • exécuter une procédure, lorsque la demande déclenche un flux que vous avez défini,
  • utiliser un outil, lorsqu’il doit appeler quelque chose,
  • proposer un interlocuteur, ou transférer l’appel.

Rédigez les exemples dans chacune des langues dans lesquelles l’agent répond. La mise en correspondance repose principalement sur les exemples ; le nom et la description comptent aussi, avec un poids bien plus faible. Ainsi, une entrée dotée d’une bonne description et sans exemples n’est pas désactivée pour autant : elle peut encore être reconnue sur les seuls mots de sa description et orienter l’appelant en conséquence. Pour conserver une entrée sans qu’elle puisse être mise en correspondance, désactivez l’ensemble complet plutôt que de vider ses exemples.

Ce qu’il ne fait pas#

Il met en correspondance les mots que vous avez écrits. Il ne paraphrase pas : une demande formulée avec un vocabulaire qu’aucun de vos exemples ne partage n’est donc pas reconnue, et elle n’est pas censée l’être. C’est précisément à cela que sert la liste Not yet covered : chaque demande qui n’a rien trouvé y est consignée, avec le nombre de fois où elle est revenue et l’entrée dont elle s’est le plus approchée. Un score de proximité élevé signifie généralement que la solution tient à un exemple de plus sur une entrée que vous avez déjà, ce que fait l’action Add to this request. Un score faible signale un type de demande réellement nouveau.

Le niveau de correspondance, et son réglage à partir de vos propres conversations#

La proximité est jugée par rapport à un niveau de correspondance que vous pouvez définir pour chaque agent. La liste Not yet covered affiche le niveau utilisé et précise si vous l’avez choisi ou s’il s’agit de la valeur par défaut de la plateforme, car il s’agit du même nombre à l’écran alors que les deux cas appellent des décisions opposées : une valeur par défaut que personne n’a choisie pour vos appelants mérite d’être réexaminée, votre propre réglage réfléchi ne le mérite généralement pas. Chaque formulation indique ensuite de combien elle est restée en deçà de ce niveau, de sorte qu’un écran rempli d’échecs de peu se lit comme un seul réglage à ajuster plutôt que comme cent entrées à rédiger.

La valeur par défaut est délibérément prudente, et elle est sévère envers la façon dont les gens parlent réellement. Une demande formulée sans détour obtient un bon score ; la même demande enveloppée dans « bonjour, désolé de vous déranger » et « merci » obtient un score bien plus faible, car chaque mot qui n’apparaît dans aucun de vos exemples tire le score vers le bas. Ces demandes relèvent parfaitement de votre domaine, et avec la valeur par défaut elles atterrissent dans Not yet covered au lieu d’être orientées.

Nous ne baissons pas la valeur par défaut à votre place, car le bon niveau dépend de la façon dont parlent vos appelants et personne ne peut le savoir de l’extérieur. Ce que la liste vous donne à la place, ce sont les éléments de preuve : quelles formulations un niveau légèrement plus bas aurait captées, et quelle part du trafic elles représentent. Baissez-le d’un cran, surveillez la même liste, et revenez en arrière si des demandes commencent à correspondre à la mauvaise entrée. Un niveau plus bas reconnaît davantage et se trompe plus souvent ; aucun réglage ne fait seulement le premier.

Une entrée que vous enregistrez mais laissez désactivée ne coûte rien et n’est jamais mise en correspondance : vous pouvez donc préparer tout un ensemble avant de l’armer.

Voyez comment s’est passée chaque conversation#

Chaque conversation terminée reçoit une lecture du ressenti de l’appelant à son début et à sa fin, du sens dans lequel il a évolué entre les deux, et du thème, parmi les vôtres, dont elle relevait. Cela est décidé une seule fois, après l’appel, à l’intérieur du résumé qui s’exécute déjà : cela n’ajoute donc rien au temps d’attente de l’appelant, ni au coût de la conversation.

Le tableau de bord affiche la répartition et les tendances. Deux chiffres méritent d’être distingués : combien de conversations sont arrivées avec un appelant mécontent, et combien se sont terminées avec un appelant mécontent. Ils répondent à des questions différentes sur une même semaine.

Needs review est la file constituée des conversations qui se sont à la fois mal terminées et ont été transmises à une personne, les pires fins en premier. C’est la liste à traiter quand vous avez vingt minutes devant vous plutôt qu’une journée.

Emerging topics regroupe les sujets que votre liste de thèmes ne couvre pas encore. L’écran indique toujours comment le regroupement a été fait : par sens, ou par vocabulaire commun lorsque l’installation ne dispose d’aucun regroupement sémantique. Lisez cette ligne avant de lire les groupes, car le vocabulaire commun est un signal plus faible que le sens commun. Rien sur cet écran ne change la façon dont un appel reçoit une réponse tant que vous n’ajoutez pas vous-même un thème.

Les filtres de sécurité#

Deux filtres s’exécutent sur chaque agent, dans chaque forfait, et vous n’avez pas à les activer.

Le filtre d’entrée examine chaque prise de parole de l’appelant, ainsi que chaque passage ou résultat d’outil que l’agent récupère, à la recherche de tentatives visant à détourner l’agent de ses instructions ou à lui faire énoncer celles-ci à voix haute. Par défaut, il consigne ce qu’il a trouvé et laisse la conversation se poursuivre, car il reconnaît des motifs dans les propres mots d’une personne réelle et un faux positif à cet endroit, c’est un appel gâché. Sur un widget web public, où le coût d’un faux positif se limite à une conversation écrite gâchée, le passer en refus est souvent le meilleur compromis. Le contenu provenant d’un document ou d’un outil n’est jamais refusé : il est marqué comme donnée à l’intérieur de sa propre délimitation, car écarter un passage reviendrait à répondre à votre appelant « je n’ai pas cette information » à cause d’une phrase que quelqu’un a écrite dans un PDF.

Le filtre de réponse s’exécute avant que quoi que ce soit ne soit prononcé ou affiché, sur chaque réponse que produit l’agent : non seulement ses réponses générées, mais aussi son message d’accueil, sa formule de départ, ses questions d’enquête et ses phrases de transfert. Il refuse une réponse qui répéterait vos instructions, énoncerait un identifiant, ou relèverait des catégories de modération que vous avez laissées activées. Une réponse refusée est remplacée par la phrase de repli de l’agent, dans la langue dans laquelle l’appelant est servi.

Le contrôle d’ancrage des réponses, optionnel, est d’une autre nature. Lorsqu’un agent répond à partir de vos documents, il retient la réponse, l’évalue au regard des passages réellement récupérés et, si la réponse n’est pas étayée, il interroge de nouveau l’agent en lui imposant explicitement de n’utiliser que ces passages. Si cette deuxième réponse n’est toujours pas étayée, l’appelant entend la phrase de repli à la place. Cela coûte une vraie pause et parfois une seconde réponse entière : c’est pourquoi il est désactivé tant que vous ne l’activez pas, et pourquoi il ne s’exécute jamais que sur des réponses tirées de vos documents.

Ce que les filtres ne détectent pas#

Il s’agit de reconnaissance de motifs, non de jugement. Ils repèrent les formes connues de « ignore tes instructions », les formes connues d’un identifiant divulgué, et un texte qui reprend vos instructions presque mot pour mot. Une formulation inédite pour laquelle personne n’a écrit de motif passe, tout comme une réponse fausse mais inoffensive : le filtre de réponse relève de la sécurité, pas de l’exactitude. L’exactitude, c’est l’affaire de la page d’évaluation, des notes attribuées aux réponses et du contrôle d’ancrage des réponses.

Chaque action entreprise par un filtre est comptée et affichée, y compris les fois où le contrôle d’ancrage des réponses n’a pas pu trancher et a laissé passer la réponse plutôt que de laisser votre appelant dans le silence. Un garde-fou qui cesserait silencieusement de protéger serait la pire version de cette fonctionnalité : ce cas figure donc sur le même graphique qu’un refus.

La console

Ces pages sont en lecture seule. L'appel de test, les clés API et la référence de l'API à jour se trouvent dans la console, où votre compte est connecté.

Ouvrir la console