Stratégies de découpage en chunks pour les systèmes RAG en production : taille fixe, sémantique et parent-enfant.

Supposons qu’un gestionnaire de sinistres dans une compagnie d’assurance demande à un assistant interne : quelles validations est nécessaire pour un sinistre de dommages causés par l’eau d’une valeur de 40 000 euros, et quels éléments doivent être vérifiés avant que le paiement ne puisse être effectué ? L’assistant s’appuie sur le manuel des sinistres en vigueur. Les fichiers ont été importés correctement, l’OCR a fonctionné, le prétraitement a éliminé les bruits, le modèle d’incorporation a identifié le bon manuel, et le réordonneur l’a placé en tête de liste.

Pourtant, la réponse reste incomplète.

Un expert en ajustement ne serait pas surpris. La règle n’est pas contenue dans un seul paragraphe. Une clause narrative indique que les demandes impliquant des dommages présumés antérieurs nécessitent une inspection indépendante avant le paiement. En dessous se trouve un tableau des autorisations. La page suivante présente un diagramme de flux montrant que le contrôle des fraudes et la vérification de la propriété doivent également être effectués en premier. Le système de documents ajoute l’identifiant du manuel, sa version ainsi que la région à laquelle il s’applique.

Pour celui qui gère ce processus, il ne s’agit pas de quatre faits distincts. Il s’agit d’une seule règle commerciale exprimée en quatre formats différents : le paragraphe définit la condition, le tableau indique qui peut approuver, le diagramme précise l’ordre des vérifications et les métadonnées indiquent quelle version est en vigueur.

Un séparateur standard réglé sur 500 tokens peut placer le paragraphe dans un bloc, la moitié supérieure du tableau dans un deuxième bloc, la ligne de tableau pertinente dans un troisième bloc et le texte extrait du diagramme dans un quatrième bloc. Chaque bloc est valide. Chaque appel d’incorporation réussit. Le tableau de bord reste vert. Pourtant, les connaissances ont été fondamentalement réorganisées. Au moment de la requête, le système doit relier le type d’affirmation à la tranche de quantité, l’associer à un responsable d’approbation, trouver les exigences d’inspection et récupérer les vérifications, tout cela à partir de fragments qui ne peuvent pas être lus seuls. Le modèle de langage reçoit des morceaux d’information et produit une réponse incomplète.

C’est pourquoi le débogage de RAG est trompeur. Les équipes changent de modèles d’incorporation, augmentent la valeur top-k, achètent un réordonneur plus puissant ou réécrivent le prompt. Parfois cela aide. Le plus souvent, cela compense les dommages causés lors de la segmentation. Une mauvaise qualité de RAG est fréquemment un problème de découpage masqué sous l’apparence d’un modèle de langage grand.

La plupart des discussions sur le chunking se réduisent à un seul chiffre : 256 tokens, 512 ou 1 000, avec le degré d’overlap. Ce sont des questions légitimes en matière d’implémentation, mais celle d’architecture est différente :

Qu’est-ce qui doit rester ensemble pour que le contenu conserve le même sens lorsqu’il est récupéré seul ?

Ce qui suit passe des stratégies les plus simples aux techniques apparues en 2024 et 2025, indique où chaque méthode justifie son coût, et se termine par une conception adaptée aux documents d’entreprise complexes.

La place du chunking dans le processus

Le chunking n’est pas une étape isolée de traitement de texte. C’est la frontière entre la compréhension de documents propres et la création de connaissances recherchables. Tout ce qui se trouve en amont détermine ce qui peut être divisé, et tout ce qui se trouve en aval dépend du fait que les fragments conservent suffisamment de sens, de structure et d’origine pour être retrouvés correctement.

Imaginez le chemin complet. Les sources telles que les PDF, les tableaux, les images, le JSON, les bases de données, les API et le code sont ingérées, analysées, nettoyées et normalisées. Ce n’est qu’alors qu’une couche de segmentation décide de la manière dont chaque type de contenu devient une unité de récupération. Les textes narratifs peuvent être divisés de manière structurée ou sémantique. Des règles détaillées conviennent bien aux représentations au niveau des propositions. Les tableaux nécessitent des limites en fonction de leur schéma. Le JSON doit suivre les objets métier. Les images exigent des descriptions visuelles renvoyant à l’original.

Ainsi, un système de production choisit rarement une seule taille de bloc pour tout. Un corpus peut contenir des représentations au niveau du document, de la section, du paragraphe, de la proposition et du token en même temps. Les paires de récupération parent-enfant utilisent de petits blocs pour assurer la précision et de plus grands blocs pour fournir le contexte, tandis que la segmentation tardive, la récupération contextuelle et RAPTOR permettent de reconstruire des informations qui seraient autrement perdues par une telle segmentation.

