RAG en entreprise : par où commencer

Un RAG impressionne toujours à la démo : on pose une question, il répond en citant vos documents, la salle est convaincue. Trois semaines plus tard en production, il cite le mauvais paragraphe, mélange deux versions d'une même procédure, ou répond à côté sur une question que tout le monde pose. Le modèle n'a pas changé entre-temps. Ce qui a changé, c'est qu'on lui pose de vraies questions sur de vrais documents, et que la partie invisible du système, la récupération, n'a pas reçu le même soin que la partie qui rédige. La plupart des RAG qui déraillent se sont trompés d'ordre de priorité. Voici comment j'en monte un qui tient, étape par étape, dans l'ordre où je les traite.

Par où commencer un projet RAG sans se tromper ?

Par les données, pas par le modèle. Le principe d'un RAG tient en deux temps : je récupère les passages pertinents dans vos documents, puis je demande au modèle de répondre à partir de ces passages, sources à l'appui. Dans 70 à 90 % des cas, la qualité de la réponse se joue sur ce premier temps, la récupération, pas sur le modèle qui rédige. C'est contre-intuitif, parce que le modèle est la partie visible et spectaculaire. Mais un modèle brillant nourri de mauvais passages produit une réponse fausse et bien tournée, ce qui est pire qu'une erreur visible. On commence donc par le corpus : l'état de préparation de vos données pèse déjà lourd dans le résultat, avant même d'avoir choisi un modèle.

Pourquoi nettoyer les documents avant de brancher le modèle ?

Parce qu'un corpus sale produit des réponses fausses énoncées avec aplomb. Le modèle ne fait pas le tri : il répond à partir de ce qu'on lui sert, sans se demander si la source est à jour ou fiable. Si vos documents contiennent trois versions d'une procédure sans aucune date, il piochera dans la mauvaise sans le signaler, et c'est exactement le terrain qui le fait répondre avec assurance à côté de la plaque. Avant toute chose, je trie, je dédoublonne et je date. C'est le travail le plus ingrat du projet, celui que tout le monde veut sauter, et c'est celui qui décide de la fiabilité finale.

• Sortir les doublons et les versions périmées, ou les dater pour que le système sache laquelle fait foi.
• Extraire proprement le texte des PDF, des scans et des tableaux, puis vérifier ce qui en sort.
• Rattacher à chaque document ses métadonnées : source, date, service, niveau de confidentialité.
• Décider qui a le droit de voir quoi, avant que le système ne remonte à un utilisateur un passage qu'il ne devrait pas lire.

Comment bien découper les documents ?

En respectant les unités logiques, pas en coupant tous les 500 caractères. Un RAG ne récupère pas des documents entiers, il récupère des morceaux, des chunks, et c'est un morceau qu'il donnera au modèle. Si vous coupez au hasard, une idée commence dans un chunk et se termine dans le suivant : chaque passage devient à moitié compréhensible, et le modèle reçoit des bouts mutilés qu'il complète à sa façon. Je découpe par unité qui garde son sens toute seule : une section, un paragraphe, une procédure, une clause. Un tableau reste avec son titre, une étape reste avec son contexte. Ça dépend de vos documents, ça n'a rien d'automatique par défaut, et c'est souvent là qu'on gagne le plus de qualité pour le moins d'effort.

Comment récupérer les bons passages ?

C'est le cœur du système, et une seule technique suffit rarement. La recherche par le sens (les embeddings) retrouve un passage même quand la question n'emploie pas les mêmes mots que le document. Elle a un angle mort : les références exactes, un numéro de contrat, un code produit, un sigle interne, que la recherche par mots-clés retrouve, elle, sans effort. Les combiner donne ce qu'on appelle une recherche hybride, et c'est souvent le bon réglage par défaut. Ensuite, on reclasse les passages récupérés pour remonter les plus pertinents en tête, on filtre par métadonnée quand la question porte sur une période ou un service précis, et on impose que chaque réponse cite ses sources. Un RAG qu'on ne peut pas vérifier ne vaut pas beaucoup mieux qu'un modèle seul.

• Recherche par le sens : retrouve les passages proches de l'intention, même formulés autrement.
• Recherche par mots-clés : rattrape les références exactes que le sens seul laisse passer.
• Reclassement (reranking) : remonte en tête les passages vraiment pertinents parmi ceux récupérés.
• Filtres par métadonnée et citation des sources : cadrer la recherche, et rendre chaque réponse vérifiable.

Comment savoir si le RAG répond juste ?

En le testant sur de vraies questions métier, pas sur les trois exemples de la démo. Je constitue un jeu de questions que vos équipes posent réellement, avec la bonne réponse et le bon document source, puis je mesure deux choses séparément : est-ce que le système a récupéré le bon passage, et est-ce que le modèle a bien répondu à partir de lui. Cette distinction dit où corriger et évite de perdre des jours à réécrire un prompt quand le problème est ailleurs. Le plus souvent, il est en amont : j'itère alors sur l'indexation, pas sur le prompt. Et parce qu'un corpus vit, mesurer le RAG en continu est ce qui l'empêche de dériver en silence après une mise à jour de vos documents. Quand une réponse déraille, je remonte la chaîne dans cet ordre :

• Le bon passage a-t-il seulement été récupéré ? Sinon, le problème est dans le découpage ou la recherche, jamais dans le prompt.
• Le passage était-il compréhensible seul, ou coupé en plein milieu ? S'il est mutilé, c'est le découpage.
• Le document source était-il à jour ? Sinon, c'est le corpus qu'il faut nettoyer.
• Le modèle avait le bon passage et a quand même dévié ? Là, et seulement là, on touche au prompt ou au modèle.

Faut-il toujours un RAG ?

Non, et la question se tranche avant de commencer, pas après six semaines de développement. Le RAG est le bon outil quand la connaissance vit dans des documents qui changent, qu'il faut citer, et qu'on veut mettre à jour sans rien réentraîner. Pour apprendre un style, un format de sortie ou un raisonnement métier récurrent, ce n'en est pas un, et le match entre RAG et fine-tuning mérite d'être posé noir sur blanc plutôt que tranché par habitude. Quand le RAG est le bon choix, je démarre étroit : un seul corpus, celui que vos équipes consultent le plus, propre et bien découpé. Un périmètre restreint qui répond juste vaut mieux qu'un gros volume qui répond à moitié.

Un LLM ne corrige pas une mauvaise récupération. Il la met en forme, et la rend crédible.

Un RAG, ce n'est pas un modèle branché sur des documents. C'est une chaîne : préparer le corpus, le découper juste, récupérer les bons passages, citer, mesurer. Le modèle est la dernière pièce, et presque toujours la plus simple. Si le vôtre impressionne à la démo et déçoit en production, le point de blocage est presque sûrement en amont du modèle, dans une de ces étapes qu'on a voulu expédier. C'est exactement le genre de chantier que je reprends : parlons-en.