Pourquoi les LLM hallucinent et 4 façons d’y remédier

Claude vient de citer avec assurance trois articles de recherche dans votre pipeline RAG. Aucun d’eux n’existe. Vous avez vérifié. Cela se produit parce que les LLM ne récupèrent pas les faits — ils prédisent le prochain token en se basant sur des schémas dans les données d’entraînement. Lorsque cette prédiction diverge de la réalité, vous obtenez une hallucination. Comprendre pourquoi cela se produit est la première étape pour l’empêcher.

Ce qu’est réellement une hallucination (et pourquoi votre modèle n’est pas défectueux)

L’hallucination n’est pas un bug comme une erreur d’exécution. C’est une conséquence fondamentale du fonctionnement des grands modèles linguistiques. Un LLM génère du texte token par token, sélectionnant le mot suivant en fonction de distributions de probabilité apprises lors de l’entraînement. Si les données d’entraînement contenaient des schémas qui récompensent la confiance (alerte spoiler : c’est le cas), le modèle apprend à paraître certain même lorsqu’il ne l’est pas.

Dans les benchmarks, Claude 3.5 Sonnet atteint environ 92 % de précision factuelle sur des questions fermées. Cela semble élevé jusqu’à ce que vous réalisiez que cela signifie qu’environ 1 réponse sur 12 contient une fabrication. Si vous effectuez des milliers d’inférences par jour, vous rencontrez régulièrement des hallucinations.

Le problème s’aggrave lorsque vous demandez à un modèle de raisonner sur des informations qu’il n’a jamais vues auparavant. Un modèle entraîné sur des données jusqu’à avril 2024 ne peut pas savoir ce qui s’est passé en juin 2024. Plutôt que de dire « Je ne sais pas », il génère un texte plausible qui correspond au schéma. C’est ainsi que l’on obtient des articles de recherche qui n’existent pas.

Les trois modes d’échec que vous rencontrez réellement

Les hallucinations ne sont pas aléatoires. Elles suivent des schémas prévisibles en fonction de votre cas d’utilisation.

Hallucinations dues à la coupure de connaissances : Le modèle génère des informations actuelles avec confiance malgré un entraînement sur des données plus anciennes. Exemple : demander à GPT-3.5 des événements de 2024 produit des faits inventés déguisés en actualités. Solution : incluez toujours la date actuelle dans votre prompt système et indiquez explicitement la date limite de formation du modèle.

Hallucinations liées au suivi d’instructions : Le modèle invente des informations pour se conformer à votre prompt. Vous demandez 10 études de cas — il en fournit 10, même si seulement 4 existent dans ses données d’entraînement. Les 6 restantes sont fabriquées pour satisfaire votre demande. C’est pourquoi les prompts comme « Trouvez 5 exemples de… » sont dangereux sans ancrage.

Hallucinations de raisonnement : Le modèle enchaîne une logique plausible qui ne mène nulle part de réel. Il cite des sources, des experts, construit des récits entiers — tout est cohérent en interne, tout est potentiellement faux. Ce sont les plus difficiles à détecter car ils ne semblent pas faux.

Technique 1 : Ancrez vos prompts dans des données réelles

C’est la méthode de réduction la plus efficace. Au lieu de demander au modèle de récupérer ou de raisonner à partir de sa mémoire, donnez-lui les informations spécifiques dont il a besoin et demandez-lui de travailler uniquement avec celles-ci.

Mauvais prompt :

Résumez les dernières tendances du marché de l'énergie renouvelable.

Le modèle hallucine des tendances récentes car il ne sait pas ce que « dernières » signifie pour vous.

Prompt amélioré :

Basé UNIQUEMENT sur le rapport de marché suivant du T1 2025, résumez les trois principales tendances.

Rapport :
[INSÉRER LE TEXTE DU RAPPORT ICI]

Règles :
- N'ajoutez pas d'informations provenant de vos données d'entraînement
- Si une information n'est pas dans le rapport, dites-le explicitement
- Citez directement lorsque vous faites une affirmation

