Lotook
Pour découper efficacement des documents pour le RAG, commencez par diviser les fichiers selon leur structure existante, limitez ensuite la longueur en tokens des sections trop grandes avec un chevauchement au niveau des phrases, et associez des métadonnées de source à chaque passage. Le choix entre découpage par tokens, sémantique et fondé sur la structure dépend de la composition de votre corpus : prose uniforme, changements de sujet, ou tableaux et titres mis en forme.
Pourquoi le découpage en chunks pour le RAG détermine-t-il la qualité de la recherche ?
La Retrieval-Augmented Generation (RAG) divise les documents sources en passages plus courts avant de les vectoriser et de les stocker dans un index de recherche. Lors d’une requête, le système récupère les chunks les plus pertinents et les transmet à un modèle de langage avec la question de l’utilisateur. Le découpage détermine l’unité de recherche, car un document entier est généralement trop vaste pour correspondre précisément à une question et trop volumineux pour tenir avec d’autres candidats dans la fenêtre de contexte du modèle.
Lorsque Patrick Lewis et ses collègues ont présenté cette approche dans leur article NeurIPS de 2020 (Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks), leur expérience divisait chaque article Wikipedia en chunks sans chevauchement d’environ 100 mots, produisant environ 21 millions de passages. Ce découpage en blocs de 100 mots était un choix expérimental de 2020 pour Wikipedia, et non une valeur par défaut en production pour 2026. En novembre 2026, le RAG moderne en production fonctionne généralement sous forme de pipeline modulaire (découpage, vectorisation, indexation, recherche et génération), plutôt que selon la configuration DPR et BART d’origine, différentiable de bout en bout.
Quelles sont les trois principales méthodes de découpage pour le RAG ?
Les méthodes de découpage pour le RAG se répartissent en trois familles : par tokens, sémantique et fondée sur la structure. Chaque famille détermine le début et la fin d’un passage à partir de sa longueur, de son sens ou du balisage du document.
| Méthode de découpage | Signal de découpage | Adaptée à | Risque principal | Coût d’indexation |
|---|---|---|---|---|
| Découpage par tokens (ou longueur) | Fenêtre fixe de tokens ou de caractères avec chevauchement glissant | Prose uniforme, texte brut ou limite de longueur après découpage structurel | Coupe des phrases, lignes de tableau, blocs de code ou définitions en deux | Faible |
| Découpage sémantique | Baisse de similarité des embeddings entre phrases voisines | Prose non formatée dont les sujets changent au milieu du document sans titre | Indexation plus lente et coûteuse ; tailles de chunks irrégulières | Élevé |
| Découpage fondé sur la structure | Titres, paragraphes, listes, tableaux, blocs de code ou pages | Markdown, HTML, documentation d’API, clauses juridiques et manuels structurés | Structure peu claire dans les PDFs numérisés ; certaines sections peuvent rester énormes | Faible à moyen |
1. Découpage par tokens et caractères
Le découpage par tokens divise le texte en fenêtres de longueur fixe mesurée en tokens ou en caractères, souvent avec un chevauchement glissant. La mesure en tokens correspond au fonctionnement des modèles : les modèles d’embedding et les LLM ont des limites strictes en tokens, les API sont facturées en tokens et un même paragraphe peut être tokenisé différemment selon la famille de modèles. Le nombre de caractères n’est qu’une approximation grossière.
Les équipes commencent généralement avec une taille de fenêtre qui respecte la limite de leur modèle d’embedding (les tutoriels commencent souvent à quelques centaines de tokens), puis l’ajustent après examen des échecs de recherche. Le principal risque d’une fenêtre fixe est d’ignorer la syntaxe et la mise en page, en coupant une phrase, une ligne de tableau, un bloc de code ou une définition et en omettant la proposition qui répond à la question.
2. Découpage sémantique
Le découpage sémantique divise le texte lorsque le sens change, par exemple lorsque la similarité des embeddings entre phrases voisines baisse ou qu’une frontière discursive apparaît, plutôt qu’à un nombre fixe de tokens. Garder une idée complète dans un chunk facilite la recherche lorsque les sujets changent au milieu d’un document sans titre.
L’indexation avec découpage sémantique est toutefois plus lente et plus coûteuse, car le découpage lui-même peut nécessiter des appels d’embedding. Un seuil de similarité bruité peut aussi découper le texte excessivement ou insuffisamment en chunks de tailles irrégulières, et la similarité des phrases n’est pas automatiquement meilleure pour les tableaux, formulaires ou le code.
3. Découpage fondé sur la structure
Le découpage fondé sur la structure utilise d’abord la structure existante du document : titres Markdown ou HTML, paragraphes, listes, sections, pages, blocs de code délimités ou frontières de tableaux. Comme le souligne l’AWS Prescriptive Guidance sur le RAG, préserver la structure du document maintient intact le contexte logiquement lié. Un chunk commençant par un titre de politique de remboursement et contenant toute la section est plus facile à retrouver et à citer qu’une fenêtre commençant au milieu d’une phrase.
Comme de nombreux PDFs et documents numérisés n’ont pas de titres clairs (et qu’un seul titre peut couvrir 20 pages), les pipelines de production combinent généralement plusieurs méthodes :
- Découper d’abord hiérarchiquement selon la structure : divisez le document par section ou titre, puis par paragraphe ou bloc, en gardant intacts les blocs de code, tableaux et listes.
- Appliquer ensuite une limite de longueur en tokens : si une section reste trop grande, divisez-la avec une fenêtre de tokens.
- Prévoir des découpages de secours pour le texte non structuré : pour les PDFs numérisés ou les longues sections non structurées, utilisez des séparations par page, des fenêtres de tokens ou des frontières sémantiques.
Comment configurer le chevauchement des chunks et les métadonnées RAG ?
Le chevauchement des chunks et les métadonnées des passages évitent de perdre des propositions aux frontières et relient les extraits récupérés à leurs documents sources.
Configurer le chevauchement des chunks
Le chevauchement répète la fin d’un chunk au début du suivant afin qu’une phrase ou une définition située à une frontière apparaisse en entier dans au moins un passage récupéré. C’est une précaution simple lorsque des fenêtres fixes ou des découpages de secours coupent une idée en deux.
Dimensionnez le chevauchement pour couvrir une ou deux phrases typiques de votre corpus, tout en le gardant assez petit pour ne pas stocker deux fois presque le même chunk. Le chevauchement augmente le nombre de tokens vectorisés, stockés et récupérés, ce qui grossit l’index et ajoute aux résultats des voisins presque identiques. Si la recherche renvoie souvent des chunks presque identiques, réduisez le chevauchement ou la taille des chunks, ou ajoutez une étape de déduplication après la recherche.
Ajouter des métadonnées RAG
Les métadonnées RAG sont des champs structurés stockés avec chaque chunk, notamment :
- ID ou URL du document source et titre
- Chemin de section ou de titres et numéro de page
- Date de création ou de mise à jour et type de document (politique, ticket, référence d’API)
- Étiquettes d’accès et d’autorisation, langue et ID stable du chunk
Les équipes peuvent exclure les métadonnées de l’embedding lorsque des ID bruts ou des horodatages fausseraient la similarité, ou ajouter certains champs (comme un titre de section) au début du texte vectorisé lorsqu’ils améliorent la recherche. Les métadonnées répondent à trois besoins en production :
- Citations : votre interface ou votre modèle peut citer un fichier, un titre et un numéro de page plutôt qu’un simple passage.
- Filtres d’autorisation et de version : récupérez uniquement la dernière version d’une politique, un produit précis ou les documents que l’utilisateur est autorisé à voir. Les autorisations doivent figurer dans les filtres de l’index et pas seulement dans le prompt, car placer des documents privés dans un index RAG non filtré les expose à toute personne pouvant interroger le système.
- Débogage et mises à jour : lorsqu’un document source change, découpez-le et vectorisez-le à nouveau, puis retirez les anciens ID de chunks pour éviter que des faits périmés ne causent des erreurs factuelles.
Comment savoir si vos chunks sont trop grands ou trop petits ?
Examiner les chunks récupérés pour de vraies questions d’utilisateurs révèle si vos passages sont trop grands ou fragmentés.
Signes que vos chunks sont trop grands
- Réponses enfouies : la recherche renvoie une longue section qui mentionne le terme recherché mais cache la réponse réelle, que le modèle doit chercher ou manque.
- Prompts surchargés : seuls quelques chunks tiennent dans le prompt, si bien qu’un résultat médiocre prend la place de meilleurs résultats.
- Coût et latence plus élevés : envoyer beaucoup de tokens non pertinents augmente les dépenses et le temps de réponse.
- Distraction accrue : le bruit supplémentaire aggrave le context rot : le modèle dispose du bon fait dans un grand prompt, mais s’appuie sur sa mémoire d’entraînement ou sur une phrase voisine erronée.
Signes que vos chunks sont trop petits
- Fragments incomplets : un chunk récupéré est incompréhensible sans la phrase précédente (par exemple une phrase qui énonce une exception pour les offres entreprise sans nommer la règle).
- Réponses en plusieurs parties séparées : une définition et son exception, une fonction et ses paramètres, ou une politique et sa date d’entrée en vigueur se retrouvent dans des chunks distincts, et top-k ne renvoie qu’une partie.
- Fragments presque identiques : vous récupérez beaucoup d’extraits répétitifs sans obtenir une idée complète, tandis que les citations deviennent confuses car chaque phrase est une source distincte.
Pour ajuster les tailles en pratique, examinez de vraies questions et les chunks récupérés, puis demandez-vous si une personne disposant uniquement de ces passages pourrait répondre. Si la phrase nécessaire se trouve dans un chunk voisin non récupéré, ajustez le chevauchement, les règles de structure ou la taille. Si elle se trouve dans le chunk récupéré entourée de texte sans rapport, découpez plus petit ou récupérez moins de chunks, plus ciblés.
Quel est l’effet du découpage RAG sur le context rot ?
Le découpage RAG agit directement contre le context rot, c’est-à-dire la baisse de qualité du raisonnement, du suivi des instructions et du rappel d’un modèle lorsqu’un prompt devient plus long ou plus encombré, même bien en dessous de la limite de contexte annoncée.
Le RAG permet de ne pas placer tout le corpus dans le prompt. Cependant, récupérer des chunks trop grands, ou augmenter top-k par précaution et remplir le prompt de nombreux chunks vaguement similaires, recrée un contexte long et bruité. Plus de contexte ne signifie pas automatiquement plus de précision. Des chunks ciblés réduisent l’encombrement du prompt, mais un bon découpage ne peut à lui seul corriger un mauvais modèle d’embedding ni éliminer les hallucinations de l’IA lorsqu’un modèle ignore le texte récupéré.
FAQ
Faut-il mesurer la taille des chunks RAG en tokens ou en caractères ?
Mesurez la taille des chunks RAG en tokens chaque fois que possible. Les modèles d’embedding et de langage imposent des limites de contexte en tokens, et l’utilisation des API est facturée par token. Le nombre de caractères n’est qu’une approximation grossière, car un même paragraphe peut produire un nombre différent de tokens selon les langues, les blocs de code et les familles de modèles. Le tokenizer de votre modèle d’embedding évite une troncature inattendue lors de l’indexation.
Le découpage sémantique est-il toujours meilleur que le découpage par tokens ?
Le découpage sémantique n’est pas automatiquement meilleur que le découpage par tokens ou fondé sur la structure. Découper lorsque la similarité des phrases baisse aide à garder les idées ensemble dans une prose non structurée, mais exige davantage de travail d’embedding à l’indexation, produit des chunks de tailles irrégulières et peut découper trop ou trop peu avec un seuil bruité. Pour les documents formatés, découper selon les titres, tableaux et blocs de code est plus rapide et suit les frontières prévues par l’auteur.
Comment découper les tableaux et blocs de code pour le RAG ?
Les tableaux, factures, clauses juridiques et le code exigent des règles fondées sur la structure qui maintiennent les blocs intacts. Un découpage naïf par caractères ou tokens au milieu d’un tableau Markdown ou du corps d’une fonction produit des chunks inutilisables qui séparent les valeurs des en-têtes de colonnes ou cassent la syntaxe. Gardez les blocs de code, tableaux et listes entiers si possible, et n’appliquez des solutions de secours fondées sur la structure que lorsqu’un bloc dépasse les limites du modèle.
Faut-il inclure les métadonnées dans l’embedding du chunk ?
Inclure les métadonnées dans le texte vectorisé est un choix de conception qui dépend du champ. Ajouter un titre de document ou un chemin de titres de section au début du texte du chunk améliore souvent la recherche lorsque les paragraphes dépendent du titre pour leur contexte. Les identifiants bruts, horodatages et étiquettes d’accès doivent rester dans des champs de métadonnées distincts et filtrables afin de ne pas fausser la similarité des embeddings.
Que se passe-t-il lorsqu’un document source change ?
Lorsqu’un document source change, votre pipeline d’ingestion doit le découper et le vectoriser à nouveau, puis retirer les anciens ID de chunks de l’index. Laisser des chunks périmés actifs à côté des chunks mis à jour amène le système de recherche à présenter des politiques obsolètes ou des passages contradictoires, transformant un oubli de maintenance de l’index en erreur factuelle dans la réponse finale.
