Quelle est la meilleure taille de chunk pour le RAG ?

Il n'y a pas de réponse universelle, mais un bon point de départ est de 400 à 512 tokens avec un chevauchement de 10 à 20 %. Ajustez ensuite selon le type de requête : 128 à 256 tokens pour une recherche précise de faits, et 512 à 1024 tokens pour des requêtes analytiques ou de synthèse. Mieux vaut évaluer quelques tailles sur vos propres questions plutôt que de vous fier à une seule valeur par défaut.

Quel chevauchement les chunks doivent-ils avoir ?

De dix à vingt pour cent de la taille du chunk, soit environ 50 à 100 tokens pour un chunk de 500 tokens. Le chevauchement évite que le sens soit coupé à une frontière ; trop peu fragmente le contexte à la coupure, et trop gonfle l'index et provoque des récupérations quasi dupliquées. NVIDIA a trouvé qu'environ 15 % était optimal sur des documents financiers.

Le chunking sémantique est-il meilleur que le chunking à taille fixe ?

Pas de façon fiable. Le chunking sémantique regroupe les phrases par sujet, ce qui semble préférable, mais les benchmarks montrent que ses gains par rapport au chunking récursif ou à taille fixe sont inconsistants et ne justifient souvent pas le calcul d'embedding supplémentaire. Le chunking fixe et récursif restent des références solides et économiques : commencez par là et ne passez au sémantique que si votre évaluation montre un gain réel.

Qu'est-ce que le late chunking et quand l'utiliser ?

Le late chunking calcule d'abord l'embedding du document entier avec un modèle d'embedding à contexte long, puis regroupe les embeddings de tokens en chunks, de sorte que le vecteur de chaque chunk porte le contexte de l'ensemble du document, et pas seulement de son propre texte. Utilisez-le pour les longs documents à dépendances à longue portée, où un passage n'a de sens qu'avec le contexte antérieur.

La recherche contextuelle améliore-t-elle vraiment la précision ?

Oui, de manière mesurable. Anthropic a rapporté que préfixer chaque chunk d'une note de contexte générée par LLM réduisait les échecs de recherche sur le top-20 de 35 % avec des embeddings contextuels, de 49 % en combinant avec BM25 contextuel, et de 67 % en ajoutant le reranking, le tout pour environ 1,02 $ par million de tokens de document avec mise en cache des prompts. C'est surtout rentable pour les corpus à enjeux élevés où un passage manqué coûte cher.

Qu'est-ce que la recherche de document parent (du petit au grand) ?

Elle découple la façon dont vous faites correspondre de ce que vous renvoyez. Vous indexez de petits chunks enfants pour une correspondance précise, mais quand l'un d'eux correspond, vous transmettez au modèle la section parent plus grande pour qu'il dispose du contexte environnant. Cela vous donne le rappel des petits chunks et la cohérence des grands sans sacrifier ni l'un ni l'autre.

Par quelle stratégie de chunking devrais-je commencer ?

Par le chunking récursif à environ 500 tokens avec 15 % de chevauchement. Il respecte les frontières naturelles, est économique et constitue une référence solide pour la plupart des contenus. Ajoutez le découpage sensible à la structure pour les PDF et manuels, la recherche de document parent quand les réponses ont besoin de plus de contexte, et la recherche contextuelle uniquement là où les enjeux justifient le coût supplémentaire.

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

Stratégies de chunking pour le RAG : tailles, chevauchement et bonnes pratiques

Le chunking fixe le plafond de qualité du RAG avant même que la recherche ne s'exécute. Ce guide compare les six stratégies qui dominent la pratique, donne des chiffres concrets de taille et de chevauchement, et explique laquelle convient à chaque type de requête.

Pourquoi le chunking détermine la qualité du RAG

Le chunk est l'unité que votre retriever va réellement chercher : les frontières des chunks fixent donc le plafond de tout ce qui vient ensuite. Des chunks trop petits font que chaque embedding manque de signal pour être trouvé de façon fiable ; des chunks trop grands diluent le signal du passage pertinent, au point que le vecteur ne correspond plus à la requête. Si vous ratez le chunking, aucun reranker ni modèle plus puissant ne rattrapera le rappel : le bon passage n'a tout simplement jamais été récupéré. C'est pourquoi le chunking, et non le choix du modèle, est généralement le premier paramètre à régler.

