Practical guide
How to choose a RAG chunking strategy
Chunking decides what your retriever can find. Chunks that are too small lose context; chunks that are too large mix unrelated ideas and reduce retrieval precision. Treat the calculator as a starting model, then test the configuration with representative questions from your users.
What the estimates mean
Source tokens
Document words are converted using your selected average tokens per word. English prose often lands near 1.2–1.5, while code, tables, and non-English text can differ significantly.
Chunk count and duplication
A sliding window advances by chunk size minus overlap. Every overlap repeats content in another embedding request, increasing ingestion tokens and the chance of retrieving near-duplicate passages.
Retrieval context
Top-k multiplied by chunk size approximates the maximum retrieved text passed downstream. Your prompt, conversation history, instructions, and generated answer still need context-window space.
Vector storage
Raw float32 storage is dimensions multiplied by four bytes for every vector. Real databases add metadata and index overhead, while quantization can reduce the vector footprint.
Don't optimize chunking in isolation
Retrieval quality also depends on parsing, metadata, embedding choice, hybrid search, filters, re-ranking, and evaluation. A smaller chunk is not automatically a better chunk.
Read my production RAG notesFrequently asked questions
What chunk size should I use for RAG?
A practical starting range is 300–800 tokens. Short chunks improve retrieval precision, while longer chunks preserve more surrounding context. The right size depends on document structure, query style, embedding model, and whether you use re-ranking or parent-child retrieval.
How much overlap should RAG chunks have?
Start around 10–20% of chunk size. Overlap helps preserve facts that cross boundaries, but excessive overlap duplicates embedding work and can return near-identical chunks. Evaluate against real questions rather than treating one percentage as universal.
How is the number of chunks calculated?
The first chunk covers the full chunk size. Every additional chunk advances by chunk size minus overlap. This calculator estimates chunks as 1 + ceiling((total tokens - chunk size) / effective stride) when the document is larger than one chunk.
Does vector storage include database overhead?
No. The storage estimate represents raw float32 vector values: chunks multiplied by embedding dimensions multiplied by four bytes. Vector indexes, metadata, IDs, replicas, quantization, and provider-specific overhead can materially change real storage.