Hallucinations LLM : comprendre et réduire en production

L'hallucination est le défaut le plus connu — et le plus mal géré — des LLM en production. Le modèle produit une réponse plausible mais factuellement fausse, sans signal pour l'utilisateur ni pour le système. Mal traitée, l'hallucination détruit la confiance, expose à des risques juridiques et tue les usages les plus stratégiques. Voici comment comprendre le phénomène, le mesurer et le réduire de manière mesurable en production.

Définition et typologie des hallucinations

Une hallucination est une sortie du LLM qui contient une information non fondée ou incorrecte, présentée avec un ton aussi assuré qu'une réponse exacte. On distingue plusieurs types :

Hallucination factuelle

• Affirmation d'un fait erroné (date, montant, nom, citation).
• Le plus visible et le plus dangereux.

Hallucination contextuelle

• La réponse contredit le contexte fourni dans le prompt (RAG, documents joints).
• Indique une mauvaise utilisation du contexte par le modèle.

Hallucination intrinsèque

• Le modèle invente du contenu absent à la fois de sa connaissance et du contexte.
• Souvent visible sur les questions « inconnues » mal gérées.

Hallucination extrinsèque

• Le modèle ajoute des détails plausibles mais non vérifiables (interpolation).
• Forme la plus difficile à détecter sans source de vérité.

Pourquoi les LLM hallucinent

Trois causes structurelles, qui s'additionnent souvent :

Nature probabiliste du modèle

Un LLM ne « sait » pas — il prédit le token suivant statistiquement le plus probable. Quand la réponse correcte est rare dans ses données d'entraînement ou ambigüe, il complète par une approximation plausible.

Données d'entraînement

• Bruitées : sources contradictoires ou erronées.
• Datées : connaissance figée au moment de l'entraînement.
• Biaisées : sur-représentation de certains domaines ou points de vue.
• Incomplètes : certains domaines sont absents ou sous-représentés.

Prompt mal cadré

• Question ambigüe : le modèle interprète, parfois faux.
• Pas de garde-fou : aucun moyen pour le modèle de signaler « je ne sais pas ».
• Manque de contexte : le modèle puise dans sa connaissance générale au lieu d'utiliser des sources fournies.

Mesurer le taux d'hallucination

On ne réduit pas ce qu'on ne mesure pas. Trois familles de mesures :

Évaluation automatique

• Comparaison à un référentiel : dataset (question, réponse attendue, sources autorisées). Outils : Ragas, TruLens, Promptfoo.
• Vérification des citations : pour les sorties RAG, vérifier que chaque affirmation est sourcée et que la source contient bien l'information.
• Cohérence interne : mesurer la consistance entre plusieurs générations sur la même question.

LLM-as-a-judge

• Un LLM tiers évalue chaque sortie selon une grille structurée (factualité, complétude, attribution).
• Pratique à grande échelle, à recalibrer périodiquement par échantillonnage humain.

Évaluation humaine

• Annotation manuelle d'un échantillon représentatif.
• Indispensable comme référence pour valider l'évaluation automatique.
• Coût élevé, à réserver aux jeux de référence critiques.

Techniques de réduction

Grounding via RAG

C'est la technique de référence : fournir au modèle le contexte factuel dont il a besoin et lui imposer de s'en tenir à ce contexte.

• Retrieval de qualité : chunks pertinents, reranking, hybrid search (vector + keyword).
• Instructions explicites : « réponds uniquement à partir des documents fournis ; si l'information n'y est pas, dis "je ne sais pas" ».
• Citations : exiger que chaque affirmation soit liée à un passage cité.

Voir RAG vs fine-tuning vs agents IA.

Citations et traçabilité

• Citations inline : forcer le modèle à insérer des références aux sources utilisées.
• Vérification post-génération : valider que chaque citation pointe vers un passage qui supporte effectivement l'affirmation.
• Surlignage côté UX pour permettre à l'utilisateur de vérifier.

Structured outputs

• JSON Schema ou format strict : restreindre le champ des sorties possibles.
• Validation automatique : rejeter ou réessayer si la sortie ne respecte pas le schéma.
• Réduit fortement les hallucinations de format mais pas les hallucinations factuelles.

Instructions défensives

• « Tu n'as pas le droit d'inventer. Si la réponse n'est pas dans les documents, dis-le explicitement. »
• « Ne réponds que si tu es sûr à 100 % et que tu peux citer la source. »
• À combiner avec des mesures côté code (validation des citations).

Self-consistency

• Générer plusieurs réponses indépendantes et garder la plus consistante.
• Réduit le risque d'hallucination ponctuelle au prix d'un coût d'inférence multiplié.

Modèles plus grands ou plus alignés

• Les modèles plus récents et plus grands hallucinent moins sur les sujets standards.
• Les modèles alignés sur la factualité (entraînement spécifique) sont plus prudents.

Architecture anti-hallucination en production

Architecture type :

Question utilisateur
   ↓
Retrieval (RAG hybride + reranking)
   ↓
Prompt avec instructions défensives + citations exigées
   ↓
Génération LLM
   ↓
Validation post-génération (citations vérifiées, schéma validé)
   ↓
Si validation OK → réponse à l'utilisateur
Si validation KO → réponse "je ne sais pas" + escalade

Cette architecture :

• Réduit drastiquement les hallucinations factuelles via le RAG.
• Détecte les hallucinations contextuelles via la validation des citations.
• Refuse explicitement quand le modèle n'est pas fiable.

Cas où l'hallucination est rédhibitoire

Sur certains domaines, l'hallucination est inacceptable et doit être traitée avec une exigence maximale :

• Santé : conseil médical, diagnostic, dosage. Exiger sources médicales validées, supervision humaine.
• Juridique : contrat, recommandation légale, citation de loi. Exiger sources juridiques tracées.
• Finance : conseil d'investissement, calcul comptable. Exiger sources réglementaires.
• Industrie critique : nucléaire, aéronautique, automobile. Exiger boucles de validation strictes.

Sur ces domaines, le LLM est un assistant qui suggère, le professionnel humain décide et porte la responsabilité.

Bonnes pratiques côté produit

L'UX du produit joue un rôle majeur :

• Afficher le niveau de confiance ou la présence/absence de sources.
• Présenter les citations cliquables.
• Indiquer clairement quand le modèle dit « je ne sais pas ».
• Faciliter le feedback utilisateur sur la qualité (thumbs up/down + commentaire).
• Eduquer l'utilisateur sur les limites de l'outil dès l'onboarding.

Conclusion : la fiabilité, nouveau différenciant des produits IA

Réduire les hallucinations n'est pas une option : c'est ce qui sépare un produit IA crédible d'un gadget. Les organisations qui investissent dans l'architecture anti-hallucination, l'évaluation continue et la traçabilité construisent des produits qui durent. Celles qui livrent en production sans cette discipline accumulent les incidents, perdent la confiance et finissent par retirer l'outil.

Pour aller plus loin :

• LLM Engineer : IA générative, RAG et agents
• LLMOps : industrialiser ses modèles IA en production
• RAG vs fine-tuning vs agents IA
• Sécurité des LLM : prompt injection, jailbreak

ForTeam IT positionne des consultants IA capables de bâtir des architectures anti-hallucination robustes chez ses clients : grounding, citations, évaluation continue. Si vous êtes LLM Engineer et que la fiabilité vous tient à cœur, vous êtes au bon endroit.

Rejoindre ForTeam IT