Chapitre 3 — Frameworks avancés de découpage

Troisième billet de la tournée chapitre par chapitre de LLM Primer III : Améliorer l'IA d'entreprise avec RAG. Là où des choix naïfs dégradent le plus silencieusement tout ce qui suit — et là où deux techniques récentes ont changé ce qu'on peut faire à la frontière.

Pourquoi ce chapitre existe

Une fois les documents analysés, la décision suivante est aussi la plus lourde de conséquences : comment les casser en morceaux assez petits pour être embarqués et assez grands pour vouloir encore dire quelque chose tout seuls. C'est le découpage. Un morceau qui sépare une définition de sa précision sera retrouvé avec confiance et sera faux. Un morceau qui empile cinq sujets sans lien dilue chaque embedding qu'il touche. Le système de recherche que vous construisez par-dessus ne peut récupérer que ce que l'étape de découpage a préservé, et les modes d'échec sont silencieux ici — le retrieveur renvoie quand même des candidats, le modèle produit quand même des réponses fluides, et seul l'utilisateur remarque que les réponses sont subtilement fausses.

3.1 Le spectre du découpage

Il est utile de classer les stratégies par ce qu'elles savent du document. À une extrémité, le découpage à taille fixe ne sait rien — compter les tokens, couper. Rapide, déterministe, et acceptable pour du texte court stylistiquement uniforme (transcriptions de chat, entrées de FAQ, avis clients). Sur des documents techniques structurés, c'est un désastre silencieux. Le découpage récursif applique une liste de séparateurs prioritaires — paragraphes, puis sauts de ligne, puis phrases, puis mots — en coupant sur la limite la plus prioritaire qui tient sous la taille cible. Presque aussi peu cher que le taille fixe et nettement meilleur. C'est le bon défaut pour la plupart des équipes.

Le découpage sémantique déplace la décision de la syntaxe vers le sens : embarquer chaque phrase, parcourir la séquence, marquer les frontières de sujet là où la similarité entre phrases adjacentes tombe sous un seuil. Cela fonctionne bien sur la prose de longue haleine où les indices structurels sont faibles (rapports d'analystes, transcriptions d'entretien) et mal sur des documents techniques structurés où les références croisées denses et le boilerplate répété trompent les embeddings de phrases. Le découpage structurel traite le document analysé comme un arbre et le découpe le long de cet arbre — par section, par niveau de titre, par fonction de code. Bien fait, c'est la forme la plus fidèle de découpage ; fait sans un parseur sensible à la mise en page en amont, il ne produit rien de différent du récursif, parce que la structure n'a jamais été extraite. Ces quatre sont des alternatives, pas une pile à déployer ensemble.

3.2 Le mythe du recouvrement et la falaise de contexte

Presque tous les tutoriels recommandent un recouvrement de morceaux de 15–20 %. L'intuition est correcte jusqu'à un point — le recouvrement prévient les pertes aux frontières — mais la courbe s'aplatit vite. Les premiers 10 % récupèrent l'essentiel du bénéfice. Au-delà d'environ 25 %, la précision est essentiellement plate alors que le coût grimpe sur trois axes : la facture d'embedding croît linéairement avec le nombre de morceaux, la taille d'index et la latence de requête augmentent, et les premiers résultats du retrieveur commencent à être quasi-doublons les uns des autres. Une requête utilisateur matche un passage dans les morceaux A, B et C ; la fenêtre de contexte est consommée sans nouvelle information ; le reranker dépense son budget à réordonner des variantes du même contenu. Une équipe qui tire vers 30–40 % de recouvrement devrait traiter cela comme le signal que le découpage est faux, pas que le recouvrement est trop bas.

Liée mais distincte, la falaise de contexte : la chute brutale de qualité de recherche quand un morceau perd les termes d'ancrage qui le rendaient retrouvable. Un paragraphe qui s'ouvre par « L'amendement de 2023 à la Politique 47-B exigeait que toutes les agences… » puis décrit l'exigence dans les phrases suivantes. Coupez après l'ouverture, et le morceau qui décrit l'exigence ne mentionne plus la politique, ni l'amendement, ni l'année. Il sera retrouvé avec confiance pour des requêtes sans rapport et raté pour les requêtes canoniques. La recherche est top-k — soit le morceau remonte, soit il ne remonte pas, sans dégradation gracieuse. La falaise est le mode d'échec dominant dans les corpus techniques, où pronoms et formes abrégées portent l'antécédent le long d'une section.

