Google DeepMind发表的关于检索增强生成还是长上下文大语言模型的全面研究

本文链接：https://blog.csdn.net/m0_59235699/article/details/141575723

一、结论写在前面

论文来自谷歌 DeepMind、密歇根大学

论文标题：Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach

论文链接：https://arxiv.org/pdf/2407.16833

检索增强生成（Retrieval Augmented Generation，RAG）一直是LLMs高效处理过长上下文的有力工具。然而，近期如Gemini-1.5和GPT-4等LLMs展现了直接理解长上下文的卓越能力。论文进行了RAG与长上下文（long-context，LC）LLMs的全面比较，突出了性能与计算成本之间的权衡。

论文利用三种最新的LLMs在多个公共数据集上对RAG和LC进行了基准测试。结果显示，在资源充足的情况下，LC在平均性能上持续优于RAG。然而，RAG显著的低成本仍然是一个明显的优势。

基于这一观察，论文提出了SELF-ROUTE，一种简单而有效的方法，根据模型自我反思将查询路由至RAG或LC。SELF-ROUTE在显著降低计算成本的同时，保持了与LC相当的性能。论文的发现为使用RAG和LC的LLMs长上下文应用提供了指导。

二、论文的简单介绍

2.1 论文的背景

检索增强生成（RAG）已被证明是大型语言模型（LLMs）利用外部知识的一种既有效又高效的方法。RAG根据查询检索相关信息，然后提示LLM在检索信息的环境中生成响应。这种方法极大地扩展了LLM以最低成本访问大量信息的能力。

然而，最近如Gemini和GPT-4等LLMs展示了直接理解长上下文的卓越能力。例如，Gemini 1.5可以处理多达100万个token。这促使了对长上下文（LC）LLMs与RAG进行系统比较：一方面，RAG 在概念上充当先验，规范 LLM 对检索片段的注意力，从而避免无关信息的干扰并节省不必要的注意力计算；另一方面，大规模预训练可能使 LLM 发展出更强的长上下文能力。因此，论文受到启发，比较 RAG 和LC，评估它们的表现和效率。

图 1：尽管长上下文 LLM（LC）在长上下文理解方面超越了 RAG，但 RAG 在成本效率上显著更高。论文的方法 SELF-ROUTE，结合了 RAG 和LC，以更低的成本实现了与LC 相当的表现

论文在多个公共数据集上系统地基准测试了 RAG 和 LC，全面了解它们的优缺点，并最终将它们结合，以获得两者的最佳效果。与先前工作（Xu et al., 2023）的发现不同，论文发现LC 在几乎所有配置（资源充足时）中始终优于 RAG。这表明近期 LLM 在长上下文理解方面的卓越进步。

尽管性能次优，RAG 仍然具有相关性，因其显著更低的计算成本。与 LC 相比，RAG 显著减少了输入 LLM 的长度，从而降低了成本，因为 LLM API 定价通常基于输入token的数量。此外，论文的分析显示，LC 和 RAG 对超过 60% 的查询的预测是相同的。对于这些查询，RAG 可以在不牺牲性能的情况下降低成本。

基于这一观察，论文提出了 SELF-ROUTE，一种简单而有效的方法，根据模型自我反思将不同查询路由至 RAG 或 LC。通过 SELF-ROUTE，论文在实现总体性能与 LC 相当的同时，显著降低了成本。例如，Gemini-1.5-Pro 的成本减少了 65%，而 GPT-40 的成本减少了 39%。

图1展示了LC、RAG和SELF-ROUTE在三种近期大型语言模型（LLMs）：GPT-40、GPT-3.5-Turbo和Gemini-1.5-Pro上的比较。除了定量评估外，论文还提供了一项全面分析，比较RAG和LC，包括RAG的常见失败模式、成本与性能之间的权衡，以及在额外合成数据集上的结果。论文的分析作为一个起点，启发未来对RAG的改进，并为使用RAG和LC构建长上下文应用提供实证指南。

2.2 RAG与LC的基准测试

2.2.1 数据集与评估指标

论文在LongBench和∞Bench的部分数据集上进行评估，这些是包含新旧数据集的近期基准，涵盖多语言中的合成与真实文本。LongBench包含21个数据集，平均上下文长度为7千字。∞Bench则包含更长的上下文，平均长度达10万token。