Le découpage en blocs ne s’arrête pas pour autant l’existence de vecteurs. Les métadonnées des blocs, les versions des documents, les liens parent-enfant, les contrôles d’accès et les références sources doivent survivre à l’indexation, à la récupération, au réclassement, à l’assemblage du contexte et à sa génération. L’évaluation clôt le cycle : les échecs de récupération, les contextes dupliqués, les citations incorrectes et les changements dans les modèles de requête doivent être pris en compte pour influencer les décisions de découpage. Le découpage en production concerne moins le fractionnement des documents que la conception des unités de récupération sur lesquelles tout le reste s’appuie.

L’équilibre fondamental

Prenons un extrait court d’une politique :

High-risk corporate customers must complete Enhanced Due Diligence.

Facilities above EUR 10 million require Group Credit Committee approval.

Fully cash-collateralised facilities may follow the exception defined in Section 7.4.3.

Conserver tout ensemble permet de préserver le contexte, mais produit un vecteur large et flou. Une segmentation agressive assure une récupération précise, cependant la règle d’approbation peut s’éloigner de la catégorie de clients à laquelle elle s’applique, et l’exception peut finir par être détachée de la règle qu’elle modifie.

Telle est toute la tension : de petits fragments améliorent la précision, de grands fragments préservent le contexte, et les systèmes en production nécessitent un équilibre délibéré. Chaque technique de segmentation représente une voie différente pour gérer ce compromis, et aucune ne dispense de bien connaître ses documents ainsi que les questions réellement posées par les utilisateurs.

Bases simples

Segmentation de taille fixe

La segmentation de taille fixe divise le texte en tronçons d’une longueur définie, généralement en tokens, avec une superposition optionnelle. Elle est simple, déterministe et peu coûteuse.

Compter les tokens est généralement préférable à compter les caractères, car les modèles d’embedding prennent en compte les tokens. Cinq cents caractères en allemand ou en chinois peuvent contenir bien moins d’unités significatives que la même quantité en anglais. La méthode encode le texte en tokens, les parcourt à intervalles réguliers et décode chaque fenêtre. L’overlap signifie que chaque fenêtre commence avant la fin de la précédente.

• Convient bien pour : un texte en prose uniforme, des benchmarks de référence, les cas où la simplicité d’utilisation est primordiale, ainsi que pour des prototypes initiaux nécessitant d’abord un pipeline fonctionnel.
• Féchit lorsque : le sens dépend de la structure. Une condition peut se terminer au token 499 tandis que son exception commence au token 501, et la frontière ne tient pas compte de la logique métier.

Quel est l’effet de l’overlap

La superposition constitue une assurance contre les défaillances aux frontières. Sans elle, une phrase peut être divisée en deux parties, et aucune des deux ne reste cohérente à elle seule. Avec elle, chaque partie conserve une partie de celle qui lui est voisine, ce qui permet à toutes deux de rester interprétables.

Le prix à payer est réel : plus de vecteurs, des coûts d’encodage plus élevés, plus d’espace de stockage et des listes de résultats encombrées de passages presque identiques. Un pourcentage de vingt pour cent relève d’une habitude et non d’une règle absolue ; il convient donc de le considérer comme un paramètre à comparer avec les métriques de récupération.

La segmentation à taille fixe trouve sa place non pas parce qu’elle est optimale, mais parce qu’elle offre une référence stable. Si une méthode plus sophistiquée ne parvient pas à la surpasser de manière mesurable sur votre corpus, la complexité supplémentaire n’est pas justifiée.

Division récursive

Les documents d’entreprise encodent déjà des limites utiles dans les titres, sections, paragraphes, phrases et listes. La séparation récursive utilise ces éléments avant de recourir à des points de coupure arbitraires. Le séparateur de caractères récursif de LangChain, par exemple, tente d’abord des double sauts de ligne, qui marquent généralement les paragraphes. Si un fragment reste trop grand, il essaie des sauts de ligne simples, puis la ponctuation des phrases, ensuite les espaces, et enfin les caractères individuels. La limite de taille constitue le seuil qui déclenche chacun de ces recours.

L’ordre des séparateurs est plus important que la valeur de la taille. Pour les politiques, procédures, manuels et documents techniques bien organisés, ceci constitue souvent un paramètre par défaut très efficace.

Un conseil de production : si l’algorithme d’extraction a déjà déterminé la hiérarchie, ne l’ignorez pas et n’exigez pas d’un outil de segmentation qu’il la redécouvre. Une section numérotée 7.4 au sein d’un chapitre consacré aux prêts indique déjà quels textes doivent être regroupés. Conservez cette structure dans les métadonnées et utilisez-la pour guider les opérations de segmentation. En d’autres termes, ne détruisez pas la structure lors du découpage, puis n’essayez pas de la reconstruire lors de la récupération des données.

La segmentation récursive part du principe que la structure suit approximativement le sens, ce qui n’est pas toujours le cas. Un paragraphe peut contenir trois règles sans rapport entre elles, et cinq paragraphes peuvent décrire un seul processus. C’est là que les méthodes basées sur le sens entrent en jeu.

