RAG chunking playground
Paste a document, choose how to split it, and see exactly where the boundaries land, what each chunk costs in tokens, and how much text you are paying to store twice. Chunk size is the decision that quietly determines whether retrieval works at all.
Runs in your browser. Nothing you paste is uploaded.
4
Chunks
302
Average chars
...
Average tokens
0%
Duplicated
Paid for twice, in storage and embedding calls
- CHUNK 01348 chars
Retrieval augmented generation has one job: put the right context in the prompt. Everything else is plumbing. The pipeline is simple to describe. Split the document into chunks. Embed each chunk into a vector. Store the vectors. At query time, embed the question, find the nearest chunks, and paste them into the prompt before the model answers.
- CHUNK 02371 chars
Chunk size is the decision that quietly determines whether any of this works. Chunks that are too small lose the context that made them meaningful, so a paragraph explaining why a decision was made gets separated from the decision itself. Chunks that are too large dilute the embedding, because a vector averaging six unrelated topics is close to nothing in particular.
- CHUNK 03378 chars
Overlap exists to stop an idea being severed at a boundary. It costs you storage and embedding calls on every duplicated character, so it is a real trade rather than a free win. A common starting point is ten to twenty percent, then measure. The failure nobody warns you about is that retrieval returns something plausible and wrong, and the model answers confidently from it.
- CHUNK 04110 chars
You do not notice this in a demo. You notice it in production, from a user, about a question you never tested.
The trade is straightforward once you can see it. Small chunks embed precisely but lose the context that made them mean anything, so the paragraph explaining a decision ends up separated from the decision. Large chunks keep context but dilute the vector, because an embedding averaging six topics sits near none of them.
Overlap is insurance against severing an idea at a boundary, and it is not free. Every duplicated character is one you embed and store twice, which is what the duplicated percentage is showing you. Ten to twenty percent is a reasonable place to start, and then you measure rather than guess.
Watch the token counts more than the character counts. Embedding models have hard input limits, and a chunk that silently exceeds one gets truncated rather than rejected. You do not get an error. You get a vector for the first half of your chunk and no indication that the rest was dropped.
If your documents have real structure, headings, sections, code blocks, then splitting on that structure beats any character count. The paragraph strategy here is the crude version of that idea, and it is usually enough to show whether the idea is worth pursuing.
Questions people arrive with
- What chunk size should I use for RAG?
- There is no single right answer, which is why this shows you the splits rather than recommending a number. Common starting points are 500 to 1000 characters with 10 to 20 percent overlap, then measure retrieval quality rather than trusting the default. Paste a real document above and see exactly where the boundaries land.
- Why does my RAG system return the wrong passage?
- Most often because a chunk boundary cut an idea in half, so the sentence explaining a decision ended up separated from the decision. Chunks that are too large fail differently: the embedding averages several unrelated topics and lands near nothing in particular.