RLHF vs RLAIF vs RLVR：从“人类偏好”到“可验证奖励”

RLHF vs RLAIF vs RLVR：从“人类偏好”到“可验证奖励”

目录

• 1. 全局视角：RLHF / RLAIF / RLVR 一图总览

• 2. RLHF：从人类反馈出发的对齐范式

• 3. RLAIF：用 AI 代替人类打分

• 4. RLVR：从可验证奖励出发的强化学习（重点）

• 5. 实战示例：一个极简 RLVR 训练脚本（PyTorch 风格伪代码）

• 6. 工程落地建议：如何选 RLHF / RLAIF / RLVR

• 7. 未来趋势与个人理解

---

1. 全局视角：RLHF / RLAIF / RLVR 一图总览

1.1 三种方法核心差异

用一句话概括：

• RLHF（Reinforcement Learning from Human Feedback）
  用“人类打分 / 排序”训练奖励模型，再用 RL（通常 PPO）优化策略。

• RLAIF（Reinforcement Learning from AI Feedback）
  把“打分的人”换成“另一个 AI（带宪法/规则）”，用 AI 自动产生偏好 / 奖励。

• RLVR（Reinforcement Learning from / with Verifiable Rewards）
  不再问人/AI“你喜不喜欢这个回答”，而是写一个（或一套）可自动验证的程序来打分：
  比如数学题直接验答案、代码跑单测、MCQA 对比标准答案。

用一个表来对比：

维度	RLHF	RLAIF	RLVR
反馈来源	人类标注（偏好/评分）	AI 标注（通常受“宪法”约束）	程序/规则/工具自动验证
奖励形式	learned reward model	learned reward model	直接可计算的 reward（0/1 或 [0,1]）
成本	标注昂贵，规模有限	便宜，易扩展，但依赖老师模型	一旦有 verifier，几乎免费、可大规模采样
主流优化	PPO / RLOO / GRPO 等	同 RLHF	PPO / GRPO / 其它 policy gradient
典型场景	聊天对齐、安全、开放式任务	安全对齐、价值观约束	数学推理、代码、MCQA、结构化任务及其扩展

1.2 一个直观类比

你可以把三种方法想象成三种“老师”：

• RLHF：“真人老师打分” —— 老师告诉你哪句回答更好。
• RLAIF：“AI 老师打分” —— 老师是一个遵守某本“宪法”的 AI。
• RLVR：“考试系统自动判分” —— 写完答案塞进判题机，自动告诉你对/错，甚至给部分分。

RLVR 的关键点在于：奖励可以被客观、可重复地自动验证，这让它在可扩展性、鲁棒性方面有巨大优势，也是当前推理类大模型（比如 DeepSeek-R1、OpenAI o 系列）非常依赖的一条路线。

---

2. RLHF：从人类反馈出发的对齐范式

2.1 标准三阶段 Pipeline

典型 RLHF pipeline（以对话模型为例）：

1. 预训练（Pretraining）
   在大规模语料上做自回归语言建模，得到一个 base LM。

2. SFT（Supervised Fine-Tuning）
   用人类写的“好回答”做监督微调，得到一个“还算听话”的模型 π₀。

3. 奖励模型 + RL（Reward Model + PPO）

   • 收集数据：对同一个 prompt，人工比较多个回答，给出偏好（哪一个更好）。
   • 训练奖励模型 r_θ(x, y)，以“哪一个被选中”为监督信号。
   • 用 r_θ 作为 reward，配合 KL 正则，用 PPO 等方法优化 policy π_φ。

最终的 RLHF 模型 π_RL 在人类偏好上表现更好，同时尽量不偏离原模型太远。

2.2 奖励模型的数学形式

最常见的是 Bradley–Terry 模型：

对每条比较样本 (x, y_w, y_l)，其中 y_w 是优选回答，y_l 是被打败的回答。奖励模型 r_θ(x, y) 输出一个标量“好坏分”。

偏好概率写成：

$$P_{\theta }(y_w\succ y_l\mid x)=\sigma \left(r_{\theta }(x,y_w)-r_{\theta }(x,y_l)\right)=\frac{1}{1+\exp \left(-(r_{\theta }(x,y_w)-r_{\theta }(x,y_l))\right)}$$