Unités de phrase et de paragraphe

Des outils tels que spaCy et NLTK proposent des détecteurs de phrases entraînés qui permettent de gérer les cas où une segmentation naïve par points-virgules entraîne des problèmes avec les abréviations, les décimales, les titres et les points d’ellipses. La segmentation en paragraphes est plus simple et souvent efficace, car un paragraphe représente un regroupement choisi intentionnellement par l’auteur. Pour des documents propres, diviser le texte en paragraphes et fusionner les voisins courts jusqu’à atteindre une taille minimale constitue un compromis raisonnable entre les approches à taille fixe et celles basées sur le sens.

Le inconvénient réside dans la taille variable des blocs. Certains paragraphes contiennent 50 tokens tandis que d’autres en ont 800, ce qui complique le regroupement en lots, augmente la latence lors de l’encodage et rend plus difficile la prédiction de la taille de l’index. Le fait que ces limites améliorées en valent la peine dépend du corpus utilisé.

Les fenêtres glissantes en tant qu’outil de rappel

Une fenêtre glissante est une méthode de segmentation à taille fixe où l’overlap est considéré comme un mécanisme de récupération et non simplement comme une garantie de délimitation. Le raisonnement est le suivant : un vecteur de requête correspond le mieux au passage qui y répond directement. Si ce passage se situe à la frontière entre deux segments, aucun des deux morceaux ne pourra obtenir un bon score. Avec un overlap suffisant, chaque passage de longueur raisonnable apparaît entier dans au moins un segment.

Un overlap plus élevé améliore le taux de rappel au détriment de la redondance. Au-delà d’environ 30 à 40 pour cent, les listes top-k se remplissent de doublons presque identiques qui consomment des ressources sans ajouter de nouvelles informations ; 10 à 25 pour cent conviennent le mieux à la plupart des corpus. Évaluez l’overlap en mesurant le taux de récupération de doublons en même temps que le Recall@k, car augmenter le Recall@5 tout en doublant le nombre de doublons n’améliore pas nécessairement la qualité des réponses.

Stratégies tenant compte du sens

Segmentation sémantique

Le chunking sémantique remplace la règle de comptage des tokens par une question : le sujet a-t-il suffisamment changé pour justifier l’ouverture d’une nouvelle unité ? Imaginez une section dont les deux premières phrases traitent des exigences d’inspection, la troisième aborde les limites de paiement et la quatrième cite les règles relatives à la fraude. Un séparateur fixe ne peut pas détecter ces changements de sujet, tandis qu’un chunker sémantique bien calibré le peut.

La méthode habituelle comporte trois étapes. D’abord, diviser le texte en phrases à l’aide d’un modèle linguistique. Ensuite, intégrer chaque phrase, ou une petite fenêtre de phrases adjacentes, à l’aide d’un sentence-transformer. Enfin, calculer la distance cosinus entre les embeddings voisins et placer une frontière là où cette distance dépasse un seuil défini en pourcentage, généralement entre le 85e et le 95e percentile des distances présentes dans ce document.

Cette limite constitue la valeur critique. Si elle est trop élevée, les idées associées se fragmentent en petits morceaux sans signification. Si elle est trop basse, les sujets distincts restent mélangés, réintroduisant le bruit que l’on voulait éliminer.

Cela entraîne également des coûts plus élevés, car une étape complète d’incorporation doit avoir lieu avant que les limites ne soient connues. Pour des documents courts et bien structurés, ce coût n’apporte que peu d’avantages. Pour des textes longs et au format incohérent, identifier de véritables changements de sujet peut améliorer considérablement la récupération des informations. Une limite importante : la méthode suppose que les sujets changent progressivement et de manière détectable d’une phrase à l’autre. Dans un texte juridique ou réglementaire dense, où une seule phrase peut contenir trois conditions et deux exceptions, les distances au niveau des phrases génèrent des signaux bruyants.

Fragmentation parent-enfant

Ce modèle fait partie des plus influents dans les systèmes RAG en production, car il résout une tension que l’approche par unité individuelle ignore : la meilleure unité pour la récupération n’est pas nécessairement la meilleure unité pour la génération.

Prenons une section de 2 000 tokens couvrant les limites, les exceptions, les contrôles et l’escalade. L’enregistrement de cette section dans son intégralité conserve le contexte, mais génère un vecteur flou. La division en fragments de 200 tokens améliore la précision de la récupération, mais le fragment correspondant peut manquer des éléments nécessaires au modèle pour raisonner correctement.

La segmentation en blocs parent-enfant sépare ces deux tâches. Un bloc parent est une section plus large et cohérente, comme toute une proposition, une procédure ou un sous-section. Les blocs enfants sont des fragments plus petits et ciblés dérivés de celui-ci : des conditions, des seuils ou des exceptions isolées. Seuls les blocs enfants sont enregistrés et recherchés. Lorsqu’un bloc enfant correspond, son identifiant de parent permet de récupérer le texte source plus long, qui est ce que le modèle lit réellement.

