奖励模型（Reward Model）基础
聊到RLHF，绕不开的一个核心组件就是奖励模型。说白了，它就是给大模型打分的那个人。你想想看，我们训练一个对话模型，怎么判断它回答得好不好？光靠人工标注太慢了，而且成本高得吓人。这时候就需要一个自动化的评分器——奖励模型。
我在做第一个RLHF项目时，一开始没太重视奖励模型，觉得随便搞搞就行。结果训练出来的模型，嗯…怎么说呢，有时候会为了讨好奖励模型而说一些看似合理但实际错误的话。后来我才明白，奖励模型的质量，直接决定了RLHF的成败。
奖励模型的作用
奖励模型的核心任务只有一个：给一段文本打一个分数。这个分数代表人类偏好——分数越高，说明这段文本越符合人类的期望。
具体来说，它有三个关键作用：
- 替代人工评估：在RLHF的强化学习阶段，模型每生成一个回答，奖励模型都能快速给出分数。这比每次都找人来打分高效得多。
- 提供梯度信号：奖励模型的输出是连续的数值，可以求导。这意味着它能给策略模型提供可学习的梯度，让模型知道往哪个方向调整。
- 对齐人类偏好：奖励模型本质上是一个「人类偏好的代理」。它学会了人类喜欢什么、不喜欢什么，然后把这个偏好传递给策略模型。
重要提醒：奖励模型不是万能的。它只能反映训练数据中的人类偏好，如果数据有偏差，奖励模型也会学歪。我见过一个项目，因为标注员偏好长回答，结果奖励模型给所有长回答都打高分，模型就学会了「废话连篇」。
架构设计：基于Transformer
奖励模型的架构，说白了就是在预训练语言模型的基础上加一个回归头。我习惯用下面这种结构：
输入文本 → [预训练Transformer] → [池化层] → [线性层] → 标量分数具体来说，有几个设计要点：
- 基座模型选择：我个人建议用和策略模型同规模的基座。比如策略模型是7B，奖励模型也用7B。太小了学不到复杂偏好，太大了训练成本翻倍。
- 池化策略：常用的有CLS token池化、均值池化、最后token池化。我在项目中试过，最后token池化效果最好。为什么？因为奖励模型关注的是整个序列的最终评价，最后一个token往往聚合了全局信息。
- 输出层：一个简单的线性层，把隐藏状态映射到1维标量。注意不要加激活函数，直接输出原始logits。
我的小技巧：训练奖励模型时，可以冻结基座模型的前几层。这样能保留预训练学到的语言知识，同时降低过拟合风险。我曾经试过全参数微调，结果模型在训练集上分数很高，但泛化能力很差。
下面这张图展示了奖励模型的完整架构：
训练数据构建
训练数据这块，我踩过不少坑。奖励模型需要的是偏好对数据——同一个prompt，有两个回答A和B，标注员告诉你哪个更好。
数据格式大概是这样的：
{
"prompt": "如何提高编程效率？",
"chosen": "建议使用版本控制工具，比如Git...",
"rejected": "多写代码就行了。"
}构建训练数据时，有几个关键点：
- 数据量：我建议至少10万对偏好数据。太少的话，奖励模型学不到稳定的偏好。我在一个项目里只用了3万对，结果模型在验证集上准确率只有62%，完全没法用。
- 多样性：prompt要覆盖各种场景——问答、写作、代码、翻译等。如果只在一个领域训练，奖励模型在其他领域会乱打分。
- 标注一致性：这是最大的坑。不同标注员对「好回答」的标准可能完全不同。我建议每个样本至少让3个人标注，取多数票。如果分歧太大，这个样本就丢掉。
避坑指南：我曾经遇到过标注员偷懒，给所有长回答都打高分。结果奖励模型学会了「越长越好」，策略模型也跟着学坏了。后来我加了长度惩罚，并且在数据中混入了一些「短而精」的好回答，才把这个问题纠正过来。
训练损失函数用的是Pairwise Ranking Loss：
loss = -log(sigmoid(score_chosen - score_rejected))这个公式的含义很简单：让好回答的分数比坏回答高。差值越大，loss越小。我习惯在训练时监控两个指标：
| 指标 | 含义 | 合理范围 |
|---|---|---|
| 准确率 | 模型判断谁更好的准确率 | 65%-75% |
| 分数分布 | 奖励分数的均值和方差 | 均值0附近，方差1左右 |
准确率太高（比如超过80%）反而要警惕，说明数据太简单或者模型过拟合了。分数分布如果严重偏离0，说明模型有bias，需要做归一化处理。
我的经验：训练奖励模型时，可以每隔500步在验证集上算一次准确率。如果连续5次没有提升，就提前停止。这样能省不少训练时间，而且效果往往更好。
嗯，奖励模型的基础就这些。说白了，它就是一个「人类偏好的打分器」。架构上不复杂，但数据质量和训练细节决定了它的上限。我见过太多项目因为奖励模型没做好，整个RLHF pipeline都白费了。所以，这块值得多花点心思。