IAMaîtriser l'IA générative Plan du corpus
Accueil/Evaluer, fiabiliser, securiser/Reduire les hallucinations

03 - Reduire les hallucinations

Une hallucination, c'est une reponse fausse ecrite avec assurance. C'est le pire defaut possible dans un pipeline de donnees.

Temps de lecture : 13 min | Niveau : Intermediaire

Ce que tu sauras faire apres

  • Autoriser explicitement le modele a dire "je ne sais pas".
  • Forcer l'ancrage sur les donnees fournies au lieu de la connaissance generale.
  • Exiger des citations exactes et faire retirer les affirmations non sourcees.
  • Mettre en place une verification en deux passes.
  • Savoir ou en est le reglage temperature en 2026, et pourquoi tu ne dois plus compter dessus.

🎯 Ce qu'est une hallucination, concretement

Ce n'est pas le modele qui dit une enormite. C'est le modele qui produit quelque chose de plausible et faux, dans le bon format, sans aucun signal d'alerte.

Chez toi, ca ressemble a ca :

  • Il cite dim_client.code_segment alors que la colonne s'appelle segment_code.
  • Il te donne un SIRET valide en apparence pour une facture qui n'en contient aucun.
  • Il resume un ticket d'incident en ajoutant une cause qui n'est ecrite nulle part.
  • Il t'explique une fonction pandas avec un parametre qui n'existe pas.
  • Il "complete" un tableau de chiffres en inventant les mois manquants.

La documentation Anthropic le dit franchement : ces techniques reduisent les hallucinations mais ne les eliminent pas. Il faut toujours valider les informations critiques, surtout pour les decisions a fort enjeu.

🧰 Les 4 techniques de base

Ce sont les strategies documentees par Anthropic. Elles sont simples et tu peux toutes les appliquer aujourd'hui.

1. Autoriser "je ne sais pas"

C'est la technique qui rapporte le plus pour l'effort le plus faible. Par defaut, un modele essaie de repondre. Si tu lui donnes explicitement la permission d'admettre son incertitude, il l'utilise.

Formulation directement adaptee de la doc Anthropic :

Si tu n'es pas sur d'un point, ou si le document ne contient pas
l'information necessaire, ecris exactement :
"Je n'ai pas assez d'informations pour repondre avec certitude."

Le detail qui compte : donne-lui la phrase exacte a ecrire. Une phrase fixe se detecte par code (if "pas assez d'informations" in reponse). Un "je ne suis pas sur" formule librement ne se detecte pas.

2. Restreindre la connaissance externe

Tu lui interdis d'utiliser ce qu'il sait par ailleurs. La doc appelle ca external knowledge restriction.

Base-toi UNIQUEMENT sur le contenu de <schema> ci-dessus.
N'utilise pas ta connaissance generale des bases de donnees.
Si un nom de table ou de colonne n'apparait pas dans <schema>, tu ne dois
pas l'utiliser, meme s'il te semble evident.

C'est la technique la plus utile en data engineering : un modele "sait" a quoi ressemble un schema e-commerce classique, et il va gentiment completer le tien avec des colonnes standard qui n'existent pas chez toi.

3. Ancrer sur des citations exactes

Pour les documents longs, la doc Anthropic recommande de demander d'abord l'extraction de citations mot pour mot avant de faire quoi que ce soit d'autre. Elle donne un seuil indicatif : documents de plus de 20 000 tokens.

La structure recommandee est en deux temps dans le meme prompt :

1. Extrais les citations exactes du document qui sont pertinentes pour
   [SUJET]. Numerote-les. Si tu ne trouves aucune citation pertinente,
   ecris "Aucune citation pertinente trouvee."

2. Utilise ces citations pour [LA TACHE], en referencant chaque affirmation
   par le numero de la citation. Base ton analyse uniquement sur les
   citations extraites.

Pourquoi ca marche : une citation mot pour mot est verifiable par code. Tu peux verifier que la chaine existe reellement dans le document source.

def verifier_citations(document: str, citations: list[str]) -> list[str]:
    """Retourne les citations qui n'existent PAS dans le document."""
    normalise = " ".join(document.split()).lower()
    fausses = []
    for c in citations:
        if " ".join(c.split()).lower() not in normalise:
            fausses.append(c)
    return fausses

Une citation inventee est un signal d'alarme absolu : si le modele invente ses sources, tout le reste est suspect.

