什么能保存到上下文中：预算受限多跳RAG的诊断方法与子模证据打包的改进时机

# 预算约束下多跳RAG的诊断指标及子模证据打包何时能改善其性能
来源：https://arxiv.org/html/2607.00725
###### 摘要

在固定读者上下文预算下的检索增强生成（RAG）面临一个选择问题：在检索到的证据中，只有一部分能展示给读者。我们认为，文档召回率——标准的检索指标——在此场景下并不是需要优化的正确指标，为此我们做出两项贡献。首先，作为一项*通用*贡献，我们引入了**答案在上下文中（answer-in-context）**这一诊断指标，它衡量的是标准答案是否作为连续片段存在于*打包后的*读者上下文中（而非检索集合中）。与召回率相比，它能更好地预测答案F1（相关系数r=0.39{=}0.39–0.550.55 vs. ∼0.31{\sim}0.31），大致能五倍地区分答案质量（在HotpotQA上0.600.60 vs. 0.120.12），并且承载了*超越*检索的信息：它在召回率基础上增加了ΔR²=0.17，即使在所有标准文档都被检索到的问题中，也显示出4.6倍的EM差距。我们还通过*干预性*实验证实了这一点：在2WikiMultiHopQA上，一种能提升覆盖率但不提升answer-in-context的打包变化，并未带来准确率提升。其次，作为一项*条件性*贡献，我们将读者上下文构建视为预算约束下的单调子模最大化问题，并构建了一个打包器，它能同时优化相关性、查询覆盖率、代表性和多样性。在HotpotQA上，使用160词元预算和3B读者，它在三个随机种子下以相同或更低的词元成本击败了强大的聚焦启发式方法、MMR和朴素打包——F1最高提升+5.1。关键是，我们诚实地描绘了这一胜利的适用范围：它需要同时满足以下条件：（i）多跳互补结构，（ii）能返回证据的检索，（iii）严格但不极端的预算，（iv）足够弱的读者，使得证据密度而非阅读能力成为瓶颈。一个量化控制的读者规模阶梯（3B→7B→14B）显示，相对于启发式方法的优势在7B时被吸收，在14B时显著逆转，而该诊断指标用单一变量解释了每一个边界。

# 什么能存活到上下文中：预算约束下多跳RAG的诊断指标及子模证据打包何时能改善其性能

Ananto Nayan Bala  
Ahsanullah University of Science and Technology  
[email protected]

## 1 引言

检索增强型阅读器（reader）具有有限的上下文窗口，而在实践中，还有一个更小的**证据预算**：窗口中分配给检索到的段落的份额。一旦检索返回的相关文本超过可容纳范围，系统就必须决定保留哪些内容。这个选择步骤通常被视为事后处理——拼接top-k结果，截断以适配（Lewis等人，2020（https://arxiv.org/html/2607.00725#bib.bib1）；Ra等人，2023（https://arxiv.org/html/2607.00725#bib.bib7））——然而，在预算紧张的情况下，正是这个步骤决定了读者是否能看到答案。

社区默认的检索指标recall@k是在*检索到的文档集合*上计算的。但读者从未消费检索到的集合；它消费的是*打包后的上下文*。当打包过程为了适配预算而丢弃证据时，召回率和读者实际看到的内容之间就会出现分歧。这种分歧对于**多跳**问题（Yang等人，2018（https://arxiv.org/html/2607.00725#bib.bib12）；Trivedi等人，2022（https://arxiv.org/html/2607.00725#bib.bib13））尤为严重，因为答案依赖于来自多个文档的证据组合：检索到所有文档是必要的，但还不够，因为打包器可能保留一对冗余文档而丢弃了桥梁。图1（https://arxiv.org/html/2607.00725#S1.F1）具体说明了这种差距。

