#Qu'est-ce qu'une hallucination

Le terme « hallucination » désigne toute affirmation produite par le modèle qui est fausse, inventée ou impossible à vérifier, mais présentée comme un fait. Ce n'est pas un bug au sens informatique : le programme fonctionne parfaitement, il génère du texte plausible. Le problème, c'est que « plausible » et « vrai » ne sont pas la même chose.

Concrètement, une hallucination prend plusieurs formes : un chiffre précis mais faux (« la population de cette ville est de 47 312 habitants »), une source qui n'existe pas (« selon l'étude de Dupont et al., 2019 »), une API ou une commande imaginaire (`ollama sync --cloud`), ou encore un mélange de vrais éléments recombinés de façon erronée. Le point commun : le ton est toujours confiant.

Ce n'est pas un mensonge

Le modèle n'a pas d'intention de tromper. Il n'a même pas de notion de vrai ou faux. Il prédit le mot suivant le plus probable. Quand la vérité et la probabilité divergent, c'est la probabilité qui gagne.

#Pourquoi le modèle invente

Un LLM est entraîné à une seule tâche : compléter du texte de manière statistiquement vraisemblable. Il a absorbé des milliards de phrases et en a tiré des régularités. Quand vous posez une question, il ne « consulte » pas une base de connaissances : il génère, mot après mot, la suite la plus probable au vu de votre requête et de son entraînement.

Pas de mémoire factuelle fiable: Les connaissances sont diluées dans les poids du réseau, pas stockées comme dans une base de données. Le modèle « se souvient » d'une tendance, pas d'un fait exact. Les détails précis (dates, chiffres, noms propres rares) sont les premiers à se déformer.
Un entraînement figé dans le temps: Le modèle ne connaît rien après sa date de coupure d'entraînement. Interrogé sur un événement récent, il ne dit pas « je ne sais pas » : il extrapole à partir de ce qu'il connaît, ce qui produit des inventions.
Le biais vers la réponse: Un LLM est optimisé pour répondre, pas pour se taire. Face à une question dont il ignore la réponse, la continuation la plus probable est souvent une réponse formulée avec assurance plutôt qu'un aveu d'ignorance.
L'effet de la quantification: Compresser un modèle en Q4_K_M économise de la VRAM mais dégrade légèrement la précision. Sur les tâches factuelles pointues, une quantification agressive peut augmenter le taux d'inventions par rapport au Q8_0 ou au FP16.
Le hasard du sampling: À chaque mot, le modèle tire au sort parmi les candidats probables. Plus ce tirage est « créatif » (température élevée), plus il peut s'écarter vers des continuations improbables — donc fausses.

Autrement dit, l'hallucination n'est pas un accident : c'est le fonctionnement normal d'un système qui produit du texte vraisemblable sans accès à la vérité. On ne l'élimine pas, on la réduit et on la contrôle.

#Repérer une invention

Avant de corriger, il faut savoir détecter. Certains signaux doivent déclencher votre vigilance immédiatement.

Une précision suspecte: Des chiffres à l'unité près, des dates exactes, des pourcentages précis sur un sujet de niche : plus c'est précis sans source, plus c'est douteux.
Des citations et des liens: Titres d'articles, noms d'auteurs, URLs, numéros de page, références légales. Les LLM inventent des sources d'une crédibilité parfaite. Aucune référence produite par un modèle ne doit être considérée comme réelle sans vérification.
Du code qui « devrait » exister: Des noms de fonctions ou d'options en ligne de commande qui semblent logiques mais n'existent pas. Le modèle complète par analogie avec des API voisines.
Une réponse qui change: Reposez exactement la même question dans une nouvelle conversation. Si la réponse factuelle varie d'une fois à l'autre, le modèle devine plutôt qu'il ne sait.

→

Le test de la reformulation

Demandez au modèle « es-tu certain ? cite ta source exacte » ou reposez la question autrement. Un fait solide résiste ; une invention se contredit souvent ou s'effondre en « je ne peux pas confirmer ».

#Les réglages qui limitent les inventions

Les paramètres de génération pilotent le compromis entre créativité et fiabilité. Pour tout ce qui touche aux faits, au code ou à l'extraction d'information, on veut du déterministe et du prudent.

