对齐实验：偏好数据、奖励设计与 Reward Hacking

项目背景与目标

本项目不下载模型，而是用候选答案和确定性评分器验证奖励设计。目标是观察：只奖励长度和关键词时，得分最高的答案可能更差；加入正确性、格式、证据和长度约束后，排序才更接近任务目标。

完整项目位于 examples/09.16-alignment-lab。

整体架构

prompts.jsonl + candidates.jsonl
              │
              ▼
reward.py：naive / guarded 两种奖励
              │
              ▼
evaluate.py：排序、真实标签、一致率、Reward Hacking 样例

核心流程

每个候选包含机器可验证字段和人工质量标签。naive 奖励只计算长度与“检查”等关键词；guarded 奖励先验证 JSON、风险和动作，再限制冗余长度。

python3 evaluate.py

预期结果中，朴素奖励会选择冗长但风险错误的答案；受约束奖励选择简洁、正确、合法的 JSON。实验输出选择一致率和具体失败样例。

关键实现

Reward Hacking 不是程序 Bug，而是优化目标与真实目标不一致。修复顺序是：

1. 明确不可妥协的硬约束；
2. 用独立真实指标评估奖励；
3. 加入对抗候选和分布外输入；
4. 监控各奖励分量，避免一个分量支配总分；
5. 训练后继续人工抽查，而不是只看奖励曲线。

遇到的问题

规则评分器是否太简单

简单恰好便于看到目标漏洞。换成奖励模型后同样需要校准、独立验证和攻击测试，只是漏洞更难解释。

奖励中直接包含标准答案是否现实

在数学、代码、结构化流程等可验证任务中可以使用结果验证器；开放式写作则需要偏好标注、模型评审与人工评价组合。

高奖励是否等于偏好对可直接训练

还需检查候选多样性、长度偏差、同源污染和安全风险。本项目只验证奖励协议，不声称完成模型对齐。

结果、评估与阶段复盘

离线实验稳定产生一个 Reward Hacking 反例，并证明受约束奖励与人工质量标签更加一致。它为以后接入 DPO、PPO 或 GRPO 提供独立验收层。

改进方向

• 加入多个标注者和一致性统计；
• 对奖励权重进行敏感性分析；
• 加入提示注入、拒答和工具副作用样例；
• 用小模型生成候选，但保持评估集冻结；
• 保存奖励版本、候选来源和模型 revision。