LlamaIndex et LangChain proposent des versions de cette approche via des nœuds hiérarchiques, une récupération allant du petit au grand échelle ainsi que la récupération des documents parents. Chaque enfant stocke un ID de parent dans ses métadonnées, et une recherche ultérieure étend les résultats aux documents parents avant l’assemblage du contexte.

Dans des environnements réglementés, les identifiants nécessitent une traçabilité précise. Un ID lisible qui combine le document, sa version et sa section est plus fiable qu’un UUID arbitraire, car un enfant provenant de la version 7.2 qui fait référence à un parent de la version 7.1 génère un contexte qui semble plausible mais est en réalité incorrect sur le plan opérationnel. Ce schéma fonctionne également pour différentes modalités : un enfant peut être une ligne de tableau serialisée, une description visuelle d’un diagramme ou une proposition, tous partageant un parent représentant une section logique.

Découpage en propositions

Prenons une phrase comme celle-ci tirée d’une politique de crédit : les emprunteurs corporatifs à risque nécessitent une diligence renforcée ainsi qu’un examen annuel, et un comité doit donner son accord chaque fois que leur exposition dépasse une limite fixée. Elle contient trois faits distincts. Un système de recherche répondant à la question de savoir avec quelle fréquence de tels clients sont examinés ne devrait pas avoir à examiner les critères d’approbation pour trouver une correspondance.

La proposition de segmentation divise le texte en énoncés atomiques et autonomes, chacun pouvant être récupéré séparément. L’extraction s’effectue généralement au moment de l’indexation par un modèle linguistique à l’aide d’une instruction soigneusement structurée, qui conserve toutes les conditions, seuils, qualificatifs et exceptions, résout les pronoms lorsque le texte le permet et n’infère rien qui n’est pas explicitement mentionné. Pour la phrase ci-dessus, le résultat pourrait être trois énoncés : de tels clients nécessitent une diligence raisonnable, exigent un examen annuel, et dépassant le seuil d’exposition, nécessitent l’approbation d’un comité.

Chaque proposition dispose de son propre embedding, ce qui fait du espace vectoriel un espace de faits atomiques et non de passages, ce qui améliore la précision pour des questions ciblées visant à obtenir des faits. Deux contraintes de production s’appliquent :

• La proposition n’est pas la source de vérité. Il s’agit d’une représentation générée par un modèle. Dans les travaux réglementés, il faut d’abord récupérer l’information via la proposition, puis revenir au texte officiel pour obtenir des références fiables, effectuer des raisonnements et citer correctement. La proposition est une entrée d’index et non une affirmation.
• Le coût augmente fortement. Un document de 10 000 tokens peut générer des centaines de propositions, chacune nécessitant une requête d’incorporation, ce qui fait que l’index grandit rapidement.

Récupérer le contexte perdu

Chunking tardif

Le chunking conventionnel divise d’abord le texte et incorpore chaque partie séparément. Le chunking tardif, introduit par Jina AI en 2024, inverse partiellement cet ordre.

La méthode de segmentation tardive commence par faire passer l’ensemble du document à travers un modèle d’incorporation de contexte étendu afin d’obtenir des représentations au niveau des tokens, en tenant compte du contexte. Les limites des segments sont ensuite définies, en regroupant les vecteurs de tokens situés à l’intérieur de chaque fenêtre. La différence par rapport à l’utilisation de segments plus grands réside dans le fait que l’unité de récupération reste petite. Le passage reste ciblé, mais son vecteur reflète le contexte dans lequel il est apparu. Les pronoms, les abréviations, les références directes et les termes définis précédemment sont intégrés dans l’incorporation, sans être laissés au modèle au moment de la génération.

Le coût de l’infrastructure est réel. Il faut un modèle d’incorporation à long contexte qui fournisse des résultats au niveau des tokens, de la mémoire d’indexation supplémentaire ainsi que du code de pooling minutieux. De plus, il ne peut pas corriger une mauvaise segmentation : un tableau mal sérialisé ou un diagramme ajouté lors du prétraitement reste introuvable. Ce qu’il résout, c’est la perte de contexte au moment de l’incorporation, et rien en amont. Pour des corpus présentant des dépendances étroites entre phrases, tels que les réglementations, les contrats et les manuels, l’amélioration de la qualité d’incorporation peut être significative.

Récupération contextuelle

La technique de récupération contextuelle d’Anthropic, publiée en 2024, aborde ce même problème d’isolement de manière différente. Elle ne modifie pas l’architecture d’incorporation ; elle enrichit plutôt le texte de récupération de chaque fragment au moment de l’indexation.

