论文解读：Auto-RAG--用推理替代规则，让大模型自主掌控迭代检索

过去几年，RAG（检索增强生成）几乎成了大模型落地应用的标配。逻辑简单直接：模型不知道的，就去外部知识库查一查，再把检索结果拼进上下文里回答。

但当问题变得复杂——一个多跳推理问题、一个需要逐步拆解的调查型问题——"查一次"就够了吗？

不够。而且差很多。

现实中的复杂问题往往需要多轮检索：先查到A，发现A里提到了B，再去查B，才能最终拼出答案。这就是迭代检索（Iterative Retrieval）的出发点。

但问题随之而来。现有的迭代RAG方案，几乎都有一个共同的硬伤——都靠人来"指挥"检索：要么手动写few-shot prompt告诉模型"这种情况下要检索"，要么设计一堆规则定义"什么时候停、什么时候继续"。

大模型本身强大的推理能力？白白浪费掉了。

就在这种"能力放着不用、规则堆着费力"的关键节点，中国科学院计算技术研究所（ICT/CAS）团队发布了Auto-RAG——一个把迭代检索的控制权彻底交还给大模型自身推理能力的系统。

研究团队由ICT/CAS智能信息处理重点实验室的于天（Tian Yu）、张少磊（Shaolei Zhang）组成，通讯作者为冯洋（Yang Feng）——同时兼任中国科学院AI安全重点实验室成员。三人均为中国科学院大学在籍研究人员。这支队伍的切入点很务实：不造新架构，不换基座模型，用数据工程和指令微调，让现有开源大模型学会推理驱动的自主决策。

1.迭代检索为什么难？三条死路先看清楚

要理解Auto-RAG解决了什么，先看清楚"迭代检索"这条路走到今天面临哪些坑。

最早的迭代RAG思路很朴素——ITER-RETGEN的做法是把上一轮的生成结果拼上原始问题，作为下一次检索的query。直觉上说得通，但问题也很明显：这种方式只是把已知信息"循环利用"，并没有真正识别出"我现在还缺什么"。

FLARE走得更细。它让模型生成下一句话的草稿，如果草稿里出现了不确定的词，就触发一次检索并用结果修正草稿。这个思路更精准地抓住了"信息缺口"，但代价极大——它需要精心设计的few-shot prompt（通常是8-shot，每条示例包含两个文档 + 一个问题 + 一条思维链），推理开销爆表。更致命的是，当检索回来的文档是噪声时，few-shot prompt反而会"逼着"模型用不相关的文档编造答案——因为示例告诉它"这种情况下应该给出答案"。

Self-RAG换了条路。它训练模型预测special "reflection token"（反思标记），用这些标记来判断是否需要检索、检索结果是否相关、答案是否有根据。听起来很系统——但本质上是在让模型机械地学习"何时输出反思标记"，而不是真正培养推理能力。遇到训练分布之外的情况，反思机制就可能失灵。

三条路，各有死穴：ITER-RETGEN太被动，FLARE太依赖人工，Self-RAG不推理。

迭代检索的核心问题——"什么时候检索、检索什么"——始终没有被真正释放给模型自己来决定。

Auto-RAG选择正面回答这个问题。

2.核心设计：LLM和检索器之间的"多轮对话"

Auto-RAG的核心思想非常简单——把迭代检索建模成LLM和检索器之间的多轮对话。

不是规则驱动，不是prompt模板，而是对话。

每一轮，Auto-RAG都要做几件事：基于当前已知信息推理（"我现在知道什么、还缺什么"）→ 判断是否需要再次检索 → 如果需要，提炼出一个精准的查询词 → 把检索结果整合进上下文 → 继续推理。直到信息足够了，才收手给出最终答案。

整个过程的控制逻辑，完全由模型的推理输出来承载——用自然语言表达，而不是special token或概率阈值。

图1

图1清晰地还原了Auto-RAG处理多跳问题的完整推理链——从初始分析、逐轮检索到精炼query，五次交互后收敛出正确答案。这不是流程图，而是一次真实的"思考过程"记录

这意味着什么？意味着可解释性是原生的。用户看到的不是"检索了3次"这个数字，而是完整的推理链："基于文档1，我找到了X，但还需要确认Y，所以……"这在RAG系统里，是第一次做到如此程度的透明。

以图1中的示例为例：面对"Coolie No.1（1995年）的导演和The Sensational Trial的导演国籍是否相同"这类多跳问题，Auto-RAG展现出了完整的侦探式推理——先查导演姓名，发现David Dhawan是印度人，再查对方导演，检索三次无果后精炼query，最终锁定Karl Freund是德国犹太裔，才给出最终答案"不同"。整个过程经历了五轮检索，全程自主，零人工干预。

