RAG vs 长上下文 LLMs：谁主沉浮？

2024-10-16
北京
本文字数：6634 字
阅读完需：约 22 分钟

编者按：随着大语言模型（LLMs）的上下文窗口不断扩大，您是否开始思考：我们还需要花费大量时间和资源来构建复杂的检索增强生成（RAG）系统吗？
本文深入探讨了长上下文 LLMs 与 RAG 系统的优劣势，揭示了它们在实际应用中的表现差异。通过对最新四篇学术研究的全面分析，作者阐明了长上下文 LLMs 在某些任务中的优势，同时也指出了 RAG 系统在某些专业领域任务和成本效益方面仍具有优势。
作者建议将 RAG 与长上下文 LLMs 结合使用，以发挥协同效应，并呼吁建立更全面、更严格的评估体系，包括统一的评估数据集和评估指标。未来，如何有效结合这两种技术，应当是人工智能领域的一个重要研究方向。

作者 | Florian June

编译 | 岳扬

2023 年，大语言模型（LLMs）的上下文窗口通常在 4K 到 8K 左右。但到了 2024 年 7 月，上下文窗口超过 128K 的 LLMs 已经变得很普遍了。

以 Claude 2[1] 为例，其上下文窗口可达 100K。Gemini 1.5[2] 则宣称能够处理 2M 的上下文信息，而 LongRoPE[3] 更是将 LLMs 的上下文窗口扩展到了 200 万个 tokens 以上。Llama-3–8B-Instruct-Gradient-4194k[4] 的上下文窗口更是达到了 4194K 。在应用大语言模型时，上下文窗口的大小似乎已经不再是限制因素。

于是，有人提出了这样的观点：既然 LLMs 能够一次性处理所有数据，那么还有必要建立检索增强生成（RAG）[5]系统吗？

因此，有一些研究人员宣称“ RAG 已死”。但也有人认为，即便有了长上下文窗口的 LLMs， RAG 系统也不会因此消亡，RAG 仍然可以焕发新的活力。

本文将重点讨论这个有趣的话题：长上下文 LLMs 是否会导致检索增强生成（RAG）系统[5]的淘汰？

图 1：RAG vs Long-Context LLMs. Image by author.

文章开头，我们将从直观的角度比较 RAG 与具备长上下文窗口的大语言模型（LLMs）。接着，我们将分析几篇针对这一议题的最新学术论文。文章的最后，我将分享自己的一些思考和见解。

01 RAG 与长上下文 LLMs 的对比分析

图 2 展示了 RAG 与具备长上下文窗口的 LLMs 在不同方面的直观对比。

图 2：RAG 与长上下文 LLMs 不同维度的对比分析。

02 学术界最新研究成果

以上内容帮助我们建立一些直观的认识，并非对这些技术严谨的比较。

长上下文 LLMs 的出现同样引起了学术界的关注。以下是最新的四篇研究论文，我们将一探究竟。

Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?[6]
RAG vs. Long Context: Examining Frontier Large Language Models for Environmental Review Document Comprehension[7]
Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach[8]
ChatQA 2: Bridging the Gap to Proprietary LLMs in Long Context and RAG Capabilities[9]

2.1 Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?

该论文[6]提出了 LOFT 基准测试，这是一个模拟真实任务场景的测试环境，需要处理上百万个 tokens 的上下文，用以评估长上下文语言模型（LCLMs）在信息检索和逻辑推理方面的能力。

LOFT 涵盖了六个主要任务场景，如图 3 上半部分所示，RAG 便是其中之一。

图 3：An overview of the LOFT benchmark. Source: Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?.[6]

图 3 的左下角展示的是传统的处理流程，其中包括多模态检索工具或 RAG pipeline，需要多个专业系统的协同工作。

与此相对的是，图 3 的右下角展示的是长上下文语言模型（LCLM）。 LCLM 能够直接将包含文本、图像和音频等多种模态信息的整个语料库作为模型输入。通过采用 “Context in Corpus”（CiC）提示词技术，模型能够在统一的框架内完成包括检索、推理和答案生成在内的多种任务。

