Hallucinations LLM : 7 techniques pour les réduire (au-delà du multi-agent)

Si votre agent commercial B2B hallucine le titre d’un prospect, vous avez acheté un remboursement. S’il invente un historique d’achat dans un email de relance, vous avez acheté un churn. En production, les hallucinations ne sont pas une curiosité de recherche, c’est un problème d’unit economics. Ce guide classe les 7 techniques qui font vraiment bouger l’aiguille en production, avec leurs arbitrages coût / impact, et explique pourquoi le célèbre “débat multi-agent” est rarement le bon premier réflexe.

#TL;DR

Règle de décision : grounder d’abord, vérifier ensuite, débattre quasi jamais. Le débat multi-agent est la dernière technique à ajouter, pas la première.

Les 7 techniques, classées par ROI pour un agent en production :

1. Grounding par retrieval (RAG bien fait), la plus grosse chute du taux d’hallucination.
2. Boucles tool-use avec vérification, transformer “quel est l’email ?” en appel d’outil, pas en devinette.
3. Few-shot examples dans le system prompt, peu cher, rapide, étonnamment efficace.
4. Calibration de confiance via log probs, savoir quand le modèle bluffe.
5. Constitutional AI / output filtering, attraper la régression avant qu’elle parte en prod.
6. Human-in-the-loop sur les actions destructrices, l’assurance dernier kilomètre.
7. Itération de prompt pilotée par les évals, la seule technique qui compose dans le temps.

Les taux d’hallucination des modèles frontière sur la tâche de résumé varient de 1,3 % à 15,8 % selon le modèle, d’après le classement Vectara Hughes Hallucination Evaluation Model (HHEM), 2024. Passé un certain seuil, les choix d’architecture comptent plus que le choix du modèle.

#Pourquoi le débat multi-agent n’est pas le bon premier réflexe

Le papier original de Du et al. “Improving Factuality and Reasoning in Language Models through Multiagent Debate”, 2023, issu du MIT et de Google, montre des gains mesurables de précision sur des benchmarks de math et de raisonnement quand trois instances de modèle débattent avant de produire une réponse finale. Le papier est rigoureux. La conclusion est réelle. Mais son applicabilité en production sur un agent commercial est beaucoup plus faible que ne le suggère son nombre de citations.

Trois raisons à cela. D’abord, la latence triple. Une réponse de 4 secondes passe à 12 secondes, ce qui tue l’UX conversationnelle en chat et casse les boucles d’outreach en temps réel. Ensuite, le coût en tokens triple au minimum, souvent 5x une fois qu’on ajoute un modérateur. Enfin, le mode d’échec par consensus est réel : quand les trois instances partagent leurs données d’entraînement, elles s’accordent avec assurance sur la même hallucination. Le débat amplifie le consensus, pas la vérité.

Le débat a sa place. Réservez-le aux analyses offline en batch où la latence n’est pas un sujet et où le coût d’erreur est élevé. Pour les workflows commerciaux temps réel, les six autres techniques de cette liste vous donnent une meilleure factualité par euro investi. Si vous voulez creuser cette technique, voyez notre guide pillar dédié au débat multi-agent comme méthode anti-hallucination.

#Technique 1 : Grounding par retrieval (RAG bien fait)

Le retrieval-augmented generation est le levier le plus puissant que vous puissiez activer contre les hallucinations. Une couche RAG bien réglée peut réduire les taux d’hallucination sur les requêtes factuelles de 71 % en moyenne, d’après le rapport “RAG Hallucination Benchmark” de Galileo, 2024. Le piège : la plupart des implémentations RAG en production ne sont pas bien réglées. Elles récupèrent les mauvais chunks, et le modèle génère consciencieusement quelque chose de plausible.

Trois choses séparent le RAG qui fonctionne du RAG démo qui ne tient pas la charge.

#Chunkez sémantiquement, pas par compteur de tokens

Découper les documents en chunks de 512 tokens est la solution la plus facile et la pire. Une note CRM sur un prospect se coupe en plein milieu de “il a souscrit l’essai en mars dernier puis a étendu vers” et l’agent ne récupère que la première moitié. Utilisez du chunking sémantique, des splits paragraphe par paragraphe, ou des chunks structurés par champ CRM. Votre rappel grimpe sans toucher au modèle.

