Découper un texte pour les embeddings : là où tombe la coupe décide de ce que vous retrouvez
Les systèmes de recherche échouent en silence. Vous encodez un corpus, branchez une recherche, posez une question, et vous récupérez quelque chose de thématiquement voisin qui n'y répond pas. Le réflexe est d'accuser le modèle d'embedding ou la mesure de similarité. Bien plus souvent, le problème s'est produit avant les deux : le texte a été découpé en morceaux qui ne contiennent pas chacun une idée complète, et aucun classement astucieux ne récupère un sens détruit au moment de la coupe.
Cet outil découpe un texte en fragments bornés en tokens avec chevauchement, en coupant à la frontière la plus significative disponible plutôt qu'à un décalage fixe. Il vous montre chaque frontière, car une mauvaise coupe ne se voit qu'en lisant où un fragment finit et où le suivant commence. Tout tourne dans cet onglet.
Le découpage récursif par frontières
L'approche naïve consiste à trancher tous les N tokens. C'est rapide et c'est faux, car une frontière de token n'a aucun rapport avec une frontière de sens : vous couperez au milieu d'une phrase, parfois au milieu d'un mot, et le vecteur obtenu décrit un fragment que personne n'a écrit.
La méthode employée ici descend une échelle de séparateurs, en utilisant le premier qui produit des morceaux assez petits pour tenir. Dans l'ordre : avant un titre Markdown, puis les lignes vides, puis n'importe quel saut de ligne, puis les frontières de phrase, puis les frontières de proposition aux virgules et points-virgules, puis les espaces entre les mots. Ce n'est que si aucun de ceux-là n'existe — un bundle minifié, un seul mot immense — qu'on retombe sur une coupe par index de token.
L'effet pratique est que la structure est préservée dès que le texte en a une. Un document à titres se découpe aux sections. La prose se découpe aux paragraphes, ou aux phrases quand un paragraphe est trop long. Un pavé ininterrompu se découpe aux mots. Chaque fragment se termine là où une personne l'aurait terminé, sauf si le texte n'offrait aucune occasion de le faire.
À quoi sert vraiment le chevauchement
Le chevauchement répète la fin d'un fragment au début du suivant. Il existe parce qu'un fait et ce à quoi il se réfère se retrouvent souvent de part et d'autre d'une frontière. « La migration a tourné cette nuit. Elle a échoué sur la troisième table. » Coupez entre ces deux phrases et le second fragment contient un échec sans sujet, tandis que le premier contient une migration sans résultat. Ni l'un ni l'autre ne remonte utilement. Avec chevauchement, le second fragment emporte son antécédent.
Le coût est la duplication : les tokens qui se chevauchent sont stockés, encodés et cherchés plus d'une fois. Dix à quinze pour cent de la taille du fragment est le compromis habituel, et c'est là que se placent les préréglages. Le panneau de statistiques indique exactement combien de tokens le chevauchement a ajoutés : l'arbitrage devient un chiffre plutôt qu'une impression.
Une protection mérite d'être connue : un chevauchement égal ou supérieur à la taille du fragment voudrait dire que chaque fragment commence par tout ce que le précédent a terminé, et le processus n'avance jamais. Cette valeur est ramenée dans les clous plutôt que laissée bloquer l'outil.
Choisir une taille
La taille du fragment est un arbitrage entre précision et contexte, et il n'y a pas de réponse universellement juste :
- Les petits fragments, autour de 256 tokens, donnent des correspondances nettes. Un vecteur portant sur deux ou trois phrases est dominé par ce que ces phrases disent. Bon pour les questions-réponses sur de la documentation dense. Le risque, ce sont des fragments qui correspondent bien mais auxquels manque le contexte nécessaire pour vraiment répondre.
- Les fragments moyens, autour de 512, sont la valeur par défaut habituelle et l'endroit où la plupart des modèles d'embedding se sentent le mieux. À peu près un paragraphe consistant.
- Les gros fragments, 1024 et au-delà, portent plus de contexte par résultat mais diluent le vecteur. Un fragment couvrant quatre sujets se place dans la moyenne des quatre et ne correspond fortement à aucun.
- Les très gros fragments, plusieurs milliers de tokens, cessent d'être une unité de recherche pour devenir une unité de pagination — pour faire passer un long document dans un modèle en plusieurs passes plutôt que pour le fouiller.
Quatre stratégies de découpe
La découpe intelligente est l'échelle récursive décrite plus haut : c'est le bon choix pour la plupart des textes. Paragraphes regroupe des paragraphes entiers sans jamais en diviser un, ce qui convient aux textes où le paragraphe est déjà l'unité de pensée et où vous préférez des tailles inégales à un paragraphe cassé. Titres Markdown donne un fragment par section, le choix naturel pour de la documentation où un titre nomme exactement ce qui suit. Lignes regroupe des lignes entières, pour les journaux, les extraits CSV et les listes où chaque ligne est indépendante.
Dans tous les modes, toute unité qui dépasse encore la limite est réduite par le découpeur récursif avant d'être empaquetée : un choix de stratégie ne produit jamais un fragment hors gabarit.
Le comptage, et ce que le chiffre veut dire
Les tokens sont comptés avec le même tokenizer que ce site utilise pour mesurer les dépôts, celui de la famille employée par les modèles d'OpenAI. Les comptes pour Claude et Gemini diffèrent un peu — des vocabulaires différents segmentent le même texte différemment — mais ils suivent d'assez près pour dimensionner un fragment face à une limite. Si votre budget est serré, gardez de la marge plutôt que de prendre le chiffre pour exact.
Notez aussi que la limite annoncée d'un modèle d'embedding est un point de troncature strict, pas une cible. Dépassez-la et la fin est silencieusement supprimée : un mode de défaillance qui ne produit aucune erreur et dégrade la recherche d'une manière franchement difficile à diagnostiquer.
Une sortie que vous pouvez donner à quelque chose
Trois téléchargements. Du texte brut avec des en-têtes --- Chunk n/N --- facultatifs, pour lire et vérifier. Du JSON sous forme de tableau d'objets avec index, nombre de tokens et texte, pour un script qui avale le tout. Du JSONL avec un objet par ligne, ce qu'attendent l'ingestion en flux et la plupart des points d'accès d'encodage par lots, et ce qu'il vous faut quand le corpus est trop gros pour tenir en mémoire sous forme d'un seul tableau analysé.
Cela s'associe naturellement au reste du site : convertissez d'abord un dépôt, un PDF, une page web ou une transcription en texte, puis découpez le résultat ici. Rien n'est envoyé, à aucune des deux étapes.