长上下文 LLM 会导致 RAG 的消亡吗？

关注公众号：青稞AI，第一时间了解最新AI技术
🔥青稞社区主页：qingkelab.github.io

摘要

本文讨论了尽管大型语言模型（LLM）在处理大量上下文窗口方面取得了进展，但检索增强生成（RAG）与长上下文LLM的持续相关性和潜在整合。

截至2024年7月，语言模型领域已经经历了显著的发展，大型语言模型（LLM）现在能够处理超过128K标记的上下文窗口。这一进展引发了学术界关于检索增强生成（RAG）系统未来的讨论。一些研究人员认为，像Claude 2、Gemini 1.5和Llama-3这样的长上下文LLM的能力可能会使RAG变得过时。然而，另一些研究人员则认为RAG仍然具有价值，尤其是在利基领域和成本效率方面。文章回顾了直观比较和学术研究，指出尽管长上下文LLM在某些基准测试中优于RAG，但在特定领域的准确性和成本效益方面，RAG增强型模型表现更为出色。提出了一种结合RAG与长上下文LLM的混合方法，作为利用两者优势的潜在解决方案。结论建议，RAG和长上下文LLM的协同组合可能是AI应用中最有效的前进路径。

观点

• RAG（Retrieval-Augmented Generation，检索增强生成）并未过时；它在专业领域知识和成本敏感的应用中仍然具有优势。
• 长上下文LLM（Large Language Models，大型语言模型），虽然强大，但在所有场景中可能并不实际，尤其是考虑到极长文本上下文所带来的高成本。
• 一个结合了RAG和长上下文LLM的混合模型可能会提供一个更为稳健和高效的AI系统。
• AI的未来可能不会完全转向长上下文LLM，而是RAG技术和LLM技术的整合。
• 需要对RAG和长上下文LLM进行更全面和标准化的评估，以便更好地理解它们各自的优缺点。
• 目前AI研究的趋势是探索如何有效地将RAG在信息检索中的精确性与LLM在宽广上下文理解上的能力结合起来。

长上下文LLM会导致RAG的消亡吗？

直观视角、学术研究与见解

在2023年，LLM的上下文窗口通常在4K到8K之间。然而，截至2024年7月，上下文窗口超过128K的LLM已经变得很常见。

例如，Claude 2 拥有10万的上下文窗口。Gemini 1.5 声称有200万的上下文长度，而后来的LongRoPE声称其扩展了LLM的上下文窗口至超过200万个标记。此外，Llama-3–8B-Instruct-Gradient-4194k 拥有4194K的上下文长度。看起来，使用LLM时上下文窗口的大小不再是问题。

因此人们自然会想：如果LLM能够一次性处理所有的数据，为什么还要费力去建立一个RAG系统？

因此，一些研究者宣称“RAG已死”。然而，其他研究者坚持认为长上下文LLM并不会导致RAG的终结，并且RAG仍可以焕发新生。

本文关注的是这个有趣的话题：长上下文LLM会导致检索增强生成（RAG）的消亡吗？

首先，本文从直观的角度介绍了RAG和长上下文LLM之间的比较。然后，它审视了几篇近期关于这一话题的学术论文的研究。最后，它分享了我的思考和见解。

直观比较RAG与长上下文LLM

学术界的最新研究

以上是一些直观的理解，并非严谨的评估。

长上下文LLMs（Large Language Models，大型语言模型）的出现也吸引了学术界的注意。让我们来看看最近的四篇论文：

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

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

这篇论文介绍了LOFT，这是一个现实世界的任务基准，需要多达数百万个token的上下文，以评估长上下文语言模型（LCLMs）在检索和推理方面的性能。

LOFT包括六个主要任务，其中RAG就是其中之一，如图3的上半部分所示。

图 3 左下方展示了传统的处理流程，其中包括多模态检索工具或 RAG 流程，需要几个专门系统的配合。

与之相对，图3右下方展示了长上下文语言模型（LCLM）的潜力。LCLM可以直接接收包含文本、图像、音频等多模态信息的整个语料库作为输入，通过语料库上下文（CiC）的提示方式，模型可以在统一的框架内完成检索、推理、答案生成等多项任务。