Une phrase isolée indiquant une limite peut ne pas correspondre à une requête mentionnant la catégorie du client, la juridiction et l’autorité d’approbation, car ces termes se trouvent dans le document environnant. Ainsi, avant l’indexation, une brève description contextuelle spécifique au document est générée pour chaque partie du texte, indiquant par exemple quelle section de quelle version de la politique provient le passage et ce qu’il définit. Cette description est placée en tête, et la combinaison est intégrée dans l’index.

D’après l’évaluation d’Anthropic, la combinaison des embeddings contextuels avec le système BM25 contextuel a réduit les échecs de récupération dans le top 20 de 49 %, tandis que l’ajout d’un réclassement a encore diminué ces échecs de 67 %. Ces chiffres proviennent des propres corpus d’Anthropic et ne constituent pas de garanties. Les gains réels dépendent de vos documents, de vos requêtes, du modèle d’embedding et de la configuration de récupération. La leçon n’est pas dans ces chiffres, mais plutôt dans le fait qu’ajouter un contexte spécifique au document aux fragments isolés peut être d’une grande aide lorsque le sens important se trouve en dehors des limites de ce fragment.

Cela est particulièrement utile pour les fragments ambigus : lignes de tableau isolées, légendes d’images, mentions de termes définis ainsi que des segments dont le champ sémantique provenait d’une section parente qu’ils ne contiennent plus. Il s’accorde également naturellement avec la récupération de type parent-enfant. Une règle s’impose : le contexte généré sert d’aide à la récupération et non de source fiable. Si l’on attribue à chaque segment la même description générique, les vecteurs deviennent trop similaires, ce qui nuit à la récupération. Une bonne contextualisation n’ajoute que ce dont un segment a besoin pour être compris indépendamment de ses voisins.

RAPTOR : plusieurs niveaux d’abstraction

RAPTOR, abréviation de Recursive Abstractive Processing for Tree-Organized Retrieval, vise un problème commun aux systèmes de recherche à un seul niveau : les fragments détaillés répondent bien aux questions factuelles précises mais ont du mal avec celles qui exigent une synthèse à partir de plusieurs sections. Comparez la question de savoir qui approuve une affirmation particulière avec celle demandant l’ensemble du cadre de contrôle de l’organisation pour ce type d’affirmation. La première a une réponse autorisée dans un tableau, tandis que la seconde nécessite des preuves provenant de règles d’inspection, d’autorités déléguées, de politiques de secours ou de récupération, de procédures d’examen et de voies d’escalade, probablement à travers plusieurs sections et documents.

RAPTOR crée une hiérarchie. Les fragments sources forment la couche inférieure. Les fragments liés sont regroupés en fonction de leur similarité d’incorporation, et un modèle de langue résume chaque groupe. Ces résumés sont à leur tour regroupés et résumés à nouveau, ce processus se répétant jusqu’à ce que quelques résumés de haut niveau représentent l’ensemble du document ou du corpus. Lors d’une requête, une question précise peut correspondre à un fragment de base, tandis qu’une question plus générale correspond à un résumé de haut niveau ; ainsi, un seul système peut gérer les deux sans modification architecturale.

La principale préoccupation en matière de production est l’origine des données. Les résumés sont des interprétations, et ces interprétations peuvent déformer les seuils, les cas limites et les exceptions, c’est-à-dire les détails qui comptent le plus dans un travail réglementé. Utilisez des nœuds de niveau supérieur pour trouver les parties pertinentes du corpus, puis revenez aux passages originaux avant de générer le contenu. Le résumé aide à localiser les preuves, tandis que c’est le texte original sur lequel le modèle fonde ses raisonnements. RAPTOR justifie son coût pour les politiques longues, les cadres réglementaires et les manuels volumineux où les utilisateurs posent à la fois des questions détaillées et des demandes de synthèse dans une même application. Pour de courtes collections ou des types de requêtes uniformes, la complexité ne rapporte que rarement ses frais.

Contenu structuré et non textuel

Tables : la structure, c’est le sens

Retournez à la table des autorités. Elle contient des relations explicites : type de réclamation lié à des dommages causés par l’eau, fourchette de montant supérieure à 25 000 euros, personne chargée de l’approbation étant le gestionnaire régional des réclamations. Si l’on transforme cela en une séquence de mots, les relations entre colonnes qui donnent un sens à chaque valeur disparaissent ; c’est pourquoi les tables nécessitent un traitement adapté.

Avec de petites tables, il est souvent préférable de conserver leur intégrité, surtout lorsque les requêtes comparent des lignes ou nécessitent l’ensemble des conditions. Il faut donc formater le tableau de manière à ce que les liens entre colonnes et lignes soient préservés, par exemple en transformant chaque ligne en paires étiquette-valeur désignant chaque colonne. Avec de grandes tables, les lignes permettent de diviser le contenu en parties plus précises, mais chaque ligne doit inclure ses en-têtes, car trois valeurs seules sans étiquettes n’ont aucun sens.