在众多数据集中，论文主要关注以下类型的任务：(a) 使用英语，(b) 真实场景，以及 © 基于查询的（例如，摘要任务不包含用于检索相关信息的查询）。这导致了从LongBench中选出的7个数据集，包括NarrativeQA、Qasper、MultiFieldQA、HotpotQA、WikiMultihopQA、MuSiQue、QMSum；以及从Bench中选出的2个数据集，包括En.QA和EN.MC。

对于评估指标，论文报告开放式问答任务的F1分数、多项选择问答任务的准确率以及摘要任务的ROUGE分数。

2.2.2 模型与检索器

评估了三种最新的LLM，包括Gemini-1.5-Pro、GPT-4O和GPT-3.5-Turbo。Gemini-1.5-Pro是G∞gle近期推出的长上下文LLM，支持高达100万token。GPT-4O是OpenAI最新推出的轻量级但强大的LLM，支持128k token。GPT-3.5-Turbo支持16k token。

在论文的研究中使用了两种检索器：Contriever，这是一种通过对比训练的密集检索器，在BEIR数据集上优于BM25；以及Dragon，这是一种近期可泛化的密集检索器，在有监督和零样本设置下均实现了高性能，无需复杂的后期交互。遵循（Xu et al., 2023）的方法，论文将长上下文分割成300词的块，并根据查询嵌入与块嵌入的余弦相似度选择前k个块（默认k=5）。这些块按相似度分数排序，并在开头添加块索引。

由于黑盒大语言模型（LLMs）在未知数据集上进行预训练，评估数据集的泄露可能发生。特别是，一些评估数据集基于维基百科，这很可能在预训练过程中被LLMs接触过。在某些情况下，论文发现模型可能使用与标准答案完全相同的词汇（例如“meticulously”）来预测正确答案，即使这些词汇并未出现在提供的上下文中。在论文的实验中，论文尝试通过提示模型仅基于提供的段落来回答问题，以缓解这一问题，无论是对RAG还是LC。如何解决LLM评估中的数据泄露问题仍然是一个开放的问题。

2.2.3 基准测试结果

论文在九个数据集上对LC和RAG的性能进行了基准测试，使用了三个近期的大型语言模型：Gemini-1.5-Pro、GPT-40和GPT-3.5-Turbo。表1展示了使用Contriever检索器的结果，其中行*-1和行*- 2分别展示了LC和RAG的基准测试结果。使用Dragon检索器的结果将在表2中讨论。

如表1所示，LC在所有三个模型中持续优于RAG，且有显著的优势。平均而言，LC在Gemini-1.5-Pro上比RAG高出 1.6%，在GPT-4O上高出13.1%，在GPT-3.5-Turbo上高出3.6%。值得注意的是，与GPT-3.5-Turbo相比，更近期模型（GPT-40和Gemini-1.5-Pro）之间的性能差距更为显著，这突显了最新LLMs在长上下文理解能力上的卓越表现。

然而，在coBench的两个较长数据集（即En.QA和En.MC）上观察到一个例外，即RAG在GPT-3.5-Turbo上的表现优于LC。这一结果与总体趋势相悖，可能是由于这些数据集的上下文长度显著较长（平均147k词），相比之下GPT-3.5-Turbo的上下文窗口有限（16k词）。这一发现强调了当输入文本远超模型上下文窗口大小时，RAG的有效性，突出了RAG的一个特定应用场景。

2.3 自路由(Self-Route)

2.3.1 动机

RAG在性能上落后于长上下文LLMs。然而，尽管存在这一性能差距，论文惊讶地发现它们的预测结果高度重叠，如图2所示。

图2：RAG 与LC 预测分数差异的分布（相对于真实标签计算）。无论是正确还是错误的预测，RAG 和LC 的预测结果高度一致

图 2 展示了 RAG 预测分数S_RAG 与LC 预测分数S_LC 之间的差异，具体为S_RAG - S_LC（分数乘以 100 以缩放到1 - 100）。这些分数S 表示模型预测与真实标签的评估。值得注意的是，对于大多数查询，RAG 分数和 LC 分数非常相似。实际上，对于 63% 的查询，模型预测完全相同；而对于 70% 的查询，分数差异小于 10（绝对值）。

表 1：使用 Contriever 检索器的 Gemini-1.5-Pro、GPT-3.5-Turbo 和 GPT-4O 的结果。LC 始终优于 RAG，而 SELF-ROUTE 以更少的标记实现了与 LC 相当的性能

有趣的是，相同的预测并不一定正确，正如不同颜色所代表的平均分数所示，即( S_R A G+S_L C ) / 2。这一观察表明，RAG 和LC 不仅倾向于做出相同的正确预测，还会犯类似的错误。

