介绍上下文检索

# AI 系统中的上下文检索 来源：https://www.anthropic.com/engineering/contextual-retrieval 要使 AI 模型在特定场景中发挥作用，通常需要获取背景知识。例如，客户支持聊天机器人需要了解其服务的具体业务，法律分析机器人则需要掌握大量过往案例。开发者通常使用检索增强生成（RAG）来增强 AI 模型的知识。RAG 是一种从知识库中检索相关信息并将其附加到用户提示中的方法，能显著提升模型的回答质量。 问题在于，传统的 RAG 解决方案在对信息进行编码时会丢失上下文，这往往导致系统无法从知识库中检索到相关信息。本文介绍了一种能够显著改进 RAG 中检索步骤的方法，称为“上下文检索”，它使用了两种子技术：上下文嵌入（Contextual Embeddings）和上下文 BM25（Contextual BM25）。该方法可将检索失败次数减少 49%，若结合重排序（reranking），则可减少 67%。这些改进直接提升了检索精度，进而改善了下游任务的性能。你可以通过我们的 cookbook（https://platform.claude.com/cookbook/capabilities-contextual-embeddings-guide）轻松部署自己的上下文检索方案，搭配 Claude 使用。 ### 关于直接使用更长提示的说明 有时最简单的解决方案就是最好的。如果你的知识库小于 20 万 token（约 500 页材料），可以直接将整个知识库放入提供给模型的提示中，无需使用 RAG 或类似方法。几周前，我们为 Claude 发布了提示缓存（prompt caching）功能（https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching），这使得该方法变得更快、更经济。开发者现在可以在 API 调用之间缓存常用提示，将延迟降低 2 倍以上，成本降低高达 90%（你可以通过阅读我们的提示缓存 cookbook（https://platform.claude.com/cookbook/misc-prompt-caching）了解其工作原理）。然而，随着知识库的扩大，你需要一个更具可扩展性的解决方案，这就是上下文检索的用武之地。 ## RAG 入门：扩展到更大的知识库 对于无法放入上下文窗口的大型知识库，RAG 是典型的解决方案。RAG 通过以下步骤预处理知识库： 1. 将知识库（文档“语料库”）分解成较小的文本块，通常不超过几百个 token； 2. 使用嵌入模型将这些文本块转换为编码语义的向量嵌入； 3. 将这些嵌入存储在支持语义相似性搜索的向量数据库中。 在运行时，当用户向模型输入查询时，向量数据库会根据与查询的语义相似性找到最相关的文本块。然后，将这些最相关的文本块添加到发送给生成模型的提示中。 虽然嵌入模型擅长捕捉语义关系，但可能会漏掉关键的确切匹配。幸运的是，有一种较老的技术可以在这种情况下提供帮助。BM25（最佳匹配 25）是一种使用词汇匹配来查找精确单词或短语匹配的排序函数。它对于包含唯一标识符或技术术语的查询特别有效。BM25 建立在 TF-IDF（词频-逆文档频率）概念之上。TF-IDF 衡量一个词对整个文档集合中某个文档的重要性。BM25 通过考虑文档长度并对词频应用饱和函数来改进这一点，有助于防止常见词主导结果。 以下是 BM25 在语义嵌入可能失效时如何成功的一个例子：假设用户在技术支持数据库中查询“错误代码 TS-999”。嵌入模型可能找到关于错误代码的一般内容，但可能错过确切的“TS-999”匹配。BM25 则查找这个特定的文本字符串以识别相关文档。 通过结合嵌入和 BM25 技术，RAG 解决方案可以更准确地检索最适用的文本块，步骤如下： 1. 将知识库（文档“语料库”）分解成较小的文本块，通常不超过几百个 token； 2. 为这些文本块创建 TF-IDF 编码和语义嵌入； 3. 使用 BM25 基于精确匹配找到顶级文本块； 4. 使用嵌入基于语义相似性找到顶级文本块； 5. 使用排名融合技术对 (3) 和 (4) 的结果进行合并和去重； 6. 将前 K 个文本块添加到提示中以生成响应。 通过同时利用 BM25 和嵌入模型，传统 RAG 系统可以提供更全面、更准确的结果，平衡精确术语匹配与更广泛的语义理解。 一个标准的检索增强生成（RAG）系统，同时使用嵌入和最佳匹配 25（BM25）来检索信息。TF-IDF（词频-逆文档频率）衡量词的重要性，是 BM25 的基础。 这种方法使你可以经济高效地扩展到巨大的知识库，远远超过单个提示所能容纳的范围。但这些传统的 RAG 系统有一个显著的局限性：它们常常破坏上下文。 ### 传统 RAG 中的上下文难题 在传统 RAG 中，文档通常被分割成较小的文本块以便高效检索。虽然这种方法在许多应用中效果良好，但当单个文本块缺乏足够的上下文时，可能会导致问题。 例如，假设你的知识库中嵌入了财务信息集合（如美国证券交易委员会文件），并收到以下问题： *“ACME 公司在 2023 年第二季度的营收增长是多少？”* 一个相关的文本块可能包含以下文字： *“该公司营收较上一季度增长 3%。”* 然而，这个文本块本身没有指明涉及哪家公司或相关时间段，使得检索正确信息或有效使用信息变得困难。 ## 引入上下文检索 上下文检索通过在每个文本块嵌入前添加特定于该块的解释性上下文（“上下文嵌入”），以及在创建 BM25 索引时也添加上下文（“上下文 BM25”），来解决这个问题。 回到我们的证券交易委员会文件集合示例。以下是文本块可能如何转换的示例： 原始文本块： ``` "该公司营收较上一季度增长 3%。" ``` 添加上下文后的文本块： ``` "此文本块来自 ACME 公司 2023 年第二季度业绩的 SEC 文件；上一季度营收为 3.14 亿美元。该公司营收较上一季度增长 3%。" ``` 值得注意的是，过去也提出过其他使用上下文改进检索的方法。其他提议包括： - 向文本块添加通用文档摘要（https://aclanthology.org/W02-0405.pdf）（我们实验后发现收益非常有限） - 假设文档嵌入（https://arxiv.org/abs/2212.10496） - 基于摘要的索引（https://www.llamaindex.ai/blog/a-new-document-summary-index-for-llm-powered-qa-systems-9a32ece2f9ec）（我们评估后发现性能较低） 这些方法与本文提出的方法不同。 ### 实现上下文检索 当然，手动注释知识库中成千上万甚至数百万个文本块的工作量太大。为了实现上下文检索，我们求助于 Claude。我们编写了一个提示，指示模型提供简洁的、文本块特定的上下文，利用整个文档的上下文来解释该文本块。 我们使用了以下 Claude 3 Haiku 提示为每个文本块生成上下文： ``` {{WHOLE_DOCUMENT}} 这是我们要在整个文档中定位的文本块： {{CHUNK_CONTENT}} 请给出简短的上下文，以便将该文本块置于整个文档中，用于改进该文本块的搜索检索。仅回答简洁的上下文，不要其他内容。 ``` 生成的上下文文本通常为 50-100 token，在嵌入之前以及创建 BM25 索引之前，将其前置到文本块中。 以下是实际预处理流程的样子： *上下文检索是一种预处理技术，可提高检索的准确性。* 如果你对使用上下文检索感兴趣，可以从我们的 cookbook（https://platform.claude.com/cookbook/capabilities-contextual-embeddings-guide）开始。 ### 使用提示缓存降低上下文检索的成本 得益于我们上面提到的特殊提示缓存功能，使用 Claude 可以以低成本实现上下文检索。使用提示缓存，你无需为每个文本块传入参考文档。只需将文档加载到缓存中一次，然后引用之前缓存的内容即可。 假设每个文本块 800 token，每个文档 8k token，上下文指令 50 token，每个文本块的上下文 100 token，**生成上下文化文本块的一次性成本为每百万文档 token 1.02 美元**。 #### 方法 我们在多个知识领域（代码库、小说、ArXiv 论文、科学论文）、嵌入模型、检索策略和评估指标上进行了实验。我们在附录 II（https://assets.anthropic.com/m/1632cded0a125333/original/Contextual-Retrieval-Appendix-2.pdf）中包含了每个领域使用的问题和答案示例。下图显示了所有知识领域平均性能，使用了性能最佳的嵌入配置（Gemini Text 004）并检索 top-20 文本块。我们使用 1 减去 recall@20 作为评估指标，衡量在 top-20 文本块中未能检索到的相关文档百分比。你可以在附录中查看完整结果——在我们评估的每个嵌入-源组合中，添加上下文都提高了性能。 #### 性能提升 我们的实验表明： - **上下文嵌入使 top-20 文本块检索失败率降低了 35%**（5.7% → 3.7%）。 - **结合上下文嵌入和上下文 BM25 使 top-20 文本块检索失败率降低了 49%**（5.7% → 2.9%）。 *结合上下文嵌入和上下文 BM25 将 top-20 文本块检索失败率降低了 49%。* #### 实现注意事项 实现上下文检索时，需要注意以下几点： 1. **文本块边界：** 考虑如何将文档分割成文本块。文本块大小、文本块边界和文本块重叠的选择会影响检索性能。 2. **嵌入模型：** 虽然上下文检索在我们测试的所有嵌入模型上都提高了性能，但有些模型可能受益更多。我们发现 Gemini（https://ai.google.dev/gemini-api/docs/embeddings）和 Voyage（https://www.voyageai.com/）的嵌入特别有效。 3. **自定义上下文化提示：** 虽然我们提供的通用提示效果不错，但根据你的特定领域或用例定制的提示可能会获得更好的结果（例如，包含关键术语的词汇表，这些术语可能只在知识库的其他文档中定义）。 4. **文本块数量：** 向上下文窗口中添加更多文本块会增加包含相关信息的几率。然而，过多信息可能会干扰模型，因此存在一个限度。我们尝试了 5、10 和 20 个文本块，发现使用 20 个是这些选项中性能最好的（参见附录比较），但值得根据你的用例进行实验。 **始终运行评估：** 响应生成可能通过传递上下文化文本块并区分哪些是上下文、哪些是文本块来改进。 ## 使用重排序进一步提升性能 最后一步，我们可以将上下文检索与另一种技术结合，以获得更多性能提升。在传统 RAG 中，AI 系统搜索其知识库以找到可能相关的信息文本块。对于大型知识库，这种初始检索通常会返回大量文本块——有时多达几百个——它们相关性和重要性各不相同。重排序是一种常用的过滤技术，确保只有最相关的文本块被传递给模型。重排序能提供更好的响应，并降低成本和延迟，因为模型处理的信息更少。 关键步骤如下： 1. 执行初始检索，获取 top 可能相关文本块（我们使用了 top-150）； 2. 将 top-N 文本块连同用户查询一起传递给重排序模型； 3. 使用重排序模型，根据每个文本块与提示的相关性和重要性进行评分，然后选择 top-K 文本块（我们使用了 top-20）； 4. 将 top-K 文本块作为上下文传递给模型，生成最终结果。 *结合上下文检索和重排序以最大化检索准确率。* ### 性能提升 市场上有多种重排序模型。我们使用了 Cohere 重排序器（https://cohere.com/rerank）进行测试。Voyage 也提供重排序器（https://docs.voyageai.com/docs/reranker），但我们没有时间测试。我们的实验表明，在不同领域，添加重排序步骤进一步优化了检索。具体来说，我们发现重排序的上下文嵌入和上下文 BM25 将 top-20 文本块检索失败率降低了 67%（5.7% → 1.9%）。 *重排序的上下文嵌入和上下文 BM25 将 top-20 文本块检索失败率降低了 67%。* #### 成本和延迟考虑 重排序的一个重要考虑因素是对延迟和成本的影响，尤其是在重排序大量文本块时。由于重排序在运行时增加了一个额外步骤，即使重排序器并行对所有文本块进行评分，也难免会增加少量延迟。在重排序更多文本块以获得更好性能与重排序更少文本块以降低延迟和成本之间存在固有的权衡。我们建议针对你的特定用例尝试不同设置，以找到合适的平衡点。 ## 结论 我们进行了大量测试，比较了上述所有技术的不同组合（嵌入模型、是否使用 BM25、是否使用上下文检索、是否使用重排序以及检索的 top-K 结果总数），所有这些测试涵盖了多种不同的数据集类型。以下是我们发现的总结： 1. 嵌入 + BM25 优于单独使用嵌入； 2. 在我们测试的嵌入中，Voyage 和 Gemini 表现最佳； 3. 向模型传递 top-20 文本块比仅传递 top-10 或 top-5 更有效； 4. 向文本块添加上下文显著提高了检索准确性； 5. 有重排序优于无重排序； 6. **所有这些好处可以叠加**：为了最大化性能提升，我们可以将上下文嵌入（来自 Voyage 或 Gemini）与上下文 BM25 结合，再加上重排序步骤，并向提示中添加 20 个文本块。 我们鼓励所有从事知识库工作的开发者使用我们的 cookbook（https://platform.claude.com/cookbook/capabilities-contextual-embeddings-guide）尝试这些方法，以解锁新的性能水平。 ## 附录 I 以下是各数据集、嵌入提供商、是否在嵌入基础上使用 BM25、是否使用上下文检索以及是否使用重排序的 top-20 检索结果明细。请参阅附录 II（https://assets.anthropic.com/m/1632cded0a125333/original/Contextual-Retrieval-Appendix-2.pdf）了解 top-10 和 top-5 检索结果的明细，以及每个数据集的示例问题和答案。 *各数据集和嵌入提供商的 1 减去 recall@20 结果。* ## 致谢