Stratégies de chunking pour le RAG : fixed-size, sémantique, hiérarchique et late chunking comparés

Les stratégies de chunking pour le RAG définissent la manière dont un document est découpé, avant l'embedding, en segments de texte interrogeables appelés chunks. Le choix de la stratégie et de la taille des chunks détermine en grande partie la qualité de la récupération : c'est de lui que dépend la capacité d'un modèle de langage à trouver le bon passage, et la présence dans ce passage d'assez de contexte pour une réponse correcte et sourcée. Le chunking est donc le levier le plus discret, mais aussi le plus efficace, de toute la stack RAG.

• Recommandation par défaut : 200-800 tokens par chunk, 10-20 % de chevauchement, toujours précédés d'un parsing layout-aware.
• Erreur la plus fréquente : le chunking naïf à taille fixe coupe phrases, tableaux et listes, et compte parmi les principales causes d'hallucinations.
• Meilleur choix polyvalent en 2026 : le chunking hiérarchique parent-enfant, éventuellement combiné au Contextual Retrieval (Anthropic : jusqu'à -67 % d'erreurs de récupération avec recherche hybride et re-ranking).

Pourquoi le chunking décide du succès ou de l'échec

Dans un pipeline RAG, chaque document source est découpé, chaque chunk est converti en vecteur (embedding) puis stocké dans une base de données vectorielle. À l'exécution, le système recherche les chunks les plus proches de la question de l'utilisateur et les transmet au modèle de langage dans le prompt. Autrement dit, ce qui n'a pas été proprement découpé ne peut même pas être trouvé. Et ce qui est trouvé, mais a été coupé sans contexte, induit le modèle en erreur.

Deux catégories d'erreurs dominent en pratique. D'abord, le chunking naïf à taille fixe ignore les limites de phrases, de tableaux et de listes ; il en résulte des hallucinations et des contenus de tableaux manquants. Ensuite, le problème du « lost-in-the-chunks » : un chunk contient la phrase « Il a augmenté de 12 % ». Sans le contexte environnant, on ne sait pas ce qui a augmenté. Ces deux problèmes apparaissent avant l'embedding, et aucun re-ranking, aussi bon soit-il, ne pourra les corriger ensuite.

Les six stratégies de chunking en un coup d'œil

Le Fixed-size Chunking découpe le texte en fenêtres fixes, par exemple 512 tokens avec un chevauchement de 50 tokens. Il est rapide, déterministe et peu coûteux, mais aveugle au contenu. Adapté aux textes uniformes comme les logs ou les transcriptions.

Le Recursive Character / Sentence Splitting découpe de façon hiérarchique selon des séparateurs (paragraphes, puis phrases, puis mots) et respecte ainsi les limites naturelles. C'est l'option générique par défaut de nombreux frameworks (LangChain) et un bon point de départ pour des corpus mixtes.

Le Sentence-window en est une variante : l'embedding et la recherche se font au niveau de la phrase, mais le LLM reçoit une fenêtre composée des phrases environnantes. C'est un précurseur léger du principe parent-enfant.

Le Semantic Chunking mesure la distance cosinus entre phrases consécutives et coupe là où la cohérence thématique se rompt (cosine drift). Il produit des chunks cohérents pour les documents au contenu hétérogène, mais l'indexation demande plus de calcul, car chaque phrase doit d'abord être vectorisée.

Le Hierarchical / Parent-Child Chunking découple la récupération de la génération : de petits chunks enfants servent de cible de recherche précise, et le grand chunk parent correspondant est transmis au générateur comme contexte. Cette stratégie est souvent le meilleur choix pour les longs rapports et les manuels techniques.

Le Late Chunking est une approche plus récente qui inverse l'ordre : au lieu de découper le texte avant l'embedding, on traite d'abord l'intégralité du document (long) avec un modèle d'embedding à contexte long, puis on agrège (pooling) les embeddings de tokens obtenus en vecteurs de chunks. Chaque vecteur de chunk porte ainsi le contexte du document entier. L'approche poursuit le même objectif que le Contextual Retrieval, à savoir résoudre le problème du lost-in-the-chunks, mais ne nécessite pas d'appel LLM supplémentaire par chunk. Elle reste toutefois relativement jeune, moins largement éprouvée, et suppose un modèle d'embedding capable de gérer un contexte long. Avant toute mise en production, vérifie la longueur de contexte prise en charge et le comportement de pooling dans la documentation actuelle du fournisseur du modèle choisi.

Deux autres méthodes valent aussi le détour : le Propositional Chunking, qui découpe le texte en affirmations atomiques et convient à une extraction de faits très précise, et le Contextual Chunking (voir plus bas), qui place en tête de chaque chunk un en-tête de contexte explicatif.

Tableau comparatif : quelle stratégie, dans quel cas ?

Compromis : taille des chunks et chevauchement

