Stratégies de chunking RAG comparées : pourquoi votre retriever ne trouve que la moitié de la réponse

Si votre système de recherche trouve une partie de la réponse la plupart du temps, il échoue probablement plus souvent que ne le dit votre tableau de bord. Une série d'articles d'octobre sur le chunking, et une expérience soignée qui a mis cinq de leurs idées côte à côte, mènent à la même leçon : la façon dont vous découpez un document décide de ce qui peut être trouvé, et le meilleur découpage dépend de la quantité de contexte que vous pouvez vous permettre d'envoyer.

Pourquoi le chunking revient à l'ordre du jour

La génération augmentée par la recherche (RAG) découpe vos documents en morceaux, trouve ceux qui correspondent à une question et les transmet à un modèle. Le modèle ne peut utiliser que ce qu'on lui donne. The Bottleneck Is Retrieval, Not Reading (arXiv, 18 octobre) a testé dix modèles de pointe et trois modèles à poids ouverts et a trouvé le même schéma chez tous : la recherche fait remonter de façon fiable certains des chunks dont une question à plusieurs faits a besoin, mais pas tous, et le chunking supprime le contexte au niveau du document qui relie un passage à un autre.

Trois articles d'octobre attaquent ce problème sous des angles différents.

QESChunker (27 octobre) traite le chunking comme une optimisation. À partir d'exemples de questions et des phrases qui y répondent, il choisit les points de coupe qui gardent le plus de preuves récupérables. Sans chevauchement, la programmation dynamique trouve la meilleure réponse exacte ; avec chevauchement, le problème est NP-difficile, et une passe gloutonne arrive à une borne prouvée du meilleur résultat.

StrucChunk (19 octobre) utilise la structure que l'auteur a déjà écrite. Il ne coupe jamais au milieu d'une clause, résout les renvois comme « see Section 4.2 » avant l'indexation, et fusionne la recherche par mots-clés (BM25) avec des embeddings denses. Sur 501 questions portant sur le code de procédure pénale indien, le Recall@5 est passé de 0,557 à 0,804, et les auteurs attribuent 88 % de ce gain au seul chunking.

SpectRAG (27 octobre) cesse de traiter les chunks comme indépendants. Il construit sur eux un graphe pondéré à partir de leur contiguïté, de la hiérarchie des sections, des entités partagées et des citations, propage la pertinence des premiers résultats de recherche à travers ce graphe, et assemble un contexte sous un budget de tokens fixe.

Une expérience, cinq chunkers

Vishal Mysore a confronté ces idées dans un laboratoire dans le navigateur que chacun peut relancer. Le document est le manuel fictif d'un observatoire, rédigé comme un règlement, avec des sections numérotées, des définitions et des renvois. La recherche se fait uniquement en BM25, donc chaque chiffre est déterministe. Chaque chunker a les mêmes limites : des chunks de 450 caractères au plus et un budget de contexte de 120 mots.

Les cinq chunkers étaient une fenêtre fixe qui coupe toutes les quelques centaines de caractères, une fenêtre de phrases qui regroupe des phrases entières, un chunker structurel dans le style de StrucChunk (un chunk par section numérotée, chemin des titres joint, définitions citées en renvoi recopiées), et QESChunker dans ses versions exacte et avec chevauchement.

Chaque chunker a conservé chaque phrase de preuve intacte quelque part. Les différences portent sur la possibilité de trouver les bons morceaux et de les faire tenir dans le budget.

Ce que disent les résultats

Le rappel partiel flatte. Chaque stratégie a trouvé au moins une phrase de preuve pour 69 à 92 % des questions. Les chunkers par défaut ont assemblé la réponse complète moins d'une fois sur quatre. Un pipeline jugé sur les réussites partielles paraîtrait en bonne santé alors que trois réponses à plusieurs faits sur quatre reposaient sur la moitié des preuves.

Les chunks petits et structurés gagnent quand le contexte est serré. Les chunks de la taille d'une section faisaient en moyenne 285 caractères contre environ 400 pour les fenêtres, si bien que deux ou trois tiennent dans 120 mots là où une seule fenêtre tient. Avec un budget de 40 mots, seul le chunker structurel a dépassé 10 %. À 300 mots, les chunkers à fenêtre l'avaient rattrapé, et à 400 ils l'avaient dépassé, tandis que le chunker structurel plafonnait à 77 %. Avec un budget généreux, presque n'importe quel chunker ramène les preuves, parce que vous envoyez une grande partie du document.

