为了让人工智能模型在特定场景中发挥效用，通常需要获取相关的背景知识。例如，客服聊天机器人需了解其服务的具体业务，而法律分析机器人则需掌握大量历史案例。
开发者通常通过检索增强生成（RAG）来丰富人工智能模型的知识。RAG方法会从知识库中提取相关信息，并将其附加到用户的提示上，大幅提高模型的响应质量。然而，传统RAG解决方案在编码信息时忽略了上下文，导致系统无法有效检索出相关信息。
在这篇文章中，我们介绍了一种显著改善RAG检索步骤的方法，称为“上下文检索”。该方法结合了上下文嵌入和上下文BM25两个子技术。研究表明，这一方法能将检索失败率降低49%，并在结合重排序时降至67%。这意味着在下游任务中，检索准确性显著提高，进而提升整体表现。
您可以通过访问我们的手册轻松部署自己的上下文检索解决方案。
简单使用更长提示的建议
有时，最简单的解决方案就是最佳选择。如果您的知识库不超过200,000个标记（约500页），可以将整个知识库直接包含在给模型的提示中，无需使用RAG等方法。
几周前，我们为Claude推出了提示缓存，使得这种方法更迅速且成本更低。开发者们可以在API调用间缓存常用提示，从而将延迟降低超过两倍，成本减少可达90%（您可以通过阅读我们的提示缓存食谱来了解具体实现）。
然而，随着知识库的扩展，您将需要更具可扩展性的解决方案，这就是上下文检索的关键所在。
RAG基础：扩展至更大的知识库
对于不适合上下文窗口的大型知识库，RAG是常用的解决方案。RAG通过以下步骤预处理知识库：
- 将知识库拆分为较小的文本块，通常不超过几百个标记；
- 使用嵌入模型将这些块转化为语义向量嵌入；
- 将这些嵌入存储在支持语义相似性搜索的向量数据库中。
在运行时，用户输入查询后，系统会利用向量数据库找到与查询语义相似的最相关文本块。随后，这些块将被加入到发送给生成模型的提示中。
尽管嵌入模型在捕捉语义关系上表现突出，但它们可能会错过一些关键信息的精确匹配。此时，BM25（最佳匹配25）技术就派上了用场。BM25利用词汇匹配来查找精确的单词或短语匹配，特别适用于包含独特标识符或技术术语的查询。
BM25是在TF-IDF（词频-逆文档频率）基础上进行优化的。TF-IDF用于衡量一个词在文档集合中的重要性，而BM25则基于文档长度和词频饱和度进行改进，以避免常见词在结果中占据主导地位。
例如，假设用户在技术支持数据库中查询“错误代码TS-999”。嵌入模型可能会检索到与错误代码相关的信息，却无法找到具体的“TS-999”匹配。BM25则专门查找该文本字符串，以识别相关文档。
通过结合嵌入和BM25技术，RAG解决方案可以更准确地检索最相关的文本块。具体步骤如下：
- 拆分知识库为小文本块；
- 为每个块创建TF-IDF编码和语义嵌入；
- 使用BM25查找基于精确匹配的顶级文本块；
- 使用嵌入查找基于语义相似性的顶级文本块；
- 结合并去重两个步骤的结果；
- 将最相关的K个文本块添加到提示中，以生成响应。
通过这一方法，传统的RAG系统能够在精准匹配与更广泛的语义理解之间取得良好的平衡。
该标准的增强检索生成（RAG）系统将嵌入和BM25结合使用，以检索信息。TF-IDF衡量单词的重要性，并成为BM25的基础。
这种方法让您能够以低成本扩展到庞大的知识库，远超单个提示所能容纳的范围。然而，传统RAG系统的一个显著缺陷是，常常会丧失上下文。
传统RAG中的上下文难题
在传统RAG中，为了实现高效检索，文档通常被拆分为较小的块。尽管这种方法适用于许多应用，但当单个块缺乏足够上下文时，可能会导致检索问题。
例如，设想您拥有一系列财务信息（如美国证券交易委员会的文件），并收到如下问题：“ACME公司在2023年第二季度的收入增长是多少？”
相关块可能包含文本：“公司的收入比上个季度增长了3%。”然而，这段文本本身并未说明其所指的具体公司或时间段，这使得准确检索相关信息变得困难。
引入上下文检索
上下文检索的解决方案是，在嵌入前和BM25索引创建前，将特定的解释性上下文添加到每个块中（即“上下文嵌入”和“上下文BM25”）。
以SEC文件为例，以下是一个块的转化示例：
original_chunk = "公司的收入比上个季度增长了3%。
contextualized_chunk = "该块来自ACME公司2023年第二季度业绩的SEC文件；上个季度收入为3.14亿美元。公司的收入比上个季度增长了3%。"`
需要注意的是，以前提出的其他方法（如将通用文档摘要添加到块中）未能产生显著的改进，而上下文检索所提出的思路则显而易见。
实施上下文检索
当然，手动注释数千或数百万个块的工作量过于庞大。为了实现上下文检索，我们转向Claude。我们编写了一个提示，指导模型为每个块提供简洁的上下文，以说明该块在整个文档中的位置。我们使用以下Claude 3 Haiku提示生成上下文：
<document> {{WHOLE_DOCUMENT}} </document>
这是我们要在整个文档中定位的块
<chunk> {{CHUNK_CONTENT}} </chunk>
请提供简短的上下文，以便在整体文档中为此块提供定位，目的是改善块的搜索检索。仅回答简洁的上下文，不需其他内容。
生成的上下文文本通常为50-100个标记，添加到块中后，再进行嵌入和BM25索引的创建。
以下是预处理流程的实践图示：
上下文检索是一种提升检索准确性的预处理技术。
如果您有意使用上下文检索，可以参阅我们的手册进行开始。
利用提示缓存降低上下文检索的成本
上下文检索得以在Claude中低成本实现，得益于我们前面提到的提示缓存功能。通过提示缓存，您无需为每个块重复传入参考文档，只需将文档加载到缓存中一次，即可引用已缓存内容。假设800个标记的块、8000个标记的文档、50个标记的上下文指令和每个块100个标记的上下文，生成上下文化块的单次成本为每百万文档标记1.02美元。
方法论
我们在多个知识领域（如代码库、小说、ArXiv论文和科学论文）、各种嵌入模型、检索策略和评估指标中开展实验。我们在附录II中提供了一些领域的问题和答案示例。
下图显示了使用最佳嵌入配置（Gemini Text 004）和检索前20个块的平均性能。我们使用1减去recall@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系统会搜索知识库，查找潜在相关的信息块。而在大型知识库中，初步检索结果往往会返回大量块，有时甚至是数百个，且这些块的相关性和重要性不一。
重排序是一种常用的过滤技术，可确保仅最相关的块被传递给模型。重排序不仅提升了响应质量，还降低了成本和延迟，因为模型处理的信息量减少。主要步骤如下：
- 进行初步检索，获取最相关的块（我们使用前150个）；
- 将top-N块与用户的查询一起传入重排序模型；
- 使用重排序模型为每个块打分，评估其与提示的相关性和重要性，然后选择前K块（我们使用前20个）；
- 将这些top-K块传入模型，生成最终结果。
结合上下文检索和重排序，最大化检索准确性。
性能提升
市场上有多种重排序模型。我们测试了Cohere重排序器。Voyage也提供重排序器，尽管我们未能进行验证。我们的实验表明，增加重排序步骤在各个领域中进一步优化了检索效果。
更具体地说，我们发现重排序的上下文嵌入和上下文BM25将前20个块的检索失败率降低了67%（5.7% → 1.9%）。
重排序的上下文嵌入和上下文BM25将前20个块的检索失败率降低了67%。
成本和延迟考量
重排序的一个重要考量是其对延迟和成本的影响，尤其是在重排序大量块时。由于重排序增加了运行时的额外步骤，尽管重排序器会并行对所有块进行评分，但仍会引入小幅延迟。在重排序更多块以实现更好表现与减少延迟和成本之间存在固有的权衡。我们建议在实际应用中对不同设置进行实验，以找到最佳平衡。
结论
我们进行了大量测试，比较了所有上述技术的不同组合（嵌入模型、使用BM25、上下文检索、重排序，以及检索的总块数），覆盖各种数据集类型。以下是我们的发现总结：
- 嵌入与BM25组合优于单独使用嵌入；
- Voyage和Gemini的嵌入表现最佳；
- 向模型传递前20个块比仅传递前10或前5个更有效；
- 为块添加上下文显著提高检索准确性；
- 重排序效果优于不进行重排序；
- 所有这些好处均可叠加：为了最大化性能提升，我们可以结合上下文嵌入（来自Voyage或Gemini）、上下文BM25，以及重排序步骤，并将20个块添加到提示中。
我们鼓励所有与知识库合作的开发者利用我们的手册进行实验，以解锁新层次的性能。
附录I
以下是针对不同数据集、嵌入提供商、使用BM25及上下文检索和重排序的检索结果细分。
有关检索@10和@5的详细信息及示例问题和答案，请参见附录II。
1减去检索@20的结果，涵盖各数据集和嵌入提供商。
原文：https://www.anthropic.com/engineering/contextual-retrieval