Stratégies de chunking

#Pourquoi le chunking pèse autant que le modèle d'embedding

Le chunking est l'opération qui coupe un document en passages avant de les indexer : chaque passage reçoit un vecteur, et c'est un passage, jamais le document entier, qui sera retrouvé puis transmis au modèle de langage. Tout ce qui suit dépend de ce découpage. Si la phrase qui répond à la question est coupée entre deux passages, aucun des deux ne la contient en entier et la recherche la rate ; si le passage mélange trois sujets, son vecteur est une moyenne floue qui ne ressemble fortement à aucune question. Un embedding plus puissant ne répare pas un découpage défaillant, puisqu'il ne peut vectoriser que ce qu'on lui donne.

Une étude de Chroma sur l'évaluation des stratégies de découpage le montre : les méthodes heuristiques comme le RecursiveCharacterTextSplitter donnent souvent de bons résultats en pratique quand elles sont bien paramétrées, et les résultats varient nettement selon la taille et le recouvrement choisis. Ce guide ne promet donc aucun gain chiffré général : la seule chose fiable est de mesurer sur vos documents.

#Quelle taille de chunk choisir

Il n'existe pas de taille universelle, mais il existe des repères. Dans l'étude de Chroma, la stratégie récursive dépasse le découpage par tokens pour des tailles de 400 tokens ou moins sans recouvrement, et le comportement diffère pour des tailles plus grandes et avec recouvrement. La configuration par défaut de l'outil de recherche de fichiers d'OpenAI, 800 tokens avec 400 de recouvrement, obtient dans ce banc d'essai un rappel légèrement inférieur à la moyenne et les scores les plus bas sur les autres métriques. Les repères ci-dessous en découlent, sans prétendre à l'exactitude pour votre corpus.

#Tokens ou caractères : le piège des unités

Les bibliothèques ne comptent pas toutes dans la même unité. Le SentenceSplitter de LlamaIndex exprime chunk_size et chunk_overlap en tokens, avec 1024 et 200 par défaut selon sa documentation. D'autres outils, dont le RecursiveCharacterTextSplitter de LangChain, comptent par défaut en caractères ; vérifiez le paramètre length_function de votre version. Régler « 500 » dans l'un ou l'autre donne des chunks dont la taille varie d'un facteur de l'ordre de quatre. Deuxième contrainte : le modèle d'embedding a sa propre longueur d'entrée maximale. Le modèle BGE-M3 gère des entrées jusqu'à 8 192 tokens selon sa fiche ; d'autres modèles d'embedding, plus anciens ou plus légers, acceptent nettement moins, et au-delà la fin du passage est ignorée. Vérifiez la limite de votre modèle avant de choisir la taille, et comptez avec le tokenizer du modèle plutôt qu'à l'œil.

#Recouvrement : utile, mais pas toujours

Le recouvrement répète la fin d'un chunk au début du suivant, pour qu'une phrase coupée en limite reste lisible d'un côté au moins. Il a un coût : plus de chunks, un index plus gros, et des doublons dans les résultats. L'étude de Chroma note qu'en réduisant le recouvrement, on améliore le score IoU, une métrique qui pénalise les informations redondantes. Le recouvrement se justifie si vous coupez à taille fixe ; il compte moins si vous coupez déjà sur les paragraphes et les titres, puisque les coupures tombent alors aux frontières naturelles.

0 token

Suffisant avec un découpage par paragraphes ou par structure ; le plus économe.

10 à 15 % de la taille

Bon compromis quand on coupe sur phrases ou caractères.

Plus de 25 %

Rarement justifié : beaucoup de redondance, des passages quasi identiques dans les résultats.

#Les stratégies de découpage, de la plus simple à la plus coûteuse

#1. Par caractères fixes

Couper tous les N caractères ou tokens, sans regarder le texte. Le plus simple, et le plus destructeur : il coupe au milieu des mots, des phrases, des tableaux. À réserver aux prototypes.

#2. Par paragraphes ou par phrases

Couper sur les doubles retours à la ligne ou sur la ponctuation, puis regrouper les unités jusqu'à la taille cible. Un progrès net à coût nul, car chaque chunk commence et finit à une frontière naturelle.

#3. Récursif

On tente d'abord les gros séparateurs (paragraphe, ligne, phrase, espace), et on ne descend au caractère qu'en dernier recours. C'est le comportement par défaut dans les principaux frameworks, et une base solide : l'étude de Chroma constate que ce type de découpage, bien paramétré, se comporte souvent bien.

#4. Selon la structure du document

On respecte les titres, listes, tableaux et blocs de code. Le MarkdownNodeParser de LlamaIndex, par exemple, découpe selon les titres et joint à chaque nœud le chemin des titres qui y mènent, ce qui donne au passage un contexte que son texte seul n'a pas. C'est le meilleur choix pour de la documentation technique, des wikis, des pages HTML exportées.

#5. Sémantique

