Pipeline RAG : de vos documents à la réponse fiable

Un pipeline RAG (Retrieval-Augmented Generation, la technique où l'IA récupère d'abord les bons passages de vos documents, puis rédige à partir d'eux) est la chaîne de traitement qui transforme vos documents en réponses fiables et sourcées : ingestion, découpage, vectorisation, recherche, reranking, puis génération d'une réponse qui cite ses passages d'origine. Chaque maillon conditionne le suivant, et une seule étape négligée dégrade toutes les réponses. Surtout, la valeur d'un RAG ne se joue pas uniquement dans ces étapes : elle se joue dans ce qui les entoure une fois le système en production, la mise à jour des sources, la supervision et l'évaluation continue. Ce guide détaille la chaîne complète, puis ce que la production exige en plus, à partir d'une plateforme que j'ai livrée et qui tourne aujourd'hui chez un client réel. Si la notion même de RAG vous est nouvelle, commencez par les fondamentaux du RAG, puis revenez ici pour la mécanique.

Les six étapes du pipeline RAG, dans l'ordre d'exécution

1. L'ingestion : collecter et nettoyer les sources

En production, un pipeline hérite rarement d'un corpus propre : la connaissance d'une entreprise est éparpillée entre un site, des PDF, une base produit, parfois un outil de tickets. L'ingestion extrait le texte de ces formats hétérogènes, le nettoie de tout ce qui parasiterait la recherche (en-têtes répétés, menus de navigation, tableaux mal convertis) et le normalise dans un format unique. Le travail est ingrat et décisif à la fois : un document mal extrait produit des passages illisibles, donc des réponses fausses, quelle que soit la sophistication du reste de la chaîne.

2. Le découpage : là où se joue la précision

Les documents nettoyés sont ensuite découpés en passages courts. Cette étape porte un nom, le chunking : la manière de segmenter un document avant indexation, qui détermine ce que la recherche pourra retrouver ensuite. Un bon découpage épouse la structure du contenu (une fiche produit, une clause, une section de procédure) pour que chaque passage se comprenne seul. Un découpage arbitraire, tous les 500 mots par exemple, coupe une information en deux et la rend introuvable. C'est l'étape la plus sous-estimée des projets RAG, et l'une de celles qui pèsent le plus sur la qualité perçue.

3. La vectorisation : indexer le sens

Chaque passage est ensuite converti en embeddings : de longues séries de chiffres qui capturent ce que le texte veut dire, et sur lesquelles la machine peut mesurer à quel point deux passages se rapprochent sur le fond. Ces vecteurs sont rangés dans un index spécialisé, par exemple avec pgvector, une extension qui dote la base de données PostgreSQL d'un stockage pour ces vecteurs et d'une comparaison très rapide entre eux. À ce stade, vos documents sont devenus interrogeables par le sens, plus seulement par les mots.

4. La recherche : ramener les bons candidats

À chaque question d'un utilisateur, le système interroge cet index. Le standard en production est la recherche hybride, qui combine la recherche par le sens et la recherche par mots-clés exacts : la première comprend les reformulations et les synonymes, la seconde ne rate ni une référence produit ni un nom propre. Cette étape ramène une liste volontairement large de passages candidats, charge aux suivantes de trier.

5. Le reranking : le second tri qui fait la différence

Sur ces candidats intervient le reranking : un modèle dédié à ce seul exercice note la pertinence réelle de chaque passage vis-à-vis de la question posée, puis réordonne la liste pour que seuls les extraits vraiment utiles partent vers la génération. L'étape est invisible pour l'utilisateur, mais c'est souvent elle qui sépare un système correct d'un système précis.

6. La génération sourcée : rédiger sous contrainte

Le LLM, le grand modèle de langage chargé de comprendre la question et de formuler la réponse finale, n'intervient qu'en bout de chaîne. Il reçoit la question, les passages retenus et un prompt, les instructions qui cadrent sa réponse : ne rien affirmer qui ne figure pas dans les extraits reçus, indiquer d'où vient chaque élément de réponse, signaler franchement les questions auxquelles le corpus ne répond pas. Sans ce cadre, le modèle retombe dans son défaut naturel, l'hallucination : il comble les trous de sa connaissance en fabriquant une réponse crédible, sans que rien dans sa formulation ne trahisse l'invention.

Prototype ou production : le même schéma, pas le même système

Ces six étapes tiennent dans un prototype monté en quelques jours avec les outils actuels, et c'est précisément le piège. La démonstration impressionne en réunion, puis le système se dégrade en silence dès que les documents évoluent et que les vraies questions arrivent. Voici ce qui sépare les deux.

La suite détaille ces exigences sur un cas réel, celui qui m'a le plus appris sur la différence entre faire fonctionner un RAG et le faire tenir.

Ce qu'un RAG en production exige : le cas Labo M

La plateforme conversationnelle que j'ai livrée à Labo M permet aux clients de questionner, en langage courant, un catalogue de 72 000 références ainsi que des milliers de PDF, protocoles et fiches de sécurité en tête. Neuf requêtes sur dix (90 %) aboutissent sans qu'un humain intervienne. Ce chiffre ne sort pas du pipeline seul : il sort de tout ce qui l'entoure. Trois blocs le rendent possible, détaillés dans la fiche mission : ce qui tourne, ce qui se met à jour, ce qui se supervise.

Ce qui tourne : une orchestration autour du pipeline

En production, le pipeline ne reçoit pas des questions propres et isolées, il reçoit des conversations. La plateforme repose donc sur une orchestration : la coordination de plusieurs briques (IA, base de données, boutique) en un flux où chacune intervient au bon moment. Elle est confiée à n8n, un outil d'automatisation fair-code (code source public, gratuit en auto-hébergement pour un usage interne) qui relie les logiciels par des scénarios visuels. Douze workflows, ces scénarios automatisés faits d'un déclencheur puis d'actions, tournent en production, dont un workflow maître de 76 nœuds : un classifieur d'intention à 13 catégories qualifie chaque message, une mémoire incrémentale suit le fil de la conversation, et un agent outillé choisit entre recherche produit, recherche dans les PDF, panier ou mise en relation. La recherche hybride elle-même vit dans une fonction Postgres unique et versionnée, qui applique en amont un pré-filtre budget déterministe : quand le client annonce une enveloppe, aucun produit hors budget n'atteint le modèle.

Ce qui se met à jour : un index qui suit le catalogue

Un index figé commence à mentir au bout de quelques semaines. Ici, le catalogue vit dans la base MySQL de la boutique, et un flux nocturne le réindexe vers pgvector avec un remplacement atomique : le nouvel index se substitue à l'ancien d'un seul coup, sans jamais exposer un état intermédiaire où la moitié des produits daterait de la veille. Avant chaque vectorisation, les fiches produit sont enrichies par un LLM, pour que le passage indexé décrive réellement le produit et pas seulement sa référence. Cette exigence vaut pour tout corpus vivant : le moteur juridique que j'ai construit pour un acteur du conseil en droit social maintient de la même façon plus de 200 000 articles de conventions collectives alignés sur la source officielle.

Ce qui se supervise : chaque réponse laisse une trace

En production, « ça marche » ne suffit pas : il faut pouvoir expliquer pourquoi telle réponse a été donnée. La plateforme journalise chaque exécution à trois niveaux : la réponse complète, chaque étape du pipeline (durées, données échangées) et chaque passage candidat avec son score de recherche, son score de reranking et le verdict des juges. Une console d'administration déroule à nouveau n'importe quelle réponse, étape après étape, ce qui transforme une réclamation client en diagnostic précis plutôt qu'en mystère. Côté fiabilité, aucun produit n'est cité sans être passé devant un juge de pertinence qui écarte les candidats douteux : ce garde-fou, parmi d'autres, est détaillé dans le guide pour éviter les hallucinations de l'IA. Enfin, les instructions de l'agent et les seuils du pipeline sont pilotés en base de données, versionnés et audités : ils s'ajustent sans redéploiement. L'évaluation continue devient alors une boucle courte : observer les réponses réelles, ajuster un seuil ou une instruction, mesurer l'effet.

Ce qu'on vous vend quand on vous vend « un RAG »

Le mot recouvre deux réalités très différentes : un prototype qui déroule les six étapes sur un corpus figé, ou un système de production qui reste juste quand vos documents changent. Quatre questions suffisent à situer une offre. Comment l'index se met-il à jour quand mes documents évoluent, et à quelle fréquence ? Peut-on rejouer une réponse contestée et voir quel maillon a failli ? Qui ajuste les réglages après la mise en ligne, et faut-il redéployer pour le faire ? Qu'est-ce qui empêche concrètement le système de citer un document ou un produit qui n'existe pas ? Un prestataire qui a déjà exploité un RAG en production répond précisément à ces quatre questions. Un prestataire qui n'a construit que des prototypes répondra par des généralités.

C'est exactement le périmètre que je couvre en mission chatbot RAG, du pipeline à l'exploitation : le moteur de recherche, la couche conversationnelle et tout l'outillage de production décrit ici. Je suis Antoine Guerra, développeur IA freelance. Le premier échange est gratuit et sert à qualifier votre corpus et votre cas d'usage, et le devis arrive sous 48 h.