Anthropic's Contextual Retrieval technique has a language model generate 50-100 tokens of chunk-specific context, such as noting which company and filing period a chunk comes from, and prepends that generated context to the chunk's own text before the chunk is embedded and before it is indexed for keyword search. Anthropic's own testing found this reduced the top-20-chunk retrieval failure rate substantially on its own, with a further reduction when reranking was added on top. What underlying problem does prepending this generated context address?
- A chunk taken in isolation often loses context that made it unambiguous inside the full document, such as which company or time period it refers to, so a bare chunk's embedding and keyword index entry can end up representing an ambiguous fragment rather than the specific fact the chunk actually states; prepending a short explanatory blurb restores that missing context before the chunk is indexed
- Embedding models have a hard minimum input length, so very short chunks fail to produce a usable embedding at all unless padded with additional generated text first
- The generated context tokens replace the original chunk text entirely, and it is faster for the embedding model to process 50-100 tokens of generated summary than the chunk's original, longer text
- The generated context is only read by a human reviewer during a quality-assurance step, and it is stripped back out before the chunk is embedded or indexed, so it never affects retrieval directly
Why A? And why not the others?
Correct answer: A. A chunk taken in isolation often loses context that made it unambiguous inside the full document, such as which company or time period it refers to, so a bare chunk's embedding and keyword index entry can end up representing an ambiguous fragment rather than the specific fact the chunk actually states; prepending a short explanatory blurb restores that missing context before the chunk is indexed
Splitting a long document into chunks strips each chunk of its surrounding context, so a chunk that says something like 'the company's revenue grew 3% over the previous quarter' can be ambiguous in isolation about which company or which quarter is meant, and an embedding or keyword index built from that bare fragment ends up representing that ambiguity rather than the specific fact the source document actually intended; Anthropic's technique addresses this by having a model generate a short, chunk-specific blurb, such as naming the company and filing period, and prepending it to the chunk before embedding it for dense search and before adding it to the keyword index, so both retrieval methods see the disambiguated version rather than the bare fragment. The claim about a hard minimum embedding-model input length is not the motivation here; embedding models can generally process short chunks without needing to be padded up to some minimum size, and Anthropic's technique targets ambiguity in meaning, not an input-length constraint. The generated context does not replace the original chunk text; it is prepended alongside the chunk's own content specifically so the chunk's original information remains present together with the added disambiguating context. And the generated context is not merely a human-facing quality-assurance note that gets stripped out before indexing; it is deliberately kept in what gets embedded and keyword-indexed, since that is precisely the mechanism by which it improves retrieval.
Source: Anthropic, 'Introducing Contextual Retrieval,' https://www.anthropic.com/engineering/contextual-retrieval