评估结果表明，在 multi-hop datasets（译者注：在阅读理解等自然语言处理任务中，一个问题的答案可能需要从多个不同的段落或文档中获取信息。这种情况下，我们就说这个问题需要"多跳"（multi-hop）来回答。包含了这类问题的数据集就被称作是 multi-hop datasets。）（如 HotpotQA 和 MusiQue）上，Gemini 1.5 Pro 在处理整个语料库上下文时的表现优于 RAG pipeline。这是因为 LCLM 能够使用思维链 [10] 在上下文窗口内跨多个段落进行推理，而 RAG pipeline 通常不具备这种能力，除非它额外配备有规划（planning）和推理（reasoning）模块。

总体来看，在 LOFT 基准测试中与 RAG 相关的任务中，Gemini 1.5 Pro（0.53）的表现略胜于 RAG pipeline（0.52）。而 GPT-4o（0.48）和 Claude 3 Opus（0.47）的表现则不如 RAG pipeline（0.52），这一结果在图 4 中有详细展示。

图 4 ：在 LOFT 128k 上下文的基准测试集上的主要实验结果。Source: Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?[6]

此外，图 5 显示，虽然 LCLM 在 128K 上下文窗口的性能与 RAG 表现相当，但当上下文扩展到 1M 时，其性能相较于 RAG pipeline 有所下降。 这一趋势与 LCLM 在文本检索性能上的衰退是一致的。

图 5：LCLM 与各垂直场景模型在语料库大小从 32K 扩充至 100 万 tokens 时的性能对比。这些结果是在每个任务所包含的所有数据集上平均计算得出的。Source: Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?.[6]

2.2 RAG vs. Long Context: Examining Frontier Large Language Models for Environmental Review Document Comprehension

“RAG vs. Long Context”[7]研究评估了 RAG 和长上下文 LLMs 在那些需要专业领域知识的特定任务场景中的表现。

通过构建 NEPAQuAD 1.0 基准测试，本研究对三种先进的 LLMs —— Claude Sonnet、Gemini 和 GPT-4 —— 在回答美国联邦机构（U.S. federal agencies）根据《National Environmental Policy Act》（NEPA）编写的环境影响报告书（EIS）中相关问题的能力进行了评估，具体请见图 6。

图 6：在比较中使用的不同环境影响报告书（EIS）上下文的示例，其中精选的 Gold passages 由领域专家挑选。Source: RAG vs. Long Context[7].

评估结果表明，不论选择哪种前沿的 LLM，基于 RAG 的模型在答案准确性方面都明显优于长上下文模型。

图 7：在不同上下文配置下，LLMs 在 EIS 文档上的答案正确性评估结果。其中，silver passages 是通过 RAG pipeline 筛选的，而 gold passages 则是由专家挑选的。Source: RAG vs. Long Context[7].

如图 7 所示，当向 LLMs 提供 RAG pipeline 筛选出的 silver passages 时，其表现显著优于不提供任何参考文献或提供含有问题上下文的完整 PDF 文档。其表现甚至接近于提供专家挑选的 gold passages。

图 8 则展示了 LLMs 在不同类型问题上的性能表现。

图 8：比较不同语言模型在四种不同上下文应用场景下回答各类型问题的正确性得分。Source: RAG vs. Long Context[7].

总体而言，RAG 增强的 LLMs（silver passages）在答案准确性上明显优于仅提供长上下文的模型。特别是在处理特定垂直领域的问题时，RAG 增强的 LLMs（silver passages）具有明显优势，其表现优于那些仅依靠零样本知识（zero-shot knowledge）或完整 PDF 文档作为上下文的模型。

另外，在回答封闭式问题时，带有上下文（silver passages 和 gold passages）的 LLMs 表现最为出色；然而，在应对发散性问题和解题型问题时，它们的表现则相对较差。

2.3 Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach

本文[8]对 RAG 与长上下文 LLMs 进行了全面比较，目的是发现并利用两者的长处。

研究方法包括使用三种最新的 LLMs，在多个公开数据集上对 RAG 和长上下文 LLMs 进行基准测试。

研究发现，在资源充足的情况下，长上下文 LLMs 的平均性能始终优于 RAG。不过，RAG 的成本明显更低，这仍然是一个明显的优势。

