Stratégies de chunking pour le RAG : taille, chevauchement et découpage par structure

Le chunking consiste à découper un document en morceaux (chunks) avant de les indexer pour la recherche. C'est souvent le réglage qui a le plus d'impact sur la qualité des réponses d'un RAG, bien avant le choix du modèle de langage. Ce guide compare les quatre grandes stratégies de découpage, explique le rôle du chevauchement et donne des tailles de chunk par défaut selon le type de document.

Pourquoi le chunking détermine la qualité des réponses

Dans un système RAG, la recherche ne porte jamais sur le document entier mais sur des fragments indexés séparément (consultez notre guide sur le fonctionnement du RAG pour le détail du processus complet). Si un chunk est trop petit, il manque de contexte et la recherche remonte une phrase isolée, difficile à interpréter. S'il est trop grand, il noie l'information utile dans du bruit et dépasse parfois la fenêtre de contexte utile du modèle, ce qui dilue la pertinence de la réponse.

Le chunking intervient juste après l'extraction du texte et juste avant le calcul des embeddings. Pour comprendre comment ces trois étapes s'articulent, notre article sur chunking, indexation et recherche détaille l'ensemble du pipeline. Chaque chunk devient ensuite un vecteur : si vous ne savez pas exactement ce que représente ce vecteur, l'article sur les embeddings expliqués simplement comble cette lacune avant d'aller plus loin.

Les quatre grandes stratégies de découpage

Le découpage à taille fixe

La méthode la plus simple : on découpe le texte tous les N caractères ou tous les N tokens, sans se soucier de la ponctuation ni de la structure. C'est rapide à mettre en œuvre et prévisible en volume, mais le risque est de couper une phrase ou un tableau en plein milieu, ce qui rend le fragment incompréhensible hors contexte. Cette approche convient pour un prototype rapide ou des textes très homogènes (journaux de logs, transcriptions brutes), mais elle est rarement optimale pour des documents métier.

Le découpage par phrase ou par paragraphe

On respecte les frontières naturelles du texte : point final, retour à la ligne, changement de paragraphe. Les fragments obtenus sont lisibles isolément, ce qui améliore nettement la qualité des citations affichées à l'utilisateur. L'inconvénient est la variabilité de taille : un paragraphe peut faire trois lignes ou trois pages, ce qui complique le calibrage de l'index et peut créer des chunks trop longs pour certains contrats ou rapports très denses.

Le découpage sémantique

Plutôt que de se fier à la ponctuation, cette approche mesure la similarité entre phrases consécutives (via leurs embeddings) et place une coupure là où le sujet change réellement. Le résultat est un découpage qui suit le sens plutôt que la forme, utile sur des documents longs et peu structurés comme des comptes rendus de réunion ou des retranscriptions d'entretien. Le coût est plus élevé : il faut calculer des embeddings intermédiaires avant même de construire l'index final, ce qui ralentit l'ingestion.

Le découpage par structure (structure-aware)

Cette stratégie s'appuie sur la structure explicite du document : titres Markdown, articles d'un contrat, sections d'une convention collective, cellules d'un tableau. Chaque chunk correspond à une unité logique complète (un article de loi, une clause, une section numérotée), souvent enrichie des titres parents pour conserver le contexte hiérarchique. C'est en général la méthode qui donne les meilleures citations, car un fragment correspond à ce qu'un lecteur humain considérerait comme une unité de sens. Elle demande toutefois un minimum de structuration en amont, un point détaillé dans notre guide pour préparer ses documents pour l'IA.

• Taille fixe : simple et rapide, mais coupes arbitraires fréquentes
• Par phrase/paragraphe : lisible, taille variable à surveiller
• Sémantique : suit le sens, coût de calcul plus élevé à l'ingestion
• Par structure : meilleures citations, nécessite des documents bien structurés (titres, numérotation)

Le chevauchement (overlap) : à quoi ça sert et combien en mettre

