Contextual Retrieval: fixing RAG's root problem
TL;DR
Chunks lose context, so RAG misses them. Contextual Retrieval has Claude write a short context for each chunk; with BM25 and reranking, Anthropic reports 67% fewer retrieval failures at a low indexing cost thanks to prompt caching.
RAG (Retrieval-Augmented Generation) is the most common way to make an LLM answer from your documents: split documents into chunks, find the relevant chunks, then put them in the prompt. The term was coined in a paper by Lewis et al. (Facebook AI, 2020). The classic problem: once split, each chunk loses its context. A passage saying "Revenue grew by 3% over the previous quarter" doesn't say which company or which quarter, so search misses it. Anthropic proposed Contextual Retrieval to close exactly this gap.
The idea: attach context to each chunk
Before embedding and indexing, have Claude read the whole document together with each chunk, then generate a short explanation (usually 50–100 tokens) prepended to the chunk:
Before: "Revenue grew by 3% over the previous quarter."
After: "This chunk is from ACME's Q2 2023 report, discussing
quarterly revenue; Q1 revenue was $314 million.
Revenue grew by 3% over the previous quarter."
The contextualised chunk feeds both indexes: Contextual Embeddings (search by meaning) and Contextual BM25 (search by keyword).
Anthropic's reported results
Measured by retrieval failure rate (1 − recall@20), averaged across domains:
| Setup | Failure rate | Reduction |
|---|---|---|
| Plain embeddings | 5.7% | - |
| Contextual Embeddings | 3.7% | 35% |
| + Contextual BM25 | 2.9% | 49% |
| + Reranking | 1.9% | 67% |
The reranking setup in the experiment: retrieve the top 150 chunks, rerank, keep the best 20. Passing 20 chunks to the prompt worked better than 5 or 10.
Is the cost worth it?
Generating context for every chunk sounds expensive, but thanks to prompt caching (the document is loaded once and chunks reuse the cache), Anthropic estimates a one-time cost of about $1.02 per million document tokens. That's an indexing cost, not a per-query cost.
The full pipeline
- Split documents into chunks (a few hundred tokens; consider boundaries and overlap).
- For each chunk, call Claude (a small model, with the document cached) to generate context.
- Embed "context + chunk" and build a BM25 index over the same text.
- At query time: search both indexes in parallel, merge results, rerank, take the top K.
- Put the chunks in the prompt and require source citations.
Risks and caveats
- Sometimes you don't need RAG: per Anthropic, a knowledge base under about 200,000 tokens can go straight into the prompt (with caching), which is much simpler.
- Customise the context prompt: adding a glossary for your domain usually beats a generic prompt.
- Reranking adds latency and cost to every query; measure the trade-off on real traffic.
- More chunks can distract: the optimal K must be found with evals, not chosen by feel.
How to apply it
- Dev: Build an eval set of 50–100 questions with their correct chunks; measure recall@20 before and after adding context, and only then add BM25 and reranking.
- Tech Lead: Run context generation via the Batch API with caching to cut indexing cost; store the context separately so it can be reused.
- PM: When an internal chatbot "can't find" information that really is in the docs, it's usually a retrieval bug, not a model bug. Fix retrieval first.
Sources & references
- Introducing Contextual Retrieval — Anthropic
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis et al. (arXiv)