On calcule un embedding par phrase, puis on coupe là où la similarité chute entre deux phrases voisines. Dans LlamaIndex, le SemanticSplitterNodeParser prend un buffer_size (nombre de phrases comparées ensemble, 1 par défaut) et un breakpoint_percentile_threshold (95 par défaut ; une valeur plus basse crée plus de nœuds). Le coût est un calcul d'embeddings supplémentaire à l'indexation, et le bénéfice n'est pas établi : une étude d'octobre 2024 sur trois tâches de récupération conclut que les coûts de calcul du découpage sémantique ne sont pas justifiés par des gains de performance constants. Testez-le sur votre corpus avant de l'adopter.

#6. Hiérarchique (parent et enfant)

On indexe de petits chunks pour la précision de la recherche, et on renvoie au modèle le bloc parent plus large pour le contexte. Le HierarchicalNodeParser de LlamaIndex produit ce genre de hiérarchie, par exemple à trois niveaux de 2048, 512 et 128 tokens selon sa documentation. C'est la réponse aux passages longs : ni petit-seulement, ni grand-seulement.

#Implémentations avec LlamaIndex

from llama_index.core.node_parser import SentenceSplitter

splitter = SentenceSplitter(chunk_size=400, chunk_overlap=40)  # en tokens
nodes = splitter.get_nodes_from_documents(docs)

from llama_index.core.node_parser import MarkdownNodeParser

parser = MarkdownNodeParser()
nodes = parser.get_nodes_from_documents(docs)
# le chemin des titres est stocké dans les métadonnées de chaque nœud

from llama_index.core.node_parser import HierarchicalNodeParser, get_leaf_nodes

parser = HierarchicalNodeParser.from_defaults(chunk_sizes=[2048, 512, 128])
nodes = parser.get_nodes_from_documents(docs)
leaves = get_leaf_nodes(nodes)  # ce sont les feuilles qu'on vectorise

from llama_index.core.node_parser import SemanticSplitterNodeParser
from llama_index.embeddings.huggingface import HuggingFaceEmbedding

embed = HuggingFaceEmbedding(model_name="BAAI/bge-m3")
splitter = SemanticSplitterNodeParser(embed_model=embed, buffer_size=1, breakpoint_percentile_threshold=95)
nodes = splitter.get_nodes_from_documents(docs)

#Redonner du contexte à chaque chunk

Un passage arraché à son document perd ses repères : « Le délai est de 30 jours » ne dit pas de quoi il s'agit. Trois pratiques simples y remédient. Préfixer chaque chunk du titre du document et du chemin de section ; stocker ces informations en métadonnées pour filtrer (par date, par source, par type de document) ; et, pour les passages qui commencent par un pronom ou une référence (« cette clause »), envisager le niveau parent du découpage hiérarchique. Une seule ligne de contexte avant le texte suffit souvent, et elle coûte bien moins que de changer de modèle.

#Évaluer son chunking avant de le figer

1. 01
   Écrire 30 à 50 vraies questions

   Des questions que vos utilisateurs poseraient, avec pour chacune le passage source attendu ; rédigez-les avant de regarder les résultats.
2. 02
   Indexer avec deux ou trois configurations

   Par exemple 250, 400 et 700 tokens, avec un recouvrement de 0 et de 10 %. Gardez les autres paramètres identiques.
3. 03
   Mesurer le rappel dans les 5 premiers résultats

   Pour chaque question, le passage attendu figure-t-il dans les 5 premiers résultats ? Le pourcentage donne le rappel à 5.
4. 04
   Regarder aussi la précision et la redondance

   Un rappel identique avec des résultats plus variés est un meilleur réglage. Comptez les doublons dans le top 5.
5. 05
   Lire les échecs un par un

   Pour chaque question ratée, ouvrez le chunk qui aurait dû répondre : coupé, trop large, extrait cassé ? La cause dicte le correctif.

#Pièges fréquents

Tableaux cassés

Un extracteur PDF qui aplatit un tableau produit des lignes de cellules sans sens : extrayez la structure en amont avant le découpage.

Blocs de code coupés

Un découpeur sans connaissance de la syntaxe coupe un bloc au milieu ; utilisez un découpage selon la structure.

Documents mixtes

Un chunk moitié français, moitié anglais, produit un vecteur moyen peu utile : séparez par langue si le corpus est mixte.

Chunks quasi vides

Un titre seul (« 3.2.1 Obligations ») sans le texte qui suit est du bruit : filtrez les chunks trop courts ou fusionnez-les avec le suivant.

Changer de chunking sans réindexer

Le découpage est figé à l'indexation : tout changement impose de recalculer les vecteurs. Prévoyez un script de réindexation dès le départ.

#Questions fréquentes sur le chunking

• Ajouter un reranker à son pipeline
• Recherche hybride BM25 + vectoriel
• Les meilleurs modèles d'embeddings FR
• RAG en local avec ChromaDB et Ollama
• LlamaIndex en pratique

• Source : Chroma, Evaluating Chunking Strategies for Retrieval
• Source : Is Semantic Chunking Worth the Computational Cost ?
• Source : LlamaIndex, node parsers
• Source : fiche Hugging Face de BAAI/bge-m3