Une décision plus importante se cache derrière la sérialisation. Si les utilisateurs posent des questions déterministes, comme lister tous les approuveurs pour des montants supérieurs à un certain seuil, la recherche vectorielle peut être complètement inadaptée. Les tables consultées via SQL ou un dataframe surpassent toute approche d’embedding pour les recherches à filtre exact. Le principe : ne détruisez pas une structure explicite juste pour que tout ressemble à du texte.

JSON et enregistrements structurés

Le même raisonnement s’applique au JSON. Un enregistrement contenant des champs tels que segment, rating, région, montant, approuvé et un drapeau de commentaire indique déjà quels champs doivent être regroupés, de sorte que l’application d’un séparateur de tokens sur du JSON serialisé ignore ce fait. Les petits enregistrements devraient rester intacts, avec un formulaire de récupération lisible qui affiche chaque champ accompagné de son étiquette. Pour les gros ensembles de données, il convient de repérer des entités commerciales naturelles telles que les clients, les comptes, les transactions, les événements de filtrage ou les décisions relatives aux dossiers, et de diviser le contenu en blocs autour de celles-ci.

Dans un enregistrement, il faut séparer les champs sémantiques de ceux qui peuvent être filtrés. Les champs auxquels se réfèrent les questions en langage naturel doivent faire partie de l’embedding. Des champs tels que la région, la version, l’unité commerciale et la date d’effet fonctionnent généralement mieux en tant que filtres de métadonnées dans l’index qu’en tant que partie du vecteur. Le pré-filtrage sur les métadonnées est plus rapide et plus précis pour les limites catégorielles, et il permet à l’embedding de conserver son sens initial.

Code : la syntaxe définit les limites

Le code pose le même problème dans un autre domaine. Un séparateur générique qui divise un fichier Python au token 500 peut couper une fonction de sa directive return ou une classe de ses méthodes. Pour la recherche de code, les limites doivent suivre la syntaxe : fonctions, méthodes, classes et modules. Le module ast de Python peut analyser le code source pour en créer un arbre et extraire chaque fonction, fonction asynchrone et classe en tant qu’unité complète, de sorte que les fragments respectent la sémantique du langage plutôt que d’être approximés par le nombre de caractères. Pour les dépôts écrits dans de nombreux langages, tree-sitter propose une seule interface d’analyse couvrant des dizaines de langages et gère les cas limites que les expressions régulières manquent. La relation parent-enfant s’applique naturellement : on récupère précisément une méthode, puis on l’étend à sa classe ou à son fichier lorsque le modèle a besoin d’un contexte plus large.

Diagrammes et images

Ne considérez pas le texte OCR comme une représentation complète d’une image. Un diagramme de flux transmet du sens grâce aux flèches, à la séquence, aux branches, au regroupement et à l’agencement spatial, éléments que l’OCR ne parvient pas à capturer. Utilisez un modèle capable de comprendre l’image pour rédiger une description permettant de déterminer ce que l’image communique, et non seulement quels mots y apparaissent. Stockez un pointeur vers l’original. La description générée constitue la fiche d’index, tandis que l’image source est ce que le système affiche comme preuve. Dans les systèmes réglementés, la citation doit faire référence à l’image originale et non à sa description.

Affectation selon le type de contenu

Les documents réels sont complexes. Un seul manuel peut contenir des règles narratives, un tableau d’autorité, un diagramme de processus, des métadonnées JSON et des références intégrées. Il n’y a aucune raison valable d’appliquer le même outil de séparation à tous ces éléments, car chacun a une signification différente : un paragraphe grâce à la continuité linguistique, un tableau via les intersections des lignes et des colonnes, un diagramme en fonction de la position, de la direction et du regroupement, et JSON grâce à des clés explicites.

La solution de production consiste en un routage par segmentation, un dispositif d’affectation qui identifie le type de contenu de chaque bloc extrait et l’envoie à la stratégie appropriée. Ce routage n’a pas besoin d’être sophistiqué ; sa valeur réside dans le fait qu’il fait du routage basé sur le type de contenu un choix de conception explicite, et non le résultat fortuit de l’application d’un séparateur générique. Pour le manuel des revendications, le texte narratif serait traité par une segmentation structurelle ou sémantique, la table des autorités par une sérialisation tenant compte des tables, le diagramme de flux par un modèle visuel pour sa description, et les métadonnées JSON par une séparation tenant compte des objets.

Chaque fragment résultant doit contenir les mêmes métadonnées de base, telles que l’ID du document, la version, l’ID du parent, la section et la région. Cette filiation commune permet aux étapes ultérieures de reconnaître qu’une ligne de tableau, un paragraphe et une description de diagramme constituent des éléments liés provenant d’une même section.

Lorsque les unités plus grandes l’emportent

