长文档推理不该顺序读：PARSER 如何拆开阅读与推理

PARSER 将长文档切块交给子 Agent 并行读取，由主 Agent 多轮追问和组合证据。本文重点分析它为何能缓解证据位置偏差、降低长上下文延迟，以及实验结论成立的条件与工程代价。

长上下文模型的问题，已经不只是“窗口够不够大”。

即使模型支持几十万乃至上百万 token，把整份文档一次性塞进去，也不意味着模型能稳定利用其中的信息。证据可能藏在中间，可能相隔几十万 token，也可能按照与推理链完全相反的顺序出现。上下文容量解决的是“能不能装进去”，没有直接解决“能不能找到并正确组合”。

为了绕开这个问题，一类长上下文 Agent 采用顺序记忆机制：把文档切成多个 chunk，依次读取，每次将当前 chunk 和上一轮记忆压缩成新的记忆，最后根据记忆回答问题。

这种方法看起来符合人的阅读直觉，但 PARSER 这篇论文指出了一个更本质的问题：

文档的排列顺序由文档决定，问题的推理顺序由问题决定。顺序记忆 Agent 却让前者控制了后者。

PARSER 的核心思路，就是把这两件事拆开：文档覆盖交给并行读取，串行计算只留给真正需要逐步推进的推理过程。

顺序记忆 Agent 错在哪里

先看顺序记忆 Agent 的基本工作流。

假设长文档被切成  个 chunk：

Agent 从第一个 chunk 开始读取，并维护一个固定容量的文本记忆。处理第  个 chunk 时，它根据问题、旧记忆和当前 chunk，生成新记忆：

最终答案只依赖最后的记忆 。

这个设计解决了上下文窗口有限的问题，因为模型每次只需要看到一个 chunk 和一份压缩记忆。但它同时引入了两个结构性约束。

证据必须在信息不完整时被判断

当 Agent 读到某个 chunk 时，它还没有看过后面的文档。此时，它必须立即判断当前内容是否重要，以及哪些信息值得写入有限容量的记忆。

问题是，多跳问答中的证据经常不是独立显著的。

某个名字第一次出现时可能看起来无关，直到后面找到另一条关系，才知道这个名字是下一跳检索的关键实体。顺序记忆要求 Agent 在下游信息尚未出现时，就决定是否保留上游证据。

这会产生三种相关但不同的偏差。

绝对位置偏差

证据出现在文档中间时，往往最容易丢失。

早期证据虽然有机会参与后续推理，但也要经历大量记忆重写；晚期证据经历的覆盖较少；中间证据既不一定能立即形成答案，又要继续承受多次压缩。

论文的受控实验确实观察到了这一点：MemAgent 在证据位于文档 50% 到 70% 区间时，准确率出现明显下降。

逻辑顺序偏差

文档中证据出现的顺序，不一定符合问题的推理顺序。

比如第二跳证据可能先于第一跳证据出现。Agent 第一次看到第二跳内容时，还不知道应该关注其中哪个实体，于是可能没有把它写入记忆。等第一跳实体后来出现，原来的第二跳证据已经无法重新读取。

ReMemR1 通过 callback 机制允许回看过去的记忆状态，可以部分缓解这个问题，但仍然没有改变顺序遍历这条主路径。

证据距离偏差

两条证据之间隔得越远，第一条证据就必须在记忆中存活越久。

如果中间插入成百上千个无关段落，固定容量记忆会持续被重写。第一条证据即使曾被识别，也可能在第二条证据出现前被覆盖。

说白了，顺序记忆 Agent 不是单纯在“读文档”，而是在进行一连串不可逆的信息压缩。证据的位置、顺序和距离，都会影响它能否活到最终推理阶段。

文档长度被直接变成了依赖深度

第二个问题是延迟。

由于第  个 chunk 的处理依赖上一轮记忆 ，所有 chunk 必须严格串行执行。哪怕有大量空闲 GPU，也不能在  生成前开始更新 。