图 9 展示了使用 GPT-4o，GPT-3.5-Turbo 和 Gemini-1.5-Pro 这三种最新 LLMs 的长上下文 LLMs、RAG 以及本论文提出的 SELF-ROUTE 方法的比较结果。

图 9：尽管长上下文 LLMs（LC）在处理、理解长上下文方面胜过 RAG，但 RAG 在成本效益上具有明显优势。Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

SELF-ROUTE 是一种结合了 RAG 和长上下文 LLMs 的一种简便而有效的方法，目的是在降低成本的同时，还能保持与长上下文 LLMs 相媲美的性能。该方法利用 LLMs 的自我反思能力来路由 queries ，并假定 LLMs 能够准确预测现有上下文是否足以回答 queries。

该方法分为两个阶段：首先是 RAG 及路由阶段，然后是长上下文预测阶段（long-context prediction step）。

在第一阶段，我们向 LLMs 提供查询和检索到的文本块，并引导它预测是否能够回答 query 。如果可以，LLMs 就会生成答案。这一过程与标准 RAG pipeline 类似，但有一个关键区别：LLMs 有权选择不回答，并在提示词中注明“如果基于现有文本无法回答 query，请写‘无法回答’”。

对于那些判断为可以回答的 query ，我们直接采用 RAG 的预测结果作为最终答案。对于那些判断为不可以回答的 query ，我们则进入第二阶段，将完整的上下文提供给长上下文 LLMs 以获得最终的预测结果。相关的提示词内容展示在图 10 中。

图 10：为每个数据集提供有相应的提示词。Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

此外，该论文还进行了几项有趣的分析。

首先，本论文探讨了在使用 top-k 方法检索到的文本块中 k 值如何影响检索结果。

图 11：随着 k 的增加，模型性能和实际使用的 token 百分比的变化曲线（a）和（b）。Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

图 11 展示了随着 k 的增加，模型性能和实际使用的 token 百分比的变化曲线（a）和（b）。

在性能方面，对于 RAG 和 SELF-ROUTE，k 值越大，性能越好。随着 k 的增加，更多文本块被输入到 LLMs 中，性能逐渐提升，逐渐接近长上下文。

从变化曲线中可以看出，在 k 值较小时，SELF-ROUTE 的性能优势最为明显，而当 k 超过 50 时，三种方法的性能表现趋于相同。

最优的 k 值可能因数据集而异。例如，平均而言，k=5 在曲线上显示的成本最低，但在某些数据集上，尤其是那些不需要 multi-hop 推理的提取式问题数据集（如 NarrativeQA 和 QMSum ），k=1 的成本最低。这表明，最优的 k 值取决于任务的性质和性能要求。

该论文还通过手动检查 RAG-and-Route 步骤预测为“无法回答（unanswerable）”的示例，分析了 RAG 系统失败的原因。它总结了四种典型的失败原因，如图 12 从 A 到 E 所示。

图 12：Prompt for the failure case analysis. Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

接下来，使用 Gemini-1.5-Pro 对提示词进行处理，以识别所有无法回答的示例。

图 13 展示了 LongBench 中七个数据集中失败原因的分布情况。每个数据集可能包含不同数量的 RAG 失败案例，因此条形图的高度也会有所不同。

图 13：典型的 RAG 失败原因分布。Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

我们观察到各技术在不同数据集下的性能表现：

基于维基百科的三个 multi-hop 推理数据集（HotpotQA、2WikiMQA、MuSiQue）因为它们需要进行多步检索，对 RAG 而言具有挑战性，如图中蓝色部分所示。
对于 NarrativeQA，其拥有包含大量对话的长故事，大多数失败原因是由于需要理解整个上下文中的 implicit queries（译者注：指的是那些没有直接在文本中表达的 query，可能隐藏在上下文中，需要通过上下文理解、推理和推断来确定。），如图中绿色部分所示。
QMSum 是一个包含开放式问题的摘要数据集，主要失败原因是通用的 queries，如图中红色部分所示。
被分类为“其他（other）”的示例大多是多步问题（multi-step questions），这些问题由于具有模糊性而难以回答。