É heurística. chars / 3.8 pra texto tipo inglês e 1 token por caractere CJK. ±5–10% pra prosa, pior pra texto code-heavy ou estruturado. Por que não o tokenizer real? tiktoken é ~1 MB de WASM — pesado demais só pra sizing. Se seu modelo downstream tem limite duro (ex.: cohere/embed-v3 a 512), construa com margem ou rode o tokenizer real na sua pipeline. Pra sizing tá ótimo. A contagem exata por chunk importa pouco pra qualidade RAG — o modelo de embedding trunca de qualquer jeito. O que importa é consistência: mesma heurística pra chunking e pra budgetar prompts downstream.

Não chunkar dados estruturados (JSON, CSV) com chunker de texto. As fronteiras caem no meio de registros e os embeddings ficam sem sentido. Divida por registro primeiro, ou use abordagem RAG específica. Não chunkar código com chunker de prosa. Pra retrieval de código, importam fronteiras de função, não contagem de caracteres. Existem chunkers baseados em tree-sitter. Whitespace e BOM. Texto colado pode trazer whitespace escondido que desvia a estimativa. Trim e normalize antes se importa. Privacidade. Tudo roda no navegador. Documentos colados não saem da página; pode usar pra material confidencial ou com PII como usaria um script local.

Chunker de Texto pra RAG

Divide texto em chunks dimensionados por tokens pra preparação de RAG / embeddings. Múltiplas estratégias: recursive char, sentence-aware, semantic boundaries. Overlap configurável. Tudo no navegador.

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

Pra que serve?

RAG (Retrieval-Augmented Generation) e busca por embeddings dependem ambos de dividir um corpus em chunks: pedaços pequenos que são embedados individualmente e guardados num vector DB. A divisão acontece antes de qualquer maquinário de IA, mas a qualidade do seu retrieval depende silenciosamente disso mais do que a maioria pensa. Chunks pequenos demais perdem contexto; grandes demais diluem relevância; chunks cortados no meio de frase retrievam mal porque o embedding cai num ponto semântico estranho. Esta ferramenta é um playground rápido no navegador pra experimentar tamanho, overlap e estratégia antes de fixar uma pipeline.

As quatro estratégias

recursive-char (padrão). Tenta dividir primeiro por parágrafos, depois quebras de linha, depois fronteiras de frase (. ), depois espaços. Cada peça é empacotada de forma gulosa até o budget de tamanho. Só recorre a corte por caracteres quando nada mais cabe. Default no LangChain, LlamaIndex e na maioria dos stacks RAG em produção; ponto de partida sensato pra quase qualquer corpus de prosa.
sentence. Divide em fronteiras de frase e nunca dentro de uma — mesmo que seja menor que o budget, fica inteira. Melhor que recursive-char quando os chunks serão citados como evidência (QA, citações) porque nenhum chunk termina no meio do pensamento. Tamanhos variam mais, porque frases variam.
paragraph. Trata cada parágrafo como unidade. Dois parágrafos curtos adjacentes podem ser empacotados juntos, mas um longo nunca é dividido. Útil pra documentação, artigos de KB e long-form bem formatado onde cada parágrafo é um pensamento coerente.
semantic. Adiciona detecção de headings em cima de paragraph: linhas com #, ## etc., ou linhas curtas em maiúsculas, são tratadas como início de nova seção. Bom pra documentação técnica onde fronteiras de seção importam mais que espaçamento visual.

Overlap — por que e quanto

Por que. Se um span relevante cai exatamente entre dois chunks, ambos retrievam mal porque cada um tem só metade. Overlap copia os últimos N tokens do chunk anterior pro início do próximo, dando a ambos chance de capturar o span.
Quanto. 10–20% do tamanho do chunk como regra. Pra chunks de 500 tokens, 50–100 de overlap. Aqui o default é 50, funciona bem na prática.
Trade-off. Mais overlap = mais embeddings totais (mais storage, mais custo, build mais lento, mais candidatos). Não passe de 30% sem razão específica; queima dinheiro sem grande ganho.

Estimativa de tokens

É heurística. chars / 3.8 pra texto tipo inglês e 1 token por caractere CJK. ±5–10% pra prosa, pior pra texto code-heavy ou estruturado.
Por que não o tokenizer real? tiktoken é ~1 MB de WASM — pesado demais só pra sizing. Se seu modelo downstream tem limite duro (ex.: cohere/embed-v3 a 512), construa com margem ou rode o tokenizer real na sua pipeline.
Pra sizing tá ótimo. A contagem exata por chunk importa pouco pra qualidade RAG — o modelo de embedding trunca de qualquer jeito. O que importa é consistência: mesma heurística pra chunking e pra budgetar prompts downstream.

Pegadinhas comuns

Não chunkar dados estruturados (JSON, CSV) com chunker de texto. As fronteiras caem no meio de registros e os embeddings ficam sem sentido. Divida por registro primeiro, ou use abordagem RAG específica.
Não chunkar código com chunker de prosa. Pra retrieval de código, importam fronteiras de função, não contagem de caracteres. Existem chunkers baseados em tree-sitter.
Whitespace e BOM. Texto colado pode trazer whitespace escondido que desvia a estimativa. Trim e normalize antes se importa.
Privacidade. Tudo roda no navegador. Documentos colados não saem da página; pode usar pra material confidencial ou com PII como usaria um script local.