Dans l'architecture d'un RAG, une étape de l'ingestion décide en grande partie de la qualité finale : le chunking, c'est-à-dire le découpage des documents en morceaux — les chunks — avant de les vectoriser. On n'indexe presque jamais un document entier d'un bloc : on le tranche, et c'est sur ces tranches que porteront l'embedding, la recherche et, au bout de la chaîne, la réponse du modèle. Un découpage maladroit handicape tout le reste : on retrouve des passages tronqués, hors sujet ou noyés dans du bruit. Cet article explique pourquoi il faut découper, ce qui se passe quand les chunks sont trop gros ou trop petits, les stratégies de découpage, et les réglages par défaut qui conviennent à la plupart des cas.
Pourquoi découper
Trois raisons imposent le découpage.
D'abord, une contrainte technique : les modèles d'embedding ont une longueur d'entrée maximale. Au-delà, le texte est tronqué — et l'on vectorise un document amputé sans le savoir.
Ensuite, une raison sémantique : un embedding est un vecteur unique de taille fixe. Lui faire résumer une page entière qui aborde dix sujets produit un vecteur « moyen », flou, qui ne ressemble vraiment à aucune question précise. Un chunk centré sur une seule idée donne au contraire un vecteur net, qui ressort clairement quand on pose une question sur cette idée.
Enfin, une raison pratique : ce que la base récupère, puis ce qu'on injecte dans le prompt, c'est le chunk. Il doit donc être assez autoportant pour répondre, et assez court pour ne pas gaspiller la fenêtre de contexte ni noyer le modèle. Le chunk est l'unité de récupération : tout le RAG raisonne à cette granularité.
Le compromis de taille
Toute la difficulté tient dans un arbitrage sur la taille des chunks. Trop petits, ils perdent leur contexte ; trop gros, ils diluent le sens et ramènent du bruit.
- Chunks trop petits (une phrase isolée) : le vecteur est précis, mais le passage est privé de son contexte. « Il est de 14 jours. » ne dit rien sans la phrase qui précède ; récupéré seul, il est inexploitable. On fragmente aussi une même idée sur plusieurs chunks, et le bon passage risque de ne plus contenir la réponse complète.
- Chunks trop gros (une page entière) : le passage est complet, mais son vecteur mélange plusieurs sujets et devient flou — il « matche » moyennement beaucoup de questions sans coller vraiment à aucune. Et même récupéré à juste titre, il injecte dans le prompt des paragraphes hors sujet qui diluent l'attention du modèle.
- La bonne taille isole une idée cohérente et autoportante : assez de contexte pour se comprendre seul, assez de focus pour produire un vecteur net. En pratique, pour de la documentation, on vise souvent l'ordre de quelques centaines de tokens par chunk — un à quelques paragraphes.
Le recouvrement (overlap)
Découper crée des frontières, et une frontière peut tomber au milieu d'une idée : la fin d'un chunk pose une question dont la réponse démarre le chunk suivant, et aucun des deux n'est complet. La parade est le recouvrement (overlap) : on fait déborder chaque chunk de quelques dizaines de tokens sur le suivant, pour qu'une idée à cheval sur une coupure se retrouve entière dans au moins un des deux chunks.
Un recouvrement de l'ordre de 10 à 20 % de la taille du chunk est un réglage courant : assez pour préserver la continuité, pas trop pour ne pas gonfler inutilement l'index avec du texte dupliqué.
Les stratégies de découpage
Plusieurs façons de tracer les frontières, de la plus simple à la plus fine.
Découpage de taille fixe (fixed-size). On coupe tous les N caractères ou tokens, avec recouvrement. Simple et rapide, mais aveugle au sens : il tranche volontiers au milieu d'une phrase ou d'un mot.
Découpage récursif (recursive). C'est le défaut recommandé. On essaie de couper d'abord sur les séparateurs les plus naturels — sauts de paragraphe, puis phrases, puis mots — en descendant l'échelle seulement si un morceau dépasse encore la taille visée. On respecte ainsi la structure du texte tout en bornant la taille. C'est ce que fait le RecursiveCharacterTextSplitter de frameworks comme LangChain.
Découpage structurel. Quand le document a une structure explicite — titres Markdown, sections HTML, code — on s'en sert comme frontières : un chunk par section, en conservant le titre dans le chunk ou ses métadonnées. Très efficace sur de la documentation bien structurée.
Découpage sémantique (semantic chunking). On coupe là où le sens change : on mesure la similarité entre phrases voisines et on ouvre une nouvelle frontière quand elle chute. Plus coûteux (il faut embedder pour découper), mais il colle au contenu plutôt qu'à un compteur de caractères.
| Stratégie | Frontières | Quand l'utiliser |
|---|
| Taille fixe | tous les N tokens | rapide, baseline, texte sans structure |
| Récursif | paragraphes → phrases → mots | défaut : bon équilibre simplicité / qualité |
| Structurel | titres, sections, balises | documents bien structurés (Markdown, HTML) |
| Sémantique | rupture de sens | contenu hétérogène, qualité prioritaire sur le coût |
Au moment de découper, on attache à chaque chunk des métadonnées : source (quel document, quelle URL), titre de section, catégorie, date, identifiant. Elles servent à deux choses essentielles. Citer la source dans la réponse, pour la traçabilité. Et filtrer la recherche (« ne chercher que dans les documents de catégorie juridique »), pour restreindre le retrieval au bon sous-ensemble. Un chunk sans métadonnées est récupérable, mais ni traçable ni filtrable.
Des réglages par défaut raisonnables
Il n'existe pas de taille universelle : l'optimum dépend du contenu, du modèle d'embedding et des questions posées — c'est précisément le genre de paramètre qu'on mesure et ajuste une fois qu'on sait évaluer un RAG. En attendant, un point de départ qui marche dans la majorité des cas pour de la documentation :
- découpage récursif ;
- chunks de l'ordre de quelques centaines de tokens (souvent ~200 à 500) ;
- recouvrement de 10 à 20 % ;
- métadonnées systématiques (au moins la source).
On garde aussi une règle de bon sens : la taille des chunks doit être cohérente avec les questions attendues. Des questions pointues sur un fait précis appellent des chunks fins ; des questions de synthèse, des chunks plus larges.
Les pièges fréquents à éviter
La plupart des mauvaises réponses d'un RAG viennent d'un problème en amont de la génération. Côté chunking, les erreurs classiques : couper au mauvais endroit (en plein milieu d'une phrase ou d'un tableau), oublier le recouvrement (une information à cheval sur une coupure devient introuvable), et oublier les métadonnées (plus de citation ni de filtrage possibles). Le réflexe de débogage à adopter : face à une mauvaise réponse, inspectez d'abord les passages récupérés avant de blâmer le modèle. Dans la grande majorité des cas, c'est le retrieval — donc souvent le chunking — qui est en cause, pas le LLM.
Conclusion
Le chunking découpe les documents en passages autoportants, ni trop petits (perte de contexte) ni trop gros (sens dilué, bruit), avec un recouvrement pour ne pas couper une idée en deux. Le découpage récursif, des chunks de quelques centaines de tokens, 10 à 20 % de recouvrement et des métadonnées systématiques constituent un point de départ solide. C'est l'une des briques les plus rentables d'un RAG : bien la calibrer, c'est éviter la majorité des défaillances en aval.