Le chevauchement consiste à répéter une partie du texte d'un chunk à la fin du précédent et au début du suivant, pour éviter qu'une information importante se retrouve coupée exactement à la frontière entre deux fragments. Sans overlap, une clause qui commence à la toute fin d'un chunk et se termine au début du suivant risque de n'être jamais retrouvée intégralement par la recherche.

En pratique, un chevauchement de 10 à 20 % de la taille du chunk est un bon point de départ : par exemple 50 à 100 tokens de recouvrement pour des chunks de 500 tokens. Au-delà de 20-25 %, le gain devient marginal et l'index gonfle inutilement en volume, ce qui augmente le coût de stockage et peut ralentir la recherche sans améliorer la pertinence.

Comment la taille du chunk influence la qualité des réponses

Il n'existe pas de taille universelle, mais les tendances suivantes se vérifient sur la plupart des corpus métier :

Un repère utile : la taille du chunk doit correspondre à peu près à la plus petite unité d'information qu'un utilisateur formulerait dans sa question. Pour une convention collective, c'est souvent un article ou un paragraphe d'article (voir par exemple comment une seule clause change tout dans notre analyse du forfait 218 jours dans la convention Syntec). Pour une FAQ, c'est une question-réponse entière. Pour un rapport financier, c'est souvent une section ou un tableau complet.

Des valeurs par défaut qui fonctionnent dans la pratique

1. Documents juridiques et contractuels (conventions collectives, contrats, marchés publics) : découpage par structure, un chunk par article ou clause, overlap faible (0-10 %)
2. Documentation technique et manuels : découpage par structure (titres Markdown ou HTML), chunks de 300-600 tokens, overlap de 10-15 %
3. Rapports et comptes rendus continus : découpage sémantique ou par paragraphe, chunks de 400-700 tokens, overlap de 15-20 %
4. FAQ et bases de connaissances questions-réponses : un chunk par paire question-réponse, sans découpage supplémentaire
5. Transcriptions et journaux : découpage à taille fixe ou par phrase, chunks courts (150-300 tokens), overlap de 15-20 % pour compenser l'absence de structure

Ces valeurs sont des points de départ, pas des règles absolues : le bon réglage dépend toujours du type de questions posées. Une base utilisée pour retrouver un chiffre précis (un seuil, un taux, un délai) tolère des chunks plus courts qu'une base utilisée pour des réponses qui demandent de recouper plusieurs paragraphes, comme c'est le cas pour des questions de conformité LCB-FT ou de calcul d'indemnités.

Tester et ajuster son chunking sans tout reconstruire

La meilleure façon de valider une stratégie de chunking reste de l'essayer sur de vrais documents et de vraies questions, puis de regarder les passages cités dans les réponses : sont-ils complets et compréhensibles isolément, ou coupés au mauvais endroit ? Sur Kopik, l'extraction, le découpage et l'indexation hybride (plein texte et recherche sémantique) sont gérés automatiquement lors de l'import d'un document, ce qui permet de comparer rapidement les résultats sur plusieurs formats (PDF, Word, Markdown) sans écrire de code. Si vous préférez garder la main sur le pipeline, la documentation développeurs détaille l'API et le serveur MCP pour interroger vos bases depuis votre propre code ou depuis un client comme Claude ou Cursor.

Dans tous les cas, gardez un œil sur la qualité des citations renvoyées : un chunk mal découpé se repère vite, car la réponse cite un fragment de phrase incomplet ou une clause amputée de sa condition. Pour aller plus loin sur ce point, notre article sur la vérification des réponses sourcées par l'IA propose une méthode pour auditer systématiquement ce que votre RAG affiche.

En résumé

Le chunking n'est pas un détail technique secondaire : c'est souvent le levier le plus rentable pour améliorer un RAG, avant même de changer de modèle ou de base vectorielle. Privilégiez le découpage par structure quand vos documents en ont une, ajoutez un chevauchement modéré pour sécuriser les frontières, et calibrez la taille sur le type de question posée plutôt que sur une valeur générique trouvée en ligne. Pour une vision d'ensemble du RAG avant de se plonger dans ces détails, notre guide pratique du RAG reste la meilleure porte d'entrée.