在当前的知识检索领域，RAG技术正引领着最新潮流，它的目标是为大型语言模型（LLM）提供丰富而精确的上下文信息。然而，传统RAG方法在处理信息时经常会忽略上下文细节，这限制了其从知识库中提取相关信息的能力。解决如何有效保存上下文信息的问题，已成为该领域的重点。
针对这一挑战，Anthropic的研究团队提出了一种名为“上下文检索”的创新技术，使得在这一领域取得了重大突破。他们最近发表的研究详细介绍了这一技术，展示了如何通过上下文嵌入和上下文敏感的BM25算法显著降低检索失败率。让我们深入探讨这一方法的关键要素。
关于使用较长提示符的说明有时候最简单的解决方案就是最好的。如果你的知识库小于200，000个token（大约500页的材料），你可以在给出模型的提示中包含整个知识库，而不需要RAG或类似的方法。
几周前，Claude发布了快速缓存，这使得这种方法更快，更具成本效益。开发人员现在可以在API调用之间缓存频繁使用的提示，将延迟减少2倍以上，成本降低高达90%（可以通过阅读prompt caching cookbook了解它是如何工作的）。
但是，随着知识库的增长，您将需要一个更具可扩展性的解决方案。这就是上下文检索的用武之地。
扩展到更大的知识库对于不适合上下文窗口的较大知识库，RAG是典型的解决方案。RAG通过使用以下步骤预处理知识库来工作：
将知识库（文档的“语料库”）分解为更小的文本块，通常不超过几百个标记; 使用嵌入模型将这些块转换为编码含义的向量嵌入; 将这些嵌入存储在矢量数据库中，以便根据语义相似性进行搜索。
在运行时，当用户向模型输入查询时，向量数据库用于基于与查询的语义相似性来找到最相关的块。然后，将最相关的块添加到发送到生成模型的提示中。
虽然嵌入模型擅长捕捉语义关系，但它们可能会错过关键的精确匹配。幸运的是，有一种更古老的技术可以帮助解决这些问题。BM 25是一个排名功能，它使用词汇匹配来查找精确的单词或短语匹配。它对于包含唯一标识符或技术术语的查询特别有效。BM 25基于TF-IDF概念，TF-IDF衡量一个单词对集合中文档的重要性。BM 25通过考虑文档长度并将饱和函数应用于词频来细化这一点，这有助于防止常见词主导结果。
假设用户在技术支持数据库中查询“Error code TS-999”。嵌入模型通常可以找到有关错误代码的内容，但可能会错过精确的“TS-999”匹配。BM 25查找此特定文本字符串以识别相关文档。
RAG解决方案可以通过使用以下步骤结合嵌入和BM 25技术来更准确地检索最适用的块：
将知识库（文档的“语料库”）分解为更小的文本块，通常不超过几百个标记; 为这些块创建TF-IDF编码和语义嵌入; 使用BM 25来找到基于精确匹配的顶部块; 基于语义相似度，使用嵌入来找到顶部块; 使用融合技术对来自（3）和（4）的结果进行聚合和去重; 将前K个块添加到提示符中以生成响应。
通过利用BM 25和嵌入模型，传统的RAG系统可以提供更全面和准确的结果，平衡精确的术语匹配和更广泛的语义理解。
这种方法使您能够经济高效地扩展到巨大的知识库，远远超出了单个提示中所能容纳的内容。但是这些传统的RAG系统有一个显著的局限性：它们经常破坏上下文。
传统RAG中的语境难题在传统的RAG中，文档通常被分成更小的块以进行有效的检索。虽然这种方法对于许多应用程序都很有效，但当单个块缺乏足够的上下文时，它可能会导致问题。
例如，假设您的知识库中嵌入了一系列财务信息，您收到了以下问题：“ACME Corp在2023年第二季度的收入增长是多少？"
一个相关的块可能包含这样的文本：“公司的收入比上一季度增长了3%。“然而，这一大块本身并没有指定它所指的是哪家公司或相关的时间段，因此很难检索正确的信息或有效地使用这些信息。
Contextual Retrieval上下文检索简介
上下文检索通过在嵌入之前将特定于块的解释性上下文前置到每个块（Contextual Embeddings）并创建BM 25索引（Contextual BM25）来解决这个问题。
下面是一个如何转换块的示例：
原始分块 = "公司的收入比上一季度增长了3%。"
上下文化分块 = "这个分块来自ACME公司在2023年第二季度的SEC文件；上一季度的收入为3.14亿美元。公司的收入比上一季度增长了3%。"
值得注意的是，过去已经提出了使用上下文来改进检索的其他方法。其他建议包括：将通用文档摘要添加到块，假设文档嵌入和基于摘要的索引。这些方法的收益和性能都很低。
实现上下文检索
手动为知识库中的成千上万个分块添加上下文显然是不现实的。为此，研究团队使用了 Claude 模型，通过一个特定的提示生成每个分块的简洁上下文，生成的上下文通常为 50-100 个 token，然后在嵌入和创建 BM25 索引之前将其添加到分块中。对应的prompt示例:
<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.
下面是预处理流程在实践中的样子：
使用Prompt Caching降低上下文检索成本
上下文检索得益于Prompt Caching功能，通过Claude可以以低成本独特地实现。有了提示缓存，您不需要为每个块传入参考文档。您只需将文档加载到缓存中一次，然后引用之前缓存的内容。假设800个令牌的块，8k令牌的文档，50令牌的上下文指令，以及每个块的100令牌的上下文，生成上下文化块的一次性成本是每百万文档令牌1.02美元。
注意事项
在实现上下文检索时，需要记住几个注意事项：
块边界：考虑如何将文档拆分为块。块大小、块边界和块重叠的选择会影响检索性能。 嵌入模型：虽然上下文检索提高了我们测试的所有嵌入模型的性能，但某些模型可能比其他模型受益更多。Gemini和Voyage嵌入特别有效。 自定义prompt：虽然通用提示效果很好，但您可以使用针对特定领域或用例定制的提示（例如，包括可能仅在知识库中的其他文档中定义的关键术语的词汇表）来实现更好的结果。 **块的数量：**在上下文窗口中添加更多的块可以增加包含相关信息的机会。然而，更多的信息可能会分散模型的注意力，所以这是有限制的。尝试使用5、10和20块，发现使用20块是这些选项中性能最好的，但值得在您的用例中进行试验。
在传统 RAG 中，AI 系统会从知识库中检索到大量潜在相关的信息分块。对于大型知识库，这一初始检索往往会返回大量分块，有时多达数百个，且相关性和重要性各不相同。重排序是一种常用的过滤技术，确保只有最相关的分块被传递给模型。实验结果显示，重排序后的上下文嵌入和上下文 BM25 将前 20 个分块的检索失败率减少了 67%（从 5.7%降至 1.9%）。
成本和延迟考虑
重排序的一个重要考虑因素是对延迟和成本的影响，特别是在对大量块进行重排序时。因为重排序在运行时增加了一个额外的步骤，所以它不可避免地增加了少量的延迟，即使重排序器并行地对所有块进行评分。在重新排序更多块以获得更好的性能与重新排序更少块以降低延迟和成本之间存在固有的权衡。建议您在特定用例中尝试不同的设置，以找到正确的平衡。
总结研究团队通过大量的实验，为大家指出了一个新的提升 RAG 性能的方法，为开发者指出了实践新方向。同时，研究团队基于大量实验的结果，给出了一些关键的经验总结：
Embeddings+BM25 比单独使用Embeddings效果更好 Voyage 和 Gemini 是测试中效果最好的嵌入模型 将前20个块传递给模型比只传递前10个或前5个块更有效 在语块中加入上下文可以大大提高检索的准确率 采用重排序的方法比起不进行重排序 将这些改进策略综合起来：为了最大限度地提高性能，我们可以将contextual embeddings（来自Voyage或Gemini）与contextual BM25结合起来，再加上重新排序步骤，并将20个块添加到提示符中。
