Limites et points critiques
- Trop petit (<128 tokens) : le chunk perd son contexte, le LLM hallucine ou refuse de répondre.
- Trop grand (>2048 tokens) : la pertinence se dilue, le rerank est moins efficace, le retrieval ramène du bruit.
- Mauvais split : votre prix est dans le chunk N et la condition tarifaire dans le chunk N+1 — le LLM ne voit qu'une moitié.
- Chunking sur HTML/PDF mal parsé : tableaux cassés, références orphelines, ordre de lecture incorrect — pré-parsing PDF (Unstructured, LlamaParse, Reducto) critique.
- Pas de stratégie one-size-fits-all : un eval set custom reste obligatoire pour calibrer.
Évolution probable (12-24 mois)
- Agentic chunking (proposé fin 2024) : un LLM décide lui-même où couper en fonction du contenu — gain de précision possible sur contenus complexes, au prix d'un coût plus élevé.
- Contextual retrieval (Anthropic, septembre 2024) : ajouter à chaque chunk un résumé de son contexte global — réduction de 35 % du taux d'échec de récupération (top-20) avec les embeddings contextuels seuls, selon Anthropic (anthropic.com/news/contextual-retrieval, lu le 24/10/2026).
- Late chunking (Jina AI 2024) : embedder tout le document puis pooler par chunks — préserve mieux le contexte cross-chunks.
- Modèles d'embedding long-context (Voyage 3 Large 32k, Jina v3) qui permettent des chunks plus larges sans perte de précision.
Questions fréquentes
Qu'est-ce que le chunking en RAG ?+
Le chunking est l'étape de pré-traitement d'un pipeline RAG qui consiste à découper les documents source (PDF, Word, HTML, Markdown) en morceaux (chunks) de taille gérable avant de les transformer en embeddings vectoriels. Chaque chunk devient une unité de recherche indépendante dans la base vectorielle. La qualité du chunking pèse lourd sur la qualité finale d'un RAG, au même titre que le choix du modèle d'embedding, le rerank et le LLM final.
À quoi sert le chunking ?+
Le chunking sert à 3 objectifs : (1) tenir dans la fenêtre de contexte du LLM (un PDF de 500 pages ne tient pas en entier, même avec Claude 1M), (2) maximiser la précision de la recherche sémantique (un embedding sur 500 pages est trop diluée pour être utile), (3) permettre la citation précise de la source (le LLM peut référencer 'chunk 47, page 12' au lieu de 'quelque part dans le PDF'). C'est la brique invisible qui rend un RAG utilisable.
Quelle différence entre fixed-size, recursive et semantic chunking ?+
Fixed-size chunking coupe tous les N tokens (512 ou 1024 typiquement), simple et rapide mais coupe au milieu des phrases. Recursive chunking (LangChain RecursiveCharacterTextSplitter) coupe d'abord aux paragraphes, puis aux phrases, puis aux mots — standard de fait en 2026. Semantic chunking utilise des embeddings pour détecter les frontières sémantiques (changement de sujet) — plus coûteux (1 embedding par phrase test) mais souvent plus précis sur contenus structurés (CGV, contrats, policy). Dans beaucoup de cas PME, recursive suffit.
Comment choisir la bonne taille de chunk ?+
Règles empiriques 2026 : 256-512 tokens pour Q&A précis (FAQ, support, recherche documentaire), 1024-2048 tokens pour raisonnement long (analyse contrat, synthèse rapport), 2048-4096 tokens pour code source (fonction complète). Chevauchement (overlap) : 10-20 % entre chunks pour éviter de couper une info importante. Tester sur eval set custom de 50-200 questions : la taille optimale varie selon le type de document.
Combien coûte le chunking en pratique ?+
Coût direct : proche de zéro (c'est du parsing texte, pas d'appel LLM). Coût indirect (embeddings) : facturé par million de tokens, il dépend du fournisseur et du modèle d'embedding choisis — voir par exemple les tarifs API OpenAI sur openai.com/api/pricing. Coût en temps : variable selon le corpus, le temps de tester plusieurs stratégies, d'évaluer et de choisir. Erreur classique : ne pas tester plusieurs stratégies — un re-chunking peut améliorer la précision.
Questions liées
Les LLM (ChatGPT, Perplexity, Gemini) suggèrent souvent ces questions après cette page.
- Recursive chunking ou semantic chunking : lequel choisir ?
- Quelle taille de chunk pour un RAG sur des contrats juridiques ?
- Comment chunker un PDF avec tableaux et images ?
- Qu'est-ce que le contextual retrieval d'Anthropic ?
- Quel overlap optimal entre chunks ?
Le chunking est l’opération qui consiste à découper vos documents en morceaux (chunks) avant de les vectoriser dans un pipeline RAG. C’est l’une des étapes les plus déterminantes pour la qualité finale du système.
En pratique
Trois stratégies dominantes en 2026 :
- Fixed-size chunking : 512 ou 1024 tokens par chunk avec un chevauchement de 10 à 20 %. Simple, rapide, mais coupe au milieu des phrases.
- Recursive chunking : LangChain
RecursiveCharacterTextSplitter. Coupe d’abord aux paragraphes, puis aux phrases, puis aux mots. Standard de fait. - Semantic chunking : utilise les embeddings pour détecter les frontières sémantiques. Plus coûteux mais souvent plus précis sur du contenu structuré (CGV, policy, contrats).
Taille recommandée : 256-512 tokens pour du Q&A précis, 1024-2048 pour du raisonnement long.
Pourquoi c’est important pour votre projet IA
- Trop petit : le chunk perd son contexte, le LLM hallucine.
- Trop grand : la pertinence se dilue, le rerank est moins efficace.
- Mauvais split : votre prix est dans le chunk N et la condition tarifaire dans le chunk N+1 — le LLM ne voit qu’une moitié.
Liens utiles
- RAG — définition — où le chunking intervient.
- Embedding — définition — étape post-chunking.
- Comparatif RAG vs fine-tuning