Mon RAG répond à côté : le diagnostic dans l'ordre

Un RAG qui répond à côté en production a presque toujours une cause identifiable, et cette cause suit un ordre de probabilité assez stable : le corpus d'abord, le découpage ensuite, puis la recherche, puis la génération. Inutile de réécrire le pipeline en entier ni de changer de modèle avant d'avoir vérifié les causes les plus fréquentes et les moins chères à tester.

Ce guide n'explique pas comment concevoir un RAG. Il part d'un système déjà déployé qui dysfonctionne : réponses hors sujet, citations fausses, documents pertinents jamais remontés. L'objectif est de vous donner une séquence de vérification exécutable, du symptôme au test, du test à la correction.

Le marché est d'ailleurs passé, en 2026, du discours "faire un RAG" au discours "opérer un RAG". Gartner anticipait que plus de 40 % des projets d'IA agentique seraient abandonnés d'ici 2027, et la première cause n'est pas la technologie : c'est l'absence de méthode pour diagnostiquer ce qui casse une fois en production.

L'ordre de diagnostic, en un coup d'œil

Un RAG qui répond à côté n'a presque jamais une cause unique et exotique. Il a une cause banale, souvent au tout début du pipeline, que personne n'a vérifiée parce que l'attention est allée directement au prompt ou au modèle de langage. Suivre un ordre évite de passer des jours à optimiser un reranker alors que le document n'a jamais été indexé correctement.

Le principe qui structure cette séquence est simple : on vérifie d'abord ce qui est gratuit à tester et statistiquement le plus probable, avant de passer à ce qui demande du développement. Le tableau ci-dessus résume l'ordre ; les sept sections suivantes détaillent, pour chaque cause, le symptôme observable, le test qui la confirme, la correction et son coût relatif.

Étape 1 : le corpus, la cause la plus fréquente et la moins chère à vérifier

Quand un RAG en production répond à côté, la première cause à écarter est le corpus lui-même : documents obsolètes jamais retirés, versions contradictoires d'un même contenu, ou zones entières du périmètre jamais indexées. Ce test ne demande aucun développement, seulement d'ouvrir les documents.

Le symptôme. L'utilisateur pose une question dont la réponse existe manifestement quelque part dans l'entreprise, mais le système ne la trouve pas, ou pire, remonte une version périmée d'une procédure qui a changé depuis.

Le test. Prenez cinq questions qui ont échoué. Pour chacune, cherchez manuellement, avec un simple ctrl+F si nécessaire, si la bonne réponse existe dans le corpus indexé, si elle existe à jour, et si elle existe en un seul exemplaire ou en plusieurs versions concurrentes.

La correction. Retirer ou archiver les documents obsolètes, fusionner les doublons, et surtout mettre en place une procédure de mise à jour : qui ajoute un document, qui en retire un, à quelle fréquence le corpus est audité. Sans ce processus, le problème revient trois mois plus tard.

Coût relatif. Faible. C'est un travail de tri documentaire, pas de développement. C'est aussi la cause la plus fréquente que nous observons en audit, largement avant les causes techniques listées plus bas.

Étape 2 : le chunking, quand le bon paragraphe existe mais arrive coupé en deux

Si le corpus contient bien la réponse mais que le système ne la retrouve pas, ou la retrouve incomplète, le découpage des documents (chunking) devient le suspect naturel. Un chunk qui tranche une phrase en plein milieu ou sépare une question de sa réponse produit un vecteur incomplet, donc une recherche qui échoue.

Le symptôme. La réponse générée est partielle, contredit un chiffre qui apparaît juste après dans le document source, ou cite un passage qui semble tronqué en plein milieu d'une idée.

Le test. Ouvrez directement les chunks stockés dans votre base vectorielle pour le document concerné, pas le document original. Vérifiez si le chunk censé contenir la réponse la contient réellement en entier, ou si elle est répartie sur deux chunks qui ne se retrouvent jamais ensemble dans les résultats.

