把长文档的"阅读"和"推理"拆开，AI处理百万字文档快了11倍 Chinese original

你有没有想过一个问题：如果让你在一本八百页的书里找答案，你会怎么做？

大概率不会从第一页开始死磕到最后一页，边读边在脑子里存一份笔记，读到第两百页时前面记的东西早忘得差不多了。你更可能是先看看目录，带着问题去翻，翻到哪个章节像是有关系就细读一下，读完发现还差点线索，再翻另一个地方接着找。

现在的AI大模型处理长文档，走的却是第一种笨办法。这篇来自香港中文大学的论文PARSER，就是想把AI的阅读方式，从死磕通读改成带着问题去翻书。

**长文档处理的老大难问题**

先说说现在的AI模型是怎么读长文档的。

如今的大语言模型（LLM），也就是ChatGPT这类AI系统背后的核心技术：能记住的上下文窗口已经能到一百万个字符（token）这个量级了。听起来应该够用了对吧？但现实很打脸。

论文里做了个实验，让AI直接读完整篇文档回答问题，文档从7000字涨到89.6万字的过程中，准确率从七十多分一路跌到三十几分，跌了四十多个百分点。这不是窗口不够大的问题，窗口明明还有富余，模型就是不会用。

这个现象业内叫"上下文腐烂"（context rot：随着输入文本变长，模型即使窗口没塞满，性能也会下降的现象）。更具体一点的表现叫"迷失在中间"（lost in the middle：证据放在文档中间位置时，模型更容易忽略它，放在开头或结尾反而记得住），已经有研究证实了这一点。

面对这个问题，业界想出了一个叫"顺序记忆"（sequential memory：模型把长文档切成一段一段，按顺序读，每读一段就把当前信息和之前攒的记忆压缩合并成新记忆，一直往前滚）的办法。代表作是MemAgent，用强化学习训练出这套流程，据说能处理百万字文档，还只用很小的上下文窗口。

这招听起来挺聪明，但有个致命的结构性缺陷。

文档必须严格按顺序读一遍，读到第五百段的时候，前面四百九十九段已经被压缩成了一份简短的记忆摘要，很多细节可能已经被挤掉了。这就好比你参加一场需要记住很多细节的考试，但规定你只能用一张便利贴记笔记，每翻一页书就得把便利贴上的内容重新精简一次给新内容腾地方。如果证据出现在第一页，你能记得清清楚楚；如果证据出现在中间某一页，等你翻到最后，那张便利贴上早就没它的痕迹了。如果不这样限制笔记大小会怎样？那就退回到了直接读全文的老问题，窗口塞不下，或者塞得下但性能照样崩。

这个便利贴机制还带来第二个麻烦：处理第五百段的时候，必须等第四百九十九段处理完，因为记忆是滚动更新的，一步接一步。文档越长，这个链条越长，推理时间跟着文档长度线性增长，怎么都甩不掉。

论文管这两个问题叫**位置敏感性**和**推理延迟**，前者是记不住中间的证据，后者是处理时间随文档长度线性暴涨。

**核心思路：读的顺序和想的顺序，本来就不该是一回事**

PARSER这篇论文提出了一个挺朴素但很有力的观察：

文档被读的顺序是文档决定的，问题该怎么被推理是问题决定的。

这两个顺序凑巧重合的场景，其实很少。顺序记忆模式让第一个顺序绑架了第二个，而PARSER要做的就是把它们彻底分开。

具体怎么分开？论文设计了两种角色。

一种叫**子代理**（subagent：绑定在某一个文档片段上的小型AI助手，只负责读自己那一块内容，收到问题后如果自己那块没有相关信息就直接说"不知道"），每个子代理只认自己那一小段文档，所有子代理同时并行工作，读的时候互不依赖。

另一种叫**主控代理**（lead agent：整个系统里唯一需要训练、唯一负责推理决策的AI，它从头到尾看不到原始文档，只看到子代理返回的发现），它压根不碰原始文档，只是不断地向所有子代理广播查询，收集反馈，然后决定接下来该问什么。

