【本文正在参与 AI.x社区AIGC创新先锋者征文大赛】
作者 |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 的出现同样引起了学术界的关注。以下是最新的四篇研究论文，我们将一探究竟。
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>总体来看，在 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]
我们观察到各技术在不同数据集下的性能表现：
2.4 ChatQA 2: Bridging the Gap to Proprietary LLMs in Long Context and RAG Capabilities
本研究提出了一种名为 ChatQA 2 的新模型，该模型基于 Llama3，目的是缩小开源大语言模型与顶级闭源大语言模型（如GPT-4-Turbo）在长上下文理解和 RAG 能力方面的差距。
此外，该研究还使用最先进的长上下文 LLM 对 RAG 和长上下文解决方案进行了全面比较。
如图 14 所示， 对于序列长度（sequence length）为 32K 的下游任务，长上下文解决方案在性能上优于 RAG。虽然使用 RAG 可以节省成本，但可能会略微降低准确率。
图 14：在最大输入为 32K tokens 的基准测试上，对 RAG 与长上下文进行评估比较。Source: ChatQA 2[9]
如图 15 所示， 当上下文长度超过 100K 时，RAG 的性能优于长上下文解决方案。
图 15：在最大输入超过 100K tokens 的任务上，对 RAG 与长上下文进行评估。Source: ChatQA 2[9]
这表明，即使是最先进的长上下文 LLM ，也可能难以有效地理解和推理，在现实世界的 128K 任务中，其表现可能不及 RAG 方法。因此，在这种情况下，可以考虑使用 RAG 来提高准确率和降低推理成本。
03 My Thoughts and Insights
以下是我的一些思考和见解。
3.1 长上下文 LLMs 不会使 RAG 过时
从研究论文中我们可以看到，长上下文 LLMs 在许多方面都超过了 RAG，但在需要专业知识的细分领域和成本方面，RAG 仍具有明显优势。
RAG 可能会持续存在。超长 LLMs 上下文窗口很有帮助，但处理每个请求 200k 或 1M 个 tokens 的成本非常高，可能高达 20 美元[11]。
目前，我能想到的唯一一种 RAG 可能会被长上下文 LLM 取代的情况是： 如果企业的应用场景相对简单，而建立 RAG 系统的人力成本