因此，顺序记忆 Agent 的关键路径长度大致是 。文档越长，chunk 越多，推理步骤和墙钟时间就越接近线性增长。

这不是简单增加并发就能完全消除的问题，因为依赖关系本身是串行的。

PARSER：让阅读并行，让推理串行

PARSER 的全称是 Parallel Reading, Sequential Reasoning。

它没有尝试继续修补顺序记忆，而是直接改变系统的依赖结构。

PARSER 包含两类角色：

• 一个主 Agent，负责拆解问题、制定查询、组合证据和生成最终答案；

• 一组子 Agent，每个子 Agent 固定绑定一个文档 chunk，只负责在自己的局部文本中寻找证据。

主 Agent 从不直接读取原始文档。它只看到用户问题、自己的推理历史，以及各个子 Agent 返回的局部发现。

一次完整的推理过程由多轮 scatter–gather 组成。

Scatter：把同一个查询广播到所有 chunk

在第  轮，主 Agent 根据当前已有信息生成一个查询，并将它广播给所有子 Agent。

每个子 Agent 只检查自己绑定的 chunk。如果 chunk 中有明确证据，就返回原文证据和局部答案；如果没有，就选择放弃回答。聚合阶段会丢弃这些无结果响应。

关键点在于，同一轮中的所有 chunk 可以并行处理。增加文档长度，主要增加的是并行宽度，而不是串行步骤数。

Gather：主 Agent 汇总结果并决定下一跳

主 Agent 收集所有非空发现，将它们加入推理上下文，然后决定：

• 当前证据是否足以回答；

• 是否需要换一种说法重新查询；

• 是否已经找到第一跳实体，需要围绕它查询第二跳；

• 是否需要将一个复杂问题拆成多个更具体的问题。

如果还不能回答，主 Agent发起下一轮 scatter–gather。新查询会基于之前发现的证据动态生成。

这也是 PARSER 与单轮 MapReduce 式并行读取的主要区别。单轮并行方案只能在读取文档前确定一个静态查询，而多跳问题的后续查询往往必须等前一跳结果出来后才能形成。

PARSER 实际上把跨 chunk 的依赖，从“沿着文档传播记忆”改成了“沿着问题推进查询”。

跨块推理为什么不需要让子 Agent 互相通信

一个自然的问题是：每个子 Agent 只能看一个 chunk，它怎么理解跨 chunk 的关系？

PARSER 的回答是，子 Agent 根本不需要独立解决完整的多跳问题。

子 Agent 的职责被刻意限制为：针对一个具体查询，在短文本中寻找可以明确支持答案的局部证据。跨 chunk 的组合由主 Agent跨轮完成。

假设一个问题需要两跳证据：

1. 第一轮查询定位实体 A；

2. 主 Agent 从返回结果中得到 A；

3. 第二轮围绕 A 生成更具体的查询；

4. 所有 chunk 再次被并行检查；

5. 主 Agent 将第二轮结果与第一轮证据组合。

因此，子 Agent 之间没有直接通信，但它们的结果会通过主 Agent 的推理历史发生关联。

这点很关键。PARSER 并没有消除串行推理，而是把串行部分限制在真正不可并行的逻辑依赖上。其关键路径不再是文档 chunk 数量 ，而是问题需要的推理轮数 。

对于长文档，通常有：

论文实验中，MemAgent 的推理步骤随文档长度持续增加，而 PARSER 的平均轮数基本维持在 4 轮左右，因为不同长度设置使用的是同一组问题，问题本身的推理深度没有变化。

为什么它能缓解位置、顺序和距离偏差

PARSER 的稳定性主要来自两个机制。

每个 chunk 在访问上是对称的

同一轮中，所有 chunk 都收到相同的查询。某条证据位于开头、中间还是结尾，不会改变它被读取的时机。

这与顺序记忆不同。顺序记忆中，chunk 的索引决定它进入记忆链的时间，也决定它还要经历多少次后续压缩。

PARSER 没有让某个 chunk 因为出现得早就承担更多遗忘风险，也没有让某个 chunk 因为位于中间而天然处于劣势。