评估结果表明，Gemini 1.5 Pro 在多跳数据集（HotpotQA 和 MusiQue）上的表现优于 RAG 管道，且覆盖整个语料库上下文。这是因为 LCLM 可以使用思路链在上下文窗口内的多个段落中进行推理，而 RAG 管道通常缺乏这种能力，除非它有单独的规划和推理模块。

总体而言，在 LOFT 基准的 RAG 相关任务中，Gemini 1.5 Pro（0.53）略优于 RAG 流水线（0.52）。而 GPT-4o（0.48）和 Claude 3 Opus（0.47）的表现不如 RAG 流水线（0.52），如图 4 所示。

外，图 5 显示，尽管 LCLM 在 128K 时的性能与 RAG 相当，但与 RAG 管道相比，其性能在 1M 时有所下降。这与 LCLM 的文本检索性能下降相对应。

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

“ RAG 与长上下文”评估了 RAG 和长上下文 LLM 在需要专业知识的细分领域的表现。

通过构建 NEPAQuAD1.0 基准，评估了三款前沿 LLM——Claude Sonnet、Gemini 和 GPT-4——在回答美国联邦机构根据《国家环境政策法》（NEPA）准备的环境影响声明（EIS）问题方面的表现，如图 6 所示。

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

如图 7 所示，向 LLM 提供providing silver passages（由 RAG 管道选择）比不提供任何参考文献或提供包含问题上下文的完整 PDF 文档的效果要好得多。它甚至接近提供gold passage（专家选择）的性能。

图 8 展示了 LLM 在不同类型问题上的表现。

总体而言，RAG 增强型 LLM（silver）在答案准确率方面明显优于仅提供长上下文的模型。RAG 增强型 LLM（silver）在处理特定领域问题时具有明显优势，比仅依赖零样本知识或整个 PDF 作为上下文的模型表现更好。

此外，具有背景的 LLM（silver和gold）在回答封闭式问题时表现最佳，但在回答发散性和解决问题时表现最差。

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

本文对 RAG 和长期 LLM 进行了全面的比较，旨在充分发挥两者的优势。

该方法涉及使用三种最新的 LLM 在各种公共数据集上对 RAG 和长上下文 LLM 进行基准测试。

结果表明，在资源充足的情况下，长上下文 LLM 在平均性能方面始终优于 RAG。不过，RAG 的成本明显较低，这仍然是一个明显的优势。

图 9 展示了使用三种最新 LLM（GPT-4o、GPT-3.5-Turbo 和 Gemini-1.5-Pro）对长上下文 LLM、RAG 和论文中提出的 SELF-ROUTE 进行的比较。

SELF-ROUTE 是一种简单有效的方法，结合了 RAG 和长上下文 LLM，旨在降低成本，同时保持与长上下文 LLM 相当的性能。它使用 LLM 的自我反思来路由查询，假设 LLM 在预测给定上下文是否可以回答查询方面经过良好校准。

它包括两个步骤：RAG-and-Route步骤和长上下文预测步骤。

在第一步中，我们向 LLM 提供查询和检索到的块，并提示它预测是否可以回答查询。如果可以，LLM 会生成答案。这与标准 RAG 类似，但有一个关键区别：LLM 可以选择拒绝回答并提示“如果根据提供的文本无法回答查询，请写为无法回答”。

• 对于被认为可回答的查询，我们接受 RAG 预测作为最终答案。
• 对于被认为无法回答的查询，我们进入第二步，并将完整上下文提供给长上下文 LLM 以获得最终预测（即长上下文 LLM）。

相应提示如图10所示。

此外，本文还进行了一些有趣的分析。

首先，它检查前 k 个检索到的文本块中的 k 值如何影响结果。

图 11 显示了 (a) 模型性能和 (b) 标记百分比关于 k 的权衡曲线。

从性能上看，RAG和SELF-ROUTE的k值越大，性能越好。随着k的增大，输入到LLM中的chunk越多，性能会逐渐提高，并且越来越接近长上下文。

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

最佳 k 值可能因数据集而异。例如，平均而言，k=5在曲线上显示最低成本，但在某些数据集中，特别是那些不需要多跳推理的提取问题（例如 NarrativeQA 和 QMSum），k=1会导致最低成本。这表明最佳 k 值取决于任务的性质和性能要求。