4. Verifier avec des citations, puis retirer

La technique la plus forte de la doc : apres avoir redige, le modele relit chacune de ses affirmations, cherche une citation qui la soutient, et supprime l'affirmation s'il n'en trouve pas.

Apres avoir redige, relis chaque affirmation de ton texte. Pour chacune,
trouve une citation exacte du document qui la soutient. Si tu ne trouves
pas de citation pour une affirmation, retire cette affirmation et marque
l'endroit avec des crochets vides [].

Les crochets vides sont un marqueur que tu peux compter automatiquement. Beaucoup de [] = le document ne contenait pas l'information = ton pipeline doit remonter le cas a un humain.

🔬 Les techniques avancees

La doc Anthropic en liste quatre. Voici ce qu'elles donnent en pratique.

Verification par raisonnement etape par etape

Demander au modele d'expliquer son raisonnement avant de conclure. Ca revele les logiques bancales.

Avant de donner ta reponse finale, ecris ton raisonnement dans <reflexion>.
Indique quelles lignes du fichier tu utilises et pourquoi.
Donne ensuite ta reponse dans <reponse>.

Best-of-N : lancer plusieurs fois et comparer

Lance le meme prompt 3 fois. Si les 3 reponses different, c'est un signal d'hallucination. Si elles sont identiques, la confiance monte (sans garantie).

import json

reponses = [extraire(texte) for _ in range(3)]
accord = len({json.dumps(r, sort_keys=True) for r in reponses}) == 1
if not accord:
    print("Divergence entre les 3 essais : a faire relire par un humain")

Pratique sur un echantillon pendant la mise au point. Trop cher sur 40 000 lignes en production : reserve-le aux cas a fort enjeu (montants, identifiants, decisions).

Raffinement iteratif

Reutiliser la sortie comme entree d'un second prompt qui demande de verifier ou de developper. Attention : ca peut aussi amplifier une erreur initiale. A combiner obligatoirement avec l'ancrage sur les sources.

Restriction a la connaissance fournie

Deja vu plus haut, c'est la technique 2. Anthropic la classe dans les avancees, je la mets en base parce que c'est la plus rentable pour ton metier.

🌡️ Et la temperature ?

C'est le point ou il faut etre precis, parce que ca a change recemment.

Le conseil classique est : baisse la temperature vers 0 pour les taches analytiques, monte-la vers 1 pour les taches creatives. La documentation de l'API Messages d'Anthropic donne encore cette recommandation : plage 0.0 a 1.0, valeur par defaut 1.0, proche de 0.0 pour les taches analytiques ou a choix multiples.

Mais la meme page marque desormais ce parametre comme deprecie. Citation exacte : « Deprecated. Models released after Claude Opus 4.6 do not support setting temperature. A value of 1.0 will be accepted for backwards compatibility, all other values will be rejected with a 400 error. »

Traduction : sur les modeles sortis apres Claude Opus 4.6, tu ne peux plus baisser la temperature. Seule la valeur 1.0 passe encore, et toute autre valeur renvoie une erreur 400.

Deuxieme point, toujours dans la doc : meme avec une temperature de 0.0, les resultats ne sont pas totalement deterministes. Deux appels identiques peuvent differer.

Conclusion pratique pour toi :

  • Sur un modele recent : n'envoie pas le parametre du tout. C'est le cas par defaut, et ca evite l'erreur 400.
  • Sur un modele ancien que tu dois garder : une valeur basse reste utile pour de l'extraction, mais c'est un gain marginal.
  • Dans tous les cas, ne compte jamais sur la temperature pour garantir la fiabilite. Elle ne pese rien a cote de l'ancrage sur les sources et de la verification par code.

Ce point a change plusieurs fois. Avant d'ecrire du code, relis la page officielle de l'API Messages listee en sources.

📋 Template pret a copier : prompt anti-hallucination

Un prompt complet qui combine les quatre techniques de base. Adapte les crochets.

Tu extrais des informations d'un document source. Tu n'inventes rien.

<document>
[COLLE ICI LE TEXTE DU DOCUMENT]
</document>

<champs_demandes>
[LISTE LES CHAMPS, UN PAR LIGNE, AVEC LEUR FORMAT ATTENDU]
</champs_demandes>

Procede en deux etapes.

