· RAG · HTML
Contextual Retrieval - 上下文检索：将 RAG 检索失败率降低 67%
Anthropic 提出的 Contextual Retrieval 方法，通过上下文增强与 BM25 混合检索，将 RAG 检索失败率降低 67%。
研究背景
2024 年 9 月，Anthropic 发布了一项影响深远的 RAG 改进方案，解决了传统检索增强生成中最根本的问题：上下文丢失。
在传统 RAG 中，文档被拆分为小块以便高效检索。但这一过程移除了关键的上下文信息：一个文本块可能写着"公司本季度收入增长了 3%"，却无法说明是哪家公司、哪个季度。这让检索系统难以匹配查询，也让模型难以有效利用检索到的信息。
Contextual Retrieval 的核心理念简单而强大：在嵌入之前，用 Claude 为每个文本块自动生成一段简短的上下文解释（50-100 token），说明该块在整个文档中的位置和背景。然后将这段上下文前置到原始文本块中，再进行嵌入和 BM25 索引。
传统 RAG 的上下文难题
当文本块脱离上下文后，检索系统在以下场景中频繁失败。
隐式引用
"The company's revenue grew by 3%" — 不知道是哪个公司、哪个时间段。
数据无来源标注
财务数据块没有说明来自哪份 SEC 申报文件、哪个财年。
跨文档引用断裂
术语在文档 A 中定义，但检索到的块在文档 B 中引用了该术语。
代码片段无项目上下文
一段函数定义不知属于哪个模块、哪个项目、哪个版本。
学术论文切片丢失
方法部分的文本块脱离了摘要和结论的背景信息。
小说场景割裂
角色对话块不知道当前是第几章、在哪个场景中发生。
文本块变化：前后对比
上下文检索的核心操作：为每个文本块自动生成解释性前缀。
图：Claude 如何为每个文本块自动生成上下文，将隐式引用变为显式信息
预处理流程
上下文检索在索引阶段的一次性预处理管道。
图：上下文检索的五步预处理管道 — 从文档分块到排序融合，实现 49% 的检索失败率降低
核心机制详解
上下文检索 = 上下文嵌入 + 上下文 BM25，两者叠加效果最佳。
上下文嵌入
为每个文本块添加 Claude 生成的 50-100 token 上下文前缀后，再进行语义嵌入。使得嵌入向量携带了完整的文档背景信息。
上下文 BM25
同样的上下文化文本块用于构建 TF-IDF 索引。BM25 现在可以精确匹配上下文中的公司名、日期和标识符。
排序融合
将语义嵌入和词汇 BM25 的检索结果通过 rank fusion 技术合并去重，兼顾语义理解和精确匹配。
Prompt Caching
文档加载到缓存后，所有文本块共享缓存引用。每百万文档 token 的上下文生成成本仅 $1.02。
关键洞察：其他方法（文档摘要、假设性文档嵌入、摘要索引）的实验效果都远不如上下文检索。核心区别在于：上下文是针对每个块定制的，而不是泛化的全文摘要。
上下文生成提示词
使用 Claude 3 Haiku 为每个文本块生成上下文的提示词模板。
生成的上下文文本通常 50-100 token。前置到原始文本块后，一起送入嵌入模型和 BM25 索引。完整示例见 官方 Cookbook。
重排序增强
在上下文检索之上叠加 Reranking，将失败率进一步降低到 1.9%。
图：Contextual Retrieval + Reranking 的完整检索管道，最终将检索失败率降至 1.9%
性能对比
跨多个知识领域（代码库、小说、ArXiv 论文、科学论文）的平均性能数据。
| 方法 | Top-20 失败率 | 相对改善 | 累计改善 |
|---|---|---|---|
| 传统 RAG（仅语义嵌入） | 5.7% | 基线 | - |
| + 上下文嵌入 | 3.7% | -35% | -35% |
| + 上下文嵌入 + 上下文 BM25 | 2.9% | -23% | -49% |
| + 上下文嵌入 + 上下文 BM25 + 重排序 | 1.9% | -35% | -67% |
图：检索失败率逐步降低的可视化对比
六项关键发现
1. 嵌入 + BM25 优于单独嵌入
语义理解 + 精确词汇匹配的组合，在任何数据集上都比单独使用嵌入更有效。
2. Voyage 和 Gemini 嵌入最佳
在所有测试的嵌入模型中，Voyage 和 Google Gemini Text 004 表现最好。
3. Top-20 比 Top-5/10 更有效
传递 20 个文本块比 5 或 10 个更有效。更多信息虽可能分散注意力，但上限在 20 块。
4. 添加上下文大幅提升检索
这是最显著的单一改进。上下文嵌入单独就能将失败率降低 35%。
5. 重排序优于不重排序
在所有实验中，添加重排序步骤都带来了额外的性能提升。
6. 所有好处可叠加
上下文嵌入 + 上下文 BM25 + 重排序 + 20 块 = 最佳结果。各项改进互不冲突。
实现注意事项
文本块边界策略
块大小、边界和重叠度的选择会影响检索性能。需要根据文档类型进行实验调优。
嵌入模型选择
上下文检索对所有嵌入模型都有改善，但 Voyage 和 Gemini 效果最佳。建议测试多个模型。
自定义上下文提示词
通用提示词效果不错，但针对特定领域定制（如加入术语表）可以获得更好结果。
始终运行评估
在上下文化块和原始块之间，对生成响应进行对比评估，确认改进确实转化为下游提升。
优势与局限
核心优势
- 检索失败率降低 49%（叠加 reranking 达 67%）
- 一次性预处理成本极低（$1.02/百万文档 token）
- 方法简单，不改变运行时查询流程
- 对所有嵌入模型和数据集都有效
- 可与现有 RAG 系统无缝集成
- 开源 Cookbook，立即上手使用
- 同时增强语义检索和词汇检索
- 基于成熟的 Claude API，生产可用
局限与注意事项
- 需要为每个文本块调用 LLM（虽然成本低）
- 上下文质量取决于 Claude 的理解能力
- 依赖 Anthropic API 的 Prompt Caching 来降低成本
- 重排序增加运行时延迟（需要权衡）
- 不适用于实时动态文档（需要重新生成上下文）
- 块边界策略需要针对具体用例调优
- 小知识库（<200K token）直接用完整文档更简单
- 实验主要在英文文档上进行
多维度评估
图：五维评分 — 性能提升和成本效益是突出优势
常见问题
Q: 上下文检索需要改动现有的 RAG 系统吗？
A: 不需要改动运行时查询流程。上下文检索是纯预处理步骤 — 只需在索引阶段为每个文本块添加上下文前缀，然后按正常流程嵌入和索引。查询时完全透明。
Q: 上下文生成的 token 成本有多高？
A: 借助 Prompt Caching，每百万文档 token 仅需 $1.02。这包括使用 Claude 3 Haiku 生成上下文的一次性费用。对于大多数知识库，总成本在几美元以内。
Q: 如果知识库很小（<200K token），还需要上下文检索吗？
A: 不需要。如果整个知识库能放入上下文窗口，直接把所有文档放到提示词里是最简单有效的方案。配合 Prompt Caching 可以进一步降低成本。上下文检索是为超出上下文窗口的大型知识库设计的。
Q: 上下文检索支持多语言吗？
A: 研究主要基于英文文档。Claude 的多语言能力意味着上下文生成在理论上适用于所有支持的语言，但性能数据尚未在多语言基准上验证。
Q: 除了 Claude，可以用其他模型生成上下文吗？
A: 可以使用其他 LLM，但 Anthropic 的方法是围绕 Claude 的 Prompt Caching 优势设计的 — 这是实现 $1.02/百万 token 低成本的关键。其他模型可能没有类似功能。
Q: 文档更新后需要重新生成上下文吗？
A: 是的。如果文档发生实质性变更，受影响的文本块需要重新生成上下文并重新索引。这对于静态知识库不是问题，但对于频繁更新的动态文档需要考虑增量更新策略。
快速开始
Anthropic 提供了完整的 Cookbook，包含代码示例和最佳实践。