3.数据怎么来：自动合成推理指令

让大模型具备这种能力，需要训练数据。但人工标注多轮迭代检索的推理链，代价过高——每条数据都是一条完整的"思考轨迹"，手工写成本无法接受。

Auto-RAG的解决方案是全自动合成。

团队构建了一套数据合成流水线：给定一个问题-答案对 (X, Y)，用一个初始模型驱动检索器，自动生成整条迭代检索轨迹——包括每一步的推理 R₀、每一次的查询 Qₜ、每一轮检索到的文档 Dₜ、以及中间推理结果 Rₜ，直到得出正确答案 A。

用公式表示就是：

图2

图2中算法完整描述了这套合成流水线的每一步——从初始推理规划（Planning）、候选query采样、文档检索，到逐轮生成中间推理结果，最终筛选出包含正确答案的完整轨迹数据

图3

图3则展示了合成训练数据中迭代次数的分布情况——大多数样本需要1-2轮检索，但也有相当比例需要4-6轮。这种分布的多样性，正是Auto-RAG能够自适应处理不同难度问题的训练基础

这里有一个关键细节值得注意：如何判断"这一轮的推理 Rₜ₋₁ 是否包含信息需求"？团队预定义了一批触发词——"however"、"no information"、"find"、"refine"——只要推理输出中出现这些词，就视为模型还有信息缺口，触发下一次检索。

翻译成人话——这套机制相当于给模型装了一个"信息缺口检测器"：只要它在思考时说出"但是我还不知道……"，检索就会自动启动。

数据合成完成后，这些轨迹数据作为指令微调的训练集，在Llama-3-8B-Instruct等开源模型上进行fine-tuning。即便训练数据量有限，结果依然令人满意——这从另一个角度说明，这套框架激活的是模型已有的推理能力，而不是从零教会它新能力。

4.查询精炼：怎么问，比问什么更重要

Auto-RAG在检索策略上有一个容易被忽视的创新：zero-shot query rewriting（零样本查询改写）。

传统RAG直接把用户的原始问题扔给检索器。这在简单问题上勉强够用，但对于多跳推理问题，每一步需要查询的是不同的"子问题"——直接检索原问题效率极低，就像你想查"张三他爸的出生年份"，却直接用"张三"去搜索引擎里搜一样。

Auto-RAG的做法是，在每轮推理后，用模型当前的推理状态作为输入，零样本生成一个专门为这一步设计的检索query——精准到这一跳、这一个信息缺口。

消融实验验证了这一点：去掉query refinement之后，Auto-RAG在NQ上从37.9降到36.8，在2Wiki（多跳问题）上从48.9降到44.0。后者下降幅度明显更大——正说明多跳问题对查询精准度的依赖远超单跳问题。每一次查询的质量，直接决定了下一跳能否找到正确的"接力棒"。

5.实验结果：六项基准，全面超越

Auto-RAG在六个基准数据集上进行了测试，覆盖两大类问题：

• 开放域QA：Natural Questions (NQ)、TriviaQA (TQA)、WebQ (WQ)、PopQA (PQA)

• 多跳推理QA：2WikiMultihopQA (2Wiki)、HotpotQA (HQA)

一句话总结：Auto-RAG在全部六个基准上均超越了所有对比基线，包括同等参数量的Fine-tuned模型和更依赖计算资源的few-shot方法。

图4

图4汇总了Auto-RAG与所有基线方法在六个基准上的完整对比结果。数字不说谎——Auto-RAG在全部数据集上均排名第一，尤其在2Wiki的F1指标上以48.9领先Naive Gen整整15个百分点

核心对比数据（Llama-3-8B 基座，六项指标平均分）：

方法	平均分
Naive Generation（无检索）	30.2
Standard RAG（单次检索）	33.8
REPLUG	31.2
RECOMP-abstractive	36.6
IRCoT（迭代RAG）	38.4
Auto-RAG	44.3

在多跳问题（2Wiki）上优势最为突出——Auto-RAG的F1达到48.9，而Naive Gen只有33.9，提升接近15个百分点。这个差距不是小差距，它意味着对于需要多步推理的问题，Auto-RAG的答对率从三成多直接拉到近五成。

更重要的是：Auto-RAG的推理开销反而更低。FLARE需要每次携带8条few-shot示例，每条包含两个文档，context长度极大；Auto-RAG完全不依赖few-shot，推理时更轻、更快。

