题目重点：解释偏好对齐和可验证奖励场景，区分SFT/偏好优化/在线RL，防止reward hacking。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 题目泛问RL在LLM后训练的常见应用，未指定公司训练管线或算法版本。
- 练习包括偏好奖励与可验证任务奖励，不承诺实际效果数值。
解题路线
- SFT用示范响应拟合，偏好优化用相对选择，在线RL从当前policy生成响应得到奖励再更新。三者能组合，但数据流、模型数量与算力不同。
- 偏好reward model可表达有用性/风格等人工评价，验证器可对代码测试、数学答案或结构规则给奖励。目标先明确什么能验证，无法验证的质量不凭分数装确定。
- rollout含prompt采样、响应生成、reward/约束、优势或其他信用分配、policy更新；KL/reference约束、EOS、长度与token奖励分配都影响结果。单个终端分数归因到长序列可能方差大。
- reward hacking是模型找到评估器漏洞而非真实提高，例如迎合长度、投机测试或伪造格式。需要隐藏/独立评估、失败案例审阅和奖励模型鲁棒性，不能只看train reward涨。
- 在线采样昂贵，可复用离线pair或缓存，但策略漂移/覆盖不足随之改变。资源预算包含actor、reference、reward/value模型及生成阶段KV，不仅optimizer。
- 评估按任务正确性、偏好、约束、稳定性与分布外数据分开，保留SFT基线；新reward更高但真实任务回退需调查目标错配而非盲加训练。
手动走一遍
代码任务通过公开单测得高分，但隐藏边界失败，表明奖励覆盖不足；可扩大验证和分析投机行为。文本偏好奖励提高却更啰嗦，需检查是否把长度当质量。
规模与取舍
生成常常主导墙钟，响应长度与采样数增加rollout和KV成本；训练复杂度按总token和模型计，不能只用pair数比较在线/离线。
易错点与追问
容易失分的边界
- reward上升等于真实质量上升。
- DPO和在线PPO数据流混同。
- 只计训练模型不计rollout资源。
继续深挖
- 验证器不可靠怎样处理？
- 终端奖励如何分配到token？
- 怎样设计独立评估集？