训练目标是最大化所有样本的对数似然，等价于最小化：

$${\mathcal{L}}_{\text{RM}}(\theta )=-{\mathbb{E}}_{(x,y_w,y_l)}\left[\log \sigma (r_{\theta }(x,y_w)-r_{\theta }(x,y_l))\right]$$

训练好 r_θ 之后，就可以把它当作“人类偏好近似函数”。

2.3 RL 优化目标与 KL 正则

假设我们要学一个新策略 π_φ，基于参考策略 π_ref（通常就是 SFT 模型 π₀）。
对 prompt x，生成回答 y ~ π_φ(·|x)，奖励为：

$$R(x,y)=r_{\theta }(x,y)-\beta \log \frac{{\pi }_{\varphi }(y\mid x)}{{\pi }_{\text{ref}}(y\mid x)}$$

第一项是“人类偏好评分”，第二项是 KL 惩罚，防止模型走太远。
整体目标：

$$\underset{\varphi }{\max }{\mathbb{E}}_{x\sim \mathcal{D},y\sim {\pi }_{\varphi }(\cdot \mid x)}\left[R(x,y)\right]$$

PPO / RLOO / GRPO 等算法本质上都是在近似求解这个目标，只是：

• 如何估计 advantage；
• 如何近似 KL；
• 如何做 clipping / trust region
  上有不同实现细节。

2.4 RLHF 的优点与局限

优点：

• 适合无法写出明确打分函数的任务（礼貌、幽默、安全性、写作质量等）。
• 兼容性好：与现有的 RL 工具链（PPO 等）亲和。
• 已在大量大模型产品中实践验证（ChatGPT、Claude 等）。

局限：

• 标注贵，且噪声大且主观（不同人标准不一）。
• 奖励模型是近似，可能被 RL 策略“reward hacking”（学会哄骗奖励模型）。
• 难以保证充分覆盖长尾和复杂推理过程。

---

3. RLAIF：用 AI 代替人类打分

3.1 基本思想与 Pipeline

RLAIF（RL from AI Feedback）本质上是 RLHF 的一个“自动化版本”：

• 用一个 老师模型（teacher LLM） 代替人类来做偏好标注；
• 老师模型遵循一套“宪法 / 规则”（Constitution），保证其反馈大致符合人类价值观；
• 其余 pipeline 基本不变：
  • 生成两份候选回答 y₁, y₂；
  • 让老师模型根据宪法说明哪个更好；
  • 用这些偏好数据训练奖励模型 r_θ；
  • 再用 RL 优化目标模型 π_φ。

3.2 与 RLHF 的本质区别

区别不在算法，而在“谁来打分”:

• RLHF：真实人类 → 真实但贵且有限；
• RLAIF：AI 老师 → 便宜、可大规模，但质量依赖老师模型和“宪法”。

从数学形式看，训练奖励模型的损失、RL 的目标函数都可以跟 RLHF 一样；
真正不同的是 数据来源与偏差类型。

3.3 风险与注意事项

• 反馈循环风险：学生模型和老师模型来自同一分布，可能一起“跑偏”。
• 宪法 / 规则设计难度大：规则写不好，容易过度保守或放飞。
• 难以离线审计：AI 反馈大规模产生，逐条人工审计成本极高。

因此很多系统会同时使用：
RLHF（高质量少量） + RLAIF（低成本大量） 混合采样。

---

4. RLVR：从可验证奖励出发的强化学习（重点）

4.1 什么是“可验证奖励”

RLVR（Reinforcement Learning from / with Verifiable Rewards） 的核心是：

将 reward 设计成一个 可被程序自动验证 的函数，尽量减少乃至完全去除主观打分 / 学习奖励模型的环节。

形式上，我们有一个 verifier 函数：

$$f(x,y)\in [0,1]$$

• x：prompt / 输入问题
• y：模型输出
• f：一个程序（可能调用工具、模型等），输出一个确定的分数（0/1 或 连续值）

