当上下文长到一百万token，AI大模型的脑子会变笨吗

你有没有遇到过这种情况：跟一个人说了太多细节，他反而抓不住重点了？信息量一旦超过某个临界点，人的注意力就开始打折扣，该记住的没记住，不该在意的反而印象深刻。

这几年大语言模型也在经历一模一样的困境。厂商们疯狂比拼谁的上下文窗口更大,百万token、两百万token，数字越报越夸张。可实际用起来，很多人发现一个诡异的现象：喂给模型的文本越长，它答问题反而越不靠谱。业内给这个现象起了个名字，叫

context rot

context rot：指大语言模型在处理超长文本输入时，随着输入长度增加，推理和回答质量明显下降的现象，可以理解为"上下文越长，脑子越乱"。

这不是危言耸听。论文里提到，在RULER-QA这个测试百万token长度问答能力的基准上，标准的检索增强生成方法（也就是RAG）准确率直接崩到10.9%。十个问题里，模型答对的还不到两个。而这已经是业内相对成熟的技术方案了。

问题出在哪？来自新加坡国立大学和Adobe Research的研究团队给出了一个挺有意思的解释：不是模型笨了，而是两件本该分开做的事，被硬塞进了同一个脑子里。

一个被忽视的矛盾：找证据和做推理，根本是两码事

想让AI回答一个基于长文本的问题，其实拆开看是两步。

第一步是

grounding（上下文定位）

grounding：从海量文本中找出与问题真正相关的那部分内容，可以理解为"大海捞针"的过程。

模型得先在几十万甚至上百万字里，把跟问题相关的那几句话、那几个数字挑出来。这一步本质上是个搜索问题，文本越长，搜索空间越大，难度跟着涨。

第二步才是真正的

reasoning（推理）

reasoning：基于已经找到的证据信息，进行逻辑推导、多步骤综合，最终得出答案的过程。

这一步的难度其实跟文本长不长关系不大。不管你的问题藏在一万字里还是一百万字里，只要证据已经摆在眼前，推理这一步该有多难还是多难，不会因为原始文本变长而变难。

问题就出在这里：传统的Transformer架构里，这两步是拧在一起的，同一套注意力机制既要负责在海量文本里大海捞针，又要负责逻辑推理。当文本长度冲到百万级别，注意力机制的算力和"带宽"大部分被搜索任务吃掉了，留给推理的余量就所剩无几。

这就好比让一个人一边在嘈杂的菜市场里找一个熟人，一边心算一道复杂的数学题。如果菜市场很小，找人不费劲，他还能腾出精力算题。可如果菜市场大到望不到边，人流嘈杂到根本听不清彼此说话，他所有的注意力都耗在"找人"这件事上了，那道数学题他压根没心思算，哪怕题目本身并不难。如果不把这两件事分开，就算给这个人再聪明的脑子，也没用，因为他的注意力资源被找人这件事榨干了。

论文用一个概率公式把这个直觉严谨地表达出来。回答问题的概率，可以拆解成"先找到关键证据的概率"乘以"基于证据推理出正确答案的概率"。在传统架构里，这两项由同一套参数、同一个注意力窗口同时承担，随着文本变长，证据定位这一项会急剧退化，进而拖累整体表现。

借鉴大数据处理的老办法：分布式计算

搞清楚病根在哪，接下来就是怎么治。

研究团队想到了一个思路，这个思路其实一点都不新，只是没人把它用到大语言模型的长文本处理上：分布式计算。

这让人想起十几年前互联网公司处理海量数据时遇到的类似问题。当年谷歌搞出

MapReduce

MapReduce：一种分布式计算框架，核心思想是把大任务拆成很多小任务并行处理（Map），再把处理结果汇总（Reduce），最早由谷歌在2004年提出。

后来又有了更高效的Apache Spark。这些系统解决的问题跟现在AI面对的问题几乎是同构的：数据太大，单台机器的内存装不下，怎么办？答案不是造一台内存更大的机器，而是把数据切成很多片，分给很多台机器同时处理，最后把结果汇总起来。