本文从一个测量缺口出发，最终提出了一种方法。我们首先问：**在预算约束下，读者上下文的什么属性实际上能预测答案质量？** 我们定义了**答案在上下文中（answer-in-context）**——即标准答案是否逐字出现在打包后的上下文中——并表明，在我们测试的每个数据集上，它预测答案F1的能力远优于检索召回率（§3（https://arxiv.org/html/2607.00725#S3））。这重新定义了预算约束RAG的目标，从"检索到标准文档"变为"打包使得答案存活"。然后我们问：**一个有原则的打包器能否提升这个指标？** 我们将读者上下文的构建形式化为**预算单调子模最大化**问题（§4（https://arxiv.org/html/2607.00725#S4）），并在HotpotQA上表明，它在三个随机种子下相对于启发式打包、MMR和朴素拼接取得了统计上可靠的胜利（§5（https://arxiv.org/html/2607.00725#S5））。一个按问题分解的分析将该胜利与诊断指标联系起来：打包器之所以有帮助，正是因为它将互补的多跳证据组装到读者上下文中。

最后——我们认为这与方法本身同样重要——我们**诚实地描绘了这一胜利的适用范围**（§6（https://arxiv.org/html/2607.00725#S6））。通过在RAGBench、MuSiQue、预算扫描和读者规模阶梯上的受控实验，我们确定了有原则的打包要击败最佳启发式方法必须同时出现的四个条件，并展示了每个条件失败的具体设置。在MuSiQue上，我们尝试了针对失败条件的明显修正（增加检索），但结果毫无变化，从而将模糊的"不适用"变成了精确的边界；一个量化控制的读者规模阶梯回应了"更强的读者会吸收你的打包优势"的反对意见——相对于启发式方法的优势在7B时被吸收，在14B时显著逆转，而打包器的机制及其相对于朴素打包的优势仍然存在。该诊断指标预测了所有这些模式。

#### 贡献。

1. 一个诊断指标（通用性）。**答案在上下文中**，一种读者上下文级别的指标，在跨度答案数据集中比召回率能更好地预测预算约束RAG质量，并展示了相对于召回率的**增量效度**（ΔR²=+0.17；即使在所有标准文档都被检索到的情况下，也有4.6倍的EM分离）以及基于**干预**的2Wiki支持。
2. 一种方法（条件性）。一个预算约束的子模证据打包器，在HotpotQA上以相同或更低的词元成本显著提升了答案质量，优于启发式、MMR和朴素打包器，并附有按问题的机制解释。
3. 一个范围图（诚实的核心）。四个条件性的说明，解释了有原则的打包何时能击败最佳启发式方法，每个条件都在受控设置中被证明会失败——包括在MuSiQue上的检索解锁消融实验，以及一个量化控制的读者规模阶梯（3B→7B→14B），该阶梯定位了策展（curation）何时不再产生收益并开始产生成本。

我们**有意不**声称图表结构证据或子模打包能普遍改进RAG。证据支持的是一个狭窄、有机制解释的主张，加上一个能泛化的诊断指标——我们认为这比一个无法在重复实验中存活的广泛主张更有用。

查询 → 检索器 → 检索集合（recall@k） → 打包器（≤ B 词元） → 上下文（此处为answer-in-context） → 读者 → 答案
图1：召回率是在*检索集合*上评分的；读者消费的是*打包后的上下文*。在预算约束下，打包器可能丢弃检索到的标准文档（此处为"标准文档#2"），因此高召回率不一定意味着答案存活。Answer-in-context衡量的正是到达读者手中的内容。

## 2 相关工作

#### 检索增强生成。

RAG将（通常为稠密型；Karpukhin等人，2020（https://arxiv.org/html/2607.00725#bib.bib3））检索器与读者LM（Lewis等人，2020（https://arxiv.org/html/2607.00725#bib.bib1）；Guu等人，2020（https://arxiv.org/html/2607.00725#bib.bib2）；Izacard和Grave，2021（https://arxiv.org/html/2607.00725#bib.bib4）；Izacard等人，2023（https://arxiv.org/html/2607.00725#bib.bib5））相结合，现已涵盖了从数万亿词元中检索（Borgeaud等人，2022（https://arxiv.org/html/2607.00725#bib.bib6））、上下文内检索（Ra等人，2023（https://arxiv.org/html/2607.00725#bib.bib7））、黑盒增强（Shi等人，2024（https://arxiv.org/html/2607.00725#bib.bib8））、联合指令微调（Lin等人，2024（https://arxiv.org/html/2607.00725#bib.bib10））以及自反思变体（Asai等人，2024（https://arxiv.org/html/2607.00725#bib.bib9））；详见Gao等人（2023（https://arxiv.org/html/2607.00725#bib.bib11））的综述。这些工作大多分别报告检索召回率和端任务准确率，并将上下文构建视为固定的top-k拼接。我们的诊断指标针对的是介于两者之间的量——打包后的上下文实际包含什么——一旦预算迫使进行选择，这个量就会成为约束变量。