#Utilisez de la recherche hybride, pas du pur vecteur

La recherche vectorielle seule rate les requêtes exact-match sur les noms, les identifiants et les montants. La recherche hybride (BM25 plus dense retrieval, avec reciprocal rank fusion) capture les deux. La recherche Contextual Retrieval d’Anthropic, septembre 2024 a montré que les approches hybrides réduisent les échecs de retrieval de 49 % par rapport aux embeddings seuls.

#Citez la source dans la réponse

Forcez le modèle à inclure l’identifiant du chunk ou l’URL du document dans sa sortie. Ça fait deux choses : ça vous donne une piste vérifiable pour le QA, et ça rend le modèle plus conservateur parce qu’il doit pointer d’où vient l’affirmation. S’il ne peut pas citer, il doit dire “je n’ai pas cette information” plutôt que d’inventer.

#Technique 2 : Boucles tool-use avec vérification

Si le modèle a besoin d’un fait, ne le laissez pas deviner. Donnez-lui un outil qui va chercher le fait. Une évaluation OpenAI de 2024 sur les agents tool-augmented a montré que le function calling structuré réduit significativement les taux d’entités fabriquées par rapport à l’extraction purement par prompt.

Le pattern pour un agent commercial B2B ressemble à ça :

Utilisateur : "Envoie une relance à Sarah chez Acme sur la démo Q4."

Agent naïf : rédige l'email, hallucine le nom de famille et l'adresse de Sarah.

Agent tool-using :
 → appel lookup_contact({company: "Acme", first_name: "Sarah"})
 ← retourne [{name: "Sarah Chen", email: "[email protected]", last_contact: "..."}]
 → rédige l'email avec des données vérifiées
 → appel verify_email_deliverable("[email protected]")
 ← retourne {deliverable: true, mx_record_valid: true}
 → envoie

L’étape de vérification est celle que la plupart des builders sautent. Après que l’outil a renvoyé ses données, passez un second appel LLM léger qui vérifie : la réponse a-t-elle utilisé uniquement les champs que l’outil a effectivement retournés, ou a-t-elle ajouté des champs absents ? Si elle a ajouté des champs non vérifiés, régénérez. C’est ce que la littérature appelle “self-consistency checking”.

Le coût est d’un appel LLM supplémentaire par tour. Le bénéfice est d’éliminer des classes entières d’hallucinations à la source.

#Technique 3 : Few-shot examples dans le system prompt

Le few-shot prompting est passé de mode à l’ère des modèles frontière zero-shot. C’est pourtant un des réducteurs d’hallucinations les plus coût-efficaces que vous puissiez déployer. La revue In-Context Learning de Microsoft Research, 2023 recense des gains de précision substantiels avec des exemples bien choisis, et ces gains sont les plus marqués sur les requêtes factuelles edge-case.

Pour un agent commercial, vos exemples few-shot doivent couvrir les modes d’échec que vous voyez réellement en production. Trois catégories comptent plus que les autres.

#Patterns de refus

Montrez au modèle à quoi ressemble “je ne sais pas” dans votre domaine :

Utilisateur : "Quel est le process d'approbation budgétaire chez Acme ?"
Assistant : "Je n'ai pas de visibilité sur le process budgétaire interne d'Acme.
Je peux remonter les données qu'on a sur leur dernier bon de commande si utile."

Sans cet exemple, le modèle invente une chaîne d’approbation. Avec, il revient sur l’honnêteté par défaut.

#Patterns d’appel d’outil

Montrez le format exact des outils que vous voulez voir utilisés, avec un exemple positif et un exemple négatif. Les modèles entraînés sur des traces de function calling régressent parfois vers des structures d’arguments plausibles-mais-fausses. Une seule démonstration in-context verrouille le schéma.

#Patterns de format de sortie

Si l’agent doit produire du JSON avec des champs spécifiques, démontrez-le. S’il doit envoyer un email dans votre ton, collez un exemple d’email qui est exactement le ton voulu. Le modèle imite les exemples beaucoup plus fidèlement qu’il ne suit des instructions abstraites.