常见例子：

1. 数学题：

   • 给定题目 x 和标准答案 a*, 把 y 中解析出的答案 a(y) 与 a* 比较；
   • 完全正确记 1，否则 0 或部分分。

2. 代码：

   • 把模型生成的代码放进沙箱，跑一套单元测试；
   • 通过率作为 reward（例如 通过率 ∈ [0,1]）。

3. MCQA（多选题）：

   • y 中预测一个选项（A/B/C/D），与标准答案比较；
   • 答对 1，答错 0。

关键特性是：f 是可审计、可复现的，并非通过黑盒 reward model 拟合而来。

4.2 RLVR 高层 Pipeline

简化版 RLVR pipeline：

1. 准备“可验证数据”

   • 例如：数学题 + 标准答案；代码题 + 测试集；医学问答 + gold label；
   • 或者提供一个可以调用外部工具的判分器。

2. 定义 Verifier / Reward 函数 f(x, y)

   • 纯规则：字符串比较、数值比较、正则表达式等；
   • 工具调用：执行代码、调用 search / DB；
   • 甚至可以是“另一个 LLM + 规则”，但要保证输出可解释。

3. 采样 Trajectory

   • 从数据分布 D 采样 prompt x；
   • 用当前策略 π_φ 生成多条回答 y₁,…,y_K（GRPO 等需 Group）；
   • 对每个 yᵢ 计算 reward rᵢ = f(x, yᵢ)。

4. 用 RL（PPO / GRPO 等）更新策略

   • 利用 rᵢ 计算 advantage；
   • 做 policy gradient 更新 π_φ，同时加 KL 正则约束其不要偏离参考策略 π_0。

整体上，RLVR 的 pipeline 和 RLHF 长得很像，只是把“学出来的奖励模型”换成了“手写/verifiable 的 reward 函数”。

4.3 数学建模：二元奖励 + KL 正则

4.3.1 基本目标：最大化成功率

对于 RLVR，最常见的是二元奖励 r ∈ {0,1}（成功 / 失败）。
设数据分布为 x ~ D，policy 为 π_φ(y|x)，verifier 为 r(x, y)，目标是：

$$J(\varphi )={\mathbb{E}}_{x\sim \mathcal{D},y\sim {\pi }_{\varphi }(\cdot \mid x)}[r(x,y)]$$

这就是最大化解题成功率 / 通过率。

4.3.2 加上 KL 正则

为了防止模型走得太偏（例如只追求通过率而牺牲语义多样性、风格等），通常会加 KL 正则，约束 π_φ 不偏离参考策略 π_0（通常是 SFT 模型）：

逐样本奖励：

$$R(x,y)=r(x,y)\beta \log \frac{{\pi }_{\varphi }(y\mid x)}{{\pi }_0(y\mid x)}$$

然后目标是：

$$\underset{\varphi }{\max }{\mathbb{E}}_{x\sim \mathcal{D},y\sim {\pi }_{\varphi }}[R(x,y)]$$

这和 RLHF 形式几乎一样，只是 r(x,y) 的来源从 reward model 变成了 verifiable 函数。

4.3.3 Policy Gradient / REINFORCE 形式

如果暂时忽略 KL（或把 KL 合并到 reward 里），标准的策略梯度为：

$${\nabla }_{\varphi }J(\varphi )={\mathbb{E}}_{x,y\sim {\pi }_{\varphi }}\left[A(x,y){\nabla }_{\varphi }\log {\pi }_{\varphi }(y\mid x)\right]$$

其中 advantage A 一般通过：

$$A(x,y)=r(x,y)-b(x)$$

b(x) 是 baseline（可以是 value network，或者简单均值）。
在 RLVR 中，因为 r 通常是 0/1，variance 很大，所以如何构造 A 非常关键，这也是 GRPO 受关注的原因。

4.4 GRPO 在 RLVR 中的角色

GRPO（Group Relative Policy Optimization） 是在 verifiable / 二元奖励场景下表现很好的一个方法，DeepSeek-R1 等推理模型就使用了 GRPO。

核心 idea：

