L'hallucination — la tendance des LLM à inventer des informations présentées avec assurance — est la principale raison pour laquelle de nombreuses directions hésitent encore à déployer l'IA sur des processus critiques. Un LLM qui invente des chiffres, des références juridiques ou des spécifications techniques peut causer des dommages opérationnels significatifs. Le RAG est la réponse architecturale à ce problème, mais encore faut-il l'implémenter correctement.

Pourquoi les LLM hallucinent-ils ?

Les LLM génèrent du texte en prédisant le token le plus probable à chaque étape, basé sur leur entraînement. Quand ils ne connaissent pas la réponse à une question, ils génèrent quand même du texte plausible — c'est leur mode de fonctionnement fondamental. Il n'y a pas de mécanisme natif pour "ne pas savoir" ou distinguer ce qui est mémorisé de ce qui est inventé.

Les 6 techniques pour éliminer les hallucinations

1. Prompting défensif : forcer le refus en cas d'incertitude

Incluez dans votre system prompt : "Si la réponse n'est pas présente dans les documents fournis en contexte, réponds exactement : 'Je ne trouve pas d'information sur ce sujet dans les documents disponibles.'" Cette instruction seule réduit les hallucinations de 60 à 80 %.

2. Citation obligatoire des sources

Demandez au modèle de citer explicitement le document et le passage d'où provient chaque information. Si aucun passage ne justifie une information, il doit l'omettre ou signaler l'incertitude.

3. Améliorer la qualité du retrieval

Beaucoup d'hallucinations viennent d'un retrieval défaillant : le système retrouve des documents peu pertinents et le LLM "comble les trous". Améliorez avec la recherche hybride (vectorielle + BM25) et un reranking cross-encoder.

4. Température basse (0 à 0.1)

Une température élevée augmente la "créativité" du modèle — et donc le risque d'hallucination. Pour les RAG en entreprise, l'objectif est d'obtenir des réponses factuelles et cohérentes, pas créatives.

5. Vérification par un second LLM

Après la génération, un second LLM (le "LLM juge") vérifie si chaque affirmation de la réponse est bien supportée par les passages fournis. Il signale les affirmations non vérifiables avant de présenter la réponse à l'utilisateur.

6. Feedback loop et amélioration continue

Implémentez un mécanisme de feedback utilisateur (👍/👎) et analysez régulièrement les réponses mal notées. Les patterns d'hallucination récurrents révèlent souvent des lacunes dans votre base documentaire.

Cas particulier : les hallucinations sur les chiffres et les dates

Les LLM hallucinent particulièrement sur les données numériques. Pour ces cas, appliquez des validations post-génération : extrayez tous les nombres et dates de la réponse, et vérifiez programmatiquement leur présence dans les passages source. Un écart doit déclencher une alerte ou un refus.

Mesurer le taux d'hallucination de votre système

Construisez un jeu de test avec 50 à 100 questions dont vous connaissez les réponses exactes. Évaluez chaque réponse sur : (1) est-elle factuelle par rapport aux sources ? (2) est-elle exhaustive ? (3) y a-t-il des affirmations non supportées ? Le taux d'hallucination cible pour un RAG en production doit être inférieur à 5 %.

Un RAG bien construit avec des garde-fous anti-hallucination est bien plus fiable qu'un LLM généraliste, et peut atteindre des taux de fidélité supérieurs à 95 % sur des questions ancrées dans votre corpus documentaire.