RAG : éviter les hallucinations LLM sur vos données métier

Le RAG (Retrieval-Augmented Generation) est devenu le standard pour faire répondre une IA sur vos données : vos procédures, vos contrats, votre documentation produit, vos FAQs. Le principe tient en une phrase : on cherche dans vos documents, on passe les passages pertinents au LLM en contexte, et le modèle répond en s’appuyant dessus.

C’est la bonne architecture. Mais elle ne supprime pas les hallucinations — elle les déplace, et les rend plus insidieuses. Une réponse hallucinée sur vos données a l’apparence d’une réponse de votre IA : votre ton, votre vocabulaire, parfois une référence à un passage qui n’existe pas.

Le résultat d’une seule erreur qui circule — un paramètre appliqué à tort, une clause inventée, une procédure inexistante — suffit à faire douter tout le monde de la fonctionnalité.

Dans cet article : d’où viennent exactement les hallucinations d’un RAG, comment les mesurer avant de passer en production, et les leviers concrets pour les limiter. Si vous voulez d’abord un tour d’horizon des causes et des conséquences des hallucinations des LLM en général, lisez notre article sur les hallucinations LLM.

Le RAG en 30 secondes

Deux étapes, deux composants :

1. La recherche (retrieval) : la question de l’utilisateur est transformée en recherche dans votre index — vos documents, découpés en passages, représentés en vecteurs sémantiques. Les passages les plus proches sont sélectionnés.
2. La génération : le LLM reçoit la question et les passages récupérés, et produit une réponse.

Le point essentiel : le LLM ne « consulte » pas votre base. Il lit un extrait que quelqu’un a choisi pour lui. Tout ce qui n’est pas dans cet extrait, il ne le sait pas. C’est là que tout se joue.

Deux points de défaillance, deux parades différentes

L’erreur classique est de traiter « hallucination » comme une cause unique. En pratique, il y en a deux, et elles exigent des réponses différentes.

1. La recherche a échoué : la réponse n’est pas dans le contexte

Le passage pertinent n’a pas été récupéré : question ambiguë, mauvais passage choisi, document jamais ingéré. Ou plus simplement : la réponse n’existe pas dans vos données — question sur une décision récente non documentée, par exemple.

Le LLM n’a pas de « je ne sais pas » par défaut. Son objectif est de générer la suite la plus plausible, et il complète. C’est précisément le cas le plus dangereux : la réponse fabriquée est rédigée dans le style de vos documents, donc elle a l’air d’être la vôtre.

2. La recherche a réussi : mais la génération déforme

L’information est bien dans le contexte. Le modèle la paraphrase, confond deux passages, ou invente un détail : un numéro d’article, une date, un seuil, un nom. Sur les textes denses — juridique, finance, RH — c’est fréquent.

Pourquoi ? La fonction objective d’un LLM n’est pas la fidélité, c’est la plausibilité du prochain token. La fidélité à votre contexte n’est pas un objectif du modèle : c’est quelque chose qu’on lui impose, et qu’il faut vérifier.

Le réflexe à adopter

Face à une hallucination observée en production, la première question n’est pas « changer de modèle » ou « améliorer le prompt ». C’est : la bonne information était-elle dans le contexte ?

• Si non, c’est un problème de recherche.
• Si oui, c’est un problème de génération.

Mélanger les deux est la cause n°1 des RAG qui stagnent : on change de LLM pendant que c’est la recherche qui est cassée, ou l’inverse.

Comment mesurer les hallucinations avant le go-live

Sans mesure, vous découvrez les hallucinations par vos utilisateurs. Et à ce moment, c’est trop tard pour quantifier le problème, comparer les solutions, ou vous engager sur des garanties contractuelles.

1. Un jeu d’évaluation d’abord

Construisez 50 à 200 questions métier réelles, avec la réponse attendue connue. Sources : vos vraies FAQs, vos tickets de support récurrents, vos procédures.

Et le point que tout le monde oublie : incluez des questions dont la réponse n’est pas dans vos données. Ce sont elles qui testent le refus. Un RAG testé uniquement sur des questions qu’il sait répondre ne vous apprend rien sur son comportement réel.

2. Les métriques à suivre

Quatre métriques suffisent pour démarrer — ce sont celles du standard RAGAS :

• Pertinence du contexte : la recherche a-t-elle ramené le bon passage ? Elle mesure la recherche.
• Fidélité (faithfulness) : chaque affirmation de la réponse est-elle soutenue par le contexte récupéré ? Elle mesure la génération.
• Pertinence de la réponse : la réponse répond-elle à la question posée ?
• Taux de refus : sur les questions sans réponse dans les données, l’IA a-t-elle refusé ou inventé ? C’est la métrique la plus importante.

