Anthropic介绍Contextual Retrieval

人工智能模型要想在特定环境中发挥作用，往往需要获取背景知识。 例如，客户支持聊天机器人需要了解具体的业务，而法律分析机器人则需要了解大量的过往案例。

开发人员通常使用检索增强生成（RAG）来增强人工智能模型的知识。 RAG 是一种从知识库中检索相关信息并将其附加到用户提示中的方法，可显著增强模型的响应能力。 问题在于，传统的 RAG 解决方案在编码信息时会移除上下文，这往往会导致系统无法从知识库中检索到相关信息。

在这篇文章中，我们将概述一种能显著改进 RAG 中检索步骤的方法。 这种方法被称为 “上下文检索”，使用两种子技术： 上下文嵌入和上下文 BM25。 这种方法可以将检索失败的次数减少 49%，如果与重排相结合，则可以减少 67%。 这代表着检索准确率的显著提高，而检索准确率的提高又直接转化为下游任务的更佳表现。

通过我们的 Cookbook，您可以轻松部署自己的上下文检索解决方案。

关于使用较长提示语的说明

有时，最简单的解决方案就是最好的解决方案。 如果您的知识库小于 200,000 个标记（约 500 页材料），您只需在给模型的提示中包含整个知识库，而无需使用 RAG 或类似方法。

几周前，我们发布了 Claude 的 prompt caching ，使这种方法大大提高了速度和成本效益。 开发人员现在可以在 API 调用之间缓存经常使用的提示，从而将延迟时间缩短 2 倍以上，成本降低 90%（您可以阅读我们的 prompt caching cookbook 了解其工作原理）。

不过，随着知识库的增长，您需要一个更具扩展性的解决方案。 这就是上下文检索的用武之地。

RAG 入门：扩展到更大的知识库

对于不适合上下文窗口的较大知识库,RAG是典型的解决方案。RAG通过以下步骤对知识库进行预处理来工作:

1. 将知识库（文档的“语料库”)分解为较小的文本块,通常不超过几百个令牌;
2. 使用嵌入模型将这些块转换为编码含义的矢量嵌入;
3. 将这些嵌入存储在矢量数据库中,该数据库允许通过语义相似性进行搜索。

在运行时,当用户向模型输入查询时,矢量数据库用于根据与查询的语义相似性找到最相关的块。然后,将最相关的块添加到发送到生成模型的提示中。

尽管嵌入模型擅长捕获语义关系,但它们可能会错过关键的精确匹配。幸运的是,有一种较旧的技术可以在这些情况下提供帮助。BM25（最佳匹配25)是一种排名功能,它使用词汇匹配来查找精确的单词或短语匹配。对于包含唯一标识符或技术术语的查询特别有效。

BM25的工作原理是建立TF-IDF（定期频率-反向文档频率）概念。TF-IDF衡量单词对集合中文档的重要性。BM25通过考虑文档长度并将饱和函数应用于术语频率来完善这一点,这有助于防止常用词支配结果。

这是在语义嵌入失败的情况下BM25成功的方法:假设用户在技术支持数据库中查询“错误代码TS-999”。嵌入模型通常会找到有关错误代码的内容,但可能会错过确切的“ TS-999”匹配。BM25查找此特定文本字符串以标识相关文档。

通过使用以下步骤组合嵌入和BM25技术,RAG解决方案可以更准确地检索最适用的大块:

1. 将知识库（文档的“语料库”)分解为较小的文本块,通常不超过几百个令牌;
2. 为这些块创建TF-IDF编码和语义嵌入;
3. 使用BM25根据确切匹配项查找顶部;
4. 使用嵌入根据语义相似性查找顶部;
5. 使用等级融合技术将(3)和(4)的结果进行合并和重复;
6. 将顶部K块添加到提示中以生成响应。

通过同时使用BM25和嵌入模型,传统的RAG系统可以提供更全面,更准确的结果,从而在精确的术语匹配与更广泛的语义理解之间取得平衡。