Gardez votre bloc few-shot sous 1 500 tokens pour rester coût-efficace. Faites tourner les exemples chaque semaine selon votre suite d’évals. Les exemples sont un actif, pas un one-shot.

#Technique 4 : Calibration de confiance via log probs

La plupart des agents en production agissent sur chaque sortie du modèle avec la même confiance. Ils ne devraient pas. Les fournisseurs d’API modernes exposent les log probabilities au niveau du token, qui vous disent à quel point le modèle était sûr de chaque token qu’il a généré. Servez-vous-en.

L’API OpenAI expose logprobs sur l’endpoint chat completion. Anthropic expose des signaux de confiance via les chemins de retour tool-use. Le pattern : après génération, vous calculez la moyenne géométrique des probabilités de tokens sur la portée de la réponse. En dessous d’un seuil (à calibrer par usage, typiquement entre 0,7 et 0,85), vous déclenchez une des trois actions :

1. Réessayer avec une température différente ou un modèle plus fort.
2. Escalader vers un human-in-the-loop.
3. Refuser avec une réponse du type “je ne suis pas assez confiant pour répondre”.

Un papier DeepMind sur la calibration des LLM, 2023 a montré que la prédiction sélective (refuser les sorties basse confiance) améliore substantiellement la précision des réponses du modèle au prix de la couverture. Pour un agent commercial, cet arbitrage est exactement celui que vous voulez : mieux vaut sauter une réponse à faible confiance que d’envoyer une hallucination à un prospect qui paie.

Deux notes opérationnelles. Les log probs se calculent au niveau du token, donc un seul token à faible probabilité dans une longue réponse peut faire chuter votre score agrégé sans bonne raison. Utilisez un seuil par percentile (par exemple la probabilité au 10e percentile) plutôt que la moyenne. Et calibrez le seuil par type de tâche : un brouillon de ligne d’objet créatif tolère plus d’incertitude qu’un lookup de donnée CRM.

#Technique 5 : Constitutional AI et output filtering

La recherche Constitutional AI d’Anthropic, 2022 a introduit le pattern d’une seconde passe sur le contenu généré pour le vérifier contre un jeu de règles écrites. En production, ça s’appelle aussi output filtering ou guardrail layers, et c’est une des polices d’assurance les moins chères à acheter.

Pour un agent commercial, une constitution utile est courte et spécifique :

• La réponse ne doit pas contenir de montants en euros sauf s’ils ont été renvoyés par un appel d’outil dans ce tour.
• La réponse ne doit pas nommer une personne sauf si cette personne apparaît dans le contexte retrouvé.
• La réponse ne doit pas promettre une date de livrable.
• La réponse ne doit pas revendiquer une capacité produit hors d’une liste approuvée fixe.

Passez chaque réponse générée par un classifieur rapide (un petit appel LLM, ou un modèle classifieur fine-tuné) qui vérifie la conformité. Si la réponse viole une règle, vous régénérez ou vous escaladez.

Le surcoût est d’un appel modèle bon marché par réponse, typiquement sous 200 ms avec un petit modèle rapide comme Haiku, GPT-4 mini ou un Llama 3 8B hébergé. Le piège est la calibration : écrivez vos règles en langage clair avec des exemples explicites de ce qui compte comme violation. Les règles vagues (“sois honnête”) produisent un filtrage incohérent. Les règles spécifiques (“ne mentionne pas un prix qui n’est pas dans le contexte retrouvé”) attrapent les bugs qui partent en prod.

#Technique 6 : Human-in-the-loop sur les actions destructrices

Certaines actions d’un agent sont réversibles. Rédiger un email est réversible jusqu’au moment où vous appuyez sur envoi. Mettre à jour une note CRM l’est aussi, à peu près. Envoyer un message à froid à un VP d’un named account ne l’est pas, en aucun sens business utile.

Le pattern est binaire : classez chaque action que votre agent peut prendre comme réversible ou destructrice, et exigez une approbation humaine pour la classe destructrice. En B2B sales, la liste destructrice inclut typiquement les messages outbound vers des comptes nommés, les invitations calendrier vers des destinataires externes, les updates CRM qui changent le stage ou le montant d’une affaire, et toute dépense au-dessus d’un seuil configuré.

