论文标题：Inference Scaling for Long-Context Retrieval Augmented Generation
会议：ICLR 2025
作者：Zhenrui Yue、Honglei Zhuang、Aijun Bai、Kai Hui、Rolf Jagerman、Hansi Zeng、Zhen Qin、Dong Wang、Xuanhui Wang、Michael Bendersky
机构：University of Illinois Urbana-Champaign、Google DeepMind、UMass Amherst
论文主题：长上下文 RAG、推理时计算扩展、DRAG、IterDRAG、Inference Scaling Laws

---

0. 先说结论

这篇论文讨论的是一个很实际的问题：

对于长上下文大模型来说，RAG 效果是不是只要塞更多文档就会变好？

作者的回答是：不是。

传统 RAG 很容易陷入一个误区：
既然模型上下文窗口变长了，那我就多检索一些文档，把更多外部知识塞进去。

但论文发现，单纯增加检索文档数量，标准 RAG 很快就会进入性能平台期，甚至可能因为噪声文档太多导致效果下降。

作者提出的核心观点是：

长上下文 RAG 的关键不是“塞更多文档”，而是“在推理阶段合理分配计算资源”。

这篇论文提出了两个策略：

• DRAG：Demonstration-based RAG

• IterDRAG：Iterative Demonstration-based RAG

然后进一步研究：
在不同推理预算下，应该如何分配：

检索文档数量 k
上下文示例数量 m
迭代生成轮数 n

论文最重要的结论是：

当推理时计算资源被合理分配时，长上下文 RAG 的性能可以随着 effective context length 的增加呈现近似线性提升。

这也是论文所谓的：

Inference Scaling Laws for RAG

简单说，这篇论文不是在说“长上下文一定有用”，而是在说：

长上下文有用的前提是，你得会用。

---

1. 论文想解决什么问题？

这篇论文想解决的问题可以概括为一句话：

在长上下文大模型时代，RAG 应该如何有效扩展推理时计算资源？

以前做 RAG，大家最常见的做法是：

用户问题
  ↓
检索 TopK 文档
  ↓
把文档和问题拼进 Prompt
  ↓
LLM 生成答案

如果效果不好，很多人会直接调大 TopK：

TopK = 5 不够，那就 10
TopK = 10 不够，那就 20
TopK = 20 不够，那就 100

长上下文模型出现后，这种想法更自然了：

反正模型支持 100K、1M 甚至更长上下文，那就多塞点文档。

但真实情况没有这么简单。

论文在 Introduction 里指出，当前长上下文大模型虽然可以接收很长的输入，但它们在复杂任务中并不总能有效定位超长上下文里的关键信息。也就是说，能装下，不等于能用好。

这就引出了论文的两个核心问题：

1. 当推理时计算资源增加时，RAG 性能到底能提升多少？
2. 给定一个推理预算，能不能预测最优的计算资源分配方式？

这里的“推理时计算资源”不只是检索文档数量，还包括：

• 放多少文档；

• 放多少示例；

• 是否做多轮检索；

• 是否做迭代生成；

• 每一轮怎么组织 Prompt。

论文把这些统一放在 inference scaling 的框架下讨论。

---

2. 过去的方法有什么不足？

过去的 RAG 扩展方法，大多把重点放在“增加知识量”上。

比如：

增加检索文档数量
增加每篇文档长度
扩大上下文窗口
把更多知识塞进 Prompt

这种思路有一定道理。
如果原来没有召回正确知识，多检索一些文档确实可能提升召回率。

但问题在于，RAG 最终效果不只取决于“有没有正确文档”，还取决于模型能不能：

从很多文档里找到关键信息
忽略无关噪声
完成多跳推理
把证据正确组合成答案

论文里提到，很多研究发现，当检索文档数量超过某个软阈值后，RAG 性能会进入平台期，甚至下降。原因也很直观：文档越多，噪声越多，模型越容易被干扰。

比如一个用户问：

A 公司的 CEO 毕业于哪所大学？

检索系统可能召回：

A 公司介绍
A 公司 CEO 简介
A 公司财报
A 公司新闻
A 公司竞争对手信息
A 公司历史沿革

正确答案可能只在某一段里。
如果上下文太长、噪声太多，模型反而可能抓错重点。

所以过去方法的不足主要有三个：

---

2.1 只扩文档数量，没有考虑计算资源分配

标准 RAG 通常只调一个参数：

TopK

但长上下文场景下，可调参数其实更多：

检索多少文档
放多少 in-context examples
是否做多轮检索
每轮生成多少中间答案
是否拆分子问题