论文还通过人工检查 RAG-and-Route 步骤预测“无法回答”的示例来分析 RAG 失败的原因。它总结了四种典型的失败原因，如图 12 中的 A 到 E 所示。

然后，使用 Gemini-1.5-Pro 和此提示对所有无法回答的示例进行分类。

图 13 显示了 LongBench 中七个数据集的故障原因分布。每个数据集可能包含不同数量的 RAG 故障案例，从而导致不同的条形高度。

我们可以看到不同数据集下的表现：

• 基于维基百科的三个多跳推理数据集（HotpotQA、2WikiMQA、MuSiQue）对于 RAG 来说具有挑战性，因为需要多步骤检索，以蓝色显示。
• 对于包含大量对话的长篇故事的 NarrativeQA，大多数失败是由于需要理解整个上下文中的隐式查询（以绿色显示）。
• 对于 QMSum（一个包含开放式问题的摘要数据集），失败主要是由于一般查询（以红色显示）。
• 归类为“其他”的例子大多是多步骤且具有歧义性的问题，因此很难回答。

ChatQA 2: Bridging the Gap to Proprietary LLMs in Long Context and RAG Capabilities

本文提出了一种基于 Llama3 的模型 ChatQA 2，旨在弥补开源 LLM 与领先的专有 LLM（如 GPT-4-Turbo）在长上下文理解和 RAG 能力方面的差距。

此外，本文还使用最先进的长上下文 LLM 对 RAG 和长上下文解决方案进行了广泛的比较。

如图 14 所示，对于序列长度为 32K 的下游任务，长上下文方案的表现优于 RAG。使用 RAG 虽然可以节省成本，但准确率会略有下降。

当上下文长度超过 100K 时，如图 15 所示，RAG 的表现优于长上下文解决方案。

这意味着，即使是目前最好的长上下文 LLM 也可能无法有效理解和推理，在现实世界的 128K 任务上表现不如 RAG 方法。因此，在这种情况下，请尝试使用 RAG 以获得更高的准确率和更低的推理成本。

个人想法和见解

RAG 不会因长期 LLM 而过时

从研究论文中我们可以看到，长上下文LLM在很多方面都超越了RAG，但是RAG在需要专业知识的细分领域以及成本方面具有明显的优势。

一般来说，RAG 可能一直存在。超长的 LLM 上下文窗口很有帮助，但每个请求处理 200k 或 1M 个 token 的成本非常高，可能高达 20 美元。

目前能想到的只有一种情况是RAG可能被长上下文的LLM取代：如果企业的应用场景比较简单，搭建RAG系统的人力和时间成本很高，那么RAG很有可能被长上下文的LLM取代。

将 RAG 与长上下文 LLM 集成

RAG 和长上下文 LLM 可以相互补充。RAG 可以从数百万或数十亿个标记中高效地检索与查询任务相关的上下文，这是长上下文 LLM 无法实现的。同时，长上下文 LLM 擅长总结整个文档，而 RAG 可能在这方面有所欠缺。

无需选择其中之一，将 RAG 与长上下文 LLM 相结合可以有效地检索和处理大规模信息，从而创建一个强大的系统。

如果将 RAG 与长上下文 LLM 结合起来，将会深刻改变当前的 RAG 范式。例如，将来可能不再需要分块过程，并且在检索过程中可能不需要精确的块级回忆。

期待更全面、更严格的评估

上述论文对RAG和长上下文LLM进行了多次评测，但其使用的数据集、评测方法和评测指标均有所不同，目前该领域还缺乏统一的评测数据集和指标。

此外，LLM 使用KV 缓存在推理过程中检索相关标记，从而降低了推理成本。但是，尚未看到 KV 缓存和 RAG 之间成本的严肃比较。

结论

本文首先对RAG与长上下文LLM进行直观的比较，然后结合近期的论文分析二者的特点，最后分享个人的见解和思考。

总体而言，长上下文的 LLM 在应用上具有更大的灵活性，但期望其解决所有问题是不现实的。关键在于探索和实施如何将长上下文的 LLM 和 RAG 解决方案的优势结合起来，以达到协同效应。