Hallucinations des LLM en production : trois couches de validation pour les intercepter

Les modèles de langage génèrent des réponses confiantes même quand ils inventent. Voici une architecture concrète en trois niveaux pour détecter l'incertitude avant qu'elle n'atteigne vos utilisateurs.

Selon une étude Vectara, les modèles de langage les plus performants du marché hallucinent dans 3 à 27 % de leurs réponses selon les tâches. Ce chiffre prend une dimension différente quand le modèle répond à un client sur vos conditions contractuelles, génère un résumé de données médicales ou alimente un tableau de bord décisionnel. Le problème central n'est pas que le LLM se trompe. C'est qu'il se trompe avec aplomb. Aucun signal d'hésitation, aucun avertissement. La réponse fausse a exactement la même apparence qu'une réponse correcte.

Pour une TPE ou PME qui déploie une application IA sur des données internes, ce comportement constitue un risque opérationnel direct : informations erronées transmises aux clients, décisions prises sur des bases fictives, ou pire, exposition de données sensibles mal interprétées. La parade ne passe pas par un meilleur prompt. Elle passe par une architecture de détection qui évalue mathématiquement la fiabilité de chaque réponse avant qu'elle ne soit affichée.

Pourquoi un LLM hallucine (et pourquoi un prompt ne suffit pas à l'en empêcher)

Un modèle de langage ne comprend pas le sens des mots. Il calcule des probabilités de séquences de tokens en fonction de son entraînement. Quand il ne dispose pas d'information pertinente pour répondre, il ne dit pas "je ne sais pas". Il génère la suite de tokens la plus probable statistiquement, même si cette suite ne correspond à aucune réalité.

C'est ce qu'on appelle une hallucination : une réponse syntaxiquement correcte, stylistiquement convaincante, mais factuellement inventée. Les causes identifiées sont multiples. Des données d'entraînement incomplètes ou contradictoires, une sur-généralisation du modèle, ou encore un contexte insuffisant dans le prompt. Selon les analyses de DataSolution, les hallucinations se manifestent principalement sous trois formes : l'invention pure de faits inexistants, la contradiction avec le contexte fourni, et la fabrication de sources fictives.

La réponse intuitive serait d'ajouter des instructions dans le prompt système : "Ne réponds que si tu es sûr", "Cite tes sources". En pratique, ces garde-fous sont contournables. Un LLM peut fabriquer des citations convaincantes, inventer des références bibliographiques complètes, et affirmer sa certitude sur une information fausse. Le prompt est une consigne, pas une contrainte technique. Pour aller plus loin sur les mécanismes réels derrière ces modèles, cet article sur la vérité technique de l'IA générative pose les bases nécessaires.

La seule approche fiable repose sur des métriques calculées, indépendantes de ce que le modèle prétend savoir.

Couche 1 : la validation du domaine, ou comment vérifier que la question a du sens

La première ligne de défense est la plus simple conceptuellement : s'assurer que la question posée appartient bien au périmètre de connaissance du système. Si un utilisateur interroge un assistant spécialisé en comptabilité sur une recette de cuisine, la réponse ne devrait jamais être générée.

Cette validation repose sur la similarité vectorielle. Chaque document de votre base de connaissances est converti en vecteur numérique (embedding). La question de l'utilisateur est elle aussi vectorisée. On calcule ensuite la distance cosinus entre le vecteur de la question et les vecteurs des documents disponibles.

Concrètement, si le score de similarité le plus élevé entre la question et vos documents est inférieur à un seuil défini (typiquement entre 0.3 et 0.5 selon les modèles d'embedding), la question est considérée hors domaine. Le système renvoie un message clair : "Cette question ne fait pas partie de mon périmètre" au lieu de tenter une réponse hasardeuse.

Cette couche filtre les requêtes aberrantes, les tentatives de détournement (prompt injection), et les questions légitimes mais hors sujet. Elle est peu coûteuse en ressources et élimine une part significative des scénarios d'hallucination avant même que le modèle ne soit sollicité.

Limite importante : cette couche ne protège pas contre les hallucinations sur des questions qui sont bien dans le domaine. Un utilisateur peut poser une question pertinente pour laquelle les documents récupérés sont insuffisants ou ambigus. C'est le rôle de la deuxième couche.

Couche 2 : l'évaluation de la qualité du contexte récupéré (RAG)

Dans une architecture RAG (Retrieval-Augmented Generation), le modèle ne répond pas uniquement à partir de sa mémoire. Il s'appuie sur des documents récupérés dans une base vectorielle pour construire sa réponse. C'est un mécanisme puissant, mais il introduit un nouveau point de défaillance : la qualité des documents récupérés.

Un document peut être remonté par le moteur de recherche vectorielle tout en étant partiellement pertinent, obsolète, ou insuffisant pour répondre à la question. Le modèle, lui, ne fait pas cette distinction. Il exploite ce qu'on lui donne et génère une réponse en apparence cohérente.

La deuxième couche de validation évalue donc la pertinence réelle du contexte avant de le transmettre au LLM. Plusieurs métriques entrent en jeu :

• Le score de similarité moyen des documents récupérés. Si les 3 à 5 meilleurs résultats ont des scores faibles (sous 0.4), le contexte est probablement insuffisant.
• La couverture thématique : les documents couvrent-ils les différents aspects de la question, ou se répètent-ils sur un seul point ?
• La fraîcheur des données : pour des sujets évolutifs (réglementations, tarifs, procédures), un document daté peut induire une réponse incorrecte.

Si les métriques de qualité sont sous les seuils acceptables, le système peut soit refuser de répondre, soit avertir explicitement l'utilisateur que la réponse s'appuie sur un contexte limité. Pour les entreprises qui envisagent de coupler IA générative et bases documentaires internes, le guide sur la conformité et la performance RAG pour PME détaille les bonnes pratiques à suivre.

Cette couche est celle qui demande le plus de calibration. Les seuils varient selon le domaine, la nature des documents et le niveau de risque acceptable. Mon conseil : commencez avec des seuils conservateurs (qui rejettent beaucoup), puis affinez en analysant les cas rejetés à tort.

Couche 3 : l'analyse des probabilités de tokens (logprobs)

C'est la couche la plus technique, mais aussi la plus révélatrice. Les LLM modernes comme GPT-4, Claude ou Mistral peuvent exposer les log-probabilités (logprobs) de chaque token généré. Ces valeurs indiquent le niveau de confiance du modèle au moment de choisir chaque mot de sa réponse.

Un logprob proche de 0 signifie que le modèle est très confiant dans son choix. Un logprob fortement négatif (par exemple -5 ou en dessous) signale une hésitation statistique : le modèle a choisi ce token parmi plusieurs alternatives sans certitude claire.

En calculant la moyenne des logprobs sur l'ensemble de la réponse, ou en identifiant des segments à faible confiance, on obtient une carte d'incertitude objective. Si la moyenne descend sous un seuil critique, ou si des passages clés (noms, chiffres, dates) présentent des logprobs faibles, la réponse est signalée comme potentiellement hallucinée.

Cette approche a un avantage décisif : elle est indépendante du contenu sémantique. Elle ne juge pas si la réponse a l'air correcte. Elle mesure si le modèle était statistiquement sûr de lui en la produisant. C'est une différence fondamentale.

Les limites existent : tous les fournisseurs d'API ne donnent pas accès aux logprobs. OpenAI les expose sur certains modèles, mais d'autres providers les masquent. De plus, un modèle peut être confiant et faux (hallucination à haute confiance), ce qui explique pourquoi cette couche fonctionne en complément des deux précédentes, jamais seule. Les SLM (Small Language Models), déployés localement, offrent souvent un accès complet à ces métriques, ce qui les rend particulièrement adaptés aux architectures de validation strictes.

Comment assembler les trois couches dans un système réel

Chaque couche prise isolément réduit le risque d'hallucination. Leur combinaison crée un pipeline de validation où chaque étape compense les angles morts de la précédente.

Le flux de traitement suit cette logique :

• Étape 1 : la question arrive. Le système calcule sa similarité vectorielle avec la base documentaire. Score insuffisant ? Réponse refusée avec message explicite.
• Étape 2 : les documents pertinents sont récupérés. Leur qualité est évaluée (score moyen, couverture, fraîcheur). Contexte insuffisant ? Réponse nuancée ou refusée.
• Étape 3 : le LLM génère sa réponse. Les logprobs sont analysés en temps réel. Confiance trop basse sur des segments critiques ? La réponse est annotée d'un avertissement ou bloquée.

Ce pipeline ajoute entre 100 et 500 millisecondes de latence selon l'implémentation, ce qui reste acceptable pour la plupart des applications métier. Le coût computationnel est marginal comparé au coût d'une information erronée transmise à un client ou utilisée dans une décision.

Un point souvent négligé : ce système produit des logs exploitables. Chaque réponse bloquée ou signalée génère une trace avec les scores de chaque couche. Ces données permettent d'améliorer continuellement la base documentaire, d'identifier les questions récurrentes mal couvertes, et d'affiner les seuils de détection.

C'est un principe qui prend tout son sens dans le cadre de projets d'Automatisation & IA, où chaque composant du pipeline est conçu pour fonctionner de manière autonome tout en s'intégrant dans une chaîne de traitement cohérente.

Ce que cette architecture ne résout pas

Il serait malhonnête de présenter ce système comme une solution absolue. Plusieurs cas échappent à ces trois couches de validation.

Les hallucinations à haute confiance restent le point faible principal. Quand un modèle produit une réponse fausse avec des logprobs élevés, sur un sujet bien couvert par la base documentaire, les trois couches la laisseront passer. Ce cas est statistiquement rare, mais il existe. Pour les domaines à haut risque (médical, juridique, financier), une validation humaine sur les réponses critiques reste indispensable.

Le calibrage des seuils demande un investissement initial. Des seuils trop permissifs laissent passer des hallucinations. Des seuils trop stricts rejettent des réponses correctes et frustrent les utilisateurs. Il faut prévoir une phase de test avec des jeux de questions-réponses annotées, et ajuster les seuils en fonction des résultats observés.

Enfin, cette architecture suppose un accès aux logprobs du modèle, ce qui n'est pas garanti avec tous les fournisseurs ni tous les modèles. Si vous utilisez un LLM en mode boîte noire sans accès aux métriques internes, la troisième couche est inaccessible. Vous opérez alors avec deux couches sur trois, ce qui réduit la couverture de détection.

Pour les entreprises qui dépendent d'un seul fournisseur d'IA sans diversifier leurs outils d'évaluation, le risque de pensée unique technologique s'ajoute au risque d'hallucination.

Conclusion

Le vrai danger des hallucinations n'est pas leur existence, c'est leur invisibilité. Trois couches de validation mathématique (domaine, contexte, confiance) transforment un LLM opaque en système auditable, où chaque réponse porte une mesure objective de fiabilité. Ce n'est pas un luxe technique réservé aux grandes entreprises : c'est le minimum pour toute PME qui expose une IA à ses clients ou à ses équipes.

Votre IA interne produit-elle des réponses que personne ne vérifie ?

Sources : Suprmind - Statistiques d'hallucinations IA : rapport de recherche DataSolution - Hallucinations LLM HubSpot - Hallucination IA (glossaire AEO) MulerTech - Quand l'IA invente plutôt que de demander