这个过程被称为**"分散-聚合"**（scatter-gather：主控代理向所有子代理同时发出同一个查询叫分散，收集各子代理返回的结果叫聚合，这一轮完成后主控代理据此决定下一轮问什么），一轮一轮循环，直到主控代理觉得信息够了，给出最终答案。

这就好比一个侦探要破一个跨越多个地区的案子。侦探自己不去挨个城市走访取证，而是同时给所有城市的当地警察局发同一份询问单，比如"有没有人见过某个特定车牌的车"。所有城市同时查，查完集中汇报给侦探。侦探看完这一轮的汇报，发现某个城市提到了一个可疑地址，就发出第二轮询问单，专门去查那个地址的更多细节。整个案子破案的快慢，取决于侦探需要问几轮问题，而不是取决于有多少个城市要查。如果换成让侦探本人挨个城市跑一遍，城市越多跑得越久，还容易在跑到第十个城市时忘了第一个城市查到的细节。

这个设计带来一个直接的好处：文档长度从"推理链条的深度"变成了"并行宽度"。文档从7000字涨到89万字，只是意味着并行读的子代理数量变多了，主控代理需要思考几轮才能问清楚一个问题，跟文档长度没关系，只跟问题本身有多复杂有关。

论文里有个数据很直观：MemAgent处理89.6万字文档时要走187058个输出词符（token：文本被切分成的最小处理单元，可以理解成词或字的片段），因为每读一段都要生成一次记忆更新，动辄几百到上千字。而PARSER的主控代理加所有子代理加起来才产出541加804个token，因为大多数子代理面对不相关的查询直接回"不知道"，根本不用长篇大论。

**为什么子代理可以不训练**

PARSER只训练主控代理，子代理保持"冻结"状态，用现成的、没有专门微调过的模型就行。

这个决定听起来有点大胆，训练本该越多越好才对，为什么偏偏不训练子代理？

原因在于任务被拆解得足够简单了。子代理面对的是一个已经被主控代理提炼过的具体小问题，加上一段不长的文档片段，任务就是判断这段文字里有没有相关信息，有就摘出来，没有就说没有。这种任务对现成模型来说已经够用了。

论文专门做了实验验证这一点。用20亿参数、40亿参数、90亿参数三种规模的模型分别当子代理，发现从20亿升到40亿，平均分从78.26涨到84.57，涨幅明显；但从40亿再升到90亿，只涨到84.77，几乎没提升。这说明子代理的任务已经简单到"够用就行"，堆更大的模型是浪费。

这就好比找人帮你在一堆文件里查一句话是否出现过。你不需要请一个博士来做这件事，普通职员一眼就能扫出来。真正需要动脑子、需要经验判断的，是决定"接下来该查哪句话""前面查到的线索指向哪个方向"，这才是需要重点培养的核心人才,对应到系统里就是主控代理。

训练方式用的是**强化学习**（reinforcement learning：让模型通过不断尝试和获得反馈来学习，而不是直接告诉它标准答案该怎么写），具体用了GRPO算法（Group Relative Policy Optimization：一种通过比较同一批多个回答的相对好坏来调整模型的训练方法），奖励信号很简单，答案对不对，对了给分，错了不给分，这种奖励叫**可验证结果奖励**（verifiable outcome reward：用能自动判断对错的规则来打分，而不是靠人工标注或另一个模型来评判）。

训练数据来自HotpotQA数据集，一种需要多步推理才能回答的问答任务，比如"谁的导演去世更早"这类需要先找到导演再比较日期的问题。构造了32768条训练样本，每条平均塞进两百个段落，大约2.8万字。

**证据放哪儿都不怕：三组对照实验**

光说理论上PARSER不受证据位置影响还不够有力，论文专门设计了三组对照实验来验证这一点。

第一组叫**证据位置控制**：把支持答案的关键段落，人为放到文档不同的百分位区间，比如文档最开头的10%、正中间的50%到60%，或者靠近末尾的90%以后，看模型表现有没有变化。

结果很明显，MemAgent一旦证据被放在文档50%到70%的位置区间，准确率明显掉下去,从八十多分掉到六十多分。这符合前面说的便利贴逻辑：证据出现在中间，前面的压缩记忆还没意识到它重要,后面的更新又把它挤掉了。PARSER全程稳定在83到87分之间，几乎是一条水平线。