chunk 可以在新查询下重新读取

PARSER 不会在第一次扫描后永久丢弃某个 chunk。

第一轮中看似无关的 chunk，第二轮可能因为主 Agent 获得了新实体而变得相关。此时，绑定该 chunk 的子 Agent 会在新的查询条件下重新检查内容。

因此，证据物理顺序与逻辑顺序可以脱钩。即使第二跳证据先出现在文档中，主 Agent 仍然可以先找到第一跳实体，再用新查询重新访问全部 chunk。

这也解释了为什么 PARSER 对证据距离不敏感：两条证据是否相隔 10 个段落或 3000 个段落，不会增加主 Agent 的推理链长度。它们分别位于哪个 chunk，只影响并行读取的宽度。

只训练主 Agent，而不是整个系统

PARSER 的另一个设计判断是：真正需要学习的不是局部阅读，而是调度策略。

每个子 Agent 面对的任务相对简单：

• 输入是一个短 chunk；

• 查询已经由主 Agent 聚焦；

• 只需要提取有明确依据的局部信息；

• 没有证据时可以直接放弃。

因此，论文保持所有子 Agent 冻结，使用现成模型完成局部阅读。训练只发生在主 Agent 上。

主 Agent 需要学习的是：

• 什么时候发起查询；

• 如何根据现有证据生成下一轮查询；

• 如何拆解多跳问题；

• 什么时候停止查询并提交答案。

论文使用 RLVR，也就是基于可验证结果的强化学习。奖励是二元 Exact Match：最终预测与标准答案匹配则获得奖励，否则没有奖励，没有额外加入格式奖励。

优化算法采用 GRPO。策略梯度只作用于主 Agent 自己生成的 token，子 Agent 返回的观察内容会被 mask，不参与梯度更新。

从系统角度看，这种训练方式有两个好处。

第一，训练对象与系统角色一致。PARSER 不要求局部阅读器学会复杂规划，只训练负责规划和聚合的主 Agent。

第二，训练成本不直接随文档长度增长。子 Agent 冻结后，长文档主要增加 rollout 期间的并行调用，而不需要为每个读取节点维护可训练参数和梯度。

不过，“只训练主 Agent”不等于训练很便宜。论文中的异步 RL 配置使用 6 张 H100，其中 4 张负责 rollout、2 张训练主 Agent，另外使用 10 张 H100 部署子 Agent。这个结果更应该理解为降低了可训练组件复杂度，而不是消除了系统资源成本。

实验设置：从 7K 一直拉到 896K token

论文主要在两个多跳问答数据集上评估：

• HotpotQA：训练与测试同分布；

• 2WikiMultiHopQA：作为分布外测试。

测试文档包含 50 到 6400 个段落，总长度约为 7K 到 896K token。同一批 128 个问题会在八种文档长度下重复评估，区别主要是加入的干扰段落数量。

主干模型使用 Qwen3.5-4B 和 Qwen3.5-9B。4B 和 9B 版本都使用 Qwen3.5-4B 作为子 Agent。推理时，文档 chunk 大小为 4096 token，主 Agent 最多执行 12 轮。

对比方法包括：

• 直接输入完整文档的 Qwen3.5；

• 支持百万 token 上下文的 DeepSeek-V4-Pro；

• 顺序记忆方法 MemAgent；

• 支持回看历史记忆的 ReMemR1。

评价指标采用 Sub_EM。

准确率：重点不是单点最高，而是长度是否稳定

在 HotpotQA 上，PARSER 最值得关注的不是某一个长度下的峰值，而是从 7K 到 896K token 的变化幅度很小。

在 HotpotQA 上，PARSER 的准确率从 7K 到 896K token 基本保持稳定，而全上下文与顺序记忆方法随长度增加明显退化。（本文根据材料数据绘制）

4B 主干的结果如下：

相对于最强顺序记忆基线，PARSER 平均提升约 5.7 个百分点；在 896K token 上，差距扩大到约 12.0 个百分点。