L’UX d’approbation compte plus que la politique. Si les approbations sont enterrées dans une queue d’emails, le goulot humain tue le throughput de l’agent et les opérateurs désactivent le human-in-the-loop sous deux semaines. Construisez la surface d’approbation là où l’opérateur vit déjà, typiquement Slack, avec un clic pour approuver, éditer ou tuer. Auto-approuvez après une fenêtre configurable pour les comptes à faible enjeu. Bloquez en dur pour les segments VIP.

Une leçon de mise en oeuvre qui mérite d’être citée : instrumentez le taux d’approbation comme une métrique de première classe à côté de la conversion. Si votre taux d’approbation est au-dessus de 95 % sur chaque type d’action, l’humain tamponne sans lire et vous pouvez étendre la surface autonome. S’il est en dessous de 70 %, l’agent produit trop de sorties basse qualité et vous avez un problème plus profond dans une couche antérieure (données, retrieval ou prompting).

#Technique 7 : Itération de prompt pilotée par les évals

On ne peut pas améliorer ce qu’on ne mesure pas. Une suite d’évals est la seule technique de cette liste qui compose dans le temps. Toutes les autres vous donnent une amélioration one-shot. Les évals vous donnent un flywheel.

L’essai Your AI Product Needs Evals de Hamel Husain, 2024 défend la thèse mieux que quiconque : construisez la suite d’évals avant d’expédier le prompt, et traitez chaque échec en production comme un nouveau cas de test. La discipline compte plus que l’outillage.

Une suite d’évals minimale pour un agent commercial a trois couches.

#Couche 1 : cas unit-test

20 à 50 prompts déterministes avec des sorties attendues, lancés à chaque changement de prompt. Exemples : “Quand l’utilisateur demande un prix qui n’est pas dans le contexte, l’agent refuse.” “Quand l’outil lookup_contact ne renvoie rien, l’agent n’invente pas de contact fallback.”

#Couche 2 : LLM-as-judge sur échantillons production

Échantillonnez 1 % des réponses production chaque jour et passez-les par un modèle plus fort (classe Claude Sonnet, GPT-4) avec une grille structurée : “Cette réponse cite-t-elle une source vérifiée pour chaque affirmation factuelle ? Score 1 à 5 avec justification.” Suivez le score dans le temps. Une régression ici signale que votre retrieval ou votre prompting a dérivé.

#Couche 3 : golden set labellisé à la main

50 à 100 réponses labellisées à la main, rafraîchies tous les trimestres, avec des critères pass-or-fail explicites. C’est la couche lente, chère, irremplaçable. Servez-vous-en pour valider que le LLM-as-judge est lui-même calibré.

Le coût est réel, vous y dépenserez du temps d’ingénierie que vous préféreriez mettre sur des features. Le bénéfice est que vous pouvez changer de prompts, swapper de modèle et refactoriser vos boucles d’agent sans peur.

#Comment stacker les techniques en production

Les 7 techniques ne sont pas un menu où l’on choisit une option. Ce sont des couches, et elles composent. L’ordre d’empilement recommandé, par ROI par semaine d’ingénierie :

1. Semaine 1 : expédiez le grounding (Technique 1) et les boucles tool-use (Technique 2). Ça élimine la pire classe d’hallucination (faits inventés) à la source.
2. Semaine 2 : ajoutez les few-shot examples (Technique 3) et une suite d’évals basique (Technique 7, couche 1). Vous pouvez maintenant mesurer le progrès.
3. Semaine 3 : ajoutez l’output filtering (Technique 5) pour les modes d’échec spécifiques de votre domaine.
4. Semaine 4 et au-delà : ajoutez la calibration de confiance (Technique 4) pour la prédiction sélective, et les checkpoints human-in-the-loop (Technique 6) sur les actions destructrices. Étendez les évals (Technique 7, couches 2 et 3).
5. Seulement si nécessaire : envisagez le débat multi-agent pour les tâches d’analyse offline où la latence n’est pas une contrainte.

L’ordre compte parce que chaque technique couvre un mode d’échec différent. Le grounding règle “les faits inventés”. Le tool-use règle “les attributs d’entité inventés”. Les few-shot règlent “le mauvais format”. La calibration règle “le bluff confiant”. Le filtering règle “les violations de politique qui passent”. Le human-in-the-loop règle “les actions destructrices sur contexte halluciné”. Les évals règlent “on ne sait pas si on s’améliore”.

