Chunking, indexation, recherche : comment fonctionne un pipeline RAG

On parle du RAG comme d’une fonctionnalité unique, mais un pipeline RAG est en réalité une chaîne de petites étapes très concrètes : extraire le texte, le découper en passages, indexer ces passages, retrouver les bons au moment de la question, puis les confier à un modèle de langage avec des consignes strictes. Chaque étape a ses réglages, et chaque réglage influe sur la qualité de la réponse finale. Ce guide parcourt toute la chaîne, explique les arbitrages à chaque maillon et montre où la plupart des pipelines se trompent sans bruit.

Si le concept lui-même est nouveau pour vous, commencez par notre guide pratique du RAG. Ici, on part du principe que vous connaissez l’idée (fournir au modèle les bons extraits plutôt que d’espérer qu’il s’en souvienne) et que vous voulez comprendre la mécanique.

Quelles sont les étapes d’un pipeline RAG ?

Tout système RAG se divise en deux phases. La phase d’ingestion s’exécute une fois par document, au moment où vous l’ajoutez : elle transforme les fichiers en passages interrogeables. La phase de requête s’exécute à chaque question : elle retrouve les passages pertinents et rédige une réponse à partir d’eux. Garder ces deux phases en tête change tout au moment du diagnostic, car une mauvaise réponse vient presque toujours d’une étape bien identifiable.

Étape 1 : l’extraction du texte, une fondation discrète mais décisive

Aucune étape en aval ne peut rattraper un texte mal extrait. Les formats .txt, .md, .csv ou .json ne posent aucun problème : le texte est déjà là. Les fichiers Word (.docx) sont du XML structuré et s’extraient proprement. Le PDF est le cas délicat : un PDF est une suite d’instructions de dessin, pas un document organisé en paragraphes. Les outils d’extraction reconstituent l’ordre de lecture à partir de la position des caractères, ce qui fonctionne en général pour les PDF texte, mais peut coincer sur les mises en page en colonnes, les notes de bas de page ou les tableaux complexes.

Le piège principal, c’est le PDF scanné. Si un document a été numérisé en image sans passer par un OCR (reconnaissance optique de caractères), il n’y a tout simplement aucun texte à extraire : le pipeline voit un fichier vide. Test rapide : ouvrez le PDF et essayez de sélectionner une phrase à la souris. Si c’est impossible, le fichier doit passer par un OCR avant d’entrer dans une base de connaissances.

Étape 2 : le chunking, ou l’art de découper les documents

Les modèles de langage ont une fenêtre de contexte limitée, et même quand elle est vaste, y déverser des documents entiers est lent, coûteux et dilue l’attention du modèle. On découpe donc le texte en chunks (ou passages) : des morceaux assez petits pour être retrouvés individuellement, assez grands pour avoir du sens seuls. Le découpage est l’étape qui pèse le plus sur la qualité des réponses, et celle qu’on laisse le plus souvent aux réglages par défaut.

Quelle taille de chunk choisir ?

Il n’existe pas de taille idéale universelle, mais l’arbitrage est toujours le même. Des passages courts sont précis : quand ils remontent, presque tout leur contenu est pertinent. Mais ils perdent le contexte, et une règle éclatée sur trois passages risque de n’être retrouvée qu’à moitié. Des passages longs conservent le contexte mais apportent du bruit, et on en fait tenir moins dans le prompt. Pour des documents rédigés (règlements, contrats, conventions, guides), des passages d’un à quelques paragraphes, autour d’un millier de caractères, constituent un compromis courant et raisonnable.

Pourquoi le chevauchement compte

Le chevauchement (overlap) consiste à répéter la fin de chaque passage au début du suivant. Il évite qu’une phrase clé tombe pile sur une frontière : grâce à lui, elle apparaît entière dans au moins un passage. Le prix à payer est un peu de doublon dans l’index. Un chevauchement modeste, une ou deux phrases, suffit généralement.

Découper selon la structure, pas au nombre de caractères

Les découpeurs naïfs tranchent tous les N caractères, souvent au milieu d’un mot ou d’une phrase. Les meilleurs sont récursifs : ils coupent d’abord sur les sauts de paragraphe, puis sur les fins de phrase, et ne recourent à une coupe brute que si une phrase est trop longue. Chaque passage reste ainsi une unité de sens cohérente.

• Découpage à taille fixe : simple et prévisible, mais aveugle au sens. Acceptable pour un texte homogène.
• Découpage récursif (paragraphes, puis phrases) : le choix pragmatique pour la plupart des documents professionnels.
• Découpage par structure (titres, articles, sections) : excellent pour des documents bien structurés, comme un code ou une convention collective.
• Découpage sémantique (coupe là où le sujet change, détecté par un modèle) : élégant, mais plus coûteux et moins prévisible.

Étape 3 : l’indexation, recherche plein texte ou embeddings ?

Une fois les passages obtenus, il faut pouvoir retrouver rapidement les bons. Il existe deux grandes familles d’index, et beaucoup de systèmes en production les combinent.

L’indexation lexicale (plein texte)

La recherche plein texte est la technologie des moteurs de recherche classiques. Chaque passage est découpé en mots, chaque mot est ramené à sa racine (licencier, licenciement et licencié se rejoignent), les mots vides sont écartés, et un index inversé associe chaque racine aux passages qui la contiennent. Une fonction de classement note ensuite les passages selon leur correspondance avec la requête. Des bases de données comme PostgreSQL le proposent nativement, avec des dictionnaires par langue : voir la documentation PostgreSQL sur la recherche plein texte.

