Stratégies de chunking pour le RAG : la taille compte

Chunking en RAG : pourquoi c'est 60 % de votre qualité de récupération

Le chunking est la partie non glamour du RAG qui détermine si votre système marche. Les threads sur r/LangChain, r/LlamaIndex et r/MachineLearning font régulièrement remonter le même pattern : les équipes blâment le modèle d'embedding ou le LLM, quand le vrai enjeu est comment elles splittent les documents.

Quelles stratégies de chunking existent vraiment et quand utiliser chacune :

• →Chunking taille fixe (ex. 512 ou 1024 tokens). Simple, prévisible, et souvent le mauvais choix. Marche quand le contenu est uniforme et autonome ; casse pour tout avec de la structure (headers, blocs de code, tables).
• →Split récursif de caractères. Le défaut LangChain. Respecte les newlines, puis les phrases, puis les mots. Une baseline sensible pour la prose.
• →Chunking sémantique. Splitte aux frontières sémantiquement signifiantes en utilisant la similarité d'embedding. La documentation SemanticSplitter de LlamaIndex décrit l'approche. Meilleur pour contenu hétérogène ; plus cher à l'ingestion.
• →Chunking conscient de la structure. Utilise la structure du document (headers markdown, sections HTML, AST de code) pour splitter aux frontières naturelles. Le gold standard pour contenu structuré.
• →Sliding-window avec overlap. Chaque chunk inclut les N derniers tokens du chunk précédent. Réduit la perte de frontière mais augmente le stockage et un peu de bruit de récupération.
• →Chunking niveau proposition. Réécrivez le texte comme des réclamations atomiques, embeddez chaque réclamation. Cher mais produit une récupération mesurablement meilleure sur les benchmarks factual-QA.
• →La récupération contextuelle d'Anthropic. Préfixer un résumé court spécifique au chunk généré par un LLM. Le post récupération contextuelle d'Anthropic documente la technique et les gains mesurés.

Ce sur quoi les praticiens se sont posés :

• →La taille du chunk compte moins que les frontières du chunk. Un chunk de 512 tokens qui finit au milieu d'une phrase récupère moins bien qu'un chunk de 300 ou 800 tokens qui finit à une cassure de paragraphe.
• →Les métadonnées comptent. Incluez titre de document, section, URL source dans le chunk. Les systèmes de récupération rangent mieux quand les métadonnées sont searchable.
• →La récupération hybride bat le vecteur pur. BM25 + récupération dense + reranking (Cohere Rerank, Voyage rerank, Jina reranker) surperforme n'importe quelle approche seule.
• →Évaluez la récupération séparément de la génération. Beaucoup de plaintes « RAG est mauvais » sont des plaintes « mon retriever a retourné de la poubelle ». Mesurez la qualité de récupération (MRR, recall@k) avant de toucher au LLM.
• →Re-chunkez quand les modèles changent. Différents modèles d'embedding ont différentes tailles de chunk optimales. Ce qui marchait pour OpenAI ada-002 peut ne pas être optimal pour Voyage ou Cohere.

Ce qui est encore pénible :

• →Chunks de code. Le splitting AST-aware aide mais n'est pas universel. Les dépendances cross-file cassent la récupération qui traite chaque fichier comme indépendant.
• →Tables et figures. Classe de contenu la plus dure ; les tables sérialisées-vers-texte récupèrent mal. Les modèles vision-langage gèrent une partie mais à coût.
• →Documents évoluants. Re-chunker et ré-embedder à chaque update est cher ; le delta chunking est sous-développé.

Le cadrage honnête : le chunking est une décision de design système, pas un hyperparamètre. Les équipes qui traitent le chunking comme une préoccupation first-class, avec évaluation, itération et tuning spécifique au domaine, construisent des systèmes RAG qui marchent. Les équipes qui utilisent le splitter récursif 512-token par défaut et blâment le LLM ne savent pas où est leur vrai plafond de qualité.

Qu'est-ce que le chunking ?

Le chunking est le processus de découpage de documents volumineux en morceaux plus petits pour le stockage et la récupération dans un système RAG.

Pourquoi découper

Problème :
- Votre document : 50 000 tokens
- Fenêtre de contexte : 8 000 tokens
- Modèles d'embedding : max 512 tokens

Solution :
- Découper en ~100 chunks de 500 tokens chacun
- Indexer et stocker chaque chunk
- Récupérer uniquement les chunks pertinents

Vous ne pouvez pas envoyer des documents entiers à la plupart des systèmes d'IA, le chunking les rend exploitables.

Pourquoi la stratégie de chunking est importante

Mauvais chunking

Chunk 1 : "...augmenté de 15 %. La nouvelle politique"
Chunk 2 : "exige que tous les employés soumettent les formulaires"
Chunk 3 : "avant vendredi. Les règles de sécurité imposent"

Les chunks coupent en pleine phrase. Le contexte est perdu. La récupération échoue.

Bon chunking

Chunk 1 : "Le chiffre d'affaires a augmenté de 15 % au T3 2024."
Chunk 2 : "La nouvelle politique de notes de frais exige que tous
          les employés soumettent leurs remboursements chaque vendredi."
Chunk 3 : "Les règles de sécurité imposent des inspections
          trimestrielles des équipements pour toutes les usines."

Des idées complètes. Un contexte clair. Une récupération efficace.

Le compromis du chunking

Petits chunks (100-200 tokens)

