RAG en production : les erreurs qui coûtent cher, et comment les éviter

Le RAG, ou génération augmentée par récupération, promet une chose simple et puissante : répondre à partir de vos documents, avec vos informations, plutôt que de laisser le modèle inventer. En démonstration, c’est convaincant. On pose une question, la réponse arrive, sourcée, dans votre langue, et l’enthousiasme monte.

En production, la réalité rattrape vite la démo. Le document est dans la base, la question est claire, et pourtant la réponse est à côté, ou pire, affirmée avec assurance. Le réflexe consiste alors à changer de modèle, comme si la justesse dépendait de la taille du LLM. Dans la majorité des cas, le modèle n’est pas le coupable : la chaîne en amont, des sources au découpage puis à la sélection des passages, a introduit l’erreur bien avant la génération. Et ces erreurs se paient en utilisateurs déçus, en argent perdu et en confiance entamée.

Elles ont une autre particularité : elles se cumulent et se masquent. La recherche renvoie un mauvais passage, le modèle compose une réponse plausible, et personne ne le remarque tant qu’un utilisateur ne se plaint pas. La bonne nouvelle, c’est qu’elles sont identifiables et corrigeables une par une. Voici les erreurs les plus fréquentes, avec pour chacune le symptôme, la cause et le correctif, puis ce qu’il faut mesurer avant de déployer.

Des documents jamais nettoyés

La première erreur est la plus banale et la plus coûteuse : on branche le RAG sur des documents bruts, sans les nettoyer. Des PDF scannés, des tableaux mal extraits, des doublons, des pages d’en-têtes et de mentions légales répétées partout. Et on s’étonne ensuite que l’agent réponde à côté.

La qualité de la récupération dépend entièrement de la qualité des sources. Un modèle de langage ne peut pas compenser un document illisible : si le contenu est mal extrait, le meilleur embedding du monde retrouvera du bruit, et la réponse sera du bruit. Le nettoyage n’est pas une tâche annexe, c’est la moitié du travail d’un RAG utile (on développe ce point dans pourquoi la qualité des sources prime sur le modèle).

Concrètement, cela passe par une chaîne de préparation : extraction propre (Docling ou Unstructured pour les PDF et les tableaux), déduplication, suppression des documents obsolètes, correction des tableaux et des images quand ils portent l’information. C’est un travail ingrat, souvent sous-estimé, et c’est pourtant lui qui sépare un RAG qui répond juste d’un RAG qui répond plausible.

Un découpage qui coupe l’information en deux

La deuxième erreur se joue au moment du découpage. Pour être retrouvée, l’information doit être découpée en passages, les chunks, et la façon de découper décide de ce que l’agent pourra récupérer. Si un passage sur les conditions de remboursement est coupé au milieu d’une phrase, ou si le montant maximal est dans un morceau et ses conditions d’application dans un autre, la recherche ne retrouvera jamais l’information complète. Symptôme typique : la réponse cite bien un chiffre, mais rate la condition qui s’y applique, et l’utilisateur agit sur une information incomplète.

La cause est presque toujours un découpage à longueur fixe, par exemple cinq cents caractères, qui ignore les titres, les paragraphes et les tableaux. C’est simple, et c’est faux dès que le document a une structure : une question et sa réponse se retrouvent séparées, un tableau est éclaté, une définition est coupée en plein milieu.

Le correctif : découper par sections sémantiques, en suivant la structure du document, avec si besoin un chevauchement minimal. Vérifiez ensuite avec une dizaine de questions dont la réponse dépend de deux passages distincts : si une seule échoue, votre découpage casse l’information quelque part. Les stratégies possibles sont détaillées dans bien découper ses documents.

Une recherche qui ne trouve pas le bon passage

La recherche vectorielle compare des représentations numériques du texte, pas les mots exacts. Si l’index a été construit avec un modèle d’embedding différent de celui utilisé à l’interrogation, ou si la question emploie des termes que le document ne contient pas (synonymes, jargon métier, références produit), le passage pertinent peut ne jamais remonter. Symptôme : le système répond « je n’ai pas trouvé cette information » alors que le document existe et contient la réponse.

