EfficientRAG: 无需高昂成本即可解决多跳问答难题

在大型语言模型 (LLM) 飞速发展的当下，检索增强生成 (Retrieval-Augmented Generation, RAG) 已成为将 AI 回答建立在现实基础上的黄金标准。通过从外部来源获取相关数据，RAG 减少了幻觉，并使模型能够回答有关特定的、私有的或最新的数据问题。

然而，有一类问题即使是标准的 RAG 系统也难以应对: 多跳问题 (multi-hop questions) 。 这些是需要多步推理才能回答的复杂查询，例如*“谁是主演了《泰坦尼克号》的那位男演员所执导电影的导演？”*

为了解决这个问题，研究人员开发了“跳跃”式检索信息的迭代方法。但这里有个问题: 这些方法通常出名地慢且昂贵，往往需要多次调用大型 LLM 仅仅是为了弄清楚下一步该搜什么。

在这篇文章中，我们将深入探讨 EfficientRAG , 这是由南京大学和微软的研究人员提出的一种新颖框架。该论文提出了一种使用轻量级模型而非重型 LLM 进行迭代检索的方法，在大幅降低延迟和成本的同时提高了准确率。

问题所在: 噪声与复杂性

标准 RAG 基于“先检索后阅读”的机制运行。你问一个问题，系统在数据库中搜索关键词，然后 LLM 阅读结果并生成答案。这对于像*“法国的首都是哪里？”*这样的简单问题非常有效。

但对于多跳问题，单次搜索往往会失败。系统可能会找到《泰坦尼克号》的演员 (莱昂纳多·迪卡普里奥) ，但却无法检索到有关他执导过的电影的信息。

为了解决这个问题，该领域转向了 迭代 RAG (Iterative RAG) 。 在这种设置下，模型检索一些信息，阅读它，意识到信息不完整，生成一个新的查询，再检索更多信息，如此反复。虽然有效，但目前的方法依赖于在每一步都调用 LLM (如 GPT-4) 来推理下一步该做什么。这引入了两个主要问题:

  1. 延迟: 串联多个 LLM 调用会使系统变慢。
  2. 噪声敏感性: 当检索到的文档包含相关事实和不相关的“噪声”混合时，即使是强大的 LLM 也会感到吃力。

研究人员进行了一项实证研究，以展示这种对噪声的敏感性。如下图所示，他们测试了 GPT-3.5、GPT-4 和 Llama-3-8B 在提供不同类型上下文时回答问题的表现。

一张分组条形图，比较了直接 (Direct) 、Oracle Chunks 和混合 Chunks (Mixed Chunks) 三种分块方法在准确率上的表现。

图 1 分析: 上图揭示了一个关键见解。蓝色条形 (Direct) 表明，如果没有检索，模型会失败。橙色条形 (Oracle Chunks) 表明，当提供完美信息时，模型表现出色。然而，请看绿色条形 (Mixed Chunks) 。当相关信息与不相关的“噪声”混合在一起时，GPT-3.5 和 Llama-3 的性能显著下降，甚至 GPT-4 的性能也有明显下滑。

这告诉我们，简单地检索更多数据并不是答案。我们需要检索更好的数据并过滤掉噪声。

EfficientRAG 登场

EfficientRAG 的核心理念很简单: 我们不需要一个万亿参数的模型来决定下一步搜索什么。

研究人员假设，识别用于下一次检索跳跃的关系和实体是一项小型的、专用模型可以有效处理的任务。通过将关于下一步搜索内容的“推理”工作卸载给轻量级模型，EfficientRAG 完全消除了中间环节的 LLM 调用。

架构设计

EfficientRAG 用两个基于较小编码器模型 (DeBERTa-v3-large) 的轻量级组件替换了检索循环中的重型 LLM:

  1. 标注器与标记器 (Labeler & Tagger) : 该组件查看检索到的文档。它“标注 (Label) ”有用的特定 Token (单词) ，并“标记 (Tag) ”文档以决定我们是否拥有足够的信息，或者是否需要继续搜索。
  2. 过滤器 (Filter) : 该组件获取由标注器识别出的有用 Token，并为下一次搜索构建一个新的、有针对性的查询。

让我们看看这个流程在实践中是如何运作的:

EfficientRAG 框架示意图，展示了从查询到检索、标注、标记和过滤的流程。

框架流程解析 (图 3) :

  1. 初始查询: 用户提问: “KGOT 广播电台工作室所在的购物中心有多大？”
  2. 检索: 系统检索文本块。
  3. 标注器与标记器:
  • *文档块 1 (上方路径) : * 讨论了 KGLK 和 KHPT 电台。标记器将其标记为 <Terminate> (无用) 或直接过滤掉，因为它不包含关于 KGOT 的已标注 Token。
  • 文档块 2 (下方路径) : * 包含句子“KGOT 在 Dimond Center 的工作室广播。”* 标注器将“KGOT”和“Dimond Center”识别为关键信息。标记器将此块标记为 <Continue>，因为虽然我们找到了地点，但我们仍然不知道它有多大。
  1. 过滤器: 过滤器获取原始问题和新发现的事实 (“KGOT，在 Dimond Center”) 。它将它们结合起来生成下一个查询: “Dimond Center 有多大？”
  2. 迭代: 这个新查询被送回检索器。

至关重要的是，整个循环过程无需提示基于聊天的 LLM。最终答案仅在检索过程完成并验证后，由 LLM 生成一次。

“Token 标注”的力量

