Éviter les hallucinations du LLM grâce à l’IA analytique, c’est possible ?

Introduction

Le succès de ChatGPT a suscité un intérêt massif pour l’IA générative dans le language. Les modèles LLM s’améliorent rapidement et les initiatives d’utilisation au sein des entreprises se multiplient.

Pour le support client, l’automatisation du traitement des demandes entrantes est un sujet de prédilection. Par exemple, la génération automatique de brouillons de réponse peut présenter plusieurs avantages : gain de temps de traitement des demandes et cohérence des réponses entre les agents.

Cependant, l’IA générative peut produire de fausses informations, qu’on appelle hallucinations, qui peuvent avoir des conséquences critiques. La diffusion d’informations incorrectes peut entrainer l’insatisfaction des clients et ainsi impacter la réputation de l’entreprise.

En revanche, l’IA analytique, telle que celle que nous avons développée pour notre produit InboxCare, ne souffre d’aucune hallucination. Le traitement de la donnée textuelle est prédictible et explicable, se synchronise avec les CRM et propose un brouillon de réponse dynamique.

Ce brouillon de réponse est généré sous forme de “template” : En fonction de la catégorie que nous détectons dans un message, nous allons sélectionner le template correspondant.

InboxCare peut bien sûr détecter le nom du client et ainsi personnaliser la réponse, mais il peut également utiliser les informations détectées dans un message pour consolider sa réponse. Par exemple, la détection d’un numéro de commande permet d’aller chercher dans une base de données le statut correspondant, et ainsi enrichir le brouillon de réponse :

Les template, par définition, disposent d’une créativité limitée. Il est possible de personnaliser la réponse dynamiquement en fonction de quelques informations extraites (telles que le nom du client ou le statut de commande), mais le ton ne peut être changé.

Afin d’illustrer ces différences, imaginons donc un graphique à deux axes, l’hallucination d’une part et de l’autre la créativité la réponse. Plaçons sur ce graphique les approches LLM et par template :

Comme mentionné précédemment, le LLM se trouve dans le coin supérieur droit : il peut être très créatif, mais souffre souvent d’hallucinations. Les templates, en revanche, se trouvent en bas, plus près du centre : ils permettent moins de créativité, mais ne souffrent pas d’hallucinations.

Avec cette étude, notre objectif est de tirer le meilleur parti des deux mondes : Utiliser les informations de notre IA analytique afin de limiter les hallucinations d’un LLM, tout en bénéficiant de sa créativité de réponses :

Cadre de notre étude

Pour tester notre théorie, nous avons donc créé quelques faux e-mails adressés aux clients d’une entreprise appelée « ACME », spécialisée dans le mobilier d’intérieur, sur les sujets suivants :

• Annulation : le client souhaite annuler une commande
• Réclamation : le client exprime son mécontentement à propos d’une commande (produit endommagé, mauvais produit, etc.)
• Modification : le client souhaite modifier la commande
• Commande : le client souhaite passer une commande
• Statut de la commande : le client demande une date de livraison

Pour chaque message, nous avons simulé différentes combinaisons en ajoutant ou supprimant des informations provenant du message lui-même

• 1 : Sujet du message
• 2 : Signature du client

Ainsi que des informations pouvant provenir d’InboxCare :

• 3 : Catégorie de message
• 4 : Information consolidée du statut de la commande (quand elle est applicable)
• 5 : Nom du client détecté

Lors de notre étude, nous avons testé les combinaisons suivantes :

Pour finir, nous avons choisi d’utiliser le modèle Llama 2 70b sur des GPU H100 hébergés par Scaleway. Si vous souhaitez en apprendre plus sur notre retour d’expérience quant à cette installation, nous y avons consacré un second article qui paraitra prochainement.

Pour résumer, voici les éléments structurants de nos tests :

Modèle testé	Llama 2 70b
GPU	H100
Hébergeur	Scaleway
Approches testées*	Zero-Shot learning Few-Shot learning
Nombre de test effectués	92
Informations pouvant provenir d’InboxCare	Catégorie du message Nom du client Statut de la commande
Types de message testés	Annulation, Réclamation, Modification, Commande, Statut de la commande
Langue	Anglais

Paramètres d’entrée

Avant de plonger dans les résultats, examinons les paramètres d’entrée les plus importants d’un LLM (que nous appellerons “Input”) que nous pouvons modifier pour faire varier la réponse du modèle (que nous appellerons “output”) : Le prompt, le prompt system et la température :

