介绍上下文检索（Contextual Retrieval）
原文链接：www.anthropic.com/engineering…
发布日期：2024年9月19日
摘要： 为了让AI模型在特定场景下发挥作用，它通常需要访问背景知识。
引言
为了让AI模型在特定场景下发挥作用，它通常需要访问背景知识。例如，客户支持聊天机器人需要了解其所服务的具体业务知识，法律分析机器人需要了解大量的过往案例。
开发者通常使用检索增强生成（RAG，Retrieval-Augmented Generation） 来增强AI模型的知识。RAG是一种从知识库中检索相关信息并将其附加到用户提示词中的方法，能够显著增强模型的响应能力。问题在于，传统的RAG解决方案在编码信息时会丢失上下文，这通常导致系统无法从知识库中检索到相关信息。
在本文中，概述了一种能够显著改进RAG检索步骤的方法。该方法被称为"上下文检索（Contextual Retrieval）"，使用两种子技术：上下文嵌入（Contextual Embeddings） 和 上下文BM25（Contextual BM25）。这种方法可以将检索失败率降低49%，当与重排序（Reranking）结合使用时，可以降低67%。这些都是检索准确性的显著提升，直接转化为下游任务的更好表现。
可以使用 cookbook 轻松部署自己的Claude上下文检索解决方案。
关于使用更长提示词的说明
有时候最简单的解决方案就是最好的。如果知识库小于200,000个token（约500页材料），可以直接将整个知识库包含在给模型的提示词中，无需使用RAG或类似方法。
几周前，Claude发布了 提示词缓存（Prompt Caching） 功能，这使得这种方法变得更快、更具成本效益。开发者现在可以在API调用之间缓存常用的提示词，将延迟降低超过2倍，成本降低高达90%（可以通过阅读 提示词缓存cookbook 来了解其工作原理）。
然而，随着知识库的增长，需要一个更具可扩展性的解决方案。这就是上下文检索的用武之地。
RAG入门：扩展到更大的知识库
对于无法放入上下文窗口的更大知识库，RAG是典型的解决方案。RAG通过以下步骤预处理知识库：
- 将知识库（文档"语料库"）分解成更小的文本块，通常不超过几百个token；
- 使用嵌入模型将这些块转换为编码语义的向量嵌入；
- 将这些嵌入存储在支持语义相似性搜索的向量数据库中。
在运行时，当用户向模型输入查询时，向量数据库用于根据与查询的语义相似性找到最相关的块。然后，将最相关的块添加到发送给生成模型的提示词中。
虽然嵌入模型擅长捕获语义关系，但它们可能会错过关键的精确匹配。幸运的是，有一种较老的技术可以在这些情况下提供帮助。BM25（Best Matching 25） 是一种使用词汇匹配来查找精确单词或短语匹配的排名函数。它对于包含唯一标识符或技术术语的查询特别有效。
BM25建立在TF-IDF（词频-逆文档频率）概念之上。TF-IDF衡量一个词对集合中某个文档的重要性。BM25通过考虑文档长度并对词频应用饱和函数来改进这一点，这有助于防止常见词主导结果。
以下是BM25如何在语义嵌入失败的地方取得成功的例子：假设用户在技术支持数据库中查询"Error code TS-999"。嵌入模型可能会找到有关错误代码的一般内容，但可能会错过精确的"TS-999"匹配。BM25查找这个特定的文本字符串来识别相关文档。
RAG解决方案可以通过以下步骤结合嵌入和BM25技术，更准确地检索最适用的块：
- 将知识库（文档"语料库"）分解成更小的文本块，通常不超过几百个token；
- 为这些块创建TF-IDF编码和语义嵌入；
- 使用BM25根据精确匹配找到排名靠前的块；
- 使用嵌入根据语义相似性找到排名靠前的块；
- 使用排名融合技术合并和去重（3）和（4）的结果；
- 将排名前K的块添加到提示词中生成响应。
通过同时利用BM25和嵌入模型，传统的RAG系统可以提供更全面和准确的结果，平衡精确的术语匹配和更广泛的语义理解。
标准检索增强生成（RAG）系统，同时使用嵌入和BM25来检索信息。TF-IDF（词频-逆文档频率）衡量词的重要性，是BM25的基础。
这种方法允许以经济高效的方式扩展到巨大的知识库，远远超出单个提示词所能容纳的范围。但这些传统的RAG系统有一个重大限制：它们经常破坏上下文。
传统RAG中的上下文困境
在传统的RAG中，文档通常被分割成较小的块以便高效检索。虽然这种方法对许多应用程序效果很好，但当单个块缺乏足够的上下文时，可能会导致问题。
例如，假设在知识库中嵌入了一组金融信息（比如美国SEC文件），并收到以下问题："ACME公司2023年第二季度的收入增长是多少？"
一个相关的块可能包含文本："该公司的收入比上一季度增长了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个token，在嵌入和创建BM25索引之前被添加到块的前面。
以下是预处理流程在实践中的样子：
上下文检索是一种提高检索准确性的预处理技术。
如果您有兴趣使用上下文检索，可以从 cookbook 开始。
使用提示词缓存降低上下文检索的成本
由于上面提到的特殊提示词缓存功能，上下文检索在Claude上可以以低成本独特地实现。通过提示词缓存，不需要为每个块传入参考文档。只需将文档加载到缓存中一次，然后引用之前缓存的内容。假设块为800个token，文档为8k个token，上下文指令为50个token，每个块的上下文为100个token，生成上下文化块的一次性成本为每百万文档token 1.02美元。
方法论
在各种知识领域（代码库、小说、ArXiv论文、科学论文）、嵌入模型、检索策略和评估指标上进行了实验。 附录II 中包含了每个领域使用的问题和答案的一些示例。
下面的图表显示了使用表现最佳的嵌入配置（Gemini Text 004）和检索前20个块时所有知识领域的平均性能。使用1减去recall@20作为评估指标，它衡量在前20个块中未能检索到的相关文档的百分比。可以在附录中看到完整结果——上下文化在我们评估的每个嵌入-来源组合中都提高了性能。
性能提升
实验表明：
- 上下文嵌入将前20个块的检索失败率降低了35%（5.7% → 3.7%）。
- 结合上下文嵌入和上下文BM25将前20个块的检索失败率降低了49%（5.7% → 2.9%）。
结合上下文嵌入和上下文BM25将前20个块的检索失败率降低了49%。
实现注意事项
在实现上下文检索时，有几个需要注意的事项：
-
块边界： 考虑如何将文档分割成块。块大小、块边界和块重叠的选择都会影响检索性能¹。
-
嵌入模型： 虽然上下文检索在测试的所有嵌入模型上都提高了性能，但某些模型可能比其他模型受益更多。 Gemini 和 Voyage 嵌入特别有效。
-
自定义上下文化提示词： 虽然我们提供的通用提示词效果很好，但您可能能够通过针对特定领域或用例定制的提示词获得更好的结果（例如，包含可能仅在知识库中其他文档中定义的关键术语词汇表）。
-
块数量： 向上下文窗口添加更多块会增加包含相关信息的机会。但是，更多信息可能会分散模型的注意力，所以这有一个限制。我们尝试了传递5个、10个和20个块，发现使用20个是这些选项中最有效的（参见附录中的比较），但值得在您的用例上进行实验。
始终运行评估： 通过传递上下文化的块并区分什么是上下文和什么是块，可能会改善响应生成。
通过重排序进一步提升性能
在最后一步中，可以将上下文检索与另一种技术结合使用，以获得更多的性能提升。在传统的RAG中，AI系统搜索其知识库以找到潜在相关的信息块。对于大型知识库，这种初始检索通常会返回大量块——有时是数百个——相关性和重要性各不相同。
重排序（Reranking） 是一种常用的过滤技术，用于确保只有最相关的块被传递给模型。重排序提供更好的响应，并降低成本和延迟，因为模型处理的信息更少。关键步骤是：
- 执行初始检索以获取排名靠前的潜在相关块（我们使用了前150个）；
- 将排名前N的块与用户查询一起传递给重排序模型；
- 使用重排序模型根据每个块与提示词的相关性和重要性给出分数，然后选择排名前K的块（我们使用了前20个）；
- 将排名前K的块作为上下文传递给模型以生成最终结果。
结合上下文检索和重排序以最大化检索准确性。
性能提升
市场上有几种重排序模型。我们使用 Cohere重排序器 进行了测试。Voyage 也提供重排序器，但我们没有时间测试它。我们的实验表明，在各个领域中，添加重排序步骤进一步优化了检索。
具体来说，我们发现重排序的上下文嵌入和上下文BM25将前20个块的检索失败率降低了67%（5.7% → 1.9%）。
重排序的上下文嵌入和上下文BM25将前20个块的检索失败率降低了67%。
成本和延迟考虑
重排序的一个重要考虑因素是对延迟和成本的影响，特别是在重排序大量块时。因为重排序在运行时添加了额外的步骤，它不可避免地会增加少量延迟，尽管重排序器会并行地为所有块评分。在重排序更多块以获得更好性能与重排序更少块以获得更低延迟和成本之间存在固有的权衡。我们建议在您的特定用例上尝试不同的设置以找到正确的平衡。
结论
我们进行了大量测试，比较了上述所有技术的不同组合（嵌入模型、使用BM25、使用上下文检索、使用重排序器以及检索的前K个结果总数），涵盖了各种不同的数据集类型。以下是我们发现的总结：
- 嵌入+BM25优于单独使用嵌入；
- Voyage和Gemini在我们测试的嵌入中表现最好；
- 向模型传递前20个块比只传递前10个或前5个更有效；
- 向块添加上下文大大提高了检索准确性；
- 重排序优于不重排序；
- 所有这些优势可以叠加： 为了最大化性能提升，我们可以将上下文嵌入（来自Voyage或Gemini）与上下文BM25结合使用，再加上重排序步骤，并将20个块添加到提示词中。
鼓励所有使用知识库的开发者使用 cookbook 来实验这些方法，以解锁新的性能水平。
附录 I
以下是在Retrievals @ 20时跨数据集、嵌入提供商、除嵌入外使用BM25、使用上下文检索和使用重排序的结果分解。
请参阅 附录 II 了解Retrievals @ 10和@ 5的分解以及每个数据集的示例问题和答案。
跨数据集和嵌入提供商的1减去recall @ 20结果。
致谢
研究和撰写：Daniel Ford。感谢Orowa Sikder、Gautam Mittal和Kenneth Lien的关键反馈，Samuel Flamini实现了cookbooks，Lauren Polansky负责项目协调，以及Alex Albert、Susan Payne、Stuart Ritchie和Brad Abrams帮助塑造了这篇博客文章。
