Pourquoi le chunking est critique
Le chunking (découpage des documents) est la première étape d'un pipeline RAG. Un mauvais chunking produit des embeddings de faible qualité et dégrade la pertinence du retrieval. Le choix de la stratégie et de la taille des chunks impacte directement la qualité des réponses.
Les stratégies principales
Fixed-size chunking
Découpage à taille fixe (ex: 512 tokens) avec chevauchement (overlap) optionnel.
- Avantages : simple, prévisible, rapide
- Inconvénients : coupe les phrases et le contexte sémantique
- Usage : documents homogènes, logs, données tabulaires
Recursive character splitting
Stratégie par défaut de LangChain. Découpe récursivement selon des séparateurs hiérarchiques (\n\n, \n, . , ).
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200,
separators=["\n\n", "\n", ". ", " "]
)Semantic chunking
Utilise les embeddings pour détecter les ruptures sémantiques. Regroupe les phrases similaires.
- LlamaIndex propose
SemanticSplitterNodeParser - Plus lent mais produit des chunks cohérents thématiquement
- Idéal pour les documents longs avec des sujets variés
Document-aware chunking
Exploite la structure du document (Markdown headers, HTML tags, PDF sections).
from langchain.text_splitter import MarkdownHeaderTextSplitter
headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers)Comment choisir la taille
- 256-512 tokens : Questions précises, FAQ, recherche factuelle
- 512-1024 tokens : Documents techniques, tutoriels
- 1024-2048 tokens : Analyses longues, rapports, contexte riche nécessaire
Règles pratiques
- Toujours utiliser un overlap de 10-20% pour préserver le contexte aux frontières
- Tester avec votre dataset réel et mesurer avec des métriques de retrieval
- Adapter la taille au modèle d'embedding (la plupart performent mieux sous 512 tokens)
- Conserver les métadonnées (source, page, section) avec chaque chunk