Votre RAG répond à côté : le problème n'est presque jamais le modèle

---

title: "Votre RAG répond à côté : le problème n'est presque jamais le modèle" seoTitle: "Diagnostiquer un RAG qui répond à côté" description: "Un assistant documentaire qui invente des réponses n'a pas besoin d'un meilleur modèle. Voici comment isoler l'étape fautive, mesurer la récupération et corriger les six causes réelles." seoDescription: "Un RAG qui répond à côté n'a pas besoin d'un meilleur modèle : isolez l'étape fautive, mesurez la récupération et corrigez les vraies causes." date: "2026-09-12" author: "Équipe Raicode" tags: ["IA", "automatisation", "architecture", "qualité"] category: "IA & Automatisation" keywords: ["RAG", "diagnostiquer un RAG", "recherche vectorielle", "recall at k", "reranking", "chunking", "recherche hybride BM25", "assistant documentaire LLM", "hallucination RAG", "base de connaissances IA"]

L'assistant interne est en ligne depuis six semaines. Il est branché sur 4 000 documents — procédures, contrats types, comptes rendus, documentation produit — et il répond avec un aplomb parfait. Le problème, c'est qu'environ une réponse sur trois est fausse : elle cite une procédure abrogée, elle mélange deux contrats, ou elle affirme quelque chose qui ne figure nulle part dans la base. L'équipe a déjà fait deux choses : ajouter « réponds uniquement à partir des documents fournis » dans le prompt système, et prévoir de passer au modèle le plus récent le mois prochain.

Ces deux actions ne changeront rien, parce qu'elles traitent l'étape qui fonctionne. Dans la quasi-totalité des systèmes RAG que nous reprenons, le modèle génère correctement à partir de ce qu'on lui donne. Ce qu'on lui donne est mauvais. Le débat « quel modèle choisir » est confortable parce qu'il se règle en changeant une ligne de configuration ; le vrai travail est en amont, dans la partie que personne n'a instrumentée.

Cet article décrit comment isoler l'étape fautive en une demi-journée, comment mesurer la récupération pour de bon, et les six causes qui expliquent l'écrasante majorité des réponses à côté. Il s'adresse à une équipe qui a déjà un RAG en production ou en pilote, pas à quelqu'un qui se demande s'il doit en construire un.

Le test qui fait gagner trois mois

Un système RAG a deux étapes : on récupère des passages, puis on génère une réponse à partir de ces passages. Un échec vient forcément de l'une des deux. Tant que vous ne savez pas laquelle, chaque décision est un pari.

Le test tient en une après-midi. Prenez vingt questions auxquelles l'assistant a mal répondu. Pour chacune, allez chercher à la main, dans le corpus, le ou les passages qui contiennent la bonne réponse. Puis posez la question au modèle en lui fournissant ces passages-là, directement, sans passer par la recherche.

Deux issues possibles :

• Le modèle répond correctement dans 18 ou 19 cas sur 20. C'est le résultat habituel. Votre problème est à 100 % dans la récupération. Changer de modèle ne fera qu'augmenter la facture. Passez à la section suivante.
• Le modèle se trompe encore sur cinq ou six questions alors qu'il a le bon passage sous les yeux. Là, il y a effectivement un travail sur la génération : passages contradictoires mal arbitrés, consignes de format qui écrasent la consigne de fidélité, questions qui demandent un calcul plutôt qu'une citation. C'est plus rare, et ça se traite séparément.

Ce test n'a l'air de rien. Il tranche pourtant la question que les équipes retournent en réunion depuis des semaines, et il évite la migration de modèle à 40 000 € qui n'aurait déplacé aucun des trois tiers de réponses fausses.

Mesurer la récupération, pas la satisfaction

Une fois établi que le problème est en amont, il faut une mesure. « Les utilisateurs disent que c'est mieux » ne permet pas d'arbitrer entre deux stratégies de découpage.

La mesure de base s'appelle le rappel à k : sur un jeu de questions dont vous connaissez la bonne source, dans quelle proportion le passage correct figure-t-il parmi les k résultats que la recherche remonte ? Si vous envoyez huit passages au modèle, mesurez le rappel à 8. C'est la seule chose qui compte : un passage qui n'est pas dans le contexte n'a aucune chance d'apparaître dans la réponse.

Constituer le jeu demande une journée de travail, pas plus. Cinquante à quatre-vingts questions suffisent, à condition qu'elles viennent des vrais usages — les logs de l'assistant, les tickets support, les questions posées en réunion — et pas d'un atelier où l'on invente des questions bien formées. Pour chacune, notez l'identifiant du document qui fait foi.

