Chunking RAG : découper ses documents sans perdre en précision

Le chunking : pourquoi tout le monde en parle (et pourquoi tout le monde se trompe)

Beaucoup d’équipes abordent le chunking comme un détail technique :

“On coupe en 500 tokens avec 50 d’overlap et voilà.”

Ça fonctionne… jusqu’au jour où :

• votre base de connaissances grossit,
• vos documents deviennent hétérogènes (PDF, slides, tableaux, procédures),
• votre entreprise invente des acronymes plus vite que vous n’indexez,
• vous ajoutez des filtres d’accès (ACL, multi‑tenant),
• et vos utilisateurs commencent à chercher avec des requêtes “réelles”.

Le chunking n’est pas une règle fixe. C’est un contrat entre :

• votre retrieval (ce qu’il sait retrouver),
• votre modèle (ce qu’il sait utiliser),
• vos documents (comment l’information est réellement structurée),
• vos contraintes (latence, coût, conformité).

La définition utile : un chunk n’est pas un “morceau de texte”

Un chunk, c’est une unité de récupération.
Son job n’est pas d’être “joli”. Son job est :

• d’être retrouvable,
• d’être compréhensible sans sa famille élargie,
• d’être injectable dans un prompt sans faire exploser le contexte,
• d’être traçable (source, page, version).

Dans le glossaire : RAG, Base de connaissances, Embedding.

Le problème central : taille, bruit, et “lost in the middle”

Trop gros : le signal se dilue

Quand un chunk est trop long :

• il contient plusieurs idées,
• il génère des embeddings “moyennés” (donc moins discriminants),
• il injecte du bruit au LLM,
• il augmente le coût (tokens),
• et il devient plus difficile à reranker proprement.

Trop petit : le sens se casse

Quand un chunk est trop court :

• il perd le contexte (“ceci”/“cela”, conditions, exceptions),
• il fait exploser le nombre de chunks,
• il augmente les risques de contradictions (vous retrouvez des fragments incompatibles),
• il force le LLM à faire des hypothèses.

Et au milieu : l’attention n’est pas uniforme

Sur des contextes longs, il existe des effets d’attention où l’information placée au milieu est moins bien exploitée (“lost in the middle”).²

Implication pratique :

• votre top‑k doit être court et bien ordonné,
• les chunks doivent être “denses” en information utile,
• la structure (titres, résumés, hiérarchie) devient un super‑pouvoir.

Les 6 décisions qui font 80% de la qualité

1) Quelle est votre unité “naturelle” ?

Selon vos documents, l’unité naturelle peut être :

• un paragraphe,
• une section (titre + contenu),
• une règle (si/alors/sauf),
• une ligne de tableau + son header,
• une page (rarement bon, parfois nécessaire).

2) Qu’est-ce qui doit rester “collé” ?

Exemples typiques :

• définition + exemple,
• condition + exception,
• procédure + prérequis,
• tableau + légendes.

Si vous coupez ces couples, vous obtenez des réponses qui semblent logiques… mais qui sont juridiquement fausses. Et ça, ce n’est pas un bug, c’est une carrière alternative involontaire.

3) Quel overlap (et pourquoi) ?

L’overlap est utile pour ne pas couper une phrase en deux idées.
Mais trop d’overlap :

• augmente la redondance,
• pollue le retrieval,
• gonfle les coûts.

Un overlap n’est pas une superstition. C’est un pansement. Si vous avez besoin d’un overlap énorme, votre unité de chunking n’est probablement pas la bonne.

4) Quels champs “titres / contexte” injecter ?

Astuce simple : un chunk sans titre est souvent moins retrouvable.

Pattern robuste :

• stocker le titre de section comme metadata,
• éventuellement l’ajouter au texte chunké (“Section: …”),
• garder un chemin hiérarchique (Doc → Chapitre → Section).

5) Comment versionner ?

En entreprise, les docs changent.
Donc :

• version de document,
• date de publication,
• source de vérité (URL, dépôt, CMS),
• stratégie de re‑indexation.

Sans ça, votre RAG devient un système qui “répond juste… mais sur la version 2021”.

6) Quelle stratégie de retrieval derrière ?

Chunking et retrieval sont un couple :

• hybride (BM25 + vecteurs) → chunks doivent contenir des termes exacts (codes),
  guide : /blog/chatbot/technique/recherche-hybride-bm25-vecteurs-reranking-rag