Points forts : termes exacts, numéros d’article, références produit et noms propres sont retrouvés de façon fiable ; les résultats sont explicables ; aucun modèle ni base vectorielle supplémentaire. Point faible : l’écart de vocabulaire. Si le document parle de rupture du contrat et que l’utilisateur demande comment se faire virer, une recherche purement lexicale peut passer à côté.

L’indexation vectorielle (embeddings)

Un modèle d’embedding convertit chaque passage en un vecteur de nombres qui en capture le sens. La question est convertie de la même façon, et l’index renvoie les passages dont les vecteurs sont les plus proches. Synonymes et reformulations sont gérés naturellement. En contrepartie : il faut un modèle d’embedding et un index vectoriel, tout réindexer si l’on change de modèle, et les identifiants exacts (un numéro d’article, une référence) sont parfois moins bien retrouvés qu’avec des mots-clés.

La recherche hybride lance les deux et fusionne les classements. Sur le papier, c’est souvent l’option la plus solide, mais elle double les briques à maintenir. Un index lexical bien réglé, associé à une étape intelligente de reformulation de la question (voir plus bas), constitue une base étonnamment robuste pour des documents professionnels, dont le vocabulaire est en général précis et constant.

Étape 4 : la recherche, de la question aux bons passages

C’est là que la question rencontre l’index. Les utilisateurs formulent rarement leurs questions comme les documents sont rédigés : les bons pipelines transforment donc la question avant de chercher.

1. Expansion de la requête : un petit modèle rapide reformule la question en mots-clés, synonymes et termes voisins (se faire virer devient licenciement, rupture, préavis). Cela comble l’essentiel de l’écart de vocabulaire de la recherche lexicale.
2. Recherche : la requête enrichie interroge l’index et renvoie des candidats notés.
3. Sélection des k meilleurs : seuls les meilleurs passages sont conservés. Trop peu, et le contexte manque ; trop, et on ajoute bruit et coût. Des valeurs entre 5 et 10 sont courantes pour du texte rédigé.
4. Reclassement (optionnel) : un modèle dédié renote les candidats au regard de la question d’origine pour affiner l’ordre.

Étape 5 : la génération avec citations

Les passages retrouvés sont placés dans le prompt, numérotés, avec la question et une consigne système : répondre uniquement à partir de ces sources, les citer, et signaler quand l’information n’y figure pas. Le modèle rédige alors une réponse avec des renvois comme [1] ou [3] vers des passages précis. Les citations sont ce qui rend le RAG digne de confiance : le lecteur peut ouvrir l’extrait exact et vérifier.

Certains usages n’ont pas besoin d’une réponse rédigée. Un agent IA qui raisonne seul préférera souvent les passages bruts pour faire la synthèse lui-même. C’est pourquoi de nombreux services RAG proposent un mode « passages » à côté du mode « réponse », ce qui facilite aussi le branchement d’une base de connaissances aux agents IA comme Claude ou Cursor via MCP.

Le pipeline RAG de Kopik, concrètement

Pour rendre tout cela tangible, voici exactement ce qui se passe quand vous créez une base sur Kopik. Vous déposez des PDF avec couche texte (un PDF scanné en image ne peut pas être lu), des fichiers Word .docx ou des formats texte (.txt, .md, .csv, .tsv, .json, .html, .xml), jusqu’à 4 Mo par fichier, ou vous collez simplement du texte. Le texte est extrait puis découpé en passages d’environ 1 200 caractères avec environ 200 caractères de chevauchement, en coupant d’abord sur les paragraphes, puis sur les phrases. Les passages sont indexés dès la fin de l’envoi, et la base s’enrichit à chaque nouveau document.

Les passages sont indexés avec la recherche plein texte de PostgreSQL, réglée sur la langue des documents choisie pour la base (français, anglais, allemand, espagnol, italien, portugais, néerlandais, ou un mode neutre pour les contenus mixtes) : racinisation et mots vides suivent cette langue. Kopik s’appuie sur une recherche lexicale, pas sur des embeddings vectoriels. Au moment de la question, un petit modèle rapide la décline d’abord en mots-clés et synonymes dans la langue des documents, si bien qu’une question posée dans une autre langue retrouve quand même les bons passages. Les 8 meilleurs passages sont retrouvés, et un modèle de langage rédige la réponse à partir de ces seuls passages, avec des citations numérotées comme [1] et [2]. Si la base ne contient pas la réponse, il le dit au lieu d’improviser. Un mode « passages » renvoie les extraits sans réponse rédigée, et les questions qui ne trouvent rien ne sont ni facturées ni décomptées.

Les pièges classiques d’un pipeline RAG et comment les corriger

Remarquez combien de correctifs se situent dans les documents plutôt que dans le code. C’est la leçon pratique de tout projet RAG : la qualité du corpus l’emporte sur les réglages astucieux. Si vous hésitez encore sur l’approche, notre comparatif RAG ou fine-tuning présente les alternatives, et notre guide pour créer une base de connaissances à partir de vos documents détaille la mise en place.

Check-list pour évaluer un pipeline RAG

• Pouvez-vous consulter le texte extrait de chaque document ?
• Le découpage respecte-t-il la structure (paragraphes, phrases) avec un chevauchement ?
• L’index gère-t-il la langue de vos documents (racinisation, mots vides) ?
• Existe-t-il une étape de reformulation de la question contre l’écart de vocabulaire ?
• Chaque réponse cite-t-elle ses sources, consultables en un clic ?
• Le système reconnaît-il quand il ne trouve rien, au lieu d’improviser ?
• Les agents peuvent-ils obtenir les passages bruts, pas seulement des réponses rédigées ?

Envie de voir comment d’autres créateurs structurent leur contenu ? Parcourez le catalogue public des bases de connaissances et posez quelques questions, ou consultez la documentation API et MCP pour interroger des bases depuis votre propre code.