Une grande partie de l’évolution décrite ci-dessus vise une plus grande granularité, ce qui peut donner l’impression fausse que plus c’est petit, mieux c’est. La recherche sur LongRAG a exploré la direction opposée, en testant si des unités de récupération beaucoup plus grandes, atteignant dans certains essais jusqu’à environ 4 000 tokens, pouvaient surpasser la récupération à haute granularité pour des questions complexes nécessitant plusieurs étapes. Il n’a pas été démontré que de gros blocs soient universellement supérieurs ; il a plutôt été constaté que la granularité de la récupération devrait correspondre à celle de la requête.

Une question portant sur la fréquence à laquelle un type de compte doit être révisé nécessite une réponse de taille similaire à celle d’une proposition. Demander le cadre complet de contrôle pour un type de prétention exige des éléments provenant de plusieurs domaines, et la récupération à haute granularité peut obliger le système à assembler une réponse globale à partir de nombreux fragments isolés, ce qui entraîne des erreurs d’assemblage même lorsque chaque fragment est correct.

Sélectionner et mesurer

Comment choisir une stratégie

Aucune stratégie de segmentation n’est optimale partout. Le choix dépend de la structure du document, des types réels de requêtes, du budget de latence, de la tolérance aux coûts d’indexation et de la conception de la génération ultérieure. Le type de requête est tout aussi important que le type de document. La même politique peut servir à des recherches ciblées portant sur une fréquence minimale de révision ainsi que des demandes plus larges visant à expliquer un cadre complet, et ces deux cas exigent une granularité de récupération différente. Si vos données d’évaluation ne couvrent qu’un seul type, la stratégie gagnante pourrait performer moins bien en conditions réelles.

Un guide approximatif :

• Prose uniforme, prototype précoce : taille fixe avec un chevauchement modéré.
• Manuels et procédures bien structurés : segmentation récursive ou basée sur la structure, avec la hiérarchie conservée dans les métadonnées.
• Récit long avec un formatage incohérent : segmentation sémantique, si le coût supplémentaire entraîne un gain mesurable.

Questions qui nécessitent à la fois précision et contexte : relation parent-enfant.

Énoncés de règles complexes et requêtes factuelles restreintes : propositions avec conservation du contexte parent.

Champs qui perdent leur sens lorsqu’isolés : récupération contextuelle ou segmentation tardive.

Types de requêtes mixtes sur de longs documents : méthodes hiérarchiques telles que RAPTOR.

Tables, JSON, code et diagrammes : traitement spécifique au type via un routeur.

Benchmarks plutôt que des suppositions

Jeter un coup d’œil à quelques champs et en déduire qu’ils semblent raisonnables aide au débogage, mais ce n’est pas une évaluation. La vraie question est de savoir si une stratégie permet au système de récupérer les éléments nécessaires pour répondre aux requêtes réellement envoyées par les utilisateurs.

Créez un ensemble d’évaluation couvrant différents besoins : une information précise liée à une seule ligne de tableau, une question nécessitant plusieurs éléments de preuve ainsi qu’une clause narrative et une description du processus, une question conditionnelle portant sur une exception, ainsi qu’une question de synthèse reliant plusieurs sections. Associez à chaque requête les identifiants des unités de récupération qui doivent être trouvées.

Les métriques de récupération ne suffisent pas seules. Enregistrez la taille de l’index par rapport à une référence de taille fixe, le coût d’encodage par document, les délais d’indexation et de récupération, le nombre de tokens contextuels par requête, le taux de doublons, la justesse des réponses et celle des citations. Trois points supplémentaires en Recall@5 ne valent pas grand-chose si l’index quadruple et que les résultats se remplissent de copies quasi identiques.

Dans un corpus de politiques typique, un schéma plausible est que la segmentation récursive surpasse celle à taille fixe de quelques points pour un coût d’indexation égal, le chunking sémantique ajoute un peu plus à un coût supplémentaire modeste, la structure parent-enfant améliore encore le taux de rappel avec une augmentation notable de l’index, tandis que les propositions associées à leurs parents atteignent le taux de rappel le plus élevé, mais à un coût et une complexité bien plus importants. La récupération contextuelle peut atteindre ce même taux de rappel avec une croissance moindre de l’index, ce qui justifie son utilisation lors de l’indexation, et RAPTOR peut être inférieur à la structure parent-enfant pour les faits simples, mais gagner en matière de synthèse. Considérez cela comme une illustration de la nature des compromis et non comme un résultat mesuré. Le point de fonctionnement optimal dépend des exigences en termes de précision, des limites de latence, du budget d’indexation et du fait de savoir si chaque amélioration justifie sa complexité.

Ne vous concentrez pas uniquement sur l’optimisation de la récupération

