04｜后训练与推理模型：从偏好目标到可验证能力

目标：理解SFT、RLHF、DPO与推理强化学习各自改变什么；能从目标函数判断一个“行为提升”是否意味着事实可靠性提升。实验：numerics.dpo_loss。

继续看相关机制：F19 · 后训练改变行为，奖励不是事实裁判O02 · 量化：省存储，也引入近似O03 · LoRA：冻结大表，学习小增量O08 · MoE：每个Token选部分计算路径

1. 预训练能力如何变成助手行为

预训练优化文本分布，SFT通过示范数据强化某些条件下的回答形式与任务策略。给模型看到高质量“请求—回答—工具结果—继续行动”轨迹，可以让它学习这些模式；但格式学会不等于任何一次调用都有效。Schema验证、权限和完成核验仍在执行层。

SFT样本的关键并非只有最终文本，还包括任务分布、正确的工具调用与恢复过程、是否允许模型看到验证反馈。把失败轨迹全部删除，可能让模型只学到顺利路径；无选择地加入失败轨迹，又可能复制错误。数据设计应明示哪些动作值得模仿、哪些内容只是环境反馈。

训练时若只优化最终回答，长轨迹中间某个危险调用可能没有被直接约束。反过来，如果机械奖励每个步骤的形式，会诱导满足格式却没有推进任务。这里需要区分目标层级与可观测反馈，而不是简单追求更长推理。[N61]

2. RLHF中的奖励不是事实真值

典型偏好流程先对回答进行比较，训练奖励模型，再优化策略使奖励变高，同时约束偏离参考策略的程度。偏好可能综合帮助性、风格、遵循指令、安全等维度，不能假设一个标量完美表示全部业务目标。

模型可能利用奖励模型的缺陷，例如偏爱冗长、特定语气或表面完整性。工程上看见“答案更自信”不应推断“事实更正确”。需要外部可核验结果，例如编译通过、数据库最终状态、证据支持率，而不是仅凭另一个模型的满意度。

强化学习里的策略更新也不是每次用户聊天都即时更新模型参数。产品可能有独立的数据与训练流程；用户在当前会话纠正答案，直接改变的是上下文，是否进入后续训练是另外的问题。

3. DPO的目标函数为何出现参考模型

从一个带KL约束的理想化优化问题出发：

maxπ  E(y~π)[r(x,y)] − β KL(π(.|x) || πref(.|x))
最优分布：π*(y|x) ∝ πref(y|x) exp(r(x,y)/β)
因此 r(x,y) = β log[π*(y|x)/πref(y|x)] + β log Z(x)

如果成对偏好概率采用Bradley–Terry形式σ(rw−rl)，同一提示下的log Z(x)在相减时消失，得到DPO损失：

z = β[(logπ(yw|x) − logπref(yw|x))
     −(logπ(yl|x) − logπref(yl|x))]
L = −log σ(z)
∂L/∂logπ(yw|x) = −βσ(−z)

这解释了DPO为什么能够直接从偏好对优化，而不是只背诵“DPO比RLHF简单”。参考模型提供相对变化基准，β控制目标中的尺度。这里推导依赖特定奖励正则化与偏好模型假设，并非说明现实人类偏好严格遵循这个概率模型。[N15]

序列log概率通常由被计入的Token对数概率求和，长度和mask因此非常重要。把序列均值与求和随意互换，会改变偏好学习目标。numerics.dpo_loss检查的是单个偏好对的稳定损失和解析梯度；它不是一个完整DPO训练器，也没有证明偏好数据能提高你的编码任务成功率。

4. 可验证奖励与推理强化学习

当答案可以通过数学结果、单元测试或规则验证，训练可以获得比纯风格偏好更明确的反馈。但验证器的覆盖决定奖励质量：通过一个弱测试集不等于实现正确。若任务允许修改测试，模型还可能通过破坏验证过程获得奖励。

DeepSeek-R1相关报告提供了用强化学习形成推理行为的公开研究案例。其方法、冷启动数据、训练阶段和评测结果都有具体实验条件；不能把“RL产生了推理模式”扩大成“任何模型只靠奖励就会学会可靠的长期Agent行为”。[N16]

组相对优势的一种直觉是对同一题采样多条回答，以组内奖励均值/尺度为基准比较，减少对独立价值估计的依赖。若组内所有回答奖励相同，相对信号可能很弱；若奖励只看最终结果，步骤是否真实有效仍不明确。部署时的“多想一会”则是推理计算分配，与训练时优化策略是两件事。

5. 过程监督、结果监督与搜索的边界

结果监督便宜而直接，但很难指出长推理中第一个错误；过程监督可以更细，却需要可靠步骤标签，也可能奖励迎合评分格式的步骤。多路径采样、自洽投票、树搜索都在推理时花额外计算探索候选，而不是天然增加基础模型知识。

若多个候选共享同一错误前提，投票只会放大错误。若验证器只偏好语言流畅，搜索可能更稳定地找到错误但悦目的答案。因此搜索的收益需要两个条件共同支撑：候选有有效多样性，评估器能够识别更优结果。两者都应在任务层做消融。

对于代码任务，先让模型运行一个相关测试，往往比无证据地生成三份长分析更可核验。这不是任何情况下测试优于推理的定律，而是优先购买能排除错误假设的信息。在高风险跨模块改动中，更深入分析仍可能非常有价值。

6. 从模型选择落到工程决策

区分三种失败：没有相关知识、无法在给定条件下推理、无法可靠执行。第一类优先检索；第二类可能需要更强模型、不同分解或更好验证；第三类优先修复工具与状态管理。把它们全部交给微调，会浪费成本并掩盖执行系统缺陷。

比较不同推理强度时，保持任务、可用工具和判分一致，记录总成本、总时间、成功率及失败类型。不要只比较最终输出字数。内部推理内容不一定对客户端开放，也不应要求模型给出所谓完整内部轨迹作为正确性证明；可观察的证据链和可重复的结果更重要。

7. 验收题

一组偏好数据总选更长答案，DPO训练后回答更完整，但功能通过率没变化。是否成功？相对于“长答案偏好”目标可能成功，相对于工程质量目标没有证据。应调整数据、评价维度或放弃该改动，而不是给结果补一个“智能提升”标签。

一个推理模型偶尔在简单任务上浪费很多轮。是否一定要新增复杂度评分器？不一定。先看提示、停止条件、工具反馈与默认推理配置；只有稳定的任务分层收益能够覆盖路由成本时，才引入模型或强度路由。模型能力是系统设计的条件，不应成为无限增加框架层的理由。