#### 多跳问答。

HotpotQA（Yang等人，2018（https://arxiv.org/html/2607.00725#bib.bib12））、MuSiQue（Trivedi等人，2022（https://arxiv.org/html/2607.00725#bib.bib13））、2WikiMultiHopQA（Ho等人，2020（https://arxiv.org/html/2607.00725#bib.bib14））和WikiHop（Welbl等人，2018（https://arxiv.org/html/2607.00725#bib.bib15））要求跨文档组合证据。大量研究工作通过多跳稠密检索（Xiong等人，2021（https://arxiv.org/html/2607.00725#bib.bib18））、交错检索与推理（Trivedi等人，2023（https://arxiv.org/html/2607.00725#bib.bib16）；Press等人，2023（https://arxiv.org/html/2607.00725#bib.bib17））——基于思维链提示（Wei等人，2022（https://arxiv.org/html/2607.00725#bib.bib53））、迭代检索生成（Shao等人，2023（https://arxiv.org/html/2607.00725#bib.bib54）；Jiang等人，2023b（https://arxiv.org/html/2607.00725#bib.bib20））以及程序式组合（Khattab等人，2022（https://arxiv.org/html/2607.00725#bib.bib19））来应对检索方面的这一困难。我们使用这些数据集不是为了改进检索，而是为了*变化*互补证据是否存在并被呈现，这决定了打包器能否发挥作用。

#### 上下文选择与压缩。

通过重排序、选择或压缩来减少读者上下文已得到充分研究。经典的冗余感知重排序器是最大边际相关性（Maximal Marginal Relevance, MMR）（Carbonell和Goldstein，1998（https://arxiv.org/html/2607.00725#bib.bib28）），这是我们的直接基线。近期方法压缩或过滤检索到的上下文——RECOMP（Xu等人，2024a（https://arxiv.org/html/2607.00725#bib.bib30））、LLMLingua（Jiang等人，2023a（https://arxiv.org/html/2607.00725#bib.bib31））、选择性上下文（Li等人，2023（https://arxiv.org/html/2607.00725#bib.bib32））、上下文过滤（Wang等人，2023（https://arxiv.org/html/2607.00725#bib.bib33））以及针对无关段落的鲁棒性（Yoran等人，2024（https://arxiv.org/html/2607.00725#bib.bib34））。"中间丢失"效应（Liu等人，2024（https://arxiv.org/html/2607.00725#bib.bib29））和长上下文研究（Bai等人，2024（https://arxiv.org/html/2607.00725#bib.bib35）；Xu等人，2024b（https://arxiv.org/html/2607.00725#bib.bib36））表明，单纯扩大窗口并不能替代选择放入其中的内容。我们的打包器与其不同之处在于，其目标与一个显式、可测量的答案密度指标（即诊断指标）相关联，而我们的核心信息是一个关于**何时**有原则的选择有所帮助的范围图。

#### 用于选择的子模优化。

具有成本缩放贪心算法及其常数因子保证（Nemhauser等人，1978（https://arxiv.org/html/2607.00725#bib.bib39））的覆盖与多样性目标由Lin和Bilmes（2011（https://arxiv.org/html/2607.00725#bib.bib37）、2010（https://arxiv.org/html/2607.00725#bib.bib38））引入用于抽取式摘要；更广泛的论述见Krause和Golovin（2014（https://arxiv.org/html/2607.00725#bib.bib40））；Bilmes（2022（https://arxiv.org/html/2607.00725#bib.bib41））。我们将该机制应用于RAG的*读者上下文证据打包*，并将目标与我们的诊断指标所衡量的answer-in-context指标联系起来。

#### 检索器与读者。

