Détecter et limiter les erreurs inventées par un LLM

Un modèle de langage peut produire une réponse fausse avec la même assurance qu’une réponse correcte, sans aucun signal apparent de doute. Ce cours explique pourquoi ce phénomène se produit, comment le repérer, et quelles techniques permettent de le réduire sans jamais l’éliminer complètement.

Objectifs#

• Comprendre pourquoi un LLM peut générer une hallucination
• Identifier les situations à risque élevé d’hallucination
• Connaître les principales techniques de détection et de mitigation
• Savoir dans quelle mesure le RAG résout ou non ce problème

Qu’est-ce qu’une hallucination#

Une hallucination est une sortie produite par un modèle de langage qui est factuellement incorrecte, non vérifiable, ou qui invente des détails (source, citation, référence, résultat de calcul) sans base réelle dans ses données d’entraînement ni dans le contexte fourni. Le terme couvre aussi bien une date erronée qu’une API inexistante suggérée dans du code, ou une citation attribuée à la mauvaise personne.

Il ne s’agit pas d’un bug ponctuel corrigible, mais d’une conséquence directe du mécanisme même de génération : un LLM prédit le token le plus probable compte tenu du contexte, il ne consulte pas une base de faits vérifiés au moment de répondre. Une réponse fluide et bien formulée n’est donc pas un indicateur de sa véracité.

Pourquoi ce n’est pas qu’un problème de taille de modèle#

Augmenter la taille d’un modèle réduit certaines hallucinations (celles liées à un manque de connaissances) mais n’élimine pas les autres catégories, notamment les hallucinations liées à une extrapolation au-delà du contexte fourni ou à une mauvaise interprétation d’une question ambiguë. Un modèle plus grand peut même halluciner avec davantage d’assurance apparente, ce qui rend l’erreur plus difficile à repérer pour un lecteur non averti.

Les causes techniques principales#

Trois mécanismes distincts expliquent la majorité des hallucinations observées.

• Lacune de connaissances : le modèle n’a jamais rencontré l’information demandée dans ses données d’entraînement (événement récent, donnée propriétaire, sujet de niche), mais génère malgré tout une réponse plausible plutôt que d’exprimer une incertitude.
• Extrapolation excessive : le modèle prolonge un motif appris au-delà de ce que les données justifient réellement, par exemple en inventant un paramètre d’API plausible mais inexistant parce que d’autres API similaires possèdent un paramètre au nom proche.
• Perte de contexte : sur une conversation longue ou un document volumineux, le modèle peut mal repondérer une information mentionnée plus tôt, ou fusionner deux faits distincts en un seul énoncé erroné.

Situations à risque élevé#

Certains types de demandes concentrent statistiquement davantage d’hallucinations, et méritent une vérification systématique de la réponse.

Techniques de détection#

Repérer une hallucination avant qu’elle ne soit utilisée telle quelle repose sur des méthodes complémentaires, pas sur une seule.

• Vérification humaine ciblée : relire en priorité les passages à risque élevé identifiés ci-dessus, plutôt que l’intégralité du texte de façon uniforme.
• Demande de sources : demander au modèle de citer ses sources ne garantit pas leur exactitude, mais permet de vérifier chaque affirmation indépendamment si les sources sont elles-mêmes contrôlables.
• Modèle juge : faire évaluer la réponse d’un premier modèle par un second appel, avec un prompt dédié à la détection d’incohérences factuelles, une pratique de plus en plus courante en production.
• Cohérence interne : demander la même question reformulée plusieurs fois et comparer les réponses ; une forte divergence entre les réponses est un signal d’incertitude du modèle sur le sujet.

Le RAG comme parade partielle#

Le RAG (retrieval-augmented generation) consiste à injecter dans le prompt des extraits de documents pertinents, récupérés au moment de la requête, plutôt que de laisser le modèle répondre uniquement à partir de ses connaissances internes.

Question utilisateur
   -> Recherche de documents pertinents (base vectorielle, moteur de recherche)
   -> Extraits injectés dans le prompt comme contexte
   -> Génération de la réponse par le modèle, ancrée sur ces extraits

Le RAG réduit sensiblement les hallucinations liées à une lacune de connaissances, puisque le modèle dispose directement de l’information recherchée dans son contexte plutôt que de devoir la deviner. Il ne les élimine pas pour autant.

Le RAG déplace donc une partie du risque d’hallucination vers la qualité du système de recherche documentaire (pertinence des extraits retournés, fraîcheur de l’index, gestion des documents contradictoires), sans supprimer le besoin de vérification en aval.

Points clés à retenir#

• Une hallucination n’est pas un bug isolé mais une conséquence du mécanisme de génération d’un LLM
• Le risque varie fortement selon le type de demande : citations, chiffres et API sont particulièrement exposés
• Aucune technique de détection n’est suffisante seule, la combinaison de plusieurs méthodes reste nécessaire
• Le RAG réduit les hallucinations liées au manque de connaissances mais ne les élimine pas, et introduit ses propres risques

Références#

• Le TP associé propose un exercice pratique de détection d’hallucinations sur des réponses générées, avec construction progressive d’une checklist de vérification.
• Le quiz associé permet de vérifier votre compréhension des causes et des techniques de mitigation avant de passer au TP.