Ce que votre IA dédiée au service client devrait faire lorsqu'elle ne connaît pas la réponse

Lorsque l'IA du service client ne connaît pas la réponse, elle doit le signaler, transférer le client à une personne capable de l'aider (en joignant l'historique de la conversation) et transformer la question restée sans réponse en une mise à jour de la base de connaissances. Elle ne doit jamais se livrer à des conjectures. C'est souvent là que naissent de nombreuses « hallucinations » dans le service client : un système conçu pour répondre à tout génère une réponse alors qu'il ne dispose d'aucune réponse validée à fournir.

Pourquoi l'IA du service client répond-elle à des questions auxquelles elle ne peut pas répondre ?

La plupart des IA dédiées au service client sont conçues pour générer du contenu. Un assistant génératif reçoit une question, extrait tout texte qui semble pertinent et rédige une réponse. La rédaction d’une réponse étant la fonction première du système, celui-ci s’exécute, que le texte extrait permette ou non de répondre à la question. Lorsque les informations sources sont insuffisantes, obsolètes ou ne traitent pas du sujet, le modèle comble cette lacune avec un texte qui semble cohérent.

Il se peut que l'entreprise n'ait pas de politique concernant la demande formulée par le client. Le problème est que le système ne dispose d'aucun moyen fiable de le détecter, ni d'aucune raison technique de s'arrêter. Une réponse erronée fluide apparaît de la même manière dans les journaux qu'une réponse correcte fluide ; c'est pourquoi ces erreurs ont tendance à se manifester sous forme de réclamations des clients après coup, plutôt que d'alertes en amont.

Pourquoi le modèle ne peut-il pas simplement vous dire quand il ne connaît pas la réponse ?

On peut toujours essayer. Le résultat n'est toutefois pas fiable, car demander à un modèle linguistique d'évaluer son propre niveau de confiance revient à demander à l'élément qui a généré l'erreur de la détecter lui-même.

Les règles de prompt telles que « ne répondre qu’à partir du contexte fourni » et « dire que l’on ne sait pas en cas de doute » réduisent le taux de réponses inventées, et il vaut la peine de les appliquer. Mais elles ne changent rien à la question de savoir qui prend la décision finale : c’est le même modèle qui rédige la réponse qui décide également s’il avait des raisons de la rédiger. La génération augmentée par la recherche (RAG) présente la même limite, comme l’explique l’article « La RAG est-elle suffisante ? Pourquoi la recherche continue-t-elle de produire des hallucinations dans le service client ? ».

Les seuils de confiance associés aux scores de pertinence sont un peu plus utiles. Cependant, un score de similarité élevé ne fait que mesurer dans quelle mesure un passage correspond aux mots d'une question, et non s'il y répond réellement. Une politique de remboursement concernant un autre produit peut obtenir un bon score tout en étant complètement erronée.

Le signal le plus fiable provient de la conception même du système. Lorsque les réponses sont rédigées et validées avant même qu’un client ne pose sa question, vérifier s’il existe une réponse validée revient à effectuer une simple recherche dont le résultat est binaire (oui ou non). Soit le système trouve une réponse correspondante, soit il n’en trouve pas. C’est bien plus fiable que de demander à un modèle d’évaluer son propre niveau de confiance alors qu’il est encore en train de rédiger la réponse.

Comment une architecture axée sur la connaissance sait-elle qu'il n'y a pas de réponse ?

Dans une architecture axée sur la connaissance, les réponses sont élaborées et validées dès leur ingestion. Lorsque Inbenta Encore ingère le contenu d’une entreprise (documents de politique, pages du centre d’aide, fichiers PDF, transcriptions d’appels, bibliothèques SharePoint et systèmes tels que Salesforce et ServiceNow), il détermine les différentes façons dont un client pourrait poser chaque question et associe chacune d’elles à une solution. Un deuxième modèle, indépendant, valide chaque réponse avant sa mise en ligne. Tout ce processus se déroule avant que le client n’y ait accès, et cette validation constitue la trace d’audit.

Au moment de l'exécution, Encore compare la requête du client à ces réponses prédéfinies. Soit il y a correspondance, soit il n'y en a pas. Lorsqu'il y a correspondance, un modèle linguistique vérifie que la question et la réponse concordent, puis adapte la formulation pour la conversation. C'est le modèle qui adapte la formulation, et non les faits. Lorsqu'il n'y a aucune correspondance, Encore n'impose pas de correspondance approximative, et le modèle n'est pas sollicité pour combler cette lacune.

Le processus de mise en correspondance est abordé dans l'article « Comment l'IA d'un centre de contact détermine-t-elle l'intention de l'appelant avant même que la question ne soit posée ? ». Pour savoir pourquoi il est plus sûr de préparer et de valider les réponses à l'avance plutôt que de les générer pendant que le client attend, consultez l'article « Comment éviter les « hallucinations » de l'IA dans le service client : corrigez l'architecture, pas la consigne ».

Que doit-il se passer lorsque l'IA n'a pas de réponse validée ?

Une IA dédiée au service client bien conçue effectue quatre actions lorsqu'elle atteint les limites de ses connaissances.

Il identifie cette lacune. Le système signale qu'il ne dispose d'aucune réponse prédéfinie, plutôt que de laisser une étape de génération combler cette lacune avec un texte plausible.

Elle pose la question lorsque celle-ci est ambiguë. Certaines erreurs sont dues à des lacunes dans la question, et non à un manque de connaissances. « Quel est le montant des frais ? » peut faire référence à quatre montants différents. Une brève question de clarification permet de régler cela sans avoir à passer le relais.

Le système procède à une remontée en fonction du contexte. Lorsque la base de connaissances ne permet pas de répondre à la question, Encore remonte le dossier à un expert en la matière ou à un agent en direct, plutôt que de se livrer à des conjectures, et transmet l'historique de la conversation afin que le client n'ait pas à se répéter. Grâce à la fonction « Live Agent Assist », l'agent a accès à l'historique du dossier dès sa remontée et s'appuie sur des brouillons de réponse standardisés, qu'il vérifie avant que toute réponse ne soit transmise au client.

Il recense les lacunes. Une question à laquelle le système n'a pas pu répondre constitue l'une des informations les plus utiles qu'il génère. Elle devrait être orientée vers une solution, et non vers un compte-rendu que personne ne lit.

L'escalade constitue-t-elle un échec pour l'IA appliquée au service client ?

Pas quand c'est prévu dès la conception. L'escalade est considérée comme un échec selon un indicateur de « confinement », dont l'objectif est de maintenir le client au sein du canal automatisé. Selon cet indicateur, un client qui abandonne compte autant qu'un client ayant obtenu une réponse, et un assistant qui devine obtient un meilleur score qu'un assistant qui transfère la demande.

La résolution est le meilleur indicateur. Un transfert bien géré qui aboutit à la résolution du problème vaut mieux qu’une réponse erronée donnée avec assurance, mais qui se solde par une réclamation, un nouveau contact ou un contrôle de conformité. Selon Gartner, les résolutions entièrement en libre-service représentent environ 22 % des interactions, ce qui signifie que le transfert occupe une place importante dans le parcours client, et ne constitue pas un cas marginal. Un assistant qui masque ses lacunes derrière du texte généré rend ce parcours plus difficile à cerner et à améliorer.

La qualité du transfert détermine le coût de la remontée vers un niveau supérieur. Lorsque le contexte est perdu, le client doit réexpliquer sa situation et l'agent repart de zéro. Avec Live Agent Assist, qui met à la disposition de l'agent des connaissances structurées et l'historique des conversations, Inbenta enregistre un taux de résolution dès le premier contact en hausse de 80 % et une baisse de 65 % du volume d'appels remontés vers un niveau supérieur. Ces deux chiffres concernent spécifiquement le canal assisté.

Comment une question à laquelle on n'a pas su répondre peut-elle devenir une meilleure réponse la semaine suivante ?

C'est là que cette lacune s'avère payante. Encore Elevate tire des enseignements des interactions réelles et met en évidence les questions qui ne sont pas couvertes par la base de connaissances : les nouvelles intentions exprimées par les clients, les sources manquantes, les acronymes non définis et les solutions aux problèmes nécessitant une escalade. Il rédige la mise à jour, et l'opérateur la publie en un seul clic. Il met également en évidence les points sur lesquels les clients rencontrent des difficultés et les cas nécessitant une escalade, afin que l'équipe chargée de l'expérience client sache par quoi commencer.

Ce cycle est essentiel, car les connaissances se déprécient après le lancement. Les produits évoluent, les tarifs changent, les politiques sont réécrites et les clients trouvent de nouvelles façons de poser d’anciennes questions. Un système qui tente de combler ces lacunes en devinant masque cette dépréciation jusqu’à ce qu’elle se transforme en réclamation. Un système qui signale et consigne ces lacunes transforme chaque omission en proposition de mise à jour, approuvée par l’équipe détentrice des connaissances. Par rapport aux architectures reposant sur l’IA générative (GenAI), Encore fonctionne avec des coûts d’exploitation inférieurs d’environ 50 %.

Le fait de refuser de répondre ne frustre-t-il pas les clients ?

C'est pire qu'une simple réponse erronée. Un client à qui l'on dit « Je vais vous mettre en relation avec quelqu'un qui pourra vous le confirmer » perd une minute. Un client à qui l'on indique un délai de remboursement erroné, des frais incorrects ou une règle d'éligibilité erronée perd de l'argent, revient encore plus en colère et, dans un secteur réglementé, peut avoir des motifs valables de réclamation auxquels l'entreprise devra répondre.

Ce compromis s'amenuise à mesure que la couverture s'étend. Les assistants IA en production répondent avec une précision de 98 à 99 %, et Encore associe les questions composées à plusieurs réponses prédéfinies avant de renvoyer une seule réponse ; ainsi, une question en deux parties n'échoue pas simplement parce que l'une des deux parties est inhabituelle. Chaque lacune comblée par Elevate représente un transfert de prise en charge en moins. L'objectif n'est pas d'avoir un assistant qui fait souvent appel à un niveau supérieur, mais un assistant qui le fait pour les bonnes raisons et qui répond correctement le reste du temps.

Quelles questions faut-il poser à un fournisseur concernant le comportement en cas d'absence de réponse ?

Cinq questions permettent de voir comment un assistant se comporte lorsqu'il atteint les limites de ses connaissances.

Que fait l'assistant lorsqu'il n'existe aucune réponse validée : remonter le problème, poser une question de clarification ou générer une réponse quand même ? Qui décide qu’il n’existe pas de réponse : un modèle évaluant son propre niveau de confiance, ou une comparaison avec un ensemble de réponses approuvées ? Que reçoit l’agent humain lors du transfert : la conversation et son contexte, ou un transfert et un nouveau départ ? Où vont les questions restées sans réponse une fois la conversation terminée ? Combien de temps faut-il pour qu’une question manquée devienne une réponse approuvée, et qui l’approuve ?

Demandez ensuite une démonstration en posant une question qui ne figure pas dans la base de connaissances. La manière dont le système traite cette question en particulier vous en apprendra davantage qu’une démonstration portant sur cinquante questions auxquelles il est capable de répondre.