如果只调 TopK，其实没有充分利用长上下文模型的能力。

---

2.2 长上下文模型并不天然擅长超长信息定位

模型上下文窗口变长，不代表它真的能在 10 万 token 里稳定找到关键证据。

这也是很多 RAG 系统线上效果不稳定的原因之一：

正确文档召回了
但模型没有用到

这种情况下，继续增加文档数量不一定有帮助。

---

2.3 多跳问题需要推理链，不只是更多文档

很多知识密集型问答不是单跳问题，而是多跳问题。

比如：

某部电影导演的出生地是哪里？

这类问题可能需要：

先找到电影导演是谁
再找导演出生地
最后生成答案

标准 RAG 一次性检索一批文档，然后直接回答，可能无法很好处理这种组合推理。

这就是论文提到的 compositionality gap。

---

3. 作者的核心思路是什么？

作者的核心思路是：

不要只扩展文档数量，而是把推理阶段的计算资源分配到“文档、示例、迭代步骤”多个维度上。

论文提出两个方法。

---

3.1 DRAG：Demonstration-based RAG

DRAG 可以理解为：

RAG + 多个带检索文档的示例。

普通 RAG 的 Prompt 大概是：

参考文档：
doc1
doc2
doc3

问题：
用户问题

答案：

DRAG 会在测试问题前面加入多个完整示例：

示例 1：
文档：
doc1, doc2, doc3
问题：
question1
答案：
answer1

示例 2：
文档：
doc1, doc2, doc3
问题：
question2
答案：
answer2

测试问题：
文档：
test_doc1, test_doc2, test_doc3
问题：
test_question
答案：

这样做的目的不是简单 few-shot，而是让模型在上下文里看到：

如何从一堆文档中定位相关信息
如何忽略无关文档
如何根据检索内容回答问题

所以 DRAG 利用了长上下文模型的 in-context learning 能力。

---

3.2 IterDRAG：Iterative Demonstration-based RAG

IterDRAG 更进一步。

它不是一次性回答，而是把复杂问题拆成子问题，然后每个子问题都可以触发新的检索。

大致流程是：

输入问题
  ↓
生成子问题 1
  ↓
检索相关文档
  ↓
生成中间答案 1
  ↓
生成子问题 2
  ↓
再次检索相关文档
  ↓
生成中间答案 2
  ↓
综合所有中间结果
  ↓
生成最终答案

论文里的 Figure 3 很清楚地对比了 DRAG 和 IterDRAG：

• DRAG：一次性把文档和示例放进去，然后直接生成最终答案；

• IterDRAG：先拆解问题，再交替进行检索和生成，最后合成答案。

这其实很接近工程里常说的：

多步 RAG
Agentic RAG
Self-Ask
Iterative Retrieval

只不过论文把它放到了 inference scaling 的框架下研究。

---

4. 方法结构是怎样的？

这篇论文的方法结构可以分成三层。

---

4.1 第一层：定义推理计算量 effective context length

论文没有简单用“上下文窗口长度”来衡量推理计算量，而是定义了一个指标：

effective context length

它表示：

在模型输出最终答案之前，所有推理步骤输入 token 数量的总和。

对于只调用一次 LLM 的方法，比如普通 RAG 或 DRAG：

effective context length = 当前 Prompt 的输入 token 数

对于 IterDRAG 这种多轮调用模型的方法：

effective context length = 每一轮输入 token 数之和

这个定义很重要。

因为 IterDRAG 不一定需要单次塞进 5M token，它可以通过多轮调用累计更大的 effective context length。

这也符合真实工程场景。
很多时候模型上下文窗口有限，但我们可以通过多轮检索、多轮调用来扩展推理计算。

---

4.2 第二层：设计 DRAG 和 IterDRAG

DRAG 的结构

DRAG 的参数主要有两个：

k：每个问题检索的文档数量
m：in-context examples 数量

DRAG 的推理结构是：

m 个示例，每个示例包含：
  - 检索文档
  - 问题
  - 答案

测试样本包含：
  - 检索文档
  - 问题

然后一次性让模型生成答案。

DRAG 的关键是：
示例不是普通 QA 示例，而是带有检索文档的 RAG 示例。

---

IterDRAG 的结构

IterDRAG 的参数多了一个：

n：最大迭代生成轮数

它在 DRAG 的基础上引入多轮：

生成子问题
检索文档
生成中间答案
继续生成子问题
继续检索
最终回答

论文中设置最多 5 轮迭代。

它的优势在于，多跳问题不需要一次性解决，而是可以拆成更简单的子问题。

比如问题是：

