Contextual retrieval prepends generated context to each chunk before embedding — what chunking failure does that fix?

The failure being fixed is about **lost context**, not about chunk size. When you split a document into fixed-size chunks and embed each one alone, a chunk often relies on information that lives elsewhere in the document. Take a chunk that reads 'it grew 3% that quarter.' On its own it never says which company, which product line, or which year. Its embedding ends up being about vague growth, with none of those specifics inside it. So when someone asks 'Acme revenue growth in Q3', the query mentions exactly the entities the chunk dropped. The two vectors land far apart, the chunk never makes the top results, and the system answers as if it has no information, even though that chunk holds the answer. Contextual retrieval fixes this at ingestion time. Before embedding, an LLM reads the chunk plus its parent document and writes a short note like 'This chunk is from Acme's Q3 2024 report about product-line revenue.' You prepend that note to the chunk, then embed the combined text. Now the vector carries the entities, and the chunk becomes retrievable. The same combined text usually goes into the keyword index too.

The failure is **referential context loss**. Plain fixed-size chunking embeds each chunk in isolation, so a chunk like 'it grew 3% that quarter' loses the entities it silently depends on: which company, which product, which year. The embedding of that bare chunk encodes generic growth, not Acme or Q3, so a query like 'Acme revenue growth in Q3' lands far away in vector space. The chunk never reaches the top-k and is effectively unretrievable even though it contains the answer. Crucially this is not a chunk-size problem; a bigger chunk that still omits the entities fails the same way. Contextual retrieval repairs this before embedding. An LLM generates a short summary situating the chunk in its source document. A typical summary reads 'This chunk is from Acme's Q3 2024 report and concerns product-line revenue.' That summary is prepended to the chunk text before embedding. The stored vector now encodes the disambiguating entities, so the chunk becomes matchable. The same prepended text typically feeds the BM25 or lexical index, so both dense and sparse retrieval improve. The tradeoff is an extra LLM call per chunk at ingestion. That is usually mitigated with prompt caching over the parent document, so the document is read once and reused across all its chunks.