这一发现促使论文利用 RAG 处理大多数查询，而对于少数真正擅长处理的查询，则保留计算成本更高的 LC。通过这种方式，RAG 可以在不牺牲整体性能的情况下显著降低计算成本。

2.3.2 自路由

基于上述动机，论文提出了SELF-ROUTE，这是一种简单而有效的方法，结合 RAG 和 LC 以降低成本，同时保持与 LC 相当的性能。SELF-ROUTE 利用 LLM 自身基于自我反思来路由查询，前提是 LLM 在预测给定上下文下查询是否可回答方面具有良好的校准性。

具体而言，论文的方法包括两个步骤：RAG-and-Route 步骤和长上下文预测步骤。在第一步中，论文将查询和检索到的块提供给 LLM，并提示它预测查询是否可回答，如果可回答，则生成答案。这与标准 RAG 类似，但有一个关键区别：LLM 可以选择拒绝回答，提示为“如果查询不能基于提供的文本回答，请写‘不可回答’”。对于被认为可回答的查询，论文接受 RAG 的预测作为最终答案。对于被认为不可回答的查询，论文进入第二步，将完整上下文提供给长上下文 LLM 以获得最终预测( ie. LC )。

正如论文的结果将展示的那样，大多数查询可以通过第一步 RAG-and-Route 解决（例如，Gemini-1.5-Pro 的 82%），只有一小部分需要后续的长上下文预测步骤。由于 RAG-and-Route 步骤仅需要检索到的块（例如，1.5k 个token）作为输入，这远比完整上下文（例如，10k - 100k 个token）短得多，因此总体计算成本大大降低。详细的token计数分析将在结果部分提供。

2.3.3 结果

表1中的行-3至-5展示了论文方法的结果，利用了三个大型语言模型（LLMs）。行*_3报告了性能表现。行*-5显示了在RAG-and-Route步骤中预测的可回答查询的百分比。行*-5展示了论文方法使用的token百分比，与LC相比。就性能而言（行*-3），SELF-ROUTE显著优于RAG，达到了与LC相当的结果。在所有三个模型中，SELF-ROUTE超越了RAG（行*-2）超过5%。与LC（行*-1）相比，GPT-40和Gemini-1.5-Pro的性能略有下降（分别为-0.2%和-2.2%），但GPT-3.5-Turbo有所提升（+1.7%）。

所有三个LLMs都一致地将超过一半的查询路由到RAG，如行*-4所示。对于Gemini-1.5-Pro，可回答的百分比甚至达到了81.74%（行*-4）。这表明RAG可能在没有LC的情况下回答大多数查询，证实了论文最初的动机。

由于高可回答率，所需的token数量显著减少（行*-5）。例如，GPT-40仅使用61个token，同时达到了与LC（47.04）相当的性能（46.83），Gemini-1.5-Pro使用了38.6%的token。由于基于transformer的LLMs的计算成本与token数量成二次方关系，并且大多数LLM API根据token数量收费，这种较低的token使用量转化为显著的成本节约。

在较长的数据集上，论文的方法对于OpenAI模型的优势更为明显，但对于Gemini则不那么显著。例如，对于GPT-40，SELF-ROUTE在包含较长上下文的EN.QA和EN.MC 上分别比LC高出2.3%和7.4%。对于GPT-3.5-Turbo，优势差距更大。然而，对于Gemini-1.5-Pro，其性能低于LC。这些不同的行为可能是由于LLM对齐方式的差异，即OpenAI模型更倾向于使用RAG拒绝回答，导致可回答百分比降低但准确性提高，从而与Gemini-1.5-Pro相比产生了不同的性能-成本权衡。

2.4 分析

2.4.1 k值的消融实验

RAG和SELF-ROUTE都依赖于top-k检索的文本块。k 值越大，输入LLM进行RAG预测和路由的上下文就越长，从而导致不同的成本与性能表现。为了研究k 的影响，论文在图3中绘制了使用不同k 值时的性能和成本（即输入token百分比）曲线。

图3：(a) 模型性能与 (b) token百分比随k 变化的权衡曲线。

在性能方面，对于 RAG 和 SELF-ROUTE，较大的k 会带来更好的性能。随着k 增加，越来越多的块被输入到大型语言模型（LLMs）中，因此性能逐渐提升以接近 LC。从曲线中可以看出，SELF-ROUTE 的优势在较小的k 值时最为显著。例如，当k=1 时，RAG 的性能为 20.24%，而 SELF-ROUTE 为 37.9%；而当k 大于 50 时，所有三种方法的性能相似。

