为了让人工智能模型在特定环境中发挥作用，它通常需要获取背景知识。例如，客户支持聊天机器人需要了解它们所用于的特定业务，而法律分析机器人需要了解大量过去的案例。
开发人员通常使用检索增强生成 (RAG) 来增强 AI 模型的知识。RAG 是一种从知识库中检索相关信息并将其附加到用户提示中的方法，从而显着增强模型的响应。问题在于，传统的 RAG 解决方案在编码信息时会删除上下文，这通常会导致系统无法从知识库中检索相关信息。
在这篇文章中，概述了一种可以显着改进 RAG 检索步骤的方法。该方法称为“上下文检索”，并使用两种子技术：上下文嵌入和上下文 BM25。此方法可将失败检索的数量减少 49%，与重新排名结合使用时可减少 67%。这些代表了检索准确性的显着提高，这直接转化为下游任务的更好性能。
关于仅使用较长提示的注意事项
有时最简单的解决方案是最好的。如果您的知识库小于 200,000 个标记（大约 500 页材料），您可以将整个知识库包含在为模型提供的提示中，而不需要 RAG 或类似的方法。
几周前，Claude 发布了prompt caching，这使得这种方法速度明显更快且更具成本效益。开发人员现在可以在 API 调用之间缓存常用的提示，从而将延迟减少 2 倍以上，并将成本降低高达 90%（您可以通过阅读prompt caching book来了解它的工作原理）。
然而，随着您的知识库的增长，您将需要更具可扩展性的解决方案。这就是上下文检索的用武之地。
RAG 入门：扩展到更大的知识库
对于不适合上下文窗口的较大知识库，RAG 是典型的解决方案。RAG 的工作原理是使用以下步骤预处理知识库：
将知识库（文档的“语料库”）分解为更小的文本块，通常不超过几百个标记； 使用嵌入模型将这些块转换为编码含义的向量嵌入； 将这些嵌入存储在向量数据库中，以便通过语义相似性进行搜索。
在运行时，当用户向模型输入查询时，矢量数据库用于根据与查询的语义相似性查找最相关的块。然后，最相关的块被添加到发送到生成模型的提示中。
虽然嵌入模型擅长捕获语义关系，但它们可能会错过关键的精确匹配。幸运的是，有一种较旧的技术可以在这些情况下提供帮助。BM25 (Best Matching 25) 是一种排名函数，使用词汇匹配来查找精确的单词或短语匹配。它对于包含唯一标识符或技术术语的查询特别有效。
BM25 的工作原理基于 TF-IDF（术语频率-逆文档频率）概念。TF-IDF 衡量一个单词对于集合中的文档的重要性。BM25 通过考虑文档长度并对术语频率应用饱和函数来对此进行细化，这有助于防止常见单词主导结果。
以下是 BM25 如何在语义嵌入失败的情况下取得成功：假设用户在技术支持数据库中查询“错误代码 TS-999”。嵌入模型通常可能会找到有关错误代码的内容，但可能会错过确切的“TS-999”匹配。BM25 查找此特定文本字符串来识别相关文档。
RAG 解决方案可以通过使用以下步骤结合嵌入和 BM25 技术来更准确地检索最适用的块：
将知识库（文档的“语料库”）分解为更小的文本块，通常不超过几百个标记； 为这些块创建 TF-IDF 编码和语义嵌入； 使用 BM25 根据精确匹配查找顶级块； 使用嵌入根据语义相似性查找顶级块； 使用等级融合技术组合（3）和（4）的结果并消除重复； 将前 K 个块添加到提示中以生成响应。
通过利用 BM25 和嵌入模型，传统 RAG 系统可以提供更全面、更准确的结果，在精确的术语匹配与更广泛的语义理解之间取得平衡。
标准检索增强生成 (RAG) 系统，使用嵌入和 BM25 来检索信息。TF-IDF（术语频率-逆文档频率）衡量单词重要性并构成 BM25 的基础。
这种方法使您能够经济有效地扩展到巨大的知识库，远远超出单个提示所能容纳的范围。但这些传统的 RAG 系统有一个显着的局限性：它们经常破坏上下文。
传统 RAG 中的上下文难题
在传统的 RAG 中，文档通常被分割成更小的块以实现高效检索。虽然这种方法适用于许多应用程序，但当各个块缺乏足够的上下文时，它可能会导致问题。
例如，假设您的知识库中嵌入了一组财务信息（例如，美国 SEC 文件），并且您收到以下问题：“ACME Corp 在 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评估并发现性能较低）。这些方法与本文中提出的方法不同。
实施上下文检索
当然，手动注释知识库中数千甚至数百万个块的工作量太大。为了实现上下文检索，求助于 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 个token、8k 个token、50 个token上下文指令以及每个块 100 个上下文token，则生成上下文化块的一次性成本为每百万个token 1.02 美元。
性能改进:
上下文嵌入将前 20 个块的检索失败率降低了 35% (5.7% → 3.7%)。 结合上下文嵌入和上下文 BM25 将前 20 个块检索失败率降低了 49% (5.7% → 2.9%)。
在实施上下文检索时，需要记住以下几点：
块边界： 考虑如何将文档分割成块。块大小、块边界和块重叠的选择会影响检索性能 嵌入模型： 虽然上下文检索提高了我们测试的所有嵌入模型的性能，但某些模型可能比其他模型受益更多。发现Gemini和Voyage嵌入特别有效。 自定义上下文提示： 虽然我们提供的通用提示效果很好，但您可以通过根据您的特定领域或用例定制的提示（例如，包括可能仅在其他文档中定义的关键术语词汇表）获得更好的结果在知识库中）。 块数： 将更多块添加到上下文窗口中会增加包含相关信息的机会。然而，更多的信息可能会分散模型的注意力，因此这是有限制的。我们尝试提供 5、10 和 20 个块，发现使用 20 是这些选项中性能最高的（请参阅附录进行比较），但值得在您的用例上进行试验。
通过重新排名进一步提高性能
最后一步，可以将上下文检索与另一种技术结合起来，以提供更多的性能改进。在传统的 RAG 中，人工智能系统搜索其知识库以查找潜在相关的信息块。对于大型知识库，这种初始检索通常会返回大量（有时是数百个）具有不同相关性和重要性的块。
重新排名是一种常用的过滤技术，可确保仅将最相关的块传递给模型。重新排名可提供更好的响应并降低成本和延迟，因为模型处理的信息较少。关键步骤是：
执行初始检索以获取最重要的潜在相关块（使用前 150 个）； 将前 N 个块与用户的查询一起通过重新排名模型； 使用重新排序模型，根据每个块与提示的相关性和重要性给每个块打分，然后选择前 K 个块（使用前 20 个）； 将前 K 个块作为上下文传递到模型中以生成最终结果。
性能改进
市场上有多种重新排名模型。使用Cohere reranker进行了测试。Voyage 还提供了重新排名器，但我们没有时间测试它。我们的实验表明，在各个领域中，添加重新排名步骤可以进一步优化检索。
具体来说，我们发现 Reranked Contextual Embedding 和 Contextual BM25 将前 20 个块的检索失败率降低了 67% (5.7% → 1.9%)。
结论
Claude进行了大量测试，比较了上述所有技术的不同组合（嵌入模型、BM25 的使用、上下文检索的使用、重新排序器的使用以及检索到的前 K 个结果的总数），所有这些都涵盖了各种技术不同数据集类型的。以下是发现的摘要：
Embeddings+BM25 比单独的 embeddings 更好； Voyage 和 Gemini 拥有我们测试的最佳嵌入； 将前 20 个块传递给模型比仅传递前 10 个或前 5 个块更有效； 在块中添加上下文可以大大提高检索准确性； 重新排名比不重新排名好； 所有这些好处叠加起来：为了最大限度地提高性能，可以将上下文嵌入（来自 Voyage 或 Gemini）与上下文 BM25 结合起来，再加上重新排名步骤，并将 20 个块添加到提示中。
