Votre RAG répond à côté : les 7 causes et leurs correctifs

Un RAG qui répond à côté a presque toujours un problème de recherche, pas un problème de modèle. Quand on nous appelle pour « corriger l'IA », le modèle est rarement en cause : le plus souvent, le bon passage n'a pas été retrouvé, ou il l'a été au milieu de passages faux, périmés ou tronqués. Voici les sept causes les plus fréquentes, avec le symptôme, le test en dix minutes et le correctif. La préparation de la base est traitée dans notre guide de préparation d'une base documentaire pour un RAG, on ne la refait pas ici.

Comment diagnostiquer un RAG en dix minutes ?

On rejoue la question fautive et on regarde les passages remontés par la recherche, avant de lire ce que le modèle en a fait. Si la bonne page ne figure pas dans les cinq ou dix fragments envoyés au modèle, le problème est en amont (découpage, doublons, requête, filtres, recherche). Si elle y figure et que la réponse reste fausse, le problème est dans le prompt. Trois questions suffisent : le bon document est-il dans la base, dans la bonne version ? Est-il remonté ? Le modèle l'a-t-il utilisé ? Chaque cause ci-dessous fait échouer une de ces étapes. Une étude de l'université Deakin publiée sur arXiv en janvier 2024, à partir de trois déploiements réels, conclut de même : la validation d'un RAG n'est possible qu'en fonctionnement, sa robustesse se construit au fil des corrections.

Pourquoi le RAG coupe-t-il un tableau ou renvoie-t-il une clause incomplète ?

Parce que le découpage a été fait à la longueur, pas à la structure. Un découpage par défaut à 800 jetons avec un recouvrement de 400, ce que propose par exemple l'API de recherche d'OpenAI quand on ne précise rien, coupera un tableau de tarifs en deux et tranchera une clause au milieu de sa condition suspensive. Le modèle reçoit la moitié d'une information et complète le reste, avec aplomb.

Symptôme : la réponse est juste sur le début d'un tableau et fausse sur la fin, ou cite une exception sans la règle. Le test : ouvrir le fragment remonté et vérifier s'il commence ou se termine en pleine ligne. Le correctif : redécouper selon la structure (un tableau entier, une clause entière, un paragraphe avec son titre de section) et ajouter à chaque fragment une phrase de contexte qui dit d'où il vient. Sur la PME industrielle citée plus bas, ce redécoupage a été fait en recette, à partir des retours des techniciens.

La deuxième cause de cette famille, ce sont les doublons et les versions périmées. Un serveur de fichiers accumule « contrat_v2_final_OK.docx » à côté de « contrat_v3.docx » ; le moteur remonte les deux et le modèle mélange. Symptôme : deux utilisateurs obtiennent deux chiffres différents pour la même question. Test : chercher un tarif qui a changé récemment et compter les fragments contradictoires. Correctif : dédoublonner par empreinte du contenu, garder une version par document, stocker la date de validité en métadonnée. Notre article sur les documents à intégrer ou à exclure d'un RAG détaille les critères de tri.

La question de l'utilisateur est-elle assez précise pour la recherche ?

Souvent non, et le système ne l'aide pas. « Garantie ? », « délai de livraison », « procédure retour » : trois mots sans nom de produit ni contexte donnent une recherche qui ramène des fragments génériques, et le modèle répond sur la garantie d'un autre produit. Test : reposer la question en une phrase complète avec le nom du produit. Si la réponse devient juste, la reformulation manque.

Le correctif tient en une étape de plus avant la recherche : demander au modèle de réécrire la question en une requête complète, en s'appuyant sur les échanges précédents de la conversation. Sur le copilote conversationnel livré à SuperHote, qui traite 95 % de 2 millions de messages mensuels avec transfert humain sous un seuil de confiance, cette étape était indispensable : un message de voyageur est rarement une question bien formée.

La quatrième cause est jumelle : l'absence de filtre par métadonnées. Une base qui couvre trois sites, douze gammes et cinq années de tarifs ramène, sans filtre, le fragment le plus proche sémantiquement, quel que soit le site. Le correctif consiste à étiqueter chaque document (site, produit, date, service émetteur) à l'indexation, puis à filtrer avant la recherche vectorielle, pas après. Sur l'assistant industriel cité plus bas, chaque machine est livrée à façon avec son propre dossier : le numéro de machine et la version du document ont été posés en métadonnées dès l'indexation.

