RAG en production : bien découper ses documents (chunking)

Un système de RAG, qui répond en récupérant des passages de vos documents puis en les faisant traiter par un modèle, ne vaut que ce que vaut sa récupération. Or la qualité de cette récupération se décide en grande partie avant même la première requête, au moment où l’on découpe les documents en segments.

Ce découpage, qu’on appelle chunking, paraît anodin : il s’agit de couper du texte en morceaux. En pratique, c’est l’une des décisions les plus lourdes de conséquences pour la qualité finale. Des segments trop grands noient la réponse dans du bruit ; des segments trop petits coupent les idées en plein milieu.

Cet article explique comment penser ce découpage, à partir de ce qui compte réellement : la façon dont un modèle comprend un passage, et la façon dont une requête retrouve un segment. Vous y trouverez des critères concrets pour calibrer taille, chevauchement, structure et métadonnées.

Pourquoi le découpage conditionne tout le reste

Le découpage agit à deux endroits. Au moment de l’indexation, il détermine ce que le système pourra retrouver. Au moment de la réponse, il détermine ce que le modèle aura sous les yeux. Une erreur de découpage se propage donc dans les deux sens : on retrouve mal, et on répond mal avec ce qu’on a retrouvé.

Un segment doit avoir une double qualité : être assez petit pour qu’une requête puisse le retrouver avec précision, et assez autonome pour qu’un modèle puisse le comprendre sans le reste du document. Ces deux exigences tirent dans des directions opposées, ce qui fait du découpage un compromis permanent plutôt qu’un réglage unique.

L’erreur la plus fréquente est de traiter le découpage comme un détail technique qu’on règle une fois avec une valeur par défaut. Les bons systèmes réexaminent leur découpage à chaque changement de corpus ou de modèle, parce que la bonne valeur dépend des deux.

La taille des segments : un compromis à calibrer

La taille d’un segment se mesure en caractères ou en jetons, et il n’existe pas de valeur universelle. La règle de travail est de commencer autour de quelques centaines de jetons, puis de calibrer en mesurant la qualité de récupération sur un jeu d’évaluation. Les découpeurs de LlamaIndex ou de LangChain exposent ces deux réglages, taille et chevauchement, ce qui rend les essais rapides ; Ragas fournit ensuite des métriques de récupération pour comparer les configurations.

Des segments trop grands ont un défaut précis : ils diluent. Plus le segment est long, moins la requête a de chances de tomber précisément sur la bonne information, et plus le modèle reçoit de texte inutile. Des segments trop petits ont le défaut inverse : ils fragmentent, et une idée qui s’étale sur deux segments devient introuvable ou incompréhensible.

La bonne taille dépend du type de document. Des questions fréquentes courtes se découpent en segments courts, presque une question par segment. Des documents techniques, où une réponse dépend de plusieurs paragraphes liés, demandent des segments plus longs. Il faut donc calibrer par corpus, pas chercher une valeur passe-partout, et le calibrage n’a de sens que mesuré sur un jeu de test représentatif.

Le chevauchement pour ne pas couper les idées

Aucun découpage fixe ne tombe jamais exactement entre deux idées. Un paragraphe qui commence en fin de segment et se poursuit au début du suivant sera perdu si l’on découpe à l’aveugle. Le chevauchement corrige cela : chaque segment reprend la fin du précédent, sur une longueur calibrée.

Le chevauchement a un coût, il duplique du texte et augmente la taille de l’index, mais ce coût est faible au regard de ce qu’il évite. Sans chevauchement, les informations situées aux frontières de segments disparaissent purement et simplement de la base, et le système devient aveugle sur ces zones.

La valeur du chevauchement se calibre elle aussi. Trop faible, il ne remplit pas son rôle. Trop fort, il fait remonter en double les mêmes passages et brouille les scores de similarité. Une valeur courante se situe autour de dix à vingt pour cent de la taille du segment, à ajuster selon la densité du texte.

