大幅降落检索失败率 Retrieval让RAG再退化 Anthropic钻研团队提出新技术 引入Contextual

​在的常识检索畛域，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技术来更准确地检索最实用的块：

经过应用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美元。

留意事项

在成功高低文检索时，须要记住几个留意事项：

经过Rerank进一步优化性能

在传统 RAG 中，AI 系统会从常识库中检索到少量潜在相关的消息分块。关于大型常识库，这一初始检索往往会前往少量分块，有时多达数百个，且相关性和关键性各不相反。重排序是一种罕用的过滤技术，确保只要最相关的分块被传递给模型。实验结果显示，重排序后的高低文嵌入和高低文 BM25 将前 20 个分块的检索失败率缩小了 67%（从 5.7%降至 1.9%）。

老本和提前思考

重排序的一个关键思考起因是对提前和老本的影响，特别是在对少量块启动重排序时。由于重排序在运转时参与了一个额外的步骤，所以它无法防止地参与了大批的提前，即使重排序器并行地对一切块启动评分。在从新排序更多块以取得更好的性能与从新排序更少块以降落提前和老本之间存在固有的权衡。倡导您在特定用例中尝试不同的设置，以找到正确的平衡。

总结

钻研团队经过少量的实验，为大家指出了一个新的优化 RAG 性能的方法，为开发者指出了通常新方向。同时，钻研团队基于少量实验的结果，给出了一些关键的阅历总结：

原文链接：​ ​​ ​