论文的作者们意识到，一个大语言模型能稳定处理好的上下文长度，其实就相当于一台计算机的内存容量。数据超了，与其死磕造一个更大内存的模型（也就是死磕更长的上下文窗口），不如干脆多找几台"机器"分头处理。

于是他们提出了

DISCO

DISCO：全称是"Distributed Long Context Scaling with Grounding-Reasoning Disaggregation"，一套通过角色分工来处理超长文本的AI推理框架，核心思路是把"找证据"和"做推理"这两件事彻底分开，分别交给不同的模型来做。

这套系统里有两种角色。

第一种叫Worker（工作节点）,一大群轻量级的小模型，每个人手里只拿到整篇长文本的一小片，专心致志地在自己那一小片里找信息，不用管全局，也不用负责推理。

第二种叫Driver（驱动节点）,一个能力更强、擅长推理的大模型，它不直接看原始的长文本，只负责指挥Worker们去哪里找什么，然后把Worker们找回来的证据汇总、推理、给出最终答案。

这个分工模式，特别像一个侦探带着一队线人办案。侦探本人从不亲自去翻遍城市里每一栋楼的监控录像，那种体力活交给手下的线人，每个线人只负责盯一个片区。线人只需要报告"我这片区看到了什么"，不需要自己去推理案件的来龙去脉。侦探坐在办公室里，收集所有线人的汇报，再动脑子把线索拼起来，推出真相。如果让侦探自己一个人跑遍全城翻监控，他要么累死要么漏掉重要线索，就算他推理能力再强，也没法同时兼顾体力活和脑力活。

不是简单切块，而是像Spark一样动态调度

如果DISCO只是把长文本机械地切成几十份，分别丢给小模型处理一遍，再简单拼接结果，那和已有的一些"分块处理"方法（比如LLM×MapReduce）也没太大区别。

DISCO更精妙的地方在于，Driver不是傻乎乎地一次性把任务全甩出去，而是像指挥官一样动态规划。论文里用了一个计算机科学的经典概念：

DAG（有向无环图）

DAG：Directed Acyclic Graph的缩写，一种表示任务依赖关系的图结构，图中的节点代表具体任务，箭头代表任务之间谁先谁后的依赖关系，且整个图不会出现"循环依赖"。

Driver接到用户的问题后，会先把这个问题拆解成一张任务图。图里有两种节点。

一种叫

Narrow Action（窄动作）

Narrow Action：只依赖某一小片本地上下文即可完成的原子级信息提取任务，交给Worker执行，比如"找出实体A的出生日期"这种直接了当的查找指令。

另一种叫

Wide Action（宽动作）

Wide Action：需要综合多个来源信息才能完成的逻辑综合任务，交给Driver自己执行，负责把零散证据拼接成完整推理链条。

举个论文里真实出现的例子。任务是把一句卡拉曼加语（一种小语种）翻译成英语。训练完成后的Driver会很聪明地把这句话拆成三段，每段单独派给一个Worker去查对应的词汇含义，三个任务互不干扰，各自去自己负责的文本片段里精确定位。而训练之前的Driver则显得很笨拙，三次查询用的是同一个模糊的关键词"卡拉曼加语言"，甚至有一次直接把整句话原封不动地塞给某个Worker，指望它能从自己手头那一小片文本里蒙出整句翻译。结果是，训练后的版本一次性就检索到317条相关证据，训练前的版本只捞到69条，差了四倍还多。

更关键的是，DISCO不是一锤子买卖。Driver执行完一轮任务图后，会检查现有证据是否足够回答问题。如果不够，它会根据已经拿到的信息，重新规划下一轮的任务图，继续查漏补缺，直到信息够用或者达到最大尝试次数为止。这种"边查边想、动态调整"的机制，让整个系统对信息缺失有相当强的容错能力。论文的实验显示，即便随机丢弃30%的检索结果，系统依然能靠重新规划把问题绕过去，只有当丢失比例逼近50%的极端情况下，性能才会明显崩溃。

用强化学习训练Driver学会更聪明地指挥

光有这套分工架构还不够，因为怎么拆解任务、怎么规划DAG，并没有现成的标准答案可以照抄。这活儿得靠Driver自己练出来。