Respecter la structure du document

Un document n’est pas une suite uniforme de caractères, c’est une structure : des titres, des sections, des listes, des tableaux. Découper sans tenir compte de cette structure, c’est fabriquer des segments qui commencent et finissent n’importe où, en pleine phrase, en pleine liste.

Le bon réflexe est de découper le long des frontières naturelles : après un titre, après un paragraphe, à la fin d’une section. On peut le faire en utilisant les repères du format, les titres en markdown par exemple, ou en découpant sur des sauts de structure plutôt que sur une longueur arbitraire. Pour les PDF et les fichiers Word, des outils d’extraction comme Docling ou Unstructured reconstituent d’abord cette structure (titres, listes, tableaux), ce qui permet ensuite de découper section par section.

Les tableaux méritent une attention particulière. Un tableau découpé en pleine ligne devient illisible pour le modèle, et une ligne isolée de son en-tête perd tout son sens. Il vaut souvent mieux traiter un tableau comme une unité, quitte à lui donner un format qui reste compréhensible une fois extrait.

Le découpage sémantique, et quand il vaut le coût

Une approche plus récente consiste à découper non pas à longueur fixe, mais là où le sens change : on segmente le texte en blocs qui parlent du même sujet. Ce découpage sémantique produit des segments plus cohérents, et améliore la qualité dans les corpus longs et hétérogènes.

Il a un coût réel : il demande un modèle supplémentaire ou des techniques de similarité entre phrases, donc plus de temps de traitement et plus de complexité. Pour un corpus homogène et court, il n’apporte souvent rien de décisif par rapport à un découpage structurel bien fait. Les corpus de documents très longs posent d’ailleurs leurs propres problèmes, qu’on traite dans RAG : gérer les documents volumineux.

La règle de décision est simple : commencez par le découpage structurel, qui est bon marché et suffisant dans la plupart des cas. Passez au sémantique quand la mesure montre que la récupération échoue sur des documents longs qui mêlent plusieurs sujets, là où un découpage fixe coupe en plein milieu des transitions.

Les métadonnées, la moitié oubliée du découpage

Le découpage ne produit pas que du texte, il produit aussi des informations sur ce texte : de quel document il vient, à quelle section il appartient, de quelle date il date. Ces métadonnées sont souvent négligées, alors qu’elles conditionnent la récupération autant que le contenu, et elles deviennent indispensables quand il faut garder les réponses à jour au fil des versions de vos documents.

Les métadonnées servent à filtrer. Si vos documents traitent de plusieurs produits ou de plusieurs versions, un utilisateur qui interroge sur un produit précis n’a pas besoin des segments des autres. Filtrer sur la métadonnée avant la recherche améliore la précision bien plus sûrement que d’augmenter la taille du segment. Les bases vectorielles courantes, pgvector, Qdrant, Pinecone ou Weaviate, permettent toutes ce filtrage, à condition que les métadonnées aient été posées au découpage.

Elles servent aussi à citer. Quand un segment remonte, le système doit pouvoir dire d’où il vient, pour renvoyer une source fiable à l’utilisateur. Un découpage qui perd la trace de l’origine du segment détruit la capacité du système à se justifier, ce qui est rédhibitoire dans un usage professionnel.

En pratique : découper votre corpus

Le découpage se règle par la mesure, pas par l’intuition, et chaque corpus demande son propre calibrage. Sur les RAG qu’on met en production, on commence par analyser le corpus (formats, structure, tableaux, versions), on construit le jeu d’évaluation avec les personnes qui connaissent les documents, puis on itère sur la taille, le chevauchement et les métadonnées jusqu’à une récupération qui tient sur les vrais cas.

Si votre RAG répond à côté alors que l’information est bien dans vos documents, le découpage est l’un des premiers suspects. C’est un diagnostic qu’on mène systématiquement dans nos projets de chatbot RAG sur vos documents, avant de toucher au modèle.