第二组叫**证据顺序控制**：故意把两段有逻辑先后关系的证据顺序倒过来放。举个例子，一个问题需要先知道两部电影各自的导演是谁，再比较两个导演谁去世更早。正常顺序是先给导演信息再给去世日期，倒过来就是先给去世日期再给导演信息。

这个实验结果非常戏剧化。正常顺序下MemAgent能拿到66.5分，一旦顺序反过来，直接掉到23.3分，跌了43分。PARSER正常顺序96.4分，反过来97.1分，基本没差。

论文里附了一个具体案例特别值得说说。问题是"《Everything's Ducky》和《Karthika》这两部电影，导演谁去世更早"，答案需要的两个导演去世日期先出现在文档里，导演和电影的对应关系却出现在更靠后的段落。MemAgent读到去世日期的段落时，还不知道这两个人跟提到的电影有关系，于是没把日期写进记忆。等读到后面段落知道了导演是谁，早前的日期已经被挤没了。最后MemAgent给出的记忆里，只剩下两个导演的名字，日期全没了，这道题根本答不出来。而PARSER处理同一道题，靠着分轮查询,先问导演是谁，再单独问这两个导演的去世日期，两轮问题各自独立，谁先谁后无所谓,轻松给出正确答案。

这个案例暴露的问题其实很有普遍性:**顺序记忆系统的推理，被文档的呈现顺序牵着鼻子走，而不是被问题的逻辑结构牵着走**。

第三组叫**证据距离控制**：保持两段证据的先后顺序不变，只改变它们之间隔了多少段无关内容。

结果同样是MemAgent随着中间隔的段落变多，表现越来越差，从77.2分一路跌到61分；PARSER始终稳定在87到88分之间。原因也很直白，第一条证据要撑过越来越多次记忆更新才能等到第二条证据出现，中间隔得越远，越容易被挤掉。而PARSER的子代理各自独立处理各自的段落,两段证据的物理距离对系统而言根本不存在。

**推理速度：11倍的差距从哪来**

除了准确率，PARSER在推理速度上的优势也很扎实。

在单次请求的场景下，处理89.6万字文档，MemAgent要876秒，PARSER只要78秒，差了11倍多。

原因藏在推理步数里。MemAgent的步数跟文档切成了多少个片段成正比，文档越长片段越多，步数线性往上涨。PARSER的步数取决于问题需要推理几轮，而不是文档有多少片段,同一批问题不管文档变多长，需要推理的轮数基本不变，稳定在4轮左右。

这就好比两种查字典的方式。一种是把字典从头翻到尾，一页一页找，字典越厚翻得越久。另一种是先看目录定位到大概章节，再往细里查，翻的次数取决于这个词有多难查，跟字典总共有多少页没什么关系。

不过这个11倍优势在高并发场景下会缩水。同时处理16个请求时，优势降到1.7倍左右。原因是MemAgent这种线性流程更容易靠批处理摊薄成本，而PARSER如果显存不够存住所有片段的**KV缓存**（KV cache：模型处理文本时为避免重复计算而保留的中间状态，能让后续同样内容不用重新计算），子代理们每一轮都要重新读一遍自己那段文档，反而增加了计算量。论文的附录里专门分析了这一点，这也是诚实地承认了方法不是没有代价的。

**性能对比：数字说话**

论文用了两个多跳问答数据集来测试，一个是HotpotQA，训练用的就是这个,属于"分布内"（in-distribution：测试数据和训练数据来自同一分布，模型见过类似的模式）测试；另一个是2WikiMultiHopQA，属于"分布外"（out-of-distribution：测试数据和训练时用的数据模式不同，能检验模型是不是真学会了通用能力，而不是死记硬背了训练集）测试，专门用来检验泛化能力。