[
  {
    "question": "Quel est le délai de rétractation sur le contrat cadre 2025 ?",
    "sources_attendues": ["contrat-cadre-2025.pdf#art-7"]
  },
  {
    "question": "Qui valide une remise supérieure à 15 % ?",
    "sources_attendues": ["procedure-remises-v4.docx#section-3"]
  }
]

Faites tourner la recherche seule sur ce jeu et comptez. Les chiffres que nous relevons à l'arrivée sur un RAG « qui ne marche pas » tournent entre 45 % et 65 % de rappel à 8. Un système exploitable commence autour de 90 %. L'écart entre 60 % et 90 % de rappel, c'est exactement l'écart entre un outil que le support refuse d'ouvrir et un outil qu'il utilise tous les jours.

Cette démarche est la même que celle décrite dans notre article sur l'évaluation d'un agent avant la mise en production : tant que la fiabilité n'est pas un nombre, elle reste une opinion, et une opinion ne se corrige pas.

Les six causes réelles

Une fois la mesure en place, les responsables sont presque toujours les mêmes. Elles se cumulent, et elles se traitent dans cet ordre.

1. Un découpage mécanique qui coupe le sens

Le découpage par défaut — 1 000 caractères, 200 de chevauchement — traite un contrat de trente pages comme un flux de texte indifférencié. Résultat : un article se retrouve scindé au milieu d'une phrase, un tableau de tarifs est séparé de son en-tête, et la clause de rétractation atterrit dans le même bloc que la clause de confidentialité.

Le correctif ne consiste pas à augmenter la taille des blocs, mais à découper selon la structure du document : par article pour un contrat, par section de titre pour de la documentation, par question pour une FAQ. Sur un corpus documentaire structuré, ce seul changement fait typiquement passer le rappel de 60 % à 75 %.

2. Des passages privés de leur contexte

Un bloc qui commence par « Dans ce cas, le délai est porté à trente jours » n'est interprétable par personne, humain compris. Il n'indique ni le document d'origine, ni la section, ni de quel cas on parle. Vectorisé tel quel, il ne ressemble à aucune question réelle.

La parade tient en une ligne de traitement : préfixer chaque bloc de son fil d'Ariane — titre du document, date de version, hiérarchie des sections — avant de calculer son vecteur. Le coût est nul, le gain sur le rappel est régulièrement de cinq à dix points, et l'effet de bord est appréciable : le modèle reçoit enfin de quoi citer sa source correctement.

3. Une recherche purement vectorielle

C'est la cause la plus fréquente et la plus mal comprise. Les vecteurs capturent la proximité sémantique, ce qui est excellent pour « comment annuler une commande » face à un document intitulé « procédure de rétractation ». Ils sont en revanche médiocres sur tout ce qui est exact : une référence produit, un numéro d'article, un nom propre, un code d'erreur, un acronyme maison. Une recherche vectorielle qui cherche REF-4471-B remonte volontiers REF-4471-C, parce que les deux se ressemblent beaucoup dans l'espace des vecteurs.

Or les questions des utilisateurs contiennent massivement ce type de termes. Le correctif est la recherche hybride : combiner la recherche vectorielle avec une recherche lexicale classique de type BM25, et fusionner les deux classements. Si votre base de données est déjà PostgreSQL, cela ne demande pas de nouvelle brique d'infrastructure. C'est, dans notre expérience, le levier au meilleur rapport gain/effort : dix à vingt points de rappel pour deux à trois jours de travail. Le raisonnement est le même que pour la recherche interne d'un site web, où l'exactitude sur les références produit décide de l'utilité de l'outil.

4. Pas de reranking

La recherche initiale est optimisée pour la vitesse sur des millions de vecteurs : elle est approximative par construction. Elle remonte souvent le bon passage, mais en septième ou en douzième position — donc hors du contexte si vous n'en envoyez que cinq.

Un modèle de reranking prend les trente premiers résultats et les réordonne en comparant réellement chaque passage à la question. L'opération coûte quelques dizaines de millisecondes et un montant négligeable par requête. Sur des corpus où le rappel à 30 était déjà bon mais le rappel à 5 mauvais, c'est le geste qui débloque tout : élargissez la recherche initiale à trente candidats, puis reclassez pour n'en garder que cinq.

5. Un corpus pollué

Personne n'aime cette cause parce qu'elle ne se règle pas avec du code. Le corpus contient trois versions du même contrat, deux procédures contradictoires, des comptes rendus de réunion où une décision a été évoquée puis abandonnée. La recherche fait son travail : elle remonte un passage pertinent. Il est simplement périmé.