电影 A 的导演出生在哪里？

IterDRAG 可能拆成：

Follow up 1：电影 A 的导演是谁？
Intermediate answer：导演是 B。

Follow up 2：B 出生在哪里？
Intermediate answer：B 出生在 C。

So the final answer is：C。

这样比一次性让模型在一大堆文档里直接推理更稳。

---

4.3 第三层：建立 computation allocation model

论文不仅提出方法，还试图回答一个更工程化的问题：

给定一个推理预算，应该选多少文档、多少示例、多少轮迭代？

这里作者把参数写成：

θ = (k, m, n)

其中：

k：检索文档数量
m：上下文示例数量
n：生成迭代轮数

然后用一个模型来预测不同配置下的性能。

这就是论文里的：

computation allocation model for RAG

它的目的不是训练一个新的 LLM，而是帮助我们选择更优的推理配置。

---

5. 关键公式或算法怎么理解？

论文里有两个比较关键的公式。

---

5.1 公式一：固定预算下的最优性能

论文定义了一个最优性能：

P*(Lmax)

它表示：

在最大推理预算 Lmax 内，通过枚举不同参数配置 θ，能够达到的最好平均性能。

公式可以简化理解为：

P*(Lmax) = 在所有满足预算限制的配置中，找到效果最好的那个

论文原式大概是：

P*(Lmax) = max over θ of average P(yi, f(xi; θ))
subject to l(xi; θ) ≤ Lmax

其中：

xi：输入问题
yi：标准答案
f(xi; θ)：使用参数 θ 的 RAG 策略得到的预测
P：评价指标，比如 EM、F1、Accuracy
l(xi; θ)：该配置消耗的 effective context length
Lmax：最大推理预算

这个公式其实很符合工程直觉。

假设你有一个预算：

最多允许 128k token 推理成本

那你可以选择：

方案 A：检索 100 个文档，不放示例
方案 B：检索 20 个文档，放 8 个示例
方案 C：检索 10 个文档，放 4 个示例，做 3 轮迭代

论文要找的就是：
在这个预算内，哪个方案效果最好？

这就是 P*(Lmax) 的意义。

---

5.2 公式二：计算资源分配模型

论文进一步提出：

σ^-1(P(θ)) ≈ (a + b ⊙ i)^T log(θ) + c

这个公式看起来有点复杂，但可以拆开理解。

---

θ 表示配置

θ = (k, m, n)

也就是：

检索文档数量
示例数量
迭代轮数

---

P(θ) 表示该配置的性能

比如 accuracy、F1、EM。

---

log(θ) 表示性能增长不是线性的

为什么要取 log？

因为在很多 scaling 现象里，资源增长和性能增长不是简单线性关系。
从 1 个文档增加到 10 个文档，收益可能很明显；
但从 500 个文档增加到 1000 个文档，收益可能很小。

所以用 log(θ) 更符合边际收益递减的情况。

---

i 表示任务对文档和示例的敏感程度

论文里定义了：

idoc：加一个文档带来的性能增益
ishot：加一个示例带来的性能增益

这相当于衡量当前任务更依赖什么。

有些任务更依赖外部知识，那 idoc 更重要。
有些任务更依赖示例模式，那 ishot 更重要。

---

σ^-1 是为了处理长上下文下的非线性

论文发现，当 context 特别长，比如超过 1M 后，性能增长会变缓。
所以引入 sigmoid 相关变换来更好拟合这种趋势。

这部分如果写代码落地，不一定要完全照搬论文公式。
但它传达的思想很重要：

不同任务、不同模型、不同预算下，RAG 的最优配置不是固定的，可以用实验数据建模预测。

---

6. 实验结果证明了什么？

论文实验主要使用 Gemini 1.5 Flash，在多个知识密集型问答数据集上评估，包括：

Bamboogle
HotpotQA
MuSiQue
2WikiMultiHopQA
StrategyQA
TriviaQA
Natural Questions

其中核心实验集中在多跳问答数据集上。

---

6.1 DRAG 和 IterDRAG 明显优于普通 RAG

论文 Figure 2 展示了不同方法在多个数据集上的准确率对比。

方法包括：

Zero-shot QA
Many-shot QA
RAG
DRAG
IterDRAG

结果显示：

• Zero-shot QA 最弱；

• Many-shot QA 有提升；

• 标准 RAG 进一步提升；

• DRAG 比标准 RAG 更好；

• IterDRAG 整体效果最好。

论文摘要中提到，在最优配置下，长上下文 LLM 上扩展推理计算相比标准 RAG 最多可以带来 58.9% 的提升。

