RAG还是长上下文LLM？一个混合方法

24年7月来自谷歌deepmind和密西根大学的论文“Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach”。

检索增强生成 (RAG) 一直是大语言模型 (LLM) 有效处理过长上下文的强大工具。然而，最近的 LLM 如 Gemini-1.5 和 GPT-4 表现出直接理解长上下文的卓越能力。对 RAG 和长上下文 (LC) LLM 进行全面比较，旨在充分发挥两者的优势。用三个最新的 LLM 在各种公共数据集上对 RAG 和 LC 进行基准测试。结果表明，在资源充足的情况下，LC 的平均性能始终优于 RAG。然而，RAG 显著更低的成本仍然是一个明显的优势。

基于以上观察，提出 SELF-ROUTE，一种简单而有效的方法，它基于模型自我反思将查询路由到 RAG 或 LC。SELF-ROUTE 显著降低计算成本，同时保持与 LC LLM 相当的性能。

对长上下文 (LC) LLM 和 检索增强生成 (RAG) 进行系统比较：一方面，RAG 在概念上充当先验，将 LLM 的注意正则化到检索的片段上，从而避免无关信息的干扰，并节省不必要的注意计算；另一方面，大规模预训练可能使LLM能够开发出更强大的长上下文能力。因此，工作的目标是比较RAG和LC，评估它们的性能和效率。

如图所示：虽然长上下文 LLM 在长上下文理解方面优于 RAG，但 RAG 的成本效率明显更高。提出的方法 SELF-ROUTE 将 RAG 与 LC 相结合，以更低的成本实现了与 LC 相当的性能。

评估三个最新的 LLM，包括 Gemini-1.5-Pro（Reid，2024）、GPT-4O（OpenAI，2024a）和 GPT-3.5-Turbo（OpenAI，2023）。Gemini-1.5-Pro 是谷歌最近推出的一款长上下文 LLM，支持多达 100 万个 token。GPT-4O 是 OpenAI 最新推出的轻量级但功能强大的 LLM，支持 128k 个 token。GPT-3.5-Turbo 支持 16k 个 token。

研究中使用两种检索器：Contriever（Izacard，2021），这是一种经过对比训练的密集检索器，在 BEIR 数据集上的表现优于 BM25；Dragon（Lin，2023），这是一种最近可泛化的密集检索器，在监督和零样本设置中均实现了高性能，而无需复杂的后期交互。

按照 (Xu et al., 2023) 的方法，将长上下文划分为 300 个单词的块，并根据查询嵌入和块嵌入的余弦相似度选择前 k 个块 (默认 k = 5)。块按相似度得分排序，块索引放在开头。

由于黑盒子 LLM 是在未知数据集上进行预训练的，因此可能会发生评估数据集的泄露。特别是，一些评估数据集基于维基百科，LLM 可能在训练过程中已经使用这些数据集。在某些情况下，模型可以使用与真值完全相同的单词 (例如“meticulously”) 来预测正确答案，即使它们没有出现在提供的上下文中。在实验中，尝试提示模型对 RAG 和 LC 都“仅基于提供的段落”来回答，以此缓解此问题。如何解决LLM评估中的数据泄露问题，仍然是一个悬而未决的问题。

如表显示使用 Contriever 检索器的结果，其中行 *-1 和行 *-2 分别显示 LC 和 RAG 的基准测试结果。

使用 Dragon 检索器的结果在下表：

SELF-ROUTE 利用 LLM 本身基于自我反思来路由查询，假设 LLM 能够很好地预测：给定上下文的查询是否可以回答。

具体来说，该方法包括两个步骤：“RAG -和-路由”和“长-上下文预测”。在第一步中，将查询和检索的块提供给 LLM，并提示它预测查询是否可以回答，如果可以，则生成答案。这与标准 RAG 类似，但有一个关键区别：LLM 可以选择拒绝回答，提示是“如果根据提供的文本，无法回答查询，则写作无法回答”。对于被认为可以回答的查询，接受 RAG 预测作为最终答案。对于被认为无法回答的查询，继续第二步，将完整上下文提供给长上下文 LLM 以获得最终预测（即 LC）。

正如结果所示，大多数查询都可以通过第一步 RAG-and-Route 解决（例如，Gemini-1.5-Pro 为 82%），只有一小部分需要执行接下来的第二步：长上下文预测。由于 第一步 RAG-and-Route 只需要检索的块（例如，1.5k 个 tokens）作为输入，这比完整的上下文（例如，10k - 100k 个 tokens）短得多，因此总体计算成本大大降低。结果将提供详细的tokens数分析。

本文评估的数据集有7个，其统计分析如下：

下表显示研究中每个数据集的提示。这些提示是根据发布的提示修改而来的，例如 LongBench（Bai，2023）和 ∞Bench（Zhang，2024）。

为了更好地理解 RAG 落后于 LC 的原因，分析了 RAG 无法回答示例的失败原因。首先手动检查一 RAG-和-路由 步预测为“无法回答”的示例，并总结出四种典型的失败原因，然后提示 LLM 对所有示例进行分类。这四个原因包括：（A）查询需要多步推理，因此需要前面步骤的结果来检索后面步骤的信息，例如“歌曲 XXX 的演唱者是哪个国籍？”。（B）查询是通用的，例如“小组对 XXX 有什么看法？”，这对于检索器制定的查询来说是一个挑战。（C）查询很长而且很复杂，这对检索器来说很难理解。然而，回答这类问题可以说是 LLM 的优势。（D）查询是隐式的，要求彻底理解整个上下文。例如，在一篇关于太空旅行的长篇对话叙述中，像“是什么导致宇宙飞船后面的阴影？”这样的问题需要读者把各个线索联系起来，推断出答案，因为在揭示原因时并没有明确提到阴影。