Atténuez les hallucinations des LLM étape par étape

Pourquoi une hallucination ne se « corrige » pas avec un prompt

Avant de toucher à la configuration, il convient d’accepter une réalité inconfortable : les hallucinations ne sont pas un bug que l’on élimine avec une instruction plus ferme. Elles sont un comportement émergent du fonctionnement probabiliste du modèle. Un LLM génère le token le plus probable étant donné une séquence, il ne consulte pas une base de faits. Lorsque le contexte ne contient pas la réponse, le modèle ne s’arrête pas : il complète avec ce qui s’accorde statistiquement. Cela signifie que toute configuration qui te promet « zéro hallucination » te vend du vent.

Ce que tu peux faire, en revanche, c’est réduire la surface où elles apparaissent, les détecter avant qu’elles n’atteignent l’utilisateur et dégrader le système de manière contrôlée lorsque la confiance chute. Cet article est une séquence de configuration réelle, avec des paramètres concrets, des seuils et des vérifications, pour les équipes qui ont déjà un LLM en production ou qui sont sur le point de le mettre en place.

Étape 1 : sépare les types d’hallucination avant de configurer quoi que ce soit

Toutes les hallucinations ne se mitiguent pas de la même façon. Configurer sans classifier conduit à corriger le mauvais endroit. Distingue au moins ces quatre types, car chacun exige une couche différente :

• Factuelle : le modèle affirme une donnée fausse (une date, un chiffre, une loi). On la combat avec la récupération de contexte et la vérification externe.
• D’attribution : il invente une source, un auteur ou une citation. C’est la plus dangereuse dans le contenu éditorial car elle semble vérifiable.
• D’instruction : il ignore une contrainte du système (répond dans une autre langue, casse le format). On la combat avec la validation de sortie.
• De raisonnement : les étapes intermédiaires sont plausibles mais la conclusion ne découle pas. On la combat avec la décomposition et la vérification de chaque étape.

Un cas que je vois régulièrement dans les équipes de contenu : elles configurent la température à 0 en pensant que cela met fin aux inventions de sources. Cela réduit la variabilité, oui, mais un modèle avec une température de 0 continue d’inventer des références s’il n’a pas la donnée. La température réduit la dispersion, pas l’ignorance.

Étape 2 : fixe la température et le sampling selon la tâche

La configuration du sampling est le premier vrai levier. Il n’existe pas de valeur universelle ; il existe une valeur par type de tâche. Guide-toi sur ce tableau :

Avertissement d’expert : baisser top_p à 0,5 tronque la queue des tokens improbables, ce qui réduit les inventions rares mais rend aussi le texte plus plat et répétitif. Dans les tâches d’extraction structurée, il convient de le combiner avec le constrained decoding (grammaires ou schémas JSON forcés), qui est plus efficace que n’importe quel réglage de température pour éviter les champs inventés.

Étape 3 : monte une récupération avec seuil de rejet

Le levier le plus puissant contre l’hallucination factuelle est de ne pas laisser le modèle répondre de mémoire. Configure un pipeline RAG (retrieval-augmented generation) avec ces décisions explicites :

1. Découpage : des fragments de 300 à 600 tokens avec un chevauchement de 10 à 15 %. Des fragments trop grands diluent le signal ; trop petits, ils perdent le contexte qui évite les interprétations erronées.
2. Récupération hybride : combine la recherche sémantique (embeddings) avec la recherche lexicale (BM25). La sémantique échoue sur les identifiants, les codes et les noms propres ; la lexicale échoue sur les paraphrases. Ensemble, elles couvrent davantage.
3. Seuil de similarité : définis un score minimal (par exemple, 0,75 en similarité cosinus, ajusté après mesure sur ton propre corpus) en dessous duquel le système n’appelle pas le modèle et renvoie un message « je n’ai pas suffisamment d’informations ».
4. Prompt à contexte fermé : instruis le modèle de répondre uniquement avec les fragments récupérés et d’indiquer explicitement lorsque le contexte ne couvre pas la question. Cette instruction n’est pas infaillible, mais combinée au seuil, elle réduit drastiquement les réponses inventées.

Voici l’erreur pratique que presque tout le monde commet la première fois : configurer le seuil de récupération trop haut. Le système commence à rejeter des questions légitimes et l’équipe, frustrée, le descend à zéro. Le bon seuil ne se devine pas : il se calibre avec un ensemble de 50 à 100 questions réelles, en mesurant combien de fois il rejette une question qui avait bien une réponse par rapport à combien de fois il répond sans contexte. Sans cet ensemble de calibration, tout seuil est une intuition.

Étape 4 : des instructions système qui fonctionnent vraiment (et celles qui ne fonctionnent pas)

Les phrases du type « n’invente rien » ont une efficacité limitée. Les instructions opérationnelles et vérifiables fonctionnent mieux :

