recursive-char (default). Prova prima a spezzare ai paragrafi, poi alle nuove righe, poi ai confini di frase ( . ), poi agli spazi. Ogni pezzo viene impacchettato in modo greedy fino al budget. Ricade su split per caratteri solo se nient'altro entra. Default in LangChain, LlamaIndex e gran parte degli stack RAG in produzione; punto di partenza sensato per quasi ogni corpus di prosa. sentence . Spezza ai confini di frase e mai dentro a una — anche se è più corta del budget, resta intera. Meglio di recursive-char quando i chunk verranno citati come evidenza (QA, citazioni) perché nessun chunk finisce a metà pensiero. Le dimensioni variano di più, perché le frasi variano. paragraph . Tratta ogni paragrafo come unità. Due paragrafi corti adiacenti possono essere impacchettati insieme, ma uno lungo non viene mai spezzato. Utile per documentazione, articoli KB e long-form ben formattato dove ogni paragrafo è un pensiero coerente. semantic . Aggiunge il rilevamento di heading sopra paragraph: righe con # , ## ecc., o righe corte tutto maiuscolo, sono trattate come nuove sezioni. Buono per documentazione tecnica dove i confini di sezione contano più della spaziatura visiva.

È euristica. caratteri / 3.8 per testo tipo inglese e 1 token per carattere CJK. ±5–10% per prosa, peggio per testo code-heavy o strutturato. Perché non il tokenizer reale? tiktoken è ~1 MB di WASM — troppo pesante solo per il sizing. Se il tuo modello downstream ha un limite duro (es. cohere/embed-v3 a 512), costruisci con margine o esegui il tokenizer reale nella tua pipeline. Per il sizing va bene. Il conteggio esatto per chunk conta poco per la qualità RAG — il modello di embedding tronca comunque. Quello che conta è coerenza: stessa euristica per chunking e per budgeting dei prompt downstream.

Non chunkare dati strutturati (JSON, CSV) con un chunker di testo. I confini cadono a metà record e gli embedding diventano insensati. Spezza per record prima, o usa un approccio RAG specifico. Non chunkare codice con un chunker di prosa. Per il retrieval di codice contano i confini di funzione, non i caratteri. Esistono chunker basati su tree-sitter. Whitespace e BOM. Testo incollato può portare whitespace nascosto che falsa la stima dei token. Trimma e normalizza prima se conta. Privacy. Tutto gira nel browser. I documenti incollati non lasciano la pagina; usalo per materiale confidenziale o con PII come faresti con uno script locale.

RAG Text Chunker

Spezza il testo in chunk dimensionati a token per preparazione RAG / embeddings. Strategie multiple: recursive char, sentence-aware, semantic boundaries. Overlap configurabile. Tutto nel browser.

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

A cosa serve?

RAG (Retrieval-Augmented Generation) e la ricerca per embeddings dipendono entrambe dallo spezzare un corpus in chunk: piccoli pezzi embeddati individualmente e archiviati in un vector DB. Lo split avviene prima di qualsiasi macchinario AI, ma la qualità del tuo retrieval dipende silenziosamente da esso più di quanto la maggior parte pensi. Chunk troppo piccoli perdono contesto; troppo grandi diluiscono rilevanza; chunk tagliati a metà frase retrievano male perché l'embedding finisce in un punto semantico strano. Questo strumento è un playground veloce in browser per sperimentare con dimensione, overlap e strategia prima di fissare una pipeline.

Le quattro strategie

recursive-char (default). Prova prima a spezzare ai paragrafi, poi alle nuove righe, poi ai confini di frase (. ), poi agli spazi. Ogni pezzo viene impacchettato in modo greedy fino al budget. Ricade su split per caratteri solo se nient'altro entra. Default in LangChain, LlamaIndex e gran parte degli stack RAG in produzione; punto di partenza sensato per quasi ogni corpus di prosa.
sentence. Spezza ai confini di frase e mai dentro a una — anche se è più corta del budget, resta intera. Meglio di recursive-char quando i chunk verranno citati come evidenza (QA, citazioni) perché nessun chunk finisce a metà pensiero. Le dimensioni variano di più, perché le frasi variano.
paragraph. Tratta ogni paragrafo come unità. Due paragrafi corti adiacenti possono essere impacchettati insieme, ma uno lungo non viene mai spezzato. Utile per documentazione, articoli KB e long-form ben formattato dove ogni paragrafo è un pensiero coerente.
semantic. Aggiunge il rilevamento di heading sopra paragraph: righe con #, ## ecc., o righe corte tutto maiuscolo, sono trattate come nuove sezioni. Buono per documentazione tecnica dove i confini di sezione contano più della spaziatura visiva.

Overlap — perché e quanto

Perché. Se uno span rilevante cade esattamente al confine tra due chunk, entrambi retrievano male perché ognuno ne ha solo metà. L'overlap copia gli ultimi N token del chunk precedente all'inizio del successivo, dando a entrambi la possibilità di catturarlo.
Quanto. 10–20% della dimensione del chunk come regola. Per chunk da 500 token, 50–100 di overlap. Qui il default è 50, funziona bene in pratica.
Trade-off. Più overlap = più embedding totali (più storage, più costo, build più lenta, più candidati). Non passare il 30% senza ragione specifica; bruci soldi senza migliorare molto.

Stima dei token

È euristica. caratteri / 3.8 per testo tipo inglese e 1 token per carattere CJK. ±5–10% per prosa, peggio per testo code-heavy o strutturato.
Perché non il tokenizer reale? tiktoken è ~1 MB di WASM — troppo pesante solo per il sizing. Se il tuo modello downstream ha un limite duro (es. cohere/embed-v3 a 512), costruisci con margine o esegui il tokenizer reale nella tua pipeline.
Per il sizing va bene. Il conteggio esatto per chunk conta poco per la qualità RAG — il modello di embedding tronca comunque. Quello che conta è coerenza: stessa euristica per chunking e per budgeting dei prompt downstream.

Trappole comuni

Non chunkare dati strutturati (JSON, CSV) con un chunker di testo. I confini cadono a metà record e gli embedding diventano insensati. Spezza per record prima, o usa un approccio RAG specifico.
Non chunkare codice con un chunker di prosa. Per il retrieval di codice contano i confini di funzione, non i caratteri. Esistono chunker basati su tree-sitter.
Whitespace e BOM. Testo incollato può portare whitespace nascosto che falsa la stima dei token. Trimma e normalizza prima se conta.
Privacy. Tutto gira nel browser. I documenti incollati non lasciano la pagina; usalo per materiale confidenziale o con PII come faresti con uno script locale.