当LLM的推理有了「水表」

> ICML 2026 · 上交大×阿里×上海AI Lab

---

一个老问题：功劳算谁的？

想象一个中学生解一道几何题。他写了满满两页草稿，最后一步算错了，答案得零分。老师批改时，只能看到最终答案——那前面两页里，到底哪一步是关键？哪一步是弯路？

这就是RL训练大模型时的核心困境：模型生成几百个token，最后只对答案打分。分数回来，怎么分？

GRPO的做法是——人人有份。每个token分到的credit差不多，像大锅饭。问题很明显：那些真正支撑正确答案的token，信号被稀释了；那些凑数的、绕远的token，反而蹭到了奖励。

FlowTracer这篇工作的起点，就是一句话：

> 「注意力不是装饰品，它本身就是推理的路线图。」

但这句口号背后有一个更具体的观察：现有credit assignment方法要么是均匀分配（GRPO给所有token一样的权重），要么是孤立点式启发（看单个token的熵、注意力统计量），二者都忽略了信息传播的全局结构——哪些token之间在互相通信？哪些token只是孤岛？

---

把水纹变成地图

论文的核心直觉很干净。模型看一个token时，注意力权重告诉你「我在从哪拿信息」。多层多头注意力叠加起来，本质上是一张信息传输的有向图：token是节点，注意力权重是管道容量。

但原始注意力图有两个毛病：

第一，死胡同太多。 很多token之间的注意力连接很强，但这条路径根本走不到答案。就像城市水管里有一大堆互相连通的支管，但水最终到不了你家——能量在局部打转，是结构性浪费。

第二，流量不守恒。 注意力权重本身不保证「流入=流出」，这不是一个真正的流网络。你没法直接跑最大流算法。

作者在这里做了一件事，叫 Doob-h-like 变换（名字唬人，本质很朴素）。

过滤网：让每滴水都流向答案

假设你已经知道答案区域在哪里（比如数学题的最终数值token）。定义一个函数h(i)：从token i出发，「能到达答案」的潜力。这个h值可以通过图上的势函数计算——本质上是在反向传播一个「答案引力」，从答案节点往整个图扩散。离答案越远、路径越窄，h值越小。

然后用这个h值去重加权所有管道：

$$ W'ik = Wik · h(k) / h(i) $$

这一步的妙处在于，它强制满足了局部流守恒（论文定理3.1）。每个节点流入多少、流出多少，必须平衡。数学上等价于在原始图上叠加了一个「答案偏置势场」，让水自发地朝答案方向流。为什么要守恒？因为不守恒的话，你没法定义「吞吐量」——你不知道一个节点处理了多少信息，有多少是进来的，有多少是出去又回来的。

用人话说：你往水管系统里加了一个重力场，方向指向答案。所有不往答案流的水，都被这个势场抵消了。剩下的，是一张干净、有方向、没有死胡同的推理骨干网。原图里那些循环打转的局部强连接，被h势场过滤后，要么被证伪（走不到答案），要么被合并到主干道上。

这个名字里带"Doob"，不是作者随便起的。概率论里，Doob的h-transform是一种改变随机过程转移概率的技巧，让过程更倾向于到达某个目标状态。这里做的事高度类似：改变注意力图的"转移概率"（权重），让信息流更倾向于汇聚到答案。

装水表：谁在关键路口转送信息？

现在有了干净的网络，怎么找关键token？

作者在prompt前面加超级源点，在答案区域后面加超级汇点，往源点注入单位流。网络跑一遍最大流，每个token流过的水量就是它的吞吐量 f(k)。

高吞吐量的token，就是推理过程中的关键中转枢纽。它们不是答案本身，但答案离不开它们。就像快递分拣中心——件不是它送的，但没它整批货都到不了。

---

实验：这不是锦上添花，是雪中送炭

FlowTracer的代价极低：一次额外前向传播，计算开销仅 2.2%-4.5%。换来的收益却很扎实。

主结果

模型	基线 (GRPO)	FlowTracer	提升
Qwen3-8B	39.4%	43.4%	+4.0%
Qwen3-4B	37.1%	39.4%	+2.2%
Llama-3.1-8B	7.7%	9.1%	+1.4%
Llama-3.2-3B	4.8%	5.9%	+1.1%

Qwen3-8B上4个点的绝对提升，在reasoning benchmark上不是小数。更值得注意的是8K长上下文：优势反而扩大，Qwen3-4B在AIME25上提升 +5.8%。长序列里信息传播更容易迷路，FlowTracer的「导航」作用反而更明显。这个趋势很说明问题——当序列变长，均匀分配credit的方法越发盲目，而知道"哪些token在真正传递信息"的方法优势被放大。

