Planning RAG: estimate chunks, overlap and vector size
Estimating chunks and vector size helps you plan a searchable knowledge collection. Compare chunking settings to understand processed text and raw storage, then test retrieval quality and actual index size on a representative sample.
Overlap has a cost and a possible benefit
Chunking creates smaller pieces to process. Overlap keeps shared material at chunk boundaries but repeats text that will be processed again. No single proportion is ideal for every document type and question.
Your material may need paragraph or heading boundaries rather than fixed windows. Evaluate representative questions on a small collection instead of assuming that the setting producing more chunks is better.
References: Microsoft — Chunking strategies and overlap trade-offs
The calculator assumes one continuous token stream
ToolRoof models a continuous corpus, fixed windows and a final possibly shorter chunk. The step between windows equals chunk size minus overlap, so overlap must be smaller than the window.
Document boundaries are not modeled: splitting 100 short documents separately can differ from combining their token counts into one stream. The tool does not upload a corpus or create embeddings; you supply the token count.
Calculate raw bytes, then label them honestly
Raw size is vector count multiplied by dimensions and bytes per dimension. A search index adds other structures; text, metadata, replicas and update overhead are not all included in that figure.
Changing dimensions or representation is not merely a storage-saving switch: it must suit the embedding model and database. This estimate proves neither retrieval accuracy, hosting cost nor answer quality.
References: Microsoft — Raw vector size and index overhead
Example: 2500 tokens and four windows
With 2500 tokens, an 800-token window and 200-token overlap, the step is 600. The resulting lengths are 800, 800, 800 and 700: 3100 tokens processed, including 600 repeated tokens. These are values from a chunking model, not results from running a RAG system.
If each chunk has a 384-dimensional vector using 4 bytes per dimension, raw size is 6144 bytes, or 6 KiB. With zero overlap this example still has 4 chunks but only 2500 embedding-input tokens. Unchanged raw size does not establish equivalent retrieval quality.