RAG expliqué aux dirigeants : pourquoi votre IA invente des réponses, et comment l'en empêcher

Vous avez déployé un assistant qui répond à partir de vos documents. Il fonctionne souvent très bien — et parfois, il invente. Il cite un chiffre qui n'existe pas, attribue une clause à un contrat qui n'en contient pas, invente un tarif. Ce phénomène porte un nom (l'hallucination), une cause principale (une récupération d'information défaillante) et des remèdes mesurables. Ce texte explique, sans jargon inutile et avec des sources, pourquoi cela arrive et comment y remédier.

C'est un sujet de direction autant que de technique. Un assistant interne qui se trompe une fois par semaine n'est pas un gadget : il érode la confiance des équipes, crée des coûts de vérification cachés, et finit désactivé. La bonne approche n'est pas de promettre un outil parfait — aucun ne l'est — mais de comprendre *où* le système flanche, de le mesurer, et de le corriger au bon endroit.

Le RAG en une image

Le RAG (*Retrieval-Augmented Generation*) combine deux étages. D'abord un moteur de récupération : il cherche, dans vos documents indexés, les passages les plus pertinents pour la question posée. Ensuite un modèle de génération : il rédige une réponse en s'appuyant sur ces passages. L'idée est simple : au lieu de demander au modèle de « savoir », on lui donne les bonnes pages sous les yeux, puis on lui demande de synthétiser.

La conséquence est importante pour un dirigeant : la qualité de la réponse dépend d'abord de la qualité de la récupération. Si les bons passages ne sont pas remontés, aucun modèle du monde ne peut produire une réponse juste à partir de rien. La plupart des hallucinations « sur vos documents » sont, en réalité, des échecs de récupération.

Cette architecture a un mérite économique : elle vous évite de réentraîner un modèle sur vos données privées. On peut mettre à jour la base documentaire le matin et interroger le système l'après-midi. Pour une PME, c'est un avantage décisif : la donnée reste chez vous, et la connaissance métier se maintient sans compétence rare en apprentissage automatique.

D'où viennent les hallucinations

Deux causes se cumulent. La première est le manque de contexte : le modèle génère pour « remplir le vide » quand l'information pertinente n'a pas été récupérée. La seconde est la nature même du modèle génératif : il produit la suite la plus probable, ce qui n'est pas la même chose que la plus vraie. Le RAG attaque surtout la première cause — c'est pourquoi améliorer la récupération est le levier le plus rentable.

Où ça casse : la récupération

Anthropic a publié une méthode de récupération contextuelle (2024) dont les résultats sont instructifs. En préfixant chaque bloc de texte par un court résumé de son contexte avant indexation, le taux d'échec de récupération chute de 35 % (de 5,7 % à 3,7 %). En combinant cette méthode avec des embeddings contextuels, il chute de 49 % (jusqu'à 2,9 %). En y ajoutant un réordonnancement (*reranking*) des résultats, l'échec tombe à 1,9 %, soit une réduction de 67 % au total.

La leçon est nette : ces gains viennent d'ingénierie de données, pas d'un modèle plus gros. Trois leviers simples — contextualisation des blocs, meilleurs embeddings, reranking — transforment la fiabilité du système pour un coût marginal.

Il faut souligner la progressivité de ces gains : chaque brique se cumule aux précédentes, et la dernière (le reranking) apporte le plus fort taux de réduction relatif. Un projet RAG bien mené avance par incréments mesurables, ce qui permet d'arbitrer sereinement l'effort à engager.

Le découpage : un détail qui décide de tout

Comment découper vos documents en blocs indexables (*chunking*) ? Une étude NVIDIA comparant sept stratégies sur cinq jeux de données a mesuré la précision en réponse : le découpage au niveau de la page atteint une précision de 0,648. Ce n'est pas nécessairement la stratégie optimale dans tous les cas, mais le message est clair : la granularité du découpage est un paramètre de premier ordre, et les découpages « à la volée » par nombre de caractères sont rarement les meilleurs pour des documents structurés.

Faut-il affiner le modèle ou enrichir les données ?