3. Comment les calculer

• LLM-as-judge : un LLM — souvent un modèle plus fort — évalue chaque réponse contre le contexte, de façon automatique et reproductible. C’est ce qui rend le jeu d’évaluation scalable.
• Échantillon humain : relisez manuellement 10 à 20 % des cas, en priorité les refus et les cas limites. C’est votre ground truth.
• À chaque changement : refaites le jeu quand vous changez le chunking, l’index, le modèle ou le prompt. Le comparatif avant/après est ce qui rend le travail mesurable.

4. En production

• Le taux de réponses sans source citée : s’il est non nul, votre pipeline est cassé par définition.
• Le feedback utilisateur « réponse erronée ».
• Des audits mensuels sur un échantillon de vraies conversations.

La métrique qui compte au final n’est pas un pourcentage : c’est zéro erreur critique — une erreur qui conduit à une mauvaise action (un paiement, un contrat, une décision RH). Ce n’est pas un objectif de mesure, c’est un objectif de conception.

Les quatre leviers pour limiter les hallucinations

1. La recherche d’abord — c’est la majorité du problème

• Recherche hybride : le sémantique seul échoue sur les questions à mots-clés (numéros de procédure, références de clause). Il faut le lexical et le sémantique, ensemble.
• Chunking qui respecte la structure : une clause ne doit pas être coupée en deux, une table doit rester entière. On découpe selon la structure du document, pas selon la taille.
• Métadonnées métier : type de document, version, date d’effet, périmètre. La recherche peut alors filtrer.
• Reranking : la recherche initiale est bruyante. Un rerank sélectionne les 3 à 5 passages qui comptent.

2. Contraindre la génération

Ici, le prompt est un contrat, pas une suggestion :

• « Réponds uniquement à partir du contexte fourni. »
• « Si la réponse n’est pas dans le contexte, dis-le. N’invente pas. »
• Cite les passages utilisés.

Et le point de vue qui change tout : refuser est une fonctionnalité. Une IA qui dit « je n’ai pas cette information dans nos documents, voici où regarder » est une IA qu’on peut utiliser. Une IA qui répond toujours est une IA qu’on doit relire — donc une IA inutile.

3. Citer les sources — la vérifiabilité

Chaque réponse doit pointer vers le passage exact qui la soutient. Ce n’est pas un détail d’ergonomie :

• L’utilisateur vérifie en cinq secondes. La confiance se construit sur le vérifiable, pas sur la garantie.
• Votre support identifie l’origine d’une réponse en une minute, au lieu de la relire à la loupe.
• Une réponse sans source n’est pas une réponse : c’est le modèle qui parle.

C’est l’architecture même de notre fonction Chercher : chaque réponse est sourcée, et la chaîne valide la fidélité avant de la renvoyer.

4. Contrôler le périmètre critique

• Sur les actions sensibles (RH, contrat, paiement) : validation humaine avant l’action. Le modèle n’agit jamais seul.
• Traçabilité complète : question, contexte récupéré, réponse, modèle et version. Auditable, reproductible.
• Surveillance : une baisse de fidélité est presque toujours un problème de documents — mal mis à jour, mal ingérés — et non d’IA. Le signal d’alerte doit vous dire « vérifiez vos données ».

Et un chatbot sans vos données, c’est quoi ?

Un LLM sans RAG ne connaît ni vos règles, ni vos versions, ni votre historique. Sur vos questions, il répond avec la moyenne de ce qu’il a vu pendant son entraînement. Et cette moyenne, pour vous, est fausse par construction.

Le RAG change le profil d’erreur : on passe d’une réponse plausible et générique à une réponse sourcée et vérifiable. C’est la différence entre une fonctionnalité IA à montrer en démo, et une fonctionnalité qu’on peut mettre dans un contrat.

Ce qu’il faut retenir

• Deux causes distinctes : la recherche n’apporte pas la bonne information, ou la génération déforme l’information apportée. Identifier laquelle avant de toucher à quoi que ce soit.
• Mesurer avant le go-live : jeu d’évaluation avec questions sans réponse, fidélité, taux de refus. Refaire à chaque changement.
• Limiter par la recherche d’abord : hybride, chunking structurel, métadonnées, reranking.
• Refuser est une fonctionnalité, citer les sources est une architecture, et le périmètre critique reste validé par un humain.