Patterns RAG avancés en entreprise : ce qui sépare une démo d'un système qui tient

Un RAG naïf donne une démonstration convaincante et un système décevant, sans jamais tomber en panne : il répond, avec le mauvais extrait, et personne ne s'en aperçoit. Voici les cinq patterns qui font la différence en production, ainsi que l'ordre dans lequel il faut les poser.

Par QDNA · Publié le 28 août 2026 · 11 min de lecture

Pourquoi le RAG naïf déçoit après la démo

Le schéma de base fonctionne remarquablement bien sur une centaine de documents homogènes, et se dégrade dès qu'on approche du corpus réel. Trois causes, dans cet ordre de fréquence.

Le découpage perd le référent. Un fragment qui commence par « ce dispositif ne s'applique pas aux contrats antérieurs » demeure inexploitable, puisque « ce dispositif » désignait quelque chose situé deux pages plus haut. Le fragment reste alors syntaxiquement correct et sémantiquement proche de la question tout en étant factuellement inutilisable, ce qui en fait la défaillance la plus fréquente et la plus difficile à repérer.

La similarité n'est pas la pertinence. Un vecteur mesure une proximité de sujet, si bien qu'une question portant sur une exception fera d'abord remonter le paragraphe qui énonce la règle, lequel traite du même sujet avec davantage d'insistance. Le modèle répondra donc la règle, et il la répondra avec assurance.

Le corpus contient des versions concurrentes. Une procédure de 2023, sa révision de 2025 et un brouillon jamais validé se ressemblent tellement dans l'espace vectoriel que, faute de métadonnée de version, le système en choisit une au hasard sans que l'utilisateur dispose du moindre moyen de s'en apercevoir.

Ces trois défaillances partagent une propriété qui explique leur longévité en production : le système répond toujours, puisqu'au lieu de renvoyer une erreur il renvoie une réponse fausse et plausible que rien ne signale.

Pattern 1 : Découper en gardant le contexte

Le découpage par taille fixe est le réglage par défaut de toutes les bibliothèques, et la première chose à remplacer.

Trois mesures, qui se cumulent sans se contredire, traitent la perte de référent constatée au découpage.

• Découper sur la structure plutôt que sur un nombre de caractères : par section, par article, par cellule de tableau. Un document a déjà des frontières sémantiques, elles sont dans son plan.
• Préfixer chaque fragment de son chemin : titre du document, chapitre, section. Le fragment cité plus haut devient « Convention collective X › Article 12 › Champ d'application : ce dispositif ne s'applique pas… ». Le coût est de quelques dizaines de tokens par fragment ; le gain est qu'il devient interprétable seul.
• Indexer aussi les phrases isolées quand le corpus contient des faits ponctuels. Une information énoncée en incise dans un paragraphe portant sur autre chose est noyée si l'on n'indexe que des blocs : le vecteur du bloc est dominé par le sujet principal, pas par l'incise.

Ces trois mesures ne relèvent pas de l'intuition, et leur effet a été chiffré. Anthropic a publié le gain qu'apporte le fait de préfixer chaque fragment de son contexte avant de le vectoriser, mesuré sur un taux d'échec de récupération dans les vingt premiers fragments : les seuls plongements contextualisés font passer ce taux de 5,7 % à 3,7 %, soit une réduction de 35 %, et leur combinaison avec un BM25 contextualisé le ramène à 2,9 %, soit 49 %. Le contexte ajouté représente 50 à 100 tokens par fragment, pour un coût de génération de 1,02 dollar par million de tokens de document.

Source : Anthropic, Contextual Retrieval. Les taux portent sur leur jeu d'évaluation et non sur votre corpus, ce qui est précisément l'objet du cinquième pattern.

Pattern 2 : Filtrer par habilitation avant de scorer

C'est le pattern le plus important pour un déploiement d'entreprise, et celui que les tutoriels omettent parce qu'il n'existe pas dans un jeu de démonstration.

La tentation consiste à récupérer les extraits les mieux classés, puis à écarter ceux que l'utilisateur n'a pas le droit de consulter, ce qui constitue un défaut de conception à deux titres. D'abord, le nombre d'extraits restants devient imprévisible : si les huit meilleurs sont filtrés, il ne reste rien pour répondre. Ensuite, et surtout, la latence du système varie selon le contenu écarté, ce qui suffit à révéler l'existence de documents à quelqu'un qui n'y a pas accès.

Le filtre d'habilitation doit donc s'appliquer dans la requête à l'index, comme une contrainte, avant le calcul de similarité. En pratique cela suppose que chaque fragment porte les métadonnées d'accès de son document source, et que ces métadonnées soient mises à jour quand les droits changent, un point que la plupart des projets découvrent tard.

Le corollaire est traité dans notre article sur les données sensibles : supprimer un document source ne purge pas ses vecteurs, et un droit retiré ne se propage pas davantage de lui-même vers l'index.

Pattern 3 : Décomposer les questions à plusieurs sauts

Une question telle que « quelle est la durée de préavis pour un cadre embauché après la révision de 2025 ? » réclame trois informations qui ne cohabitent dans aucun paragraphe, la date de la révision, le statut cadre et la grille de préavis, si bien qu'une recherche unique ne peut pas les rapporter ensemble.

Le pattern consiste à faire produire par le modèle, avant toute recherche, la liste des sous-questions à résoudre, puis à exécuter une recherche par sous-question et à assembler. C'est plus lent et plus coûteux, ce qui impose de ne l'activer que sur les questions qui le méritent, un classifieur en amont, comme celui décrit dans le moteur d'orchestration, suffit à faire ce tri.

