Ajouter un chatbot IA à Discourse est facile (grâce à deux excellents plugins). En revanche, ajouter un chatbot capable d’assurer un support technique est beaucoup plus complexe ! Ce partage d’expérience retrace notre mise en place d’un chatbot de support technique pour support.suretyhome.com : ce que nous souhaitions, les problèmes rencontrés, comment nous les avons résolus, et nos perspectives d’évolution.
Notre équipe de support n’est disponible que pendant les heures ouvrées, mais nos clients souhaitent une assistance 24h/24 et 7j/7. Nous ne cherchons pas à remplacer l’équipe de support. Notre objectif est de l’augmenter grâce à un bot qui soit :
- Disponible 24h/24 et 7j/7, y compris la nuit et les week-ends, tout comme notre forum
- Réactif immédiatement, alors que notre équipe humaine prend un peu plus de temps
- Capable de répondre à des questions que les utilisateurs ne parviennent pas à résoudre via une recherche sur le forum
Voici notre expérience.
Choix du Plugin
Il existe deux excellents plugins offrant un chatbot IA.
Le plugin Discourse AI est le plugin officiel d’IA de l’équipe de développement de Discourse. Il inclut un chatbot ainsi que d’autres fonctionnalités d’IA. Le plugin Discourse Chatbot se concentre uniquement sur le chatbot. Il a été créé avant Discourse AI et vise à exceller dans cette seule fonction.
Initialement, nous ne savions pas lequel choisir, j’ai donc posé la question ici pour obtenir des conseils.
Nous avons reçu beaucoup d’aide précieuse. Nous avons finalement opté pour Discourse Chatbot car il est plus flexible en tant que chatbot, avec plus d’options (« cloches et sifflets ») pour la personnalisation. Notre cas d’usage comportait des exigences spécifiques qui ne semblaient pas encore réalisables avec Discourse AI. Les deux peuvent être d’excellents choix. Lequel convient le mieux dépend des besoins spécifiques de votre forum.
Configuration Initiale
La configuration initiale de Discourse Chatbot peut s’apparenter à un véritable projet, car il existe de nombreuses options à choisir et des personnalisations à effectuer. Suivez attentivement les instructions de configuration et assurez-vous d’examiner tous les paramètres.
Notre objectif était de fournir une expérience de type chat, nous ne souhaitions donc que le bot fonctionne dans Discourse Chat, et non dans les sujets publics ou les messages privés. Les premières étapes que nous avons dû suivre étaient :
- Configurer Discourse Chat (Discourse Chatbot en dépend)
- Dans les paramètres de Discourse Chatbot, activer l’option chatbot permitted in chat (chatbot autorisé dans le chat)
Ingénierie des Prompts
Discourse Chatbot est incroyablement personnalisable. Tout ce qui n’est pas un paramètre est personnalisé dans Discourse > Personnaliser > Texte. C’est ici que vous effectuez toute votre ingénierie de prompts. Dans Personnaliser > Texte, recherchez chatbot.prompt pour filtrer et afficher tous les textes de prompts personnalisables.
Pour que le bot se comporte comme nous le souhaitons, nous devons modifier le prompt système. Mais il y en a deux : l’un pour les discussions publiques et l’autre pour les discussions privées. Comme nous n’utilisons le bot que dans des canaux de chat privés, nous avons dû modifier chatbot.prompt.system.rag.private.
En tant que bot de support technique, il doit être plus conservateur et précis que les LLM ne le sont généralement par défaut. Notre prompt système devait être relativement long pour y parvenir. Dans le prompt système, donnez au LLM des instructions et un contexte permettant de répondre à des questions telles que :
- Qui est votre bot ? Quel rôle doit-il jouer ?
- Quelles informations de base ou quel contexte doit-il connaître ?
- Quels sujets est-il censé discuter ? Quels sujets ne doit-il jamais aborder ?
- Quel style d’écriture ou quel ton doit-il utiliser ?
- Que doit-il faire lorsque l’utilisateur est frustré ?
En plus de cette ingénierie de prompts générale, le prompt système est également un endroit où vous pouvez tenter de résoudre des problèmes découverts lors des tests. Si vous constatez que votre bot commet une erreur flagrante, vous pourrez peut-être la corriger en ajoutant des instructions au prompt système. Mais attention, le prompting n’est qu’une suggestion pour le LLM. Vous ne le programmez pas. Vous lui demandez simplement de se comporter d’une certaine manière. Il pourrait ne pas vous écouter.
Température et Top P
Un autre outil pour rendre le bot plus conservateur et moins enclin à inventer des informations est le paramètre de température. Par défaut, la température est réglée sur 100, ce qui correspond à 50 % de la température maximale. Vous pouvez la réduire davantage pour rendre le bot plus conservateur ou déterministe, et moins susceptible de faire des erreurs. Cependant, lorsque la température est très basse (comme 0), le LLM ne semble pas aussi impressionnant. C’est un compromis que vous devrez faire.
En plus de la température, il existe le paramètre Top P. Vous n’en aurez probablement pas besoin, mais il est là si nécessaire. Consultez la documentation OpenAI pour plus d’informations.
Les paramètres de Discourse Chatbot pour cette section sont :
- chatbot request temperature
- chatbot request top p
Problème : Le LLM est Imprécis et Obsolète
Le LLM a été entraîné sur une vaste quantité de données générales, il y a quelque temps. Nous avons besoin qu’il dispose des informations les plus récentes et les plus spécifiques concernant notre forum, et qu’il soit aussi précis que possible. La solution est la Génération Augmentée par Récupération (RAG).
Le RAG recherchera des informations supplémentaires sur le forum avant de répondre à l’utilisateur. En tant que bot de support technique, nous ne pouvons pas nous fier uniquement aux connaissances acquises lors de l’entraînement du LLM ; nous devons que le bot recherche des informations techniques sur notre forum avant de répondre.
Pour mettre en œuvre le RAG, Discourse Chatbot doit créer une base de données d’« embeddings » qui représentent chacun de nos messages de forum sous forme de vecteurs de « caractéristiques » sémantiques. Cela doit être activé, mais je recommande d’attendre d’avoir configuré votre stratégie d’embeddings avant de l’activer, ce que nous aborderons dans la section suivante.
Les paramètres de Discourse Chatbot pour cette section sont :
- chatbot bot type high trust : RAG
- chatbot bot type medium trust : RAG
- chatbot bot type low trust : RAG
- chatbot embeddings enabled : activé (après avoir configuré la stratégie d’embeddings)
Problème : De nombreux messages du forum ne sont pas utiles
Faire rechercher le bot sur votre forum avant de répondre (RAG) est une excellente idée, mais cela introduit un nouveau problème. De nombreux messages sur un forum ne sont pas très utiles. Certains sont pertinents, et ce sont ceux que vous souhaitez que le bot trouve, mais beaucoup sont simplement conversationnels, confus, ou carrément erronés. Notre solution consiste à créer une base de connaissances (KB) ne contenant que les messages que nous souhaitons que le bot trouve.
Pour cela dans Discourse Chatbot, nous utilisons la stratégie categories embeddings. La stratégie d’embeddings détermine quels messages sont accessibles au chatbot lors de sa recherche sur le forum. Notre approche consiste à utiliser une seule catégorie non publique comme base de connaissances du chatbot, nous avons donc choisi categories comme stratégie d’embeddings. La catégorie de la base de connaissances doit également être identifiée dans le paramètre embeddings categories.
Nous utilisons une catégorie non publique (visible uniquement par le personnel) car nous dupliquons de nombreux sujets publics dans cette catégorie et ne souhaitons pas que les utilisateurs voient les doublons. La duplication de sujets dans une catégorie privée soulève quelques autres problèmes.
- C’est beaucoup de travail de les copier, et pire encore de maintenir les copies lorsque les sujets sont mis à jour ou que de nouvelles réponses sont ajoutées.
- Les sujets que le bot trouve lors de sa recherche sur le forum ne sont pas des sujets publics auxquels les utilisateurs devraient recevoir des liens en référence. Nous devons envoyer au LLM des liens vers les sujets publics.
Pour résoudre ces deux problèmes, nous avons créé des outils minimaux pour nous aider à copier des sujets depuis des catégories publiques vers notre catégorie privée de base de connaissances du chatbot, et à maintenir ces copies à jour lorsque les sujets publics sont modifiés. Ils sont disponibles ici si vous souhaitez adopter la même approche que nous.
Les outils KB importent un sujet public entier dans la catégorie privée KB sous forme de nouveau sujet avec un seul message, en concaténant tous les messages du sujet public et en ajoutant un lien vers chaque message public avant son contenu. Ainsi, lorsque le bot trouve le message privé KB lors d’une recherche RAG, il obtient le contenu de tout le sujet public et les URL des messages publics qu’il peut inclure dans sa réponse comme références.
Les paramètres de Discourse Chatbot pour cette section sont :
- chatbot embeddings strategy : categories
- chatbot embeddings categories : (votre catégorie privée KB)
- chatbot forum search function include topic titles : désactivé (par défaut)
De plus, vous devez supprimer certaines clés d’interpolation du prompt de recherche sur le forum car elles ne sont pas pertinentes lorsque les messages sont dans une catégorie privée.
- chatbot.prompt.function.forum_search.answer.topic.each.post : Supprimer %{username} et %{date}
- chatbot.prompt.function.forum_search.answer.topic.each.topic : Supprimer %{title} et %{url}
Problème : Le LLM ne lance pas assez de recherches RAG
Maintenant que nous avons une catégorie privée remplie de messages sélectionnés contenant uniquement de bonnes informations pour servir de base de connaissances à notre chatbot, tout devrait bien se passer, n’est-ce pas ? Faux. Le problème suivant que nous avons rencontré est que la fonction de recherche RAG n’était pas utilisée suffisamment souvent par le LLM.
Les LLM comme GPT-4 sont tout juste assez intelligents pour être dangereux. Ils pensent souvent qu’ils connaissent déjà la réponse et n’ont pas besoin de demander de l’aide, alors qu’en réalité, ils devraient effectuer une recherche RAG et chercher la réponse dans la base de connaissances. Pour résoudre cela, nous utilisons l’option de choix d’outil et forçons le LLM à appeler une fonction.
Nous pourrions forcer une recherche locale sur le forum, mais nous avons constaté que forcer simplement un appel de fonction suffit, et nous voulons laisser au LLM la liberté d’appeler parfois une autre fonction au lieu de faire une recherche sur le forum.
Les paramètres de Discourse Chatbot pour cette section sont :
- chatbot tool choice first iteration : force_a_function
Problème : Performance de la recherche sur le forum
En forçant un appel de fonction, le LLM effectue de manière fiable une recherche RAG pour presque chaque réponse. Mais nous obtenions encore de mauvais résultats. Le bot ne trouvait pas les bons messages dans la base de connaissances. Avec autant d’informations dans nos messages, il y avait beaucoup de « bruit » qui interférait avec la capacité de la fonction de recherche à trouver le meilleur message.
Par exemple, imaginons que l’utilisateur demande au bot comment empêcher son imprimante HP Laser Jet de biper. Le LLM pourrait effectuer une recherche sur le forum avec la requête « HP LaserJet stop beeping ». Il pourrait y avoir un message dans la base de connaissances qui traite parfaitement ce problème, mais la partie « question » de ce message (qui correspondrait étroitement à la requête) ne représente que 2 % du texte du message. Les 98 % restants du texte sont les étapes de dépannage et les réponses.
La recherche locale sur le forum de Discourse Chatbot est une recherche sémantique qui utilise les embeddings vectoriels pour trouver le message (ou les quelques messages) le plus similaire à la requête. La partie question du meilleur message est très similaire à la requête, mais elle ne représente que 2 % du texte global. Les 98 % restants du texte rendent le message moins similaire à la requête, de sorte que le message ne se classe pas haut dans les résultats de recherche pour cette requête.
Notre solution à ce problème consiste à ajouter des « messages appâts » à nos sujets de la base de connaissances, contenant uniquement du texte similaire à la requête de recherche. Dans notre exemple ci-dessus, nous pourrions ajouter un message appât contenant simplement « HP Laser Jet beeping ». La fonction de recherche locale sur le forum trouvera facilement le message appât car il est très similaire à la requête. Ensuite, Discourse Chatbot enverra le contenu du vrai message, qui inclut la réponse, au LLM au lieu du message appât.
Comme nos sujets KB ont tout leur contenu dans le premier message, nous pouvons utiliser les réponses dans les sujets KB comme messages appâts. Après avoir utilisé nos outils KB pour importer des sujets dans la base de connaissances, nous pouvons simplement répondre aux sujets KB pour créer des messages appâts.
Les paramètres de Discourse Chatbot pour cette section sont :
- chatbot forum search function results content type : topic
- chatbot forum search function results topic max posts count strategy : just_enough
- chatbot forum search function results topic max posts count : 1
Les messages appâts offrent un mécanisme puissant pour optimiser la base de connaissances pour la recherche, mais vous devez le faire à l’aveugle. Vous ne pouvez pas voir les recherches en temps réel, il est donc difficile de déterminer exactement comment vos messages appâts impactent le classement des recherches. Pour résoudre ce problème, nous avons créé un petit programme qui effectue la même recherche sémantique que Discourse Chatbot, mais localement sur votre ordinateur et affiche tous les détails tels que les scores de similarité et le classement. Cela rend beaucoup plus facile la création de messages appâts qui améliorent réellement les performances de recherche et optimisent la base de connaissances.
La combinaison du RAG, d’une base de connaissances sélectionnée, de la force imposée au LLM d’appeler une fonction, et des messages appâts a finalement donné un chatbot de support technique plutôt efficace ! 
Le LLM Hallucine des URL
Bien que le bot s’en sortît bien pour répondre aux questions techniques, il présentait toujours un problème d’hallucination gênant. Il hallucinait fréquemment des URL dans ses réponses à l’utilisateur. C’est un problème connu avec les LLM et le consensus général est qu’il faut simplement l’accepter. Nous ne voulions pas que nos utilisateurs aient à faire avec cela.
Comme notre bot assure un support technique, nous nous appuyons fortement sur le RAG pour fournir au LLM des informations précises et à jour. Nous le forçons à effectuer une recherche RAG avant chaque réponse. Nous nous appuyons sur le LLM pour « comprendre » et communiquer avec l’utilisateur, mais nous nous appuyons presque entièrement sur notre base de connaissances pour les informations techniques utilisées pour répondre à leurs questions. Nous pouvons exploiter cela pour empêcher le bot d’halluciner des URL.
Notre solution consiste à ajouter une contrainte au bot afin qu’il ne puisse inclure une URL dans sa réponse que si cette URL provient d’un résultat de recherche sur le forum. Si le LLM tente d’inclure une URL qui n’était pas déjà dans un résultat de recherche sur le forum, Discourse Chatbot informera le LLM du problème et lui demandera de réessayer. Cette simple astuce a efficacement éliminé les hallucinations d’URL.
Les paramètres de Discourse Chatbot pour cette section sont :
- chatbot url integrity check : activé
Problème : Le Chatbot ne peut pas tout gérer
Certaines questions de support ne peuvent absolument pas être traitées par le chatbot car elles nécessitent une action à entreprendre. Par exemple, si une modification de compte doit être apportée ou si un produit doit être retourné (ce qui nécessite un remboursement et/ou une autorisation), le bot ne peut pas le faire.
Cela dépend aussi de la complexité. De nombreuses questions sont simples : si l’utilisateur avait simplement recherché sur le forum avec la bonne requête, il aurait trouvé la réponse. Dans ce cas, le bot est assez bon pour rechercher sur le forum, trouver la réponse et la lui présenter. Mais lorsque le problème nécessite une enquête ou une analyse complexe, le bot donne souvent une réponse générique qui n’apporte pas beaucoup de valeur.
Dans l’une ou l’autre de ces situations où le bot ne peut pas gérer le problème, nous devons qu’il transfère la conversation à notre équipe de support humaine. Discourse Chatbot dispose d’une fonction permettant au LLM de faire exactement cela, appelée escalate to staff (transférer au personnel).
Les paramètres de Discourse Chatbot pour cette section sont :
- chatbot escalate to staff function : activé
- chatbot escalate to staff groups : (le groupe vers lequel transférer)
Nous forçons déjà le LLM à appeler une fonction avant de répondre, mais maintenant se pose la question de savoir quelle fonction appeler. Le LLM doit-il appeler la fonction local forum search (RAG) ou la fonction escalate to staff ? Il doit prendre cette décision à chaque fois qu’un utilisateur lui envoie un message. La plupart du temps, nous voulons qu’il appelle local forum search. Nous ne voulons qu’il transfère au personnel que lorsqu’il ne peut pas gérer le problème, qu’il remarque que l’utilisateur est frustré, ou que l’utilisateur le demande explicitement.
Nous utilisons le prompting pour guider le LLM sur la façon de décider quelle fonction appeler. Les textes de prompts que vous pouvez modifier pour cela dans Personnaliser > Texte sont :
- chatbot.prompt.system.rag.private
- chatbot.prompt.function.forum_search.description
- chatbot.prompt.function.escalate_to_staff.description
Problème : Impossible de surveiller les conversations
Lorsque les utilisateurs utilisent réellement le chatbot, il est utile de voir les conversations et de surveiller les mauvaises réponses ou les opportunités d’amélioration. Mais Discourse ne fournit pas de moyen pour les administrateurs de lire les chats, ce qui est logique car les chats sont généralement des conversations privées entre personnes. Cependant, les conversations avec le bot de support ne sont pas des conversations privées, et si nous ne pouvons pas les examiner, nous ne pouvons pas améliorer continuellement le bot.
La bonne nouvelle est que Discourse offre aux administrateurs un moyen d’exporter l’historique complet des chats du forum sous forme de fichier CSV.
Pour résoudre ce problème, nous avons créé un petit programme qui convertit le fichier CSV de l’historique des chats en une série de fichiers HTML, un pour chaque utilisateur ayant discuté avec le bot. Nous ne pouvons pas surveiller l’utilisation du bot en temps réel, mais avec cette solution, nous pouvons exporter périodiquement l’historique des chats, le convertir en fichiers HTML et les examiner pour travailler à l’amélioration de notre bot.
Conclusion
Après avoir résolu chacun de ces problèmes et suffisamment sélectionné la base de connaissances, nous avons enfin pu permettre aux utilisateurs de commencer à utiliser le chatbot.
Jusqu’à présent, les résultats sont mitigés. C’est excitant lorsque nous voyons des personnes utiliser le chatbot la nuit et les week-ends, obtenir des réponses à leurs questions et résoudre leurs problèmes. C’est révélateur lorsque nous voyons des personnes essayer d’utiliser le chatbot sans avoir une bonne expérience. Cela signifie généralement qu’il manque quelque chose ou que quelque chose est peu clair dans notre base de connaissances. Parfois, nous constatons un problème nécessitant une amélioration du prompt système. Et parfois, il est clair qu’il y a de la confusion et que nous devons améliorer la façon dont nous présentons le chatbot à l’utilisateur.
Nous avons constaté qu’environ la moitié des conversations nécessitaient un transfert au personnel. Environ la moitié de ces transferts concernaient des cas où le bot n’aurait absolument pas pu gérer la situation. L’autre moitié (environ 25 % des conversations) concernait des cas où le bot aurait pu résoudre le problème mais a échoué, ce qui représente des opportunités d’amélioration.
Parmi les conversations qui ne se soldent pas par un transfert au personnel, il est difficile de savoir si l’utilisateur a réellement résolu son problème ou s’il a simplement abandonné et quitté. Il est évident lorsque le bot donne une mauvaise réponse ce qu’il faut améliorer. Ce n’est pas toujours évident lorsque le bot donne des réponses raisonnables et bonnes de savoir si l’utilisateur a pleinement compris et si son problème a été résolu, sauf s’il nous le dit.
Dans l’ensemble, nous sommes satisfaits de cette première itération du chatbot de support Surety et nous attendons avec impatience que le LLM s’améliore ainsi que notre base de connaissances au fil du temps. Travailler sur la base de connaissances est notre tâche principale actuellement.
Discourse Chatbot a ajouté le support de la recherche hybride (à la fois sémantique et textuelle) depuis que nous avons commencé ce projet, nous allons donc probablement expérimenter cela bientôt.
Merci à @merefield pour tout son travail acharné sur le plugin Discourse Chatbot ! Ce fut très amusant à travailler et il s’est avéré à la hauteur de la tâche.
Si quelqu’un d’autre décide de créer un chatbot de support technique pour son forum, n’hésitez pas à me contacter ! Ce serait formidable d’avoir d’autres personnes avec qui collaborer et échanger des idées. Je mettrai à jour à nouveau lorsque des choses intéressantes se produiront, des changements seront apportés ou que nous apprendrons quelque chose de nouveau.