图 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），这些问题由于具有模糊性而难以回答。
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 来提高准确率和降低推理成本。