✅ Récupération précise
✅ Moins de bruit dans les résultats
❌ Risque de perte de contexte
❌ Plus de chunks à parcourir

Grands chunks (1000+ tokens)

✅ Plus de contexte préservé
✅ Moins de chunks à gérer
❌ Plus de bruit dans les résultats
❌ Peut dépasser les limites du modèle

Le juste milieu

Pour la plupart des cas d'usage : 300-500 tokens par chunk avec 50-100 tokens de chevauchement

5 stratégies de chunking

1. Chunking à taille fixe

Découpage par nombre de caractères/tokens :

Tous les 500 tokens → nouveau chunk
Chevauchement : 50 tokens entre les chunks

Simple mais brutal. Peut couper en pleine phrase.

Idéal pour : Prototypes rapides, documents uniformes

2. Chunking par phrase

Découpage aux frontières de phrases :

Remplir le chunk jusqu'à ~500 tokens
Toujours terminer sur une phrase complète

Respecte les frontières naturelles du langage.

Idéal pour : Texte général, articles, documentation

3. Chunking par paragraphe

Conserver les paragraphes ensemble :

Chaque paragraphe = un chunk (si taille raisonnable)
Combiner les petits paragraphes
Découper les très grands paragraphes

Préserve la cohérence thématique.

Idéal pour : Documents bien structurés, rapports

4. Chunking sémantique

Découpage basé sur les changements de sens :

Utiliser l'IA pour détecter les changements de sujet
Commencer un nouveau chunk quand le sujet change

Le plus précis mais plus lent/coûteux.

Idéal pour : Documents complexes, contenu mixte

5. Chunking par structure de document

Suivre la hiérarchie du document :

Respecter les titres, sections, listes
Chaque section H2 = chunk logique
Tableaux conservés intacts

Exploite l'organisation de l'auteur.

Idéal pour : Documentation technique, manuels, contenu structuré

La question du chevauchement

Pourquoi chevaucher ?

Sans chevauchement :
Chunk 1 : "...l'entreprise a réalisé des ventes record."
Chunk 2 : "Cela est principalement dû à la nouvelle gamme de produits."

Le lien entre "ventes record" et "nouvelle gamme de produits" est perdu.

Avec chevauchement (2 dernières phrases répétées) :
Chunk 1 : "...l'entreprise a réalisé des ventes record."
Chunk 2 : "...réalisé des ventes record. Cela est principalement 
          dû à la nouvelle gamme de produits."

Contexte préservé aux frontières des chunks.

Quel niveau de chevauchement ?

10-15 % de la taille du chunk est typique
Exemple : chunks de 500 tokens, 50-75 tokens de chevauchement

Trop peu : rupture de contexte
Trop : stockage gaspillé, résultats dupliqués

Taille de chunk par cas d'usage

Erreurs courantes de chunking

1. Taille unique pour tout

Utiliser la même taille de chunk pour des FAQ et des contrats juridiques ❌
Les différents types de contenu nécessitent des stratégies différentes

2. Ignorer la structure

Couper un tableau entre deux chunks ❌
Séparer un titre de son contenu ❌
Fragmenter un bloc de code ❌

3. Pas de métadonnées

Chunk sans connaître son document source ❌
Aucune idée de quelle section il provient ❌

Toujours préserver : source, page, section, date

4. Ne jamais tester

Définir la taille de chunk une fois, sans jamais évaluer ❌
La qualité de récupération varie — testez et itérez

Les métadonnées : l'arme secrète

Les bons chunks incluent du contexte :

{
  "text": "La politique de retour autorise 30 jours...",
  "metadata": {
    "source": "politiques-clients.pdf",
    "section": "Retours & Remboursements",
    "page": 12,
    "last_updated": "2024-06-15"
  }
}

Cela permet :

• →Le filtrage par source
• →La citation de pages spécifiques
• →L'affichage de la fraîcheur
• →Le débogage des problèmes de récupération

Évaluation : votre chunking fonctionne-t-il ?

Testez avec des requêtes réelles

Question : "Quelle est la politique de congés pour les nouveaux employés ?"

Vérifiez :
1. Le bon chunk est-il récupéré ?
2. Contient-il la réponse complète ?
3. Y a-t-il trop de contenu non pertinent ?

Métriques à suivre

Précision de récupération : % de chunks récupérés qui sont pertinents
Rappel de récupération : % de chunks pertinents qui sont récupérés
Qualité de réponse : le LLM produit-il des réponses correctes ?

Points clés à retenir

1. →Chunking = découper les documents pour la récupération RAG
2. →La taille compte : 300-500 tokens en général, à ajuster selon le cas d'usage
3. →La stratégie compte : fixe, par phrase, par paragraphe, sémantique, structurel
4. →Le chevauchement préserve le contexte aux frontières (10-15 %)
5. →Les métadonnées rendent les chunks traçables et filtrables

Prêt à maîtriser le RAG ?

Cet article a couvert le quoi et le pourquoi des stratégies de chunking. Mais les systèmes RAG en production nécessitent une conception de bout en bout incluant le choix des embeddings, l'optimisation de la récupération et l'intégration.

Dans notre Module 5, RAG & Ingénierie de contexte, vous apprendrez :

• →La conception complète d'une architecture RAG
• →Les implémentations avancées de chunking
• →Les stratégies de recherche hybride
• →L'évaluation et l'optimisation de la récupération
• →Les patterns de déploiement en production

→ Explorer le Module 5 : RAG & Ingénierie de contexte