上下文检索（Contextual Retrieval）¶
原文发布于 2024 年 9 月 19 日，作者 Daniel Ford
引言¶
传统 RAG 在分块编码时丢失了上下文信息，"上下文检索"通过为每个块补充解释性上下文，将检索失败率最高降低了 67%。 AI 模型在特定场景中往往需要领域知识才能真正发挥作用——客服机器人需要业务知识，法律分析工具需要了解过往案例。
开发者通常使用检索增强生成（RAG）来扩展 AI 的知识面。然而，传统 RAG 在信息编码过程中会丢失上下文，导致检索失败。
本文介绍的方法叫做"上下文检索"（Contextual Retrieval），包含两个子技术：上下文嵌入（Contextual Embeddings） 和 上下文 BM25（Contextual BM25）。实验结果表明：
| 方法组合 | 检索失败率降低 |
|---|---|
| 上下文嵌入 + 上下文 BM25 | 49% |
| 上下文嵌入 + 上下文 BM25 + 重排序 | 67% |
Cookbook 参考：Contextual Embeddings Guide
关于"直接把所有内容塞进 Prompt"¶
如果知识库小于 200,000 token（约 500 页），可以直接将全部内容放入 prompt。 Anthropic 的 prompt 缓存功能可以将延迟降低 2 倍以上，成本降低最多 90%。
只有当知识库规模超出 prompt 窗口时，才需要用到 RAG。
RAG 基础：扩展到大规模知识库¶
RAG 的核心思路是"先检索、再生成"——从海量知识中找到相关片段，注入 prompt 后再让模型回答。 RAG 的预处理流程如下：
- 将知识库拆分为较小的文本块（通常不超过几百 token）
- 用嵌入模型将文本块转换为向量表示
- 将向量存入向量数据库，用于语义相似度搜索
运行时，向量数据库根据查询的语义相似度检索相关文本块。
BM25（Best Matching 25）¶
BM25 通过词汇精确匹配弥补了语义搜索的不足。 BM25 基于 TF-IDF（词频-逆文档频率），衡量一个词对文档的重要程度。BM25 在此基础上进一步考虑了文档长度，并对词频施加饱和函数。
典型场景： 查询 "Error code TS-999" 时，嵌入模型可能检索到泛泛的错误码相关内容，但漏掉了精确匹配的那段文字。BM25 可以直接匹配到包含这个特定字符串的文本块。
完整的 RAG 流程（结合嵌入 + BM25）¶
| 步骤 | 操作 |
|---|---|
| 1 | 将知识库拆分为文本块 |
| 2 | 分别创建 TF-IDF 编码和语义嵌入向量 |
| 3 | 用 BM25 检索精确匹配的 top 文本块 |
| 4 | 用嵌入向量检索语义相似的 top 文本块 |
| 5 | 合并去重（使用 rank fusion 技术） |
| 6 | 将 top-K 文本块注入 prompt 生成回答 |
传统 RAG 的上下文困境¶
文档被拆分成小块后，每个块往往缺少足够的上下文信息来正确检索。 举个例子：你在查 "ACME 公司 2023 年 Q2 的营收增长"，检索到一个块写着"该公司营收较上季度增长了 3%"——但块内既没说是哪家公司，也没说是哪个季度。这就是传统 RAG 的核心痛点。
上下文检索的核心方法¶
核心思路：在嵌入和建索引之前，为每个文本块前置一段解释性的上下文描述。 这样，每个块在被检索时都携带了充足的背景信息。
块转换示例¶
original_chunk = "The company's revenue grew by 3% over the previous quarter."
contextualized_chunk = "This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter."
业界此前也有一些尝试（效果有限）：添加通用文档摘要、假设性文档嵌入（HyDE）、基于摘要的索引等。上下文检索的区别在于它为每个块生成针对性的上下文。
实现方式¶
使用 Claude 3 Haiku 为每个块生成上下文，prompt 如下：
<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.
生成的上下文通常为 50-100 token，被前置到原始块的内容之前，然后再进行嵌入和 BM25 索引。
利用 Prompt 缓存降低成本¶
通过 prompt 缓存，整篇文档只需加载到缓存一次，后续每个块的上下文生成都可以复用。 假设每个块 800 token、文档 8000 token、上下文指令 50 token、生成的上下文 100 token，整体成本约为每百万文档 token 花费 $1.02（一次性成本）。
测试方法¶
跨多种数据集进行测试：代码库、小说、ArXiv 论文、科学论文。评估了多种嵌入模型和检索策略。
| 维度 | 详情 |
|---|---|
| 数据集 | 代码库、小说、ArXiv 论文、Science 论文 |
| 最佳嵌入模型 | Gemini Text 004 |
| 评估指标 | 1 - recall@20（即 top-20 块中检索失败的文档百分比） |
性能提升¶
| 方法 | 检索失败率 | 相对降低 |
|---|---|---|
| 传统嵌入（基线） | 5.7% | — |
| 上下文嵌入 | 3.7% | 35% |
| 上下文嵌入 + 上下文 BM25 | 2.9% | 49% |
实现时的注意事项¶
| 考量因素 | 说明 |
|---|---|
| 分块策略 | 块大小、边界划分、重叠区域的选择都会影响性能 |
| 嵌入模型 | Gemini 和 Voyage 的嵌入效果最佳 |
| 定制化 Prompt | 针对特定领域定制上下文生成 prompt 可能进一步提升效果（例如附带术语表） |
| 检索块数量 | 20 个块效果最好（测试了 5、10、20），但信息过多可能干扰模型 |
通过重排序进一步提升性能¶
重排序（Reranking）在初步检索之后，用专门的模型对候选块进行精细打分，只保留最相关的内容。 步骤如下：
- 初步检索得到较多候选块（top 150）
- 将候选块和用户查询一起送入重排序模型
- 模型为每个块打相关性分数，选出 top-K（实验中取 top 20）
- 将筛选后的 top-K 块注入 prompt 生成最终回答
重排序的性能表现¶
测试使用了 Cohere 重排序模型（Voyage 也提供了重排序器，但未纳入测试）。
| 方法 | 检索失败率 | 相对基线降低 |
|---|---|---|
| 传统嵌入（基线） | 5.7% | — |
| 上下文嵌入 + 上下文 BM25 | 2.9% | 49% |
| 重排序 + 上下文嵌入 + 上下文 BM25 | 1.9% | 67% |
成本和延迟的权衡¶
重排序会增加延迟（但各块的打分可以并行进行）。核心权衡是：重排序的候选块越多，效果越好，但延迟和成本也越高。
结论：各技术的叠加效果¶
所有优化手段可以叠加使用——上下文嵌入、上下文 BM25、重排序、合理的块数量——组合后性能最大化。
核心发现：
| # | 结论 |
|---|---|
| 1 | 嵌入 + BM25 优于单独使用嵌入 |
| 2 | Voyage 和 Gemini 是测试中最好的嵌入模型 |
| 3 | 检索 top-20 块比 top-10 或 top-5 更有效 |
| 4 | 为文本块添加上下文显著提升检索准确率 |
| 5 | 使用重排序优于不使用 |
| 6 | 所有优化可叠加： 上下文嵌入（Voyage/Gemini）+ 上下文 BM25 + 重排序 + 20 个块 = 最佳性能 |
附录 I¶
各数据集、嵌入模型、BM25 使用、上下文检索、重排序组合下的详细实验结果（Retrievals @20）：
附录 II（PDF）：Contextual Retrieval Appendix 2
致谢¶
研究和撰写：Daniel Ford。感谢 Orowa Sikder、Gautam Mittal、Kenneth Lien、Samuel Flamini、Lauren Polansky、Alex Albert、Susan Payne、Stuart Ritchie 和 Brad Abrams。