Calculadora de número de chunks
Estime quantos chunks seu conjunto de documentos gera para um pipeline RAG — grátis e totalmente privado no seu navegador. Configure número de documentos, média de palavras, tamanho do chunk, sobreposição e estratégia (tamanho fixo, janela deslizante, frases, parágrafos, recursiva ou semântica). Veja na hora o total de chunks, o custo de embeddings em 5 fornecedores e as estimativas de armazenamento vetorial.
Estimate how many chunks your dataset produces based on document size, chunk size, overlap, and chunking strategy. See total embedding token counts, embedding costs, and vector storage requirements - instantly in your browser.
Dataset
Splits text into equal-sized chunks. Simple and predictable.
Chunk Parameters
Chunk Count Results
Total Chunks
200
Chunks / Doc
2
Avg Doc Tokens
667
Effective Tokens
462
per chunk
Embedding & Storage Estimates
Tokens to Embed
102,400
chunk_count × chunk_size
Embedding Cost
$0.0020
OpenAI text-embedding-3-small
Vector Storage
1.2 MB
1,536 dims × float32
Strategy Comparison (same dataset & chunk size)
| Strategy | Total Chunks | Embed Cost | vs. Fixed |
|---|---|---|---|
Fixed-Size (no overlap)Selected | 200 | $0.0020 | Baseline |
Sliding Window (with overlap) | 200 | $0.0020 | Baseline |
Sentence-Based | 200 | $0.0020 | Baseline |
Paragraph-Based | 200 | $0.0020 | Baseline |
Recursive Character Split | 200 | $0.0020 | Baseline |
Semantic Chunking | 200 | $0.0020 | Baseline |
Por que o número de chunks define o custo do RAG
Em um pipeline RAG, o número de chunks determina dois custos ao mesmo tempo: a geração de embeddings na ingestão e o armazenamento dos vetores. Uma estratégia ruim pode multiplicar ambos sem melhorar a recuperação.
Informe número de documentos, média de palavras, tamanho do chunk e sobreposição para ver quantos chunks o conjunto vai gerar e quanto custará vetorizar.
- Chunks = ceil((tokens do documento − sobreposição) / (tamanho do chunk − sobreposição)).
- O custo de embeddings é pago uma vez na ingestão, mas se repete se o conteúdo ou o modelo mudar.
- O armazenamento real supera a estimativa bruta por metadados e índices HNSW.
Escolher a estratégia de divisão
Não existe uma estratégia universalmente melhor. Tamanho fixo é simples e previsível; abordagens semânticas e recursivas respeitam melhor a estrutura do documento, mas geram contagens e custos menos previsíveis.
- Tamanho fixo e janela deslizante: simples e fáceis de orçar.
- Por frases e parágrafos: preservam unidades de sentido, com contagens irregulares.
- Recursiva e semântica: melhor recuperação, custo maior e menos previsibilidade.
Ajustar tamanho e sobreposição
Comece com 512 tokens e 50 de sobreposição, meça a qualidade da recuperação e ajuste. Aumentar a sobreposição melhora a continuidade, mas encarece a ingestão.
- Estime o número de chunks com seu tamanho e sobreposição atuais.
- Calcule o custo de embeddings e o armazenamento vetorial resultantes.
- Teste uma segunda configuração (por exemplo, 256 tokens) e compare os cenários.
- Escolha a configuração que equilibre recuperação, custo e volume de armazenamento.
Perguntas frequentes
Um chunk é um trecho de texto de tamanho fixo ou variável produzido ao dividir um documento maior. Em um sistema RAG (Retrieval-Augmented Generation), os documentos são divididos em chunks, cada chunk vira um embedding vetorial e os embeddings ficam em um banco vetorial. No momento da consulta, os chunks semanticamente mais parecidos são recuperados e injetados como contexto no prompt do LLM.
Para divisão de tamanho fixo: chunks = ceil((tokens_do_documento − sobreposição) / (tamanho_do_chunk − sobreposição)). Um documento de 1.000 tokens com chunks de 512 e 50 de sobreposição gera ceil((1000 − 50) / (512 − 50)) = ceil(950 / 462) = 3 chunks por documento. Estratégias por frases e parágrafos dão contagens um pouco diferentes por efeitos de alinhamento de limites.
Um ponto de partida comum é 512 tokens com 50 de sobreposição para documentos de texto corrido. Chunks menores (128-256 tokens) melhoram a precisão da recuperação, mas podem faltar contexto. Chunks maiores (1024+ tokens) dão contexto mais rico, mas podem reduzir a relevância. O tamanho ideal depende do tipo de documento, do estilo de consulta e do modelo de embeddings. Avalie sempre a qualidade da recuperação empiricamente.
Tokens de sobreposição são compartilhados entre chunks consecutivos. Com 512 tokens de tamanho e 50 de sobreposição, os últimos 50 tokens do chunk N viram os primeiros 50 do chunk N+1. Isso evita perder informação perto dos limites e melhora a continuidade em consultas que cruzam fronteiras. A sobreposição aumenta proporcionalmente o total de chunks e o custo de embeddings.
Custo de embeddings = total_de_chunks × tokens_por_chunk / 1.000.000 × custo_por_milhão_de_tokens. Por exemplo, 1.000 chunks × 512 tokens = 512.000 tokens para vetorizar. Com OpenAI text-embedding-3-small (US$ 0,020/M tokens), isso custa US$ 0,0102. Cada chunk é vetorizado uma vez na ingestão — nova vetorização só é necessária quando o conteúdo muda.
Armazenamento vetorial = total_de_chunks × dimensões_do_embedding × 4 bytes (float32). Para 10.000 chunks com OpenAI text-embedding-3-small (1.536 dims): 10.000 × 1.536 × 4 = ~61,4 MB de vetores brutos. O armazenamento real é maior por causa de metadados, estruturas de índice (grafos HNSW) e replicação. Modelos quantizados (int8) reduzem essa estimativa pela metade.
Sim. A calculadora roda inteiramente no seu navegador. Nenhum conteúdo de documento, detalhe de conjunto de dados ou configuração é enviado a servidor algum. Todos os cálculos — número de chunks, custo de embeddings, armazenamento — são feitos localmente no seu dispositivo. Seus dados permanecem 100 % privados, sem cadastro.