Enhancing RAG with Contextual Retrieval

Why it matters

A chunk cut from its document often loses what it is about, so neither semantic nor keyword search can find it. 3.6 asks you to tune relevance across retrieval stages; this notebook adds one stage at a time and measures each.

What to practise

Establish a Pass@k baseline over a pre-chunked set of codebases. Then have Claude write a short situating context for every chunk at ingestion, with the whole document behind cache_control, and watch the cache metrics as chunks from one document reuse it. Index the contextualized chunks in BM25 on Elasticsearch as well, fuse both rankings with weighted reciprocal rank fusion, and tune the semantic and BM25 weights. Separately, over-retrieve from the contextual embeddings alone and rerank the candidates with a Cohere reranker.

How it fits

The hybrid fusion, reranking and retrieval depth are 3.6.3’s relevance stages, and the added chunk context answers 3.5.3’s boundary problem at ingestion rather than per query. Compare each stage’s Pass@k gain with its cost: contextualization is paid once at ingestion, while BM25 adds a search service and reranking adds latency and cost to every query.