• 对每个 prompt x，不是只采样一个回答，而是采样 K 个回答 y₁,…,y_K；
• 对这 K 个回答计算对应的 reward 向量 r = (r₁,…,r_K)；
• 在一个 group 内做标准化 / 白化，得到 group-relative advantage：

$$A_i=\frac{r_i-{\mu }_r}{{\sigma }_r+ϵ}\text{其中}{\mu }_r=\frac{1}{K}\sum _j{r}_j,{\sigma }_r^2=\frac{1}{K}\sum _j(r_j-{\mu }_r{)}^2$$

• 使用 A_i 作为 advantage 做策略梯度更新。

直觉：
在同一 prompt 上，相对表现更好的回答会得到正优势，差的得到负优势，这样在同分布内形成“对比学习”的效果。

更进一步的理论分析表明，在 verifiable / 0-1 奖励下，GRPO 的目标可以改写成一个 带 KL 正则的对比学习损失，在一定条件下可以单调提高成功率。

简化的 GRPO 风格 objective（概念）

忽略 token 级别细节，把每个回答当作一个 action，
那么 GRPO 的更新可以近似看成：

$${\mathcal{L}}_{\text{GRPO}}(\varphi )=-{\mathbb{E}}_x\sum _{i=1}^K{A}_i(x)\log {\pi }_{\varphi }(y_i\mid x)+\beta D_{\mathrm{KL}}({\pi }_{\varphi }(\cdot \mid x)\parallel {\pi }_0(\cdot \mid x))$$

理论上可以推导出一个迭代形式：

$${\pi }_{n+1}(y\mid x)\propto {\pi }_0(y\mid x{)}^{1-\alpha }{\pi }_n(y\mid x{)}^{\alpha }\exp (\gamma {\hat{r}}_n(x,y))$$

其中 (\hat{r}_n) 是某种 group 标准化后的 reward，α, γ 由 KL 系数等超参决定。该迭代能在理想条件下单调提高成功率的上界。

4.5 与 PPO / RLHF 的关系与差异

从工程视角看：

• 相同点

  • 都是 policy gradient + KL 正则；
  • 都需要采样、估计 advantage、反向传播更新；
  • 都可以在序列级别 / token 级别实现。

• 主要差异

  • PPO 通常依赖 value function 来估计 advantage；
  • GRPO 用 group 内 reward 标准化 直接构造 advantage，避免单独训练 value network；
  • RLHF 中 reward 来自 learned reward model；
  • RLVR 中 reward 来自 verifier/程序，更客观可控。

实践中，RLVR 也可以用 PPO，而不仅限于 GRPO；只是当前推理类工作里 GRPO 特别受欢迎。

4.6 奖励设计：规则、程序与“软可验证”

RLVR 真正难的其实不是 RL 算法，而是怎么设计一个好用的 verifier。

典型设计思路：

1. 硬可验证（hard verifiable）

   • 数学：对比标准答案或用符号计算库验证等价；
   • 代码：跑单测、静态分析；
   • 分类：对比 label。

2. 部分可验证（soft verifiable）

   • 例如在医学 QA 中，模型回答是否“完全正确”很难写规则，但可以：
     • 用一个强基线 LLM 做“证据检索 + consistency 检查”；
     • 再配合规则（比如对 ICD-10 编码、用药剂量等检查）。

3. rubric / 生成式 verifier

   • 对更加开放的任务（essay、策略建议等），可以把 rubric（细化评分标准）结构化，交给一个 verifier 模型打分，而这个 verifier 本身也要尽量可审计。
   • 这类工作正在尝试“把 RLVR 扩展到开放任务”：例如用 rubric anchors、生成式 reward model 尝试在多领域、多维度上实现“尽量客观”的自动打分。

总体来说：
RLVR 不是一定要 100% 规则可验证，而是在尽可能多的维度上使用可审计的、程序化的打分机制。

4.7 典型应用场景：数学、代码、医学、情感对话等

目前 RLVR 在以下场景已有较多研究与落地：

1. 数学推理 / 奥数题 / 奥赛题

   • 答案通常是确定的数字或表达式；
   • 可用符号工具验证，或者只检查最终答案是否匹配；
   • DeepSeek-R1、一些 o 系列模型就大量使用类似设定。