这种方法的一个独特之处在于 Token 标注 (Token Labeling) 。 EfficientRAG 不要求模型“重写查询” (这需要生成新文本——一个缓慢的过程) ，而是将问题视为分类任务。

标注器查看检索到的文本，并将每个 Token 分类为 True (有用) 或 False (无关) 。然后，过滤器本质上执行“填空”操作，用文本中找到的已标注 Token 替换原始查询中的未知部分。这在计算成本上要低得多。

合成数据构建

你可能会问: 如何训练一个小模型知道哪些 Token 是重要的？

由于不存在大量的“问题映射到段落中特定有用 Token”的数据集，研究人员使用教师 LLM (Llama-3-70B) 合成了他们自己的数据。

他们将教师 LLM 的过程分为四个步骤:

  1. 分解 (Decomposition) : 将多跳问题分解为单跳子问题。
  2. Token 标注 (Token Labeling) : 要求 LLM 识别文档中确切回答子问题的单词。
  3. 下一跳过滤 (Next-hop Filtering) : 要求 LLM 制定下一个搜索查询应该是什么。
  4. 负采样 (Negative Sampling) : 寻找棘手但不相关的文档，以训练模型不使用什么。

然后，这些合成数据被用于微调较小的 DeBERTa 模型，有效地将大模型的推理能力蒸馏到一个更快、更专业的架构中。

实验结果

研究人员将 EfficientRAG 与几个基准进行了对比测试，包括:

  • Direct: 无检索的标准 QA。
  • Direct-R: 标准的单跳 RAG。
  • Iter-RetGen & SelfAsk: 使用 LLM 进行查询重写的先进迭代方法。

评估涵盖了三个具有挑战性的多跳数据集: HotpotQA、MuSiQue 和 2WikiMQA 。

1. 检索效率

首先要回答的问题是: EfficientRAG 真的能找到正确的文档吗？

折线图比较了不同输入规模下的召回率表现。Efficient RAG Decompose 始终能够实现更高的召回率。

如 图 2 所示，EfficientRAG (蓝线) 在 召回率 (Recall) 方面表现优于直接检索，甚至优于基于 LLM 的分解。

  • X 轴代表检索到的文档块数量 (对数刻度) 。
  • Y 轴代表召回率 (找到了多少必要信息) 。

注意蓝线是如何更快上升的吗？这意味着 EfficientRAG 更早地找到了相关信息，只需更少的文档块就能获得全貌。标准的分解方法 (绿线) 最终会赶上，但它们需要检索更多的数据才能做到这一点。

2. 计算效率

这无疑是这篇论文最具影响力的结果。由于 EfficientRAG 在中间步骤使用了小模型，它应该更快。但快多少呢？

表格对比了 LLM 调用次数、迭代次数、延迟和 GPU 使用率等效率指标。

表 4 呈现了一个鲜明的对比:

  • LLM 调用次数: EfficientRAG 仅需 1.00 次调用 (用于最终回答) 。相比之下, Iter-RetGen 需要 3.00 次 , SelfAsk 需要 7.18 次 。
  • 延迟: EfficientRAG 耗时约 3.62 秒 。 SelfAsk 则耗时惊人的 27.47 秒 。
  • 加速比: EfficientRAG 比 Iter-RetGen 快约 3 倍 , 比 SelfAsk 快近 8 倍 , 同时保持了相似的 GPU 使用率。

这种延迟的大幅降低使得迭代 RAG 在用户无法等待 30 秒才能得到答案的实时应用中变得可行。

3. 端到端准确率

如果答案是错的，速度再快也没用。幸运的是，EfficientRAG 在这方面也表现出色。

表格展示了 2WikiMQA 数据集上的端到端 QA 性能。EfficientRAG 达到了最先进 (SOTA) 的准确率。

在 表 5 中，使用 GPT-3.5 作为最终生成器，EfficientRAG 达到了 53.41 的准确率，击败了先进的 Iter-RetGen 方法 (46.59) 和标准的直接检索 (32.70) 。

通过在不相关的文档块到达最终 LLM 之前将其过滤掉，EfficientRAG 提供了“更干净”的上下文，使生成器能够更准确地回答问题。

4. 泛化能力

最后，研究人员测试了模型是否能处理它未经过训练的数据集 (域外适应) 。

表格展示了域外实验结果。EfficientRAG 在不同数据集之间表现出了可迁移性。

表 6 显示，在 HotpotQA 上训练的模型在 2WikiMQA 上测试时表现惊人地好，反之亦然。这表明识别有用 Token 和过滤噪声的“技能”是一种可泛化的能力，而不仅仅是对特定数据集模式的死记硬背。

结论与启示

EfficientRAG 代表了我们设计 RAG 系统方式的一个重大转变。它挑战了我们需要在每个子问题上都投入更多 LLM 算力的假设。

关键要点:

  1. 专业化优于规模化: 小型、微调过的模型 (如 Labeler/Filter) 在查询制定等特定结构化任务上可以胜过通用 LLM。
  2. 噪声是敌人: 改进 RAG 不仅仅是找到更多文档；而是要积极地过滤掉错误的文档。
  3. 效率解锁可用性: 通过将 LLM 调用从 7 次以上减少到 1 次，多跳 QA 在对成本和延迟敏感的生产环境中变得可行。

对于学生和从业者来说，这篇论文提醒我们: 在将多个昂贵的 API 调用串联起来之前，请考虑是否可以用更小的、训练有素的组件更快、更好地完成工作。随着 AI 系统变得越来越复杂，像 EfficientRAG 这样的效率优化将是其规模化应用的关键。