BlogIALes LLMs donnent parfois des réponses qui « sonnent » justes mais sont factuellement fausses, ou inventent des détails inexistants. On appelle cela des hallucinations. Elles cassent la confiance, créent des risques juridiques, et brouillent la prise de décision. La bonne nouvelle: on peut fortement en réduire la fréquence perçue en combinant trois leviers simples et complémentaires: des sources visibles, une détection automatique raisonnable, et des politiques de refus lisibles par l’utilisateur.
Ce que sont vraiment les hallucinations — Ce n’est pas seulement une « erreur »: c’est une affirmation qui n’est pas supportée par une source fiable dans le contexte fourni, ou qui contredit une donnée vérifiable. Le modèle n’est pas « malveillant »: il extrapole lorsqu’il manque d’information, ou optimise pour la fluidité du texte plutôt que la véracité. La prévention consiste donc à apporter des preuves et à définir ce qui est acceptable quand la preuve manque.
Pourquoi elles apparaissent —
Manque d’ancrage documentaire: la réponse est produite sans références (pas de RAG, ou contexte mal sélectionné).
Ambiguïté du prompt: la consigne ne précise pas de citer des sources, ni de refuser en cas d’incertitude.
Domaines sensibles: médicale, juridique, finance, processus internes d’entreprise.
Sorties « contraignantes »: JSON à remplir, valeur chiffrée à donner, nom propre à produire; le modèle comble les trous.
Philosophie produit — On n’obtient jamais zéro hallucination. L’objectif est de rendre le système prévisible, avec des preuves et un comportement de « prudence » quand la confiance est faible. Ce que l’utilisateur vit au quotidien compte plus qu’un score académique.
1) Ancrer les réponses dans des sources visibles —
Utiliser un RAG ou une base métier: injecter dans le prompt des extraits pertinents, horodatés et sourcés.
Exiger les citations: « Pour chaque affirmation factuelle, citer 1–3 passages avec liens. »
Mettre en forme la preuve: afficher sous la réponse les documents cités et surligner l’extrait utile.
Définir le refus: si aucune source ne supporte l’affirmation, demander plus de contexte ou refuser poliment.
L’expérience utilisateur change immédiatement quand les preuves sont visibles. Une réponse exacte mais sans preuve inspire moins confiance qu’une réponse prudente avec sources claires.
2) Détection automatique à coût raisonnable — On cherche des signaux de « faible fidélité » sans exploser les coûts.
Entailment: vérifier que le contenu généré est « supporté » par les passages du contexte. Les contradictions ou inférences trop lointaines déclenchent une alerte.
Cohérence interne: repérer les inversions de dates, d’unités, de noms au sein d’une même réponse.
Cross‑check léger: poser la même question avec 1–2 variantes de prompts; si les réponses divergent fortement, baisser la confiance.
Validation de format: si l’on exige du JSON, valider strictement le schéma; les déviations de format sont un bon proxy d’instabilité.
Concrètement, on calcule un score de confiance agrégé (0–1) à partir de ces signaux. En dessous d’un seuil, on active le mode « prudent ».
3) Politiques de refus lisibles — En dessous du seuil de confiance, le système doit s’arrêter proprement.
Messages clairs: « Je ne trouve pas de source fiable pour confirmer X. Voulez‑vous préciser Y ? »
Classes sensibles: en finance/juridique/santé, interdire les réponses non sourcées. Rediriger vers une ressource vérifiée ou un humain.
Garde‑fous par défaut: pour les calculs, conversions d’unités, et valeurs chiffrées, demander confirmation utilisateur.
L’important n’est pas d’être parfait, mais d’être prévisible et honnête. Un « je ne sais pas » bien formulé vaut mieux qu’une fiction confiante.
4) Intégration dans un flux produit — Le système doit agir sans friction.
Après génération, calculer automatiquement le score de confiance (entailment + cohérence + format).
Si score haut: afficher la réponse avec sources; autoriser l’action (ex: création de ticket) si le domaine n’est pas sensible.
Si score moyen: afficher la réponse, marquer « prudence », proposer une reformulation ou une recherche de sources supplémentaires.
Si score bas: demander des précisions, ou refuser poliment avec suggestions; afficher quand même les sources trouvées (même si insuffisantes).
Cette logique simple évite 80% des catastrophes sans coûteux pipelines.
5) Boucles humaines ciblées — L’humain intervient là où il a de la valeur.
Échantillon: 5–10% des interactions, plus un sur‑échantillon automatique des cas à faible confiance ou signalés.
Grille d’évaluation: factualité, utilité, clarté, sécurité (1–5) + commentaire libre.
Catégorisation des erreurs: invention, confusion de noms, hors sujet, raisonnement cassé, format invalide.
Exploitation: corriger les prompts (exiger preuves), améliorer l’index RAG (meilleurs champs et filtres), enrichir les données d’entraînement si besoin.
Les revues doivent être tracées: « qui a changé quoi, quand, pourquoi ». C’est vital pour comprendre les dérives.
6) Mesurer sans s’illusionner —
FE‑rate (Factual Error rate): part des réponses factuellement fausses dans un échantillon.
FPR « injuste »: part des refus alors qu’une bonne réponse sourcée était possible (pour éviter un système trop timide).
Délai moyen d’obtention d’une réponse de confiance: inclut le temps de re‑prompt ou de demande de précision.
Tendance: suivre ces métriques par domaine et par version de modèle.
Mettre des objectifs réalistes (par exemple FE‑rate < 3% sur le domaine support) et les tenir dans la durée vaut mieux qu’un score ponctuel.
Exemple concret: FAQ métier — Une entreprise gère une FAQ interne (politiques RH, procédures). Le LLM répond avec un RAG sur la base documentaire.
Ancrage: chaque réponse cite 1–2 extraits du wiki interne avec lien.
Détection: entailment bas si l’extrait ne supporte pas la phrase; cross‑check léger sur 1 variante de prompt.
Politique de refus: si pas de source à jour, proposer d’ouvrir un ticket RH; message « politique en révision » si document trop ancien.
Résultat: baisse des escalades vers l’équipe RH et hausse de la confiance perçue, même quand la réponse est « je ne sais pas ».
Autre exemple: sorties structurées — Générer un JSON de configuration.
Validation stricte de schéma: si invalide, régénérer une fois; si re‑échec, basculer en mode « propose un brouillon et demande validation ».
Entailment ciblé: vérifier que les valeurs du JSON sont mentionnées (ou justifiées) dans les sources du prompt.
Trace: stocker le brouillon et la version validée par l’utilisateur.
Erreurs fréquentes —
Penser qu’un « meilleur prompt » suffit. Les gains existent, mais plafonnent vite sans preuves.
Tout miser sur un méga‑classifieur « hallucinomètre ». Coûteux et fragile hors distribution; préférez des signaux simples et combinés.
Cacher les refus. Mieux vaut montrer la prudence du système que faire semblant de savoir.
Oublier la maintenance des sources: un RAG pollué par des documents obsolètes crée de « fausses preuves ».
Négliger l’UX de la preuve: des liens minuscules ou des références cryptiques n’aident pas l’utilisateur.
Checklist de mise en place (copier‑coller) —
Prompts exigent explicitement des sources et définissent le refus en cas d’incertitude.
RAG ou base métier fournit des extraits horodatés; liens visibles et passages surlignés.
Score de confiance agrégé: entailment + cohérence interne + validation de format.
Seuils et politiques: haut → répondre; moyen → prudence/demander précision; bas → refuser poliment.
Boucle humaine: échantillon + cas à faible confiance; grille d’évaluation simple.
Mesures: FE‑rate, FPR injuste, délai de réponse de confiance; suivi par domaine/version.
Hygiène des sources: documents obsolètes identifiés, archivés ou mis à jour.
Journalisation: trace par requête (prompt, sources, score, décision, révision humaine).
En combinant sources visibles, détection légère et refus lisible, vous transformez la relation utilisateur: le système ne prétend pas tout savoir, mais il devient fiable et auditable. Et cela suffit souvent à faire passer vos métriques de satisfaction au vert. original: true category: Guide tags:
Qualité
Hallucinations
LLM permalink: /guides/hallucination-detection-2025/