30 秒快速回答：Contextual Retrieval（上下文检索）是 Anthropic 提出的 RAG 优化技术——在向量化之前，先用 LLM 给每个文本块生成一段「上下文描述」（它来自哪份文档、讲的是什么），再把「描述 + 原文」一起嵌入向量库。这样每个片段不再是孤立的字符串，而是带着语境的语义单元，检索时更容易被用户问题命中。核心价值：不用换模型、不用改架构，只靠一条预处理流程就能让 RAG 检索失败率平均降低 35%，配合混合检索 + 重排序最高达 49%，是目前性价比最高的检索质量提升手段。
一、为什么要给文本块加上下文？
RAG（检索增强生成）的经典流程是：把文档切块（chunk）→ 向量化 → 存入向量库 → 查询时检索 Top-K → 交给大模型生成答案。
问题出在「切块」这一步。一个 chunk 被硬生生从原文里切出来后，常常丢失了语境。比如下面这句：
第 4 季度环比增长 12%，超出预期。
单独嵌入这条文本时，模型并不知道「这说的是哪家公司、哪个指标、出自哪份财报」。当用户问「苹果上一季度营收表现如何」时，这条 chunk 的向量距离可能匹配不上，检索召回就失败了——再强的生成模型也救不回来。
这正是 2026 年 RAG 实践反复遇到的「嵌入式失忆」问题：切块切断了语义上下文，向量化保留了字面却丢了出处。
二、Contextual Retrieval 的原理
Anthropic 的解法非常直观：在嵌入之前，先让 LLM 为每个 chunk 生成一小段上下文描述，然后把「描述 + 原文」拼接后一起嵌入。
官方建议的 Prompt 模板（要点）：
<document>（整份文档原文）</document>
这里是上述文档中的文本块，请给出简短的上下文描述：
指出这段文本的主题、说话人、前文关系等关键信息，
控制在 50-100 个词内，并保留关键实体与数字。
<chunk>（当前文本块）</chunk>
处理流程变成：
文档 → 切块 → LLM 生成每块上下文描述 → 拼接描述+chunk → 嵌入 → 存入向量库
检索阶段完全不变：用户问题 → 向量化 → Top-K 检索 → 生成。改变的只是入库前的数据形态——每一条向量现在都携带了「出处 + 主题 + 邻近内容」三重语境。
官方实测：Contextual Retrieval 让 Top-20 检索失败率降低 35%；再叠加混合检索（向量 + BM25）与重排序（Reranker），失败率总计降低 49%。
三、实用代码示例
以下是基于 Anthropic 官方思路的 Python 实现（伪代码级别可直接改造）：
import anthropic
client = anthropic.Anthropic()
def contextualize_chunk(document: str, chunk: str) -> str:
"""为单个文本块生成上下文描述并拼接"""
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=300,
messages=[{
"role": "user",
"content": f"""<document>{document}</document>
这里是上述文档中的文本块，请用 50-100 个词给出
简短上下文描述（主题、说话人、与前文关系，保留关键实体数字）：
<chunk>{chunk}</chunk>"""
}]
)
context = resp.content[0].text
return f"{context}\n\n{chunk}" # 描述 + 原文一起嵌入
# 批量处理：对每个 chunk 生成上下文后写入向量库
for chunk in chunks:
contextual_chunk = contextualize_chunk(document, chunk)
vector_store.add(embed(contextual_chunk))
生产环境三条优化建议：
- 用 Prompt Caching：整份 document 是重复前缀，缓存后上下文生成的 token 成本可下降约 90%；
- 分层生成：只对「与 query 相关性不确定」的中等 chunk 生成上下文，高价值与低价值块跳过，控制成本；
- 必须叠加混合检索 + 重排：Contextual Retrieval 与 Reranker 是乘法关系，叠加后提升最大。
四、对比与选型：什么时候该用？
| 维度 | 朴素 RAG | Contextual Retrieval | + 混合检索 & 重排 |
|---|---|---|---|
| 检索失败率（Top-20） | 基线 | 降 35% | 降 49% |
| 额外成本 | 无 | token 成本约翻倍（可缓存缓解） | 再加重排计算 |
| 实现难度 | 低 | 中（一条预处理流水线） | 中高 |
| 适用场景 | 快速 Demo、短文档 | 长文档、多文档库、问答准确率敏感 | 生产级知识库系统 |
结论：文档很长、chunk 之间相互依赖（如财报、论文、合同）、检索召回明显不准的场景，Contextual Retrieval 是第一优先级的低成本改造；如果只是几十页的短文档、查询命中率已经很高，则没必要为它付出翻倍 token 成本。
总结与延伸阅读
要点回顾：
- RAG 检索失败的根源之一是「切块切断语境」，Contextual Retrieval 用 LLM 生成上下文描述补齐语境；
- 实现只需在入库前加一道「描述 + 原文」预处理，检索链路零改动；
- 官方数据：检索失败率降 35%，叠加混合检索 + 重排最高降 49%；
- 成本可接受：配合 Prompt Caching 与分层生成，能把 token 开销控制在合理范围。
延伸阅读建议：
- 本系列《什么是混合检索与重排序？》了解与它配合的检索链路；
- 本系列《什么是 Agentic RAG？》学习检索之上的自主决策；
- Anthropic 官方博客《Introducing Contextual Retrieval》与 Anthropic Cookbook 的完整代码仓库。