研究团队选择用

GRPO（组相对策略优化）

GRPO：Group Relative Policy Optimization的缩写，一种强化学习训练算法，通过让模型对同一个问题生成多条不同的解题轨迹，再比较这些轨迹的优劣来调整模型参数，最早由DeepSeek团队在其数学推理模型中提出并验证有效。

来训练Driver。奖励函数由三部分构成:一是答案是否正确，二是答案是否真的是从检索到的证据里推导出来的（而不是模型凭空编的，这一项专门用来防止幻觉），三是生成的任务图格式是否规范、能不能被系统正确执行。

这里有个挺聪明的处理细节，叫做

奖励回传

奖励回传：在多轮次的任务执行过程中，把最终结果的奖励信号反向传播给中间每一步的决策，让模型明白哪一步规划间接导致了最终的成功或失败。

因为DISCO的一次完整推理往往要经过好几轮规划和执行，只有最后给出答案的那一刻才知道对错。如果不把这个最终的对错信号传导回前面每一步的规划决策，模型就没法知道自己第一步的任务拆解到底拆得好不好。

这套训练带来的效果非常直观。论文里做了对比实验，专门看格式规范这项奖励的作用。如果去掉这项奖励，Driver生成的任务图经常会出现语法错误或者依赖关系混乱，系统只能反复重试，光是处理这些无效指令就浪费大量时间，整体延迟从381秒飙升到499秒。有个案例更极端：一个涉及企业调查报表分析的任务，训练之前的Driver生成的八条查询指令全部格式错误，Worker一条有效信息都没提取出来，最后系统被迫在没有任何证据的情况下强行给出答案。而训练之后的Driver只用了三条格式规范的查询，一次性拿到224条有效证据，零错误。

实测效果：百万token下依然稳如老狗

说了这么多设计思路，最终还是得看数字说话。

在RULER-QA这个百万token级别的问答测试里，用Qwen3-8B做底座，标准RAG方案的准确率是10.9%，DISCO达到了78.4%。这不是提升几个百分点的差距，是差了七倍还多。

在LongBench v2这个更贴近真实场景的长文本理解测试里，DISCO用Qwen3-14B跑出48.7分，比直接把全部文本塞进模型窗口的做法（38.9分）高出9.8分。经过强化学习训练之后，这个分数进一步涨到50.9分。

有个细节特别值得说一说。论文测试了打开"思考模式"（也就是让模型多花点时间做链式推理）之后带来的收益。在传统的"全部塞进窗口"方案里，开启思考模式只带来了0.9到5.6分的提升，说明模型大部分的思考精力都耗在了在噪音里找证据这件事上，真正花在推理上的余量不多。而在DISCO架构下，因为证据已经被Worker提前筛选干净，开启思考模式带来的提升一下子涨到5.5到13.5分。这个对比本身就是最有力的证据，说明分离"找证据"和"推理"这两件事，确实把原本被浪费掉的推理能力给解放出来了。

成本方面的表现也很亮眼。论文用Gemini-3-Pro-Preview做实验，DISCO达到的准确率是71.3%，跟直接把全部文本塞进模型（72.2%）几乎打平，但推理成本从126.7美元降到了20.4美元，降幅超过六倍。这意味着，用DISCO这套架构，可以用便宜得多的方式获得接近顶级模型直接处理长文本的效果。

论文还测试了在固定8块H100显卡算力预算下，处理256K到1M token长度时的端到端延迟表现。传统的串行多智能体方法（比如Chain-of-Agents）随着文本变长，延迟几乎是线性暴涨，处理1M token时要花上一千多秒。而DISCO的延迟曲线几乎是平的,不管文本从256K涨到1M，处理时间基本没有明显增加。这背后的原因也很直接：因为繁重的文本扫描工作被分摊给了大量轻量级Worker并行处理，而不是靠一个大模型硬啃全部文本，所以文本变长带来的压力被"摊薄"了，而不是集中压在一个节点上。

这套架构换个模型组合还灵不灵