Sautez une couche et vous acceptez le mode d’échec correspondant en production.

#Là où Tasmela applique ces techniques

Tasmela provisionne un agent IA dédié par client qui tourne sur une instance Hetzner par tenant, avec la stack OpenClaw qui gère les boucles tool-use, le grounding par intégration (CRM, Google Workspace, Slack, etc.) et les checkpoints human-in-the-loop sur les messages outbound. Le LLM est swappable au runtime via OpenRouter, ce qui permet de router les tâches à faible enjeu vers des modèles moins chers et les tâches à fort enjeu vers des modèles frontière sans réécrire votre agent. Les seuils de calibration et les exemples few-shot sont configurés par instance.

Si vous évaluez build-or-buy, la page /tarifs détaille la structure de crédits et la matrice d’intégrations.

#FAQ

#Quelle est la différence entre hallucination et bullshit dans le contexte d’un LLM ?

Dans l’article ChatGPT is bullshit de Hicks, Humphries et Slater, 2024, les auteurs défendent l’idée que les erreurs des LLM sont mieux décrites comme du bullshit (indifférence à la vérité) que comme des hallucinations (fausse perception). Pour les builders, la distinction compte : “hallucination” sous-entend qu’on peut “soigner” le modèle, “bullshit” sous-entend qu’il faut injecter la vérité par grounding externe. Les 7 techniques de ce guide supposent toutes le cadre bullshit : ne faites pas confiance au modèle pour savoir ce qui est vrai, donnez-lui accès à ce qui est vrai.

#Les modèles de raisonnement comme o1 et Claude 3.7 hallucinent-ils moins ?

Preuves mitigées. D’après le classement Vectara HHEM, 2024, les modèles de raisonnement peuvent afficher des taux d’hallucination supérieurs sur les tâches de résumé par rapport à leurs équivalents non-raisonnement. Le raisonnement aide sur la logique et la math, mais ne réduit pas fiablement la confabulation au niveau des faits-entités. Traitez les modèles de raisonnement comme un upgrade pour certaines tâches, pas comme un correctif aux hallucinations.

#Le fine-tuning est-il un bon moyen de réduire les hallucinations ?

Rarement, et généralement pour de mauvaises raisons. Le fine-tuning fige des connaissances dans les poids, ce qui veut dire que les erreurs se cuisent dans le modèle. D’après la documentation OpenAI sur les bonnes pratiques de fine-tuning, le fine-tuning est meilleur pour le shaping comportemental (ton, format, patterns de refus) que pour l’injection de connaissances factuelles. Pour les faits, utilisez RAG.

#Comment mesurer le taux d’hallucination en production ?

Échantillonnez, labellisez, suivez. Tirez 100 réponses production par semaine, labellisez chacune comme “factuelle”, “refusée correctement” ou “hallucinée”, et suivez le taux d’hallucination dans le temps. Des outils comme Galileo et Patronus AI offrent des pipelines d’évaluation hébergés, mais une Google Sheet plus une revue hebdomadaire suffit pour les 6 premiers mois. La discipline compte plus que la plateforme.

#Quand le débat multi-agent vaut-il vraiment le coup ?

Utilisez le débat pour de l’analyse offline où la latence n’est pas une contrainte et où le coût d’erreur est élevé : rapports de due diligence, analyse de contrats, résumés post-call notés par 3 runs de modèle séparés. Pour des agents conversationnels temps réel en sales, les 6 autres techniques vous donnent une meilleure factualité par euro et par seconde.

#À lire ensuite

• Comment réduire les hallucinations d’un LLM : le débat multi-agent (guide 2026), le guide pillar dédié à la technique du débat, complémentaire à celui-ci.
• Agent IA Clarity : analyser le comportement des utilisateurs avec une IA, une application concrète du tool-use et du grounding sur données analytics.
• Comment donner accès à LinkedIn à un agent IA, la couche action où l’output filtering compte le plus.
• Réduire les no-show avec un agent IA et Twilio, un exemple en production du checkpoint human-in-the-loop entre brouillon et envoi SMS.