temperature: Le levier principal. À 0, le modèle prend toujours le mot le plus probable : réponses stables et conservatrices. Montez à 0.7–1.0 pour de l'écriture créative, mais descendez à 0.1–0.3 pour les tâches factuelles.
top_p: Restreint le tirage aux candidats qui cumulent une probabilité donnée. Une valeur basse (0.1–0.5) coupe la longue traîne des mots improbables, souvent responsables des dérapages.
top_k: Limite le nombre de candidats considérés à chaque étape. Un top_k bas (10–20) réduit la fenêtre où le modèle peut partir en vrille.
seed: Fixer une graine rend la génération reproductible : à réglages identiques, même sortie. Indispensable pour tester si une réponse est stable ou aléatoire.
num_ctx: La taille de contexte. Trop courte, le modèle « oublie » le début et peut recombiner des bribes de façon erronée. Assurez-vous que vos documents de référence tiennent dans la fenêtre.

Avec Ollama, ces réglages se passent à la volée dans l'appel API ou se figent dans un Modelfile. Voici un exemple d'appel factuel prudent sur le daemon local :

Terminal

curl http://localhost:11434/api/generate -d '{
  "model": "mistral",
  "prompt": "Résume ce texte sans rien ajouter : ...",
  "stream": false,
  "options": {
    "temperature": 0.2,
    "top_p": 0.5,
    "top_k": 20,
    "seed": 42
  }
}'

Pour rendre ces réglages permanents sur un modèle, on les inscrit dans un Modelfile et on crée une variante dédiée aux tâches factuelles :

Modelfile

FROM mistral
PARAMETER temperature 0.2
PARAMETER top_p 0.5
PARAMETER top_k 20
SYSTEM "Tu réponds uniquement à partir des informations fournies. Si tu ne sais pas, tu dis 'Je ne sais pas'. Tu n'inventes jamais de source, de chiffre ni de citation."

Terminal

ollama create mistral-prudent -f ./Modelfile
ollama run mistral-prudent

Température basse ≠ vérité garantie

Baisser la température rend la réponse stable et conservatrice, pas exacte. Un modèle peut halluciner de façon parfaitement déterministe à température 0. Les réglages réduisent le bruit ; ils ne créent pas de connaissance qui n'existe pas.

#Prompts de prudence

La façon dont vous formulez votre demande change beaucoup le taux d'inventions. L'idée : autoriser explicitement l'ignorance et interdire l'invention.

Donner le droit de ne pas savoir: « Si tu n'es pas certain, réponds : Je ne sais pas. » Sans cette permission, le modèle comblera le vide par une invention.
Exiger l'ancrage: « Réponds uniquement à partir du texte ci-dessous. N'utilise aucune connaissance extérieure. » On force le modèle à se limiter au contexte fourni.
Demander les sources dans le texte: « Pour chaque affirmation, cite la phrase exacte du document qui la justifie. » Si le modèle ne trouve pas de justification, l'absence devient visible.
Séparer faits et hypothèses: « Distingue ce qui est établi de ce qui est une supposition de ta part. » Cela pousse le modèle à étiqueter ses propres incertitudes.
Décomposer les tâches complexes: Une question en plusieurs étapes explicites laisse moins de place à l'improvisation qu'une grosse question ouverte.

System prompt anti-hallucination

Tu es un assistant factuel et prudent.
Règles :
1. Réponds uniquement à partir du contexte fourni par l'utilisateur.
2. Si l'information n'y figure pas, réponds exactement : « Je ne sais pas ».
3. N'invente jamais de chiffre, de date, de nom, de source ni d'URL.
4. Pour chaque affirmation, cite la phrase du contexte qui la justifie.
5. Distingue clairement les faits des hypothèses.

→

Le simple « Je ne sais pas » change tout

Ajouter une consigne autorisant l'aveu d'ignorance est le geste le plus rentable. Beaucoup d'inventions viennent uniquement du fait que le modèle croit devoir répondre coûte que coûte.

#Ancrer les réponses avec vos propres documents

La technique la plus efficace contre l'hallucination ia reste le RAG (Retrieval-Augmented Generation) : au lieu de laisser le modèle puiser dans sa mémoire diffuse, on lui fournit les passages pertinents de vos documents et on lui demande de répondre à partir d'eux seulement. Le modèle passe d'un rôle de « source » à un rôle de « lecteur ».

