Adaptive Chunking : et si le meilleur chunking pour un document n’était justement pas le même pour le suivant ?
Les projets de RAG (Retrieval-Augmented Generation, génération augmentée par récupération) ont un talent particulier pour nous rappeler une vérité un peu vexante : le modèle le plus brillant du monde répondra mal si on lui donne un contexte mal découpé.
C’est précisément ce que vient attaquer le papier Adaptive Chunking: Optimizing Chunking-Method Selection for RAG. Et il le fait avec une idée simple, presque évidente une fois formulée : arrêter de chercher la méthode de chunking universelle, et commencer à choisir la bonne méthode selon le document.
Dit autrement, ce papier prend au sérieux une intuition que beaucoup de praticiens ont déjà en production sans toujours pouvoir la formaliser. Un contrat juridique, une doc technique et un rapport ESG ne respirent pas de la même manière. Les découper pareil, c’est comme prendre une carte entière et décider que tous les quartiers d’une ville doivent avoir exactement la même taille. Sur le papier, c’est propre. Dans la vraie vie, on coupe une avenue en deux, on colle deux rues sans rapport, et tout le monde finit par se perdre.
C’est là que le papier devient intéressant. Il ne se contente pas de dire que le chunking compte. Il tente de répondre à une question bien plus utile : comment décider, document par document, quelle méthode de chunking mérite d’être choisie ?
"The effectiveness of Retrieval-Augmented Generation (RAG) is highly dependent on how documents are chunked"
Cette phrase d’ouverture du papier a le mérite d’être nette. Oui, le chunking n’est pas un détail d’implémentation. C’est une pièce maîtresse du système.
Pourquoi ce papier mérite qu’on s’y arrête
Dans beaucoup d’équipes, le chunking reste traité comme un réglage de plomberie : taille de chunk, overlap, séparateurs, et roule ma poule. Puis viennent les symptômes familiers. Le retrieval récupère presque la bonne zone, mais pas la bonne phrase. Les réponses deviennent vaguement plausibles. Le système "sait presque", ce qui est souvent la manière la plus pénible d’échouer.
Le papier part de ce constat, mais ajoute un angle plus original : on manque d’un cadre d’évaluation intrinsèque du chunking. En général, on évalue indirectement, via la performance finale du RAG. Le problème, c’est que cette performance dépend aussi du retriever, du reranker, du prompt, du générateur, du jeu de questions, et même de la météo morale de votre pipeline le jour du benchmark.
Les auteurs formulent cela très bien :
"chunking lacks a dedicated evaluation framework"
C’est sans doute la contribution la plus féconde du travail. Le papier ne propose pas seulement une nouvelle recette de découpe. Il propose une manière de juger la qualité d’un chunking avant même de regarder la réponse finale du LLM (Large Language Model, grand modèle de langage).
L’idée centrale, en version vulgarisée
Le cœur de l’approche tient en une phrase : on applique plusieurs stratégies de chunking à un document, on les score avec plusieurs métriques intrinsèques, puis on sélectionne la meilleure pour ce document précis.
Autrement dit, au lieu de décréter que la méthode récursive, la méthode sémantique ou la découpe par page sera toujours la bonne, on les met en concurrence. Le document devient le juge.
Les auteurs évaluent leur approche sur 33 documents issus de trois domaines — technique, juridique et reporting de durabilité — pour un total d’environ 1,18 million de tokens. Ils comparent plusieurs familles de chunking, dont un recursive splitter revu, des découpes plus simples, une stratégie par page, et un LLM-regex splitter, dans lequel un LLM propose un motif regex adapté à la structure du document.
Sur le fond, c’est presque une petite révolution culturelle. Le chunking cesse d’être un hyperparamètre figé. Il devient une décision contextualisée.
Les cinq métriques : le vrai moteur de l’approche
Le papier introduit cinq métriques intrinsèques. Dit comme ça, on pourrait craindre une salade d’acronymes. En réalité, elles sont assez concrètes.
La première, RC (References Completeness, complétude des références), vérifie si le chunking casse des chaînes de coréférence, par exemple en séparant une entité de son pronom. Si "la société X" est dans un chunk et "elle" dans un autre, le retrieval peut retrouver l’un sans l’autre et la génération perd le fil. Le dépôt officiel décrit ce signal comme le fait de ne pas briser des paires entité-pronom à travers les frontières de chunks.
Ensuite vient ICC (Intrachunk Cohesion, cohésion intra-chunk). L’idée est simple : un bon chunk ne doit pas être une colocation forcée de phrases qui ne se parlent pas. Dans l’implémentation officielle, cette cohésion est calculée en comparant les phrases d’un chunk à l’embedding global de ce chunk.
La troisième, DCC (Document Contextual Coherence, cohérence contextuelle du document), regarde si un chunk reste cohérent avec son voisinage textuel. Là encore, les auteurs utilisent une mesure d’embedding, mais à l’échelle d’une fenêtre de contexte glissante autour des chunks.
Puis il y a BI (Block Integrity, intégrité des blocs). Celle-ci parlera à quiconque a déjà vu un tableau PDF coupé au milieu, une liste éclatée sur deux chunks, ou un paragraphe assassiné entre deux titres. La métrique mesure la proportion de blocs structurels gardés intacts. Là, le papier rejoint de très près l’expérience terrain : les frontières structurelles ne sont pas du folklore, ce sont des repères cognitifs.
Enfin, SC (Size Compliance, conformité de taille) vérifie simplement si les chunks restent dans les bornes de taille visées. C’est la métrique la plus prosaïque, mais aussi celle qui évite les deux caricatures classiques : le chunk minuscule qui perd tout contexte, et le pavé de 1800 tokens qui noie la précision.
Ce quintette est malin, car il équilibre plusieurs tensions réelles : structure, sens, continuité référentielle, contexte local et contrainte de taille. Aucun signal ne suffit seul. Ensemble, ils donnent une boussole bien plus crédible.
Deux chunkers ajoutés pour muscler le benchmark
Le papier n’apporte pas seulement une logique de sélection. Il ajoute aussi deux méthodes de chunking.
La première est un LLM-regex splitter. Le principe : on donne au LLM un extrait représentatif du document, il propose une regex censée capturer ses frontières naturelles, puis on segmente selon ce motif. C’est une idée très pragmatique, presque artisanale au bon sens du terme : on demande au modèle de repérer la charpente documentaire avant de sortir le coupe-coupe. L’implémentation du dépôt confirme ce fonctionnement via une réponse contenant un bloc <regex>...</regex>.
La seconde est un split-then-merge recursive splitter. En pratique, il s’agit d’une version plus disciplinée du chunking récursif : on split d’abord selon des séparateurs, puis on fusionne intelligemment les petits morceaux au lieu de tout aplatir vers une taille cible aveugle. Le dépôt montre bien cette double logique, avec un mode où l’on ne fusionne que les segments trop petits, afin de mieux préserver les frontières sémantiques.
Autrement dit, le papier ne jette pas le recursive chunking à la poubelle. Il le raffine. Et c’est important.
Les résultats : modestes en apparence, très parlants en pratique
Les résultats rapportés sont suffisamment nets pour qu’on les prenne au sérieux.
Sur les métriques intrinsèques agrégées, l’Adaptive Chunking atteint un score moyen de 91,07, devant le LLM regex à 89,80 et le LangChain recursive à 88,62. La différence n’est pas cosmique, mais elle est robuste et statistiquement significative selon le dépôt officiel.
Là où cela devient vraiment intéressant, c’est en bout de chaîne RAG. Sans changer les modèles ni les prompts, l’approche adaptative fait monter la correctness des réponses à 72 % dans l’abstract arXiv, alors que les baselines sont autour de 62–64 %. Le dépôt officiel, lui, rapporte 78,0 de correctness contre 70,1 pour le recursive LangChain et 73,3 pour la découpe par page, ainsi qu’un passage de 49 à 65 requêtes correctement traitées sur 99. Les chiffres exacts diffèrent légèrement entre l’abstract et le README, probablement parce que le dépôt détaille un protocole ou un tableau précis, mais la tendance, elle, ne bouge pas : mieux choisir le chunking améliore réellement le RAG.
Le passage le plus frappant de l’abstract reste sans doute celui-ci :
"Without changing models or prompts, our framework increases RAG outcomes"
C’est une petite phrase, mais elle a de grandes conséquences. Elle suggère qu’une partie du gain que beaucoup cherchent côté modèle, prompt engineering ou reranking dort en réalité plus en amont, dans la façon de découper les documents.
Ce que ce papier dit face au réel
Dans un projet RAG, la partie la plus centrale — et souvent la plus dure — est de comprendre comment chaque document s’articule pour choisir la bonne méthode de chunking.De mpn côté, j'ai très souvent recours au chunking structurel récursif, avec de bons résultats, mais au prix d’un travail manuel coûteux. Automatiser ce choix fait gagner un temps énorme, sans remplacer pour autant la mise en qualité des données.
Le papier valide presque point par point cette lecture. Il confirme que le chunking conditionne fortement la qualité du retrieval et que les approches "one-size-fits-all" sont insuffisantes. Il confirme aussi que la structure du document doit guider la découpe. Et surtout, il propose une manière crédible d’automatiser ce choix sans tomber dans la magie noire.
Toutefois, une nuance est à apporter sur l’idée que j'ai que le chunking est la partie la plus ardue de tout projet RAG. Souvent, la difficulté reine reste un trio infernal : qualité de parsing, qualité des documents source, qualité du protocole d’évaluation. Le chunking est peut-être le point de levier le plus visible entre ingestion et retrieval, mais il ne travaille jamais seul.
En revanche, le chunking n’est pas seulement central pour le retrieval, il est aussi central pour la traçabilité du système. Quand les chunks respectent les blocs, les références et la cohérence locale, on obtient non seulement de meilleurs passages, mais aussi des justifications plus lisibles et des debug sessions moins déprimantes.
Au final, dans un projet RAG, le chunking est l’un des leviers les plus centraux et les plus sous-estimés, parce qu’il transforme la structure documentaire en structure de preuve exploitable par le retrieval**. Et ça, le papier l’illustre très bien.
Pourquoi cela compte au-delà du RAG classique
L’intérêt du papier dépasse le chatbot documentaire.
Pour l’IA appliquée au développement, on imagine tout de suite des gains sur la recherche dans des documentations hétérogènes, des RFC, des tickets, des runbooks ou des bases de connaissance internes. En data science, la même logique vaut pour les rapports, notebooks exportés, annexes méthodologiques ou documents réglementaires. Dans le jeu vidéo aussi, la leçon est utile : qu’il s’agisse de lore, de quêtes, de dialogues, de design docs ou de patch notes, un système qui récupère des "quartiers" documentaires cohérents produira des assistants plus fiables, des moteurs de recherche internes plus utiles, et des outils de narration assistée moins hallucinés.
Le vrai message est là : si le document a une architecture, le retrieval doit la respecter. Sinon, il erre.
Conclusion : moins de dogme, plus de discernement
Ce papier ne prétend pas avoir inventé le chunking parfait. Et c’est justement sa force.
Il propose quelque chose de plus mature : remplacer le dogme de la méthode unique par une sélection guidée par des métriques. Dans un domaine où l’on adore parfois chercher la recette miracle, c’est une approche presque reposante.
La conséquence pratique est très concrète. Oui, automatiser le choix du chunking peut faire gagner un temps précieux. Oui, cela peut améliorer le retrieval sans toucher au modèle ni au prompt. Et non, cela ne dispense pas de nettoyer les données, de soigner le parsing, ni d’évaluer sérieusement le pipeline. Le papier ne vend pas une baguette magique. Il vend mieux : une méthode de discernement.
Et franchement, dans l’univers RAG, disposer enfin d’un système qui choisit le bon quartier avant d’envoyer le retriever s’y promener, c’est déjà une très belle victoire. Parce qu’au fond, un RAG médiocre n’est pas toujours un système qui ne sait pas lire. C’est souvent un système à qui on a donné une mauvaise carte.
Références
- Paulo Roberto de Moura Júnior, Jean Lelong, Annabelle Blangero, Adaptive Chunking: Optimizing Chunking-Method Selection for RAG, arXiv, 26 mars 2026.
- Dépôt officiel : ekimetrics/adaptive-chunking.