另一个值得单独点出的发现：Auto-RAG在更强的基座（Llama-3.1-8B-Instruct）上，平均分进一步提升到49.1。这说明Auto-RAG的框架和模型推理能力之间存在正向放大效应——基座越强，Auto-RAG能释放的自主决策能力就越充分。

6.消融实验：推理不是锦上添花，是核心支柱

消融实验里最值得关注的一组对比：去掉推理（reasoning）之后，性能下降幅度远大于去掉训练本身。

具体数字：

• 完整Auto-RAG：平均 44.3

• 去掉训练（只用few-shot prompt）：38.5，下降5.8分

• 去掉推理（只检索不推理）：35.3，下降整整9分

图5

图5将这一差距可视化得更直观：移除推理能力后，Auto-RAG在2Wiki上的性能曲线几乎垂直跌落，与完整版之间的差距远超移除训练数据带来的影响。推理能力的权重，从柱状图上一眼看出

去掉训练，模型还有一定的few-shot泛化能力；但去掉推理，连查询改写的质量都垮了——模型失去了"理解自己需要什么"的能力，只能机械地检索，检索到不相关内容也无法甄别，更无法决定何时停止。

这说明推理不是锦上添花，而是Auto-RAG整个系统的命脉。没有推理，迭代检索退化成随机漫游；有了推理，每一次检索都在向答案逼近。

7.自适应迭代：大模型真的在"想"

这篇研究里有一个格外有趣的分析：Auto-RAG会根据问题难度自动调节迭代次数，不需要任何人工干预。

简单的单跳问题，平均1-2次检索就能得出答案；困难的多跳问题，迭代次数可以达到4-5次甚至更多。这种"按需分配"的行为是模型推理能力的直接体现——它真的在"想"，而不是在执行规则。

图6

图6从三个数据集（NQ、TriviaQA、HotpotQA）的维度，呈现了Auto-RAG在不同每轮文档数量下的迭代次数分布。可以看到，文档数量越少，模型就倾向于发起更多轮检索来弥补信息密度的不足——这正是"自主决策"而非"硬编码规则"的体现

图7

图7进一步量化了每轮检索文档数对最终性能的影响：并非文档越多越好，每轮提供2-3份文档时性能最优（NQ达到39.75），过多反而引入噪声干扰推理。Auto-RAG对检索质量的感知，远比"多多益善"的朴素逻辑更精细

对比来看，FLARE是固定触发机制，Self-RAG靠reflection token的概率阈值决策，两者都是"硬编码"逻辑；Auto-RAG的决策是"软"的、上下文感知的——每一步都基于当前的推理状态和已检索到的知识质量来决定。这才是真正意义上的自主。

还有一个附加发现：Auto-RAG在通用任务（ARC、RACE、SWAG等）上，性能从75.0微升到75.6，没有出现"灾难性遗忘"。迭代检索的专项训练，没有伤害模型的通用推理能力。整个训练框架是增益式的，而不是零和式的。

图8

图8给出了Auto-RAG与原始Llama-3-8B在ARC、RACE-high、SWAG等通用基准上的对比数据——两者几乎持平（75.6 vs 75.0），部分子任务甚至微有提升。微调没有造成遗忘，这一点数据说话

8.总结与展望

Auto-RAG代表的是RAG研究里一次值得关注的方向转变——从"外部规则驱动检索"到"模型自主推理决策"。

这不是一次调参优化，而是一次控制权的转交。

过去，迭代检索的"大脑"在人类设计的规则系统里；Auto-RAG之后，这个大脑搬进了模型自身的推理过程。在六个基准上平均领先IRCoT约6个百分点，在多跳推理任务上的性能提升尤为突出，且推理开销还低于依赖few-shot的对比方案——这个组合拳打出来，说明这条路线的方向是对的。

未来有几个方向值得期待：

更长的推理链。目前Auto-RAG在多跳任务上最大迭代次数设为10，但真实世界的复杂问题可能需要更精细的子问题分解和更长的检索序列。

更大规模模型的释放。目前主要在8B参数量验证，70B级别的推理能力释放潜力可能更大——毕竟Auto-RAG的框架本身就是在激活模型已有的推理能力。

走出QA，进入Agent任务。当前的评测以问答为主。Auto-RAG的自主决策框架，理论上可以迁移到更复杂的多步骤Agent任务和知识密集型生成场景。

如果说过去的RAG是"给模型装了一双眼睛"，那Auto-RAG展示的方向，是让模型学会自己决定"何时睁眼、往哪里看"。

论文地址：https://arxiv.org/abs/2411.19443