这说明：

RAG 的效果提升不只是靠更多文档，也可以靠示例和迭代推理。

---

6.2 标准 RAG 很快进入平台期

论文 Figure 1 和 Figure 4 都展示了一个关键现象：

标准 RAG 在 effective context length 增加到一定程度后，很快进入平台期。

也就是说，继续增加文档数量，性能不再明显提升。

原因也很直观：

更多文档提高了召回率
但也引入了更多噪声
模型不一定能从长上下文里稳定找到关键信息

这和我们做工程时的经验非常一致。

很多时候 TopK 从 5 调到 20 有用，
但从 20 调到 100，效果可能不升反降。

---

6.3 DRAG 和 IterDRAG 展现出更好的 scaling 特性

论文发现：

• DRAG 在较短预算，比如 16k、32k 时表现更好；

• IterDRAG 在 128k 以上更有优势；

• 当预算继续增加，IterDRAG 能通过多轮检索和生成继续利用推理计算。

Table 1 里可以看到，在 128k、1M、5M 这种更高预算下，IterDRAG 通常表现更强。

这说明：

长上下文预算越大，越应该考虑多轮检索和迭代生成，而不是一次性把所有文档塞进去。

---

6.4 最优性能与推理计算量近似线性相关

论文把这个现象称为：

Inference Scaling Laws for RAG

意思是：

当推理资源被最优分配时，RAG 性能会随着 effective context length 的数量级增长呈现近似线性提升。

注意这里有一个很重要的前提：

optimally allocated

不是随便增加 token 都能线性提升，而是要选对参数配置。

如果只是无脑增加文档数量，标准 RAG 很快平台期。
如果合理组合文档、示例和迭代步骤，才会呈现更好的 scaling。

---

6.5 计算资源分配模型具有一定预测能力

论文还验证了 computation allocation model。

几个结果比较关键：

• 消融实验中，完整模型的拟合效果最好；

• Domain generalization 中，预测配置能达到 oracle 结果的 96.6%；

• Length extrapolation 中，从 128k 外推到 1M 时，预测和 oracle 的平均差距只有 2.8%；

• 但外推到 5M 时误差变大，说明超长上下文预测仍然更难。

这说明该模型不是纯理论包装，而是确实能为配置选择提供参考。

---

7. 这篇论文有什么局限？

这篇论文很有启发，但也有明显局限。

---

7.1 主要实验基于 Gemini 1.5 Flash

论文实验主要使用 Gemini 1.5 Flash。

这带来一个问题：

结论能否完全迁移到其他模型？

比如：

GPT-4 系列
Claude 系列
Qwen 长上下文模型
DeepSeek 系列
Llama 长上下文模型

不同模型的长上下文利用能力、指令跟随能力、ICL 能力差别很大。

所以这篇论文的趋势有参考价值，但工程落地时不能直接照搬参数。

---

7.2 论文没有把输出 token 和检索成本纳入主要计算

论文用 effective context length 衡量推理计算量，并且主要统计输入 token。
它排除了输出 token 和检索成本。

在论文设定的知识密集型 QA 任务里，输出通常很短，这样处理可以理解。

但在真实业务里，输出可能并不短。
比如：

生成报告
总结长文档
合同审查
代码分析
多轮问答

这时输出 token 和多轮调用成本也会变得很重要。

---

7.3 检索质量仍然是瓶颈

论文 Appendix 里分析了检索质量。

结果显示，随着文档数量增加，Recall 会提升，但 NDCG 和 MRR 很早就进入平台期。

这说明：

更多文档能提高“有没有召回”
但不能保证“重要文档排得靠前”

如果检索器质量不高，或者没有 rerank，长上下文只会把更多噪声带给模型。

---

7.4 IterDRAG 成本更高，延迟更大

IterDRAG 需要多轮调用模型，每一轮还可能触发检索。

这会带来：

更高延迟
更高 token 成本
更复杂的工程链路
更难做线上稳定性保障

所以它适合复杂问题，不一定适合所有问题。

如果用户问的是简单事实：

公司报销标准是多少？

可能普通 RAG + rerank 就够了。

如果问题是多跳复杂推理：

某政策影响下，哪些部门的流程需要调整，依据分别是什么？

这时 IterDRAG 才更有价值。

---

7.5 评价指标仍然存在问题

论文错误分析里提到，有些错误来自评价本身。

比如：

310 sq. km
310 square kilometers

语义等价，但自动指标可能判错。

这说明 RAG 评测不能只依赖 EM、F1、Accuracy。
真实业务中还需要：

