Hallucinations des LLM — comment les détecter, les réduire et gérer le risque en production

Ce que sont les hallucinations et pourquoi elles apparaissent

Une hallucination dans un LLM est la génération d’une information qui sonne crédible, mais qui est factuellement fausse ou non justifiée. Ce n’est pas une « erreur » au sens d’une panne système — c’est une conséquence du fonctionnement des modèles de langage. Le LLM ne « sait » pas comme une base de données — il prédit le token suivant le plus probable, basé sur les statistiques d’entraînement. Quand le prompt contient une question pour laquelle le modèle n’a pas une bonne couverture dans les données d’entraînement, il génère la réponse « qui sonne la plus probable ». Souvent cette réponse est correcte. Parfois — non.

Scénarios typiques d’hallucinations dans les applications métier :

Citation d’arrêts de tribunaux ou de paragraphes de lois inexistants dans le conseil juridique
Invention de noms de fonctions, classes ou bibliothèques lors de la génération de code
Énoncé de statistiques ou dates incorrectes dans les rapports
Invention de contacts, adresses, numéros de téléphone
Mélange de faits concernant différentes entreprises ou personnes aux noms similaires

Couche 1 — Grounding (RAG)

La technique unique la plus efficace pour réduire les hallucinations est le grounding — fournir au modèle des documents ou données concrètes comme contexte d’où il doit puiser ses réponses. RAG classique (Retrieval-Augmented Generation) :

Question utilisateur → recherche des fragments de documents les plus pertinents (vector search dans une base pgvector / Qdrant / Milvus)
Fragments + question → prompt avec l’instruction « réponds uniquement sur la base des documents ci-dessous »
Réponse du modèle → vérification qu’elle contient des citations/références aux sources

Le RAG réduit typiquement les hallucinations de 60-80 % dans les cas d’usage du type « réponds aux questions sur notre base de connaissances ». Il ne les élimine pas complètement — le modèle peut toujours « interpréter » les documents de manière non justifiée. D’où la nécessité de couches supplémentaires.

Couche 2 — Self-consistency et ensemble

La self-consistency est une technique consistant à poser la même question plusieurs fois (ou à plusieurs modèles différents) et à comparer les réponses. Quand les réponses sont cohérentes — haute confiance. Quand elles diffèrent — signal que le sujet est incertain.

Variante pratique : posez à Claude Sonnet, Llama 70B et Bielik la même question. Si les trois renvoient le même nombre, la même date, le même fait — probablement correct. S’ils diffèrent — escalade vers l’humain ou vers un modèle plus coûteux (Opus). Ce pattern, implémenté dans le routage LLM à 8 niveaux, combine réduction des coûts et amélioration de la fiabilité.

Couche 3 — Pipelines d’évaluation

Un déploiement LLM en production sans pipeline d’évaluation, c’est comme écrire du code sans tests. Métriques concrètes :

Faithfulness — la réponse découle-t-elle des documents fournis. Mesurée par un second modèle IA (LLM-as-judge) ou une bibliothèque comme RAGAS, deepeval.
Answer relevance — la réponse adresse-t-elle la question de l’utilisateur.
Context precision — les meilleurs fragments ont-ils été retournés par le retrieval (qualité du vector search).
Groundedness score — pourcentage d’affirmations dans la réponse pour lesquelles on peut indiquer une source dans le contexte.

Chaque nouveau build d’une application basée sur un LLM devrait passer un ensemble de 50-500 questions d’évaluation avec une ground truth connue. Si la faithfulness tombe sous 90 % — déploiement bloqué.

Couche 4 — Guardrails et validation de la sortie

Les guardrails sont des règles validant la sortie du LLM avant sa livraison à l’utilisateur. Exemples :

Validation de schéma — la sortie doit respecter un schéma concret (JSON Schema, Pydantic). Les hallucinations du type « champs inventés » sont détectées mécaniquement.
Forbidden patterns — détection et blocage de patterns inadmissibles (PII sans masquage, données financières hors contexte, contenus potentiellement nuisibles).
Citation enforcement — chaque affirmation factuelle doit avoir une citation source. Si le modèle ne cite pas — la réponse est rejetée.
Validation de plages numériques — les nombres dans la sortie sont vérifiés du point de vue du sens (par exemple, prix > 0, date ≤ aujourd’hui, pourcentage dans la plage 0-100).
Cross-reference check — comparaison de la sortie avec une base de faits (par exemple KRS, dictionnaire de citations de lois).

Bibliothèques : Guardrails AI, NeMo Guardrails, instructor (pour schema enforcement). Une implémentation maison est souvent plus simple et moins coûteuse à maintenir.

Couche 5 — Human-in-the-loop

Pour les applications à haut risque (décisions juridiques, médicales, financières, RH), la couche human-in-the-loop est indispensable. Les modèles IA ne prennent pas la décision finale — ils soutiennent l’humain. Patterns concrets :

Draft + review — l’IA génère la première version du document/de la réponse, l’humain vérifie et accepte avant l’envoi.
Seuil de confiance — les réponses à faible confiance (issues de self-consistency ou d’une demande explicite de confiance) sont automatiquement escaladées vers l’humain.
QA par échantillonnage aléatoire — 5-10 % de toutes les réponses du LLM sont auditées manuellement, indépendamment de la confiance — métrique de qualité de base dans le temps.
Boucle de feedback — l’utilisateur peut marquer une réponse erronée ; le système apprend et améliore le retrieval, les prompts, les paramètres.

Mesure — comment savoir si la réduction fonctionne

Métriques de production concrètes à surveiller :

Taux d’hallucination — pourcentage de réponses classifiées comme hallucinations dans l’évaluation manuelle (sampling). Objectif : moins de 2 % pour les applications business-critical.
Taux de feedback utilisateur — pourcentage d’utilisateurs qui ont marqué la réponse comme erronée.
Taux d’escalade — pourcentage de requêtes escaladées vers l’humain. Trop bas (moins de 5 %) — le système passe probablement à côté des cas incertains. Trop haut (plus de 30 %) — le système ne fournit pas de valeur d’automatisation.
Score de faithfulness dans les tests de régression — tendance mensuelle.
Time-to-correction — de la détection de l’hallucination à l’implémentation de la correction (meilleur retrieval, nouveau guardrail, fine-tuning).

Conclusions pour les décideurs

Les hallucinations sont gérables — elles nécessitent un investissement dans une architecture défensive à plusieurs couches. Les entreprises qui déploient des LLM sans cette architecture rencontreront tôt ou tard un incident grave (publication d’informations erronées à un client, mauvaise décision basée sur des données hallucinées, dommage réputationnel). Le coût de la construction d’un stack défensif complet (RAG + évaluation + guardrails + human-in-the-loop) représente typiquement 15-30 % du coût du déploiement LLM lui-même — et c’est un investissement absolument nécessaire pour les usages en production. Les conséquences de son omission sont asymétriques : faible coût d’inaction dans 95 % des cas, catastrophique dans 5 %.