Que faire quand le RAG invente au lieu de dire « je ne sais pas » ?

Imposer dans le prompt système deux règles non négociables : citer la source de chaque affirmation, et répondre « l'information n'est pas dans la base » quand les passages remontés ne contiennent pas la réponse. Sans ces consignes, un modèle fait ce pour quoi il a été entraîné, il complète. Symptôme : des réponses fluides, jamais sourcées, fausses une fois sur cinq. Test : poser une question dont la réponse n'est nulle part dans la base. Si le système répond quand même, le prompt est trop permissif.

En pratique, le prompt reçoit les fragments numérotés et doit renvoyer, pour chaque phrase de sa réponse, le numéro du fragment utilisé ; les phrases sans référence sont supprimées avant affichage. Sur la PME industrielle centenaire où nous avons indexé 2 000 documents techniques, chaque réponse cite le nom du fichier et le numéro de page. C'est cette règle, plus que la vitesse, qui a fait adopter l'outil par les techniciens SAV : le temps de recherche a baissé de 55 %, et la précision mesurée en recette sur cinq techniciens atteint 90 %.

Faut-il combiner recherche vectorielle et recherche par mots-clés ?

Oui, dès que la base contient des références, des codes, des noms propres ou des chiffres. La recherche vectorielle seule comprend le sens mais confond « FR-2041-B » et « FR-2041-C », deux références sans rapport. Symptôme : bon sujet, mauvaise référence ou mauvaise version de norme. Test : chercher une référence exacte et vérifier si le fragment qui la contient arrive en tête.

Le correctif est la recherche hybride : une recherche lexicale de type BM25, qui exige les mots exacts, combinée à la vectorielle, avec fusion des classements. Les chiffres publiés convergent. Anthropic a mesuré en septembre 2024 que la combinaison d'embeddings contextualisés et d'un BM25 contextualisé réduit de 49 % le taux d'échec de recherche sur les 20 premiers fragments, et de 67 % avec un reclassement en sortie. Sur des documents financiers mêlant texte et tableaux, une étude publiée sur arXiv en avril 2026 constate que BM25 seul bat les méthodes vectorielles récentes, et qu'un pipeline hybride avec reclassement atteint un rappel à 5 de 0,816 sur 23 088 questions. Notre avis : on déconseille de partir en production avec une recherche purement vectorielle sur une base technique, juridique ou financière. L'hybride coûte une à deux journées de développement ; une mauvaise référence envoyée à un client coûte bien plus.

Quel correctif pour quel symptôme, et à quel effort ?

La septième cause n'est pas technique : personne ne vérifie le système après la mise en service. Les documents changent, les questions évoluent, un fournisseur met à jour son modèle d'embeddings, et la qualité dérive sans que personne le mesure. Symptôme : « ça marchait bien au début ». Le correctif est un jeu de 50 à 100 questions avec leurs réponses attendues, rejoué à chaque changement de la base ou du prompt, avec un seuil d'alerte. La construction et les indicateurs de ce jeu de test sont décrits dans notre article sur les métriques d'évaluation d'un RAG ; ici, retenons seulement qu'un RAG sans jeu de questions est un RAG dont on découvrira la dérive par un client mécontent.

Le tableau récapitule les sept causes, du symptôme observé à l'effort de correction constaté en mission.

Efforts constatés sur des bases de 1 000 à 10 000 documents, code accessible. Ils s'additionnent rarement : une mission de correction type traite trois causes en deux semaines, pas sept.

Comment JUWA reprend un RAG qui répond à côté

On commence par une semaine de diagnostic, jamais par une réécriture. On récupère 30 à 50 questions qui ont posé problème, on rejoue chacune en affichant les fragments remontés, et on classe chaque échec dans une des sept causes. Ce tri donne un plan chiffré et répond à la question qui fâche : faut-il changer de modèle ? Presque jamais.

Ensuite, on corrige dans l'ordre du tableau, après avoir livré un jeu de questions d'évaluation, pour que chaque correctif soit mesuré et non ressenti. La validation humaine sous seuil de confiance est en place dès la première version, l'hébergement reste en France ou en Europe quand la donnée l'exige, et un chef de projet nommé fait le point chaque semaine. Pour un nouveau projet, notre offre de chatbot IA professionnel adossé à vos documents intègre d'emblée ces sept garde-fous, avec une mise en production en 4 à 8 semaines.