Ce passage — d’une récupération ouverte à un raisonnement borné — réduit les hallucinations d’environ 60 % lors de tests répétés sur des tâches d’extraction structurée. Vous ne demandez plus au modèle de savoir quelque chose ; vous lui demandez de lire quelque chose.

Technique 2 : Utilisez les contrôles de température et d’échantillonnage

La température contrôle la quantité d’aléatoire que le modèle introduit lors de la sélection du prochain token. Température plus élevée = plus créatif, moins prévisible. Température plus basse = plus déterministe, plus confiant.

Pour les tâches factuelles, une température plus basse aide. La valeur par défaut de Claude est 1.0 ; pour l’extraction ou la synthèse, utilisez 0.3 à 0.5. Cela réduit la tendance du modèle à explorer des séquences de tokens improbables — là où se cachent souvent les hallucinations.

Cependant, c’est un instrument rudimentaire. Abaisser la température n’élimine pas les hallucinations ; cela les rend simplement moins fréquentes. Une température de 0.0 ne produit pas la vérité — elle produit la réponse la plus statistiquement probable, qui peut toujours être fausse.

Exemple Python avec l’API Claude :

import anthropic

client = anthropic.Anthropic()

# Tâche d'extraction avec basse température
response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    temperature=0.3,  # Plus bas pour les tâches factuelles
    messages=[
        {
            "role": "user",
            "content": "Extrayez les noms d'entreprise de ce texte : [TEXTE]"
        }
    ]
)

print(response.content[0].text)

Technique 3 : Implémentez des boucles de vérification

Ne présumez pas qu’une seule sortie de modèle est fiable. Ajoutez une deuxième passe qui audite la première.

Pour les affirmations factuelles, utilisez Claude ou un autre modèle performant pour vérifier les citations. Demandez-lui : « Ces articles sont-ils réels ? Vérifiez chaque citation et signalez tout ce que vous ne pouvez pas confirmer. » Cela détecte environ 75 % des références inventées dans mes tests.

Pour les données structurées, analysez la sortie et validez-la par rapport à des schémas connus. Si vous extrayez des adresses e-mail, vérifiez le format. Si vous extrayez des dates, vérifiez qu’elles sont valides. Si vous extrayez des URL, testez qu’elles aboutissent (ou suivez au moins un schéma valide).

Pour les tâches de raisonnement, utilisez une technique appelée « vérification d’auto-contradiction ». Posez la même question au modèle de trois manières différentes. Si les réponses divergent significativement, signalez-la pour un examen humain plutôt que de faire confiance à la réponse.

Technique 4 : Contrainte stricte du format de sortie

Les hallucinations prospèrent dans les réponses non structurées. Contrainte le modèle à du JSON, XML ou CSV avec un schéma clair.

Au lieu de :

Extrayez le nom du produit et le prix de ce reçu.

Utilisez :

Extrayez les données de ce reçu. Retournez UNIQUEMENT du JSON valide dans ce format, aucun autre texte :
{
  "product_name": "string",
  "price_usd": number,
  "currency": "string"
}

Reçu :
[TEXTE]

La sortie structurée réduit les hallucinations car le modèle a moins de degrés de liberté. Il ne peut pas divaguer ou inventer des fioritures narratives — il doit correspondre au schéma, sinon la sortie échoue en aval.

Claude prend en charge le mode JSON natif (réglez temperature sur 0 et incluez "type": "json_object" dans les appels API), ce qui réduit davantage les sorties invalides.

Par où commencer : Choisissez une technique pour votre pipeline

N’implémentez pas les quatre à la fois. Commencez par l’ancrage — c’est le changement le plus impactant et le plus simple. Donnez à votre modèle des données réelles au lieu de lui demander de se souvenir.

Cette semaine : auditez un prompt dans votre système. Trouvez un endroit où vous demandez au modèle de récupérer ou d’inventer des informations. Remplacez-le par une version qui inclut le matériel source réel. Exécutez 20 cas de test. Comptez les hallucinations avant et après. Vous verrez la différence immédiatement.