22 août 2026
RAG en production : les 7 erreurs qui cassent la qualité (et comment les corriger)
Les 7 erreurs RAG que je corrige en production : chunking, evals, reranking, métadonnées, hallucinations, latence, coût et monitoring.
Un RAG ne casse presque jamais d'un coup
Un système RAG donne rarement l'impression d'être mauvais le premier jour. La démo répond vite, cite deux documents, et donne confiance. Les problèmes arrivent ensuite, quand les vrais utilisateurs posent des questions ambiguës, quand le corpus grossit, ou quand une réponse approximative influence une décision métier. À ce moment-là, la qualité ne se joue plus dans le choix du modèle. Elle se joue dans l'ingénierie du système complet.
Dans les projets que je vois en production, notamment dans des environnements média et connaissance comme Brut, Les Echos, ou des équipes produit plus discrètes, les mêmes erreurs reviennent. Elles sont concrètes : découpage trop naïf, aucune mesure de rappel, documents obsolètes, prompt qui demande au modèle d'être sûr quand les sources ne le sont pas. La bonne nouvelle, c'est qu'elles se corrigent quand on traite le RAG comme un produit vivant, pas comme une boîte noire branchée sur une base documentaire.
Erreur 1 — Découper pour le moteur, pas pour le métier
Le premier réflexe consiste à découper tous les documents en morceaux de taille fixe : 800 tokens, overlap de 100, indexation, terminé. Cela fonctionne sur une démo simple, mais la qualité chute dès que l'information utile dépend d'un titre, d'une définition, d'un tableau, d'une exception juridique, ou d'un paragraphe situé juste avant. Le chunk devient techniquement propre et métier pauvre. Le modèle récupère un extrait plausible, mais pas l'unité de sens dont il avait besoin.
La correction que j'applique est de repartir du document réel. Je découpe par sections, titres, blocs sémantiques, pages ou entités métier quand c'est possible. J'ajoute des métadonnées utiles au chunk : source, date, type de document, niveau de confiance, propriétaire, version. Je teste ensuite plusieurs tailles de chunk sur des questions réelles, pas sur une intuition. Un bon découpage doit permettre de répondre précisément, mais aussi de citer proprement. Si l'utilisateur ne peut pas vérifier la source, le RAG n'est pas encore prêt.
Erreur 2 — Croire que l'embedding suffit
La recherche vectorielle est puissante, mais elle n'est pas magique. Elle rapproche des formulations, pas nécessairement des vérités métier. Une question peut contenir un acronyme interne, une référence produit, un nom de client, une période, ou un mot exact qui compte plus qu'une similarité sémantique générale. J'ai vu des systèmes récupérer un document très proche dans le ton et complètement faux dans le contexte. C'est dangereux parce que la réponse paraît intelligente.
En production, je combine souvent plusieurs signaux : recherche vectorielle, recherche lexicale, synonymes contrôlés, filtres métier, puis reranking sur les meilleurs candidats. Le reranker est utile quand le corpus contient beaucoup de documents similaires. Il remet la bonne source au-dessus, au lieu de laisser l'embedding décider seul. Je préfère un pipeline explicite, observable et testable, à une recherche élégante qui échoue silencieusement sur les cas importants.
Erreur 3 — Ne jamais évaluer la recherche
Beaucoup d'équipes évaluent seulement la réponse finale. Elles lisent dix sorties, trouvent que cela a l'air correct, puis passent à autre chose. Le problème est que le générateur peut produire une bonne réponse avec les mauvaises sources, ou une mauvaise réponse malgré les bonnes sources. Sans évaluation séparée de la retrieval, on ne sait pas où le système échoue. On débat du modèle, alors que le problème est peut-être simplement que le bon document n'arrive jamais dans le top 5.
Mon correctif est pragmatique : construire un jeu de 50 à 100 questions réelles avec sources attendues, réponses acceptables, refus attendus et pièges. Je mesure le rappel, le rang de la bonne source, les cas sans résultat, puis je rejoue ce set à chaque changement de chunking, d'embedding, de filtres ou de reranking. Les evals ne sont pas une couche académique. Elles évitent de casser ce qui marchait hier en améliorant ce qui semblait faible aujourd'hui.
Erreur 4 — Oublier les métadonnées, les dates et les droits
Un RAG qui récupère le bon paragraphe dans le mauvais contexte reste un mauvais RAG. Le cas classique : une politique RH de 2023 passe devant la version 2026, une slide commerciale remonte avant la documentation validée, ou un utilisateur obtient une information qui existe dans l'index mais qu'il n'a pas le droit de lire. Le moteur semble performant, mais il casse la confiance parce qu'il ignore la gouvernance du contenu.
Je filtre avant de générer, pas après coup. Les chunks doivent transporter les métadonnées qui comptent : validité, langue, équipe propriétaire, confidentialité, client concerné, statut brouillon ou approuvé. Les permissions doivent être appliquées au moment de la recherche, avec des tests dédiés. Dans un système sérieux, une source ancienne ou non autorisée ne doit pas être récupérée puis masquée par le prompt. Elle ne doit pas entrer dans le contexte.
Erreur 5 — Demander au modèle de deviner la vérité
Quand la recherche remonte des sources faibles, contradictoires ou incomplètes, le modèle a tendance à lisser le problème. Il rédige une réponse confiante, mélange deux documents, ou invente la partie manquante pour satisfaire l'utilisateur. Ce n'est pas un défaut moral du modèle. C'est le comportement naturel d'un générateur optimisé pour produire une réponse utile. En RAG, la question n'est donc pas seulement : que sait le modèle ? La question est : que peut-il prouver avec les sources disponibles ?
Je construis des garde-fous simples et visibles. Le prompt doit demander des réponses ancrées dans les sources, des citations courtes, et un refus clair quand les documents ne suffisent pas. L'interface doit montrer les références utilisées, pas seulement les cacher dans les logs. Sur les sujets sensibles, j'ajoute parfois une étape de vérification : est-ce que chaque affirmation importante correspond à un extrait ? Si non, la réponse est reformulée ou bloquée. Une bonne expérience RAG sait dire : je n'ai pas assez d'éléments fiables.
Erreur 6 — Optimiser la qualité en oubliant latence et coût
On peut toujours améliorer une réponse en ajoutant plus de chunks, un meilleur modèle, un reranker plus lourd et une seconde passe de critique. Le problème est que l'utilisateur attend, et que la facture augmente à chaque requête. Un pipeline parfait à 18 secondes n'est pas forcément un bon produit. Un pipeline excellent mais trop cher sera limité ou désactivé dès que l'usage monte.
Je traite la latence et le coût comme des contraintes de design. Je garde un top-k raisonnable, je reranke seulement quand cela améliore vraiment les cas difficiles, je cache ce qui peut l'être, je stream la première réponse utile, et je choisis les modèles par étape plutôt que par ego. Une extraction simple n'a pas besoin du même modèle qu'une synthèse à risque. Le bon RAG donne assez de qualité pour la décision, assez vite pour le workflow, à un coût que l'entreprise peut assumer tous les jours.
Erreur 7 — Ne rien monitorer après le lancement
La qualité RAG dérive. Le corpus change, les utilisateurs apprennent à poser de nouvelles questions, les documents vieillissent, les prompts sont modifiés, et une source utile disparaît parfois sans bruit. Si personne ne regarde les traces, le système peut perdre 20% de qualité avant que l'équipe ne comprenne pourquoi les utilisateurs reviennent vers Slack ou Google Drive. Le lancement n'est pas la fin du travail. C'est le début de la boucle de maintenance.
Je veux toujours voir quelques signaux simples : question posée, documents récupérés, score de recherche, réponse finale, latence, coût, feedback, fallback, et version du prompt. Ensuite, je mets en place une revue légère : quelles questions échouent, quelles sources manquent, quels refus sont utiles, quelles réponses coûtent trop cher ? Cette boucle transforme le RAG en système améliorable. Sans monitoring, on espère. Avec monitoring, on pilote.
Le bon RAG est un produit qui apprend
La plupart des problèmes de qualité RAG ne demandent pas une architecture plus compliquée. Ils demandent une architecture plus honnête : documents propres, recherche mesurée, règles de confiance, interface qui expose les sources, et équipe qui regarde ce qui se passe après la mise en production. C'est moins impressionnant qu'une démo magique, mais beaucoup plus rentable.
Quand je reprends un RAG existant, je commence rarement par changer de modèle. Je regarde les questions réelles, les sources remontées, les erreurs utilisateur et les contraintes produit. Puis je corrige dans l'ordre : chunking, retrieval, filtres, evals, garde-fous, latence, monitoring. C'est cette discipline qui fait passer un assistant documentaire de sympa en réunion à vraiment utile dans le travail quotidien.