Taille des chunks et budget doivent se régler ensemble. Avec des chunks de 800 caractères, les fenêtres fixe et de phrases ont obtenu 0 % : une fenêtre de 800 caractères fait environ 130 mots, plus que le budget de 120 mots, donc aucun chunk n'a tenu. C'est l'échec que l'on obtient quand une personne règle le chunker et une autre le prompt.

Le chunker prouvé optimal a fini dernier. La version exacte de QESChunker a obtenu 15 % sur les questions réservées. Elle est optimale pour son objectif, qui récompense le fait de garder les phrases de preuve entières. Le moyen le moins coûteux de garder une règle entière est de couper juste avant elle, et dans un manuel, la ligne qui précède une règle est son titre. Le titre s'est retrouvé à la fin d'un chunk et la règle au début du suivant, si bien qu'une recherche par mots-clés sur le titre trouvait le mauvais chunk. Aucun de ses chunks ne commençait par un titre. La leçon est générale : un chunker optimise ce que vous mettez par écrit, et une preuve intacte n'est pas la même chose qu'une preuve trouvable. La version avec chevauchement a fait bien mieux, 46 % sur les questions réservées et 83 % sur celles sur lesquelles elle avait été réglée. Cet écart est l'avertissement pour tout chunker entraîné sur des exemples de questions : l'index est façonné autour des questions auxquelles vous avez pensé.

Un graphe de chunks aide là où les définitions sont des pivots. Passer le chunking structurel en recherche par graphe l'a fait monter de 62 % à 69 %. Pour « Is flash photography allowed on the dome floor? », le BM25 simple classait la définition de la zone de lumière rouge en troisième position, et elle ne tenait plus dans le budget. En mode graphe, deux autres sections renvoient à cette définition, si bien que la pertinence a circulé jusqu'à elle et qu'elle a été retenue. Désactiver la résolution des renvois a effacé le gain. Sur les chunkers à fenêtre, le graphe n'a pas aidé, et pour les fenêtres de phrases il a fait baisser le score de 23 % à 15 %.

Certains échecs ne sont pas des problèmes de chunking. « My 8-year-old is coming. What rule applies on the terrace? » a échoué partout, parce que la règle dit « children under 10 » et ne partage aucun mot avec la question. Cet écart exige une recherche dense ou hybride, une reformulation de la requête ou un reranker.

Ce qu'il faut changer dans votre pipeline

Pour des documents réellement structurés, comme des contrats, des règlements, des manuels et des spécifications, découpez par section, joignez le chemin des titres et résolvez les renvois au moment de l'indexation pour qu'une règle voyage avec la définition dont elle dépend. Des outils comme Docling et Unstructured récupèrent cette structure à partir de PDF ; Chonkie se charge du chunking lui-même.

Mesurez les réponses complètes, pas les réussites partielles. Une question à plusieurs faits à laquelle on répond avec la moitié de ses preuves est une mauvaise réponse qui a l'air juste. Ragas peut noter le rappel du contexte question par question.

Réglez la taille des chunks et le budget de contexte au même endroit, et testez avec le budget que vous envoyez réellement. Le meilleur chunker à 120 mots n'était pas le meilleur à 400.

Si vous essayez une méthode supervisée ou basée sur un graphe, vérifiez que son objectif correspond au retriever que vous utilisez. Deux articles de septembre le confirment sous d'autres angles : une étude de 54 configurations a constaté que les choix de parser et de chunker interagissent, sans retriever unique meilleur partout, et une comparaison de six pipelines sur environ 464 000 articles a constaté que le reranking et l'interaction tardive font davantage bouger la qualité que les ajustements de la première étape. Un troisième, sur la profondeur de recherche adaptative, rapporte un F1 meilleur de plus de 36 % et 14 % de tokens en moins sur les requêtes faciles en choisissant combien de chunks récupérer selon le type de question.

Notre avis : le chunking décide de ce qui peut être récupéré ; le retriever décide de ce qui l'est. Corrigez le premier avec la structure, le second avec la recherche hybride et un reranker comme Cohere Rerank 5 ou Jina Reranker v3.5, et jugez les deux sur le fait que la réponse entière arrive ou non.