2. 代码生成

   • 提供函数签名和单元测试，reward = 测试通过率；
   • 可以扩展到 bug 修复、refactoring 等。

3. 医学 QA / 科学 QA

   • 标准答案来自专业标注；
   • 使用 verifiable reward 可以减少模型在关键领域的幻觉。

4. 情感对话 / 情绪智能

   • 如 RLVER 这类工作，尝试为“情绪适切性”定义可验证奖励（例如根据标注数据训练一个较为客观的情绪判别器+规则）。

5. 跨领域复杂任务

   • “Crossing the Reward Bridge”等工作探索如何用 RLVR 支撑多领域的 reasoning（医学、心理学、经济学等），往往结合自动构造 reference answer 或 verifier。

4.8 RLVR 的优势与局限

突出优势：

1. 客观与可审计

   • 奖励由程序或工具给出，逻辑清晰可追踪；
   • 更容易做安全审计和回溯。

2. 高度可扩展

   • 一旦有 verifier，就可以用极少的人力标注，支持超大规模 RL 训练；
   • 对于数学/代码等领域尤其有利。

3. 更强的“真正能力提升”

   • 因为 reward 本身就是“任务解对没”，模型被直接逼着学会真正的推理，而不是只学会“讨好人类/奖励模型”。

现实局限：

1. 需要设计 verifier

   • 对很多开放任务，难以写出全面高质量的 verifier；
   • 即使用 LLM 作为 verifier，也会带来新的不确定性。

2. 容易忽略不可验证维度

   • 模型可能极善于“答对题”，但其他维度（礼貌、安全、多样性）被忽略；
   • 需要与 RLHF / RLAIF 或额外约束联合使用。

3. 二元 reward 的高方差问题

   • Reward 只有 0/1，会导致训练不稳定；
   • 需要 GRPO 等技巧缓解，或者设计更细致的 reward。

---

5. 实战示例：一个极简 RLVR 训练脚本（PyTorch 风格伪代码）

下面给一个极简化的 RLVR 训练示例，场景为：

做四则运算题：输入一个表达式，模型输出结果，reward=是否算对。

说明：

• 代码是伪代码（很多细节略去），主要展示 RLVR + GRPO 风格训练结构；
• 真正工程里需要接 HuggingFace / 自研框架的 LM，实现 sampling / logprob 计算等。

5.1 数据与环境设定

• 数据：一批 (prompt, answer) 样本，例如

  • prompt: "What is 123 + 456?"
  • answer: 579

• Verifier：解析模型输出中的最后一个整数，判断是否等于 answer。

# 简单的可验证 reward 函数示例
def extract_last_int(text: str):
    import re
    nums = re.findall(r"-?\d+", text)
    if not nums:
        return None
    return int(nums[-1])

def reward_math(prompt: str, completion: str, gold_answer: int) -> float:
    """
    一个极简 math RLVR 奖励函数:
    - 若能解析出最后一个整数且等于 gold_answer -> 1.0
    - 否则 -> 0.0
    """
    pred = extract_last_int(completion)
    if pred is None:
        return 0.0
    return 1.0 if pred == gold_answer else 0.0

5.2 GRPO 风格的优势计算

import torch

def compute_group_advantages(rewards: torch.Tensor, eps: float = 1e-8):
    """
    rewards: [batch_size, group_size]
    对每个 prompt 内部做标准化:
        A_ij = (r_ij - mean_j) / (std_j + eps)
    返回同 shape 的 advantages
    """
    # 按 group 维度做 mean / std
    mean = rewards.mean(dim=-1, keepdim=True)        # [B, 1]
    std = rewards.std(dim=-1, keepdim=True)          # [B, 1]
    advantages = (rewards - mean) / (std + eps)
    return advantages

5.3 完整训练伪代码

注意：这里的 PolicyLM / logprobs_from_model / sample_completions 都是占位，真实实现要接自己的模型。

import torch
from torch import nn
from torch.optim import Adam
from typing import List, Dict