Une mise en garde utile : la reformulation systématique de la question avant recherche est souvent présentée comme un gain automatique. Elle ne l'est pas. Sur un corpus dont le vocabulaire est très proche de celui des utilisateurs, réécrire la question l'éloigne des documents. Les techniques d'expansion de requête doivent être mesurées sur votre corpus avant d'être adoptées ; plusieurs d'entre elles dégradent le rappel dans des contextes où la littérature les donne gagnantes.

Pattern 4 : Retrouver petit, rendre large

Les deux besoins du système entrent ici en tension, puisque la recherche gagne en précision sur de petits fragments alors que la génération produit de meilleures réponses lorsqu'elle dispose d'un contexte étendu.

Le pattern qui résout cette tension consiste à dissocier l'unité indexée de l'unité transmise : on indexe des fragments courts et discriminants, puis, lorsque l'un d'eux ressort, on transmet au modèle le bloc parent auquel il appartient, qu'il s'agisse de la section entière, du document court ou des paragraphes voisins.

La troisième ligne du tableau n'a rien de cosmétique, car un système qui cite ses sources de façon vérifiable transforme la nature même de l'erreur : l'utilisateur constate que l'extrait ne dit pas ce que la réponse affirme, alors que sans citation la même erreur reste indétectable.

La même mesure chiffre l'apport du reclassement : ajouté aux plongements contextualisés et au BM25, il fait tomber le taux d'échec de 5,7 % à 1,9 %, soit une réduction de 67 %. La source note également que transmettre les vingt premiers fragments donne de meilleurs résultats que les cinq ou les dix premiers, ce qui va contre l'intuition d'économiser du contexte.

Sur la dissociation entre unité indexée et unité transmise, voir aussi H-RAG, SemEval-2026 Task 8, qui décrit un pipeline hiérarchique parent-enfant séparant la recherche fine du contexte transmis.

Pattern 5 : Mesurer le rappel avant la qualité

Ce cinquième pattern conditionne les quatre précédents, et c'est aussi celui qui manque le plus souvent aux systèmes déployés.

La tentation est d'évaluer le système de bout en bout : on pose des questions, on juge les réponses. Le problème est que ce chiffre unique agrège deux causes indépendantes, le bon extrait n'a pas été retrouvé, ou il a été retrouvé et mal exploité. Ces deux défaillances appellent des correctifs opposés, et un score global ne permet pas de savoir laquelle des deux vous affecte.

La mesure qui sert à décider se conduit en deux temps distincts, dont l'ordre importe.

1. Le rappel de la recherche : sur un jeu de questions dont vous connaissez le passage attendu, dans quelle proportion ce passage figure-t-il parmi les extraits remontés ? C'est un chiffre objectif, qui ne dépend d'aucun modèle de génération, et qui borne tout le reste. Si le rappel est de 60 %, aucune amélioration du prompt ne fera mieux que 60 %.
2. La qualité de la réponse à extraits donnés : en fournissant délibérément le bon passage, le modèle répond-il correctement ? Si oui, votre problème est la recherche ; si non, il est dans la génération ou le format du contexte.

Constituer le jeu de questions annotées reste le travail ingrat qui rend tout le reste possible, alors que cent questions accompagnées de leur passage attendu suffisent à distinguer une amélioration réelle d'une impression, ce qu'aucune démonstration ne permettra jamais d'établir.

Ce que ces patterns ne règlent pas

Trois limites méritent d'être posées, parce qu'elles conduisent souvent à empiler des patterns là où le problème est ailleurs.

Un corpus contradictoire le reste après indexation. Si trois documents également valides donnent trois réponses différentes, aucune technique de recherche ne tranchera à leur place, et le système devrait alors signaler le désaccord plutôt que de choisir, comportement qui se code explicitement et suppose donc d'avoir été décidé.

Les questions agrégatives ne relèvent pas du RAG. Une question telle que « combien de contrats arrivent à échéance ce trimestre ? » réclame un décompte sur l'ensemble du corpus et non la récupération de quelques extraits, ce qui en fait une requête sur données structurées : extraire l'information vers une base puis interroger celle-ci coûte moins cher et donne un résultat juste.

Le RAG ne remplace pas la gouvernance documentaire. Indexer un corpus mal tenu produit un système qui répond avec autorité à partir de documents périmés, ce qui fait de la qualité du corpus la variable dominante, bien avant tout raffinement technique de la recherche.

Par où commencer

L'ordre de mise en œuvre qui évite les impasses commence par la mesure et non par les patterns, contrairement à l'intuition.

1. Constituer cinquante à cent questions annotées avec leur passage attendu. Sans ce jeu, tout ce qui suit est de l'intuition.
2. Mesurer le rappel du système actuel. Le chiffre est presque toujours plus bas que ce que l'équipe estimait.
3. Corriger le découpage, c'est le levier au meilleur rapport effort/gain, et celui qui explique le plus souvent un rappel médiocre.
4. Poser le filtre d'habilitation dans la requête, avant d'ajouter quoi que ce soit d'autre. Le rattraper plus tard suppose de réindexer.
5. Ajouter décomposition et bloc parent seulement si la mesure montre qu'ils apportent quelque chose sur votre corpus.

Le cadre général du pipeline, du découpage à la recherche hybride, est posé dans notre guide du RAG en entreprise. Pour servir l'ensemble sur votre infrastructure, voir vLLM et la matrice de dimensionnement, ou un échange pour cadrer le premier jalon.