• Au lieu de « sois précis », utilise « cite le fragment de contexte dont provient chaque affirmation ; s’il n’y a pas de fragment, réponds «non documenté» ».
• Au lieu de « n’hallucine pas », utilise « si la question nécessite des données postérieures à tes connaissances ou absentes du contexte, dis-le avant de répondre ».
• Ajoute un format de sortie avec des champs obligatoires : réponse, sources (liste des fragments utilisés), confiance (haute/moyenne/basse). Le champ des sources force le modèle à s’engager et facilite la vérification automatique.

Ce qui ne fonctionne pas : empiler dix restrictions négatives dans le prompt système. À partir d’un certain nombre, le modèle commence à ignorer les premières ou à se sur-restreindre et à rejeter des requêtes valides. Priorise trois ou quatre règles critiques et valide chacune par des tests.

Étape 5 : vérification de la sortie avant de la montrer à l’utilisateur

La configuration ne s’arrête pas au modèle. Ajoute une couche de validation programmatique entre la réponse et l’utilisateur :

• Validation de schéma : si tu attends du JSON, rejette toute sortie qui ne respecte pas le schéma. N’essaie pas de la réparer avec un autre prompt sans marquer l’échec.
• Vérification des entités : extrais les noms, les dates et les chiffres de la réponse et compare-les avec le contexte récupéré. Si une entité n’apparaît dans aucune source, signale-la.
• Vérification des citations : si le modèle cite un document, vérifie que ce document existe dans ton index et que le fragment cité s’y trouve. Les citations inventées se détectent ainsi avec une grande fiabilité.
• Second passage avec un autre modèle ou prompt : un modèle plus petit agissant comme vérificateur peut signaler des affirmations non étayées. Ce n’est pas infaillible et cela ajoute de la latence, mais dans les flux de contenu éditorial, cela en vaut la peine.

Nuance importante : la vérification automatique comporte des faux positifs. Un vérificateur trop strict rejettera des réponses correctes qui paraphrasent le contexte au lieu de le citer littéralement. Configure le vérificateur pour comparer le sens, et non la correspondance exacte des chaînes, sinon tu auras un système qui rejette tout.

Étape 6 : définis le comportement de dégradation

Un système mature sait quoi faire lorsqu’il n’est pas sûr. Configure explicitement ces états :

1. Confiance haute : réponse directe avec sources.
2. Confiance moyenne : réponse avec avertissement visible et liens vers les sources pour vérification humaine.
3. Confiance basse : ne pas répondre ; proposer de reformuler la question ou transférer vers un humain.
4. Échec de validation : enregistrer le cas complet (prompt, contexte récupéré, sortie, motif du rejet) pour analyse ultérieure.

L’enregistrement est la partie que l’on oublie le plus et la plus précieuse. Sans un journal des échecs, tu ne peux améliorer ni les seuils ni les prompts ; tu ne peux que prier. Selon la documentation des principaux fournisseurs de modèles, l’évaluation continue avec des ensembles de test propres est le seul moyen fiable de mesurer si tes changements réduisent les hallucinations ou ne font que les déplacer.

Étape 7 : mesure avec un ensemble de test propre, pas avec des benchmarks publics

Les benchmarks génériques ne reflètent pas ton domaine. Configure un ensemble d’évaluation avec trois types de cas : des questions que ton système doit répondre correctement, des questions hors périmètre qu’il doit rejeter et des questions pièges (prémisses fausses) qu’il doit corriger. Exécute cet ensemble chaque fois que tu modifies la température, le prompt, le modèle ou le seuil de récupération.

Deux métriques minimales : taux d’invention (réponses contenant des affirmations non étayées divisé par les réponses données) et taux de rejet correct (questions hors périmètre rejetées divisé par les questions hors périmètre). Si tu optimises seulement la première, le système finira par tout rejeter ; si tu optimises seulement la seconde, il répondra en inventant. Elles évoluent en tension et il faut les surveiller ensemble.

Ce que cette configuration ne résout pas

Transparence totale : même avec tout ce qui précède bien en place, il reste des hallucinations résiduelles. Les cas les plus difficiles à contrôler sont les hallucinations de raisonnement dans les questions nécessitant plusieurs étapes enchaînées, celles qui surgissent d’un contexte récupéré ambigu (documents qui se contredisent entre eux) et celles qui apparaissent lorsque l’utilisateur pousse le modèle avec des prémisses fausses persistantes. Dans les domaines réglementés (santé, juridique, financier), aucune configuration ne remplace la révision humaine ; le système peut assister, mais la responsabilité de l’affirmation finale n’est pas délégable au modèle.

L’attente réaliste n’est pas zéro hallucination, mais des hallucinations détectées avant de causer un dommage, avec un système qui sait quand se taire. C’est la configuration que tu peux défendre devant un client ou un auditeur.