RAG Chunk Size Calculator
Chunk count, embedding cost, vector storage size, and whether top-k retrieved chunks actually fit your context window.
It helps you cut documents into pieces that an AI can search and read.
What this tool does
RAG systems split documents into chunks, search for the closest chunks, then place them in the model’s prompt. This tool estimates chunk count, indexing cost, storage, and how much retrieved text fits.
- Choose a first chunk size and overlap for a RAG system
- Check whether the selected top-k chunks fit the model context
- Estimate embedding and vector storage costs
Corpus tokens: ( words)
| Provider | Model | Embed cost | Storage |
|---|---|---|---|
pricing. Tokens ≈ 0.75 × words. Storage = chunks × dims × 4 bytes + ~512 B metadata/chunk. See embeddings cost estimator for re-embed schedules.
Top-k chunks exceed available context after system prompt and question. Lower k, shrink chunks, or pick a larger window — try the context window fit checker with real text.
Retrieval fits with headroom for model output. Leave space for the answer — this bar only covers retrieved context + fixed prompt budget.
Smaller chunks improve precision but multiply embedding cost and index size. Larger chunks preserve local context but retrieve irrelevant text. Overlap reduces boundary splits but increases chunk count — 10–20% is a common starting point. Re-ranking (cross-encoder or LLM) after vector search often beats tweaking chunk size alone.
Chunk sizing is the first RAG architecture decision. This calculator connects corpus size to chunk count, embedding bills, and whether your retrieval budget actually fits the model you plan to call.