Hallucinations : pourquoi on a arrêté d'essayer de les corriger et ce qu'on fait à la place

Pendant plusieurs mois, on a traité les hallucinations comme des bugs. On ajoutait des instructions dans le prompt, "ne réponds que si tu es sûr", "cite tes sources", "dis-moi si tu ne sais pas". On ajoutait des vérificateurs post-génération. On affinait. Chaque correctif réduisait un type d'hallucination et en déplaçait un autre. On jouait au jeu de la taupe.

Le changement de posture a été de traiter les hallucinations non pas comme un bug à corriger, mais comme une propriété intrinsèque des modèles de langage à contenir architecturalement.

Ce que les hallucinations sont vraiment

Un LLM génère des tokens en maximisant la probabilité selon son entraînement. Il n'a pas de mécanisme de vérification interne, il ne "sait" pas s'il sait. Quand il génère une affirmation factuelle, il produit ce qui est statistiquement plausible dans le contexte, pas ce qui est vrai.

C'est structurel. Aucune instruction dans le prompt ne change cette propriété fondamentale. "Ne dis que ce dont tu es sûr" demande au modèle d'évaluer sa propre certitude, or sa certitude est encodée dans la même distribution de probabilité que produit les hallucinations. La confiance du modèle et l'exactitude factuelle ne sont pas corrélées de façon fiable.

Des études sur GPT-4 montrent que le modèle exprime une haute confiance sur des affirmations incorrectes dans environ 20 % des cas où il hallucine (Kadavath et al., "Language Models (Mostly) Know What They Know", 2022). Cette proportion varie selon le domaine, elle monte sur des sujets de niche ou des dates précises.

Ce qu'on a arrêté de faire

Les instructions méta dans le prompt. "Ne réponds que si tu es certain", "indique ton niveau de confiance de 1 à 10", "signale les informations que tu ne connais pas". Ces instructions changent le style de la réponse, pas sa factualité. Le modèle apprend à formuler des incertitudes rhétoriques sur des informations erronées.

La vérification post-génération par LLM. Utiliser un second LLM pour vérifier la réponse du premier ne résout rien si les deux partagent le même espace de training. Sur des faits de niche, le vérificateur hallucine au même endroit que le générateur.

Le fine-tuning "anti-hallucination". Fine-tuner sur des exemples où le modèle dit "je ne sais pas" produit un modèle qui refuse plus souvent, ce qui dégrade l'utilité sans améliorer la précision sur ce qu'il accepte de traiter.

Ce qu'on fait à la place

Contraindre le contexte de génération

Si le modèle ne génère que sur la base d'un contexte fourni explicitement, les hallucinations factuelles tombent drastiquement. C'est le principe du RAG, mais appliqué comme contrainte architecturale plutôt que comme amélioration optionnelle.

La formulation qu'on utilise dans les prompts système de production :

Tu réponds uniquement à partir des extraits fournis entre les balises <context>.
Si l'information nécessaire n'est pas dans <context>, tu réponds :
"Je n'ai pas trouvé cette information dans les documents fournis."
Tu ne complètes pas les informations manquantes avec tes connaissances générales.

C'est une contrainte forte. Elle change l'expérience utilisateur : le système va refuser de répondre à des questions que le modèle "connaît" mais qui ne sont pas dans le contexte. C'est un choix délibéré, on préfère un refus honnête à une réponse plausible-mais-fausse.

Citation obligatoire de source

Sur les produits où la factualité est critique (assistance médicale, juridique, financière, technique), on impose la citation de source comme contrainte de format, pas comme instruction polie.

SYSTEM_PROMPT = """
Tu es un assistant documentaire. Chaque affirmation factuelle dans ta réponse
doit être suivie d'une référence au format [Doc-X, §Y] pointant vers l'extrait
fourni en contexte. Si tu ne peux pas citer une source pour une affirmation,
ne la fais pas.

Format de réponse attendu :
[Réponse avec citations inline]

Sources utilisées :
- [Doc-X] : {titre_document}
"""

La citation n'est pas juste cosmétique. Elle force le modèle à ancrer chaque affirmation dans du texte source, et rend la vérification humaine possible et rapide. Un utilisateur qui voit "[Doc-3, §2]" peut contrôler. Un utilisateur face à une réponse fluide et sans source ne peut pas.

Décomposer les questions complexes

Les hallucinations sont plus fréquentes sur les questions qui demandent de combiner plusieurs informations ou de raisonner sur du long terme. Sur ces cas, on décompose en sous-questions factuelles simples, chacune ancrée dans une recherche documentaire séparée, avant de synthétiser.

Question : "Quelle est la meilleure stratégie d'investissement pour..."
→ Étape 1 : Récupérer les données factuelles sur chaque option [RAG]
→ Étape 2 : Extraire les critères de comparaison [structuré]
→ Étape 3 : Synthèse en exposant les incertitudes [LLM]

Chaque étape a une source vérifiable. La synthèse finale peut encore contenir des biais de cadrage, mais elle ne contient plus de faits inventés.

Accepter le périmètre restreint

La décision la plus difficile est de réduire le périmètre du produit pour que les hallucinations deviennent rares mécaniquement. Si le produit ne répond qu'à des questions sur un corpus contrôlé et bien indexé, et refuse tout ce qui sort de ce périmètre, les hallucinations factuelles sont rares, non pas parce qu'on les a corrigées, mais parce qu'on a retiré les conditions qui les produisent.

C'est un arbitrage business : un assistant plus capable qui hallucine, ou un assistant plus étroit et plus fiable. La plupart des cas d'usage B2B méritent le second.

Ce qu'on ne peut pas encore résoudre

Les hallucinations de raisonnement, quand le modèle commet une erreur logique sur des prémisses correctes, sont plus difficiles à contenir architecturalement. Le grounding factuel n'y change rien. Les modèles à reasoning explicite (o1, o3, DeepSeek-R1) progressent sur ce point, mais ils introduisent de nouvelles classes d'erreurs dans les étapes intermédiaires.

La question reste ouverte : est-ce qu'un LLM suffisamment contraint peut atteindre un niveau de fiabilité factuelle acceptable pour des usages à haute criticité ? Ou la bonne réponse reste-elle une architecture hybride où le LLM génère une réponse que des règles déterministes valident ?