Contextual retrieval, in one move at ingestion time

**Contextual retrieval** is a trick you apply while building your index, not while answering a query. When you split a document into chunks, each chunk gets embedded on its own. The problem is that a chunk often leans on context that lives elsewhere in the document. A chunk that reads 'it grew 3% that quarter' makes perfect sense in the original report, but on its own it never names the company, the product, or the year. Once that chunk is embedded in isolation, its vector carries none of those missing details. The fix is simple. Before embedding each chunk, send it plus the whole document to an LLM and ask for a one or two sentence summary of where the chunk sits, such as 'This is from Acme's Q3 2024 report and concerns product-line revenue.' You prepend that summary to the chunk text, then embed the combined text. Now the stored vector encodes the missing entities, so a query like 'Acme revenue growth in Q3' can match it. The same prepended text usually feeds the keyword index too. The cost is one extra LLM call per chunk at indexing time, which prompt caching over the parent document keeps cheap.

**Contextual retrieval** acts at ingestion time. Before each chunk is embedded, an LLM generates a short summary situating that chunk inside its source document, and the summary is prepended to the chunk text. The failure it fixes is referential. Plain chunking embeds each chunk in isolation, so a chunk like 'it grew 3% that quarter' loses the entities a query depends on: which company, which product, which year. The vector then carries no signal that lets a query like 'Acme Q3 revenue growth' match it, and the chunk becomes effectively unretrievable even though it holds the answer. Prepending the generated context puts those disambiguating entities back into the text before embedding, so the stored vector now encodes them and the chunk becomes matchable. The same prepended text typically feeds the lexical or BM25 index too, which is why the technique improves both dense and sparse retrieval. The cost is one extra LLM call per chunk during indexing. The standard mitigation is prompt caching over the parent document, so the document is read once and reused across all its chunks rather than re-sent each time.