75.6 比最强基线高 15.9，这个说法能查，但它盖住了两列输赢。
一、先把 15.9 的分母找出来
75.6 减 15.9 等于 59.7，正好是 Table 1 里 Gemini 3.5 Flash 驱动的 Interact-RAG 的均值。换 Qwen3.5-9B 那一系，最强基线只有 54.0，领先幅度就是 21.6 点。
分母是谁，会让同一个数差 5.7 个点。帖子没说清分母是谁，这不算错，但读者只能照抄。
二、逐列对完：4 胜 2 负
- DataBench：RECAST 83.3，最强基线是 Direct Code 的 88.0，输 4.7 点。输给的是一个不检索、直接写代码的基线。
- HotpotQA：92.0 对 IRCoT 的 94.7，输 2.7 点。
- FinQA 68.3 对 5.0（Direct Code 的 Gemini 几乎做不了），领先 63.3 点。
三、留出集那个 15.0，取的是更宽松的分母
79.3 比 strongest baseline at 64.3 高 15.0。我去查 64.3 是谁——IRCoT（Qwen3.5-9B）的均值。
但逐列看：2WikiMultiHopQA 对 77.0（Interact-RAG）高 6.0；TAT-QA 对 73.0（IRCoT）高 8.0；WikiTableQuestions 对 59.0 高 15.0。逐列最强基线均值是 69.7，按这个口径领先是9.6 点。
论文三个自算的差值（6.0/8.0/15.0）对应的正是逐列最强基线，而均值那句对的是 IRCoT。数字都没错，但 15.0 这个数依赖选谁当分母。
四、真正的卖点帖子里一个字没有：token 成本
Table 13 才是这篇论文最实用的那张表：
- Interact-RAG（Gemini）：26.9k token，成功率 59.7
- RECAST（Qwen，SFT+GRPO）：19.4k token，成功率 75.6
更狠的一条：Gemini 那栏从 26.9k 降到 5.5k，省 79.6%。全论文没有一个字提这件事。摘要卖点是准确率，工程上真正会改变部署决策的是这条。
五、消融表里两处落差值得摆出来
只用正确性作奖励，75.6 掉到 68.9，掉 6.7 点——最大的落差，说明 reward shaping 有实质作用。
去掉 mixed-outcome 过滤掉到 73.0，但【直引】论文自己写了：「Because filtering produces a smaller training pool, its higher performance demonstrates improved sample efficiency」。也就是 73.0 那条是用了更多训练数据换来的，作者主动交代了。
六、几条限定词
【直引】「Re-evaluating predictions with two alternative LLM judges and token-level F1 preserves the overall performance advantage」——75.6 是裁判模型的产物，换裁判数字会变。
即使 temperature 全是 0，论文也写明由于托管 API 的非确定性和批量 GPU 推理，输出仍会在多次运行间变化。600 题跑三次取均值，总体标准差 0.3% 到 0.8%。
CompilerLM 可替换性：换成 Gemini 3.5 Flash Lite 在域内只掉 2.4 点，留出集 79.3 持平。说明路由策略不绑死单一编译模型。
失败模式那节很细：大模型的失败是「inspect the source instead of computing an answer」——只打印记录不赋给输出变量，所以没有结果返回；小模型的失败主要是把推理写成代码注释导致代码被截断。
七、作者自己承认延迟变差
Limitations 段：训练数据要靠执行结果筛，推理时多轮调 RouterLM 会比单轮检索慢。而 Table 13 只报了 token 数，没报墙钟延迟。
下一根钉子：token 省了 27.9%，但延迟可能反而变差，而论文没测墙钟。如果把这条补上，结论可能从「更准也更省」变成「更准、更省 token、更费墙钟」——三者排序取决于机器人场景里哪一项更紧。这不是论文的漏洞，是它把结论停在了自己没测的那一格上。