Stratégies de chunking RAG : 7 méthodes, classées par les données de retrieval (2026)

Stratégies de chunking RAG : 7 méthodes, classées par les données de retrieval (2026)

Les stratégies de chunking RAG décident de ce que votre retriever peut trouver avant même qu'une seule requête ne tourne. L'étude de Chroma de juillet 2024 a exécuté 472 requêtes sur cinq corpus avec text-embedding-3-large, et le splitter que vous choisissez déplace le rappel d'environ cinq points : 86,7 % pour un simple splitter par tokens, 91,7 % pour celui basé sur GPT-4o, avec cinq chunks récupérés par requête. La précision, elle, oscille bien plus fort. Sur l'ensemble du rapport, elle varie de 1,5 % à 8,0 %, ce qui fait de votre choix de taille de chunk une décision de coût déguisée en décision de qualité. Et tous les guides en première page de Google listent les mêmes sept méthodes sans jamais montrer laquelle récupère le mieux.

Points clés

• Le chunking découpe les documents avant l'embedding ; les points de découpe déterminent ce que votre retriever peut et ne peut pas trouver.
• Dans l'étude de Chroma de juillet 2024 portant sur 472 requêtes, le rappel allait de 86,7 % à 91,7 % selon les splitters mesurés.
• La précision varie plusieurs fois plus que le rappel, donc la taille de chunk est surtout une décision de coût en tokens.
• Commencez à 512 tokens avec 10 % de chevauchement, puis ajustez face à votre propre jeu d'évaluation.

Quelle stratégie de chunking RAG choisir ? (Classement)

Pour la plupart des équipes qui construisent sur de la prose plate, le chunking récursif par caractères à 512 tokens avec 10 % de chevauchement est le bon choix par défaut. Il respecte les limites de paragraphes et de phrases, ne coûte rien de plus, et dans le benchmark de Chroma sur 472 requêtes, il finit à 3,2 points de rappel derrière le splitter basé sur un LLM. N'en changez que si vos documents ont une structure forte ou si votre jeu d'évaluation prouve le contraire.

Notre lecture : commencez par le chunking récursif par caractères. Dans les données de Chroma, il n'est devancé en rappel que par les splitters par cluster et par LLM, et la précision de 3,9 % du splitter LLM signifie que vous envoyez au générateur environ deux fois plus de bruit par token pertinent. La plupart des équipes n'ont pas de problème de chunking ; elles ont un problème de taille de chunk qu'elles n'ont jamais mesuré.

Que disent réellement les données sur la taille de chunk ?

La seule comparaison publique en face-à-face des stratégies de chunking RAG est le rapport technique de Chroma, « Evaluating Chunking Strategies for Retrieval » (Brandon Smith et Anton Troynikov, publié le 3 juillet 2024). Ils ont lancé 472 requêtes sur 5 corpus (328 208 tokens), généré les embeddings avec text-embedding-3-large d'OpenAI et récupéré 5 chunks par requête. Les lignes ci-dessous proviennent du tableau en annexe du rapport, pour tous les corpus avec text-embedding-3-large et 5 chunks récupérés ; elles sont donc directement comparables entre elles :

Le tableau de résultats principal de Chroma, qui porte sur un autre paramétrage de récupération, place la meilleure précision du chunker par cluster à 8,0 % avec 87,3 % de rappel, et étend la plage de précision de tous ses splitters de 1,5 % (KamradtSemanticChunker) à 8,0 %. Source : Chroma Research, Evaluating Chunking Strategies

« Introducing Contextual Retrieval » d'Anthropic (publié le 19 septembre 2024) attaque le problème sous un autre angle. Leur taux d'échec de récupération de base dans le top 20 était de 5,7 % ; les embeddings contextuels seuls le font tomber à 3,7 % (réduction de 35 %), le BM25 contextuel par-dessus le ramène à 2,9 % (49 %), et le reranking le pousse à 1,9 % (67 %). Anthropic ne publie ni la taille de chunk exacte ni le chevauchement utilisés ; traitez donc ces chiffres comme une preuve au niveau de la méthode, pas au niveau de la taille. Source : Anthropic, Contextual Retrieval.

