RLHF 与 Test-Time 算力：大模型强化学习与推理时优化

Author 收录于博客

2026-03-08 约 404 字预计阅读 1 分钟

1. RL 回顾：为什么需要“训练阶段的强化学习”？

1.1 三个基本问题

任务不匹配（task mismatch）：语言模型本身只是在最大化 $p(\text{probable response} \mid \text{prompt})$，也就是“最可能的下一个词”。但我们真正想要的是：
- 有用的回答（helpful）
- 不冒犯的回答（non‑offensive）
- 正确的解答、能通过测试的代码等。
数据不匹配（data mismatch）：预训练数据里有很多我们不想要的输出，比如有毒评论、带 bug 的代码，而真正的“好链路思维、好答案”数据反而很少。
exposure bias：训练时模型总是看“正确前缀”，几乎没见过自己的错误；测试时一旦前面某步错了，后面会越走越偏，因为它没学过怎样在错误状态下恢复。

1.2 RL 的基本思路

通过强化学习，把“任务指标”直接变成 reward，让模型在自己产生输出的闭环里学习。核心是四元组 MDP $(S, A, E, R)$：状态、动作、环境、奖励。

例子：语言生成
- 状态：当前 prompt 和已经生成的 token，$s_t = (x, y_{
- 动作：下一 token $a_t = y_t$
- 策略：$p_\theta(y_t \mid y_{
- 环境：把 token 拼接到序列里
- 奖励：对整个序列 $r(x, y)$ 打分，比如答案对不对。
也可以用“一步 MDP”：一次性生成整段回答，看整体 reward。

2. Reward 设计：Rule‑based、Model‑based 和 Preference

2.1 Rule‑based rewards（可验证规则）

这类 reward 的特点是可自动检查对错。

数学题：
- 让模型给出最终答案，自己写个 checker 看答案是否等于标准值。
- 定义 $r(x, y) = 1$（答对）或 $0$（答错）。
代码题：
- 运行单元测试，reward = 通过的测试用例比例。
- $r(x, y) = \text{fraction of passed tests}$。
生成 5 行诗：
- 计算模型输出的行数 $\text{num\_lines}$，设计 reward 反映和目标 5 行的差距，例如 $r(x, y)= -|\text{num\_lines} - 5|$。

这类 reward 简单、客观，非常适合数学、编程等“有标准答案”的任务。

2.2 Model‑based rewards：直接打分的模型

当无法轻易写规则时，用一个**单独训练的“打分模型”**来充当 reward function。

Direct assessment model：
- 输入：prompt x + 模型输出 y。
- 输出：一个实数 $R$（或者 0–1 概率），表示“helpful / safe 的程度”。
- 例子：NVIDIA 的 Aegis 内容安全数据集里，每个样本都会标注是否安全，拿来训练一个“安全分类器”作为 reward model。
Preference model / Reward model：
- 收集人类偏好数据：同一个 prompt 下，两个回答 $y_+, y_-$，标注哪个更好。
- 训练目标：让 reward model $r_\theta$ 对好的回答打更高分：$ \mathscr{L} = - \sum_{(y_+, y_-) \in D} \log \sigma(r_\theta(y_+) - r_\theta(y_-))$
- 这会鼓励 $r_\theta(y_+) \gg r_\theta(y_-)$。
- 真实例子：（1）Anthropic 的 HH‑RLHF 对话数据集：给出“chosen / rejected”回答对来训练 preference model。（2）UltraRM‑13B 是一个开源对话 reward 模型，用这种方式训练出来。
代码 Reward model：
- CodeScaler 提出用“execution‑free reward model”给代码打分，不用真的跑测试，用在 RL 训练和 test‑time Best‑of‑N 选择上，大幅省算力。

3. Policy Gradient：如何用 reward 更新 LLM？

目标是最大化期望奖励 $J(\theta)$。在“一步生成”的设置下，当输入 x 固定时，policy gradient 公式为：

$$ \nabla_{\theta} J(\theta) = \mathbb{E}_{y \sim p_\theta(\cdot \mid x)}\left[ r(x, y)\, \nabla_\theta \log p_\theta(y \mid x)\right] $$

直觉：
- reward 高的样本，梯度方向推动 $\log p_\theta(y|x)$ 变大（概率增大）；
- reward 低的样本，推动概率减小。

用采样近似期望：抽一个或几个 $\hat{y}$，得到损失：

$$ \mathcal{L}_{PG} = - r(x, \hat{y}) \log p_\theta(\hat{y} \mid x) $$

对这条 loss 做梯度下降，就相当于 policy gradient。

多步序列的“credit assignment”（归因）

如果 reward 只在最后给出（比如 Atari 游戏胜负），不清楚是哪个动作起了关键作用。常用办法是折扣：

$$ \hat{r}_t = \gamma^{T-t} r_T, \quad \gamma \in (0,1) $$

越接近终局的动作，$\hat{r}$ 越大；越早的动作被折扣得更多。

4. 让 RL 训练“稳定”的三大技巧

4.1 防止 Reward Hacking：KL 惩罚

Reward hacking：模型学会利用 reward 的漏洞，而不是学真正的任务。

例子：如果 reward 只奖励“不冒犯”，模型可能学会永远输出空字符串，因为空字符串“最不冒犯”。
动物比喻：训练“狼抓羊”，如果奖励设计不当，狼发现“直接撞墙尽早结束”反而罚得更少，于是选择躺平。

解决方案：在优化目标里加入 KL penalty，让新策略不要偏离原始模型太远：

$$ \arg\max_\theta \mathbb{E}[r(x,y)] - \beta D_{KL}(p_\theta || p_0) $$

在实现上，可把 KL 惩罚近似成一个额外 reward 项：

$$ r^{KL} = -\beta \log \frac{p_\theta(y|x)}{p_0(y|x)} $$

其中 $p_0$ 是原始模型或 supervised policy。

4.2 Reward Scaling：优势函数（advantage）

直接用 $r(x,y)$ 乘 $\log p_\theta$ 噪声大，会导致学习不稳定。常见做法是引入 baseline：

$$ \mathcal{L} = - (r(x, y) - b(x,y)) \log p_\theta(y|x) $$

baseline $b(x,y)$ 是对“期望 reward” 的估计，反映“平均水平”。
真正起作用的是 advantage $A = r-b$：
- $A > 0$ 表示比预期好 → 增大概率
- $A < 0$ 表示比预期差 → 降低概率。

baseline 的实现方式：

输出平均：对同一个 x 采样多条 y，用平均 reward 做 baseline（GRPO 类方法）。
滑动平均：跨 batch 维护历史 reward 的 running mean。
学习式：训练一个 value network 预测期望 reward。

4.3 控制更新步长：PPO

大步更新容易把策略“拧坏”，PPO 通过限制新旧策略比值来保证每一步变化不太大：

定义比值：

$$ \text{ratio}(x,y) = \frac{p_\theta(y|x)}{p_{\theta_{\text{old}}}(y|x)} $$

PPO 损失：

$$ L_{PPO} = \min\big(\text{ratio} \cdot A,\ \text{clip}(\text{ratio}, 1-\epsilon,1+\epsilon)\cdot A\big) $$

如果 ratio 超出 $[1-\epsilon,1+\epsilon]$，就被裁剪，防止太大更新。

开源库 verl 给出了 PPO 的实际代码实现，用 log‑prob 差值来近似 KL，并在每个 token 的 EOS mask 下取平均。

5. RLHF 与 RLVR：RL 在 LLM 上的几种用法

5.1 经典 RLHF 流程

InstructGPT / ChatGPT 采用的标准三步：

收集“示范数据”，做监督微调（SFT），得到初始 policy。
收集“比较数据”（同 prompt 的多回答对，人工标 preference），训练 reward model。
用 PPO 在 reward model 上做 RL 训练，得到最终 policy。

5.2 RLVR：可验证奖励（verifiable reward）

RLVR 用“可验证的 0/1 reward”替代复杂 reward model：

适用领域：算术题、数学竞赛题、明确可检验的 instruction‑following 任务。
流程：
- policy 生成 chain‑of‑thought + 最终答案；
- 通过规则/程序检查答案是否正确，reward = 0/1；
- 使用 PPO + output‑average baseline（GRPO）优化。

DeepSeek‑R1 就是 RLVR 风格：模型在训练中出现“aha moment”，会自己发现逻辑错误、重新分配算力到难题上。

5.3 “RL 真的提升推理能力了吗？”两篇连续工作

NeurIPS 2025：Does RL Really Incentivize Reasoning Capacity in LLMs? 主要发现：
- 对于大 sampling 数（大 k），单纯 base 模型 + 大量采样的 pass@k 反而比 RL 模型更好。
- RLVR 模型得到的解法路径，基本仍在 base 模型原本的输出分布里；RL 更像是“提高抽样效率”，而不是“扩展推理边界”。
- 不同 RL 算法（PPO、GRPO、Reinforce++）性能差异小，都离“最优抽样效率”还很远。
- 与此相对，知识蒸馏可以真正往模型里“注入新知识”，扩展可解问题的集合。
ICLR 2026：Beyond Pass@1 – Self‑Play with Variational Problem Synthesis Sustains RLVR
- 提出自博弈 + 变分出题策略（SvS），在 AIME 等数学 benchmark 上，RL 训练可以明显提升 pass@1 和 pass@32。
- 结论：在合适的设定和数据构造下，RL 确实能推动推理边界。但需要精心设计。

6. Test‑Time Scaling：把算力用在“推理阶段”

这一讲的核心主题是：不再无限扩大预训练，改用“inference 阶段多采样、搜索、验证”等方式来提升性能。

6.1 重复采样 + 验证：Large Language Monkeys

“LLM 像猴子敲键盘”——Large Language Monkeys 工作提出：

生成很多候选解（coverage 问题）
- 从同一个 prompt 出发，用温度采样、多次 sampling 得到 $k$ 个 candidate。
- 只要其中有一个正确，我们就“覆盖”了这个问题。
用 verifier 选出正确答案（precision 问题）
- 对 code：用单元测试；
- 对数学：用证明检查器；
- 对一般任务：可以用 reward model / 投票等。

关键观察：

在有自动 verifier 的领域（math / code），仅仅靠 repeated sampling，模型能力就能大幅提升；Llama‑3‑8B 在足够多采样下可以超过 GPT‑4o。
pass@k 与 k 之间也服从类似 scaling law：拟合成指数化的 power‑law 曲线，可以预测“多采样多少，准确率会到哪里”。

6.2 Inference‑time Scaling 的前提：可靠的验证器

对 math / code，自动验证比较靠谱。
对一般自然语言任务（开放问答、写作）：
- 单纯 majority vote / reward model 排名，与理论上“只看有没有正确答案”的 coverage 之间差距很大。
- 原因：正确答案往往是极少数样本，甚至在 1 万个样本里才有一两个；多数投票很容易被错误样本淹没。

结论：test‑time scaling 若要有效，必须搭配强大的 verification / ranking 方法。

7. Test‑Time Compute vs Pretraining Compute

GDM 2024 的工作“Scaling LLM Test‑Time Compute Optimally…”比较了两种花算力的方式：

增加预训练 FLOPs：放大模型或训练更久。
增加测试时 FLOPs：在同一模型上多做采样 / 搜索 / 修正。

在 MATH benchmark 上的发现：

对简单和中等难度题：在给定总 FLOPs 预算下，把一部分算力挪到 test‑time compute，往往比只放大预训练更划算。
对最难的题：test‑time scaling 的回报很有限，反而需要更强 base model。

8. Test‑Time 策略：并行采样 vs 顺序修正

8.1 两大范式

Parallel sampling（Best‑of‑N）
- 一次性生成 N 个完整解答，用 verifier / reward model 挑一个最好的。
- 适合难题：要靠“多种思路并行探索”。
Sequential revisions（顺序修正）
- 先生成一个解答，verifier 判错 → 要求模型根据错误反馈重写；重复多轮。
- Base 模型对简单题本来就差不多正确，多次自我修正可以渐进逼近正确答案。

实验证明：

简单题：全用顺序修正（sequential）表现最好。
难题：需要在 parallel 和 sequential 之间找到一个最佳比例；完全 sequential 会陷在某些错误思路里，完全 parallel 又浪费很多算力在差的样本上。

8.2 Process Reward Model + Beam Search

为了更细粒度地引导搜索，引入 Process Reward Model（PRM）：

不只给最终答案打分，而是给推理过程中的每一步打分。
用 PRM 做“beam search”：
- 第一步生成多个 partial steps；
- PRM 打分、只保留 top‑k 路径；
- 再往每条路径扩展下一步，如此反复；
- 相当于在 reasoning tree 上剪掉“红色坏分支”，保留“绿色好分支”。

这种“过程奖励 + 搜索”在 MATH 上比单纯 Best‑of‑N 更高效。

9. Archon：系统化搜索 Test‑Time 架构

为了系统地设计“推理时流水线（多模型 + 多阶段操作）”，ICML 2025 的 Archon 提出一个架构搜索框架。

9.1 基本操作（Inference‑Time Operations）

每一步操作都抽象成一个“op”：

类型	功能	输入 → 输出	典型用途
Generator	从指令生成候选回答	prompt → candidates	所有任务
Fuser	合并多候选为一个	prompt + candidates → fused	多回答融合
Critic	给每个候选写优缺点	prompt + candidates → critiques	供 Ranker/Fuser 使用
Ranker	排序并挑 top‑k	prompt + candidates → ranked	选择最佳若干
Verifier	验证推理正确性	prompt + candidates → verified set	数学/代码等
Unit Test Generator	生成单测	prompt → tests	代码任务
Unit Test Evaluator	运行单测并打分	prompt + tests + candidates → scores	代码任务

9.2 Archon 架构规则

第一层必须是 Generator（先生成候选）。
一层只能有一种 op 类型。
Critic 必须在 Ranker / Fuser 之前；Unit Test Generator 后必须接 Evaluator。
可以堆多层形成“深度推理架构”（类似多层神经网络）。

通过 贝叶斯优化 在给定的模型集合 + op 集合 + 调用预算下，搜索性能最好的 architecture（比随机/贪心搜索效率高得多）。

9.3 性能结果

在多个 benchmark（MT‑Bench、AlpacaEval、Arena‑Hard、MixEval、MATH、Code Contests）上，Archon 的“任务定制架构”在 pass@1 / win‑rate 上大幅超过单一 GPT‑4o、Claude 3.5 Sonnet 等 baseline，也优于现有 LM‑system（如 MoA, ADAS, AFlow 等）。
同时保持合理的调用次数和成本。

10. 何时该用 RL / Test‑Time Scaling？

最后的结论：

用 RL 的场景
- 目标是优化序列级任务指标（例如“整段回答是否对用户有帮助”、“整段 chain‑of‑thought + 答案是否正确”）。
- 存在非平凡 MDP（多轮对话、网页操作、机器人控制等），reward 来自整个交互过程。
用 Test‑Time Scaling 的场景
- base 模型已经不错，但还想在 math / code 等可验证领域进一步榨干性能；
- 希望不再花大量钱做新预训练，而是用更多 inference 预算 + 好的 verifier 和架构搜索来提升效果；
- 尤其是你有自动验证方式时（单元测试、定理证明、编译器、自然语言单测等）。

目录