Le chunking découpe vos documents en morceaux indexables pour un RAG. Trop gros, le modèle noie le signal ; trop petit, le sens se brise. Voici ce que le mot désigne, comment l’ajuster, et pourquoi c’est souvent le vrai levier avant d’acheter du matériel.
Définition
Dans un pipeline RAG, on ne donne rarement le PDF entier au modèle à chaque question. On indexe des passages. Le chunking définit la taille typique de ces passages, parfois un chevauchement (overlap), et la stratégie de coupe (par caractères, tokens, titres, pages…). Mal coupé, un raisonnement éclate au milieu d’une phrase ou un tableau perd ses en-têtes.
Ce que le mot ne désigne pas : ce n’est pas la base vectorielle (là où l’on stocke), ni le reranker (qui reclasse après coup), ni la recherche hybride (mots-clés + sens). Ce n’est pas non plus une preuve que « plus de chunks = meilleures réponses ». Trop de petits fragments bruyants peut polluer la récupération autant qu’un pavé trop long.
Un bon chunking se juge au rappel : le passage utile apparaît-il parmi les candidats ? et à la lisibilité : le modèle reçoit-il assez de contexte pour répondre sans inventer le milieu de phrase manquant ? Ces deux critères battent n’importe quel chiffre de « tokens idéaux » copié sur Internet sans rapport avec votre corpus.
Un exemple du quotidien
Imaginez un classeur trop épais. Pour retrouver une info, vous avez découpé des pochettes thématiques. Si chaque pochette contient un chapitre entier, vous ramenez trop de papier. Si chaque pochette ne contient qu’une ligne, vous perdez le contexte. Le chunking, c’est le calibrage de ces pochettes pour votre corpus et vos questions typiques.
Dans un outil comme Open WebUI, des réglages de taille de chunk et d’overlap apparaissent souvent dans l’admin documents. Ce ne sont pas des curseurs magiques universels. Une procédure RH et un catalogue de pièces détachées ne se découpent pas pareil. Testez avec des questions dont vous connaissez la page source.
Un exemple en Hauts-de-France
À Saint-Quentin, un cabinet comptable indexe des notes de doctrine et des check-lists internes (hors dossiers clients nominatifs au début). Les premiers essais ratent des mentions d’articles parce que les chunks coupent au milieu des références. En ajustant la taille et en préservant mieux les titres, les réponses citent enfin le bon passage. Le modèle n’a pas « appris la compta » : le découpage est devenu lisible.
Lors d’un atelier à Laon, l’animateur fait comparer deux stratégies sur le même PDF public régional. Les participants voient qu’un reranker aide, mais qu’un chunking absurde limite tout. On croise aussi le matériel : injecter trop de passages longs coûte du contexte et de la mémoire, même avec une belle interface.
On confond souvent
Première confusion : croire qu’il existe une taille de chunk universelle. Faux. Elle dépend de la langue, de la structure des documents, de la longueur de contexte du modèle, et du type de questions. Les ordres de grandeur qu’on lit en ligne sont des points de départ, pas des lois. Mesurez sur votre corpus.
Deuxième confusion : confondre chunking et résumé. Découper n’est pas condenser. Autre mélange : penser que l’overlap « répare tout ». Un chevauchement aide à ne pas perdre une phrase frontière ; il n’invente pas de structure dans un scan illisible. Nettoyez d’abord le document source quand c’est possible.
En pratique, que faire avec ce mot
Commencez avec une stratégie simple (coupe par taille raisonnable + overlap modéré), indexez un petit corpus propre, posez vingt questions réelles, notez les ratés. Puis ajustez : plus petit si le bruit domine, plus grand si le sens se brise, ou coupe par titres si vos docs sont bien structurés. Activez ensuite hybride et reranker si besoin.
Documentez les réglages retenus (taille, overlap, outil). Croisez base vectorielle, recherche hybride et le tutoriel Qwen pour une stack complète. Refusez les tableaux qui promettent « exactement N tokens » comme vérité universelle. Et n’indexez pas de données que vous n’avez pas le droit de centraliser.
En pratique régionale, testez le chunking sur un corpus public local (délibération anonymisée, guide d’aide, règlement d’occupation) avant d’y mettre des dossiers sensibles. Observez si les réponses citent le bon passage ou un voisin trompeur. Ajustez taille et chevauchement seulement après avoir vu trois échecs réels. Cette discipline évite de régler au feeling et produit une configuration explicable à un collègue non technicien.
Termes voisins
- Overlap
- Chevauchement entre chunks voisins pour limiter les coupures malheureuses en frontière.
- Embedding
- Représentation numérique du sens d’un chunk, utilisée pour la recherche sémantique.
- Reranker
- Reclasse les passages candidats après la première recherche. Voir reranker.
- Recherche hybride
- Combine mots-clés et similarité sémantique. Voir recherche hybride.
Pour aller plus loin
Pour la suite du pipeline : reranker, base vectorielle, recherche hybride. Ateliers : l’agenda. Communauté : l’inscription.
Questions fréquentes
Pourquoi découper les documents ?
Parce qu’un RAG retrouve et injecte des passages, pas nécessairement un livre entier à chaque question. Le découpage crée des unités indexables et injectables dans la fenêtre de contexte. Sans découpage adapté, soit vous dépassez le contexte, soit vous ramenez du bruit, soit vous cassez des idées au milieu. Le chunking est donc un geste de conception, pas un détail cosmétique. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
Quelle taille de chunk choisir ?
Il n’y a pas de chiffre unique honnête hors corpus. Partez d’un ordre de grandeur courant dans votre outil, puis validez par tests. Si vos questions portent sur des détails localisés, des chunks plus petits aident souvent. Si elles exigent un raisonnement sur un paragraphe entier, élargissez. Gardez une trace des essais pour vos collègues. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
L’overlap est-il obligatoire ?
Non, mais il est souvent utile pour éviter qu’une phrase clé soit coupée entre deux chunks. Un overlap excessif grossit l’index et peut dupliquer du bruit. Commencez modéré, observez les frontières ratées, ajustez. L’overlap ne remplace pas une structure de document claire (titres, listes, tableaux propres). Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant. Conservez la version d’outil et du modèle pour pouvoir expliquer la décision à un collègue.
Le chunking suffit-il pour un bon RAG ?
Non. Il faut aussi un embedding adapté, une base saine, une stratégie de récupération (top-k, hybride), parfois un reranker, et un modèle lecteur correct. Mais un mauvais chunking sabote le reste. En pratique, corrigez d’abord découpage et qualité des PDF avant d’acheter une carte graphique plus grosse. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant. Conservez la version d’outil et du modèle pour pouvoir expliquer la décision à un collègue.
Comment savoir si mon chunking est mauvais ?
Signes fréquents : réponses qui manquent une info pourtant présente, citations tronquées, confusion entre deux sections proches, échec sur les tableaux et les listes numérotées. Construisez un jeu de questions-oracles. Si le bon passage n’apparaît même pas dans les candidats, le problème est en amont du LLM : chunking ou recherche, pas seulement la température. Relisez aussi le PDF source : un OCR médiocre produit des chunks illisibles que aucun réglage ne répare vraiment.