我们使用在MTEB（Muennighoff等人，2023（https://arxiv.org/html/2607.00725#bib.bib26））和BEIR（Thakur等人，2021（https://arxiv.org/html/2607.00725#bib.bib27））上评估的双编码器检索器（Reimers和Gurevych，2019（https://arxiv.org/html/2607.00725#bib.bib22）；Xiao等人，2024（https://arxiv.org/html/2607.00725#bib.bib25）），并辅以经典稀疏检索（Robertson和Zaragoza，2009（https://arxiv.org/html/2607.00725#bib.bib21））、晚期交互（Khattab和Zaharia，2020（https://arxiv.org/html/2607.00725#bib.bib24））和跨编码器（Nogueira和Cho，2019（https://arxiv.org/html/2607.00725#bib.bib23））作为周边上下文。读者是指令微调的大语言模型（Qwen团队，2025（https://arxiv.org/html/2607.00725#bib.bib42）；Touvron等人，2023（https://arxiv.org/html/2607.00725#bib.bib43）；Brown等人，2020（https://arxiv.org/html/2607.00725#bib.bib44））；我们读者阶梯的较大层级使用4位NF4量化（Dettmers等人，2023（https://arxiv.org/html/2607.00725#bib.bib45），2022（https://arxiv.org/html/2607.00725#bib.bib46））以适应商用GPU，这就是我们包含精度控制的原因。

#### RAG评估。

EM/F1（Rajpurkar等人，2016（https://arxiv.org/html/2607.00725#bib.bib47））衡量答案质量，而RAG特定框架在知识密集型套件（Petroni等人，2021（https://arxiv.org/html/2607.00725#bib.bib51）；Mallen等人，2023（https://arxiv.org/html/2607.00725#bib.bib52））上评估忠实度和上下文相关性（Es等人，2024（https://arxiv.org/html/2607.00725#bib.bib48）；Saad-Falcon等人，2024（https://arxiv.org/html/2607.00725#bib.bib49）；Chen等人，2024（https://arxiv.org/html/2607.00725#bib.bib50））。这些方法评估的是*检索到的*上下文或*最终*答案；而answer-in-context衡量的是读者看到的打包上下文，并且我们表明它在预测端任务质量方面相对于召回率具有增量效度。

## 3 答案在上下文中的诊断指标

### 3.1 定义

给定一个问题及其标准答案集合AA，以及一个**物化的读者上下文**CC（实际展示给读者的打包片段的拼接），我们定义：

- **答案在上下文中（answer-in-context）**：如果某个归一化后的a∈Aa \in A作为归一化后CC的连续词元子序列出现，则值为1，否则为0；
- **标准文档读者覆盖率**：对CC贡献了≥1个片段的标准文档的比例；**所有标准文档都在读者中**：是否*所有*标准文档都贡献了片段；
- **标准词元密度**：CC中来自标准文档的词元占比。

这些指标是在*打包后的*运行上计算的，而非检索集合——这是与recall@k的关键区别，后者是在*打包前*基于检索到的文档ID评分的。Answer-in-context是抽取式读者正确的必要条件，我们假设它是解释为什么高召回率在预算约束下不一定提高答案质量的中间变量。

### 3.2 Answer-in-context预测质量；而召回率不能

表1：HotpotQA上的特征-质量相关性（种子42，500个问题，n=2,500个策略×问题行，预算160）。Answer-in-context是最强的单一预测因子——高于两个检索指标。表1（https://arxiv.org/html/2607.00725#S3.T1）汇集了HotpotQA上所有策略×问题行，并将每个诊断指标与答案质量相关联。Answer-in-context是最强的单一预测因子，高于两个检索指标和读者级别覆盖率。直接条件化：当标准答案在读者上下文中时，平均F1为0.596，而不在时为0.123（差距+0.47）。这解决了“较低召回率，更好答案”的悖论：在预算约束下，重要的是答案是否*存活到上下文中*，而不是检索到了多少标准文档。

### 3.3 增量效度：并非伪装成召回率

查看图注
图2：在HotpotQA上，*所有*标准段落都被检索到的问题中（recall@5=1），打包是否将答案保留在上下文中仍然是决定性的：F1 0.61 vs. 0.20，EM 0