9B 主干下，PARSER 在 HotpotQA 上的平均准确率为 86.79，MemAgent 为 80.05，ReMemR1 为 78.39。PARSER 相比最强顺序记忆基线高约 6.7 个百分点。

论文还将 9B 版本与 DeepSeek-V4-Pro 的全上下文 think-max 设置比较。后者在 HotpotQA 上平均为 80.47，PARSER 为 86.79，相差约 6.3 个百分点。

这里不能简单得出“小模型全面超过百万上下文大模型”的结论，因为二者采用的是不同系统结构和推理方式。更准确的解读是：在这组长文档多跳问答设置中，把读取变成多轮、查询驱动的并行检索，比单次把完整文档交给长上下文模型更稳定。

分布外结果同样没有随长度明显退化

在 2WikiMultiHopQA 上，4B PARSER 的平均准确率为 87.04，896K token 时为 86.98；9B PARSER 的平均准确率为 88.48，896K token 时为 88.02。

相比之下，顺序记忆方法的分布外表现下降更明显：

作者将这种分布外稳定性部分归因于阅读与推理的解耦：主 Agent 不直接读取训练文档，也不学习特定风格的循环摘要；负责阅读的子 Agent 又保持冻结。

这是一个合理解释，但仍然主要来自当前实验结果，并不能直接外推到所有领域文档。

受控实验比主表更能说明问题

仅看不同文档长度，可能无法区分性能下降究竟来自 context rot、干扰段落增多，还是记忆机制本身。

因此，论文分别控制了证据位置、逻辑顺序和相对距离。

改变证据的绝对位置

作者将 HotpotQA 的证据段落放到约 894K token 文档中的不同百分位区间，同时保持干扰段落和其他位置不变。

MemAgent 在证据位于中间区间时明显下降，ReMemR1 的回看机制有所缓解，但仍然存在波动。PARSER 在不同位置下大致维持在 82% 到 86% 区间。

这支持了“并行读取带来位置对称性”的解释。

反转证据的逻辑顺序

作者从 2WikiMultiHopQA 中选择 512 个两跳问题，构造两份包含完全相同段落的长文档，唯一区别是证据段落的相对顺序：

• 一份按照逻辑依赖顺序排列；

• 另一份将证据顺序反转。

MemAgent 从 66.5% 降到 23.3%，ReMemR1 从 75.5% 降到 61.7%。PARSER 则从 96.4% 变为 97.1%，基本没有受影响。

这个实验直接对应了方法的核心主张：推理顺序不应该由文档顺序决定。

拉大两条证据之间的距离

作者固定前后填充段落，并逐步增加两条证据之间的干扰段落数量。

随着距离从 0 到 200 个段落增加到 3200 到 3400 个段落，MemAgent 从 50.0% 降至 44.6%，ReMemR1 从 77.2% 降至 61.0%。PARSER 始终维持在约 87% 到 89%。

这表明顺序记忆方法必须让第一条证据穿过大量后续记忆更新，而 PARSER 可以在不同轮次独立读取两条证据，再由主 Agent 组合。

延迟：从按文档长度串行，变成按推理轮数串行

在单并发设置下，MemAgent 的延迟基本随着文档长度线性增长：

• 7K token：10.56 秒；

• 112K token：112.59 秒；

• 448K token：438.61 秒；

• 896K token：876.20 秒。

PARSER 对应为：

• 7K token：5.33 秒；

• 112K token：13.30 秒；

• 448K token：42.19 秒；

• 896K token：78.22 秒。

在 896K token 上，PARSER 相对于 MemAgent 的延迟缩短约 11.2 倍。

单并发下，MemAgent 的延迟随文档长度近似线性增长，PARSER 在 896K token 时从 876.20 秒降至 78.22 秒。（本文根据材料数据绘制）

这个差距不只是并行请求带来的。两者生成 token 的模式也不同。

MemAgent 每处理一个 chunk，都要生成一份可能包含数百或上千 token 的新记忆。随着 chunk 数量增加，总输出 token 数近似线性增长。在 896K token 设置下，论文统计 MemAgent 平均生成 187058 个输出 token。