class PolicyLM(nn.Module):
    """
    占位：真正实现需要封装一个语言模型，
    支持:
        - 根据 prompt 采样 completion
        - 计算给定 completion 的 logprob
    """
    def __init__(self, base_lm):
        super().__init__()
        self.lm = base_lm  # 假设是某个预训练 LM

    def forward(self, input_ids, attention_mask=None):
        return self.lm(input_ids=input_ids, attention_mask=attention_mask)

    # 伪接口: 采样多条 completion
    def generate(self, prompts: List[str], num_samples: int) -> List[List[str]]:
        """
        返回: completions[b][k] = 第 b 个 prompt 的第 k 条采样
        真正实现需要用到 beam search / sampling 等
        """
        raise NotImplementedError

    # 伪接口: 计算 completion 的 logprob
    def logprob(self, prompts: List[str], completions: List[List[str]]) -> torch.Tensor:
        """
        返回 logprobs: [batch_size, group_size]
        每个元素是该 completion 的总 logprob
        真正实现要 tokenize + teacher-forcing 计算
        """
        raise NotImplementedError


def rlvr_train_loop(
    policy: PolicyLM,
    ref_policy: PolicyLM,
    dataset: List[Dict],
    optimizer: Adam,
    group_size: int = 4,
    kl_beta: float = 0.02,
    num_iterations: int = 1000,
    batch_size: int = 8,
):
    """
    一个极简 RLVR + GRPO 风格训练 loop（伪代码）:
    - dataset: 每个元素类似 {"prompt": str, "answer": int}
    - group_size: 每个 prompt 采样多少条 completion (K)
    """
    policy.train()
    ref_policy.eval()  # 参考策略，一般不更新

    for it in range(num_iterations):
        # 1. 采样一个 batch 的 prompt
        batch = random_batch(dataset, batch_size)
        prompts = [b["prompt"] for b in batch]
        gold_answers = [b["answer"] for b in batch]

        # 2. 对每个 prompt，用当前策略采样 group_size 条 completion
        completions = policy.generate(prompts, num_samples=group_size)
        # completions: List[List[str]], shape [B][K]

        # 3. 计算 reward: [B, K]
        rewards_list = []
        for i, prompt in enumerate(prompts):
            ans = gold_answers[i]
            group_rewards = []
            for k in range(group_size):
                comp = completions[i][k]
                r = reward_math(prompt, comp, ans)  # 上面定义的 RLVR 奖励函数
                group_rewards.append(r)
            rewards_list.append(group_rewards)
        rewards = torch.tensor(rewards_list, dtype=torch.float32)  # [B, K]

        # 4. 计算 group-relative advantages
        advantages = compute_group_advantages(rewards)            # [B, K]

        # 5. 计算当前策略和参考策略的 logprob
        logprobs = policy.logprob(prompts, completions)           # [B, K]
        with torch.no_grad():
            ref_logprobs = ref_policy.logprob(prompts, completions)  # [B, K]

        # 6. 构造 per-sample KL (序列级别)
        kl = (logprobs - ref_logprobs)                            # [B, K]
        # 注意: 对自回归 LM，序列级 KL ≈ sum_t (log p_t - log p_ref_t)

        # 7. 构造被 KL penalty 调整后的 advantage
        #    R_ij = A_ij - kl_beta * KL_ij
        #    这里把 KL 直接减到 advantage 里，和 RLHF 常见做法类似
        adjusted_adv = advantages - kl_beta * kl                  # [B, K]

        # 8. policy gradient loss = - E[adjusted_adv * logprob]
        loss = -(adjusted_adv * logprobs).mean()

        optimizer.zero_grad()
        loss.backward()
        torch.nn.utils.clip_grad_norm_(policy.parameters(), 1.0)
        optimizer.step()

        if it % 50 == 0:
            avg_reward = rewards.mean().item()
            print(f"[iter {it}] loss={loss.item():.4f}, avg_reward={avg_reward:.4f}")

几点说明：