Notre lecture : trois conclusions tirées de l'arithmétique. D'abord, le choix du splitter vaut un vrai gain de rappel, et Chroma le dit sans détour : certaines stratégies dépassent les autres de jusqu'à 9 % en rappel. Dans son tableau de résultats principal, le rappel va de 83,6 % (KamradtSemanticChunker) à 91,9 % (LLMSemanticChunker), et dans les lignes à 5 chunks récupérés ci-dessus, il s'étend encore de 86,7 % à 91,7 %. La précision bouge plusieurs fois plus sur les mêmes données : de 1,5 % à 8,0 %, soit un écart de 5,3x contre 1,1x pour le rappel. Le rappel est donc là où vous gagnez quelques points ; la précision et le coût en tokens sont là où le choix fait vraiment mal. Ensuite, le splitter basé sur un LLM achète le meilleur rappel au prix de la pire précision : vous payez un appel LLM par document et vous envoyez plus de bruit au générateur. Enfin, les chiffres d'Anthropic montrent qu'enrichir les chunks avec du contexte (de 5,7 % à 3,7 %) a plus déplacé le taux d'échec que n'importe quel choix de splitter dans le tableau de Chroma. Enrichissez vos chunks avant de réajuster le splitter. Le reranking récupère les chunks que votre splitter a massacrés, et la recherche hybride combine BM25 et recherche vectorielle pour la même raison.

Limites honnêtes : les deux études utilisent un seul modèle d'embedding, des corpus en anglais uniquement, et aucune des deux n'est un test contrôlé de votre corpus. Sur 472 requêtes, l'écart entre le meilleur et le pire splitter était d'environ 5 points de rappel à 5 chunks récupérés, et proportionnellement bien plus grand encore en précision.

Pourquoi la taille de chunk détermine-t-elle la qualité de retrieval ?

La taille de chunk fixe la granularité de votre clé de récupération. Un chunk de 400 tokens produit un embedding focalisé qui correspond à des requêtes précises ; un chunk de 4 000 tokens fait la moyenne de nombreux sujets et ne correspond précisément à rien. Les petits chunks récupèrent le passage exact mais peuvent fragmenter une réponse sur plusieurs résultats. Les gros chunks gardent le contexte ensemble mais affaiblissent le signal de l'embedding.

Le plafond de contexte du modèle d'embedding compte aussi. Si votre modèle plafonne à 512 tokens en entrée et que vous lui en donnez 800, la fin est tronquée silencieusement. Votre embedding ne représente que les deux tiers du chunk. Aucune erreur n'est journalisée.

Puis le côté générateur. Liu et al. ont montré dans « Lost in the Middle » (arXiv 2307.03172, 2023) que la précision des LLM chute de plus de 20 % quand le document pertinent se retrouve au milieu d'un long contexte. Récupérer cinq chunks de 1 000 tokens déverse 5 000 tokens dans le prompt, et la réponse dont vous avez besoin peut atterrir à la position que le modèle lit le moins bien. Des chunks plus petits gardent le passage pertinent plus près d'une position que le modèle traite correctement.

Pensez à un index de bibliothèque. Une fiche qui dit « Section 4.2, paragraphe 3 : politique de remboursement » vous mène à la page. Une fiche qui dit « tout sur le commerce au XXe siècle » vous mène au bâtiment. Votre embedding est cette fiche. Construisez une application RAG de bout en bout pour voir où se place le chunking dans le pipeline, et lisez notre guide du context engineering pour comprendre comment les chunks récupérés deviennent des tokens de prompt. Le guide de chunking de Pinecone présente le même compromis côté base de données vectorielle.

Chunking à taille fixe et chunking récursif (commencez ici)

Le taille fixe est la référence par rapport à laquelle vous mesurez tout ; le récursif est ce que vous mettez réellement en production.

Chunking par tokens de taille fixe

Découpez tous les N tokens, quel que soit le contenu.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

Le bon choix pour : la prose plate sans structure de titres, les prototypes rapides et toute comparaison de référence. Ce n'est pas stupide. C'est le groupe témoin.

