推理能力强弱取决于答案验证成本:数学可脚本自动评测所以 RL 信号充足,代码有编译器检验,文本策略建议几乎无法自动评判。
标准解释是数学具有逻辑性,而文本不具有。并非如此。真正的原因是一个数学答案可以在毫秒内通过脚本检验,而一段策略建议却无法被检验,所有后续的不对称性都源于此。
一行论点
推理能力是通过强化学习针对自动评分器训练出来的。一个领域获得良好推理能力的程度与其答案被评分的廉价程度成正比——因为这决定了存在多少训练信号、能够生成多少过程监督,以及测试时技术(如 best-of-N)是否有可选择的内容。
难度几乎与此无关。竞赛数学比写一份连贯的产品简报要难得多,但模型在前者上的改进远远超过后者。可验证性,而非难度,才是那个变量。
一切条件都具备。最终答案是一个数字或表达式,因此相等性检查微不足道。题目配有大量参考解答。中间步骤可以单独检验,这正是步级数据集得以存在的原因——Let's Verify Step by Step 背后的 PRM800K 数据集之所以可能,是因为人类(或后来的 rollout 估计)可以判断第七行是否从第六行推导而来。
在推理时,同样的特性持续发挥作用。由于数值答案可以比较相等性,多数投票得以有效运作:错误答案散布在数轴上,正确答案则堆积在一起。正是这一个特性使得自洽性(self-consistency)在数学中几乎免费,在文本中却无法实现。
这里有一个已发表的警告值得重视。Mirzadeh 和 Apple 的同事在 2024 年提出了 GSM-Symbolic,从符号模板生成 GSM8K 问题的变体,并报告模型在同一问题的不同变体上准确率存在显著差异——当插入一个看起来相关但实际什么也没改变的条款时(即他们的 GSM-NoOp 条件),准确率下降幅度很大。数学高分是真实的,但它们也比基准数字所显示的更容易因表面变化而变脆。
代码拥有存在的第二好的验证器:它能运行。编译器免费拒绝一整类错误,测试套件对行为给出二元信号。这就是为什么编程表现出第二大的推理收益,也是为什么重复采样在那里效果如此之好——如果能自动识别那 10%,你可以在 90% 的时间里犯错。
噪声来自于测试是部分规格。测试通过不等于正确:代码可以通过测试但同时不可维护、不安全、在需要线性时是二次的,或者仅在有人想到要写的用例上正确。针对测试结果优化的模型学会满足测试,这包括对测试使用的输入进行特殊处理。这是过度优化模式的一个实例,而非独立现象。
实际上:推理模型最清晰地体现其价值的地方在于:有复现步骤的调试、有交互约束的多文件更改、以及任何有可执行检查的任务。它们在最不值得的地方体现价值:写样板代码,首稿本来就已经是对的。
开放式文本没有廉价的评分器,而且对许多任务来说也没有唯一正确的答案。这种缺失在三个方面造成影响。
训练信号更少。 强化学习针对基于规则的评分器的做法不可用,因此文本领域的推理改进主要作为从其他领域的迁移的副作用。
推理时无法选择。 Best-of-N 需要一个选择器;多数投票需要可比较的答案。"写一份给董事会的备忘录"两者都不具备。
评估本身不可靠。 对文本的模型评分评估存在已知偏差——偏向长度、偏向复杂结构、偏向评分者自身的风格——而这正是推理模型推动输出的方向。推理模型在 LLM 评判的写作评估中获得更高分数,而读者实际上更喜欢更短的回答,这是完全可能的。
在文本领域推理确实有帮助的地方,往往是那些偷偷夹带了验证器的子任务:对照枚举规则检查文档、协调两条相互矛盾的信息源、或者回答一个答案蕴含在所提供的文本中的问题。这些更像是穿着散文外衣的逻辑问题,它们的行为也相应地如此。
Agentic 工作处于代码和文本之间,且越来越多地在其中部署推理模型。它有一个部分验证器——工具要么返回了错误,要么没有;文件要么存在,要么不存在——这提供了纯文本任务所缺乏的步级反馈。它也有一个真正的规划组件,具有交互约束和错误分支的真实代价,这正是推理擅长处理的特征。
它缺乏的是端到端的评分器。"Agent 做了用户想要的事吗"通常是人类的判断,所以该技术在步级层面效果好,在任务层面难以评估。这种不匹配解释了一种常见体验:轨迹看起来每步都令人印象深刻地胜任,但附加的结果没有人能总体上说出什么。
检验标准不是你数据的样子。而是:这个任务你能否在一小时内写出一个自动评分器,一个返回布尔值且你信任的评分器?
如果可以,你处于数学和代码的 regime,无论你的领域叫什么名称,整个工具箱——推理投入、best-of-N、验证器重排、升级路由——都对你可用。如果不能,你处于文本 regime,预期收益更小,你的首要投资应该是构建一个你信任的评估,而不是购买更昂贵的模型。没有评分器你无法判断昂贵的模型是否有帮助,这意味着你无法证明其合理性,也无法注意到它何时停止帮助。