• reranking → chunks doivent être lisibles et comparables,
  guide : /blog/chatbot/technique/reranking-rag-cross-encoder-vs-llm-reranker
• filtres ACL → chunks doivent porter des métadonnées (tenant, entitlements),
  guide : /blog/chatbot/technique/metadonnees-acl-rag-multitenant-filtrage

Les stratégies de chunking qui comptent en 2026

Stratégie A — Fixed-size (token/char) : le “marteau”

Le plus simple : découper tous les n tokens.

Quand ça marche :

• corpus homogène (FAQ courtes),
• documents bien rédigés et réguliers,
• besoin de vitesse d’implémentation.

Quand ça mord :

• procédures longues,
• tableaux,
• PDF (headers/footers),
• règles avec exceptions.

Stratégie B — Recursive / structure-aware : la meilleure baseline

Le splitter récursif découpe en respectant une hiérarchie : paragraphes → phrases → tokens, en visant une taille cible.
LangChain documente ce pattern (RecursiveCharacterTextSplitter).¹

Ce n’est pas “magique”, mais c’est un excellent baseline, car :

• il respecte mieux la structure naturelle,
• il évite les chunks absurdes (couper au milieu d’une liste),
• il réduit le besoin d’overlap.

Stratégie C — Chunking par sections (Markdown/HTML) : “comme c’est écrit”

Si vos documents ont déjà une structure :

• titres,
• sous‑titres,
• listes,
• blocs “attention”,

…utilisez‑la.

Pattern :

• chunk = section,
• metadata = titre + chemin,
• fallback = découpe récursive si section trop grande.

Stratégie D — Parent‑child retrieval : le compromis “précision + contexte”

Idée :

• vous indexez des petits chunks (child) pour retrouver précisément,
• mais vous injectez au LLM un parent plus large (ou plusieurs parents) pour garder le contexte.

Ça résout un cas classique :

• retrieval veut petit,
• génération veut grand.

Le parent‑child vous évite d’avoir à choisir un camp.

Stratégie E — Hiérarchies (RAPTOR) : résumer pour mieux retrouver

RAPTOR propose une approche hiérarchique : construire une arborescence de résumés et de segments, puis faire du retrieval à plusieurs niveaux.³

Pratique quand :

• vos documents sont longs,
• les requêtes sont “haut niveau” (“résume la politique de remboursement”),
• vous voulez éviter d’injecter 12 pages de procédure au LLM.

Risque :

• vos résumés deviennent une source de vérité secondaire,
• donc il faut tracer et relier au texte original.

Stratégie F — Late chunking : embeddings plus contextualisés

Le “late chunking” (au sens du papier) vise à produire des embeddings de chunks en tenant compte du contexte du document plutôt qu’en encodant chaque chunk isolément.⁴

Intuition : si vous encodez une phrase “Conditions d’annulation” sans le reste du document, son embedding est moins informatif que si vous encodez la phrase dans son contexte.

C’est une piste intéressante si :

• vous avez un encoder long‑contexte,
• vous cherchez à améliorer le retrieval sur des docs longs,
• vous avez déjà un chunking structurel correct.

La table “zéro à héros” (comparatif chunking)

PDF, images, scans : le chunking commence avant le texte

Quand votre document est un PDF, vous avez deux problèmes :

1. extraire du texte fiable,
2. préserver la structure (titres, tableaux, pages, colonnes).

Et c’est là que beaucoup de stacks se trompent de combat.

VLM direct vs OCR + texte : le bon choix dépend du volume

Un VLM peut “comprendre” une page, mais :

• sur des documents de 80 pages,
• avec des tableaux,
• et une exigence de traçabilité,

…il n’est pas forcément la meilleure option.

Options OCR :

• open source : Tesseract, PaddleOCR,⁵⁶
• commercial : solutions “Document AI” des hyperscalers, et offres spécialisées.

Pour aller plus loin :

• Visual RAG : PDF longs, OCR, layout, VLM
• Traitement de pièces jointes : OCR vs VLM

Nettoyer le texte : l’étape invisible qui vaut une semaine

Le chunking sur OCR brut, c’est comme cuisiner avec du sable :

• headers/footers dupliqués,
• numéros de page partout,
• tableaux “cassés”,
• ligatures, erreurs de reconnaissance.

Avant de chunker :