PARSER 中，大部分子 Agent 只返回很短的无结果响应，聚合时还会将其丢弃。相同长度下，主 Agent 平均生成 541 个 token，所有子 Agent 合计生成 804 个 token。

因此，PARSER 同时利用了两种稀疏性：

• 执行上的并行：不同 chunk 可以同时读取；

• 输出上的稀疏：只有少数包含相关证据的 chunk 返回有效内容。

不过，论文报告的是每个测试子集总墙钟时间除以 128 个样本得到的摊销时间，并不完全等同于在线系统中单个请求的端到端响应时间。

资源配置也不完全相同：Full-context 和 MemAgent 使用一张 H100，PARSER 使用一张 H100 部署全部子 Agent，并用一张 RTX 3090 部署主 Agent。论文认为主 Agent 与子 Agent 交替运行，因此比较仍然有效，但这些数字更适合被理解为特定部署配置下的系统级结果，而不是严格等 GPU 资源下的纯算法速度对比。

每轮扫描全部 chunk，代价并没有消失

PARSER 把文档长度从串行深度变成了并行宽度，但宽度本身需要硬件承接。

每一轮查询都会广播给全部 chunk。即使绝大多数 chunk 最终没有返回有效证据，它们仍然需要执行模型 prefill 和局部判断。

如果文档长度为 ，被切成  个 chunk，独立编码这些 chunk 的总 prefill 复杂度可写为：

这低于直接对完整文档做一次标准注意力的 ，但 PARSER 可能进行  轮查询。如果无法复用 chunk 的 KV Cache，每一轮都需要重新 prefill，计算量会上升到：

论文的实现利用 SGLang 缓存固定前缀。由于同一个子 Agent 始终绑定相同 chunk，不同轮次的输入主要只在查询后缀上变化，因此可以缓存指令和 chunk 对应的 KV 状态。

但这种优化依赖足够的 GPU 显存和缓存命中。一旦高并发导致 KV Cache 被驱逐，子 Agent 就必须重新编码 chunk，PARSER 的优势会收窄。

实验也反映了这一点。

在 896K token 下：

并发提高后，MemAgent 可以更充分地利用批处理，而 PARSER 面临更大的 KV Cache 压力，两者差距明显缩小。

所以，“并行读取让延迟不再随文档长度增长”需要加上工程条件：有足够资源同时服务大量 chunk，并且能够维持较好的缓存复用。否则，并行宽度会重新表现为计算、显存和调度压力。

短文档不一定值得使用多 Agent

PARSER 不是所有输入长度下延迟最低的方法。

在 7K token、单并发设置中：

• Full-context 非思考模式为 1.16 秒；

• PARSER 为 5.33 秒；

• MemAgent 为 10.56 秒。

短文档可以一次完成 prefill，而且只需要生成一个简短答案。此时，多轮主 Agent 调度、子 Agent 广播和结果聚合反而是额外开销。

随着文档增长，全上下文方法的注意力计算和显存需求快速上升，PARSER 才逐渐表现出优势。在 896K token、单并发设置下，全上下文非思考模式为 185.42 秒，PARSER 为 78.22 秒。

这意味着实际系统可能不应该固定使用一种路径。短文档直接输入，中长文档再切换到并行读取，会比不加区分地启用多 Agent 更合理。论文没有评估这种自适应路由，但其延迟数据已经说明了这个边界。

chunk 越大，context rot 会重新出现

PARSER 的效果并不只是来自主 Agent 的多轮查询，短 chunk 本身也很重要。

论文比较了不同 chunk 大小。4B 版本在 4096 token chunk 下，HotpotQA 平均准确率为 84.57。随着 chunk 增大，结果逐步下降：

当一个子 Agent 直接接收完整文档时，系统虽然保留了主 Agent 的查询调度，但长输入中的信息捕获能力仍然明显下降。

这说明 PARSER 的收益来自两个部分：

• 主 Agent 根据证据动态改写查询；

• 子 Agent 在短上下文中完成局部定位。