01
Indexer vos documents
Vos fichiers (PDF, notes, docs internes) sont découpés en morceaux, transformés en vecteurs par un modèle d'embeddings et stockés dans une base vectorielle.
02
Retrouver les passages pertinents
À chaque question, le système recherche les morceaux les plus proches sémantiquement de la requête et les récupère.
03
Injecter dans le contexte
Les passages retrouvés sont collés dans le prompt, accompagnés d'une consigne stricte : répondre uniquement à partir de ces extraits.
04
Générer avec citations
Le modèle rédige la réponse en s'appuyant sur les extraits fournis, idéalement en citant lesquels. S'ils ne contiennent pas la réponse, il doit le dire.

Open WebUI, branché sur le daemon Ollama (http://localhost:11434), propose un RAG intégré : vous téléversez des documents et les référencez avec `#` dans la conversation. Pour des besoins sur mesure, une base vectorielle et un pipeline maison offrent plus de contrôle.

Le RAG réduit, il n'élimine pas

Même ancré, un modèle peut mal interpréter un passage ou extrapoler au-delà. La qualité du découpage et de la recherche compte autant que le modèle. Un RAG mal réglé qui remonte les mauvais extraits produit des réponses confiantes… et fausses.

#Vérifier systématiquement

Aucune technique ne rend un LLM fiable à 100 %. La vérification n'est donc pas une option, c'est une étape du workflow. Elle doit être proportionnée à l'enjeu.

Croiser avec une source réelle: Toute donnée factuelle destinée à être utilisée (chiffre, date, citation) se vérifie auprès d'une source primaire. Le modèle est un point de départ, jamais une référence.
Tester le code avant de le croire: Exécutez ce que le modèle produit. Une fonction qui n'existe pas lèvera une erreur immédiate. Ne copiez jamais du code critique sans l'avoir fait tourner.
Comparer deux générations: Reposez la question avec un seed différent ou dans une nouvelle session. Les points stables sont plus fiables ; les points qui varient sont suspects.
Utiliser un second modèle: Faire relire la réponse d'un modèle par un autre (ou par une variante plus grande) fait ressortir les incohérences flagrantes.
Garder l'humain dans la boucle: Pour toute décision qui a des conséquences (santé, droit, argent, sécurité), la validation finale reste humaine. Sans exception.

#Les cas où il ne faut jamais faire confiance

Certains domaines concentrent les hallucinations les plus dangereuses. Sur ceux-là, traitez toute sortie du modèle comme un brouillon non vérifié, par défaut faux jusqu'à preuve du contraire.

Santé et médicaments: Posologies, interactions, diagnostics. Une invention peut être dangereuse. Le modèle n'est pas un professionnel de santé.
Droit et fiscalité: Articles de loi, jurisprudence, obligations déclaratives. Les LLM inventent des références juridiques d'un réalisme trompeur.
Chiffres et statistiques précis: Populations, taux, montants, dates exactes. Les détails numériques sont le point faible structurel des modèles.
Événements récents: Tout ce qui est postérieur à la coupure d'entraînement. Le modèle comblera par extrapolation sans le signaler.
Citations et références: Titres, auteurs, URLs, numéros de page. À vérifier systématiquement, sans exception, avant toute réutilisation.
Personnes et faits de niche: Biographies de personnes peu connues, détails obscurs : le modèle recombine des bribes et invente le reste.

La règle d'or

Un LLM local est un excellent assistant de rédaction, de brainstorming et de reformulation. Ce n'est pas une base de connaissances vérifiée. Plus l'enjeu est élevé, plus la vérification humaine doit être stricte.

#Pour aller plus loin

Réduire les hallucinations, c'est surtout combiner les bons réglages et le bon ancrage. Ces guides complètent l'approche :

Température, top-p, top-k : les paramètres: Pour maîtriser en détail les leviers de sampling évoqués ici et régler finement le compromis créativité/fiabilité.
Choisir sa quantification (Q4, Q5, Q8, FP16): Pour comprendre l'effet de la compression sur la précision factuelle et arbitrer quand la fiabilité prime.
Maîtriser les system prompts: Pour aller plus loin sur les prompts de prudence et figer un comportement anti-invention par défaut.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Premiers pas · 8 min