Contextual Retrieval：让 RAG 更懂上下文

Contextual Retrieval：让 RAG 更懂上下文

原文：Introducing Contextual Retrieval | Anthropic | 2024.9.19

导语

RAG（检索增强生成）已经是 LLM 应用的标配。但传统的 RAG 有一个根本性缺陷：在切分文本块时会丢失上下文。

一个文本块说"该公司收入较上一季度增长了 3%"——但它没说是哪家公司、哪个季度。这导致检索系统在面对精确查询时经常"找不到"相关信息。

Anthropic 提出了 Contextual Retrieval，通过在每个文本块前面添加上下文解释，将检索失败率降低了 49%，结合重排序甚至可降低 67%。

---

一、传统 RAG 的问题

传统 RAG 的预处理流程：

1. 将文档分解为小块（通常几百个 token）
2. 用嵌入模型将块转换为向量
3. 存储到向量数据库中

问题所在： 切分后，单个块缺乏足够的上下文。

比如财务报告中的一段话：

原始块："该公司收入较上一季度增长了 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%

---

五、重排序进一步提升

在检索后添加重排序步骤：

1. 初始检索获取前 150 个候选块
2. 使用重排序模型（如 Cohere Reranker）评估每个块的相关性
3. 选择前 20 个最相关的块

---

六、关键发现总结

1. 嵌入 + BM25 优于单独使用嵌入
2. Voyage 和 Gemini 嵌入模型表现最好
3. 传递前 20 个块比前 10 或前 5 个更有效
4. 向块添加上下文大幅提高检索准确性
5. 重排序比不重排序更好
6. 所有好处都是叠加的

---

七、小提示：何时不需要 RAG

如果你的知识库少于 200,000 个 token（约 500 页），可以直接将整个知识库放入提示中。配合提示缓存，延迟降低 2 倍，成本降低 90%。

---

读后感

Contextual Retrieval 的思路非常优雅：不是改模型，不是改算法，而是改数据。通过在预处理阶段投入小成本为每个块添加上下文，获得了巨大的检索质量提升。

这再次印证了一个 AI 工程的基本原则：数据质量 > 算法复杂度。

---

本文是 Anthropic AI Agent 系列 第 8 篇，共 15 篇。下一篇：长时间运行的 Agent：如何设计可靠的执行框架

关注公众号 coft 获取系列更新。