如果 chunk 太大，子 Agent 自己也会遭遇 context rot；如果 chunk 太小，子 Agent 数量、调度开销和 KV Cache 数量又会上升。4096 token 是论文推理实验中的默认设置，但不能直接视为其他模型和任务的通用最优值。

子 Agent 可以轻量，但不能太弱

论文固定 4B 主 Agent，分别使用 2B、4B 和 9B 子 Agent。

平均准确率分别为：

• 2B 子 Agent：78.26；

• 4B 子 Agent：84.57；

• 9B 子 Agent：84.77。

从 2B 提升到 4B 有明显收益，但继续扩大到 9B 后基本饱和。作者认为，这是因为经过问题拆解和文档切块后，子 Agent 面对的是短上下文中的定向证据提取，4B 模型已经具备足够能力。

这个结果支持冻结轻量子 Agent 的设计，但边界也很明确：子 Agent 的任务必须能够被拆解成局部、明确、可验证的问题。

如果某条证据本身需要跨段落语义整合，或者局部 chunk 无法独立判断其相关性，那么“子 Agent 只做简单提取”的假设可能不再成立。论文主要在多跳问答上验证，还没有证明同样的拆解方式能稳定覆盖法律分析、长代码库理解或复杂科研文献综合等任务。

RL 有用，但架构本身已经贡献了大部分长度稳定性

论文还比较了不经过 RL 的 PARSER。

在 HotpotQA 上：

• 4B PARSER 从 74.42 提升到 84.57；

• 9B PARSER 从 76.24 提升到 86.79。

在 2WikiMultiHopQA 上：

• 4B 从 82.85 提升到 87.04；

• 9B 从 84.86 提升到 88.48。

RL 对最终准确率有明显帮助，尤其是在同分布 HotpotQA 上。但未经 RL 的 PARSER 已经表现出较好的长度稳定性，并且明显优于未经训练的顺序记忆 Agent。

这说明两件事不能混在一起：

• 并行读取和多轮动态查询，主要改变了证据访问结构；

• RL 主要优化主 Agent 如何使用这个结构。

换句话说，长度稳定性首先来自架构归纳偏置，RL 再进一步提高查询策略和停止策略的质量。

如何看待这篇论文

PARSER 最有价值的地方，不是简单提出了“多 Agent 并行读文档”。并行 MapReduce、leader-worker 和多轮协作都不是全新的模式。

它真正讲清楚的是长上下文 Agent 中一个经常被忽略的依赖问题：

不应该因为文档是线性排列的，就让推理也沿着文档顺序线性推进。

顺序记忆把文档长度变成了状态传播深度，每个 chunk 都要在信息不完整时参与一次不可逆压缩。PARSER 则把所有 chunk 保留为可重新访问的外部信息源，由主 Agent 根据已经发现的证据不断修改查询。

这使系统的串行深度更接近问题本身的推理跳数，而不是文档被切成了多少块。

但代价同样清楚：

• 每轮都要访问全部 chunk；

• 并行宽度需要实际算力承接；

• KV Cache 是否能够保留，直接影响多轮读取成本；

• 高并发下，延迟优势从 11 倍收窄到约 1.3 至 1.7 倍；

• 短文档上，全上下文直接回答更快；

• 当前证据集中在合成扩展后的多跳问答；

• 训练和部署都使用了较多 GPU 资源；

• 独立 chunk 阅读依赖问题能够被拆成局部可回答的子查询。

因此，PARSER 更像是对长上下文 Agent 执行图的一次重新设计，而不是一种无条件替代长上下文模型或 RAG 的方案。

它给出的技术判断值得保留：当文档很长、证据稀疏、问题需要多跳推理，而且系统有能力并行服务大量 chunk 时，与其让一个 Agent 顺序读完整份文档并反复压缩记忆，不如让多个读者负责覆盖，再让一个主 Agent 只为问题需要的推理深度付出串行成本。

原始链接

https://arxiv.org/abs/2609.06702

https://cuhk-parser.github.io/