一个方法如果只在特定的模型组合下有效，那价值要打折扣。研究团队专门做了跨模型族的验证，换用LLaMA-3.1-70B-Instruct做Driver，搭配Ministral-3-8B做Worker，准确率从25.9分（全文本基线）提升到28.7分。换成Ministral-8B-Reasoning做Driver，搭配Qwen3-4B-Instruct做Worker，准确率从32.41分涨到37.96分。

更有意思的是，Worker的具体型号似乎没那么重要。同样用LLaMA-3.1-70B做Driver，分别换用Ministral-3-8B和Qwen3-4B做Worker，两者拿到的分数几乎一样（28.7对27.8）。这说明Driver对Worker的要求其实很朴素，只要能老老实实完成"从自己手头这一小片文本里找信息"这个基础任务就够了，不需要Worker本身多聪明。这就好比一个乐队的指挥，对每个乐手的要求是能准确演奏谱面上分配给他的那一小段旋律，而不是要求每个乐手都懂整部交响乐的结构。真正决定演出水准的，是指挥对全局的把控能力，而不是某个乐手个人有多出众。如果反过来要求每个乐手都精通全局，那乐队根本没法运转,因为没人愿意花那么多钱雇一整队水平顶尖的乐手，而且协调成本会高到失控。

写在后面

读完这篇论文，最触动我的其实是一个挺朴素的类比：AI模型的有效上下文窗口，被拿来跟计算机的内存做对比。这个类比听起来简单，但背后的逻辑其实颠覆了这几年整个行业的默认路径。

过去两三年，几乎所有厂商解决长文本问题的思路都是同一条路：造更大的窗口。从32K到128K，再到百万甚至两百万token，大家默认的假设是"内存不够就扩内存"。但DISCO这篇论文提醒我们，计算机科学早就在几十年前走过这条弯路,单机内存扩到极限之后，业界最终选择的不是继续死磕硬件，而是转向分布式架构。这个历史经验被搬到大语言模型领域，居然依然成立，这件事本身挺让人意外的。

另一个值得单独拎出来说的细节是那个"格式错误导致完全崩溃"的案例。训练之前的Driver在企业调查分析任务里，八条查询全部格式错误，最后系统在零证据的情况下被迫强行作答。这个案例让我意识到，很多时候AI系统的失败根源，不是它"不够聪明"，而是它连最基础的"把指令写对"这件事都没做好。这跟人类团队协作时经常出现的问题其实很像,一个能力很强的人，如果布置任务时说得含糊不清，团队照样会一团乱麻，问题往往不出在执行者身上，而出在指挥者有没有把话说清楚。

这篇论文没有解决的问题也很明显。整套系统依赖Driver反复规划、多轮迭代才能收敛，如果遇到极端复杂、信息极度稀疏的任务，会不会陷入无休止的重新规划循环？论文里设了最大重规划次数为10作为兜底，但这个数字本身其实是个经验值，换到别的任务场景上是否依然合适，还有待验证。另外，Worker之间目前是完全独立并行工作的，彼此互不通信,如果某个答案真的需要跨越多个分片、层层递进地综合信息，现在这套机制是否够用，也是个值得继续追问的问题。

Q&A

Q1：DISCO是什么？

A：DISCO全称"Distributed Long Context Scaling with Grounding-Reasoning Disaggregation"，是由新加坡国立大学和Adobe Research提出的一套AI长文本处理框架，核心思路是把"找证据"和"做推理"分开，交给不同的模型分工完成，从而解决大模型处理超长文本时准确率下降的问题。

Q2：DISCO和普通的RAG检索增强生成有什么区别？

A：普通RAG依赖向量相似度检索，容易漏掉语义上相关但字面不相似的信息，在百万token长度下准确率会跌到10.9%左右。DISCO用生成式小模型（Worker）主动扫描理解每个文本分片，而不是简单做相似度匹配，同一测试下准确率能达到78.4%。

Q3：DISCO会不会让大模型处理长文本的成本更高？

A：不会，反而更省钱。论文用Gemini-3-Pro-Preview做实验，DISCO准确率71.3%，接近直接处理全文本的72.2%，但推理成本从126.7美元降到20.4美元，降幅超过六倍，因为繁重的扫描工作被分摊给了大量轻量级模型并行处理。