Ne chunkez pas de données structurées (JSON, CSV) avec un chunker de texte. Les frontières tombent au milieu des records et les embeddings deviennent absurdes. Découpez par record d'abord, ou utilisez une approche RAG spécifique. Ne chunkez pas de code avec un chunker de prose. Pour le retrieval de code, ce sont les frontières de fonction qui comptent, pas le nombre de caractères. Des chunkers tree-sitter existent. Whitespace et BOM. Du texte collé peut transporter du whitespace caché qui fausse l'estimation. Trimmez et normalisez avant si ça compte. Privacy. Tout tourne dans le navigateur. Les documents collés ne quittent jamais la page ; utilisable pour du contenu confidentiel ou avec PII, comme un script local.

RAG Text Chunker

Découpez du texte en chunks de taille en tokens pour la préparation RAG / embeddings. Plusieurs stratégies : recursive char, sentence-aware, semantic boundaries. Overlap configurable. Tout dans le navigateur.

Paste your document

RAG (Retrieval-Augmented Generation) is a technique that pairs an LLM with an external knowledge base. Instead of relying only on the model's parametric memory, the system retrieves relevant passages at query time and concatenates them into the prompt.

The retrieval step depends on a vector store. Documents are split into chunks, each chunk gets an embedding vector, and those vectors are stored in a database that supports approximate nearest-neighbour search.

# Chunk size matters

Chunks that are too small lose context — a single sentence might not contain enough information to answer the question. Chunks that are too large dilute relevance — the embedding becomes an average of many unrelated topics, and retrieval gets noisy.

A common starting point is 500 tokens per chunk with 50 tokens of overlap. Overlap lets a chunk see a bit of context from its neighbours, which helps when a relevant span happens to fall across a chunk boundary.

# Strategy choice

Recursive character splitting is the most general: it tries paragraph breaks first, then line breaks, then sentence boundaries, then spaces. This is the default in most frameworks and works well for prose.

Sentence-aware splitting respects sentence boundaries and never breaks mid-sentence. It produces cleaner chunks for QA over articles and books, at the cost of more variable chunk sizes.

Paragraph chunking treats each paragraph as its own chunk (subject to the size limit). This is useful for structured documents like documentation or knowledge-base articles where each section is already a coherent unit.

Semantic chunking goes one step further: it tries to keep semantically related content together by respecting headings and topic boundaries, even when those don't align with paragraph breaks.

Chunk size (tokens): 500

Overlap (tokens): 50

Strategy

À quoi ça sert ?

La Retrieval-Augmented Generation (RAG) et la recherche par embeddings dépendent toutes deux du découpage d'un corpus en chunks : petits morceaux embeddés individuellement et stockés dans une vector DB. Le découpage se passe avant toute machinerie IA, mais la qualité de votre retrieval en dépend en silence plus que la plupart des gens le pensent. Chunks trop petits perdent du contexte ; trop grands diluent la pertinence ; chunks coupés au milieu d'une phrase retrievent mal car l'embedding atterrit dans un point sémantique bizarre. Cet outil est un playground rapide dans le navigateur pour expérimenter taille, overlap et stratégie avant de figer une pipeline.

Les quatre stratégies

recursive-char (par défaut). Essaie de découper d'abord aux paragraphes, puis aux sauts de ligne, puis aux frontières de phrase (. ), puis aux espaces. Chaque morceau est emballé glouton jusqu'au budget de taille. Ne retombe sur un découpage par caractères que si rien d'autre ne rentre. Default dans LangChain, LlamaIndex et la plupart des stacks RAG en prod ; point de départ raisonnable pour à peu près tout corpus de prose.
sentence. Découpe aux frontières de phrase, jamais à l'intérieur — même si une phrase est plus courte que le budget, elle reste entière. Mieux que recursive-char quand les chunks seront cités comme preuve (QA, citations) car aucun chunk ne termine au milieu d'une pensée. Tailles plus variables, car les phrases le sont.
paragraph. Traite chaque paragraphe comme une unité. Deux paragraphes courts voisins peuvent être emballés ensemble, mais un long n'est jamais découpé. Utile pour la doc, les articles KB et le format long bien structuré où chaque paragraphe est une pensée cohérente.
semantic. Ajoute la détection de headings au-dessus de paragraph : lignes avec #, ## etc., ou lignes courtes en majuscules, sont traitées comme début de nouvelle section. Bon pour la doc technique où les frontières de section comptent plus que l'espacement visuel.

Overlap — pourquoi et combien

Pourquoi. Si un span pertinent tombe pile entre deux chunks, les deux retrievent mal car chacun n'en a que la moitié. Overlap copie les derniers N tokens du chunk précédent au début du suivant pour que les deux puissent capturer le span.
Combien. 10–20% de la taille du chunk en règle générale. Pour des chunks de 500 tokens, 50–100 d'overlap. Le default ici est 50, fonctionne bien en pratique.
Trade-off. Plus d'overlap = plus d'embeddings total (plus de stockage, plus de coût, build plus lent, plus de candidats au retrieval). Ne dépassez pas 30% sans raison précise ; vous brûlez de l'argent sans gros gain.

Estimation des tokens

C'est une heuristique. chars / 3.8 pour du texte de type anglais et 1 token par caractère CJK. ±5–10% pour la prose, pire avec code ou texte structuré.
Pourquoi pas le vrai tokenizer ? tiktoken c'est ~1 Mo de WASM — trop lourd juste pour le sizing. Si votre modèle aval a une limite stricte (p.ex. cohere/embed-v3 à 512), construisez avec marge ou faites tourner le vrai tokenizer dans votre pipeline.
Pour le sizing ça suffit. Le compte exact par chunk importe peu pour la qualité RAG — le modèle d'embedding tronque de toute façon. Ce qui compte c'est la cohérence : même heuristique pour le chunking et pour budgétiser les prompts aval.

Pièges courants

Ne chunkez pas de données structurées (JSON, CSV) avec un chunker de texte. Les frontières tombent au milieu des records et les embeddings deviennent absurdes. Découpez par record d'abord, ou utilisez une approche RAG spécifique.
Ne chunkez pas de code avec un chunker de prose. Pour le retrieval de code, ce sont les frontières de fonction qui comptent, pas le nombre de caractères. Des chunkers tree-sitter existent.
Whitespace et BOM. Du texte collé peut transporter du whitespace caché qui fausse l'estimation. Trimmez et normalisez avant si ça compte.
Privacy. Tout tourne dans le navigateur. Les documents collés ne quittent jamais la page ; utilisable pour du contenu confidentiel ou avec PII, comme un script local.