Contextual Retrieval：让 RAG 更懂上下文
原文：Introducing Contextual Retrieval | Anthropic | 2024.9.19
导语
RAG（检索增强生成）已经是 LLM 应用的标配。但传统的 RAG 有一个根本性缺陷：在切分文本块时会丢失上下文。
一个文本块说"该公司收入较上一季度增长了 3%"——但它没说是哪家公司、哪个季度。这导致检索系统在面对精确查询时经常"找不到"相关信息。
Anthropic 提出了 Contextual Retrieval，通过在每个文本块前面添加上下文解释，将检索失败率降低了 49%，结合重排序甚至可降低 67%。
一、传统 RAG 的问题
传统 RAG 的预处理流程：
- 将文档分解为小块（通常几百个 token）
- 用嵌入模型将块转换为向量
- 存储到向量数据库中
问题所在： 切分后，单个块缺乏足够的上下文。
比如财务报告中的一段话：
原始块："该公司收入较上一季度增长了 3%。"
这个块本身不说明是哪家公司或时间段，导致无法精确检索。
二、Contextual Retrieval 的解决方案
在嵌入之前，在每个块前面添加块特定的解释性上下文：
上下文化的块："此块来自 ACME Corp 2023 年第二季度业绩的 SEC 文件；
上一季度的收入为 3.14 亿美元。该公司收入较上一季度增长了 3%。"
具体做法
使用 Claude 为每个块自动生成上下文：
<document>
{{WHOLE_DOCUMENT}}
</document>
这是我们希望置于整个文档上下文中的块
<chunk>
{{CHUNK_CONTENT}}
</chunk>
请提供一个简短的上下文，以便将该块置于整个文档中，
以便改进块的搜索检索。仅回答简短的上下文，不要回答其他任何内容。
生成的上下文通常为 50-100 个 token。
成本控制
使用 Anthropic 的提示缓存功能，文档只需加载到缓存中一次。生成上下文块的一次性成本约为每百万文档 token 1.02 美元。
三、两个子技术
上下文嵌入（Contextual Embeddings）
在嵌入之前添加上下文，让向量更准确地表示块的语义。
上下文 BM25（Contextual BM25）
BM25 是基于词法匹配的排名函数，特别擅长精确匹配（如"错误代码 TS-999"）。添加上下文后，BM25 的匹配能力大幅提升。
四、性能提升
| 方法 | 检索失败率降低 |
|---|---|
| 上下文嵌入 | 35% |
| 上下文嵌入 + 上下文 BM25 | 49% |
| 上下文嵌入 + 上下文 BM25 + 重排序 | 67% |
五、重排序进一步提升
在检索后添加重排序步骤：
- 初始检索获取前 150 个候选块
- 使用重排序模型（如 Cohere Reranker）评估每个块的相关性
- 选择前 20 个最相关的块
六、关键发现总结
- 嵌入 + BM25 优于单独使用嵌入
- Voyage 和 Gemini 嵌入模型表现最好
- 传递前 20 个块比前 10 或前 5 个更有效
- 向块添加上下文大幅提高检索准确性
- 重排序比不重排序更好
- 所有好处都是叠加的
七、小提示：何时不需要 RAG
如果你的知识库少于 200,000 个 token（约 500 页），可以直接将整个知识库放入提示中。配合提示缓存，延迟降低 2 倍，成本降低 90%。
读后感
Contextual Retrieval 的思路非常优雅：不是改模型，不是改算法，而是改数据。通过在预处理阶段投入小成本为每个块添加上下文，获得了巨大的检索质量提升。
这再次印证了一个 AI 工程的基本原则：数据质量 > 算法复杂度。
本文是 Anthropic AI Agent 系列 第 8 篇，共 15 篇。下一篇：长时间运行的 Agent：如何设计可靠的执行框架
关注公众号 coft 获取系列更新。