使用嵌入和最佳匹配25（BM25)来检索信息的标准检索增强生成（RAG）系统。TF-IDF（术语频率逆文档频率）衡量单词的重要性并构成BM25的基础。
这种方法使您能够经济有效地扩展到庞大的知识库,远远超出了单个提示的范围。但是这些传统的RAG系统有一个很大的局限性:它们经常破坏上下文。

传统RAG中的上下文难题

在传统的RAG中,文档通常会分成较小的块以进行有效检索。尽管此方法对许多应用程序都有效,但是当单个块缺乏足够的上下文时,它可能导致问题。

例如,假设您收集了一系列财务信息（例如,美国 SEC文件）嵌入到您的知识库中,您收到以下问题: “ 2023年第二季度,ACME Corp的收入增长是多少？”

相关部分可能包含文本: “该公司的收入比上一季度增长了3%。” 但是,这一部分本身并未指定其所指的公司或相关的时间段,因此很难检索正确的信息或有效地使用信息。

介绍上下文检索

上下文检索通过在嵌入之前将块特定的说明上下文添加到每个块(“上下文嵌入”)并创建BM25索引(“上下文BM25 ”)来解决此问题。

让我们返回我们的SEC文件收集示例。这是一个如何转换块的示例:

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."

值得注意的是,过去已经提出了使用上下文来改善检索的其他方法。其他建议包括: 将通用文档摘要添加到大块（我们进行了实验,发现收益非常有限）, 假设文件嵌入,和 基于摘要的索引（我们进行了评估,发现性能低下）。这些方法与本文中提出的方法不同。

实施上下文检索

当然,在知识库中手动注释成千上万个甚至数百万个块将是太多的工作。为了实现上下文检索,我们求助于Claude。我们写了一封提示,指示模型提供简洁,特定于块的上下文,该上下文使用整个文档的上下文来解释块。我们使用以下Claude 3 Haiku提示为每个块生成上下文:

<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个令牌）在嵌入该块之前和创建BM25索引之前被添加到了该块之前。

这是实践中的预处理流程:

上下文检索是一种预处理技术,可提高检索准确性。
如果您有兴趣使用上下文检索,则可以开始使用 我们的食谱。

使用提示缓存降低上下文检索的成本

得益于上文提到的特殊提示缓存功能，Claude 可以低成本实现上下文检索。 有了提示缓存功能，你就不需要为每个分块传递参考文档。 只需将文档加载到缓存中一次，然后引用之前缓存的内容即可。 假设有 800 个标记块、8k 个标记文档、50 个标记上下文指令和每个标记块 100 个上下文标记，那么生成上下文化标记块的一次性成本为每百万文档标记 1.02 美元。

方法

我们在不同的知识领域（代码库、小说、ArXiv 论文、科学论文）、嵌入模型、检索策略和评估指标之间进行了试验。 我们在附录 II 中列举了我们在各个领域中使用的问题和答案的一些示例。

下图显示了使用性能最佳的嵌入配置（双子座文本 004）和检索前 20 个文块在所有知识域中的平均性能。 我们使用 1 减去召回率@20 作为评估指标，该指标用于衡量在前 20 个数据块中未能检索到的相关文档的百分比。 您可以在附录中看到全部结果–在我们评估的每种嵌入-来源组合中，上下文关联都能提高性能。

性能改进

我们的实验表明：

• 上下文嵌入将前 20 个数据块的检索失败率降低了 35%（5.7% → 3.7%）。
• 将上下文嵌入和上下文 BM25 结合使用将前 20 个数据块的检索失败率降低了 49%（5.7% → 2.9%）。

将上下文嵌入和上下文 BM25 结合使用，可将前 20 个大块的检索失败率降低 49%。

实施注意事项

在实施上下文检索时，有几个注意事项需要牢记：