• Prompt : Dans notre cas, elle contiendra la demande du client accompagnée d’une instruction simple du type “Réponds à ce client”
• Prompt système : Définit le contexte et le comportement que le modèle doit suivre. Dans notre cas, les instructions portent sur son rôle en tant qu’agent de support client, le ton à aborder, le format de la signature etc. Il est important de noter que tandis que le prompt change pour chaque nouvelle demande, le prompt système reste le même.
• Température : Pouvant aller de 0.01 à 5, elle permet de contrôler le degré de créativité de la sortie générée par le modèle.
  • Température élevée : Résultats créatifs, hallucinations fortes
  • Température faible : Résultats plus constants, hallucinations plus faibles

Ainsi, notre objectif pour cette étude est d’ajouter au prompt des informations pouvant provenir d’InboxCare afin de limiter l’hallucination en output :

Notez que d’autres approches étaient possibles, mais celle-ci nous semblait être la plus simple et suffisante pour tester notre théorie.

Ainsi, après de nombreux tests, nous avons trouvé que les paramètres suivants d’input donnaient les meilleurs résultats :

Résultats

Voici le même tableau que précédemment, mais qui cette fois-ci fait ressortir un “score d’hallucination” pour chacun des tests effectués. Ce “score d’hallucination”, de 0 à 3, a été attribué de manière subjective en suivant les règles suivantes :

• Score de 0 : Pas d’hallucination dans la réponse
• Score de 1 : L’hallucination est mineur. Par exemple, le modèle demande une information supplémentaire au client (telle que son adresse ou son numéro de téléphone) ou la confirmation du produit demandé.
• Score de 2 : L’hallucination est importante. Par exemple, le modèle invente un délais de livraison.
• Score de 3 : L’hallucination est critique. Par exemple, le modèle confirme automatiquement une annulation ou invente la disponibilité ou non d’un produit en stock.

Les résultats sembles aléatoires et n’avoir aucune corrélation avec les variables utilisées.

Pour mieux comprendre, analysons en détails deux cas particulièrement intéressants* : D’une part, un cas ou aucune information pouvant provenir d’InboxCare n’a été ajoutée (test 1) et d’autre part, un cas ou les trois informations pouvant provenir d’InboxCare ont été ajoutée (test 5).

*Ces deux cas sont surlignés en jaune sur le tableau ci-dessus

Focus test 1 : Pas d’ajout d’informations provenant d’InboxCare

Input

Please respond to this client:
Subject: Order Order Status - Modern Sofa Set
Hi there,
Could you provide an update on my order for the Modern Sofa Set? Order ID: 45678.
Regards,
Remy Lemoine

Information provided by InboxCare:

Output

Dear Remy Lemoine,

Thank you for reaching out to us regarding your order for the Modern Sofa Set (Order ID: 45678). Our teamis working hard to ensure that your order is processed and shipped as soon as possible. Unfortunately, we do not have any updates available at this time.

Please be assured that we will keep you informed throughout the process, and you will receive an email notification once your order has been shipped. If you have any further questions or concerns, please feel free to reach out to us.

Best regards,
Sophie
Customer Support Agent
ACME Interior Furniture

Du côté positif, le LLM a correctement compris le sujet de l’e-mail, détecté le nom du client, l’ID de commande, l’article en question et respecté les instructions du prompt système.

Cependant, la réponse générée comprenait quelques informations inventées :

• “we will keep you informed throughout the process”
• “you will receive an email notification once your order has been shipped”
• « nous rencontrons un léger retard dans le planning de livraison« 

Regardons maintenant le même exemple, mais en ajoutant les trois informations pouvant provenir d’InboxCare.

Focus test 5 : Ajout d’informations pouvant provenir d’InboxCare

Input

Please respond to this client:
Subject: Order Order Status - Modern Sofa Set
Hi there,
Could you provide an update on my order for the Modern Sofa Set? Order ID: 45678.
Regards,
Remy Lemoine

Information provided by InboxCare: 
Email topic: Order Status 
Order Status: In transit
Client name: Remy Lemoine

Output

Dear Remy Lemoine,

Thank you for reaching out to us regarding your order for the Modern Sofa Set (Order ID: 45678). We apologize for any inconvenience caused and appreciate your patience.

According to our records, your order is currently in transit. Our team is working hard to ensure that it reaches you as soon as possible.