Chunking récursif par caractères

Le RecursiveCharacterTextSplitter de LangChain découpe selon une hiérarchie de séparateurs : d'abord \n\n (paragraphes), puis \n (lignes), puis . (phrases), puis (mots). Chaque chunk reste sous chunk_size tout en respectant la plus grande frontière naturelle qui tient.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

La liste de séparateurs est la partie que tous les concurrents omettent. Le splitter essaie \n\n d'abord et ne retombe sur . que lorsqu'un paragraphe dépasse chunk_size. Si votre Markdown a des titres, ajoutez "## " avant "\n\n" pour que les sections restent intactes.

Arithmétique du chevauchement : à 512 tokens avec 50 tokens de chevauchement, le pas est de 462. Un document de 10 000 tokens produit ceil(10000 / 462) = 22 chunks. Total de tokens embarqués : 22 x 512 = 11 264, ce qui signifie que vous ré-embeddez environ 12,6 % du corpus en chevauchement. C'est le coût de stockage et d'API pour éviter que les phrases en bordure ne restent orphelines.

Comment fonctionne le chunking sémantique, et vaut-il son coût ?

Le chunking sémantique génère un embedding de chaque phrase, mesure la distance cosinus entre les embeddings de phrases voisines et découpe là où cette distance dépasse un seuil de percentile (couramment le 95e). Les chunks se coupent aux changements de sujet plutôt qu'à des nombres de tokens arbitraires. Le notebook « 5 Levels of Text Splitting » de Greg Kamradt est à l'origine de cette approche par point de rupture en percentile, et l'étude de Chroma benchmark ses chunkers nommément.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

Le calcul de coût est la partie que personne ne met en avant. Le chunking sémantique embedde votre corpus deux fois : une fois pour calculer les distances entre phrases et trouver les points de rupture, une fois pour générer les embeddings des chunks résultants en vue de l'indexation. Au prix de 0,13 $ par million de tokens pour text-embedding-3-large d'OpenAI, un corpus de 10 millions de tokens coûte 1,30 $ à indexer normalement et 2,60 $ avec le chunking sémantique. Vous payez le double avant même qu'une requête ne tourne.