Vérifiez d’abord la cohérence entre l’indexation et l’interrogation : le même modèle, la même version, la même normalisation du texte. Ensuite, testez une recherche hybride, qui combine recherche lexicale classique et recherche vectorielle (Elasticsearch, Weaviate ou Qdrant la proposent nativement) : elle rattrape à la fois les cas où le mot exact est présent et ceux où il ne l’est pas. Enfin, mesurez le rappel sur vos vraies questions, pas sur des questions inventées.

Un contexte trop chargé qui noie la bonne source

Plus le modèle reçoit de passages, plus il a de chances de s’appuyer sur le mauvais. Un top-k fixé à huit ou dix passages « au cas où » remplit le contexte de bruit : le passage pertinent est noyé parmi des passages voisins, similaires ou hors sujet, et le LLM n’a aucun moyen fiable de départager. Il compose alors une réponse qui mélange deux sujets, ou qui s’appuie sur un passage secondaire au détriment du passage décisif. Au passage, ce contexte surchargé coûte aussi plus cher à chaque requête.

La correction passe par trois gestes. Réduisez le nombre de passages transmis au modèle, en ne gardant que l’essentiel. Ajoutez une étape de re-ranking, avec Cohere Rerank par exemple, qui réordonne les résultats par pertinence avant la génération. Et filtrez par métadonnées : type de document, date, langue, périmètre. Un passage hors périmètre écarté avant d’atteindre le contexte ne peut plus faire de dégât.

Des documents qui se contredisent, sans règle de priorité

Deux versions d’une même procédure, un tarif mis à jour et l’ancien encore dans l’index, une brochure générale et une note de service plus récente : le RAG remonte les passages concurrents et le modèle tranche au hasard, souvent selon l’ordre de l’index plutôt que vers la version la plus à jour. Symptôme : la réponse change selon les jours, ou donne une information périmée avec la même assurance que la bonne.

La cause est l’absence de gestion des versions et de métadonnées de date. Le correctif : dater chaque document à l’indexation, utiliser cette date dans la recherche pour filtrer ou pondérer, retirer de l’index ce qui est remplacé, et définir une règle de priorité explicite, par exemple « la version la plus récente fait foi ». Une règle simple et appliquée systématiquement vaut mieux qu’un modèle qui doit deviner quelle source domine. Pour organiser ce cycle de vie, voyez garder des réponses à jour quand les sources changent.

Des réponses sans source

L’erreur suivante est la plus dangereuse en termes de confiance : l’agent répond sans citer ses sources. On obtient une réponse plausible, sans savoir d’où elle vient, sans pouvoir la vérifier, sans pouvoir la corriger quand elle est fausse.

Un RAG qui ne cite pas ses sources est une boîte noire. En production, c’est intenable, parce que chaque erreur devient une crise de confiance : l’utilisateur ne peut pas distinguer une réponse sourcée d’une réponse inventée, et finit par douter de tout, y compris des réponses justes.

La règle est simple : chaque réponse doit être traçable, reliée au document et au passage dont elle est tirée. Cela permet de vérifier, de corriger, et surtout de répondre « je ne sais pas » quand la source manque, plutôt que d’inventer. La traçabilité n’est pas une fonctionnalité, c’est la condition de la confiance.

Une réponse jamais vérifiée contre sa source

Citer une source ne suffit pas. Un LLM peut générer une phrase grammaticalement parfaite, appuyée sur un passage bien retrouvé, et pourtant infidèle : elle avance un chiffre absent de la source, généralise un cas particulier, ou conclut ce que le passage ne dit pas. Sans étape de vérification, cette réponse part en production, fluide et crédible, et l’erreur est repérée par l’utilisateur, pas par vous.

