偏好对齐与微调效果验收

微调完，模型能按要求回答了——但把几条回复摆在一起看，有好有坏。拿退款咨询来说：一个回答只给操作入口，另一个还说明了审核条件、到账以实际审核为准。两条都没错，但第二条把用户接下来会遇到的情况交代得更清楚。

让模型从"会答"进化到"答得更好"，靠偏好对齐；证明"确实更好"，靠验收评测。这一课把两件事一次讲清。

一、后训练地图：SFT 是教，对齐是调

后训练不是固定流程，而是一组方法的总称，各司其职：

• SFT：用"指令 + 期望回答"示范，教模型任务格式、回答方式、领域表达——教的是"怎么答"；
• 偏好对齐：在模型已会回答之后，用"同一问题的多个回答 + 优劣标注"教它"怎样答得更好"；
• 奖励模型（RM）：把人工偏好学成一个自动评分函数（学习目标：chosen 得分 > rejected），供强化学习使用；
• PPO / GRPO：按奖励信号优化生成策略；DPO：跳过奖励模型，把偏好关系直接写进训练目标。

实际项目不必全用，按模型能力、任务目标和资源灵活组合。注意：偏好对齐学的不是抽象的"人类价值观"，而是你为具体任务定义的评价标准——先想清楚"什么叫更好"，否则标注员会给出互相矛盾的选择。

二、偏好数据怎么造：prompt + chosen + rejected

一条偏好数据长这样：

{
  "prompt": "会员昨天自动续费，我想申请退款。",
  "chosen": "请先查看订单状态。符合退款条件时，可在订单详情中提交申请；如果没有退款入口，请联系人工客服核验。",
  "rejected": "可以，退款会在三个工作日内到账。"
}

rejected 的问题不在"错"，在于遗漏必要条件 + 承诺了不确定的到账时间。偏好数据表达的是相对关系，不是永久的好坏标签。

构造五步：准备有代表性的 Prompt → 用当前模型/不同版本/不同采样参数生成多个候选 → 按统一标准两两比较或排序 → 转成 chosen/rejected 数据对 → 抽查标注一致性，冲突样本交复核。

三个标注偏差要主动防：更长的回答显得更完整、更自信的措辞显得更可靠、排在前面的候选更易被选中。对策：随机调整候选顺序、隐藏模型名称、分维度独立检查（事实/完成度/风格/安全）、部分样本多人重复标注。

三、微调有没有用，测才知道：分任务指标速查

分类任务：从混淆矩阵四格（TP/TN/FP/FN）出发——

• Accuracy：整体正确率。类别不均衡时会骗人：1000 条里只有 20 条负样本，全预测"正向"也有 98% 准确率，但 20 条负样本一条没识别出来；
• Precision（预测为正中有多少真是正）/ Recall（真实为正中识别出多少）/ F1（两者平衡）；
• 混淆矩阵看哪些类别互相混淆：如"软件故障"常被误判为"网络故障"，就说明这两类的区分要补数据。

信息抽取任务：字段准确率（抽对的字段/应抽字段）+ 实体级 Precision/Recall/F1（应对多实体任务，字段准确率看不出漏抽）。

生成任务：五个维度——正确性（事实与结论对不对）、完整性（该答的都答了吗）、相关性（是否围绕问题）、格式遵循（JSON/字段顺序能否被下游解析——格式不对，内容再对程序也用不了）、幻觉（是否编造看似合理的事实）。

四、FDE 视角：验收报告是尾款的关键证据

• 基线对比是铁律：基础模型与微调模型在同一测试集上的对比表，是"微调产生了价值"的唯一硬证据——没有基线的验收报告等于没有报告；
• 指标跟着任务走：给抽取任务汇报 Accuracy 会被追问，直接上实体级 P/R/F1；给生成任务加格式遵循率——下游系统解析成功率客户最关心；
• 偏好标准文档化：把"什么叫更好的回答"写成评审标准（哪些算遗漏、哪些算过度承诺），既是标注依据，也是将来验收争议时的仲裁标准。

本课自测

1. SFT 和偏好对齐分别教模型什么？用退款回答 A/B 的例子说明。
2. 偏好数据的三元组结构是什么？rejected 回答常见的三类问题是什么？
3. 为什么类别不均衡时只看 Accuracy 会误判？应该补看哪些指标？
4. 生成任务的五个评测维度是什么？哪个维度出问题会直接导致下游程序无法解析？