3.3 Accorder la taille de morceau au type de requête

On débat souvent de la taille de morceau comme s'il y avait une bonne réponse unique. Il n'y en a pas, parce que la bonne réponse dépend des requêtes que le système recevra. Une requête factuelle — « quelle était la franchise sur la police 47-B en 2024 ? » — veut 150–300 tokens, assez étroit pour être précis, assez large pour désambiguïser. Une requête de raisonnement — « résume les changements entre les versions 2023 et 2024, et explique comment ils affectent le renouvellement » — veut 800–1 200 tokens pour préserver le tissu conjonctif d'une section. La taille optimale diffère d'un facteur 4 à 8 entre les deux, et le trafic de production est généralement un mélange.

Deux réponses productives. L'indexation multi-granularité stocke le même corpus à plusieurs tailles de morceaux et route les requêtes par classification d'intention. La recherche hiérarchique indexe de petits morceaux pour la précision mais renvoie leurs sections parentes pour le contexte — un seul index, conditionné au moment de la requête, plus courant en production parce qu'il dégrade gracieusement quand la classification d'intention se trompe. Le patron document-parent est l'une des techniques de plus grande valeur dans la littérature de recherche en production.

3.4 Recherche contextuelle et découpage tardif

La frontière est la reconnaissance que le morceau et l'embedding sont des préoccupations séparables. Deux techniques récentes exploitent cette séparation dans des directions opposées. La recherche contextuelle, popularisée par Anthropic en 2024, envoie chaque morceau plus le document complet à un LLM bon marché et lui demande une description en une ou deux phrases de la place du morceau — « Ce morceau traite du changement du calcul des franchises introduit dans l'amendement de 2024 à la Politique 47-B » — puis la préfixe au texte du morceau avant l'embedding. Le morceau devient retrouvable pour des requêtes que le texte sous-jacent n'a jamais nommées. Les gains rapportés sont d'environ 49 % de réduction des échecs de recherche sur l'évaluation d'Anthropic, davantage avec recherche hybride et reranking par-dessus. L'astuce qui rend cela économique est le cache de prompt : envoyer le document une fois, traiter chaque morceau contre la version cachée.

Le découpage tardif, introduit par Jina AI en 2024, attaque le même problème par l'autre côté. Le document complet passe par un modèle d'embedding à long contexte en une seule fois, produisant des embeddings au niveau du token déjà contextualisés sur tout le document. Ce n'est qu'ensuite que le document est découpé, l'embedding de chaque morceau étant pooled depuis ses tokens désormais contextualisés. Pas d'appels LLM supplémentaires ; les embeddings héritent du contexte au niveau document implicitement. La contrainte est que le modèle d'embedding doit le supporter nativement (jina-embeddings-v3/v4 et certains modèles de recherche le font) et le document doit tenir dans la fenêtre du modèle. Pour les documents qui tiennent, le découpage tardif égale la recherche contextuelle à une fraction du coût d'indexation. Pour ceux qui ne tiennent pas, la recherche contextuelle est plus générale. Les deux ne sont pas mutuellement exclusives, et les systèmes de production sérieux font souvent tourner les deux avec une étape de déduplication par-dessus.

Ce que prépare le Chapitre 3

Le découpage transforme un document analysé en une population d'unités retrouvables. Chaque unité a besoin d'un endroit où vivre — stockée, indexée, interrogée à faible latence, mise à jour à mesure que le corpus change. Cet endroit est la base vectorielle, et le choix de la base vectorielle est une décision d'un autre genre que celle du découpage. Le découpage est un problème logiciel avec des coûts logiciels. La sélection de base de données est un problème logiciel avec des conséquences d'infrastructure, opérationnelles et réglementaires, et le mauvais choix peut prendre six mois à défaire.

Prochaine étape — Chapitre 4 : Choisir la bonne base vectorielle. Architectures dédiées contre extensions, les leaders managés, le terrain open source, et les trois axes — résidence, exploitation, et coût total — qui décident habituellement du vrai choix.