Le correctif est une vérification de fidélité avant l’envoi : un second appel au modèle liste les affirmations de la réponse, puis vérifie chacune contre les passages retrouvés. Des bibliothèques comme Ragas ou DeepEval fournissent ce type de métrique de fidélité. Ce n’est pas infaillible, mais cela détecte les réponses décrochées et permet d’afficher une mention « réponse partiellement étayée » au lieu de livrer une erreur avec assurance. Couplée à une relecture humaine régulière d’un échantillon de conversations, cette vérification transforme un bug silencieux en problème visible et corrigeable.

Des coûts non maîtrisés

Une erreur se voit sur la facture plutôt que dans les réponses. Des prompts trop longs, des appels redondants, un contexte surchargé, un modèle trop gros pour la tâche : les coûts dérivent vite, et souvent sans qu’on le voie venir, parce qu’on n’a pas mesuré le coût par requête dès le départ.

Le coût d’un RAG se joue à plusieurs endroits : la taille du contexte envoyé au modèle, le nombre d’appels successifs (dont la vérification de fidélité), le choix du modèle, le volume de documents indexés et la fréquence de réindexation. Chacun de ces paramètres se budgète, et les mauvaises surprises viennent toujours de celui qu’on n’a pas regardé.

La bonne pratique est de mesurer le coût par requête dès le prototype, de le suivre en continu dans un outil comme Langfuse, et de traiter toute dérive comme un signal d’alerte. Un RAG dont le coût explose n’est pas rentable, même s’il répond bien.

Aucune évaluation en conditions réelles

La dernière erreur est méthodologique, et c’est elle qui laisse passer toutes les autres : on teste le RAG avec trois questions inventées, on regarde deux réponses qui semblent bonnes, et on part en production sans avoir jamais rien mesuré. Les démos passent, les usages réels échouent : les vraies questions sont plus longues, plus ambiguës, elles mélangent plusieurs sujets et emploient un jargon que le jeu de test ne contenait pas.

Le correctif tient en deux étapes. Construisez un jeu de référence d’une trentaine de questions relevées dans les demandes réelles, avec pour chacune la réponse attendue et les passages qui devraient être retrouvés ; la méthode est détaillée dans construire un jeu de test représentatif. Puis relancez ce jeu à chaque modification du pipeline, par exemple avec Promptfoo dans la CI, et suivez en production la proportion de questions reformulées par l’utilisateur, qui signale presque toujours une réponse insatisfaisante. Sans ces mesures, vous corrigez un RAG à l’aveugle ; avec elles, chaque correctif se valide par une différence mesurable.

Ce qu’on surveille avant de déployer

Quatre chiffres résument la santé d’un RAG : le taux de réponses sourcées, le taux d’hallucination par catégorie de question, la latence, et le coût par requête. Le premier dit si les réponses sont vérifiables, le deuxième si elles sont fiables là où ça compte, le troisième si l’expérience est acceptable, le quatrième si l’économie tient.

Ces chiffres ne demandent pas un outillage lourd. Ils demandent une discipline : les mesurer dès le prototype, les suivre en continu, et refuser de déployer tant qu’ils ne sont pas au niveau attendu. Quand un chiffre se dégrade, le parcours des erreurs ci-dessus donne l’ordre de diagnostic : sources, découpage, recherche, contexte, versions, vérification.

Un RAG qui tient la production

Aucune de ces erreurs n’exige un modèle plus puissant. Elles se corrigent avec de la méthode, et presque toujours dans le même ordre : d’abord les sources et le découpage, ensuite la recherche et le contexte, puis la traçabilité et la vérification, avec des mesures à chaque étape. Si vos documents contiennent des données sensibles, ajoutez un critère dès le départ : où sont hébergés l’index et le modèle, un sujet traité sur la page IA souveraine.

C’est la démarche qu’on applique quand on construit ou reprend un assistant RAG sur vos documents internes : on commence par les sources, on pose le jeu d’évaluation avant d’optimiser quoi que ce soit, et on ne met en production que ce qu’on peut piloter avec des chiffres.