- Réduire la température entre 0.0 et 0.2
- Imposer au modèle d'avouer son ignorance
- Vérifier systématiquement liens, calculs et dépendances de code
On s'est tous fait coincer au moins une fois. Vous posez une question pointue à ChatGPT ou Claude, le bouzin vous répond avec un aplomb olympien, déroule une démonstration sans accroc, cite un décret ministériel précis avec numéro d'article ou vous colle un lien GitHub parfaitement formaté. Problème : le décret n'existe pas, la fonction Python invoquée appartient à une bibliothèque imaginaire, et la page web renvoie une erreur 404. Bienvenue dans le monde merveilleux des hallucinations.
Les grands modèles de langage (LLM) ne réfléchissent pas, ne vérifient rien et n'ont aucune notion de la vérité factuelle. Ce sont de formidables moteurs statistiques prédictifs de texte. Si vous les utilisez pour coder, rédiger ou faire de la veille sans filet de sécurité, vous jouez à la roulette russe professionnelle. Voici la méthode concrète pour blinder vos requêtes et ne plus jamais gober les bobards de votre terminal.
Pourquoi c'est important
Prendre pour argent comptant ce qui sort d'un modèle d'IA générative n'est plus juste un sujet de discussion geek autour d'une bière : c'est devenu un risque opérationnel lourd. Tout le monde se souvient de cette affaire aux États-Unis en 2023 (Mata v. Avianca) où deux avocats new-yorkais ont soumis un mémoire truffé de jurisprudences entièrement inventées par ChatGPT. Résultat : une sanction financière et une humiliation publique devant le tribunal fédéral.
Dans le monde du développement, c'est le même cirque : un modèle peut inventer une dépendance npm ou PyPI fantôme. Des chercheurs en sécurité ont déjà démontré que des attaquants exploitent ce phénomène (le package hallucination) en publiant des malwares sous les noms de paquets fictifs fréquemment inventés par les IA. Si vos équipes copient-collent ces suggestions sans audit préalable, vous importez directement du code non vérifié sur vos machines de prod. Bref, l'hallucination n'est pas un bug passager qu'une simple mise à jour va balayer : c'est la nature probabiliste même de ces architectures.
1. Dompter la température et l'échantillonnage
Si vous utilisez des API (OpenAI, Anthropic, Mistral) ou que vous faites tourner vos modèles localement sur votre machine avec Ollama ou LM Studio, vous avez accès direct aux hyperparamètres de génération. Le plus critique s'appelle la température.
Par défaut, la température tourne souvent autour de 0.7 ou 1.0 pour apporter de la variété dans l'écriture. Plus elle est haute, plus l'échantillonneur pioche des tokens moins probables pour surprendre le lecteur, ce qui ouvre grand la porte au délire inventif. Si votre tâche exige de la rigueur documentaire, du parsing de données ou de l'analyse logique, descendez la température entre 0.0 et 0.2. Vous obtiendrez des sorties déterministes, répétitives, mais infiniment moins propices aux affabulations artistiques.
2. Forcer le modèle avec la technique du zéro-refus contrôlé
Le principal défaut des modèles fermés des GAFAM, c'est leur tendance compulsive à faire plaisir à l'utilisateur (le fameux biais d'alignement RLHF). Si vous demandez "Quel est le record du monde du 100 mètres couru par un chat ?", certains modèles préfèrent broder une réponse absurde plutôt que de répondre simplement que la question n'a aucun sens.
Pour contrer cela, modifiez vos prompts système en intégrant des clauses de sortie explicites :
- Ajoutez systématiquement l'instruction : "Si tu ne disposes pas d'une source certaine pour répondre, indique textuellement : JE NE SAIS PAS. Ne devine rien."
- Demandez au modèle de décomposer sa réflexion avec du Chain-of-Thought (pensée pas-à-pas) avant de conclure, par exemple en écrivant : "Détaille d'abord les faits bruts identifiés, puis formule ta réponse finale."
- Interdisez l'extrapolation : imposez-lui de travailler en environnement fermé (closed-book) en lui fournissant vous-même le document source.
3. Privilégier le RAG plutôt que la mémoire du modèle
La règle d'or pour éliminer 90 % des inventions : ne demandez jamais à un modèle de se souvenir d'un fait. Utilisez la technique du RAG (Retrieval-Augmented Generation). Au lieu d'interroger la mémoire interne de l'IA (ses poids synaptiques figés lors de l'entraînement), injectez le texte brut de votre documentation ou de votre fichier dans le prompt et ordonnez-lui d'extraire la réponse uniquement à partir de ce texte.
Pour de la recherche web, oubliez les fenêtres de chat basiques déconnectées et tournez-vous vers des moteurs connectés ou des outils comme Perplexity ou Kagi, qui indexent les pages réelles avant de passer la main au modèle. Si vous travaillez sur des données sensibles ou du code interne, montez une stack open source locale avec Ollama couplé à un framework de RAG léger. Vous gardez la main sur les données et vous forcez le générateur à citer les lignes exactes de vos documents.
4. L'arbitrage croisé par modèle miroir
Une méthode redoutable pour débusquer les bobards consiste à automatiser la contradiction. Quand un premier modèle (par exemple GPT-4o) génère un raisonnement complexe ou une liste d'arguments, soumettez immédiatement sa réponse à un modèle concurrent issu d'une autre famille (comme Claude 3.5 Sonnet ou Mistral Large) avec ce prompt précis : "Analyse le texte suivant et pointe uniquement les incohérences factuelles, les liens suspects et les affirmations non démontrables."
Les modèles n'ont pas les mêmes données d'entraînement ni les mêmes angles morts statistiques. Ce qu'un modèle invente par biais d'association de tokens saute immédiatement aux yeux d'une architecture concurrente interrogée en mode relecture critique.
Les erreurs à éviter
Pour rester du bon côté de la barrière, évitez ces pièges récurrents :
- Faire confiance au ton affirmatif : L'assurance stylistique d'un LLM n'a strictement aucun rapport avec sa précision factuelle. Plus il parle comme un prof émérite, plus vous devez douter.
- Valider des liens ou des identifiants sans cliquer : Les DOI d'articles scientifiques, les URL web et les numéros ISBN générés par les modèles sont quasi systématiquement des chimères recomposées. Testez chaque lien.
- Demander des calculs mathématiques bruts : Les LLM sont nuls en arithmétique pure dès qu'on sort des tables basiques. Exigez qu'il écrive et exécute un script Python pour calculer le résultat plutôt que de le laisser prédire les chiffres au jugé.
Notre verdict
Les hallucinations ne sont pas une anomalie passagère, c'est le mécanisme même de fonctionnement des modèles de langage probabilistes. Appliquez dès aujourd'hui une politique Zero Trust à toutes les sorties générées : réglez votre température au plus bas sur vos tâches factuelles, forcez le modèle à avouer son ignorance, et ne validez aucune ligne de code sans l'avoir lue et testée vous-même.
Sources et références
- Tribunal de district des États-Unis pour le district sud de New York, affaire Mata v. Avianca, Inc. (2023) concernant l'utilisation non vérifiée de citations générées par ChatGPT.
- Documentation technique OpenAI et Anthropic relative aux paramètres de génération (temperature, top_p) et aux limitations factuelles des LLM.
- Travaux de recherche sur les risques d'hallucinations de paquets logiciels (Vulcan Cyber, 2023).
- Conférence d'Andrej Karpathy sur le fonctionnement interne des grands modèles de langage (YouTube).