Qu'est-ce que cela achète ? Dans les lignes à 5 chunks récupérés de Chroma, le chunker sémantique par cluster atteint 89,0 % de rappel et 6,7 % de précision, contre 88,5 % et 7,0 % pour le récursif à la même taille de 200 tokens. Dans le tableau de résultats principal, le même chunker affiche la meilleure précision de l'étude, 8,0 %, avec 87,3 % de rappel. Un demi-point de rappel dans un sens ou dans l'autre, et un résultat de précision qui change de signe selon le paramétrage de récupération que vous lisez, pour le double de facture d'embedding. Notre verdict : le chunking sémantique est rentable sur des corpus à sujets variés (archives de presse, collections d'articles) où les frontières fixes coupent régulièrement en plein milieu d'un sujet. Pour des corpus homogènes (documentation produit, base de connaissances unique), le récursif vous donne 95 % de la qualité pour la moitié du coût. Si vous exécutez des modèles d'embedding en local avec Ollama, le coût du double embedding se réduit à du temps de calcul.

Chunking conscient du document : Markdown, HTML et code

Le découpage conscient de la structure utilise les frontières du document lui-même (titres, éléments de liste, définitions de fonctions) au lieu de compter les caractères. Un H2 en Markdown est une frontière sémantique qu'un humain a placée délibérément ; un splitter par caractères le réduit en miettes.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

Pour le code, les frontières sont les nœuds de l'AST. Les NodeParsers de LlamaIndex fournissent des splitters conscients du langage qui coupent sur les définitions de fonctions et de classes. Le détail critique : gardez le bloc d'imports et la signature de la classe englobante attachés à chaque chunk de fonction. Un corps de fonction sans ses imports est un bruit impossible à embedder ; préfixez donc les deux à chaque chunk, et l'embedding capture ce que fait la fonction et ce dont elle dépend.

Pour le RAG de code en particulier : découpage sur les frontières de l'AST, imports préfixés, 256 à 512 tokens par fonction, zéro chevauchement.

Et le late chunking, le chunking hiérarchique et le chunking agentique ?

Ce sont les stratégies de chunking RAG avancées derrière le battage autour du « RAG 2.0 », et toutes les trois occupent 1/10 de la couverture du SERP.

Late chunking

Le late chunking, introduit par Günther et al. dans « Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models » (arXiv 2409.04701, septembre 2024), génère d'abord l'embedding du document entier avec un modèle long contexte, puis regroupe les embeddings au niveau des tokens en vecteurs de chunks. Ainsi, chaque chunk porte le contexte de tout le document, et « ça coûte 40 $/mois » sait à quoi « ça » réfère. L'abstract revendique une récupération supérieure sur plusieurs tâches mais ne publie aucun chiffre phare que nous ayons pu vérifier. L'article de Weaviate explique la mécanique et s'arrête, lui aussi, avant toute comparaison contrôlée. État des preuves : prometteur, non quantifié.

Chunking hiérarchique (parent-enfant)

Indexez de petits chunks (256 tokens) pour la récupération ; renvoyez le parent (1 024 tokens) au générateur. Le retriever trouve l'aiguille ; le générateur reçoit la botte de foin autour. Vous maintenez deux niveaux d'index et une table de correspondance parent-enfant. Aucun benchmark public n'isole cet effet.

Chunking basé sur un LLM / agentique

Le LLMSemanticChunker de l'étude de Chroma utilise GPT-4o pour décider des points de découpe de chaque document : 91,7 % de rappel (le plus haut) et 3,9 % de précision (la plus basse). Vous payez un appel LLM par document au moment de l'indexation (environ 100 $ pour un corpus de 10 000 documents) et vous envoyez plus de bruit au générateur. Réservez-le aux corpus vraiment irréguliers : dépôts juridiques, PDF scannés sans titres extractibles.

Quelle taille de chunk pour votre modèle d'embedding ?

Le nombre maximal de tokens en entrée de votre modèle d'embedding est un plafond de troncature, pas une recommandation. Un modèle qui accepte 8 192 tokens n'embedde pas mieux à 8 192 qu'à 512. La qualité se dégrade par dilution bien avant le plafond : le modèle fait la moyenne du sens sur plus de tokens et le vecteur dérive vers le centroïde du corpus. La colonne de recommandation ci-dessous est l'interprétation de Techsy, pas les conseils des éditeurs.

Sources : guide des embeddings OpenAI, docs Cohere embed, docs des embeddings Voyage, model card BGE.

Le schéma : les modèles avec un plafond dur de 512 tokens (Cohere v3, BGE) exigent des chunks bien inférieurs à 512, car la troncature est silencieuse. Donnez-en 600 à l'un d'eux et les 88 derniers disparaissent de l'embedding sans qu'aucune erreur ne soit journalisée. Les modèles avec de grands plafonds (OpenAI, Voyage, Cohere v4) tolèrent des chunks plus gros mais ne les récompensent pas. La longueur d'entrée maximale d'un modèle est une limite de troncature, pas une recommandation.

Associez ceci à notre comparatif des meilleurs modèles d'embedding pour le RAG, à ce que mesure vraiment un score MTEB et au comparatif des embeddings Voyage, OpenAI et Cohere avant de vous engager sur un modèle.

Comment chunker des documents non-anglais ?

Les tokenizers ne sont pas neutres vis-à-vis de la langue. Petrov et al. ont montré dans « Language Model Tokenizers Introduce Unfairness Between Languages » (arXiv 2305.15425, 2023) qu'un même texte traduit d'une langue à l'autre peut différer en longueur tokenisée jusqu'à 15x. Même les modèles au niveau des caractères et des octets affichent plus de 4x de différence pour certaines paires de langues. Un chunk de 512 tokens contient bien moins de sens en turc, en arabe ou en japonais qu'en anglais.

Voici la même phrase tokenisée avec l'encodage cl100k_base de tiktoken (le tokenizer de GPT-4) :

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Comptes générés avec tiktoken cl100k_base, le 30 juillet 2026.

Conseils pratiques : à une taille fixe de 512 tokens, vos chunks turcs et japonais contiennent environ 37 % du sens de vos chunks anglais, et vos chunks arabes environ 26 %. Chunkez par nombre de caractères ou par nombre de phrases selon la langue, ou augmentez le budget de tokens proportionnellement (environ 1 400 pour le turc, 2 000 pour l'arabe). Les langues CJK n'ont pas de frontières de mots par espaces, donc les splitters par caractères s'y comportent différemment. La morphologie de l'arabe entasse plusieurs marqueurs grammaticaux dans des tokens uniques, ce qui gonfle encore les comptes.

Un arbre de décision pour choisir votre stratégie de chunking

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

Trois prescriptions rapides. Chatbot sur documentation : MarkdownHeaderTextSplitter à 512 tokens, zéro chevauchement, chemin des titres dans les métadonnées. Assistant de recherche de code : découpage sur les frontières de l'AST à 256-512 tokens par fonction, imports préfixés. Corpus d'entreprise mixte : routez par type de document à l'ingestion et stockez dans la base de données vectorielle qui héberge vos chunks avec des métadonnées de type pour un réglage par type plus tard. Ce routage par document est l'essentiel du chunking adaptatif pour les applications RAG.

Outils : LangChain vs LlamaIndex vs Chonkie

Nous ne vendons aucun de ces outils ; les trois premières pages de résultats sur ce mot-clé sont des blogs d'éditeurs avec des CTA produit.

Sources : docs LangChain, NodeParsers LlamaIndex, docs Chonkie.

Les trois implémentent les mêmes algorithmes de base ; choisissez donc selon ce que votre pipeline utilise déjà. Pour l'écosystème d'outils RAG au sens large au-delà des splitters et le comparatif Qdrant, Chroma et pgvector pour le stockage, consultez nos guides de cluster.

L'approche du chunking chez Techsy

Sur les projets RAG clients, l'équipe de Techsy commence à 512 tokens avec 10 % de chevauchement et ne touche pas au splitter tant que nous n'avons pas construit un jeu d'évaluation de 20 à 50 questions à partir des vrais tickets de support du client. Le jeu d'évaluation vient d'abord ; ensuite nous changeons une variable à la fois : taille, chevauchement, stratégie. Pas de changement de splitter sans un chiffre avant/après sur les mêmes questions. Demandez une consultation gratuite pour un second regard sur votre pipeline de récupération.

Questions fréquemment posées

Qu'est-ce que le chunking en RAG ?

Le chunking est l'étape de prétraitement qui découpe les documents en segments plus petits avant l'embedding, afin que le retriever puisse confronter les requêtes à des passages focalisés plutôt qu'à des fichiers entiers. Les points de découpe déterminent ce que votre système peut et ne peut pas trouver au moment de la requête.

Quelle est la meilleure stratégie de chunking pour le RAG ?

Pour la plupart des systèmes en production sur des documents généralistes, le chunking récursif par caractères à 512 tokens avec 10 % de chevauchement est le choix par défaut le plus solide. Dans l'étude de Chroma sur 472 requêtes (juillet 2024), il obtient 88,5 % de rappel, à 3,2 points de la méthode basée sur un LLM la plus coûteuse, sans aucun coût supplémentaire.

Quelle est la taille de chunk optimale pour le RAG ?

Commencez à 512 tokens. Descendez à 256 si votre modèle d'embedding plafonne à 512 tokens en entrée (Cohere v3, BGE) ou si vos requêtes attendent des réponses en une seule phrase. Montez à 1 024 uniquement si votre jeu d'évaluation montre que des réponses multi-paragraphes sont fragmentées. Mesurez toujours face à vos propres questions.

Quel chevauchement de chunk utiliser ?

10 à 20 % de la taille du chunk (50 à 100 tokens à 512). Le chevauchement empêche les phrases en bordure de rester orphelines : un fait coupé entre deux chunks apparaît complet dans au moins un des deux. Au-delà de 20 %, vous ré-embeddez une trop grande partie du corpus pour des gains décroissants. La plupart des équipes se fixent à 10 % et n'y reviennent jamais.

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

De peu, et pour le double de coût d'embedding. Le benchmark de Chroma de juillet 2024 montrait le chunker sémantique par cluster à 89,0 % de rappel et 6,7 % de précision, contre 88,5 % de rappel et 7,0 % de précision pour le récursif à la même taille de tokens, son résultat de meilleure précision à 8,0 % provenant d'un autre paramétrage de récupération. Cela vaut le coup pour des corpus à sujets variés ; c'est difficile à justifier pour des ensembles de documents homogènes.

La taille de chunk dépend-elle du modèle d'embedding ?

Oui. Les modèles avec un plafond de 512 tokens en entrée (BGE, Cohere v3) exigent des chunks bien inférieurs à 512, car la troncature est silencieuse. Les modèles avec des plafonds de 8 192 et plus tolèrent des chunks plus grands mais ne les récompensent pas ; la qualité de l'embedding se dégrade par dilution avant le plafond. Voir le tableau d'association ci-dessus pour les points de départ par modèle.

Comment chunker du code pour un système RAG ?

Découpez sur les frontières de l'AST (définitions de fonctions et de classes) plutôt que sur des nombres de tokens. Gardez chaque chunk entre 256 et 512 tokens par fonction, préfixez le bloc d'imports du fichier et la signature de la classe englobante, et utilisez zéro chevauchement puisque les fonctions sont des unités autonomes. Le CodeSplitter de LlamaIndex et les splitters conscients du langage de LangChain gèrent tous les deux ce cas.

Qu'est-ce que le late chunking ?

Le late chunking génère d'abord l'embedding du document entier avec un modèle long contexte, puis regroupe les embeddings au niveau des tokens en vecteurs de chunks. L'embedding de chaque chunk porte le contexte de tout le document, ce qui résout le problème « à quoi "ça" réfère-t-il ? ». Introduit par Günther et al. (arXiv 2409.04701, septembre 2024). Aucun benchmark public en face-à-face ne quantifie encore le gain.

Comment chunker des documents dans d'autres langues que l'anglais ?

Les nombres de tokens ne sont pas neutres vis-à-vis de la langue. La même phrase prenait 2,7x plus de tokens en turc et en japonais qu'en anglais, et 3,9x en arabe (tiktoken cl100k_base). Un budget fixe de 512 tokens donne silencieusement moins de sens aux chunks non-anglais. Chunkez par nombre de caractères ou de phrases selon la langue, ou augmentez le budget proportionnellement.

Comment savoir si mon chunking fonctionne vraiment ?

Construisez un jeu d'évaluation de 20 à 50 questions à partir de vraies requêtes d'utilisateurs avant de toucher au splitter. Notez le hit@5 et le MRR sur vos chunks actuels. Changez une variable (taille, chevauchement, stratégie), relancez, comparez. Sans jeu d'évaluation, vous réglez à l'intuition. Vingt questions suffisent pour commencer.

L'essentiel à retenir

• Commencez par le chunking récursif par caractères à 512 tokens, 10 % de chevauchement. Le bon choix par défaut pour la prose plate.
• Parmi les quatre familles de splitters que quelqu'un a mesurées, les 472 requêtes de Chroma déplacent le rappel d'environ 5 points et la précision plusieurs fois plus. Réglez d'abord pour la précision et le coût.
• Assortissez la taille de chunk au plafond d'entrée de votre modèle d'embedding. Un modèle plafonné à 512 tokens exige des chunks inférieurs à 512.
• Enrichissez les chunks avec du contexte (la chute du taux d'échec de 5,7 % à 3,7 % chez Anthropic) avant de réajuster le splitter.
• Construisez le jeu d'évaluation d'abord. Chaque décision de splitter sans chiffre avant/après est une supposition.

Pour le pipeline complet autour de votre choix de chunking, voyez construire une application RAG de bout en bout. Vous hésitez encore entre récupération et fine-tuning ? RAG ou fine-tuning détaille quand chacun l'emporte.