Votre RAG n'hallucine pas, il récupère mal
On accuse le modèle d'halluciner, mais avez-vous regardé ce qu'on lui donne à lire ? L'essentiel des erreurs en RAG naît d'une récupération défaillante.
Le procès systématique fait au générateur
Lorsqu'un pipeline RAG produit une information factuellement fausse, le premier réflexe des équipes d'ingénierie est d'incriminer le grand modèle de langage. Le client voit le générateur formuler la réponse, c'est donc lui qui porte la responsabilité de l'erreur. La réaction immédiate consiste à alourdir le prompt système avec des injonctions négatives, à changer de modèle pour une version plus coûteuse, ou à baisser la température en espérant brider l'imagination de l'algorithme.
C'est un diagnostic erroné. Le générateur n'est que la dernière brique de rendu d'une chaîne complexe. Si la base factuelle nécessaire pour répondre à la requête est absente du contexte fourni, le modèle n'a que deux options : avouer son ignorance si ses instructions le contraignent parfaitement, ou extrapoler à partir de sa mémoire paramétrique. Dans les deux cas, le pipeline échoue.
Cesser d'accuser la dernière brique d'une chaîne de génération permet de concentrer le budget d'ingénierie là où la perte d'information se produit réellement : la recherche.
Ouvrir le contexte : qu'a-t-il vraiment reçu ?
Avant de réécrire une seule ligne d'instruction, il faut intercepter la charge utile envoyée au modèle. L'audit d'un pipeline commence par la journalisation systématique des passages effectivement récupérés par la base vectorielle pour une requête donnée. L'objectif est de définir une évaluation stricte basée sur la donnée entrante.
Dans la majorité des cas fautifs que nous auditons, le bon passage n'était tout simplement pas présent dans la fenêtre de contexte. Le modèle n'a pas menti par défaut de raisonnement, on l'a mal nourri. Il a synthétisé avec fluidité un ensemble de documents non pertinents. Transformer ce débat d'opinion sur la qualité intrinsèque du LLM en une mesure stricte de la précision de récupération change radicalement la nature du correctif à apporter.
Journaliser les passages injectés fige la réalité technique des requêtes et fournit une base de travail irréfutable pour déboguer le pipeline.
Les trois fautes de récupération
L'échec de la récupération s'explique rarement par un seul facteur, mais par la combinaison de trois failles architecturales classiques. La première est un découpage (chunking) naïf. Un découpage basé uniquement sur un nombre fixe de tokens coupe régulièrement les phrases au milieu d'une idée, séparant une affirmation de la justification qui lui donne son sens.
La deuxième faille est l'absence d'une couche de reranking. S'en remettre exclusivement à la similarité cosinus d'un modèle d'embedding dense (bi-encoder) remonte souvent des documents thématiquement proches mais factuellement inutiles. La troisième faute réside dans l'absence d'expansion sémantique de la requête : une question ambiguë ou trop courte tapée par l'utilisateur est cherchée telle quelle, ignorant le vocabulaire spécifique employé dans le corpus documentaire.
Isoler et corriger ces trois variables permet de restructurer radicalement la pertinence de l'indexation sans avoir à modifier l'architecture globale du pipeline.
Mesurer le grounding au niveau du passage
Une fois la mécanique de récupération stabilisée, l'évaluation doit se déplacer sur l'ancrage factuel (grounding). La question n'est plus seulement de savoir si le bon document a été remonté, mais si la réponse générée s'appuie effectivement sur le passage censé la fonder. C'est ici que s'applique notre distinction entre cité et corroboré.
Une URL ajoutée en bas de réponse n'est qu'un artifice d'interface si le texte généré contient des entités ou des métriques absentes du chunk fourni. L'inspection doit se faire au niveau du passage : on confronte chaque proposition de la sortie avec le texte brut du contexte injecté. Si une information sortante n'a pas d'origine entrante claire, le grounding a échoué, même si la réponse finale semble plausible.
On n'évalue pas la fiabilité d'un RAG à la fluidité de sa réponse, mais à la traçabilité mathématique de ses affirmations dans les chunks fournis.
Évaluer le grounding passage par passage garantit que chaque affirmation générée dispose d'une traçabilité documentaire exacte, protégeant l'entreprise contre les risques de désinformation.
Réparer la recherche avant d'accuser le modèle
L'ordre d'intervention sur un RAG défaillant est strict et non négociable. On intervient d'abord sur la stratégie de retrieval (chunking sémantique, métadonnées). On ajoute ensuite un modèle de reranking (cross-encoder) pour trier les résultats avec précision et s'assurer que les informations vitales occupent les premières positions de la fenêtre de contexte.
Ce n'est qu'une fois la qualité de cette chaîne de recherche prouvée par des métriques de rappel (Recall@K) que l'on s'autorise à modifier le prompt ou à changer de LLM. Inverser cet ordre conduit inévitablement à masquer les problèmes de recherche sous des instructions complexes, créant une dérive silencieuse des instructions qui finira par casser lors de la prochaine mise à jour du modèle.
Respecter cet ordre d'intervention fige l'infrastructure de recherche logicielle et prévient les régressions coûteuses lors du remplacement inévitable du modèle de langage sous-jacent.