然而，SELF-ROUTE 的成本趋势并非单调。如所示，成本在k = 5 时达到最小。这是因为当k 增加时，RAG（及路由）的成本增加，但更多的查询从 LC 路由到 RAG，因此总体成本可能下降。k 的甜点可能因数据集而异，例如，平均而言，k=5 的成本最低，如曲线所示，但在某些数据集中，特别是那些包含不需要多跳推理的抽取式问题（如 NarrativeQA 和 QMSum），k=1 导致最低成本。这表明最优k 取决于任务的性质以及性能要求。论文鼓励未来研究者在将论文的方法应用于各种应用时寻找不同的k 值。

2.4.2RAG 为何失败？

为了更好地理解为什么RAG落后于LC，论文分析了RAG无法回答的示例的失败原因。论文首先手动检查了一些RAG-and-Route步骤预测为“无法回答”的示例，并总结了四种典型的失败原因，然后提示LLM对所有示例进行分类。

这四种原因包括：(A) 查询需要多步骤推理，因此需要先前步骤的结果来为后续步骤检索信息，例如“歌曲XXX的表演者是哪个国家的？”。(B) 查询是通用的，例如“group对XXX有什么看法？”，这对检索器来说很难形成一个好的查询。© 查询长且复杂，这对检索器来说很难理解。然而，回答这类问题可以说是LLMs的优势。(D) 查询是隐含的，需要对整个上下文有深入的理解。例如，在一个关于太空旅行的长篇对话叙述中，像“是什么导致了飞船后面的阴影？”这样的问题需要读者联系前后文并推断答案，因为在揭示原因时并没有明确提到阴影。

利用这些原因，论文提示Gemini-1.5-Pro使用论文手动标注的少量上下文示例来分类所有无法回答的示例。

表2：使用Dragon检索器的Gemini-1.5-Pro结果

图4：典型 RAG 失败原因的分布

论文将示例归入这四类，外加一个“其他”选项。图 4 展示了 LongBench 中七个数据集的失败原因分布。每个数据集可能包含不同数量的 RAG 失败案例，导致条形高度各异。分布模式与数据集的性质一致。例如，三个基于维基百科的多跳推理数据集（HotpotQA、2WikiMQA、MuSiQue）对 RAG 具有挑战性，因为涉及多步骤检索，如图中蓝色所示。对于包含大量对话的长故事 NarrativeQA，大多数失败案例是由于需要理解整个上下文的隐式查询（如图中绿色所示）。

对于包含开放式问题的摘要数据集 QMSum，失败大多是由于通用查询（如图中红色所示）。论文手动检查了归类为“其他”的示例，发现其中大多数实际上是多步骤问题，通常带有歧义，这给回答带来了挑战。论文希望这种失败分析能激发 RAG 未来的改进。例如，将思维链引入 RAG 可能有助于解决多步骤问题，而重新审视查询理解技术，如查询扩展，可能有助于处理通用查询和复杂查询。论文也很高兴看到近期在这方面的努力。

2.4.3 不同检索器

使用检索器 Dragon 的结果如表2 所示，基于 Gemini-1.5-Pro。可以看出，结果与 Contriever 一致，对于所有 LC、RAG 和 SELF-ROUTE，表明论文的发现可跨检索器泛化。

2.4.4 合成数据上的结果

论文主要关注真实数据集，考虑到合成数据（由研究人员人为创建）可能受数据集特性的影响。论文注意到一些研究人员采用的创建合成长上下文数据集的方法可能无意中，但很大程度上，影响 RAG 和 LC 之间的性能比较。例如，这里论文描述了 coBench 中“PassKey”数据集及其变体的结果。

这个“PassKey”数据集呈现了一个“大海捞针”的测试，其中包含一个带有密钥的句子（例如，“密钥是123456”）隐藏在大量无关文本中，模型被要求回答“什么是密钥”的问题。这项任务需要强大的检索能力。在这个数据集上，RAG达到了80.34%的准确率，超过了使用Gemini-1.5-Pro的LC，后者获得了65.25%的准确率。然而，如果查询稍微修改为“文本中隐藏的特殊标记是什么”，RAG的准确率急剧下降至仅4.58%，而LC保持大致相同（69.32%）。另一个例子：如果块中包含两个密钥，并且查询是“哪个密钥更大？第一个还是第二个？”，那么RAG（47.63%）的表现不如LC（64.24%）。这些例子表明，评估结果高度依赖于数据集构建中的偏差，显示出合成测试的局限性。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述