1. 块边界(Chunk boundaries)： 考虑如何将文档分割成块。 分块大小、分块边界和分块重叠的选择会影响检索性能。
2. 嵌入模型(Embedding model)： 在我们测试的所有嵌入模型中，上下文检索都能提高性能，但某些模型可能比其他模型更有优势。 我们发现 Gemini 和 Voyage 嵌入尤其有效。
3. 自定义上下文提示(Custom contextualizer prompts)： 虽然我们提供的通用提示效果很好，但如果能根据具体领域或用例定制提示，效果可能会更好（例如，包含可能只在知识库的其他文档中定义的关键术语表）。
4. 块的数量(Number of chunks)： 在上下文窗口中添加更多信息块可增加包含相关信息的机会。 但是，更多的信息可能会分散模型的注意力，因此这是有限度的。 我们尝试了提供 5、10 和 20 个数据块，结果发现使用 20 个数据块的性能最好（参见附录中的比较），但也值得根据自己的使用情况进行尝试。 始终运行验证： 通过将上下文化的分块传递给响应生成器并区分上下文和分块，可以改善响应生成。

始终运行 evals： 将上下文分块传递给响应生成器，并区分上下文和分块，可以改进响应生成。

通过重新排名进一步提高性能

最后一步，我们可以将上下文检索与另一种技术相结合，以进一步提高性能。 在传统的 RAG 中，人工智能系统会搜索其知识库以找到潜在的相关信息块。 对于大型知识库，这种初始检索通常会返回大量相关性和重要性各不相同的信息块，有时甚至多达数百个。

重新排序是一种常用的过滤技术，可确保只将最相关的信息块传递给模型。 重新排序可提供更好的响应，并降低成本和延迟，因为模型处理的信息更少。 关键步骤如下

1. 执行初始检索，获取潜在相关性最高的数据块（我们使用的是前 150 个）；
2. 将前 N 个数据块连同用户的查询一起传递给重排模型；
3. 使用重排模型，根据每个数据块与提示的相关性和重要性给每个数据块打分，然后选出前 K 个数据块（我们使用的是前 20 个）；
4. 将前 K 个数据块作为上下文传递给模型，生成最终结果。

结合上下文检索和重新排名，最大限度地提高检索准确性。

性能改进

市场上有多种重排模型。 我们使用 Cohere reranker 进行了测试。 Voyage 也提供了重新排序器，不过我们没有时间对其进行测试。 我们的实验表明，在不同的领域中，添加重新排序步骤可以进一步优化检索。

具体来说，我们发现重新排序的上下文嵌入和上下文 BM25 将前 20 个大块的检索失败率降低了 67% （5.7% → 1.9%）。

重新排序的上下文嵌入和上下文 BM25 将前 20 个大块的检索失败率降低了 67%。

成本和延迟因素

重排的一个重要考虑因素是对延迟和成本的影响，尤其是在重排大量数据块时。 由于重排在运行时增加了一个额外步骤，因此不可避免地会增加少量延迟，即使重排器对所有数据块进行并行评分。 重排更多的数据块以获得更好的性能，与重排更少的数据块以获得更低的延迟和成本，两者之间存在固有的权衡。 我们建议根据具体使用情况尝试不同的设置，以找到合适的平衡点。

结论

我们进行了大量测试，比较了上述所有技术的不同组合（嵌入模型、BM25 的使用、上下文检索的使用、重排序器的使用以及检索到的 Top-K 结果总数），所有这些测试都跨越了各种不同的数据集类型。 以下是我们的发现摘要：

1. 嵌入+BM25比单独嵌入效果更好；
2. Voyage和Gemini的嵌入效果是我们测试过的嵌入效果中最好的；
3. 将排名前20的词块传递给模型比只传递排名前10或前5的词块更有效；
4. 给词块添加上下文能大大提高检索准确率；
5. 重新排序比不重新排序效果更好；
6. 所有这些优势： 为了最大限度地提高性能，我们可以将上下文嵌入（来自 Voyage 或 Gemini）与上下文 BM25 结合起来，再加上重新排序步骤，并将 20 个语块添加到提示中。

我们鼓励所有使用知识库的开发人员使用我们的烹饪手册来尝试这些方法，从而将性能提升到新的水平。

附录 I

以下是不同数据集、嵌入式提供商、除嵌入式外还使用 BM25、使用上下文检索以及使用重排检索 @ 20 的结果细目。

检索 @ 10 和 @ 5 的细目以及每个数据集的问题和答案示例见附录 II。