La correction. Passer d'un découpage à taille fixe à un découpage qui respecte les frontières de sens (paragraphe, section, tableau entier), et pour les documents à forte densité d'information, tester un Parent Document Retriever : on indexe un petit chunk précis pour la recherche, mais on renvoie au modèle le chunk parent, plus large, qui contient tout le contexte.

Coût relatif. Faible à moyen. Retravailler la stratégie de découpage se fait généralement en quelques jours de développement, sans changer l'architecture générale du système. Nous détaillons cette étape dans notre guide sur l'optimisation d'un système RAG, avec le semantic chunking et ses variantes.

Étape 3 : l'absence de métadonnées et de filtrage documentaire

Un RAG sans métadonnées ne sait pas distinguer un document actif d'un document archivé, ni une filiale d'une autre, ni une version française d'une version anglaise. Il traite tout le corpus comme un seul sac de texte, et la recherche vectorielle remonte alors des passages qui n'ont pas leur place dans le contexte de la question posée.

Le symptôme. Le système mélange des informations qui appartiennent à des périmètres différents : une clause contractuelle d'un client s'applique à un autre, une procédure d'une filiale se retrouve appliquée à une autre entité, ou une version brouillon d'un document est citée comme si elle faisait foi.

Le test. Vérifiez si chaque chunk indexé porte des métadonnées exploitables : date de publication, statut (actif ou archivé), périmètre (entité, filiale, produit), langue. Si ces champs n'existent pas ou ne sont jamais utilisés au moment de la recherche, c'est la cause.

La correction. Enrichir l'indexation avec des métadonnées structurées, puis ajouter un filtrage pré-recherche qui restreint le périmètre avant même de lancer la recherche vectorielle, plutôt que de compter sur la similarité sémantique pour deviner le bon contexte. C'est aussi souvent le moment où le choix de la base vectorielle compte : toutes ne supportent pas le filtrage par métadonnées de la même manière, un point détaillé dans notre comparatif des bases de données vectorielles pour le RAG.

Coût relatif. Moyen. Cela suppose de retravailler le pipeline d'indexation et, parfois, de ré-indexer tout le corpus avec les champs manquants.

Étape 4 : la recherche purement vectorielle, sans recherche lexicale

Un RAG qui ne fait que de la recherche vectorielle rate systématiquement les correspondances exactes : références produit, codes d'erreur, noms propres, acronymes métier. La recherche sémantique capte l'intention, mais elle noie souvent ces termes précis dans un concept vectoriel trop vague pour les retrouver.

Le symptôme. Les questions qui contiennent un identifiant précis (une référence, un code, un nom de produit exact) échouent plus souvent que les questions formulées de façon générale, alors que l'information existe et est bien indexée.

Le test. Testez la même question formulée de deux façons : une fois avec le vocabulaire exact du document, une fois reformulée avec des mots différents mais le même sens. Si l'écart de qualité est important, la recherche manque de sa composante lexicale. Une étude publiée à la conférence EACL 2026 a documenté ce phénomène de façon chiffrée : une reformulation simplement moins formelle d'une question peut faire chuter le rappel (Recall@5) jusqu'à 40 % selon le modèle de retrieval utilisé, ce qui illustre à quel point une recherche purement sémantique est sensible à la façon exacte dont une question est posée.

La correction. Ajouter une recherche lexicale de type BM25 en parallèle de la recherche vectorielle, puis fusionner les deux classements avec un algorithme comme le RRF (Reciprocal Rank Fusion). C'est un changement d'architecture, pas seulement un paramètre à ajuster.

Coût relatif. Moyen. Le bénéfice est généralement le plus net des sept causes de cette liste dès qu'un corpus contient du vocabulaire technique ou des identifiants précis. C'est aussi, à ce stade, qu'un système déjà déployé mérite un regard extérieur : refondre la couche de recherche sans casser ce qui fonctionne déjà demande une méthode que peu d'équipes internes ont eu l'occasion de pratiquer plusieurs fois. Une baseline d'évaluation RAG permet de mesurer précisément l'impact de chaque changement avant de le déployer en production, plutôt que d'itérer à l'aveugle sur un système que des utilisateurs réels utilisent déjà.