Supposons que un chevauchement important améliore le Recall@5, mais que les cinq meilleurs résultats contiennent désormais quatre passages presque identiques provenant d’une même clause, ce qui écarte une autre section pertinente du budget de contexte. Une métrique s’améliore tandis que la qualité du système diminue. Il convient d’évaluer l’ensemble du processus, de la récupération à la réclassification, en passant par l’assemblage du contexte et la génération, en se demandant à chaque étape si les preuves nécessaires ont survécu, si les doublons consomment de l’espace utile, si la réponse est correcte et fondée, ainsi que si la citation renvoie à la source et à la version appropriées.

Dans les systèmes réglementés, la justesse des citations n’est pas une simple question de confort. Une réponse peut être factuellement correcte tout en étant basée sur la mauvaise version d’une politique. Cela constitue néanmoins une faille de conformité, qui reste invisible à moins que l’origine des citations ne soit testée explicitement.

Une architecture de production

Le changement fondamental dans la façon de penser est qu’un pipeline d’entreprise mature ne souhaite presque jamais disposer d’un seul outil de segmentation universel. Il exige une couche de routage qui envoie chaque bloc de contenu vers la stratégie appropriée, conserve des métadonnées relatives à l’historique commun de tous les fragments générés, et maintient des liens explicites vers la source officielle.

Pour le manuel des demandes, une configuration plausible consiste en ce qui suit : les sections narratives sont divisées de manière structurale ou sémantique ; les clauses de règles complexes deviennent des propositions tout en conservant leur élément parent ; les petites tables sont transmises dans leur intégralité ; les grandes tables sont découpées en blocs de lignes prenant en compte les en-têtes ; les diagrammes reçoivent des descriptions basées sur des modèles de vision ; et les enregistrements JSON sont séparés par des objets. Chaque bloc, quel que soit son type, porte les mêmes identifiants : ID du document, version, ID de l’élément parent, section, région et référence à l’artefact source. Cette filiation commune est tout aussi importante que les blocs eux-mêmes, car elle permet de relier à nouveau une ligne de tableau, une clause et une description de processus en tant qu’éléments provenant d’une section d’une version donnée.

Retour à la demande de dédommagement pour dommages causés par l’eau

La question n’a jamais été de savoir si 500 ou 800 tokens était la taille appropriée. La source contenait différents types de preuves : le paragraphe indiquait qu’une inspection indépendante était nécessaire, le tableau précisait qui approuvait les plages de quantité, le diagramme décrivait les contrôles avant paiement, et les métadonnées indiquaient quelle version et quelle région s’appliquaient.

Une couche de segmentation bien conçue conserve chaque élément dans sa structure d’origine tout en enregistrant qu’ils partagent une même section. Cela permet des options lors de la récupération : les questions relatives à l’approbation affichent la ligne du tableau, celles concernant l’inspection affichent la clause correspondante, les questions relatives au processus affichent la description du diagramme, et les questions complexes récupèrent plusieurs éléments associés pour les afficher sous leur parent commun. C’est là la différence entre simplement diviser le texte et concevoir des unités de récupération adaptées.

L’ordre de priorité n’est pas fixe : on ne part pas d’une logique sémantique puis propositionnelle où l’idée la plus récente l’emporterait. Plutôt : apprendre la source, comprendre les requêtes, conserver la structure existante, choisir le degré de granularité de la récupération, restaurer le contexte manquant, préserver l’origine des données, évaluer la qualité de la récupération et des réponses, et n’ajouter de complexité que là où elle est vraiment nécessaire.

Une dernière liste de vérification avant l’indexation

Avant que les fragments n’arrivent dans le pipeline d’incorporation, chacun doit répondre à trois critères :

• Récupérable. Suffisamment spécifique pour correspondre aux requêtes pertinentes, sans être trop large au point de correspondre de manière vague à tout.
• Interprétable. Contenant suffisamment de contexte pour conserver son sens par lui-même, ou disposant d’un moyen fiable pour récupérer ce contexte via une recherche dans un élément parent.

Traçable. Référence à la source autorisée : le document exact, sa version, sa section, sa page, son tableau, son image ou le enregistrement d’où il a été extrait.

Lorsque l’un de ces éléments fait défaut, la couche de segmentation transmet ses problèmes aux étapes de récupération, de réclassement, d’assemblage du contexte et de génération. Un stockage vectoriel indexera volontiers une unité de mauvaise qualité, une API d’embedding renverra un vecteur sans se plaindre et un modèle pourra y ajouter une réponse affirmative, sans que rien ne révèle que la représentation est incorrecte. Corriger une unité défectueuse reste le moyen le moins coûteux avant qu’elle ne devienne un embedding.

Au préalable de la mise en production, planifiez également le journalisation, la gestion des secrets et des configurations, l’attribution d’ID déterministes, la versionning des modèles et des prompts, le suivi de l’origine des blocs, les contrôles d’accès, les ensembles de données d’évaluation, la gestion du cycle de vie des index ainsi que le suivi de la qualité de récupération, de la latence et des coûts.