La taille des chunks relève d'un arbitrage classique. Les petits chunks (par ex. 256 tokens) produisent des embeddings plus nets et des résultats plus précis pour des questions factuelles ponctuelles, mais risquent une perte de contexte. Les grands chunks (par ex. 800 tokens et plus) véhiculent davantage de contexte, mais diluent l'embedding et augmentent le risque que l'information pertinente se perde à cause de l'effet « lost-in-the-middle » du LLM. Des ensembles top-k trop volumineux transmis au modèle aggravent encore le problème. Il est donc recommandé de condenser les résultats après la récupération, via un re-ranker, à top_k = 5-10.

Le chevauchement (tokens partagés entre chunks voisins) évite qu'une idée soit coupée pile à la limite du découpage. Une valeur de 10-20 % de la taille du chunk a fait ses preuves comme repère. Davantage de chevauchement augmente la redondance, le besoin de stockage et les coûts d'indexation, sans améliorer la qualité dans les mêmes proportions.

Un facteur souvent sous-estimé pour les corpus en allemand : les mots composés allemands comme « Datenschutz-Folgenabschätzung » génèrent, selon le tokenizer (BPE/SentencePiece), nettement plus de tokens que leur équivalent anglais. En règle générale, l'allemand consomme, selon le modèle, environ 1,3-1,7x plus de tokens. Cela réduit la capacité de contenu effective d'un chunk de 512 tokens : une taille définie en tokens transporte donc moins de contenu en allemand qu'en anglais.

Exemple concret avec des chiffres

Supposons que tu indexes 10 000 pages PDF techniques (contrats et manuels produit).

1. Parsing : layout-aware, avec un parser comme Docling ou Unstructured, pour que les tableaux, les listes et les titres soient préservés.
2. Chunking : parent-enfant. Chunks parents d'environ 1 500 tokens (sections entières), chunks enfants d'environ 300 tokens avec 15 % de chevauchement.
3. Cible de l'embedding : les chunks enfants ; le LLM reçoit le chunk parent correspondant.
4. Contextual Header optionnel : pour chaque chunk, une courte phrase de contexte générée par un LLM avant l'embedding. Selon Anthropic (septembre 2024), le taux d'erreur de récupération top-20 passe de 5,7 % à 3,7 % (-35 %) avec ces seuls Contextual Embeddings. Combiné au Contextual BM25 (recherche hybride), il descend à 2,9 % (-49 %), et avec un re-ranking supplémentaire à 1,9 % (-67 %). Anthropic chiffre le coût unique des phrases de contexte à environ 1,02 dollar américain par 1 million de tokens de document (Claude 3 Haiku avec prompt caching, chunks de 800 tokens, documents de 8 000 tokens, prix de septembre 2024). Avec des chunks de 300 tokens comme ici, la valeur est plus élevée, car davantage de chunks par million de tokens ont besoin d'une phrase de contexte.

Pseudo-code pour le découpage hiérarchique :

```
parents = split(document, size=1500, separators=["\n## ", "\n\n"])
for p in parents:
children = split(p, size=300, overlap=45) # 15 % de 300
for c in children:
c.context = llm("Situe brièvement ce chunk dans le document complet.", document=document, chunk=c.text) # optionnel
index.upsert(embed(c.context + c.text), parent_ref=p.id)
```

Comment tester la bonne stratégie

Les décisions de chunking ne se devinent pas, elles se mesurent. La démarche :

• Constituer un gold set : 50-200 vraies questions d'utilisateurs, chacune annotée avec le passage source correct. Sans gold set, un LLM-as-Judge (RAGAS reference-free) ou un jeu de test généré synthétiquement peut dépanner.
• Indexer des variantes : découper plusieurs fois le même corpus, par exemple en Fixed-512, Recursive-300, Semantic et Parent-Child, avec un pipeline identique par ailleurs.
• Mesurer avec RAGAS : les métriques centrales de l'évaluation RAG avec RAGAS sont Context Precision et Context Recall (les bons passages sont-ils trouvés ?) ainsi que Faithfulness et Answer Relevancy (la réponse s'appuie-t-elle vraiment sur le contexte ?).
• A/B en production : opposer la variante arrivée en tête du test offline à la variante existante et observer des signaux réels (clics, retours des utilisateurs).

Important : si le modèle d'embedding change, une réindexation complète est nécessaire, car les embeddings de modèles différents ne sont pas comparables. Attribue donc une chaîne de version à tes index.

Pour les agences et les décideurs B2B

Le chunking n'est pas un détail de configuration qu'on règle une fois pour l'oublier ensuite : c'est le réglage qui pèse le plus sur la qualité des réponses de ton système RAG, et donc sur la confiance que lui accordent clients et collaborateurs. Démarrer avec un chunking naïf à taille fixe se paie plus tard en hallucinations, en escalades au support et en corrections coûteuses. En tant qu'agence, chez Blck Alpaca (Vienne), nous concevons et évaluons des pipelines RAG pour des entreprises en Europe de manière mesurable, à l'aide des métriques RAGAS, avec une tokenisation adaptée à l'allemand, un hébergement dans l'UE conforme aux exigences du RGPD et une stratégie de chunking qui correspond à tes documents et à tes questions. Parle-nous-en avant la mise en production plutôt que de devoir réparer après.