Étape 5 : reranking absent et top-k mal calibré

Le bon passage peut exister dans les résultats de recherche sans jamais être vu par le modèle de génération, soit parce qu'il est classé trop bas, soit parce que le nombre de résultats transmis (le top-k) est mal calibré. Ces deux réglages sont souvent négligés parce qu'ils semblent secondaires, alors qu'ils déterminent ce que le modèle voit réellement.

Pas de reranking : le bon passage est là, mais en quinzième position

Le symptôme. Le document contenant la réponse figure bien parmi les résultats de recherche quand vous les inspectez manuellement, mais il n'est jamais dans les premiers résultats transmis au modèle de génération.

Le test. Loggez les scores de similarité de tous les résultats de recherche pour une requête donnée, pas seulement les cinq premiers. Si le bon passage apparaît en dixième ou quinzième position, la recherche fonctionne, le classement est en cause.

La correction. Ajouter un reranker de type cross-encoder après la recherche initiale : on récupère large (une cinquantaine de résultats), le reranker les réanalyse un par un avec la question, puis on ne garde que les meilleurs pour le modèle de génération. C'est une étape de finition, à ajouter seulement après avoir corrigé le corpus, le chunking et le hybrid search : un reranker ne peut pas remonter un passage qui n'a jamais été récupéré en premier lieu.

Top-k mal calibré : trop de bruit ou pas assez de matière

Le symptôme. Soit le modèle génère des réponses qui mélangent plusieurs sujets sans rapport (top-k trop élevé, trop de contexte non pertinent), soit il répond de façon incomplète à des questions qui nécessitent plusieurs passages pour être traitées correctement (top-k trop bas).

Le test. Faites varier le top-k sur un même échantillon de questions représentatives et mesurez l'impact sur le taux de bonnes réponses. La valeur optimale dépend directement de la longueur de vos chunks et de la nature des questions : il n'existe pas de chiffre universel valable pour tous les corpus.

La correction et son coût. Ajuster ce paramètre est rapide, souvent quelques heures de test. C'est l'une des corrections les moins coûteuses de cette liste, mais elle est inefficace si les causes en amont (corpus, chunking, recherche) n'ont pas déjà été traitées.

Étape 6 : le prompt qui autorise la réponse sans preuve, et l'absence d'évaluation

Même avec un retrieval parfait, un prompt de génération mal cadré peut laisser le modèle répondre en dehors des documents fournis, produisant une réponse plausible mais fausse. Et sans dataset d'évaluation, ce type d'erreur reste invisible jusqu'à ce qu'un utilisateur s'en plaigne, parfois des mois plus tard.

Le prompt qui autorise à répondre sans preuve

Le symptôme. Le retrieval remonte les bons passages, visibles dans les logs, mais la réponse générée contient une information qui ne figure dans aucun d'entre eux. C'est une hallucination classique, produite malgré un contexte correct.

Le test. Relisez le prompt système de génération. Contient-il une instruction explicite du type "réponds uniquement à partir des passages fournis, indique que tu ne sais pas si l'information est absente" ? La plupart des prompts hérités d'un prototype n'ont jamais cette contrainte, parce qu'elle n'était pas nécessaire en démo sur trois documents propres.

La correction. Ajouter cette contrainte explicite dans le prompt, et surtout définir un seuil de confiance en dessous duquel le système répond qu'il ne sait pas et, idéalement, escalade vers un humain plutôt que de laisser sortir une réponse inventée.

L'absence totale d'évaluation, la cause qui explique pourquoi les six précédentes n'ont jamais été détectées

