For the complete documentation index, see llms.txt. Every page on this site is also served as Markdown: append `.md` to any URL, or send `Accept: text/markdown`.
AI Glossary

Chunking

Splitting a corpus into retrievable pieces before embedding it, why the split destroys context, and what contextual retrieval measured about fixing it.

Karl-Gustav KallasmaaKarl-Gustav Kallasmaa, Founder & CEOLast updated

Chunking is the step where a body of text is cut into smaller pieces so each piece can be indexed and retrieved on its own. It is the least glamorous part of a retrieval system and routinely the part that decides whether it works.

Anthropic's description of a standard pipeline puts it first: break the corpus into smaller chunks of text, usually no more than a few hundred tokens; use an embedding model to convert those chunks into vectors that encode meaning; store the vectors in a database that supports searching by semantic similarity. At query time, the nearest chunks are found and added to the prompt sent to the generative model.

The context problem

Cutting text up destroys the thing that made it understandable. Anthropic states the failure directly: traditional retrieval removes context when encoding information, which often results in the system failing to retrieve the relevant information at all.

Its example is the clearest one available. Imagine a collection of financial filings and the question "What was the revenue growth for ACME Corp in Q2 2023?" A genuinely relevant chunk might read: "The company's revenue grew by 3% over the previous quarter." That sentence names neither the company nor the quarter. Nothing about its vector will bring it back for a query that names both, and if it does come back, the model has no way to know what it refers to.

This is not an exotic edge case. It is what happens to most pronouns, most "this", most section-relative references and most tables whose header row landed in a different chunk.

Contextual retrieval, and what it measured

The fix Anthropic published is preprocessing rather than clever querying: prepend chunk-specific explanatory context to each chunk before embedding it and before building the lexical index. The transformed version of the example reads: "This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter."

Because annotating millions of chunks by hand is impossible, the context is generated by a model, prompted to situate each chunk within its whole document and answer with nothing else. The resulting text is usually 50 to 100 tokens.

The reported results, measured as one minus recall at 20 across codebases, fiction, ArXiv papers and science papers:

Three of Anthropic's implementation notes are worth carrying over regardless of stack: chunk size, chunk boundary and chunk overlap all affect performance; some embedding models benefit more than others; and passing 20 chunks to the model outperformed 5 or 10 in their tests, though more information can also distract a model, so there is a limit.

The part that is a writing problem

An engineer can tune chunk size. Nobody can tune a document into being self-contained. If a section only makes sense after the two above it, every chunking strategy will produce a piece that means less than the author intended.

That is why chunking belongs in a marketing glossary at all. The way your page is written decides what its chunks say once they are separated from it:

  • One subject per section. A section covering four topics produces a vector that means none of them.
  • Headings that state the claim, not headings that tease it, because the heading is often the only context a chunk keeps.
  • Repeat the subject. Naming the product, the version and the period inside the paragraph rather than relying on the H2 above it is the manual version of contextual retrieval.
  • Keep identifiers literal. Exact strings are what a lexical index can match when a vector cannot.
  • Do not split a claim from its qualifier. A caveat in a different paragraph is a caveat in a different chunk.

When not to bother

The first question is whether retrieval is needed at all. Anthropic's guidance is that a knowledge base under 200,000 tokens — roughly 500 pages — can simply go in the prompt, no retrieval required, and notes that prompt caching makes that approach cheaper and faster than it used to be. Chunking is the price of scale, not a virtue, and a system that pays it for a corpus that fits in the context window has bought a failure mode for nothing.

Frequently Asked Questions about Chunking

Anthropic's description of a standard retrieval pipeline says a knowledge base is broken into smaller chunks of text, usually no more than a few hundred tokens, which are then embedded and stored for search by semantic similarity.

Because a chunk can lose the context that makes it findable. Anthropic's example is a chunk reading 'The company's revenue grew by 3% over the previous quarter', which on its own names neither the company nor the period, making it hard to retrieve for a question that names both.

A preprocessing technique that prepends chunk-specific explanatory context to each chunk before it is embedded and before the lexical index is built. Anthropic reports the added context is usually 50 to 100 tokens.

Anthropic reports that contextual embeddings reduced the top-20-chunk retrieval failure rate by 35%, from 5.7% to 3.7%, and that combining contextual embeddings with contextual BM25 reduced it by 49%, from 5.7% to 2.9%.

Anthropic's guidance is that if a knowledge base is smaller than 200,000 tokens, about 500 pages of material, you can include the whole thing in the prompt with no need for retrieval at all.
Share this term

Track how your brand shows up in ChatGPT, Claude, and Google AI

Attensira monitors your visibility across AI search platforms so you know exactly when and how you're being recommended.