Le chunking est le facteur n°1 de la qualité d'un RAG
Avant de changer de modèle d'embedding ou de LLM, vérifiez votre stratégie de chunking. La façon dont vous découpez vos documents en fragments détermine 60% de la qualité des résultats de votre chaîne RAG. Un chunk trop petit perd le contexte. Un chunk trop grand noie l'information pertinente dans du bruit. Un découpage qui coupe une phrase en deux rend le passage inutilisable. Les bonnes pratiques : adapter la taille au type de document, utiliser un overlap de 10 à 20%, et enrichir chaque chunk avec des métadonnées (titre de section, numéro de page, date).
Le problème
Votre assistant IA donne des réponses partielles. Il cite un paragraphe qui commence au milieu d'une phrase. Il mélange des informations de deux sections différentes. Ou il ne trouve tout simplement pas l'information alors qu'elle existe bien dans la base documentaire. Dans 60% des cas, le problème n'est pas le LLM — c'est le chunking.
Le chunking (découpage des documents en fragments indexables) est la première étape du pipeline RAG, et c'est celle qui est le plus souvent négligée. La plupart des équipes utilisent un RecursiveCharacterTextSplitter avec les paramètres par défaut (1000 caractères, 200 d'overlap) sans jamais mesurer l'impact sur la qualité du retrieval.
Les problèmes les plus courants d'un mauvais chunking :
- Chunks orphelins — Un fragment commence par « De plus, ce taux… » sans que le contexte précédent soit disponible. Le retriever remonte un passage incompréhensible, le LLM hallucine pour combler les trous.
- Chunks trop volumineux — Un chunk de 2000 tokens contient 3 sujets différents. Le retriever le sélectionne pour un sujet, mais le LLM se laisse distraire par les deux autres. Résultat : une réponse diluée qui mélange les thèmes.
- Perte de structure — Les titres, sous-titres, tableaux et listes à puces sont aplatis en texte brut. Le LLM perd la hiérarchie de l'information et traite un titre de section comme une phrase de contenu.
- Absence de métadonnées — Impossible de filtrer par date, par auteur ou par type de document. Le retriever cherche dans toute la base alors qu'une simple requête filtrée aurait trouvé le résultat en premier.
La solution IA
Une stratégie de chunking efficace combine trois approches complémentaires, adaptées à la nature de vos documents et à vos cas d'usage.
Chunking structurel (par section)
Découpez en suivant la structure native du document : titres, sous-titres, paragraphes. Utilisez les marqueurs Markdown ou HTML comme points de découpe naturels. Chaque chunk hérite du titre de sa section parent comme métadonnée. Idéal pour la documentation technique, les wikis et les manuels. Implémentation : MarkdownHeaderTextSplitter (LangChain) ou SentenceSplitter (LlamaIndex).
Chunking sémantique (par thème)
Utilisez un modèle d'embedding pour détecter les ruptures thématiques dans un texte long. Quand la similarité cosinus entre deux phrases consécutives chute sous un seuil (ex : 0.75), c'est un point de découpe naturel. Meilleur pour les documents narratifs longs (rapports, études, articles). Implémentation : SemanticChunker (LangChain) ou avec sentence-transformers.
Enrichissement par métadonnées
Chaque chunk est associé à un jeu de métadonnées : titre de la section parente, numéro de page, date du document, auteur, type de document. Ces métadonnées permettent un filtrage pré-retrieval qui réduit le bruit de 40%. Indispensable quand votre base contient des milliers de documents de nature différente.
Mise en oeuvre
L'optimisation du chunking se fait en trois phases itératives. Chaque phase produit des résultats mesurables grâce aux métriques d'évaluation RAG.
Audit de la base documentaire (semaine 1)
Classifiez vos documents par type : technique (manuels, API docs), juridique (contrats, CGV), commercial (fiches produit, présentations) et conversationnel (emails, tickets). Pour chaque type, analysez la structure (titres, tableaux, listes) et la longueur moyenne. Définissez une stratégie de chunking par type de document : taille cible, méthode de découpe, métadonnées à extraire. Documentez le tout dans un fichier de configuration versionné.
Implémentation et benchmark (semaines 2-3)
Implémentez 3 variantes de chunking pour votre corpus principal : taille fixe (512 tokens), structurel (par section) et sémantique. Pour chaque variante, réindexez un échantillon de 500 documents et exécutez votre Golden Set d'évaluation. Comparez les scores de context recall et context precision. Dans notre expérience, le chunking structurel surpasse le taille fixe de 15 à 25% sur les documents bien formatés.
Optimisation fine et monitoring (semaine 4)
Ajustez les paramètres de la stratégie gagnante : taille du chunk (testez 256, 512, 768, 1024), overlap (10%, 15%, 20%), métadonnées incluses. Mettez en place un pipeline de réindexation automatique qui se déclenche à chaque ajout de document. Monitorez le context recall en production pour détecter les dégradations. Prévoyez une revue trimestrielle de la stratégie de chunking.
Résultats
Résultats mesurés chez nos clients après optimisation de la stratégie de chunking sur des projets RAG entreprise.
Questions fréquentes
Quelle est la taille idéale d'un chunk pour un RAG ?
Il n'existe pas de taille universelle. Pour des documents techniques ou juridiques, 512 à 1024 tokens offrent le meilleur compromis entre contexte suffisant et précision du retrieval. Pour des FAQ ou des fiches produit, 256 à 512 tokens sont préférables. La règle empirique : un chunk doit contenir une idée complète et autosuffisante. Testez 3 tailles différentes sur votre Golden Set et mesurez le context recall.
Qu'est-ce que l'overlap et pourquoi est-il important ?
L'overlap (chevauchement) consiste à répéter les dernières phrases d'un chunk au début du chunk suivant. Un overlap de 10 à 20% de la taille du chunk évite de couper une information en deux morceaux incomplets. Par exemple, avec des chunks de 512 tokens et un overlap de 64 tokens, les 64 derniers tokens du chunk N sont aussi les 64 premiers du chunk N+1. Cela améliore le recall de 5 à 15% selon nos benchmarks.
Faut-il utiliser le chunking sémantique ou par taille fixe ?
Le chunking par taille fixe (RecursiveCharacterTextSplitter dans LangChain) est suffisant pour 80% des cas d'usage. Le chunking sémantique (qui détecte les ruptures thématiques via embeddings) améliore les résultats de 10 à 20% sur des documents longs et hétérogènes (rapports annuels, documentation technique multi-sujets). Commencez par le chunking fixe, mesurez vos métriques, puis testez le sémantique uniquement si le context precision est insuffisant.
Pour les profils tech
Implémentation technique du chunking
Le choix de la stratégie de chunking dépend de votre stack technique et de la nature de vos documents. Voici les implémentations de référence avec LangChain et LlamaIndex.
Configuration recommandée par type de document :
- Documentation technique (Markdown/HTML) — MarkdownHeaderTextSplitter + chunk_size=768, overlap=128. Préservez les titres comme métadonnées.
- PDF complexes (tableaux, colonnes) — Extraction via Unstructured.io ou PyMuPDF, puis chunking structurel. Traitez les tableaux comme des chunks autonomes.
- Contrats juridiques — Chunking par article/clause via regex, chunk_size=1024, overlap=200. Métadonnées : numéro d'article, date, parties.
- FAQ / fiches produit — Un chunk par question-réponse ou par fiche. Pas d'overlap nécessaire. Métadonnées : catégorie, produit, date de mise à jour.
Comparatif des stratégies de chunking
| Critère | Structurel (sections) | Taille fixe | Sémantique |
|---|---|---|---|
| Context Recall | 0.82 | 0.65 | 0.85 |
| Context Precision | 0.78 | 0.60 | 0.80 |
| Complexité d'implémentation | Moyenne | Faible | Élevée |
| Coût de calcul | Faible | Faible | Moyen (embeddings) |
| Adapté aux docs structurés | Excellent | Correct | Bon |