Chunking et préparation du corpus

Pourquoi le chunking détermine la qualité de tout le pipeline RAG

Un système RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire (retrieval-augmented generation) ne peut restituer que ce qu'il a indexé, et il ne peut indexer que ce que le chunkingChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire lui a livré comme unités. Un modèle d'embeddingembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire excellent et un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire performant en génération ne compensent pas des chunks mal taillés : si l'unité récupérée est incomplète, hors contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire ou noyée dans du bruit, la réponse finale hérite de ce défaut, quelle que soit la qualité du reste de la chaîne.

Le chunking est donc une décision d'architecture, pas un détail d'implémentation traité en fin de projet. Il conditionne trois choses simultanément : la pertinence de la recherche (un chunk trop large dilue le signal vectoriel), la complétude de la réponse (un chunk trop petit ampute une explication de son contexte), et le coût du système (plus de chunks signifie plus de vecteurs à stocker et à interroger).

La configuration optimale dépend du type de document, de la distribution réelle des questions posées par les utilisateurs, et du modèle d'embedding utilisé. Une valeur qui fonctionne bien pour une base de FAQ courtes peut être contre-productive pour des contrats juridiques ou de la documentation technique structurée. Ce chapitre donne des repères de départ, pas des constantes à appliquer sans validation.

Taille de chunk : le compromis central

Le paramètre chunk_size arbitre un compromis entre deux erreurs opposées.

Un chunk trop petit isole une phrase ou un fragment de sa justification, de sa condition d'application ou de l'exemple qui la rend compréhensible. Le modèle de génération reçoit un extrait techniquement pertinent mais insuffisant pour répondre correctement, ou pire, il complète le manque avec des connaissances générales potentiellement fausses dans le contexte précis du document source.

Un chunk trop grand dilue le signal au moment de l'embedding : un vecteur unique représente alors plusieurs idées distinctes, ce qui dégrade sa capacité à matcher précisément une requête ciblée. Il consomme aussi une part disproportionnée du budget de contexte du LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire au moment de la génération, réduisant le nombre de sources différentes qu'on peut lui soumettre pour une même question.

Ces valeurs sont des points de départ raisonnables, pas des cibles à atteindre aveuglément. La seule validation fiable consiste à construire un jeu de questions représentatif — un golden set — et à mesurer le taux de récupération correcte pour plusieurs configurations avant de trancher.

L'overlap : pourquoi chevaucher les chunks

Découper un texte en segments contigus et parfaitement jointifs pose un problème systématique : une idée, une définition ou une phrase peut se trouver coupée exactement à la frontière entre deux chunks. Le lecteur humain recolle intuitively ce type de coupure ; un système de recherche vectorielle, lui, traite chaque chunk comme une unité indépendante et n'a aucun moyen de reconstituer automatiquement ce qui a été séparé.

L'overlap (chevauchement) consiste à faire répéter une portion du texte à la fin d'un chunk au début du suivant, de sorte qu'aucune idée ne se retrouve isolée d'un seul côté d'une frontière artificielle.

En pratique, un overlap représentant 10 à 20 % de la taille du chunk suffit dans la majorité des cas. Le pas d'avancement (stride) se calcule simplement : stride = chunk_size - overlap. Pour des chunks de 500 tokens avec 15 % d'overlap, le stride est d'environ 425 tokens.

Chaque token dupliqué entre deux chunks est stocké et embeddé deux fois. Un overlap excessif (au-delà de 30-40 %) gonfle inutilement l'index, ralentit l'indexation, et peut produire un effet pervers en recherche : plusieurs chunks quasi identiques remontent dans le top-k pour la même requête, ce qui réduit la diversité réelle du contexte fourni au LLM au lieu de l'enrichir.

Stratégies de découpage

Plusieurs approches coexistent, avec des niveaux de sophistication et des coûts de calcul différents.

Découpage à taille fixe. La méthode la plus simple : on tranche le texte tous les N caractères ou tokens, sans tenir compte de la structure. Rapide, mais aveugle — elle peut couper en plein milieu d'une phrase ou d'une cellule de tableau. À réserver aux corpus très homogènes ou aux prototypes rapides.

