奖励模型（Bradley-Terry）

0. 任务目标

奖励模型（Reward Model, RM）是 RLHF 里唯一一个「把人的判断压缩成一个可微函数」的环节。第 5 章把 Bradley-Terry 从概率模型一路推到那个著名的 -logsigmoid(r_chosen - r_rejected)，本作业要做的就是把这个损失真的跑一遍，然后回答一个很朴素的问题：它到底学没学到东西？

之所以要单独问一遍，是因为 RM 训练有一个不太友好的性质：它的所有指标看起来都在动。loss 会降，margin 会涨，训练准确率会升。但这些当中只有一个和「模型是否真的会判好坏」直接挂钩，其余几个都可能在模型什么都没学会的情况下照样好看。这组实验就是用两个规模的基座，把这件事演示出来。

上游第 5 章末尾的 Suggested Experiments 第 1 条给的起手式是 --samples 2000 --epochs 1，默认基座 Qwen/Qwen3-0.6B-Base；本站因为显存只剩约 6.9 GiB，换成了 SmolLM2 的 135M 与 360M 两档，正好凑成一组规模对照。

1. Bradley-Terry 训练在做什么

完整推导在第 5 章，这里只留跑实验必需的那几行。

Bradley-Terry 模型假设每个回复 $y$ 在给定 prompt $x$ 下有一个标量「实力值」，人在两个回复之间做选择的概率由二者实力之差决定：

其中 $\sigma$ 是 sigmoid，$y_{\text{c}}$ / $y_{\text{r}}$ 分别是被选中（chosen）与被拒绝（rejected）的回复。对数据集做最大似然，取负对数，就得到实现里那一行：

loss = -F.logsigmoid(r_chosen - r_rejected).mean()

模型结构：一个挂在最后一个非 padding token 上的线性头

上游 reward_models/base.py + train_preference_rm.py 的做法非常薄：拿一个普通的因果语言模型当骨干，在最后一层隐状态上加一个输出维度为 1 的 nn.Linear，然后只取序列最后一个有效位置的输出作为整条序列的奖励。

def get_reward(self, input_ids, attention_mask):
    hidden = self.get_hidden_states(input_ids, attention_mask)

    # 每条序列的最后一个非 padding 位置
    seq_lengths = attention_mask.sum(dim=1) - 1
    batch_indices = torch.arange(hidden.size(0), device=hidden.device)
    last_hidden = hidden[batch_indices, seq_lengths]

    return self.head(last_hidden).squeeze(-1)

两个细节值得留意：

• 为什么取最后一个 token。因果注意力下，只有最后一个位置「看过」整条序列，所以它的隐状态是唯一能代表全序列的那个。这就是第 5 章说的序列级（sequence-level）监督——整条回复只拿一个标量分数。
• attention_mask.sum(dim=1) - 1 依赖右侧 padding。如果 tokenizer 配成左侧 padding，这行代码会静默取错位置。这是 RM 实现里最常见的沉默 bug 之一。

骨干是全参数微调（不是只训头），这也是为什么显存开销和一次普通 SFT 是同一个量级，而不是「只训一个线性层」那么轻。

一次前向要跑两遍

forward 对 chosen 和 rejected 各调一次 get_reward，所以一个「pair」在计算上等于两条序列。配置里的 batch_size: 2 指的是 2 个 pair，实际过模型的是 4 条序列——估算显存和时间时容易记漏这一点。

2. 运行命令

这个模块没有配套 YAML，全部走命令行覆盖。本次实测的通用形式是：

python -m reward_models.train_preference_rm \
    --model-id <M> --samples <N> --epochs <E> --no-wandb

两组对照具体展开就是：

# A 组：135M，2000 对，1 个 epoch
python -m reward_models.train_preference_rm \
    --model-id HuggingFaceTB/SmolLM2-135M --samples 2000 --epochs 1 --no-wandb

# B 组：360M，5000 对，2 个 epoch
python -m reward_models.train_preference_rm \
    --model-id HuggingFaceTB/SmolLM2-360M --samples 5000 --epochs 2 --no-wandb

其余参数保持上游默认（batch_size 2、max_length 512、grad_accum_steps 8、lr 5e-5、val_ratio 0.1、eval_interval 25）。数据集是 argilla/ultrafeedback-binarized-preferences-cleaned。

