Publié le 6 octobre 2026
La plupart des systèmes RAG fonctionnent correctement en démonstration, puis déçoivent discrètement en production. Le schéma est familier : une preuve de concept répond bien à une poignée de questions de test, obtient le feu vert, est mise en ligne, puis trois semaines plus tard, quelqu’un remarque que le système cite avec assurance le mauvais article de politique ou passe à côté d’un document pourtant clairement pertinent. Le modèle n’est généralement pas le problème. C’est le pipeline qui lui fournit le contexte.
La génération augmentée par récupération semble simple sur un tableau blanc — intégrer les documents, stocker les vecteurs, récupérer les correspondances les plus proches, les transmettre au modèle. En pratique, presque chaque étape de cette chaîne comporte un mode de défaillance qui n’apparaît qu’au contact de vrais documents et de vraies requêtes. Voici où cela se passe réellement mal, et à quoi ressemble la correction.
La stratégie de découpage est généralement la première erreur
Le découpage à taille fixe — séparer les documents tous les 500 ou 1000 caractères, quelle que soit leur structure — est la méthode par défaut dans la plupart des tutoriels et la première à casser sur du contenu réel. Une clause de contrat, une ligne de tableau ou une étape de procédure est coupée en deux, et le moteur de récupération se retrouve avec deux segments qui, pris isolément, n’ont aucun sens. Le modèle invente alors soit un lien entre des fragments sans rapport, soit répond à partir d’un contexte incomplet sans signaler qu’il est incomplet.
La solution consiste à découper en respectant la structure du document — en s’appuyant sur les titres, les paragraphes, les limites des tableaux ou les unités sémantiques plutôt que sur un simple nombre de caractères — et cela doit être fait par type de document plutôt qu’au moyen d’une règle globale. Un manuel technique, un contrat juridique et un fil de tickets d’assistance n’ont pas les mêmes unités naturelles, et une stratégie de découpage conçue pour l’un dégradera discrètement les autres.
Incompatibilité du modèle d’embeddings
Les équipes choisissent souvent un modèle d’embeddings en se basant sur un classement de référence générique, puis ne revoient jamais ce choix une fois en production. Les modèles d’embeddings varient fortement dans leur capacité à capturer le sens propre à un domaine — un modèle entraîné sur du texte web général peut ne pas distinguer des termes techniques très proches dans un domaine spécialisé, ce qui signifie que des requêtes censées retrouver des documents distincts aboutissent à des scores de similarité quasiment identiques pour les deux.
Cela compte bien plus dans les domaines techniques ou réglementaires denses que dans les cas d’usage de bases de connaissances générales, et il vaut la peine de tester les modèles d’embeddings sur votre ensemble de documents réel et vos schémas de requêtes avant de vous engager, pas seulement sur un benchmark public. Un modèle médiocre sur les benchmarks de récupération généraux peut surpasser le leader du classement sur votre corpus spécifique, et la seule façon de le savoir est de tester les deux à partir de vraies requêtes de votre domaine.
Profondeur de récupération : trop peu ou trop de segments
Récupérer trop peu de segments prive le modèle du contexte dont il a besoin ; en récupérer trop noie le passage pertinent dans le bruit et augmente le risque que le modèle s’accroche à un segment sans rapport, mais superficiellement similaire. Il n’existe pas de bon nombre universel — cela dépend de la taille des segments, de la densité des documents et de la fréquence à laquelle une bonne réponse exige réellement de synthétiser plusieurs sources plutôt qu’un seul passage clair — mais la plupart des systèmes adoptent un top-k fixe sans jamais vérifier si ce nombre sert réellement la distribution de requêtes qu’ils rencontrent en pratique.
Une approche plus fiable consiste à faire varier la profondeur de récupération en fonction d’un seuil de score de pertinence plutôt qu’en fonction d’un nombre fixe, puis à revoir régulièrement les requêtes pour lesquelles le système a récupéré avec assurance mais a répondu à tort — ce profil d’échec pointe généralement directement vers un problème de profondeur de récupération ou de découpage plutôt que vers un problème de génération.
Pas d’ensemble d’évaluation, donc aucun moyen de savoir que tout est cassé
C’est le piège à l’origine de la plupart des autres : les équipes déploient des systèmes RAG sans ensemble réservé de requêtes représentatives et de réponses exactes connues pour les tester, ce qui rend les régressions invisibles jusqu’à ce qu’un utilisateur se plaigne. Sans ensemble d’évaluation, chaque modification de la stratégie de découpage, du modèle d’embeddings ou du modèle de prompt relève de l’hypothèse plutôt que d’une amélioration mesurée, et il est impossible de savoir si une « correction » a réellement aidé ou si elle a simplement déplacé le mode d’échec ailleurs.
Constituer même un ensemble d’évaluation modeste — cinquante à quelques centaines de paires requête-réponse représentatives issues de l’usage réel ou de l’examen d’experts métier — avant de faire passer un système RAG du stade pilote à l’échelle, est rentabilisé presque immédiatement, car cela transforme chaque décision d’ajustement ultérieure d’une supposition en mesure.
Contenu source obsolète ou dupliqué
Les bases de connaissances évoluent. Les politiques sont mises à jour, les anciennes versions ne sont pas supprimées de l’index, et le moteur de récupération n’a aucun moyen de savoir quelle version est la bonne — il renvoie simplement le segment dont le score de similarité est le plus élevé, ce qui correspond parfois à la version obsolète. Il s’agit moins d’un problème de modélisation que d’un problème de cycle de vie du contenu, et il s’aggrave à mesure qu’un système RAG fonctionne sans processus défini de réindexation, de déduplication et de mise hors service des documents sources obsolètes.
Les systèmes conçus pour la recherche de connaissances en entreprise nécessitent un pipeline de contenu explicite — pas seulement une tâche initiale d’ingestion — qui gère les versions et retire du moteur les documents obsolètes selon un calendrier défini ; sinon, la qualité de la recherche se dégrade silencieusement à mesure que la base de connaissances sous-jacente vieillit.
Ignorer le cas « aucune bonne réponse »
Un système RAG confronté à une question sans bonne réponse dans sa base de connaissances récupérera quand même les segments les plus proches disponibles, et le modèle générera souvent malgré tout une réponse qui semble assurée à partir de ceux-ci, car rien dans l’architecture ne l’oblige à reconnaître que le contexte récupéré ne répond pas réellement à la question. C’est l’un des modes de défaillance les plus dommageables, car il ressemble à s’y méprendre à une réponse correcte jusqu’à ce qu’une personne vérifie la source.
Bien gérer ce cas exige une vérification explicite de confiance ou de pertinence entre la recherche et la génération — une étape qui évalue si les segments récupérés sont réellement assez pertinents pour répondre à la requête avant de les transmettre au modèle, et qui oriente vers une réponse du type « Je n’ai pas assez d’informations » plutôt que de forcer une réponse lorsqu’ils ne le sont pas.
Traiter RAG comme une réalisation ponctuelle au lieu d’un système entretenu
Les écueils ci-dessus ont une cause commune : considérer l’implémentation RAG comme un projet avec une ligne d’arrivée, plutôt que comme un système qui nécessite un réglage continu à mesure que l’ensemble documentaire, les schémas de requêtes et les modèles sous-jacents évoluent. Les modèles d’embedding s’améliorent, les volumes documentaires augmentent, les habitudes de requête des utilisateurs changent avec l’adoption — un système RAG calibré une seule fois au lancement et jamais réévalué se dégradera avec le temps, même si rien dans l’implémentation n’était incorrect le premier jour.
Les équipes qui tirent la valeur la plus durable de RAG l’abordent comme elles le feraient pour tout système en production, avec des cycles de supervision et d’itération — réexécutions périodiques des évaluations, contrôles ponctuels de la qualité de la recherche liés aux retours réels des utilisateurs, et processus défini de réindexation lorsque le contenu source évolue — plutôt que comme une intégration unique censée continuer à fonctionner indéfiniment sans attention.
Par où commencer pour corriger un système sous-performant
Si un système RAG déjà en production sous-performe, la première étape la plus rentable consiste presque toujours à construire l’ensemble d’évaluation qui aurait dû exister dès le départ, car c’est le seul moyen de diagnostiquer lequel des écueils ci-dessus est réellement en cause plutôt que de supposer. À partir de là, la stratégie de découpage et la profondeur de recherche tendent à produire les gains les plus importants au regard de l’effort, les changements de modèle d’embedding et les correctifs du cycle de vie du contenu venant ensuite, une fois la mesure en place pour confirmer qu’ils apportent un bénéfice.
Si vous définissez un nouveau projet RAG ou cherchez à comprendre pourquoi un système existant sous-performe, lancez une conversation projet et nous examinerons ensemble où votre implémentation perd probablement en qualité de recherche.
Lié