人工评测
引用正确性
证据一致性
拒答能力
幻觉率
用户满意度

---

8. 对工程落地有什么启发？

这篇论文对做 RAG 系统很有价值，尤其是长上下文 RAG。

---

8.1 不要迷信“长上下文 + 更多文档”

很多团队做 RAG，第一反应是：

模型上下文变长了，那我多塞点文档

但论文告诉我们：

多塞文档只是增加了信息量，不代表模型能有效使用信息。

工程上应该先问：

检索结果是否相关？
正确文档是否排在前面？
是否有 rerank？
是否有噪声过滤？
模型是否真的引用了正确证据？

如果这些没做好，长上下文可能只是让 Prompt 更贵。

---

8.2 TopK 不应该是固定值

很多系统里 TopK 是固定配置：

top_k = 5
top_k = 10
top_k = 20

但论文说明，不同任务、不同预算、不同数据集下，最优配置不同。

工程上可以考虑动态策略：

简单问题：少量文档 + 直接回答
复杂问题：更多文档 + rerank
多跳问题：query decomposition + iterative retrieval
高价值问题：允许更大推理预算
低价值问题：控制 token 成本

也就是说，RAG 系统应该有“预算意识”。

---

8.3 复杂问题可以引入 Iterative RAG

对于多跳问题，IterDRAG 的思想非常值得借鉴。

工程上可以实现成：

1. 判断问题是否复杂
2. 如果复杂，生成子问题
3. 每个子问题单独检索
4. 生成中间答案
5. 汇总所有证据
6. 生成最终答案

这个流程比一次性检索更稳，尤其适合：

复杂政策问答
多文档分析
法律条款对比
技术故障排查
论文综述
财报分析

---

8.4 RAG 示例也可以作为 Prompt 资产

DRAG 的思想提醒我们：

示例不一定只是普通 QA 示例，也可以是完整 RAG 示例。

比如企业知识库场景，可以准备一些高质量示例：

参考资料
用户问题
标准回答
引用依据
拒答示例
多版本冲突处理示例

这些示例能告诉模型：

怎么用资料
怎么引用来源
什么时候拒答
怎么处理噪声文档
怎么处理多个候选答案

这比只写一段 system prompt 更具体。

---

8.5 线上 RAG 应该记录推理配置和效果

论文的 computation allocation model 对工程有一个重要启发：

如果我们记录足够多的线上数据，就可以逐步学习什么配置最有效。

线上系统可以记录：

问题类型
检索文档数量
rerank 分数
上下文长度
是否使用多轮检索
模型回答
用户反馈
人工评分
token 成本
延迟

后续就可以做策略优化：

什么问题该用普通 RAG
什么问题该用多轮 RAG
什么问题该增加 TopK
什么问题该减少上下文
什么问题该直接拒答

这比拍脑袋调参数更可靠。

---

9. 我自己的理解和总结

这篇论文最有价值的地方，不是提出了一个特别复杂的新模型，而是把 RAG 的优化视角从“检索更多文档”推进到了“推理计算资源分配”。

以前我们做 RAG，经常纠结：

TopK 设多少？
chunk 多大？
上下文放多少？
要不要 rerank？

这篇论文给了一个更系统的视角：

给定一个推理预算，如何把 token 花在最有价值的地方？

这句话很重要。

因为真实业务里，RAG 系统不是只追求准确率，还要考虑：

延迟
成本
吞吐
稳定性
用户体验

如果用户问一个简单问题，却触发 5M token 的 IterDRAG，那显然不划算。
如果用户问一个复杂多跳问题，却只检索 5 个文档直接回答，那又很容易答错。

所以我觉得这篇论文最大的工程启发是：

RAG 系统应该从固定流程，走向动态推理策略。

未来比较合理的 RAG 系统，可能不是一个固定 pipeline：

retrieve → rerank → generate

而是一个带策略选择的系统：

判断问题复杂度
判断是否需要检索
判断检索多少文档
判断是否需要 rerank
判断是否需要拆分子问题
判断是否需要多轮检索
判断什么时候停止

DRAG 和 IterDRAG 都是这个方向上的探索。

当然，这篇论文也提醒我们，长上下文不是万能的。
长上下文模型确实让更多信息进入 Prompt 成为可能，但能不能用好这些信息，仍然取决于：

检索质量
文档排序
噪声过滤
Prompt 设计
模型长上下文能力
推理策略
评测体系

如果用一句话总结这篇论文，我会这样说：

长上下文 RAG 的关键，不是把上下文塞满，而是把推理预算用对。

这也是我认为它值得精读的原因。