• dédupliquez les headers/footers,
• reconstruisez les paragraphes,
• conservez les coordonnées/page pour la traçabilité,
• gérez les tableaux (au moins header + lignes).

Chunking + metadata : le duo qui rend votre RAG “entreprise”

Un chunk sans métadonnées est un chunk qui :

• fuit (si ACL non gérées),
• dérive (si versions non suivies),
• et devient inexpliquable (“d’où sort cette info ?”).

Minimum recommandé :

• source (doc id, URL),
• date/version,
• section/titre,
• langue,
• produit/BU,
• droits (tenant, groupe).

Guide : ACL & métadonnées RAG.

Comment valider votre chunking (sans attendre la prod)

Vous ne validez pas un chunking “à l’intuition”.
Vous le validez comme un produit :

1. retrieval eval : les bons passages sont-ils dans le top‑k ?
2. end‑to‑end eval : les réponses sont-elles plus grounded, plus courtes, plus stables ?

Guide : Évaluation chatbot IA.

Méthode : un chunking prod en 5 jours (audit + itération)

1

Échantillonnez 20 documents représentatifs

Mélangez : procédures, fiches produit, PDF, contrats, tableaux. Ne trichez pas : prenez ce que vos équipes utilisent vraiment.

2

Dessinez la structure : titres, sections, objets

Identifiez les unités naturelles (sections, règles, tableaux). C’est votre grille de chunking. Si vous ne la voyez pas, c’est que vos docs sont déjà un problème (et votre RAG ne le cachera pas).

3

Implémentez une baseline structure-aware (avec fallback)

Sections quand possible, splitter récursif sinon.¹ Gardez un id stable par chunk et des métadonnées complètes.

4

Testez retrieval + rerank sur un set de requêtes réel

Évaluez top‑k. Puis ajoutez un reranker si nécessaire. Guides : /blog/chatbot/technique/recherche-hybride-bm25-vecteurs-reranking-rag et /blog/chatbot/technique/reranking-rag-cross-encoder-vs-llm-reranker.

5

Itérez : là où ça casse, c’est là où ça compte

Ajustez la taille cible, la segmentation des tableaux, le parent‑child si besoin, et re‑mesurez. Le chunking est une boucle, pas un choix unique.

FAQ — Chunking RAG

Questions frequentes

Quelle est la “meilleure” taille de chunk ?+

Il n’y a pas de taille magique. Commencez par une approche structure-aware (sections + fallback récursif) puis ajustez avec des métriques : qualité top‑k, coût, groundedness. Si vous cherchez une taille “par défaut”, vous cherchez en réalité un processus d’évaluation.

Overlap : indispensable ?+

Utile, mais pas systématique. L’overlap sert à éviter des coupures absurdes. Si vous en mettez trop, vous créez de la redondance qui pollue le retrieval et augmente les coûts.

Parent-child : ça vaut la complexité ?+

Souvent oui, sur des procédures et des règles. Vous retrouvez précisément (child) tout en injectant un contexte utilisable (parent). C’est un très bon compromis quand le fixed‑size échoue.

RAPTOR : c’est juste du résumé ?+

C’est une hiérarchie qui combine résumés et segments pour retrouver à plusieurs niveaux.³ C’est utile sur des documents longs, mais il faut tracer le lien entre résumé et source pour éviter la dérive.

Late chunking : je dois l’utiliser ?+

Pas en premier. Commencez par un chunking structurel propre + métadonnées + reranking. Ensuite, si vous avez encore des limites sur docs longs, explorez late chunking pour des embeddings plus contextualisés.⁴

Chunking sur PDF : VLM direct ou OCR ?+

Sur quelques pages très visuelles, VLM peut être excellent. Sur des documents longs et volumineux, OCR + extraction structurée + retrieval est souvent plus stable et scalable. Voir : /blog/chatbot/technique/visual-rag-pdf-documents-longs-ocr-layout-vlm.

Sources et references

1. [1]LangChain, “RecursiveCharacterTextSplitter” (documentation).
2. [2]Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (arXiv).
3. [3]Sarthi et al., “RAPTOR: Recursive Abstractive Processing for Tree‑Organized Retrieval” (arXiv).
4. [4]Li et al., “Late Chunking: Contextual Chunk Embeddings Using Long‑Context Transformers” (arXiv).
5. [5]GitHub, “tesseract‑ocr/tesseract”.
6. [6]GitHub, “PaddlePaddle/PaddleOCR”.