加上 --no-wandb 之后指标去哪了

--no-wandb 会让 log_metrics 空转，但这个模块和 SFT / DPO 不同：它把关键信息也打到了 stdout。每个优化步一行训练指标，每 eval_interval（默认 25）步一行验证指标，每个 epoch 结束再来一行汇总。格式大致是这样（下面第二行的数字取自本次 B 组的实测结果）：

Epoch 0 step 25 | loss <训练 loss> | acc <训练准确率>
Epoch 1 | Val Loss: 0.6963 | Val Accuracy: 0.558 | Val Margin: 0.2348

所以这一组直接重定向控制台输出就够用了，不必套 run_with_metrics.py——本作业 logs/ 下的两份日志就是这么来的。（如果你想要 train/r_chosen_mean、train/r_rejected_mean 这些只进 W&B 的字段，再用包装器。）

训练结束后的 demo

脚本默认会在训练结束后跑一个 demo_scoring：对固定 prompt Explain quantum computing in simple terms. 给出一个「好回答」和一个「差回答」，分别打分，然后打印模型有没有把好的排在前面。加 --skip-demo 可以跳过。

3. 实测结果

两组对照

日志：homework/hw2-rm/logs/run_bt_smol135m.log、run_bt_smol360m.log。

先把这张表读完再往下：A 组的 0.485 在 0.5 的下面。成对判别的随机基线就是 0.5，所以 A 组不是「学得慢」，是完全没学到——0.485 与 0.5 的差距完全在 200 条留出样本的采样噪声之内。B 组的 0.568 高于随机，但离第 5 章提到的合格 RM 的 0.65–0.75 还差得远。

B 组的 val margin 轨迹

这条曲线单看非常漂亮：从 0.126 一路单调爬到 0.235，只在最后两个点上略微回落。如果 margin 是你唯一盯着的指标，你会认为这次训练很成功。

epoch 汇总

A 组的训练 loss 全程在 0.73–0.76——注意这是在 $\ln 2 \approx 0.693$ 这条随机基线之上。

4. 四个教学点

(1) 135M 完全学不动

A 组的 val 准确率 0.485 就是随机。三条独立证据互相印证：

• 0.485 落在 0.5 的下方，200 对留出样本上这个偏差毫无意义；
• A 组的训练 loss 全程 0.73–0.76，而 BT 损失的随机基线是 $\ln 2 \approx 0.693$——训练 loss 都在基线之上，连训练集都没拟合；
• demo 里它甚至给差回答打了更高的分。

值得强调的是，SmolLM2-135M 能写出通顺的句子。它有完整的语法能力、常识片段和上下文建模。但「判断两个回答哪个更好」是一个完全不同的能力：它要求模型同时理解问题、评估两个回答各自的正确性与完整性、还要把这个比较压进一个标量。

实践含义：如果你的 RM 训练曲线看起来像 A 组（训练 loss 贴着或高于 0.693，准确率在 0.5 附近），先怀疑基座太小或数据管线有 bug，不要去调学习率。调超参救不回一个容量不够的模型。

(2) 360M 学到了，但很弱

B 组的 0.568 确实高于随机，训练 loss 也从 0.7276 降到了 0.6502（跌破了 $\ln 2$），说明学习信号是真的。但 0.568 远低于第 5 章提到的合格 RM 的 0.65–0.75。

这个区间值得记住，因为它有一层反直觉的含义：即使是生产级的偏好奖励模型，成对判别准确率也就在 0.65–0.75 这个量级，而不是接近满分。原因不是模型笨，而是偏好数据本身就有大量「两个回答其实差不多」或者「标注者之间意见不一致」的样本——第 10 章那句「标注者之间的分歧不是噪声，是信号」在这里体现为一个准确率天花板。所以看到 0.568 时要同时意识到两件事：这个模型很弱，而且就算训得很好，它的上限也远没有一般分类任务那么高。

(3) 第二个 epoch 已经在过拟合

把 epoch 汇总表竖着读一遍：

这是过拟合的教科书形态：训练指标和验证指标分道扬镳。第二个 epoch 里模型学到的东西，全部是这 4500 对训练样本的特有模式，没有一点泛化出去。

(4) margin 会持续涨，但涨的不一定是判别力

