目录
01 RAG 与长上下文大语言模型：全面对比分析
02 最新学术研究成果深度解析
2.1 长上下文语言模型能否替代检索、RAG、SQL 等传统技术？
2.2 RAG 对垒长上下文：评估前沿大模型在环境审查文档理解中的表现
2.3 检索增强生成还是长上下文大模型？一项综合研究与混合策略方案
2.4 ChatQA 2：填补长上下文与RAG能力在开源模型与闭源模型之间的鸿沟
03 个人观点与深入思考
3.1 长上下文大模型不会让RAG沦为过去式
3.2 将RAG与长上下文大模型巧妙融合
3.3 渴望更全面、更严谨的评估体系
04 结语
?文中链接?
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）系统[5]走向终结？
图 1：RAG vs Long-Context LLMs. Image by author.
开篇，我们先从直观角度对RAG与长上下文LLMs进行对比。接着，深入剖析几篇最新的学术论文。最后，分享一些个人的观察与思考。
01 RAG 与长上下文大语言模型：全面对比分析
图 2 从多个维度直观展示了RAG与长上下文窗口LLMs之间的差异。
图 2：RAG 与长上下文 LLMs 不同维度的对比分析。
02 最新学术研究成果深度解析
上述内容有助于建立直观认识，但并非严谨的技术对比。长上下文LLMs的出现同样引起了学术界的广泛关注。以下四篇最新研究或许能带我们一探究竟。
长上下文语言模型能否替代检索、RAG、SQL 等传统技术？[6]
RAG 对垒长上下文：评估前沿大模型在环境审查文档理解中的表现[7]
检索增强生成还是长上下文大模型？一项综合研究与混合策略方案[8]
ChatQA 2：填补长上下文与RAG能力在开源模型与闭源模型之间的鸿沟[9]
2.1 长上下文语言模型能否替代检索、RAG、SQL 等传统技术？
这篇论文[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）提示词技术，模型可以在一个统一框架内完成检索、推理和答案生成等多种任务。
评估结果表明，在多跳数据集（如HotpotQA和MusiQue）上，Gemini 1.5 Pro在处理整个语料库上下文时的表现优于RAG pipeline。其原因在于LCLM能够使用思维链[10]在上下文窗口内跨多个段落进行推理，而RAG pipeline通常不具备这种能力，除非额外配备规划和推理模块。
总体来看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 对垒长上下文：评估前沿大模型在环境审查文档理解中的表现
“RAG vs. Long Context”[7]这项研究评估了RAG和长上下文LLMs在需要专业领域知识的特定任务场景中的表现。
通过构建NEPAQuAD 1.0基准测试，该研究对三种先进的LLMs——Claude Sonnet、Gemini和GPT-4——回答美国联邦机构根据《国家环境政策法案》（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 检索增强生成还是长上下文大模型？一项综合研究与混合策略方案
这篇论文[8]对RAG与长上下文LLMs进行了系统性比较，目标不仅仅是比出高下，更是要发掘并利用两者的长处。
研究方法很直接：使用三种最新的LLMs，在多个公开数据集上对RAG和长上下文LLMs进行基准测试。
研究发现耐人寻味：在资源充足的情况下，长上下文LLMs的平均性能始终优于RAG。但另一边，RAG的成本优势非常明显，这仍然是它的一张王牌。
图 9 展示了使用GPT-4o、GPT-3.5-Turbo和Gemini-1.5-Pro这三种最新LLMs的长上下文LLM、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的自我反思能力来路由查询请求，并假设LLMs能够准确预测现有上下文是否足以回答查询。
该方法分为两个阶段：首先是RAG及路由阶段，然后是长上下文预测阶段。
在第一阶段，向LLMs提供查询和检索到的文本块，并引导它预测是否能够回答该查询。如果可以，LLMs就会生成答案。这一过程与标准RAG pipeline类似，但有一个关键区别：LLMs有权选择不回答，并在提示词中注明“如果基于现有文本无法回答该查询，请写‘无法回答’”。
对于那些判断为可以回答的查询，直接采用RAG的预测结果作为最终答案。对于那些判断为无法回答的查询，则进入第二阶段，将完整的上下文提供给长上下文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百分比的变化趋势。
在性能方面，对于RAG和SELF-ROUTE，k值越大，性能越好。随着k的增加，更多文本块被输入到LLMs中，性能逐渐提升，越来越接近长上下文的水平。
从变化曲线中可以看出，在k值较小时，SELF-ROUTE的性能优势最为明显，而当k超过50时，三种方法的性能表现趋于相同。
最优的k值可能因数据集而异。例如，平均而言，k=5在曲线上显示的成本最低，但在某些数据集上，尤其是那些不需要multi-hop推理的提取式问题数据集（如NarrativeQA和QMSum），k=1的成本最低。这表明，最优的k值取决于任务的性质和性能要求。
该论文还通过手动检查RAG-and-Route步骤预测为“无法回答”的示例，分析了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），如图中绿色部分所示。
QMSum是一个包含开放式问题的摘要数据集，主要失败原因是通用的queries，如图中红色部分所示。
被分类为“其他”的示例大多是多步问题（multi-step questions），这些问题由于具有模糊性而难以回答。
2.4 ChatQA 2：填补长上下文与RAG能力在开源模型与闭源模型之间的鸿沟
本研究提出了一款名为ChatQA 2的新模型，该模型基于Llama3，旨在缩小开源大语言模型与顶级闭源大语言模型（如GPT-4-Turbo）在长上下文理解和RAG能力方面的差距。
此外，该研究还使用最先进的长上下文LLM对RAG和长上下文解决方案进行了全面比较。
如图 14 所示，对于序列长度为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 个人观点与深入思考
3.1 长上下文大模型不会让RAG沦为过去式
从上述研究论文中可以看出，长上下文LLMs在许多方面都超越了RAG，但在需要专业知识的细分领域和成本控制方面，RAG仍握有牢固的筹码。
RAG大概率会持续存在。超长的LLMs上下文窗口固然诱人，但处理每个请求200k或1M个tokens的成本实在高昂，有时可能高达20美元[11]。
目前来看，RAG被长上下文LLM取代的唯一可能情况是：如果企业的应用场景相对简单，而搭建RAG系统的开发与时间成本又特别高，那么长上下文LLM或许会成为一个替代方案。
3.2 将RAG与长上下文大模型巧妙融合
与其说谁取代谁，不如说两者是互补关系。RAG擅长从数百万甚至数十亿个tokens中高效检索与任务相关的上下文，这是长上下文LLM力所不能及的。而长上下文LLM则擅长总结整个文档，这恰恰是RAG的短板。
与其二选一，不如将两者结合。这样既能高效地检索，又能处理大规模信息，从而构建一个更强大的系统。
如果将RAG与长上下文LLM整合起来，它很可能会深刻改变当前的RAG范式。例如，在未来的应用中，可能不再需要进行繁琐的分块处理，也无需在检索过程中追求精确的块级召回。
3.3 渴望更全面、更严谨的评估体系
上述论文对RAG和长上下文LLM进行了多项评估，但它们所使用的数据集、评估方法和评估指标各不相同。该领域明显缺乏一个统一的、公认的评估标准。
此外，LLM在推理过程中利用KV缓存[12]来检索相关tokens，这有助于降低推理成本。不过，KV缓存和RAG之间的成本具体如何对比，目前尚未见到相关报道。
04 结语
本文首先直观地比较了RAG与长上下文LLM，然后根据最新论文研究分析了它们各自的特点，最后分享了个人见解。
总的来说，长上下文LLM在应用上具有更大的灵活性，但期望它们解决所有问题显然不现实。关键在于探索并践行将两者优势相结合的方法，以实现真正的协同效应（synergistic effect）。
Thanks for reading! Hope you ha ve enjoyed and learned new things from this blog!