Découpage récursif. On coupe aux frontières les plus significatives d'abord (paragraphes), puis on descend vers des séparateurs plus fins (phrases, puis mots) uniquement si le segment dépasse encore la taille cible. Une liste de séparateurs typique ressemble à ["\n\n", "\n", ". ", " ", ""]. C'est l'approche la plus utilisée en production, pour son bon rapport simplicité/qualité.

Pour un document Markdown, on essaie d'abord de couper aux doubles sauts de ligne. Si un paragraphe dépasse encore la taille cible, on retente sur les sauts de ligne simples, puis sur les fins de phrase (". "), et en dernier recours sur les espaces. Ce n'est qu'en l'absence totale de séparateur naturel qu'on tranche au caractère près — un cas rare sur du texte bien formé.

Découpage structuré (structure-aware). Le texte est segmenté en respectant sa structure logique : titres et sous-titres Markdown ou HTML, sections d'un PDF, blocs fonction/classe d'un fichier de code via son arbre syntaxique (AST). Chaque chunk correspond à une unité de sens réelle plutôt qu'à une tranche arbitraire — l'approche la plus robuste pour de la documentation technique bien hiérarchisée.

Chunking sémantique. Les phrases sont embeddées individuellement, puis on détecte les ruptures thématiques via une chute de similarité cosinus entre phrases consécutives : on coupe là où le sujet change réellement. Plus coûteux en calcul, cette méthode est surtout utile sur du contenu long-format hétérogène où la structure explicite ne reflète pas fidèlement les ruptures de sujet.

Enrichir chaque chunk de métadonnées

Un chunk isolé de tout contexte documentaire perd une grande partie de son utilité, même s'il est parfaitement découpé. Chaque unité indexée devrait porter avec elle :

• Identifiant et titre du document source, pour permettre une citation exacte dans la réponse finale.
• Position hiérarchique — titre de section, sous-section, chemin dans la table des matières — pour restituer le contexte structurel sans réembarquer tout le document.
• Numéro de page ou de chunk et total de chunks du document, utile pour la stratégie de récupération dite « small-to-big » : on retrouve un petit chunk précis, puis on va chercher ses voisins immédiats pour élargir le contexte au moment de la génération.
• Date de publication ou de dernière mise à jour, indispensable pour filtrer ou pondérer les résultats quand plusieurs versions d'un même document coexistent dans l'index.
• Langue, si le corpus est multilingue, pour éviter de mélanger des résultats dans une langue que l'utilisateur ne maîtrise pas.
• Empreinte de contenu (hash), pour détecter et éliminer les doublons ou quasi-doublons avant indexation.
• Niveau de confidentialité ou droits d'accès (ACL), dans tout contexte multi-utilisateur où certains documents ne doivent pas être exposés à tous les demandeurs.

Sans identifiant de source fiable, impossible de citer correctement l'origine d'une réponse — le système génère une affirmation invérifiable pour l'utilisateur. Sans contrôle d'accès au niveau du chunk, un moteur de recherche RAG peut restituer, dans sa réponse, le contenu d'un document que l'utilisateur n'était pas censé pouvoir consulter. Ce n'est pas un détail cosmétique : c'est une faille de sécurité applicative construite dès la phase de préparation du corpus.

Nettoyage du corpus en amont

Le meilleur découpage appliqué à un corpus sale produit un index bruité. Le nettoyage précède logiquement le chunking, et mérite le même soin :

