10 月 7 号 17:51 UTC 挂上 arXiv，编号 2610.10507，35 页、2 幅图、13 张表。摘要里最显眼的数字是 75.6%——六个异构基准族上的平均成功率，比最强的大模型基线高 15.9 个点。
我看到这个数第一反应是往下翻，找它怎么聚合的。职业病，改不掉。这次拆的是这个 75.6% 和端到端指标背后的环节归因，不是复现它的实验。正文 13 张表我没逐张啃完，下面有些话是从摘要层那几个数反推的，不是论文结论，我会标出来。
这个提法我认
“不少任务需要的证据不在任何单一来源里，得从多个条目里筛、拼、算”——这句我在自己的测试记录里撞见过太多次。
前阵子拿一组跨表问题去喂几条 RAG 管线，卡住的地方从来不是没召回到，是召回到了三张表，但没人把它 join 起来。这两类失败的修法完全不一样：前者改 chunking、改 query 改写那一套；后者你怎么改检索都是在原地打转，缺的是一个能写出 SELECT ... GROUP BY 的执行层。固定相似度检索的天花板在这儿，智能体式那套改写查询、调工具的做法也没跳出这个框——它还是以检索为中心，只是检索得更勤快。
所以“证据可以被推导，而不只是被检索”这个方向是对的，不是包装出来的新词。三角色结构也对得上：RouterLM 迭代地挑操作、表述操作，CompilerLM 把操作翻成可执行代码，AnswerLM 等 router 说“够了”再给答案。全称 Routing Evidence through Computation, Access, and Synthesized Tools，写得很直白。
但 75.6% 是个裸数字
六个异构基准取算术平均，前提是这六个基准彼此可比。可它们连“一道题”的定义都未必一样——有的是单跳问答，有的是多跳，有的要调工具。题量怎么配的也不知道。要是有哪个基准题量占了一半以上，这个 75.6% 基本就是在描述那一个基准，剩下五个陪跑。
方差我没看到。摘要只给了一个点估计，没给区间。正文 13 张表里应该有，但我没读到，所以现在能说的是：口径没交代清楚，能看，不能信。它不构成一次测量，只构成一个传闻——听起来难听，但这就是我对所有没给分布的单点数字的默认归类。
35 页配 13 张表，平均不到 3 页一张，实证密度是按论文标准来的；只有 2 幅图，说明作者没打算用图讲故事。是个好迹象，但好迹象不等于好数据。
真正让我把页面往回滚的是那 5.0%
训练过的 Qwen3.5-9B RouterLM，比没经过训练的 Gemini 3.5 Flash RouterLM 高 5.0%。
这条的信息量比 15.9 大得多。
Router 这个位置不需要世界知识，也不需要长链推理，它要的是“在当前这个证据状态下，下一步该干什么”这么一个窄决策——动作空间是离散的、基本的和自定义的操作集合，视野短，反馈还稀。这种活儿如果真需要大模型的推理能力，9B 不可能追得上 Flash。追上了，还超了 5 个点，说明这层是可学的，而且学得很便宜。
另一个我欣赏的地方是克制：CompilerLM 和 AnswerLM 都冻结，整套系统只训一个 RouterLM，SFT 起手再用 GRPO 磨。训练成本压在最小的那个组件上，其余两个直接吃现成的通用能力。这跟“把可训练参数量做到最小”是一个思路，比那种全链路微调、最后说不清哪一步起作用的做法干净。
GRPO 用在这儿也合理——组内相对比较，不需要单独的价值网络，采样一组轨迹摊薄奖励的稀疏性。但奖励从哪来是关键。
我没看到的那部分：失败归因
三个环节串起来，端到端成功率大致是三个环节成功率的乘积（假设链路独立，实际不独立，先这么估）。
Compiler 一次编译正确率 85%、answer 抽取 95%，那 router 的决策链正确率得做到 93.6% 以上，端到端才够 75.6%。反过来更清楚：router 只有 80%、compiler 90%，那 answer 环节得做到 105%——不可能。
这个反向推演的意思是，75.6% 意味着三个环节都得站在 90% 上下，任何一环掉到 85% 以下，整条链就上不去。上面 85/95 的拆法是我拿 75.6 除出来的，纯算术，不是论文里的分组数据，别当结论引用。但它指向一个很实在的问题：最弱的那一环决定天花板。
而我认为最弱的一环是 compiler。冻结的通用代码模型，在异构数据源上写出来的代码有多鲁棒，是这套系统最脆的地方。真实场景里的数据源不是干净的 SQL 表——有 JSON 套 JSON 的，有半结构化日志，有字段名带空格的。冻结的 compiler 遇上这些，出错方式会很难看，而且这种错不会进“检索失败”的统计，它会静默地算出一个错答案，被 AnswerLM 拿去用。端到端指标只记它错了，不记它错在哪。
再往下一层，是信用分配。RouterLM 用 GRPO 训，如果奖励信号来自端到端成功与否，那 router 会被惩罚那些“决策选对了、但 compiler 编错了”的轨迹。它在为下游的错背锅。这会把它往保守的方向推——宁可多走一步稳的检索，也不去试那个需要复杂计算的操作。这个副作用在指标上看不出来，因为它被算进了“决策不准”那一栏。
写到这儿我发现自己在打架
前面说了两句互相拆台的话。一句是“瓶颈在 compiler”；另一句是“换个训练过的 9B router 就涨 5 个点，说明 router 这层还有很大压缩空间”。
这两句不能同时成立。如果 router 已经磨到 93.6%，再优化它的边际收益该很小，换个 router 怎么涨 5 个点？
可能我对 compiler 那个 85% 的假设本身就是拍的。也可能那 5 个点里有相当一部分不是“决策更准”，而是“表述更规范”——router 输出的操作描述变了，compiler 的编译通过率跟着变了。这两条路径我分不开，论文的聚合口径也分不开。这是我这次读得最不清楚的地方，先记下来。
留出集上那 0.9 个点
三个留出基准上相对最强基线平均提升 15.0%，全基准是 15.9%。差了 0.9 个百分点。
⚠️ 这个 0.9 我觉得是整篇里最健康的信号。留出集上没垮，说明训出来的 router 不是在背六个基准的题型，那套“选操作、表述操作”的能力确实迁移出去了。要是留出集上掉到 5 个点，这篇就是过拟合演示。
但也就是个方向。三个留出基准、每个多少题，我不知道；样本量不够的时候，0.9 个百分点完全可能是噪声。作者说这是零样本泛化能力，从架构设计上我相信，从数字上我没法给置信——样本量没披露之前，15.0% 和 15.9% 这两个数的差我不敢往任何方向解读。
还有一点提醒：v1 挂上去到今天不到两周，还没有 revision，提交历史里只有第一作者一条。现在引用的所有数字都是初版，后面改了口径，手上的引用就得跟着改。
如果我来复测
我不会去跑它那六个基准——那套题集不是我常用的任务类型，跑出来的数对我没用。我要拆的是环节：
| 环节 | 测什么 | 怎么测 |
|---|---|---|
| Router 决策 | 给定证据状态，最优下一步被选中的比例 | 人工标 200 条轨迹的最优动作，只看 top-1 |
| Compiler 编译 | 操作描述 → 可执行代码的一次通过率 | 固定 50 个操作描述，每个数据源跑 10 次 |
| Answer 抽取 | 执行结果 → 最终答案的正确率 | 只喂正确执行结果，屏蔽上游错误 |
| 链路耦合 | 上游表述变化对下游的污染 | 同一个决策三种表述，看编译通过率的方差 |
第三行那个“只喂正确结果”是我最想做的。把 Answer 环节单独拎出来，看它是不是一个纯粹的“读结果”步骤——如果它自己就在掉分，那 75.6% 里有一块跟“证据构建”完全无关，纯粹是答案抽取的老问题。
第四行是为了回答前面那个打架的问题。同一个决策、三种不同表述，如果编译通过率的方差够大，那 5 个点里就有相当一部分是“router 学会了说什么话 downstream 才听得懂”，不是“想得更对”。这两种能力在训练里混在一起，只能靠这种方式硬拆。
置信标签
**