La tentation, quand un assistant se trompe, est de vouloir « réentraîner le modèle sur nos documents ». C'est presque toujours la mauvaise première réponse : c'est coûteux, difficile à maintenir à jour, et cela n'attaque pas la cause la plus fréquente — un mauvais rappel des bons passages. La démarche rentable consiste d'abord à auditer la récupération : les bons documents sont-ils indexés ? le découpage est-il adapté ? le reranking est-il activé ? Ce n'est qu'après avoir épuisé ces leviers que l'on envisage un ajustement plus lourd.

Documents complexes : le vrai test

Beaucoup de contenus d'entreprise ne sont pas du texte propre : ce sont des PDF à colonnes, des tableaux, des formulaires à cases, des scans. OmniDocBench (arXiv:2412.07626, CVPR 2025) évalue la compréhension de documents sur 981 échantillons couvrant 9 types de documents — un rappel utile que la « lecture de documents » est un problème à part entière, distinct de la génération de texte. Un pipeline RAG qui ignore cette étape hérite de toutes les erreurs de lecture en amont.

Mesurer la qualité : RAGAS

Un système qu'on ne mesure pas ne s'améliore pas. Le cadre RAGAS (arXiv:2309.15217, 2023) propose des métriques précises et actionnables :

• faithfulness (fidélité) : la réponse s'appuie-t-elle réellement sur le contexte fourni ?
• answer relevancy (pertinence de la réponse) : répond-elle à la question posée ?
• context precision (précision du contexte) : les passages remontés sont-ils pertinents ?
• context recall (rappel du contexte) : l'information nécessaire a-t-elle été récupérée ?

Ces quatre métriques séparent deux problèmes que l'on confond souvent : un problème de récupération (précision/rappel du contexte) et un problème de génération (fidélité). Sans cette distinction, on optimise le mauvais étage.

Détecter l'hallucination : attention aux outils « populaires »

Une idée répandue est qu'il suffit de brancher un « détecteur d'hallucination » en sortie. Le FaithBench de Vectara (HHEM, arXiv:2505.04847, 2025) montre pourquoi c'est insuffisant : un détecteur populaire n'atteint que 52,6 % sur les cas difficiles, là où l'approche de référence FaithJudge atteint 84 %. Autrement dit, sur les cas justement problématiques, l'outil le plus répandu se trompe environ une fois sur deux. Ne confiez pas votre garantie de fiabilité à un composant dont la performance s'effondre là où elle compte.

Le volet sécurité des données

Le classement OWASP GenAI Top 10 for LLM Applications 2025 pointe un risque spécifique au RAG : LLM08 — Vector and Embedding Weaknesses. Les bases vectorielles et les embeddings introduisent des vulnérabilités propres : empoisonnement de l'index, fuite d'information par similarité, cloisonnement insuffisant entre sources. Pour une PME, cela signifie qu'indexer des documents sensibles sans contrôle d'accès fin revient à créer une nouvelle surface de fuite.

Conclusion : vos cinq décisions

Pour un dirigeant, le RAG n'est pas un choix « oui ou non », c'est une série de décisions mesurables :

1. Investir dans les données avant le modèle. Contextualisation, embeddings, reranking : le meilleur retour sur effort.
2. Soigner le découpage. Il conditionne la pertinence davantage qu'on ne le croit.
3. Traiter la lecture des documents complexes à part. Tableaux, scans et formulaires méritent un pipeline dédié.
4. Mesurer avec RAGAS dès le premier jour. Fidélité, pertinence, précision et rappel du contexte.
5. Refuser les réponses non fondées. Fournir les citations sources dans l'interface, et définir un comportement « je ne sais pas » lorsque le contexte manque.

Un RAG honnête ne promet pas zéro erreur. Il promet une chose plus utile : savoir *pourquoi* il se trompe, et corriger l'endroit exact où ça casse.

En pratique, cela signifie aussi accepter un réflexe culturel : valoriser les réponses « je ne trouve pas cette information dans vos documents » plutôt que de récompenser une réponse fluide mais fausse. Un assistant qui admet ses limites est paradoxalement plus utilisé — parce qu'on finit par lui faire confiance pour ce qu'il affirme.