Pourquoi votre RAG répond mal, et comment le corriger

Le RAG est en production, les documents sont indexés, et pourtant les utilisateurs ne s'en servent plus. Les réponses arrivent tronquées, les sources citées n'ont aucun rapport avec la question, un chiffre faux passe de temps en temps. Le réflexe consiste à incriminer le modèle de langage. Dans la quasi-totalité des cas rencontrés, le modèle n'y est pour rien. La panne se situe en amont, dans la chaîne de recherche. Cet article décrit les symptômes, remonte aux cinq causes réelles et donne la méthode pour mesurer les corrections. Il prolonge notre guide du RAG en entreprise sur le volet qualité.

Les symptômes, et ce qu'ils révèlent vraiment

Un RAG ne tombe pas en panne, il se dégrade. Les utilisateurs abandonnent bien avant qu'une alerte technique ne se déclenche, parce qu'aucune erreur n'est levée : le système répond toujours, simplement de moins en moins bien. Voici la grille de lecture que nous appliquons en audit.

Le point commun de ces situations mérite d'être souligné. Aucune ne se corrige en changeant de modèle de langage, ni en rédigeant un meilleur prompt. Toutes se corrigent dans la chaîne qui alimente le modèle.

Cause 1, le découpage des documents

Avant d'être indexé, chaque document est fragmenté en passages. La méthode par défaut découpe tous les mille caractères, sans regarder ce qu'elle coupe. Sur une procédure de dix étapes, la coupure tombe entre l'étape six et l'étape sept. Le système remonte le fragment contenant les six premières étapes, le modèle rédige une réponse cohérente, complète en apparence, et amputée de quatre étapes. Personne ne s'en aperçoit tant que l'utilisateur ne connaît pas déjà la réponse.

Le correctif consiste à faire dépendre le découpage de la structure du document plutôt que d'un compteur de caractères. Une section reste entière, un article réglementaire ne se scinde pas, un tableau n'est jamais coupé en travers. Deux réglages complémentaires aident beaucoup : un recouvrement entre fragments consécutifs, de sorte qu'une information à cheval apparaisse dans les deux, et l'ajout en tête de chaque fragment du titre de la section dont il provient, pour que le passage reste interprétable isolément.

Cause 2, le modèle de vectorisation

La recherche repose sur des embeddings, ces représentations numériques qui rapprochent les textes de sens voisin. Beaucoup d'installations utilisent un modèle entraîné majoritairement sur de l'anglais généraliste. Sur un corpus français rempli de terminologie métier, de sigles internes et de références réglementaires, ce modèle place côte à côte des passages qui n'ont rien à voir et sépare des passages équivalents.

Le test est simple à mener. Prenez une question métier dont vous connaissez la réponse, puis observez les passages remontés, sans regarder la réponse finale. Si le bon document n'apparaît pas dans les cinq premiers, le problème est là, et aucune amélioration du prompt n'y changera quoi que ce soit.

Deux leviers existent. Choisir un modèle d'embedding entraîné sur le français, ce qui règle la majorité des cas. Et adopter une recherche hybride, combinant la similarité vectorielle avec une recherche lexicale classique, particulièrement efficace quand le vocabulaire comporte des références exactes, des codes produit ou des numéros d'article que la sémantique seule capte mal.

« Un RAG qui répond mal est presque toujours un RAG qui cherche mal. Le modèle ne fait que rédiger ce qu'on lui donne. »

Cause 3, l'absence de reclassement

La recherche vectorielle a une propriété que l'on oublie facilement. Elle rapporte toujours quelque chose. Quand la question ne trouve aucune réponse dans le corpus, elle remonte malgré tout les passages les moins éloignés, et ces passages arrivent au modèle avec la même apparence de légitimité que de vraies sources. Le modèle fait alors ce pour quoi il est conçu, il rédige une réponse plausible à partir du matériau fourni.

Deux mécanismes coupent court à ce comportement. Un modèle de reclassement, qui réexamine les vingt premiers passages et les réordonne selon leur pertinence réelle vis-à-vis de la question, gain généralement spectaculaire pour un coût modeste. Et un seuil de pertinence, en dessous duquel le système annonce qu'il ne dispose pas de l'information plutôt que de produire une réponse. Cette capacité à dire non vaut mieux qu'une réponse sur deux qui serait juste, surtout dans un environnement où la décision engage la responsabilité, comme nous le détaillons pour les environnements réglementés.

Cause 4, le corpus qui vieillit

Au démarrage, le corpus a été nettoyé avec soin. Dix-huit mois plus tard, la version 3 d'une procédure coexiste avec les versions 1 et 2, le brouillon d'un document validé traîne encore dans l'index, et rien ne distingue l'un de l'autre aux yeux du système. Le RAG remonte l'ancienne version parce qu'elle formule mieux la question posée.

Le traitement est organisationnel autant que technique. Il faut un cycle de ré-indexation déclenché par les mises à jour documentaires, une date de validité portée par chaque document et exploitée au moment de la recherche, une suppression effective des versions périmées de l'index et non seulement de la source, ainsi qu'un propriétaire identifié pour chaque corpus. Sans responsable désigné, la base se dégrade toujours. Ce poste de maintenance relève du coût récurrent que nous chiffrons dans notre article sur le coût d'un projet RAG.