在HotpotQA上，用40亿参数模型做主控代理，PARSER平均分84.57，比最强的顺序记忆基线（ReMemR1，78.91分）高出5.66分。文档长度拉到89.6万字这种极端情况下，PARSER还能维持85.42分，MemAgent只有72.92分，差距拉大到12个百分点。换成90亿参数的模型，PARSER平均分86.79，甚至超过了支持一百万字上下文的DeepSeek-V4-Pro（80.47分），高出6.3个百分点。

分布外测试更能看出问题。在2WikiMultiHopQA上，MemAgent的表现直接崩了，40亿参数版本平均分只有60.61,比它在HotpotQA上的78.58分掉了18分。原因值得琢磨一下:MemAgent训练的时候学的其实是怎么根据具体的训练文档生成摘要，换了一批没见过的文档，这套本领就不太管用了。而PARSER因为主控代理压根不直接接触文档,它学的是怎么针对问题提问、怎么整合答案,这种能力天然更通用。PARSER在这个数据集上依然稳在87分左右，几乎没掉分。

**换一批子代理试试：兼容性验证**

论文还测试了主控代理能不能配合不同类型的子代理工作，而不用重新训练。

一种是让子代理开启"思考模式"（相当于让子代理生成的答案前先展示一段推理过程，而不是直接给结论），配合主控代理后平均分85.55，比单独的思考模式全文档回答（65.82分）高出近20分。

另一种叫**直接语料交互**（DCI：Direct Corpus Interaction，一种让AI直接用类似rg、grep这样的命令行文本搜索工具去查找原始语料，而不是把内容塞进上下文窗口的检索方式），配合主控代理后平均分84.67，比单独使用DCI代理（75.61分）高出9个百分点。

这说明主控代理学到的其实是一种相对通用的"怎么提问、怎么整合信息"的策略，换掉底层执行阅读的模块，整体框架依然能跑得起来。

**没那么完美的地方**

论文也坦诚地展示了一个失败案例，挺有意思。

问题是"格鲁吉亚公主Elene的丈夫是谁"，文档里有两条相关证据，一条正确指出Elene是某位国王的女儿，另一条通过身份链条推出正确答案应该是某位王子。但有个子代理负责的片段里刚好提到另一个同名的人叫Elena（俄国的一位公主），这个子代理只看到自己那一小段文字，压根不知道主控代理问的是哪个Elene,于是很自信地回答"她的丈夫是希腊和丹麦的尼古拉斯王子"。

主控代理收到这个看起来很干脆、很直接的回答，居然就信了，没有进一步核实这个回答是不是真的对应问题里说的那个人，最终给出了错误答案。

这暴露了PARSER架构里一个真实存在的风险：子代理看不到主控代理的完整推理过程，只看到孤立的一句查询,遇到名字相似、指代模糊的情况，很容易答偏。而主控代理也看不到子代理背后的原始文段，没法直接核验这段回答到底靠不靠谱。论文说这种情况是偶发的，多数时候主控代理会多问几轮细化查询来交叉验证，但这次没有触发这个纠错机制。

Q&A

Q1：PARSER是什么，它和之前的长文档处理方法有什么不同？

A：PARSER是香港中文大学团队提出的长文档问答系统，核心创新是把"阅读文档"和"推理问题"拆成两个独立角色。之前的方法（如MemAgent）要求AI按顺序读完整篇文档并不断压缩记忆，而PARSER让多个子代理同时并行读文档片段，主控代理只负责多轮提问和整合答案，不直接接触原文档。

Q2：PARSER为什么不用训练子代理，只训练主控代理？

A：因为子代理的任务已经被简化到很基础的程度，只需判断某个文档片段里有没有相关信息，有就摘出来，没有就说不知道，现成的模型就能胜任。实验显示把子代理从40亿参数升到90亿参数几乎没有提升，说明堆更大模型没意义，真正需要学习的是主控代理怎么提问、怎么整合信息的策略。

Q3：PARSER处理长文档的速度为什么比MemAgent快很多？

A：因为MemAgent必须按顺序一段一段处理，文档越长步骤越多，处理时间线性增长；而PARSER所有片段并行读取，推理步数只取决于问题需要几轮才能问清楚，跟文档长度基本无关。实验中处理89.6万字文档时，PARSER只需78秒，MemAgent需要876秒，快了11倍多。