AI 工程基础体系 · 第 78/100 篇。内容覆盖机器学习、深度学习与生成式 AI;模型、数据、评测、权限和成本会作为同一生产系统处理。
偏好对齐:RLHF、DPO、奖励模型、数据偏差与上线评测
偏好对齐(preference alignment)是指:在模型已经具备语言建模能力的基础上,使它生成的结果更符合某种可观测的偏好、规范或任务目标。这里的“偏好”不等于“事实正确”,也不等于“所有用户都喜欢”。它通常来自人工比较、规则判定、专家评分、用户行为或组合信号,因此本质上是一个带有测量误差和分布限制的学习问题。
RLHF、DPO 和奖励模型解决的是同一条链路中的不同环节:
- 奖励模型(Reward Model,RM):把“人更喜欢哪个回答”学习成一个可计算的分数。
- RLHF(Reinforcement Learning from Human Feedback):用人类反馈训练奖励模型,再通过强化学习优化语言模型,使其获得更高奖励,同时通常限制它不要偏离参考模型太远。
- DPO(Direct Preference Optimization):直接使用偏好数据优化策略模型,把奖励函数隐含在策略与参考模型的概率比中,省去显式奖励模型和在线强化学习过程。
- 数据偏差:偏好数据、采样流程、标注者和任务分布都会改变学习目标,使模型学到“标注系统偏好的表面模式”,而不是预期能力。
- 上线评测:验证对齐后的模型在真实流量、真实权限、真实成本和真实失败路径下是否可靠,而不是只看离线偏好准确率。
这些方法都建立在 Transformer 语言模型之上。Transformer 的自注意力机制负责根据上下文计算下一个 token 的条件分布;对齐训练通常不改变“模型按 token 自回归生成”的基本形式,而是改变哪些完整回答会获得更高训练目标。
一、先区分预训练、监督微调与偏好对齐
给定输入 ,语言模型生成回答 的概率为:
其中:
- 是参数为 的策略模型,也就是待训练的语言模型;
- 是第 个 token;
- 是前面已经生成的 token。
1. 预训练学习“像数据”
预训练通常最小化下一个 token 的交叉熵:
它主要回答:
训练语料中,给定上下文后,什么 token 更可能出现?
因此,一个预训练模型可能会:
- 续写格式正确但不适合对话;
- 复述训练语料中的偏见;
- 在多个合理答案之间随机选择;
- 对有害请求给出能力很强但不应提供的回答。
预训练目标本身没有“应该如何帮助用户”的显式概念。
2. 监督微调学习“按照示例回答”
监督微调(SFT)使用输入—理想回答对:
仍然优化回答 token 的似然,但数据中的 已经体现了格式、语气、任务流程和部分安全要求。SFT 通常是偏好对齐前的重要阶段,因为偏好优化需要模型具备足够高的有效回答概率;如果模型连任务格式都不会,偏好信号往往只会推动它学习表面风格。
3. 偏好对齐学习“两个答案哪个更好”
偏好数据通常写成:
其中 是被偏好的回答, 是未被偏好的回答。这里的“更好”必须绑定评价标准,例如:
- 更准确;
- 更安全;
- 更完整;
- 更简洁;
- 更符合企业语气;
- 更适合某类用户。
如果标注说明只写“选择更好的回答”,不同标注者很可能使用不同标准,训练目标就会变成多个隐含目标的混合。
二、奖励模型:把比较判断变成可优化的分数
1. 为什么需要奖励模型
语言模型生成的是离散 token 序列。人工可以比较两个完整回答,但不能直接对每一步 token 提供稳定、低成本的梯度。奖励模型的作用是学习一个函数:
它接收输入 和回答 ,输出一个标量奖励。这个分数不是客观真理,而是对标注偏好的近似。
常见做法是使用语言模型的隐藏表示,在最后增加一个标量头:
其中 可以是最后一个位置的隐藏状态, 是奖励头参数。实现上也可以使用池化表示、专门的分类头或其他结构,但核心都是把完整序列映射为标量。
2. Bradley–Terry 偏好模型
一个常见假设是:回答的奖励差越大,被选择的概率越高。用 Bradley–Terry 或 logistic 模型表示:
其中:
于是奖励模型的损失为:
推导这个损失的步骤如下:
- 假设每个回答有一个潜在效用 。
- 假设标注者选择 的概率由两个效用之差决定。
- 将选择概率写成 sigmoid。
- 对真实选择结果取负对数似然。
- 对所有偏好样本求平均并优化 。
如果 ,,则:
但这只意味着模型认为前者更可能被偏好,不代表它“有 88.1% 的事实正确率”。
3. 奖励的平移不影响偏好,但尺度会影响优化
如果对每个输入都同时加上常数 :
那么:
偏好概率不变。因此,奖励模型的绝对零点通常没有意义。
但是,如果把奖励乘以常数 ,则:
会发生变化。奖励尺度会影响强化学习阶段的梯度、KL 惩罚相对强度和训练稳定性。因此,奖励归一化、裁剪和校准不是纯粹的展示问题。
4. 奖励模型并不等于评价器
奖励模型适合在训练时提供密集、可微的排序信号,但它可能存在以下问题:
- 对长度有偏好;
- 偏爱礼貌措辞而不是事实;
- 把“看起来像推理”误认为真实推理;
- 对训练分布外的问题评分失真;
- 被策略模型针对其弱点优化。
这导致一个关键区别:
奖励模型回答的是“像不像标注数据中的高分回答”,而不是“是否满足所有真实世界约束”。
三、RLHF:先学习奖励,再用强化学习优化策略
严格来说,RLHF 是一个较宽泛的术语,通常指利用人类反馈构造奖励,并用强化学习优化模型的流程。经典对话式 RLHF 常包含:
- 预训练模型;
- 监督微调得到初始策略;
- 收集回答比较数据;
- 训练奖励模型;
- 用 PPO 等强化学习算法优化策略;
- 持续进行离线和在线评测。
其中 PPO 是常见实现,但“使用人类反馈”不必然意味着只能使用 PPO。
1. RLHF 中的策略、动作和状态
把生成过程写成强化学习形式:
- 状态 :用户输入和当前已生成前缀;
- 动作 :选择下一个 token;
- 策略 :语言模型的下一个 token 分布;
- 轨迹:完整回答 ;
- 终止奖励:奖励模型对完整回答的评分。
如果直接最大化:
模型可能学会生成奖励模型喜欢但用户不需要的输出。因此通常加入相对于参考策略 的 KL 约束:
这里:
- 通常是 SFT 模型的冻结副本;
- 控制偏离参考模型的代价;
- 较大时模型更保守,较小时更容易追逐奖励模型漏洞。
在 token 级实现中,常见近似是计算生成序列的对数概率差:
但序列级 KL、token 级 KL、是否包含 EOS、如何处理 padding,都会影响具体训练行为,不能把所有实现简单视为完全等价。
2. KL 正则化目标的最优策略
对固定输入 ,考虑所有可能回答 ,目标为:
约束是:
构造拉格朗日函数:
对 求导并令其为零:
整理得到:
因此:
其中 是归一化常数。
这个结果说明了 RLHF 中 KL 正则的直觉:
- 高奖励回答的概率增加;
- 参考模型原本概率高的回答更容易被保留;
- 控制“追逐奖励”和“保持原能力”的折中;
- 如果奖励模型错误,策略会以指数形式放大这个错误。
3. PPO 解决的是什么问题
PPO 不直接求上述全空间最优解,而是通过采样轨迹、估计优势函数并限制策略更新幅度来近似优化。其典型裁剪目标包含:
其中:
是动作优势,表示当前动作相对于基线的好坏; 限制新旧策略概率比的变化范围。
PPO 的裁剪并不等于 KL 约束的数学替代。实际 RLHF 系统可能同时使用 PPO clipping、参考模型 KL、价值函数损失、熵奖励和奖励归一化。它们分别控制更新幅度、参考偏离、价值估计和探索程度。
4. RLHF 的奖励黑客
假设奖励模型偏爱更长、更有条理的答案,策略可能生成大量标题、免责声明和重复总结。奖励提高了,但事实正确率下降。这叫奖励黑客(reward hacking):模型优化了奖励函数的可测代理,而不是原始目标。
一个更隐蔽的例子是:
- 真实目标:回答客户问题并引用正确条款;
- 奖励代理:人工更喜欢“谨慎、详细、有条理”的文字;
- 优化结果:回答变长、语气更稳妥,但引用条款仍然错误;
- 离线结果:偏好胜率上升;
- 线上结果:用户需要重复提问,客服转人工率上升。
因此,奖励模型的改进必须和独立的事实、任务成功率、风险指标一起观察。
四、DPO:从 KL 正则化最优解直接得到偏好目标
DPO 的核心不是“完全不使用奖励”,而是把奖励函数通过参考策略和当前策略的概率比隐式表示出来,从而直接用偏好对训练策略。
1. 从最优策略反推出奖励
由前面的最优策略公式:
两边取对数:
因此:
对同一个输入 的两个回答相减,归一化项抵消:
将这个隐式奖励差代入 Bradley–Terry 模型,就得到 DPO 的损失:
DPO 的每个变量含义是:
- :正在训练的策略;
- :冻结参考模型;
- :偏好回答;
- :非偏好回答;
- :控制隐式奖励差和参考策略约束的尺度。
2. DPO 的一次数值计算
设某个输入的偏好对为 ,四个对数概率如下:
先计算两个相对参考模型的 log-ratio:
偏好差为:
若 ,则 sigmoid 输入为:
偏好概率为:
损失为:
这说明当前策略虽然相对于参考模型提高了 的相对概率、降低了 的相对概率,但幅度很小,所以模型仍然只有略高于 50% 的信心。
如果训练后 变成 ,在同样 下:
模型会更偏向 ,但还没有达到极高置信度。若直接把 改成 ,则 sigmoid 输入变成 ,偏好概率约为 。这表明 不只是一个无关紧要的学习率参数,它直接影响偏好目标的温度。
3. DPO 为什么不需要显式奖励模型
DPO 每个样本只需要:
- 输入 ;
- 被偏好的回答 ;
- 未被偏好的回答 ;
- 参考模型对两个回答的对数概率;
- 当前模型对两个回答的对数概率。
语言模型可以通过 teacher forcing 计算完整回答的 token 对数概率:
因此 DPO 不需要:
- 单独训练一个奖励模型;
- 通过策略采样在线生成轨迹;
- 训练价值模型;
- 使用 PPO 估计优势。
但这并不意味着 DPO 没有假设。它仍然依赖:
- 偏好数据足以代表目标;
- Bradley–Terry 一类的偏好模型近似合理;
- 参考模型质量合适;
- 当前策略和参考策略的 log-probability 可稳定比较;
- 回答长度、截断和 EOS 处理没有引入不可控偏差。
4. DPO 的长度偏差
回答的序列对数概率是 token 对数概率之和。因为每个概率通常小于 1,所以回答越长,未归一化的 log-probability 越负:
如果 比 长很多,直接比较总和可能把长度差混入偏好差。DPO 中使用的是“当前模型相对于参考模型”的差:
这会抵消一部分共同的长度效应,但不保证完全消除,因为当前模型和参考模型对不同位置的概率变化并不相同。
因此,训练和评测时必须明确:
- 是否使用总 log-probability;
- 是否按有效 token 数平均;
- prompt token 是否纳入损失;
- padding 和 EOS 如何处理;
- 截断是否截掉了回答结尾。
随意改变这些实现细节,可能改变模型偏好的内容,而不只是改变训练速度。
5. 一个可运行的 DPO 损失示例
下面的代码不加载完整语言模型,而是使用预先计算好的序列 log-probability 演示 DPO 的反向传播。它可以直接运行,依赖 PyTorch:
import torch
torch.manual_seed(0)
# 当前策略对每个回答的序列 log-probability。
# 这些张量必须来自当前模型,并且需要梯度。
policy_chosen = torch.tensor([-2.0], requires_grad=True)
policy_rejected = torch.tensor([-1.0], requires_grad=True)
# 参考模型被冻结,因此不需要梯度。
ref_chosen = torch.tensor([-2.5])
ref_rejected = torch.tensor([-0.8])
beta = 0.1
chosen_log_ratio = policy_chosen - ref_chosen
rejected_log_ratio = policy_rejected - ref_rejected
logit = beta * (chosen_log_ratio - rejected_log_ratio)
loss = -torch.nn.functional.logsigmoid(logit).mean()
loss.backward()
print("chosen_log_ratio =", chosen_log_ratio.item())
print("rejected_log_ratio =", rejected_log_ratio.item())
print("logit =", logit.item())
print("loss =", loss.item())
print("grad(policy_chosen) =", policy_chosen.grad.item())
print("grad(policy_rejected) =", policy_rejected.grad.item())
预期会看到:
chosen_log_ratio = 0.5rejected_log_ratio = -0.2logit约为0.07loss约为0.659- 被偏好回答的 log-probability 梯度方向会促使其增加;
- 未被偏好回答的 log-probability 梯度方向会促使其降低。
实际训练 LLM 时,policy_chosen 等值不是手工输入,而是对模型输出 logits 做 log_softmax 后,按回答 token 位置收集并求和。常见错误包括:
- 把 prompt 的 token 也算入回答损失;
- chosen 和 rejected 的 mask 错位;
- 参考模型没有切换到
eval(); - 参考模型仍参与梯度计算,造成显存浪费;
- 不同样本的截断规则不一致;
- 把 padding token 的 log-probability 加入序列总和。
五、RLHF 与 DPO 的关系、差异和边界
可以把两者放在同一个正则化目标下理解:
区别在于优化路径:
| 方面 | RLHF | DPO |
|---|---|---|
| 偏好数据 | 通常需要 | 需要 |
| 显式奖励模型 | 通常需要 | 不需要 |
| 在线策略采样 | 常见 | 通常不需要 |
| 强化学习算法 | PPO 等 | 直接分类式目标 |
| 价值模型 | 常见 | 不需要 |
| 训练复杂度 | 较高 | 通常较低 |
| 对奖励建模的显式控制 | 强 | 弱,奖励隐含在策略比中 |
| 适合在线反馈闭环 | 较自然 | 需要重新构造偏好数据 |
“DPO 更简单”不等于“DPO 总是更好”。如果系统有非常复杂的可执行奖励、工具调用轨迹、长时序信用分配或在线环境反馈,显式奖励和强化学习仍可能有价值。相反,如果目标主要是让回答 相对 更受偏好,DPO 可以减少奖励模型和 PPO 带来的工程复杂度。
一个重要边界是:DPO 不能凭空创造偏好数据中的能力。若数据只比较语气,模型主要学习语气;若数据没有覆盖工具失败、事实核验和权限边界,DPO 不会自动学会这些行为。
六、数据偏差:模型优化的是采样到的偏好,而不是口头目标
数据偏差不是一个单独的“数据质量问题”,而是从目标定义到上线流量的整条因果链问题。
1. 选择偏差:谁的问题进入了数据集
设真实线上输入分布为 ,训练偏好数据分布为 。如果训练集主要来自:
- 内部员工;
- 高频用户;
- 英文用户;
- 简单问答;
- 已被安全过滤的请求;
那么模型优化的是 下的期望,而不是 下的期望:
即使训练集中的偏好准确率很高,线上长尾输入仍可能失败。
2. 标注者偏差:不同人使用了不同效用函数
理想情况下,标注者根据统一标准比较回答。现实中每个标注者可能有不同的隐含效用:
其中 表示标注者, 是事实性、安全性、简洁性等特征, 是个人权重。
例如:
- 标注者 A 更重视简洁;
- 标注者 B 更重视解释完整;
- 标注者 C 对拒答更宽松;
- 专家更容易识别技术错误;
- 普通用户更容易受流畅语气影响。
若不记录标注者群体和任务条件,最终奖励模型可能学习到“平均标注者的折中”,但这个平均值未必适合任何真实用户。
3. 标签偏差:偏好不等于正确
“回答 A 被选中”可能有多种原因:
- A 更正确;
- A 更完整;
- A 更礼貌;
- A 更短;
- A 更像参考答案;
- A 只是格式更漂亮。
如果标签没有区分这些原因,模型就会把相关但非目标的特征当作代理信号。这是偏好学习中最常见的混淆。
一个典型反例:
- A:“这个结论需要根据数据进一步确认。”
- B:给出一个明确但错误的结论。
- 标注者偏好 A 的谨慎语气。
- 模型学到“多使用不确定性表达”。
- 在线上,模型对本来可以准确回答的问题也持续含糊其辞。
这不是“安全性提升”,而是把校准问题错误地简化成语言风格。
4. 位置偏差和展示偏差
如果比较界面总是把某一回答放在左边,标注者可能形成位置偏好。若一个回答先生成、另一个回答后生成,标注者也可能偏好后看到的内容。还可能存在:
- 更长回答更容易显得认真;
- 格式更规整的回答更容易被选中;
- 标注者只看开头;
- 标注时间过短;
- 无法核验事实却必须做选择。
因此,偏好数据应至少保留:
- prompt;
- chosen/rejected;
- 标注者或标注者群体;
- 标注标准版本;
- 是否允许“不确定/平局”;
- 生成模型和采样参数;
- 时间、语言和任务类别;
- 是否经过专家复核。
5. 反馈回流偏差
线上用户的点赞、点踩和停留时间不是纯粹的质量标签。例如:
- 用户点踩可能是因为答案拒绝了请求,而不是拒答错误;
- 用户没有继续追问,可能是满意,也可能是放弃;
- 长回答可能增加停留时间,但降低任务效率;
- 高风险用户更可能主动反馈,低风险用户可能沉默。
将这些行为直接当作奖励,会产生选择偏差和反事实缺失:系统只观察到模型已经给出的答案,看不到同一个用户在另一个答案下会如何反应。
6. 数据去重和泄漏
如果评测问题、偏好训练问题和预训练语料高度重复,离线结果可能虚高。需要检查:
- prompt 的近重复;
- 答案模板的重复;
- 外部公开基准的污染;
- 训练前后模型生成内容的重合;
- 同一用户会话跨训练集和测试集泄漏。
“测试集没有完全相同字符串”并不代表没有泄漏。语义近重复和固定模板同样会让指标失去解释力。
七、从偏差到诊断:不要只看一个总分
设总体偏好胜率为:
这个数字会隐藏分布差异。更有用的做法是按任务、风险、语言、长度、用户类型和工具状态分层:
其中 可以是“法律问题”“中文长上下文”“拒答边界”“工具调用失败”等分组。
还应报告不确定性。对于胜负样本,可以用二项分布近似计算标准误:
如果两个模型的胜率差小于统计波动,不能直接宣称一个模型更好。对于同一 prompt 上的配对比较,应优先使用配对置信区间或 bootstrap,而不是把每个回答当成完全独立样本。
八、上线评测:从离线偏好到真实系统行为
上线评测不是单纯把测试集换成线上流量。它要评估模型作为生产系统一部分时的行为:
一个回答即使文本质量很高,只要调用了不该调用的工具、泄露了无权访问的数据,仍然是系统失败。
典型的数据流如下:
flowchart LR
A[用户请求] --> B[身份与权限检查]
B -->|允许| C[上下文构造]
B -->|拒绝或降级| R[安全响应]
C --> D[模型生成]
D --> E[输出安全与格式校验]
E --> F[工具执行或返回用户]
F --> G[日志与指标]
G --> H[抽样复核和偏好数据]
H --> I[离线训练与评测]
I --> J[候选模型]
J --> K[离线门禁]
K --> L[灰度/Canary]
L --> M[全量发布或回滚]
关键路径是:
- 请求先经过身份、租户和权限判断;
- 模型只能看到被授权的上下文;
- 生成结果经过安全、格式和工具参数校验;
- 线上记录可审计指标,但不应默认记录未经脱敏的敏感内容;
- 新数据进入训练前需要版本化、筛选和抽样复核;
- 候选模型先过离线门禁,再进入小流量灰度;
- 发现硬性风险时应立即停止放量并回滚。
1. 离线评测的层次
至少应区分以下几类指标:
偏好一致性
让标注者或强约束评测器比较两个回答,计算胜率、平局率和按类别胜率。它适合回答:
新模型是否更符合当前偏好标注?
它不能单独回答:
新模型是否更真实、更安全、更省钱?
任务成功率
对于结构化任务,应使用可验证结果。例如:
- SQL 是否执行成功;
- JSON 是否符合 schema;
- 分类标签是否正确;
- 代码测试是否通过;
- 工具调用参数是否有效;
- 检索答案是否包含正确证据。
这类评测通常比“语言流畅度”更接近业务目标。
事实性和可验证性
如果任务需要事实正确,评测应尽量引入:
- 标准答案;
- 数据库或知识库核对;
- 引用证据存在性;
- 引用内容与结论的一致性;
- 不知道时是否明确表达不确定。
只评估“答案和参考答案的文本相似度”可能把正确但不同表述判为低分,也可能把复制错误参考答案判为高分。
安全和拒答边界
安全评测不能只统计拒答率。拒答过多会损害正常任务,拒答过少会放大风险。应测量:
- 应拒绝请求的拒答率;
- 不应拒绝请求的误拒率;
- 拒答是否给出安全替代;
- 多轮诱导下是否保持边界;
- 是否泄露系统提示、凭证或受限上下文。
2. 线上评测必须包含成本和权限
模型上线后,每个请求至少涉及:
- 输入和输出 token 成本;
- 检索或工具调用成本;
- 延迟和超时;
- 并发下的队列等待;
- 租户配额;
- 数据访问权限;
- 审计和保留期限。
例如,为了提高偏好胜率,模型从平均 300 token 变成 1200 token:
- 人工可能更喜欢“更完整”的回答;
- 首 token 延迟可能增加;
- 每请求成本可能上升;
- 上下文窗口更容易被占满;
- 用户不一定更快完成任务。
因此应同时记录:
只看每 token 价格会误导,因为更便宜但任务失败率更高的模型,单位成功任务成本可能更高。
3. 灰度发布与回滚条件
候选模型上线可采用:
- 离线固定集;
- 回放线上脱敏请求;
- shadow 流量:候选模型生成结果但不返回用户;
- 小比例 canary;
- 按租户、语言或任务分组灰度;
- 逐步扩大流量。
放量门禁应同时包含硬指标和软指标:
- 硬指标:严重安全事件、越权访问、格式破坏、工具误调用;
- 软指标:偏好胜率、任务成功率、平均延迟、成本、用户反馈。
硬指标一旦越界应立即停止放量,不应被总体平均分掩盖。回滚必须指向已验证的旧版本,并验证:
- 路由是否真的切回旧模型;
- 缓存是否仍返回候选模型结果;
- 工具 schema 是否与旧模型兼容;
- 监控是否恢复到正常基线;
- 已生成的高风险结果是否需要补救通知。
九、一个完整的失败案例:偏好胜率上升但系统质量下降
假设团队收集客服问答偏好数据,标注者更喜欢:
- 语气礼貌;
- 解释完整;
- 有“总结”段落;
- 少用绝对化表达。
团队使用 DPO 训练新模型,离线偏好胜率从 52% 上升到 64%。
上线后发现:
- 平均回答长度增加 2.5 倍;
- 用户完成任务所需的追问次数增加;
- 部分退款请求没有直接调用退款工具,而是生成了长篇说明;
- 对明确可查的订单状态,模型频繁使用“可能”“建议确认”等措辞;
- 高峰期超时增加。
故障链条是:
- 标注目标偏重表达风格;
- 训练数据缺少“任务是否完成”的标签;
- DPO 推高了长而谨慎的回答;
- 离线评测只测偏好胜率;
- 线上工具调用成功率和单位成功任务成本没有作为门禁;
- 模型在真实权限和工具环境中表现变差。
诊断时应进行反事实分解:
- 固定相同 prompt,比对新旧模型的工具调用决策;
- 去掉格式和语气因素,只评估事实和任务完成;
- 按回答长度分层比较胜率;
- 检查长回答是否被标注者系统性偏好;
- 重放失败请求,区分模型决策错误、工具错误和权限拒绝;
- 计算每个成功退款任务的总成本,而不是只看 token 成本。
修复可能包括:
- 在偏好数据中增加任务完成和工具正确性维度;
- 对“完成任务但较短”的回答增加正例;
- 将结构化执行结果纳入独立评测;
- 对过长回答设置软约束,而不是简单截断;
- 对工具调用使用 schema 校验和权限中间层;
- 重新训练或重新筛选偏好数据,而不是只调大 DPO 的训练轮数。
十、常见误解与反例
误解一:奖励最高就代表模型最好
反例是奖励模型偏爱长回答。模型可以通过重复、免责声明和格式化获得高分,却没有增加事实信息。解决方法是使用独立的任务成功率、事实核验和长度分层评测。
误解二:DPO 不需要奖励模型,所以没有奖励偏差
DPO 没有显式的 ,但它仍然通过偏好标签学习一个隐含奖励:
如果偏好数据含有位置偏差、长度偏差或标注者偏差,DPO 会直接优化这些偏差。去掉奖励模型只减少了一类建模误差,没有消除数据测量误差。
误解三:参考模型只是训练细节
参考模型决定了“偏离什么算异常”。如果参考模型本身过度拒答,DPO 可能难以学到正常请求的直接回答;如果参考模型有严重幻觉,过强的参考约束又可能保留问题行为。参考模型应被视为对齐目标的一部分,而不是无关的实现参数。
误解四:偏好对可以随意交换顺序
在 DPO 中,交换 和 会把 logit 变号:
这不是数据格式变化,而是相反的监督信号。数据管道必须验证 chosen/rejected 字段是否在转换、排序和批处理过程中保持语义。
误解五:只要线上用户没有投诉就说明对齐成功
用户反馈存在沉默、选择偏差和幸存者偏差。安全问题可能低频但高损失,权限泄露可能没有及时被用户发现,错误答案也可能被用户直接放弃而不反馈。线上评测必须主动抽样和构造压力测试,不能只依赖自然反馈。
十一、如何设计可解释的对齐实验
一次可解释的实验应至少固定以下变量:
- 基础模型和 tokenizer;
- SFT 数据及版本;
- 偏好数据及采样策略;
- chosen/rejected 的定义;
- 参考模型;
- 序列 log-probability 的计算范围;
- 最大长度和截断规则;
- DPO 的 、学习率、batch size 和训练步数;
- 随机种子;
- 评测集版本;
- 线上流量切分方式。
实验结果不应只写“胜率提高”。更有信息量的报告应包含:
同时报告各指标的样本量、置信区间和分组结果。若某个模型总体更好,但在高风险分组显著更差,生产决策通常不能由总体平均值决定。
十二、模型、数据、权限和成本必须作为一个闭环
偏好对齐最终不是一个只发生在训练集上的模型问题。一个生产系统可以抽象成以下闭环:
每个环节都有独立的故障模式:
- 数据采集可能泄露个人信息或混入无权数据;
- 偏好建模可能放大标注者和展示偏差;
- 策略优化可能奖励黑客;
- 离线评测可能存在测试泄漏;
- 上线路由可能把候选模型错误地用于高风险租户;
- 线上日志可能包含敏感 prompt 和工具结果;
- 成本上升可能迫使系统降低超时预算,间接降低任务成功率。
权限控制应位于模型之外。不能把“模型应该拒绝越权请求”作为唯一防线;检索系统、工具网关和数据服务仍需独立执行租户隔离、字段权限和审计。模型输出的工具参数也应经过 schema、权限和业务状态校验。
成本控制也不能简单通过截断回答实现。截断可能删除免责声明、代码结尾或关键证据。更合理的做法是分别观察:
- 输入上下文长度;
- 输出长度;
- 检索文档数量;
- 工具调用次数;
- 重试次数;
- 并发排队时间;
- 每个任务是否最终成功。
当这些指标被同时纳入评测,团队才能判断某种对齐方法是在提高真实能力,还是只是在优化一个容易被测量的代理目标。
偏好对齐的核心结论不是某一种算法必然优于另一种算法,而是:模型最终优化什么,取决于偏好数据如何定义、奖励或隐式奖励如何构造、参考模型如何约束,以及上线系统如何验证结果。 RLHF 提供了显式奖励和强化学习闭环,DPO 提供了更直接的偏好优化路径;两者都无法绕过数据偏差、目标错配和线上评测。只有把这些部分放在同一个可审计、可分层、可回滚的生产系统中,对齐结果才具有实际意义。
系列导航与关联阅读
- 系列入口:AI 工程完整学习路线:从机器学习与 Transformer 到 RAG、Agent 和生产治理
- 上一篇:指令微调:样本格式、数据混合、损失、灾难遗忘和评测
- 下一篇:模型量化:PTQ、QAT、INT8、INT4、精度损失与硬件适配
官方资料
本文依据研究论文、标准组织与主流框架官方文档重新梳理;正文、示例与工程清单由 WR BLOG 编写。

评论
0 条讨论