Le symptôme. Personne dans l'entreprise ne sait dire, avec un chiffre, quel pourcentage de questions le RAG traite correctement. Le jugement repose sur des retours ponctuels d'utilisateurs mécontents, pas sur une mesure systématique.

Le test. Existe-t-il un jeu de questions-réponses de référence, passé régulièrement sur le système pour mesurer un taux de bonnes réponses ? Si la réponse est non, c'est la cause racine qui explique pourquoi les six problèmes précédents ont pu s'installer sans être détectés à temps.

La correction et son coût. Constituer un jeu de 30 à 50 questions représentatives, avec leurs réponses attendues, et le repasser après chaque modification du système. C'est peu coûteux à mettre en place, mais c'est la brique qui manque le plus souvent, parce qu'elle ne produit pas de résultat visible immédiat, seulement une visibilité sur ce qui se passe vraiment.

Si vous êtes arrivé jusqu'ici sans avoir isolé la cause, ou si plusieurs causes se combinent, c'est le signe qu'un diagnostic structuré vaut mieux qu'une nouvelle itération à l'aveugle. C'est exactement l'objet de notre audit technique RAG : établir une baseline mesurée, isoler la ou les causes réelles parmi celles listées ici, et prioriser les corrections par impact et par coût, plutôt que de deviner.

Ce que cet ordre ne remplace pas

Suivre cette séquence corrige la grande majorité des cas où un RAG répond à côté. Elle ne remplace pas un travail de conception en amont si le projet part de zéro : notre article sur les 5 erreurs qui font échouer un projet RAG couvre les pièges de cadrage et de méthode à éviter avant même le premier déploiement, et notre guide pour optimiser un système RAG détaille en profondeur chacun des cinq leviers techniques (hybrid search, parsing, chunking, query rewriting, reranking) une fois la cause identifiée.

Elle ne remplace pas non plus une refonte architecturale si le vrai problème n'est pas le retrieval mais la nature des questions posées. Quand les utilisateurs posent régulièrement des questions qui croisent plusieurs documents ou nécessitent une comparaison, ce n'est plus un bug de configuration : c'est le signe qu'un RAG classique atteint ses limites structurelles et qu'il faut envisager une couche agentique. Et pour les cas de support client où l'historique et le contexte conversationnel comptent autant que les documents, l'architecture elle-même doit être pensée différemment, comme le montre notre article sur le RAG appliqué à une base de connaissances support N1.

Enfin, cet ordre suppose que vous savez mesurer ce que vous corrigez. Les frameworks d'évaluation comme RAGAS, TruLens ou DeepEval, présentés dans notre comparatif des outils d'évaluation et d'observabilité LLM, transforment cette dernière étape en discipline reproductible plutôt qu'en intuition. Et pour comprendre ce qui se joue au niveau des embeddings eux-mêmes, notre guide technique sur les embeddings et la recherche sémantique pose les bases qui sous-tendent les étapes 2 à 4 de ce diagnostic.

Questions fréquentes

Pour aller plus loin

• Audit technique RAG : établir une baseline mesurée et une roadmap de correction priorisée sur un système déjà en production.
• 5 erreurs qui font échouer un projet RAG : les pièges de cadrage et de méthode à éviter avant même le premier déploiement.
• Optimiser un RAG : 5 leviers qui changent tout : hybrid search, parsing, chunking, query rewriting et reranking en détail.
• Bases de données vectorielles pour le RAG : comparatif pour choisir selon vos besoins de filtrage et de recherche hybride.
• Outils d'évaluation et d'observabilité LLM : RAGAS, TruLens, DeepEval et les métriques pour mesurer un RAG en continu.
• Embeddings et recherche sémantique : la brique fondamentale derrière le chunking et le hybrid search.
• Agentic RAG : quand les questions croisent plusieurs documents et que le RAG classique atteint ses limites structurelles.
• RAG pour base de connaissances support client : un cas d'architecture où le contexte conversationnel compte autant que les documents.