• Suppression du texte répétitif non informatif — en-têtes, pieds de page, menus de navigation, mentions légales répétées sur chaque page d'un site scrapé. Non retiré, ce texte se retrouve dupliqué dans des centaines de chunks et pollue les résultats.
• Normalisation de l'encodage — uniformiser en UTF-8, retirer les caractères de contrôle résiduels, corriger les problèmes classiques d'export (guillemets mal encodés, espaces insécables erratiques).
• Déduplication et quasi-déduplication — deux pages quasi identiques (version imprimable et version web d'un même contenu) doublent inutilement une information dans l'index. Des techniques de type shingling ou simhash détectent ces quasi-doublons au-delà de la correspondance exacte.
• Conversion structurée du HTML — retirer le balisage de mise en forme sans perdre la structure sémantique (titres, listes, tableaux), pour que le chunking structuré puisse s'appuyer dessus.
• Correction des artefacts d'OCR — sur des PDF scannés, erreurs de reconnaissance, sauts de ligne parasites ou colonnes mal réordonnées doivent être traités avant chunking, sous peine de découper un texte déjà corrompu.
• Traitement des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sensibles — selon la politique de l'organisation, les informations personnelles ou confidentielles doivent être identifiées et masquées avant indexation, pas après.

Aucune stratégie de chunking, aussi raffinée soit-elle, ne compense un corpus mal nettoyé en amont. Investir du temps dans cette étape réduit davantage le taux d'erreur final qu'optimiser finement la taille des chunks sur un corpus resté bruité.

Cas particuliers à traiter spécifiquement

Tableaux. Un découpage naïf peut trancher un tableau en deux chunks, séparant les données de leurs en-têtes. Deux approches courantes : répéter la ligne d'en-tête dans chaque chunk contenant une portion du tableau, ou sérialiser chaque ligne en phrase autonome (« Pour le produit X, le prix est Y et le stock est Z »).

Code source. Chunker par nombre de lignes fixe ignore la structure logique du programme et peut séparer une fonction de sa signature. Un découpage basé sur l'arbre syntaxique (AST), qui isole chaque fonction ou classe comme unité, préserve la cohérence sémantique.

PDF scannés. L'OCR doit être exécuté et validé — en vérifiant un score de confiance par page — avant tout chunking. Une extraction consciente de la mise en page (colonnes, notes de bas de page) évite de mélanger des blocs de texte sans rapport, simplement proches sur la page originale.

Transcriptions longues. Pour des réunions ou vidéos transcrites, découper par tour de parole ou segment temporel (horodatage conservé en métadonnée) préserve la continuité d'un raisonnement et permet de renvoyer l'utilisateur vers le passage exact de la source.

Checklist avant ingestion

• Le corpus a été nettoyé du texte répétitif non informatif et des artefacts d'extraction (HTML, OCR).
• La taille de chunk a été choisie en fonction du type de contenu, pas appliquée uniformément à un corpus hétérogène.
• Un overlap raisonnable (10 à 20 % de la taille du chunk) est configuré pour éviter les coupures sèches d'idées.
• Chaque chunk porte les métadonnées minimales : source, position, date, langue, hash.
• Les droits d'accès sont propagés au niveau du chunk si le corpus contient des documents à confidentialité différenciée.
• Les cas particuliers du corpus (tableaux, code, PDF scannés) ont une stratégie de découpage dédiée, pas le traitement par défaut.
• Un golden set de questions représentatives a été utilisé pour comparer au moins deux configurations de chunking avant de figer la configuration de production.
• La limite de contexte du modèle d'embedding utilisé a été vérifiée : un chunk trop long est tronqué silencieusement par de nombreux modèles, sans message d'erreur.

Pièges fréquents à éviter

• Couper au milieu d'un tableau ou d'une liste numérotée. Le fragment récupéré perd son sens sans les lignes ou éléments qui l'entourent.
• Configurer un overlap nul ou excessif. L'absence d'overlap fragmente les idées aux frontières ; un overlap trop généreux gonfle l'index et fait remonter des quasi-doublons dans les résultats de recherche.
• Appliquer un chunk_size unique à un corpus hétérogène. Des FAQ courtes et des contrats juridiques n'ont pas la même granularité optimale ; un paramétrage global uniforme dessert systématiquement l'un des deux types de contenu.
• Omettre les métadonnées de citation. Une réponse générée sans source vérifiable identifiable n'est pas exploitable en contexte professionnel, quelle que soit sa qualité rédactionnelle.
• Ne jamais tester sur des requêtes réelles. Une configuration de chunking qui « semble raisonnable » sur le papier peut se révéler inadaptée à la façon dont les utilisateurs formulent effectivement leurs questions ; seul un golden set le révèle.
• Ignorer la limite de tokens du modèle d'embedding. Un chunk dépassant cette limite est tronqué en silence par de nombreuses API d'embedding, ce qui revient à indexer un fragment incomplet sans qu'aucune alerte ne le signale.