Les six stratégies qui dominent la pratique

La pratique actuelle se regroupe en six approches :

Taille fixe : segments égaux de tokens ou de caractères avec chevauchement. La plus ancienne, la moins coûteuse, la plus reproductible, et une référence étonnamment solide.
Récursif : découpe selon une hiérarchie de séparateurs (paragraphe → ligne → phrase) pour rester sous une limite de taille tout en respectant les frontières naturelles. La valeur par défaut recommandée.
Sémantique : regroupe les phrases par similarité d'embedding afin que chaque chunk porte un seul sujet. Les gains par rapport au récursif sont inconsistants et exigent un coût de calcul supplémentaire pour l'embedding.
Sensible à la structure : découpe selon la structure du document (titres, sections, pages, markdown). Idéale pour les PDF, manuels et documents financiers.
Late chunking : calcule d'abord l'embedding du document entier avec un modèle à contexte long, puis regroupe les embeddings de tokens en chunks, de sorte que chaque chunk porte un contexte global.
Recherche contextuelle : préfixe chaque chunk d'une note de contexte générée par LLM avant l'indexation.

Commencez par le récursif ; passez aux autres quand vos documents ou types de requêtes l'exigent.

Taille des chunks et chevauchement : des chiffres concrets

Il n'existe pas de taille universellement optimale, mais il y a de bons points de départ. Commencez avec environ 400–512 tokens et un chevauchement de 10–20 % (environ 50–100 tokens pour un chunk de 500 tokens). Adaptez ensuite la taille au type de requête : les petits chunks (128–256 tokens) favorisent la recherche précise de faits et de mots-clés, tandis que les plus grands (512–1024 tokens) favorisent les requêtes analytiques et de synthèse, où le fil narratif compte.

Le chevauchement évite que le sens soit coupé à une frontière : trop peu fragmente le contexte, trop gonfle l'index et duplique les récupérations. Le benchmark de NVIDIA a établi qu'environ 15 % de chevauchement était optimal sur des documents financiers, et que le chunking au niveau des pages offrait la précision la plus élevée et la plus constante sur des corpus mixtes, avec des requêtes factuelles culminant entre 256–512 tokens et des requêtes analytiques au-delà de 1024.

Avancé : recherche contextuelle et late chunking

Deux techniques plus récentes s'attaquent au même problème : un chunk qui indique « les revenus ont augmenté de 15 % » est inutile si l'on ignore de quelle entreprise ou de quel trimestre il s'agit.

La recherche contextuelle d'Anthropic préfixe chaque chunk d'une note de contexte de 50–100 tokens générée par LLM, avant l'embedding et l'indexation BM25. Mesurés par rapport à un taux d'échec de référence de 5,7 % sur le top-20, les embeddings contextuels réduisent les échecs de 35 %, l'ajout de BM25 contextuel de 49 %, et l'ajout du reranking de 67 %, le tout pour environ 1,02 $ par million de tokens de document avec mise en cache des prompts.

Le late chunking de Jina inverse le pipeline : il calcule l'embedding du document entier avec un modèle à contexte long (jusqu'à ~8192 tokens), puis regroupe les embeddings de tokens contextualisés en chunks, de sorte que chaque embedding de chunk porte déjà un contexte inter-chunks. Utilisez-le pour les longs documents à dépendances à longue portée.

Recherche de document parent et métadonnées

Deux affinements s'avèrent payants presque partout. La recherche de document parent (« du petit au grand ») découple la granularité de la recherche de celle de la génération : indexez de petits chunks enfants (≈100–500 tokens) pour une correspondance précise, mais renvoyez au modèle la section parent plus grande (≈500–2000 tokens) afin qu'il dispose du contexte environnant. Et l'enrichissement des métadonnées — associer source, titre de section, numéro de page et horodatages à chaque chunk — améliore le filtrage, permet les citations et augmente la précision de la recherche indépendamment de la taille du chunk.

Choisir et régler dans osFoundry

