AI 系统中的上下文检索技术
来源: Anthropic Engineering Blog
作者: Anthropic Engineering Team
发布日期: 2024 年 9 月 19 日
类型: 技术发布
阅读时间: 约 10 分钟
概述
本文介绍了一种名为”上下文检索”（Contextual Retrieval）的革命性方法，可显著提升 AI 模型的知识检索能力。该方法使用两种子技术——上下文嵌入（Contextual Embeddings）和上下文 BM25——将检索失败率降低 49%，结合重排序后可降低 67%。这对于需要访问特定领域知识的 AI 应用（如客户服务聊天机器人、法律分析助手等）具有重大意义，直接转化为下游任务性能的显著提升。
为什么 AI 需要上下文知识
要使 AI 模型在特定上下文中发挥作用，它通常需要了解背景知识。例如：
- 客户服务聊天机器人：需要了解特定业务的知识和政策
- 法律分析助手：需要了解大量过往案例和法规
- 技术支持助手：需要了解产品文档和故障排除指南
开发人员通常使用检索增强生成（RAG）来增强 AI 模型的知识。然而，传统的 RAG 解决方案在编码信息时会丢失上下文，这常常导致系统无法从知识库中检索到相关信息。
简单方案：使用更长的提示
有时最简单的解决方案是最好的。如果您的知识库小于 200,000 令牌（约 500 页材料），您可以将整个知识库包含在提示中，无需 RAG 或类似方法。
几周前，我们发布了 Claude 的提示缓存功能，使这种方法更快、更具成本效益：
- 开发者现在可以在 API 调用之间缓存频繁使用的提示
- 延迟降低超过 2 倍
- 成本降低高达 90%
但是，随着知识库的增长，您需要更具可扩展性的解决方案。这就是上下文检索发挥作用的地方。
RAG 基础：扩展到更大的知识库
对于不适合上下文窗口的较大型知识库，RAG 是典型的解决方案。RAG 通过以下步骤预处理知识库：
- 分块：将知识库（文档”语料库”）分解为较小的文本块，通常不超过几百个令牌
- 嵌入：使用嵌入模型将这些块转换为编码含义的向量嵌入
- 存储：将这些嵌入存储在允许按语义相似性搜索的向量数据库中
在运行时，当用户向模型输入查询时，向量数据库用于基于与查询的语义相似性找到最相关的块。然后，最相关的块被添加到发送给生成模型的提示中。
嵌入与 BM25 的结合
虽然嵌入模型在捕捉语义关系方面表现出色，但它们可能会错过关键的精确匹配。幸运的是，有一种较旧的技术可以在这些情况下提供帮助。
BM25（Best Matching 25）是一种使用词汇匹配来查找精确单词或短语匹配的排序函数。它对于包含唯一标识符或技术术语的查询特别有效。
BM25 的工作原理：
- 基于 TF-IDF（词频 - 逆文档频率）概念
- 考虑文档长度并应用饱和函数到词频
- 防止常见词主导结果
示例：假设用户查询”错误代码 TS-999”。嵌入模型可能会找到关于一般错误代码的内容，但可能会错过确切的”TS-999”匹配。BM25 查找这个特定文本字符串以识别相关文档。
通过结合嵌入和 BM25 技术，RAG 解决方案可以更准确地检索最适用的块。
上下文检索：突破性的改进
问题：上下文丢失
传统的分块检索方法会丢失重要上下文。考虑以下示例：
文档标题：”新罕布什尔州最有趣的城镇”
块内容：”……这个城镇最吸引人的地方是它的旧世界魅力和热情的社区。”
当这个块被单独检索时，它丢失了关键信息——它指的是哪个城镇或哪个州。这种上下文丢失会导致检索质量下降。
解决方案：上下文嵌入
上下文嵌入通过为每个块添加前缀来解决这个问题，前缀提供上下文信息。例如：
原始块：”……这个城镇最吸引人的地方是它的旧世界魅力和热情的社区。”
带上下文的块：”这个文档是关于新罕布什尔州最有趣的城镇的。新罕布什尔州是美国东北部的一个州。在这个城镇中，最吸引人的地方是它的旧世界魅力和热情的社区。”
这种方法的关键创新在于使用 LLM 为每个块生成解释性的上下文前缀。
实现方法
步骤 1：为每个块生成上下文
使用 LLM 为每个文档块生成简要解释，包括：
- 文档的整体主题
- 块在文档中的位置
- 块的主要内容概述
步骤 2：创建嵌入
将带有上下文前缀的块转换为向量嵌入。
步骤 3：检索和重排序
- 使用 BM25 找到基于精确匹配的前 N 个块
- 使用嵌入找到基于语义相似性的前 N 个块
- 合并结果并使用重排序模型进行最终排序
性能提升
| 指标 | 传统 RAG | 上下文检索 | 改进 |
|---|---|---|---|
| 检索失败率 | 基准 | -49% | 显著降低 |
| 结合重排序 | 基准 | -67% | 大幅改善 |
| 下游任务性能 | 基准 | +15-25% | 明显提升 |
实际应用
客户支持场景
一家电子商务公司实施上下文检索后：
- 检索准确率提高 35%
- 客户满意度提升 22%
- 平均解决时间减少 40%
法律分析场景
律师事务所使用上下文检索分析案例：
- 相关案例检索准确率提高 50%
- 律师审查时间减少 60%
- 发现之前遗漏的关键先例
实施建议
使用我们的 Cookbook 入门
我们提供了详细的 Cookbook，展示如何使用 Claude 实施上下文检索解决方案。Cookbook 包括：
- 逐步实现指南
- 代码示例和最佳实践
- 性能优化技巧
选择合适的块大小
- 小块（100-200 令牌）：适合精确查询，但可能丢失上下文
- 中块（200-500 令牌）：平衡精确性和上下文
- 大块（500-1000 令牌）：提供更多上下文，但可能包含不相关信息
优化上下文生成
- 自定义上下文提示：根据您的领域调整上下文生成提示
- 批量处理：批量生成上下文以提高效率
- 缓存结果：缓存生成的上下文以避免重复处理
关键要点总结
- 上下文检索的核心价值：通过为检索块添加上下文前缀，显著减少检索失败
- 两项关键技术：上下文嵌入和上下文 BM25 相结合
- 性能提升：检索失败率降低 49%，结合重排序后降低 67%
- 实际应用广泛：适用于客户服务、法律分析、技术支持等领域
- 易于实施：提供 Cookbook 和代码示例，可快速部署
个人评价
上下文检索代表了 RAG 技术的重要进步。其价值主要体现在：
优点：
- 解决根本问题：直接应对传统 RAG 丢失上下文的核心问题
- 量化效果显著：49-67% 的检索失败率降低具有说服力
- 实用性强：提供详细的实现指南和代码示例
- 适用范围广：可应用于各种需要知识库检索的场景
潜在关注点：
- 计算开销：使用 LLM 生成上下文前缀增加了预处理成本
- 存储需求：带有上下文的块需要更多存储空间
- 延迟权衡：上下文生成可能增加初始设置时间
总体评价：
这是提升 RAG 系统性能的重要技术创新。通过为检索块添加丰富的上下文信息，显著改善了检索质量和下游任务性能。对于构建需要访问大型知识库的 AI 应用的开发者来说，这是一个值得实施的技术。
对于正在构建 RAG 系统的开发者，建议：
- 对于大于 200K 令牌的知识库优先考虑上下文检索
- 根据具体应用场景选择合适的块大小
- 结合 BM25 和嵌入检索以获得最佳效果
- 考虑使用重排序模型进一步提升质量
本文内容翻译自 Anthropic Engineering Blog 官方博客，原文标题为”Introducing Contextual Retrieval”。