Please note that we do not have access to real-time tracking information. 
However, we can inform you that our delivery team is doing their best to get your order delivered within the estimated timeframe.

We understand that delays can happen, but rest assured that we are doind everything possible to minimize any disruptions. If you have any further
questions or concerns, please feel free to reach out to us.

Best regards,
Sophie
Customer Support Agent
ACME Interior Furniture

En ajoutant des informations provenant d’InboxCare à la demande, le LLM a été en mesure de générer une réponse plus précise et pertinente en fournissant au client une mise à jour sur l’état de sa commande.

Conclusion

Dans l’ensemble, nous avons effectué environ 100 tests en variant les messages, les paramètres et les prompts. Voici nos principales conclusions.

• Le LLM est déjà capable de comprendre et d’utiliser efficacement les informations contenues dans les message (sujet de la demande et nom du client). Ajouter ces mêmes informations provenant d’InboxCare ne semble pas influer sur la qualité du résultat.
• La consolidation d’InboxCare permettant d’obtenir l’information du statut de la commande permet en revanche d’influer sur la qualité du résultat. En effet, nous avons ici fourni au LLM une information dont il ne disposait pas.
• Le prompt engineering influe grandement la qualité et la précision des réponses générées. Ce travail est crucial et ne doit pas être sous-estimé car il demande beaucoup de temps et d’expertise. Par ailleurs, cette pratique relève encore aujourd’hui plus d’un art que d’une science. Même les créateurs de Llama continuent de découvrir comment ce modèle fonctionne.
• Imposer une limitation taille de réponse à fournir (dans notre étude elle était de 40 mots) ainsi que d’imposer une température minimale (dans notre étude elle était à 0.01) sont les deux facteurs qui permettent de limiter le plus les hallucinations.

💡 Depuis peu, un nouveau métier a fait son apparition, celui de “Prompt Engineer”. Son rôle est notamment de trouver les requêtes (ou prompts) les plus adaptés à un besoin donné. Pour en savoir plus, nous vous invitons à lire cet article sur le sujet.

Nous semblons donc faire face à un paradoxe : Afin de limiter au maximum les hallucination du LLM, nous avons “cadrer” fortement le LLM via les instructions dans les prompts ainsi que la température. Mais ce faisant, nous réduisons ainsi la créativité des réponses. Nous ne parvenons pas à atteindre notre idéal

Par conséquent la question de l’intérêt d’utiliser un LLM, au profit d’un système par template, se pose car limiter les hallucinations demande beaucoup d’effort en prompt engineering, sans pour autant avoir la garantie de les supprimer totalement. Cette question est d’autant plus cruciale si l’on souhaite appliquer ces technologies à la réponse automatique**.** Dans ce cas, il est tout bonnement impossible de laisser passer quelconque hallucination.

Bien sûr, davantage d’expérimentations sont nécessaires pour exploiter pleinement son potentiel. Les approches possibles sont énumérées ci-dessous.

Autres axes de recherche

• Explorer d’autres modèles LLM. Par exemple, le modèle Mistral 7b montre de grandes promesses. En expérimentant avec différents LLM, nous pouvons identifier le modèle qui convient le mieux à nos besoins et objectifs spécifiques.
• Affiner le prompt engineering. En fournissant plus d’effort dans l’écriture du prompt et du prompt system, nous pourrions probablement obtenir de meilleurs résultats.
• Affiner spécifiquement le modèle LLM pour notre cas d’utilisation du support client peut également être bénéfique. Ce processus, appelé “fine-tuning” permet au modèle d’apprendre à partir d’exemples qui ressemblent étroitement aux types de message qu’il rencontrera dans des situations réelles. En affinant le modèle, nous pouvons améliorer sa compréhension des demandes des clients et la qualité de ses réponses générées.
• Déclencher l’utilisation d’un LLM seulement pour certaines catégories de message. Par exemple, la catégorie “Demande d’information” pourra déclencher, l’utilisation d’un LLM car une légère hallucination pourrait être acceptable. En revanche, la détection d’un catégorie “Réclamations” déclencherai l’utilisation d’un template de réponse, car aucune hallucination ne serait acceptable.

---

Dans la deuxième partie de cet article, nous explorerons notre expérience de l’exécution d’un modèle de langage (LLM) sur notre infrastructure, en utilisant la dernière offre GPU de Scaleway. Nous aborderons la configuration et la mise en place du LLM, y compris le matériel et le logiciel utilisés.