Un guide de décision rapide : le récursif est la valeur par défaut sûre ; sensible à la structure ou au niveau des pages pour les documents structurés ; sémantique pour la prose thématiquement dense ; late chunking pour les longs documents avec un embedder à contexte long ; recherche contextuelle pour les corpus à enjeux élevés où la perte de contexte coûte cher ; document parent quand vous avez besoin à la fois de précision et de contexte.

osFoundry traite tout cela comme de la configuration, pas du code. Le chunking automatique fournit un paramètre récursif par défaut sensé, et le pipeline RAG personnalisé vous permet de régler taille, chevauchement et stratégie par base de connaissances, avec le reranking et la recherche de document parent comme interrupteurs d'étape du pipeline. Comme les étapes sont configurables, vous pouvez faire des tests A/B des réglages de chunking sur votre propre distribution de requêtes — factuelles ou analytiques — en gardant le reste de la pile inchangé, ce qui correspond exactement au flux de travail à paramètres réglables que la recherche recommande.

Frequently asked questions

Quelle est la meilleure taille de chunk pour le RAG ?: Il n'y a pas de réponse universelle, mais un bon point de départ est de 400 à 512 tokens avec un chevauchement de 10 à 20 %. Ajustez ensuite selon le type de requête : 128 à 256 tokens pour une recherche précise de faits, et 512 à 1024 tokens pour des requêtes analytiques ou de synthèse. Mieux vaut évaluer quelques tailles sur vos propres questions plutôt que de vous fier à une seule valeur par défaut.
Quel chevauchement les chunks doivent-ils avoir ?: De dix à vingt pour cent de la taille du chunk, soit environ 50 à 100 tokens pour un chunk de 500 tokens. Le chevauchement évite que le sens soit coupé à une frontière ; trop peu fragmente le contexte à la coupure, et trop gonfle l'index et provoque des récupérations quasi dupliquées. NVIDIA a trouvé qu'environ 15 % était optimal sur des documents financiers.
Le chunking sémantique est-il meilleur que le chunking à taille fixe ?: Pas de façon fiable. Le chunking sémantique regroupe les phrases par sujet, ce qui semble préférable, mais les benchmarks montrent que ses gains par rapport au chunking récursif ou à taille fixe sont inconsistants et ne justifient souvent pas le calcul d'embedding supplémentaire. Le chunking fixe et récursif restent des références solides et économiques : commencez par là et ne passez au sémantique que si votre évaluation montre un gain réel.
Qu'est-ce que le late chunking et quand l'utiliser ?: Le late chunking calcule d'abord l'embedding du document entier avec un modèle d'embedding à contexte long, puis regroupe les embeddings de tokens en chunks, de sorte que le vecteur de chaque chunk porte le contexte de l'ensemble du document, et pas seulement de son propre texte. Utilisez-le pour les longs documents à dépendances à longue portée, où un passage n'a de sens qu'avec le contexte antérieur.
La recherche contextuelle améliore-t-elle vraiment la précision ?: Oui, de manière mesurable. Anthropic a rapporté que préfixer chaque chunk d'une note de contexte générée par LLM réduisait les échecs de recherche sur le top-20 de 35 % avec des embeddings contextuels, de 49 % en combinant avec BM25 contextuel, et de 67 % en ajoutant le reranking, le tout pour environ 1,02 $ par million de tokens de document avec mise en cache des prompts. C'est surtout rentable pour les corpus à enjeux élevés où un passage manqué coûte cher.
Qu'est-ce que la recherche de document parent (du petit au grand) ?: Elle découple la façon dont vous faites correspondre de ce que vous renvoyez. Vous indexez de petits chunks enfants pour une correspondance précise, mais quand l'un d'eux correspond, vous transmettez au modèle la section parent plus grande pour qu'il dispose du contexte environnant. Cela vous donne le rappel des petits chunks et la cohérence des grands sans sacrifier ni l'un ni l'autre.
Par quelle stratégie de chunking devrais-je commencer ?: Par le chunking récursif à environ 500 tokens avec 15 % de chevauchement. Il respecte les frontières naturelles, est économique et constitue une référence solide pour la plupart des contenus. Ajoutez le découpage sensible à la structure pour les PDF et manuels, la recherche de document parent quand les réponses ont besoin de plus de contexte, et la recherche contextuelle uniquement là où les enjeux justifient le coût supplémentaire.