这是四个教学点里最容易被忽略、也最值得带走的一个。把两条曲线并排放：

margin 单独看会骗人，必须和准确率一起读。这条规则的适用范围远不止 RM：

• HW4 的 DPO 也报 margins，同样不能单独看——那里的 accuracy 是配套指标。
• HW1 是这个主题的另一个版本：loss 在动而能力没动（那里是 loss 不降但能力提升，这里是 margin 上升但能力不变——两个方向的脱钩都存在）。
• 第 14 章的过优化整章都在讲这件事的放大版：奖励曲线一路向上，模型却越来越难用。

5. 自选消融

上游第 5 章的建议是「先扫 --samples、--lr、--model-id，再考虑动模型结构」。这个顺序有道理：结构改动会同时改变一堆东西，在你还不知道基线长什么样的时候动它，得不到任何可解释的结论。以下全部未在本次会话中运行，只说改什么、看什么。

(a) 先补一组干净的规模对照

这是最该做的第一件事。第 2 节说过，A / B 两组同时改了三个变量，所以「规模」这个结论其实是脏的。固定样本数和 epoch，只换 --model-id：

for M in HuggingFaceTB/SmolLM2-135M HuggingFaceTB/SmolLM2-360M; do
  python -m reward_models.train_preference_rm \
      --model-id "$M" --samples 2000 --epochs 1 --no-wandb
done

要回答的问题很具体：135M 的失败是容量问题，还是只是数据/训练量不够？如果 360M 在同样的 2000 对 / 1 epoch 下明显超过 0.5，那容量假说成立；如果它也趴在 0.5 附近，说明前面观察到的差异里数据量的贡献更大。

(b) 扫样本数

--samples 取 1000 / 2000 / 5000 / 10000，固定基座为 360M、固定 1 个 epoch。注意留出集是按比例切的（val_ratio 0.1），所以样本数一变，评测集也跟着变——这会让不同设置之间的准确率不严格可比。想做对，要么把 --val-ratio 设成 0 再配一个固定的外部评测集（见 (d)），要么至少在解读时记住这一点。

(c) 扫学习率

上游默认 lr 5e-5。往两边各试一个数量级（1e-5 / 5e-5 / 1e-4），观察：

顺带一提，本作业沿用的是 lr_scheduler: linear_decay（warmup + 线性衰减）。另一个可选值 warmup_only 保留了上游更早的行为，做学习率消融时不要同时改这一项，否则末段的有效学习率也变了。

(d) 加一个 50–200 条的固定留出评测集

这是上游第 5 章 Suggested Experiments 明确点名的一个「有用的贡献」，也是本组实验最大的短板——第 3 节列过：本次没有独立评测集，验证集是从同一批训练样本里切出来的。

要做的事很小：从 UltraFeedback（或另一个偏好数据集）里固定抽 50–200 对，永远不参与训练，写一个不需要跑完整训练就能调用的评测函数，报告成对排序准确率。核心逻辑其实上游已经写好了，就是 evaluate_preference_rm：

margin = r_chosen - r_rejected
total_correct += (margin > 0).sum().item()
total_margin  += margin.sum().item()

需要补的只是「固定的一份数据 + 一个能单独调用的入口」。它带来的三个好处：

• 不同超参设置之间终于可比了——评测集不再随 --samples 变。
• 能在调参过程中随时用，不必每次等训练跑完（这正是上游要求「小到能在调参时用」的原因）。
• 能同时报准确率和 margin，把第 4 节 (4) 那个脱钩现象变成一个常规检查项，而不是事后才发现的意外。

做完这组实验后回哪一节

• 第 5 章 · 奖励建模：Bradley-Terry 的完整推导、ORM / PRM / 生成式奖励的分工、value head 的实现细节、以及 RewardBench 这类评测在测什么、测不到什么。
• 第 14 章 · 过优化：本页第 4 节 (4) 的放大版——当这个不完美的 RM 被拿去做 RL 优化目标时会发生什么。
• HW3 · 策略梯度：下一步。有了奖励函数之后怎么用它更新策略。
• HW4 · DPO：另一条路线——完全跳过显式奖励模型，直接从偏好对上优化策略。跑完 HW2 再看 DPO，会更容易理解「隐式奖励」这个说法到底省掉了什么。