ETAPE 1 - Citations
Pour chaque champ demande, extrais la citation exacte, mot pour mot, du
<document> qui contient l'information. Numerote-les.
Si aucune citation ne correspond a un champ, ecris pour ce champ :
"AUCUNE CITATION".

ETAPE 2 - Extraction
A partir des citations seulement, remplis les champs.

Regles strictes :
- Utilise UNIQUEMENT le contenu de <document>. N'utilise pas ta connaissance
  generale, meme si une valeur te semble evidente.
- Si un champ a "AUCUNE CITATION", sa valeur est null. Ne devine jamais.
- Ne corrige pas les valeurs du document, meme si elles semblent erronees.
- Si le document n'est pas du type attendu ([TYPE DE DOCUMENT ATTENDU]),
  reponds uniquement : "DOCUMENT NON CONFORME".

Renvoie ce JSON :
{"citations": {"<champ>": "<citation exacte ou AUCUNE CITATION>"},
 "valeurs": {"<champ>": <valeur ou null>}}

🔁 AVANT / APRES : analyse d'un incident de pipeline

Avant

Voici les logs d'echec du DAG Airflow. Explique pourquoi le job a plante et
comment le corriger.

[LOGS]

Ce que ca produit : une explication tres bien redigee qui cite une variable d'environnement absente des logs, propose un retry sur un operateur qui n'apparait nulle part, et affirme une cause racine que rien ne prouve. C'est plausible. Tu vas y passer deux heures.

Apres

<logs>
[LOGS]
</logs>

<dag_source>
[CODE DU DAG]
</dag_source>

1. Extrais les lignes exactes de <logs> qui indiquent une erreur. Numerote-les.
   Si aucune ligne n'indique d'erreur, ecris "Aucune erreur identifiee dans les
   logs fournis" et arrete-toi.

2. Pour chaque cause possible, indique :
   - la ou les lignes de <logs> qui la soutiennent (par numero)
   - la ou les lignes de <dag_source> concernees
   - un niveau de confiance : certain / probable / hypothese

3. Ne propose pas de correction pour une cause de niveau "hypothese". Indique
   a la place quelle information supplementaire permettrait de trancher.

Tu ne dois citer aucun nom de variable, de tache ou de fichier qui n'apparait
pas dans <logs> ou <dag_source>.

Pourquoi c'est mieux :

  • Deux sources delimitees, donc le modele est ancre.
  • Les citations sont numerotees, donc verifiables.
  • Le niveau de confiance separe ce qui est prouve de ce qui est suppose.
  • L'interdiction de citer des noms absents est un controle que tu peux rejouer par code sur la sortie.
  • La sortie "Aucune erreur identifiee" est une porte de sortie honnete.

🧷 Le garde-fou final : la verification par code

Quelle que soit la qualite du prompt, ajoute une couche de verification apres coup. Exemple pour du SQL genere :

import re

def controler_noms(reponse: str, schema_reel: dict[str, set[str]]) -> list[str]:
    """Retourne les noms table.colonne cites qui n'existent pas."""
    inconnus = []
    for table, colonne in re.findall(r"\b(\w+)\.(\w+)\b", reponse):
        if table not in schema_reel or colonne not in schema_reel[table]:
            inconnus.append(f"{table}.{colonne}")
    return inconnus

Cette fonction attrape en 5 lignes une categorie entiere d'hallucinations, sans appel API, sans ambiguite. C'est toujours ca qu'il faut chercher : transformer la sortie du modele en quelque chose de verifiable mecaniquement.

A retenir

  • Donne toujours au modele une phrase exacte pour dire qu'il ne sait pas.
  • Interdis explicitement l'usage de la connaissance generale quand tu fournis des donnees.
  • Pour les documents longs, fais extraire les citations mot pour mot AVANT la tache.
  • Fais relire et retirer les affirmations sans citation : les crochets vides sont un signal exploitable.
  • temperature est deprecie sur les modeles Claude sortis apres Opus 4.6 : n'envoie plus ce parametre, et ne compte pas dessus pour la fiabilite.
  • Aucune technique n'elimine les hallucinations. Le vrai garde-fou est une verification par code apres coup.

Sources

Toutes ces pages ont ete ouvertes et verifiees le 26 septembre 2026.

Corpus personnel de formation · genere le 26/09/2026 · source : 03-reduire-les-hallucinations.md