Cause 5, les métadonnées et les droits

Dernière cause, la plus lourde de conséquences. Quand la recherche s'effectue sur la totalité de l'index sans filtre préalable, deux problèmes surgissent en même temps. Le bruit, d'abord, car une question portant sur un produit précis rapporte des passages relatifs à tout le catalogue. L'exposition, ensuite, quand un utilisateur reçoit un extrait d'un document auquel il n'a pas accès.

Le principe à retenir tient en une phrase. Le filtrage par droits s'applique avant la recherche, jamais après. Un système qui cherche partout puis masque les résultats interdits a déjà laissé fuiter l'information dans le contexte transmis au modèle. Les métadonnées utiles sont peu nombreuses mais indispensables : service émetteur, niveau de confidentialité, type de document, version et date de validité, périmètre produit ou entité. Ce sujet est structurant en environnement sensible, et il pèse directement sur l'architecture retenue, ce que nous développons dans notre guide du RAG souverain et on-premise.

Le cas particulier des documents structurés

Trois formats font échouer un pipeline standard, et ils sont omniprésents dans les corpus d'entreprise.

• Les tableaux. Un découpage naïf sépare les valeurs de leurs en-têtes. Le modèle reçoit une colonne de nombres orphelins et les rattache au premier intitulé venu. C'est la source principale des chiffres faux. Chaque fragment issu d'un tableau doit porter ses en-têtes.
• Les documents scannés. Sans reconnaissance de caractères, ils sont indexés comme des pages vides. Le système ne les ignore pas, il ne les voit pas. Vérifiez systématiquement que le texte a bien été extrait, page par page, sur un échantillon.
• Les annexes et les renvois. Une procédure qui renvoie à son annexe 4 perd tout son sens si l'annexe est indexée séparément, sans lien vers le document principal. La relation doit être portée par les métadonnées.

Mesurer avant de corriger

Voici l'erreur de méthode la plus répandue. On modifie le découpage, on trouve que les réponses semblent meilleures, on passe à autre chose. Trois semaines plus tard, un utilisateur signale une régression sur un cas qui fonctionnait auparavant. Sans mesure, l'optimisation d'un RAG se réduit à une succession d'impressions.

Construisez donc un jeu de questions de référence avant toute modification. Entre trente et cent questions métier réelles, collectées auprès des utilisateurs et non inventées en réunion. Pour chacune, notez la réponse attendue et le document qui la contient. Deux indicateurs suffisent ensuite à piloter.

• La qualité de la recherche. Sur l'ensemble des questions, dans quelle proportion le bon document figure-t-il parmi les cinq premiers passages remontés ? Cet indicateur isole la chaîne de recherche du reste.
• La fidélité de la réponse. Chaque affirmation produite est-elle bien soutenue par un passage cité ? Un écart signale une réponse partiellement inventée, même quand la recherche a fonctionné.

Ce jeu de référence se rejoue à chaque modification. Il transforme l'optimisation en démarche mesurable et rend visibles les régressions, qui autrement ne se découvrent qu'en production.

Par où commencer

L'ordre compte, parce que chaque étape conditionne la mesure de la suivante.

Les deux premières lignes ne coûtent presque rien et évitent de corriger au hasard. Les troisième et quatrième apportent l'essentiel du gain observable. Les deux dernières relèvent du travail de fond, et ce sont elles qui déterminent si le système tiendra dans deux ans.

Questions fréquentes

Pourquoi mon RAG donne-t-il des réponses incomplètes ?
Le découpage est presque toujours en cause. Si l'information utile est répartie sur plusieurs fragments et qu'un seul remonte, la réponse est partielle par construction. Découpez selon la structure du document plutôt que selon un nombre fixe de caractères.

Pourquoi mon RAG cite-t-il des documents hors sujet ?
La recherche vectorielle rapporte toujours les passages les moins éloignés, même quand aucun n'est pertinent. Un modèle de reclassement et un seuil en dessous duquel le système déclare ne pas savoir corrigent la plupart de ces cas.

Pourquoi mon RAG invente-t-il des chiffres ?
Les chiffres vivent dans des tableaux, et un découpage naïf sépare les valeurs de leurs en-têtes. Le modèle reçoit des nombres sans libellé et les rattache au mauvais intitulé. Les tableaux exigent un traitement spécifique.

Comment savoir si mon RAG s'améliore ?
En construisant un jeu de trente à cent questions métier réelles avant toute modification, avec pour chacune la réponse attendue et son document source. Sans cette base, les régressions restent invisibles.

Le modèle est rarement le coupable

Un RAG qui déçoit envoie un signal, et ce signal porte sur la chaîne documentaire bien plus que sur l'intelligence artificielle. Découpage, vectorisation, reclassement, fraîcheur du corpus, métadonnées : cinq maillons, dont un seul défaillant suffit à dégrader l'ensemble. La bonne nouvelle tient dans le caractère mesurable de chacun. Pour le cadre général, revenez au guide du RAG en entreprise. Pour les exigences de traçabilité qui s'ajoutent en environnement contraint, consultez le RAG en secteur réglementé.