Pipeline RAG en production : les étapes qui comptent

Un pipeline RAG en production, c'est deux chaînes : l'ingestion (lire les documents, les découper, calculer les embeddings, tenir l'index à jour) et la réponse (retrouver les bons passages, générer une réponse citée, filtrer ce qui ne doit pas sortir). Autour, une évaluation chiffrée et une observabilité des traces disent si le système progresse ou régresse. Sans ces deux briques, impossible de savoir si une modification améliore ou dégrade les réponses.

Sur plus d'une dizaine de RAG construits, plus de cinq améliorés et plus de cinq audités, dont une dizaine en production aujourd'hui, les mauvais résultats viennent rarement du modèle de langage. Ils viennent d'un PDF mal lu, d'un passage coupé au mauvais endroit, d'un bug dans la chaîne de recherche. Cet article reprend chaque étape dans l'ordre du pipeline : ce qui casse en vrai, ce qu'on fait en production, ce qui n'a rien donné.

Le fonctionnement détaillé de chaque technique est traité côté praticien sur ianas.fr, avec des liens au fil de l'article. Ici, on parle de ce qu'il faut mettre en production et pourquoi.

Les étapes d'un pipeline RAG en production

Un pipeline RAG de production compte six étapes : parsing, chunking, embeddings et index, recherche, génération avec garde-fous, puis évaluation et observabilité. Les trois premières tournent à l'ingestion, en tâche de fond. Les suivantes tournent à chaque question, sous contrainte de temps de réponse.

Le tutoriel classique s'arrête à « découper, vectoriser, chercher les plus proches voisins, envoyer au LLM ». Ce pipeline répond, mais pas assez souvent juste. Un RAG basique répond correctement à environ 50 à 70 % des questions : assez pour une démo convaincante, pas assez pour qu'une équipe s'y fie.

Le tableau ci-dessous résume, pour chaque étape, ce qui casse le plus souvent sur les systèmes que je construis ou que j'audite, et ce qu'on met en place.

Ce découpage vaut quel que soit le corpus : procédures internes, documentation technique, conventions collectives, base de connaissances support. Les arbitrages, eux, changent d'un projet à l'autre. Pour le cadre général (cas d'usage, coûts, organisation), voir notre guide du RAG en entreprise.

Ingestion : parsing, chunking et mise à jour de l'index

L'ingestion d'un pipeline RAG transforme des fichiers hétérogènes en passages propres, retrouvables et à jour. C'est l'étape la moins visible et celle qui pèse le plus sur la qualité finale : un passage mal extrait ne sera jamais bien retrouvé, quel que soit le moteur de recherche qui suit.

Le parsing des PDF complexes

Un corpus bien organisé en docx s'exploite bien. Les difficultés arrivent avec les tableaux, les graphiques et les schémas, les documents faits uniquement de schémas, les doublons et certains PDF délicats (scannés, en plusieurs colonnes, avec des en-têtes répétés sur chaque page).

Ce qu'on fait : une extraction structurée qui produit du Markdown en conservant titres et tableaux (des outils comme Docling le font en open source), un OCR sur les pages scannées, et un modèle de vision sur les pages où la mise en page porte le sens. Pour un acteur du spatial, le découpage de PDF techniques complexes s'appuyait sur des modèles visuels qui repèrent les blocs de la page. Chez ModelRH, les documents passaient par l'OCR de Mistral avant tout traitement.

Le dédoublonnage se fait à l'ingestion, sur une empreinte du texte normalisé : trois versions quasi identiques d'une même procédure, c'est trois passages qui se disputent les premières places, dont deux périmés. Le détail des outils d'extraction est dans l'article sur le parsing de PDF pour un RAG, et le cas des images et tableaux dans notre article sur le RAG multimodal.

Le chunking : découper selon la structure

Le chunking découpe le texte en passages que la recherche pourra retrouver. Un découpage tous les N caractères coupe les procédures en deux et sépare un tableau de son titre. On découpe donc selon la structure du document (sections, articles, étapes), et on ajoute à chaque passage le chemin de titres dont il dépend : « Convention collective X > Congés > Ancienneté » change beaucoup de choses pour un passage qui commence par « Au-delà de 5 ans ».

Ce contexte ajouté au passage a été mesuré. Dans son étude publiée en septembre 2024, Anthropic indique que l'ajout d'un court contexte à chaque passage, combiné à une recherche par mots exacts, réduit de 49 % les échecs de recherche sur leurs jeux de test (de 67 % avec un reranking en plus). Ce chiffre vaut pour leurs corpus ; sur le vôtre, c'est le jeu de test qui tranche, y compris sur la taille des passages.

Embeddings, index et mises à jour

L'index doit suivre les documents. On garde pour chaque document un identifiant stable, sa source, sa date et une empreinte de son contenu. À chaque synchronisation, seuls les documents modifiés sont relus, leurs anciens passages sont supprimés, les documents retirés de la source disparaissent de l'index. Sur un RAG législatif livré pour le secteur public, cette mise à jour automatique de l'index était une exigence de départ : un texte abrogé qui continue de sortir, c'est une réponse fausse avec une source à l'appui.

Le changement de modèle d'embeddings est le seul cas qui impose une réindexation complète. On construit le nouvel index à côté, on relance l'évaluation dessus, puis on bascule. Le sujet est traité en détail dans notre article sur la maintenance d'un RAG en production.

Retrieval : les bugs d'abord, la recherche hybride ensuite

La recherche (retrieval) est l'étape où l'on trouve le plus de bugs en audit, et ce sont eux qui expliquent le plus de mauvaises réponses. Après les premières corrections, il est fréquent de passer de 30 % à 70 % de bonnes réponses, de 50 % à 70 %, ou de 20 % à 50 % sur des cas d'usage complexes, avant d'avoir ajouté la moindre technique avancée.

Trois bugs qu'on retrouve en audit

• Un modèle d'embeddings à l'indexation, un autre à la recherche. Les vecteurs ne sont pas comparables, la recherche renvoie des passages sans rapport, et aucune erreur ne s'affiche.
• Un seul passage récupéré par mégarde. Dès que l'information est répartie sur deux sections, la réponse est incomplète.
• La recherche porte sur le dernier message seulement. « Et pour les CDD ? » ne veut rien dire seul. On réécrit la question en une question autonome à partir de l'historique avant de chercher.

Le premier se bloque en quelques lignes : on enregistre le modèle avec l'index, et on refuse de chercher si le modèle de requête diffère.

# À l'indexation : le modèle est stocké avec la collection
meta = {"embedding_model": "bge-m3", "dim": 1024}

# À la recherche : on refuse de chercher avec un autre modèle
if encoder.name != meta["embedding_model"]:
    raise RuntimeError("Modèle d'embeddings différent de celui de l'index")

La recherche hybride

La recherche hybride combine une recherche sémantique (vecteurs) et une recherche par mots exacts (BM25), puis fusionne les deux classements. Elle rattrape ce que la recherche sémantique rate : références de pièces, codes d'erreur, acronymes, numéros d'article. Sur un corpus technique, c'est presque toujours un gain net pour une latence faible. Chez Continental, dont la documentation porte sur les erreurs machine, l'effet de l'ajout de BM25 est chiffré dans le cas client Continental.

La fusion la plus courante, le Reciprocal Rank Fusion, tient en quelques lignes et n'a pas besoin de normaliser des scores qui ne sont pas comparables :

def rrf(classements, k=60):
    scores = {}
    for classement in classements:  # ex. [ids_vectoriel, ids_bm25]
        for rang, doc_id in enumerate(classement):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rang + 1)
    return sorted(scores, key=scores.get, reverse=True)

En pratique, Qdrant et la plupart des bases vectorielles récentes font cette fusion nativement. Le principe et ses variantes sont détaillés dans l'article sur la recherche hybride BM25 et vectorielle.

Reranking et agentic RAG : ce qui n'a rien donné

Le reranking réordonne les passages retrouvés avec un modèle plus fin. Sur un projet réel, il faisait passer la note de 89 % à 92 %. Je ne l'ai pas gardé : le cas d'usage demandait des réponses rapides, et trois points ne justifiaient pas le temps d'attente ajouté. Le parcours complet de ce projet, étape par étape, est raconté dans l'article améliorer un RAG : pourquoi on a renoncé au reranking.

Passer en agentic RAG, où un agent décide lui-même de lancer plusieurs recherches, n'a rien apporté non plus sur ce que nous avons testé en expérimentation. Il ajoute des appels au modèle, donc de la latence et du coût. Il se justifie quand les questions demandent vraiment d'enchaîner plusieurs recherches, pas pour réparer un pipeline qui répond à côté.

Génération : citer les sources et poser des garde-fous

La génération d'un pipeline RAG en production a deux obligations : montrer d'où vient chaque information, et savoir ne pas répondre. Un modèle qui comble un trou de recherche avec une réponse plausible fait plus de dégâts qu'une absence de réponse.

Une réponse citée, vérifiable en un clic

Je propose presque systématiquement de sourcer les réponses : chaque affirmation renvoie au document, à la section ou à la page d'où elle vient, avec un lien pour l'ouvrir. L'utilisateur vérifie au lieu de croire, et une réponse fausse se repère tout de suite. Les métadonnées gardées à l'ingestion (titre, page, chemin de titres) servent directement ici.

« Une chose importante dans le RAG, c'est l'interface et la façon dont l'information est présentée à l'utilisateur. »

Concrètement : la réponse courte d'abord, les sources dessous, le passage cité dépliable. C'est un travail d'interface autant que de prompt, et c'est souvent lui qui décide si l'outil est adopté.

Les garde-fous qui tournent à chaque question

• Pas de passage pertinent, pas de réponse inventée. Si la recherche ne remonte rien d'assez proche, le pipeline répond qu'il ne trouve pas l'information et, selon le cas, oriente vers un humain.
• Hors périmètre et requêtes malveillantes. Sur le RAG législatif du secteur public, une étape détectait les requêtes malveillantes (tentatives de détourner les instructions) avant la recherche.
• Droits d'accès appliqués à la recherche. Le filtre se fait sur les métadonnées des passages, avant la génération : un document qu'un utilisateur ne peut pas ouvrir ne doit pas pouvoir être cité. Le sujet est détaillé dans l'article sur la sécurisation d'un RAG.

Savoir ne pas répondre fait aussi partie du résultat. Sur les assistants de service client, 50 à 80 % des questions sont traitées sans humain selon le secteur ; une question sur un problème de commande, elle, part vers une personne. Le cas client Heeya, plus de 20 000 questions répondues, montre ce découpage sur un SaaS de support.

Évaluation : mesurer avant chaque modification

L'évaluation d'un pipeline RAG est un jeu de questions de test, noté réponse par réponse, relancé à chaque modification. C'est la première question que je pose en mission d'amélioration (« comment mesurez-vous la performance ? »), et en général aucune entreprise ne sait y répondre. Certaines posent les trois mêmes questions à chaque nouvelle version.

La méthode qu'on applique sur chaque projet :

1. 20 à 50 questions de test dès les deux ou trois premiers jours, avec la réponse attendue et le document source.
2. Une notation binaire : correcte ou non, complète ou non, fausse ou non. Une note de 1 à 5 est peu exploitable, deux évaluateurs ne la donnent pas de la même façon.
3. Trois pourcentages suivis : bonnes réponses, réponses complètes, réponses fausses.
4. Pendant les tests, toutes les questions des utilisateurs sont ajoutées au jeu. Elles ne ressemblent jamais à celles imaginées par l'équipe.
5. Le jeu est relancé à chaque changement de prompt, de chunking, de modèle ou de recherche. Chez Continental, ces tests de régression faisaient partie du pipeline.

Quand le jeu dépasse ce qu'on peut relire à la main, un LLM as a judge prend le relais : un modèle compare la réponse à la réponse attendue et rend un verdict binaire. On l'a utilisé chez Reezet et pour un acteur du spatial. Un juge se vérifie lui aussi, sur un échantillon de réponses notées à la main, sinon on mesure ses erreurs plutôt que celles du RAG.

Le travail se découpe en sprints d'un mois, avec des objectifs précis et des livrables. Je ne promets pas la lune, mais une procédure scientifique, avec l'évaluation au centre. La méthode complète est dans notre article sur la mesure de la performance d'un RAG, et les métriques outillées (RAGAS et autres) dans l'article sur l'évaluation d'un RAG en production.

Observabilité en production : traces, retours et Langfuse

L'observabilité d'un RAG en production consiste à garder la trace de chaque réponse, étape par étape, pour savoir où une erreur s'est produite. Sans trace, une réponse fausse signalée par un utilisateur ne se diagnostique pas : on ne sait pas si la recherche a raté le bon passage ou si le modèle l'a mal lu.

Nous utilisons Langfuse sur plusieurs projets, dont Continental, Reezet, le RAG d'un acteur du spatial et celui du secteur public. Il est open source et s'héberge sur vos serveurs, ce qui compte quand les questions des utilisateurs contiennent des données internes. Pour chaque question, la trace contient :

• la question d'origine et la requête réellement envoyée à la recherche, après réécriture ;
• les passages retrouvés, avec leur score et leur document source ;
• le prompt final, la réponse, la latence de chaque étape et le coût en tokens ;
• le retour de l'utilisateur, un simple pouce levé ou baissé.

Ce retour utilisateur boucle avec l'évaluation : une réponse notée négativement est relue, et si elle révèle un cas manquant, la question entre dans le jeu de test. C'est ce qui permet de suivre un système dont l'usage évolue : sur la plupart des chatbots de service client que nous suivons, l'usage est en hausse, et les questions changent avec lui. Le détail de la mise en place est dans notre guide Langfuse.

Si vous partez de zéro, c'est l'ensemble de ce pipeline que couvre notre développement RAG sur mesure : on le conçoit, on le construit en Python sur vos documents et vos outils, on le livre avec son jeu d'évaluation et on le suit en production.

Questions fréquentes sur le pipeline RAG

Pour aller plus loin

• Évaluer un RAG : Ragas, Langfuse ou notation binaire : les métriques, leurs limites et la méthode appliquée en production.
• Qdrant ou pgvector : choisir sa base vectorielle selon PostgreSQL, le volume et le multi-tenant.
• vLLM ou Ollama : servir un modèle ouvert sur ses propres serveurs.
• Améliorer un RAG étape par étape : un projet réel, de la correction des bugs au reranking écarté.
• Mesurer la performance d'un RAG : le jeu de test et la notation binaire en détail.
• Maintenir un RAG en production : mises à jour de l'index, changement de modèle, dérive de qualité.
• Bases de données vectorielles pour un RAG : Qdrant, pgvector et les autres options.
• Les embeddings dans un RAG : comment ils fonctionnent et comment les choisir, côté praticien.