Playground · Context & Chunking
Context windows & chunking
A model's context window is finite, so long documents are sliced into overlapping chunks before they're embedded and retrieved. Drag the sliders and watch how chunk size and overlap reshape the passages a RAG system would actually work with.
Context budget
Retrieval only passes as many chunks as fit the model's window. Pick a budget and see how many chunks land inside it.
—
Chunks
Each card is one chunk. Highlighted tokens are shared with a neighbouring chunk — that's the overlap.
Why chunk at all?
Windows are finite
Long documents rarely fit a model's context window, and cramming everything in is slow and costly. Splitting into chunks lets retrieval fetch just the passages relevant to a query.
Overlap preserves meaning
A hard split can cut a sentence — or the link between a claim and its evidence — in half. Overlapping a few tokens keeps that context intact across chunk boundaries.
It's a trade-off
Small chunks are precise but fragmented; large chunks carry more context but fewer fit the budget. Tuning size and overlap is how you balance recall against relevance.
Token counts here are approximate: this demo splits on whitespace and punctuation and treats each word-ish piece as roughly one token. Real tokenisers work in subwords (a rough rule of thumb is ~4 characters per token), so exact counts differ per model. See tokenisation up close in the RAG playground, or browse more explainers on the Learn shelf.