Aucun réglage technique ne compense. Il faut trancher en amont : marquer les versions faisant foi, exclure les brouillons et les archives de l'indexation, ajouter une date de validité à chaque document et filtrer dessus. Comptez deux à cinq jours d'un métier qui connaît le fonds documentaire. C'est le poste le plus rentable du chantier, et celui qui est systématiquement reporté.

6. Des questions qui ne relèvent pas de la recherche de passage

« Combien de clients ont résilié en 2025 ? », « Quelle est la différence entre nos trois offres ? », « Résume-moi les décisions du dernier trimestre ». Ces questions n'ont pas de réponse dans un passage : elles demandent d'agréger, de compter ou de comparer sur l'ensemble du corpus. Un RAG classique y répond toujours — mal, à partir des cinq blocs qu'il a trouvés.

Il faut les identifier et les router ailleurs : vers une requête SQL sur la vraie base pour les questions de dénombrement, vers un document de synthèse rédigé une fois pour les comparatifs récurrents, ou vers un refus explicite. Un assistant qui répond « cette question demande un chiffre consolidé, voici où le trouver » vaut mieux qu'un assistant qui invente un nombre plausible.

L'ordre d'attaque, et ce que ça coûte

Sur une reprise type, nous traitons dans cet ordre, parce que c'est celui du rapport entre le gain et l'effort :

1. Jeu d'évaluation et mesure du rappel — 1 jour. Sans lui, tout le reste est aveugle.
2. Recherche hybride — 2 à 3 jours. Le plus gros gain unitaire.
3. Contextualisation des blocs — 1 jour. Quasi gratuit.
4. Reranking — 1 à 2 jours. Décisif si le rappel large est bon.
5. Découpage structurel — 2 à 4 jours selon l'hétérogénéité des formats.
6. Nettoyage du corpus — en parallèle, côté métier.

Entre huit et douze jours d'ingénierie, donc, pour passer typiquement d'un rappel de 60 % à un rappel supérieur à 90 %. À comparer aux six mois de tâtonnements sur les prompts que ce chantier remplace, et qui sont l'une des raisons classiques pour lesquelles un POC IA ne passe jamais en production.

Côté facture, deux points méritent l'attention. Le reranking ajoute un appel par requête, mais il permet presque toujours de réduire le nombre de passages envoyés au modèle — de huit à quatre, par exemple. Comme les passages dominent le volume de tokens en entrée, le bilan est souvent négatif, c'est-à-dire favorable. Le réindexage complet du corpus, lui, est un coût ponctuel qu'il faut chiffrer avant de lancer la machine : sur 4 000 documents, il reste modeste, mais il se paie à chaque changement de stratégie de découpage. C'est le genre de ligne qui explique les surprises décrites dans notre article sur la facture d'API qui triple en production.

Ce que le RAG ne réparera pas

Trois situations méritent d'être reconnues tôt, parce qu'aucun réglage ne les sauve.

Si la réponse n'existe nulle part dans le corpus, le système ne peut que le dire. Nous voyons régulièrement des assistants jugés « mauvais » sur des questions dont la réponse n'a jamais été écrite : elle est dans la tête de deux personnes. Mesurez cette proportion avant d'accuser la technique — au-delà de 20 %, le chantier prioritaire est documentaire, pas informatique.

Si les utilisateurs attendent une décision plutôt qu'une information (« est-ce que je peux accorder cette remise ? »), un moteur de recherche augmenté n'est pas le bon outil. Il faut une règle métier explicite, quitte à ce que le modèle serve uniquement à la formuler.

Enfin, si le corpus change plusieurs fois par jour et que la fraîcheur est critique, l'indexation devient un problème d'ingénierie de données à part entière, avec ses propres délais de propagation. Cela se fait, mais cela se budgète comme tel.

Par où commencer lundi

Ne touchez à aucun paramètre cette semaine. Faites trois choses, dans l'ordre : extrayez cinquante vraies questions des logs et des tickets, annotez la source qui fait foi pour chacune, et mesurez le rappel actuel de votre recherche. Vous aurez, en deux jours, le chiffre qui manquait à toutes vos réunions — et vous saurez si vous avez un problème de récupération, un problème de corpus, ou un problème de périmètre.

C'est la seule manière de savoir ce que vaut le changement suivant. Un système dont on connaît le rappel se répare en deux semaines ; un système dont on ne connaît que l'humeur des utilisateurs se répare, au mieux, par hasard.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.