1. rewards 是纯 verifiable reward（0/1），来自 reward_math；
2. advantages 使用 GRPO 风格的 group 标准化；
3. kl = logprobs - ref_logprobs 是序列级 KL 的一种简化（更严格做法是 token 级）；
4. adjusted_adv = advantages - kl_beta * kl 等价于在 reward 中减去 KL penalty；
5. 整体结构非常接近 RLHF，只是奖励来源变成可验证程序。

真正落地时，还会加入：

• 长度奖励 / 惩罚（防止模型疯狂拉长 CoT）；
• Value function / critic 以降低方差；
• 对 KL 做 clipping / moving target；
• 复杂的采样策略（比如对困难样本加权）。

---

6. 工程落地建议：如何选 RLHF / RLAIF / RLVR

6.1 选型原则

可以用一个简单 checklist：

1. 能否写出一个“够用”的 verifier？

   • 如果可以（数学、代码、MCQA、形式化任务）→ 优先考虑 RLVR；
   • 如果完全写不出，只能基于主观审美 / 安全 / 风格 → 用 RLHF / RLAIF。

2. 人力标注预算如何？

   • 钱多且希望高质量 → RLHF + 少量 RLVR；
   • 钱少但有强老师模型 → RLAIF + RLVR。

3. 安全 / 价值观是否是核心目标？

   • 是：RLHF / RLAIF 仍是主角，RLVR 作为补充；
   • 否（主要追求任务正确率）：RLVR 可以成为主力。

4. 数据域是否稳定、规范？

   • 若有明确标准答案 / 协议 / 规范 → 更适合 RLVR；
   • 若 domain 经常变化且难以形式化 → 更适合 RLHF / RLAIF。

通常实际做法是：SFT +（RLHF / RLAIF）+ RLVR 组合拳。

6.2 常见坑与 Debug 思路

1. reward 崩坏 / 被 hack

   • 现象：模型学会“利用判分器 bug”而不是认真解题；
   • 对策：
     • 加入“反作弊”规则，如限制 format、禁止特定 pattern；
     • 对高 reward 的样本做人工审计；
     • 对判分逻辑做 fuzzing 测试。

2. 训练不收敛 / reward 卡在低值

   • 可能原因：
     • verifiable 任务太难，基础成功率接近 0；
     • group_size 太小，优势估计高噪声；
     • KL 过强导致几乎不更新。
   • 对策：
     • 提升 base 模型能力（更强 SFT / 更大模型）；
     • 先从简单子任务开始 RLVR（curriculum）；
     • 调小 KL 系数，增大 group_size。

3. 样本质量退化（虽然答对了）

   • 现象：答案正确但语言风格变差，或安全性下降；
   • 对策：
     • 在 RLVR 前或中间做 RLHF / RLAIF；
     • 把“格式、礼貌、安全”等维度也变成可验证规则（尽量形式化）。

---

7. 个人理解

7.1 RLVR 向开放任务扩展

最近的研究在试图解决一个核心问题：

“大部分现实任务都不是单一的 0/1 正确性，怎么把 RLVR 推到这些场景？”

典型方向包括：

• 生成式 verifier：用 LLM 作为评分器，但评分过程透明可审计；
• rubric-based reward：把复杂评价标准拆成多维 rubric（结构化），每一维都有可验证的规则集；
• multi-domain RLVR：在医学、心理学、教育、经济等领域构造 verifiable 任务和数据集；
• 情感和多轮对话的 RLVR：在 emotional response、empathy 等领域构建半可验证的打分器。

可以预见：
长期来看，RLVR 更像是一个“范式”，而不是某一个具体算法，
我们会不断增强“可以被程序验证的那一部分任务”。

7.2 与工具调用 / verifier 生态的结合

RLVR 和 tool use / agents 天然适配：

• 模型可以调用 calculator / code executor / API 来帮助自己“变得可验证”；
• 训练时的 verifier 也可以调用各种工具，如知识库、检索、符号计算；
• 未来更有可能出现一整套“verifier-as-a-service”基础设施。

从工程角度看：

• 训练端：RLVR 用工具做判分；
• 推理端：模型调用工具辅助推理；
• 二者共享部分组件，形成一个自洽的“可验证推理生态”。