Countdown逻辑谜题上更是夸张：+10.6%绝对提升。这类任务需要精确的多步算术，中间一步错就全崩，正好击中FlowTracer的甜点区——关键中间步骤必须被精确识别。比如"从100开始，每次减7，目标是得到2"，你需要精确追踪中间每一步的减法结果。错一步，后面全错。FlowTracer能把credit精准投到那些承载中间计算结果的token上，而不是均匀撒给所有token。

CrossThinkQA（跨领域推理）+2.2%，说明方法不是过拟合到特定题型。它在数学、科学、常识等多个领域都有稳定增益。

消融：40%的枢纽就够了

作者试了只选top-k%的token施加credit mask：

Top-20%：覆盖不够，漏掉关键中转站，效果下降
Top-40%：最优，信息量和噪声的平衡点
Top-60%：引入太多低流量token，噪声淹没信号

中间层注意力（15-25层）提取的网络最有效。太浅层还没形成语义结构，太深层已经高度压缩。

γ_flow=1.5最优。太小，区分度不足；太大，模型过拟合到被mask的token，其他地方崩掉。

一个有趣的细节：硬mask优于连续重加权。因为flow分布极度偏斜——少量token承载绝大部分流量，连续加权反而让低流量token蹭到不该有的credit。干脆一刀切，只奖励枢纽，其余token正常训练。这个结果说明，FlowTracer发现的"关键token"确实是一小撮，不是模糊的梯度分布。

结构分隔符才是隐藏大佬

流量分析揭示了一个反直觉的现象：占据高流量节点的，不是语义内容token（名词、动词），而是结构分隔符——逗号、句号、换行、缩进。这些token像交通信号灯，控制着信息在哪个语义块之间流转。语义内容token补充增益，但骨架是结构性的。

这个发现让人重新思考：我们在训练reasoning模型时，是不是一直低估了"格式"和"结构"的价值？模型学到的推理模式，可能很大程度上是通过这些分隔符来组织思维块的。一个换行符的流量可能高于一个关键名词，因为它决定了"上一段结论是否被承接到下一段"。

这也解释了为什么prompt engineering里，让模型用""标签包裹推理过程会有效——这些标签本质上就是人为制造的高流量结构节点，强制模型在特定位置进行信息整理和分发。

---

因果验证：不是相关性，是因果性

作者做了干扰实验，验证高流量token的因果作用：

干扰对象	答案改变率	正确→错误率
高流量token	45.9%	14.9%
随机token	29.5%	4.5%
低流量token	14.9%	0.5%

数字不撒谎。干扰高流量token，答案几乎有一半会改变，而且近15%的正确答案直接变成错误。干扰低流量token？几乎无事发生。这不是事后归因，是主动干预后的因果验证。

---

局限：诚实的边界

作者没遮遮掩掩，三条限制写得很清楚：

1. 需要局部化答案区域。开放生成（开放式写作、对话）没有明确的答案token集合，h函数的定义域在哪？需要扩展。不过，对于对话场景，可以把"最后一轮回复"作为答案区域，这至少是一个可行的方向。

2. 仅靠outcome奖励不够。如果模型的中间推理是有效的，但最终答案错了，FlowTracer照样把中间token打低分。这理论上需要配合PRM（过程奖励模型）才能解决。论文也提到，FlowTracer和PRM不是竞争关系，而是互补——FlowTracer负责"找关键token"，PRM负责"判断这些token的推理是否正确"。

3. 16K+超长上下文，注意力图可能更嘈杂，流量估计的准确性会下降。但反过来看，实验已经证明在8K上下文上优势反而扩大，所以这里的问题不是"方法失效"，而是"需要更鲁棒的图估计"。

---

一个值得想的问题

FlowTracer本质上是在回答：「给定答案，哪些token是不可替代的？」

但人真实的思考过程，很多时候是反过来的——一个token之所以关键，不是因为它通向了最终答案，而是因为它排除了一片错误分支。一个否定性的选择，同样塑造了推理路径。

FlowTracer的h函数只捕捉了「正向可达」的潜力，没有捕捉「负向排除」的功劳。如果一个token在推理中的核心价值是「堵死了某条错误路」，它会在流量网络里被低估吗？

换句话说，在注意力流里，不存在的信息传输，和重要但微弱的信息传输，我们如何区分？

---

参考

论文: How Does Reasoning Flow? Tracing Attention-Induced Information Flow for Targeted RL in LLMs
作者: Zhichen Dong, Yang Li, Yuhan Sun, Weixun Wang, Yijia Luo, Zinian Peng, Taiheng Ye, Chao Yang, Wenbo Su, Yu Cheng, Bo Zheng, Junchi Yan
机构: 上海交通大学 · 阿里巴巴 · 上海人工智能实验室
会议: ICML 2026 (Accepted)
arXiv: 2606.10646

#LLM #强化学习 #推理 #ICML2026 #FlowTracer #注意力机制 #大模型训练 #小凯