入门强化学习时我们通常最先接触的是这样的公式智能体在环境中执行动作环境返回一个数值奖励智能体通过最大化累积奖励来学习策略。这个范式在游戏、机器人控制、推荐系统里非常成熟因为它有一个非常重要的前提——奖励是“可验证”的。但当任务变成“生成一段摘要”“写一句符合品牌调性的文案”“判断一段代码是否易读”时奖励就不那么客观了。没有标准答案没有明确的验证器甚至两个专家对同一个输出的评分都会不一致。这类任务恰恰是当前 AI Engineer 在落地大模型应用时最常遇到的。本文将围绕“强化学习无需可验证奖励”这一主题展开先讲清楚可验证奖励与非可验证奖励的本质差异再给出三套工程上可落地的替代方案奖励模型、偏好学习、过程奖励模型并提供一个可以运行的简化实战案例。读完你不仅能理解 RLHF 这一类方法背后的原理还能在自己的项目里搭出一套“无验证奖励也能训策略”的最小闭环。1. 背景当强化学习碰上“说不清好坏”的任务1.1 可验证奖励是什么先看一个对比。玩 Atari 游戏时游戏分数就是可验证奖励。模型输出一个动作环境立刻算出新的分数分数变化就是奖励。训练一个数学解题模型时如果模型给出最终答案我们可以拿答案和标准答案比对对错就是奖励。写代码场景中模型生成的代码能否通过单元测试也是一个明确的可验证奖励。这些例子的共同点是存在一个确定的、可程序化的验证函数输入状态和动作输出一个客观的奖励值。# 可验证奖励的典型形式 def verifiable_reward(response: str, ground_truth: str) - float: # 数学题回答与标准答案一致返回 1否则返回 0 return 1.0 if response.strip() ground_truth.strip() else 0.0可验证奖励的最大优势是稳定、低成本、可无限次重复。只要验证函数写得正确训练过程中不需要任何人参与奖励也不会漂移。这也是为什么在大模型推理能力训练中很多团队优先选择数学、代码这类可验证任务。1.2 为什么“没有可验证奖励”是常态问题在于真实业务里大量任务并不满足“存在确定验证函数”这个条件。例如让模型写一段产品介绍判断标准是“是否吸引人”“是否准确”“是否符合品牌语气”。这些标准主观且多维。再比如让模型润色一段新闻稿不同编辑会给出不同偏好甚至同一个人在不同时间点的判断都可能有差异。客服对话场景中“用户是否满意”本身就是一个需要推断的隐变量。这些任务的共同特征是人类能判断好坏但无法用一段脚本表达好坏。于是我们面临一个矛盾强化学习需要数值奖励而真实业务无法直接给出数值奖励。如果强行把业务目标压缩成一个可计算指标往往会出现“指标上去了业务没变好”的尴尬局面。这个现象在学术界和工业界有一个专门的名字——奖励黑客Reward Hacking也就是策略学会了钻奖励函数的空子而不是真正完成任务。1.3 本文要解决什么问题本文要解决的核心问题是当任务没有可验证奖励时如何为强化学习构建可靠的奖励信号。这不是一个理论问题而是一个工程问题。它涉及数据怎么采、模型怎么训、奖励怎么用、效果怎么验证。下面我们先梳理核心概念再逐步给出可落地的方案和代码。2. 核心概念奖励信号的三种来源要理解“无需可验证奖励”的强化学习需要先建立一个坐标系奖励信号到底从哪里来。2.1 环境规则可编程的验证器这是最理想的情况。环境自身携带目标函数比如游戏分数、电路仿真结果、模拟器回报。程序可以直接计算奖励不需要人类参与。但当任务转向自然语言、图像生成、内容质量等主观领域时环境规则往往无法覆盖真正的业务目标。即使你强行写一个可计算的指标它也只能是真实目标的近似近似就存在被利用的风险。2.2 奖励模型把主观评价变成标量既然人类能判断好坏我们能不能训练一个“评分员”模型来代替人类打分这就是奖励模型Reward Model的基本思路。我们用人类标注的数据训练一个模型让它学习人类偏好然后在强化学习阶段用这个模型代替真实奖励。奖励模型的好处是推理成本低、可以批量打分、可以反复使用。但它也有明显风险奖励模型本身有误差策略会专门寻找奖励模型的漏洞而不是做正确的事。这个风险不是理论上的而是实践中反复被验证过的。2.3 人类反馈最昂贵但最可靠的信号人类反馈是最原始的奖励来源。它的可靠性最高但成本也最高无法大规模标注而且标注一致性难以保证。因此现代工程实践通常采用“人类反馈 奖励模型”的组合方式先用少量高质量的人类反馈训练奖励模型再用奖励模型替代人类打分最后在关键节点引入人类审核来修正奖励模型。这条路线就是 RLHFReinforcement Learning from Human Feedback的雏形。小结一下奖励来源可靠性成本典型场景环境规则高低游戏、数学、代码测试奖励模型中中文本质量、审美、对话满意度人类反馈高高策略对齐、偏好校准3. 环境准备与工具链在进入实战之前我们先准备一套可以运行后续示例的环境。3.1 版本说明本文代码以 Python 3.10 为基础深度学习框架使用 PyTorch 2.x 系列。需要说明的是PyTorch 版本更新较快具体版本号请以你实际安装时的官方说明为准本文重点演示实现思路不绑定某个具体小版本。建议环境如下操作系统Linux 或 macOS 均可Windows 也可以运行但推荐 WSL 或云服务器Python3.10 或 3.11PyTorch2.xCPU 版本即可运行本文示例其他依赖numpy、datasets、tqdm如果你还没有安装 PyTorch可以使用官方安装命令生成符合本机环境的安装指令。为了快速验证思路这里不需要 GPU但如果要训练真实的奖励模型建议使用 GPU 环境。3.2 项目结构我们用一个简单的目录来组织代码rl_without_verifiable_rewards/ ├── data/ │ └── preference_data.jsonl ├── reward_model.py ├── train_reward_model.py ├── policy.py ├── train_policy.py └── utils.py本文后面所有代码都按照这个结构放置方便你对照路径理解。3.3 安装依赖创建一个虚拟环境并安装依赖python -m venv venv source venv/bin/activate pip install torch numpy tqdm4. 方案一训练奖励模型替代真实奖励先看第一个方案训练一个奖励模型用它为强化学习提供标量奖励信号。这是目前工程上最常用的做法。4.1 奖励模型的建模思路奖励模型本质上是一个回归模型输入一段文本或一个状态动作对输出一个标量分数分数越高表示质量越好。它的训练数据来自人类偏好。偏好数据的基本单元是一对样本同一个输入对应两个输出人类标注哪个更好。假设我们有输入 (x)、输出 (y_1) 和 (y_2)人类认为 (y_1) 优于 (y_2)那么奖励模型应该满足[ r(x, y_1) r(x, y_2) ]我们不需要人类给出绝对分数只需要相对比较。这正是偏好学习的关键思想绝对分数难以标相对比较容易达成一致。4.2 构造训练数据为了演示我们构造一个简单的偏好数据集。这里以“摘要质量”为例给定一段原文模型生成两个摘要人工标注哪个更流畅、更完整。数据格式采用 JSONL每一行是{ input: 原文文本..., chosen: 更好的摘要, rejected: 较差的摘要 }实际项目中这份数据需要由标注人员或用户反馈来生产。这里为了跑通流程我们可以临时用规则生成少量模拟数据。注意模拟数据只能用来验证代码流程不能代替真实数据。# utils.py import json import random def generate_demo_data(num_samples200): 生成模拟偏好数据仅用于流程演示 data [] for i in range(num_samples): topic f关于主题{i}的一段长文本描述了产品特性和使用场景。 good_summary f本文介绍了主题{i}的核心特性与适用场景内容简洁完整。 bad_summary f一些文字内容不太清晰。 data.append({ input: topic, chosen: good_summary, rejected: bad_summary }) return data def save_demo_data(pathdata/preference_data.jsonl, num_samples200): data generate_demo_data(num_samples) with open(path, w, encodingutf-8) as f: for item in data: f.write(json.dumps(item, ensure_asciiFalse) \n) print(f已生成 {num_samples} 条模拟偏好数据 - {path})4.3 奖励模型代码实现这里实现一个轻量级奖励模型。由于我们只是演示偏好建模的核心流程不使用大模型底座而是用 LSTM 对文本特征进行编码再接一个线性层输出分数。# reward_model.py import torch import torch.nn as nn class RewardModel(nn.Module): 简化版奖励模型输入 token 序列输出标量奖励 def __init__(self, vocab_size, hidden_size128, num_layers1): super().__init__() self.embedding nn.Embedding(vocab_size, hidden_size) self.lstm nn.LSTM(hidden_size, hidden_size, num_layers, batch_firstTrue) self.score_head nn.Linear(hidden_size, 1) def forward(self, input_ids, attention_maskNone): emb self.embedding(input_ids) out, _ self.lstm(emb) if attention_mask is not None: # 取每个序列最后一个有效位置的隐状态 lengths attention_mask.sum(dim1) - 1 batch_size input_ids.size(0) out out[torch.arange(batch_size), lengths] else: out out[:, -1, :] score self.score_head(out) return score.squeeze(-1)这里的关键点是奖励模型输出的是一个标量分数分数本身没有绝对含义我们只关心它对不同样本的相对排序。4.4 训练与验证训练奖励模型时我们使用对比损失。对于一对样本 ((x, y_{chosen})) 和 ((x, y_{rejected}))我们希望 chosen 的分数大于 rejected 的分数差距越大越好。这里使用的是 Bradley-Terry 模型的简化形式# train_reward_model.py import torch import torch.nn as nn from torch.utils.data import Dataset, DataLoader from reward_model import RewardModel def preference_loss(chosen_scores, rejected_scores): 偏好对比损失让 chosen 分数尽量高于 rejected 分数 logits chosen_scores - rejected_scores loss -torch.nn.functional.logsigmoid(logits).mean() return loss class PreferenceDataset(Dataset): def __init__(self, tokenized_data): self.data tokenized_data def __len__(self): return len(self.data[input_ids]) def __getitem__(self, idx): return { input_ids: torch.tensor(self.data[input_ids][idx]), chosen_ids: torch.tensor(self.data[chosen_ids][idx]), rejected_ids: torch.tensor(self.data[rejected_ids][idx]), }真实项目中你需要一个 tokenizer 将文本转成 token 序列这里略过词汇表构建细节。训练主循环如下model RewardModel(vocab_size5000) optimizer torch.optim.Adam(model.parameters(), lr1e-3) for epoch in range(3): for batch in dataloader: chosen_scores model(batch[chosen_ids]) rejected_scores model(batch[rejected_ids]) loss preference_loss(chosen_scores, rejected_scores) optimizer.zero_grad() loss.backward() optimizer.step() print(fepoch {epoch} loss: {loss.item():.4f})训练结束后奖励模型就可以对任意输入序列打分了。在强化学习阶段这个分数会被当作奖励信号传给策略优化器。5. 方案二基于偏好的强化学习RLHF/PbRL上面训练奖励模型的方法严格来说是“两步走”先训练奖励模型再在强化学习阶段使用它。现在很多大模型项目采用一种更直接的思路——不显式训练奖励模型而是直接从偏好数据中优化策略。这类方法统称为基于偏好的强化学习Preference-based RLPbRLRLHF 是它在人类反馈场景下的特例。5.1 Bradley-Terry 偏好模型Bradley-Terry 模型是偏好建模的经典工具。它的核心假设是每个候选都有一个“潜在强度”分数两个候选被选择的概率由它们的分数差决定。假设奖励模型输出分数为 (r(x, y))人类更喜欢 (y_1) 而不是 (y_2) 的概率被建模为[ P(y_1 \succ y_2 | x) \frac{\exp(r(x, y_1))}{\exp(r(x, y_1)) \exp(r(x, y_2))} ]这个概率形式就是 sigmoid 函数的作用对象因此训练目标可以写成最小化负对数似然即我们上一节代码中的 preference_loss。5.2 偏好数据与损失函数在 RLHF 框架中一般流程是用人类偏好数据训练一个奖励模型。用 PPO 等算法以奖励模型打分为奖励信号微调策略模型。训练过程中定期采样新的生成结果交给人类或奖励模型评估防止策略漂移。这里有一张简洁的流程示意人类偏好数据 ↓ 训练奖励模型 RM ↓ 强化学习PPO← RM 提供奖励 ↓ 更新策略模型 ↓ 采样新样本 → 定期回归人类评估这个过程比较重因为 PPO 的实现复杂度不低。幸运的是后来研究者提出了 DPODirect Preference Optimization它跳过了显式奖励模型直接用偏好数据优化策略。5.3 从偏好到策略优化DPO 的核心思想是不需要先训练一个奖励模型再把奖励反馈给策略而是把“偏好”直接转化为策略的优化目标。它的损失函数形式上可以理解为让策略尽可能提高被偏好样本的概率同时不要偏离参考策略太远。这是一个示意图真实的 DPO 损失涉及参考策略的 KL 散度项# dpo_loss.py 思路示意 def dpo_loss(policy_logps, ref_logps, chosen_mask, rejected_mask, beta0.1): policy_logps: 当前策略对样本的对数概率 ref_logps: 参考策略对样本的对数概率 beta: KL 散度正则系数 chosen_policy policy_logps[chosen_mask].sum(-1) chosen_ref ref_logps[chosen_mask].sum(-1) rejected_policy policy_logps[rejected_mask].sum(-1) rejected_ref ref_logps[rejected_mask].sum(-1) log_ratio_chosen chosen_policy - chosen_ref log_ratio_rejected rejected_policy - rejected_ref loss -torch.nn.functional.logsigmoid( beta * (log_ratio_chosen - log_ratio_rejected) ).mean() return loss这段代码是 DPO 损失的核心骨架。它没有显式训练奖励模型而是利用“当前策略与参考策略的概率比值”来隐式表达偏好。对于 AI Engineer 来说DPO 最大的吸引力在于训练复杂度低、资源消耗小在很多场景下效果接近甚至超过 PPO。但需要注意DPO 对数据质量要求很高偏好数据里的噪声会直接传导到策略优化过程不像 PPO 那样有一个独立的奖励模型做缓冲。6. 方案三过程奖励模型PRM6.1 结果奖励的局限在数学推理、代码生成这类任务中即使存在可验证的最终答案我们依然可能遇到一个问题最终答案对了但推理过程有严重错误。以数学题为例模型可能写了一段完全无关的中间推导最后蒙对一个答案。如果只根据最终答案给奖励模型就会学到“乱推导但碰巧答案对”的行为。这种现象在复杂推理任务中非常常见。更关键的是很多业务场景根本没有最终答案只有一步步的执行过程。比如让 AI 操作浏览器下单最终“下单成功”这个结果可能因为页面变化而无法准确判断但每一步“是否点击了正确的按钮”是可以评估的。6.2 过程奖励如何打分过程奖励模型Process Reward ModelPRM的思路是不只看最终结果而是对每个中间步骤分别打分。训练 PRM 需要的数据是步骤级别的标注给定一个推理过程每一步是否正确。然后奖励模型不再接收完整序列而是接收“当前已生成的步骤”输出这一步骤的质量分数。# process_reward.py 思路示意 class ProcessRewardModel(nn.Module): 过程奖励模型对每一步的隐状态打分 def __init__(self, base_model, hidden_size128): super().__init__() self.base_model base_model # 通常是一个 Transformer 底座 self.step_score_head nn.Linear(hidden_size, 1) def forward(self, step_hidden_states): # step_hidden_states: [batch, num_steps, hidden_size] scores self.step_score_head(step_hidden_states) # [batch, num_steps, 1] return scores.squeeze(-1)在训练阶段我们使用步骤级标签计算二分类或对比损失。在推理阶段将所有步骤的分数累加或加权得到整个轨迹的奖励。6.3 过程奖励的代码思路这里有一个重要的工程决策如何定义“步骤”。不同任务的步骤粒度不同。数学题的步骤可以是“每写一个等式”代码任务的步骤可以是“每完成一个函数”Agent 任务的步骤可以是“每次工具调用”。步骤定义越细标注成本越高但奖励信号越准确。实际项目中通常采用“适度粒度”原则先定义一个业务上可判定的最小动作单元而不是追求理论上的最优粒度。过程奖励的损失函数可以参考下面的伪代码def process_reward_loss(step_scores, step_labels): step_scores: 模型预测的每一步分数 [batch, num_steps] step_labels: 每一步是否正确 [batch, num_steps] (0/1) loss torch.nn.functional.binary_cross_entropy_with_logits( step_scores, step_labels.float() ) return loss相比结果奖励过程奖励能提供更密集的反馈信号缓解稀疏奖励问题。但它也有代价标注成本高、步骤定义难统一、奖励模型本身也可能出错。工程上通常把它与结果奖励结合使用。7. 完整实战无验证奖励下的文本生成策略优化下面我们把前面几节的内容串起来实现一个最小闭环在没有任何可验证奖励的情况下用一个奖励模型驱动策略梯度更新。这个示例做了大量简化目的是展示流程而不是追求 SoTA 效果。真实的大模型强化学习需要分布式训练、参考策略约束、KL 惩罚、大规模采样等复杂设计。7.1 任务定义我们定义一个简化的文本生成任务模型需要生成一句话人类偏好是“包含主题词并且长度适中”。这个偏好没有客观公式只能通过对比来定义。整个闭环分三步用模拟偏好数据训练奖励模型。用奖励模型为策略生成的样本打分。用策略梯度更新策略参数。7.2 训练奖励模型先复用第 4 节的数据构造和训练代码训练出一个 RewardModel。训练完成后保存模型权重torch.save(model.state_dict(), reward_model.pt)7.3 策略网络与策略梯度我们实现一个简单的策略网络它根据动作输出对应 token 的概率分布然后用 REINFORCE 算法更新。# policy.py import torch import torch.nn as nn class PolicyNetwork(nn.Module): 简化版策略网络输入状态输出动作分布 def __init__(self, state_dim, action_dim, hidden_size64): super().__init__() self.net nn.Sequential( nn.Linear(state_dim, hidden_size), nn.ReLU(), nn.Linear(hidden_size, action_dim), nn.Softmax(dim-1) ) def forward(self, state): return self.net(state)策略梯度的核心公式是用“动作的奖励”作为权重去放大或缩小对应动作的概率。当奖励来自奖励模型而不是环境时这个过程的本质不变。# train_policy.py import torch import torch.nn as nn from policy import PolicyNetwork def reinforce_update(policy, rewards, log_probs, optimizer): REINFORCE 更新奖励越高对应动作概率提升越明显 这里使用 (reward - baseline) 降低方差 baseline rewards.mean() advantages rewards - baseline loss -(log_probs * advantages).mean() optimizer.zero_grad() loss.backward() optimizer.step() return loss.item()为了让代码真正串联起来还需要一个完整的训练循环。示意如下policy PolicyNetwork(state_dim16, action_dim4) optimizer torch.optim.Adam(policy.parameters(), lr1e-3) reward_model load_reward_model(reward_model.pt) for epoch in range(50): states torch.randn(8, 16) # 模拟状态输入 probs policy(states) dist torch.distributions.Categorical(probs) actions dist.sample() log_probs dist.log_prob(actions) # 关键用奖励模型打分而不是环境给奖励 generated_seqs decode_actions(actions) # 伪代码把动作转成文本 rewards reward_model.score(generated_seqs) # 奖励模型打分 loss reinforce_update(policy, rewards, log_probs, optimizer) if epoch % 10 0: print(fepoch {epoch}, loss: {loss:.4f}, avg_reward: {rewards.mean():.4f})7.4 运行结果观察在这个简化例子里你会观察到几个现象初始阶段奖励分数较低且波动大因为策略还在随机探索。随着训练推进平均奖励逐渐上升说明策略学到了“高分样本对应动作”的分布。如果训练时间过长可能出现奖励高但实际质量下降的现象这就是奖励黑客的早期信号。最后一个现象尤其值得关注。它提醒我们奖励模型的分数只是真实偏好的近似策略优化会把近似误差放大。因此生产系统必须在训练过程中持续采样新数据、加入人类评估甚至定期重新训练奖励模型。8. 常见问题与排查思路在没有可验证奖励的强化学习项目中下面这些问题是高频出现的。我整理了它们的现象、原因和排查思路。问题现象常见原因解决思路奖励模型分数很高但人工评估效果差奖励模型过拟合标注数据学到了表面特征增加标注多样性做交叉验证定期人工抽样评估策略生成内容越来越单一策略“钻空子”集中生成奖励模型的盲区样本加入 KL 散度约束限制策略与参考模型偏离程度训练初期 loss 不下降偏好数据质量差标注噪声大清洗数据计算标注一致性提高数据质量奖励信号方差极大奖励模型没有规范化输出对奖励做标准化或使用 advantage 归一化人类偏好与奖励模型冲突奖励模型训练数据分布老化定期采集人类反馈迭代式重新训练奖励模型PPO 训练崩溃奖励模型打分不稳定或策略更新过大降低学习率增加 KL 惩罚系数增大采样批次过程奖励模型步骤粒度不一致步骤定义没有标准化建立步骤标注规范先小规模标注试运行排查时建议遵循以下顺序先检查数据偏好数据是否干净正负样本差异是否明显再检查奖励模型单独评估奖励模型的准确率和稳定性。最后检查策略训练看是否出现 reward hacking 的典型特征例如多样性下降、奖励曲线突增。9. AI Engineer 的工程最佳实践9.1 奖励信号架构设计没有可验证奖励不代表没有奖励信号。AI Engineer 要做的是把业务目标拆解成“可被人类或模型评估的信号层次”。一个常见的分层结构是第一层硬性规则信号。例如“是否包含敏感词”“是否超过最大长度”这类信号可以用程序判断。第二层弱监督信号。例如“是否包含关键业务实体”“是否符合基本格式”。第三层人类偏好信号。例如“表达是否自然”“观点是否清晰”这类信号交给奖励模型或直接用于偏好学习。不要一上来就用奖励模型替代所有信号。优先用规则把明显不合格的样本过滤掉再让奖励模型处理那些“规则无法区分”的样本。这样既降低了奖励模型的学习难度也减少了被攻击的面。9.2 防范奖励黑客奖励黑客是“无需可验证奖励”场景下最大的工程风险。常用防护手段包括KL 约束限制策略模型与参考模型的分布差距防止策略生成完全不自然的文本。奖励模型集成训练多个奖励模型取平均或取最小值降低单一模型的盲区被利用的概率。对抗性样本检测定期人工审视策略生成的高分样本找出奖励模型被骗的模式。标准答案验证对于存在部分可验证属性的任务保留规则验证器用来兜底。9.3 评估体系搭建没有可验证奖励时训练指标不能直接当评估指标。必须建立独立的评估集和评估流程离线评估固定一批测试输入记录策略输出用奖励模型和人工共同打分。在线评估在真实业务中做小流量 A/B 测试观察业务指标。定期回归记录历史策略的表现防止新策略在某个维度上回退。评估体系要尽量与训练奖励解耦。如果你用了奖励模型 A 做训练评估时最好引入人工判断或其他维度的指标避免“自己给自己打分”的循环论证。9.4 数据、标注与迭代这是“无需可验证奖励”路线里最容易被低估的部分。很多项目失败在算法之前先失败在数据上。建议从第一天就建立以下规范偏好标注必须有明确的指导手册说明“什么是更好”。每个样本至少两个人标注计算一致性不一致的样本要仲裁。数据按场景拆分成多个桶避免奖励模型被单一类型样本主导。记录标注时间、标注人员、样本来源方便回溯和分析。在实际项目中奖励模型的迭代频率通常高于策略模型。每当线上反馈出现新的失败模式就应该补充一批针对该模式的偏好数据重训奖励模型然后再做策略更新。10. 总结与学习路线本文围绕“强化学习无需可验证奖励”这个主题梳理了从问题本质到工程落地的一条完整链路。关键点回顾可验证奖励来自环境规则客观且低成本但很多真实业务不具备这个条件。没有可验证奖励时可以用奖励模型、偏好学习、过程奖励模型三种方案构建奖励信号。奖励模型把主观偏好映射成标量分数DPO 这类偏好学习跳过了显式奖励模型过程奖励模型为中间步骤提供密集反馈。工程落地的核心不是算法本身而是数据质量、奖励黑客防护和独立评估体系。如果你刚接触这个方向建议按下面的路线继续学习先吃透基础的策略梯度算法理解奖励信号如何驱动策略更新。再学习 Hugging Face TRL 库中 PPO、DPO 的实现和本文的简化代码做对照。然后用一个小规模开源偏好数据集完整跑一遍“奖励模型训练 策略优化”的流程。最后在真实业务中从规则信号叠加开始逐步引入奖励模型和人类反馈迭代。无验证奖励的强化学习并不是“没有奖励”而是把奖励的定义权从环境规则转移到了人类偏好和模型推断。谁能够更准确、更稳定地建模这份偏好谁就能让模型在那些“说不清楚好坏”的任务上持续进步。希望这篇文章能帮你把这个方向的第一段路走通。 无验证奖励的强化学习：奖励模型、偏好学习与PRM工程实践
入门强化学习时我们通常最先接触的是这样的公式智能体在环境中执行动作环境返回一个数值奖励智能体通过最大化累积奖励来学习策略。这个范式在游戏、机器人控制、推荐系统里非常成熟因为它有一个非常重要的前提——奖励是“可验证”的。但当任务变成“生成一段摘要”“写一句符合品牌调性的文案”“判断一段代码是否易读”时奖励就不那么客观了。没有标准答案没有明确的验证器甚至两个专家对同一个输出的评分都会不一致。这类任务恰恰是当前 AI Engineer 在落地大模型应用时最常遇到的。本文将围绕“强化学习无需可验证奖励”这一主题展开先讲清楚可验证奖励与非可验证奖励的本质差异再给出三套工程上可落地的替代方案奖励模型、偏好学习、过程奖励模型并提供一个可以运行的简化实战案例。读完你不仅能理解 RLHF 这一类方法背后的原理还能在自己的项目里搭出一套“无验证奖励也能训策略”的最小闭环。1. 背景当强化学习碰上“说不清好坏”的任务1.1 可验证奖励是什么先看一个对比。玩 Atari 游戏时游戏分数就是可验证奖励。模型输出一个动作环境立刻算出新的分数分数变化就是奖励。训练一个数学解题模型时如果模型给出最终答案我们可以拿答案和标准答案比对对错就是奖励。写代码场景中模型生成的代码能否通过单元测试也是一个明确的可验证奖励。这些例子的共同点是存在一个确定的、可程序化的验证函数输入状态和动作输出一个客观的奖励值。# 可验证奖励的典型形式 def verifiable_reward(response: str, ground_truth: str) - float: # 数学题回答与标准答案一致返回 1否则返回 0 return 1.0 if response.strip() ground_truth.strip() else 0.0可验证奖励的最大优势是稳定、低成本、可无限次重复。只要验证函数写得正确训练过程中不需要任何人参与奖励也不会漂移。这也是为什么在大模型推理能力训练中很多团队优先选择数学、代码这类可验证任务。1.2 为什么“没有可验证奖励”是常态问题在于真实业务里大量任务并不满足“存在确定验证函数”这个条件。例如让模型写一段产品介绍判断标准是“是否吸引人”“是否准确”“是否符合品牌语气”。这些标准主观且多维。再比如让模型润色一段新闻稿不同编辑会给出不同偏好甚至同一个人在不同时间点的判断都可能有差异。客服对话场景中“用户是否满意”本身就是一个需要推断的隐变量。这些任务的共同特征是人类能判断好坏但无法用一段脚本表达好坏。于是我们面临一个矛盾强化学习需要数值奖励而真实业务无法直接给出数值奖励。如果强行把业务目标压缩成一个可计算指标往往会出现“指标上去了业务没变好”的尴尬局面。这个现象在学术界和工业界有一个专门的名字——奖励黑客Reward Hacking也就是策略学会了钻奖励函数的空子而不是真正完成任务。1.3 本文要解决什么问题本文要解决的核心问题是当任务没有可验证奖励时如何为强化学习构建可靠的奖励信号。这不是一个理论问题而是一个工程问题。它涉及数据怎么采、模型怎么训、奖励怎么用、效果怎么验证。下面我们先梳理核心概念再逐步给出可落地的方案和代码。2. 核心概念奖励信号的三种来源要理解“无需可验证奖励”的强化学习需要先建立一个坐标系奖励信号到底从哪里来。2.1 环境规则可编程的验证器这是最理想的情况。环境自身携带目标函数比如游戏分数、电路仿真结果、模拟器回报。程序可以直接计算奖励不需要人类参与。但当任务转向自然语言、图像生成、内容质量等主观领域时环境规则往往无法覆盖真正的业务目标。即使你强行写一个可计算的指标它也只能是真实目标的近似近似就存在被利用的风险。2.2 奖励模型把主观评价变成标量既然人类能判断好坏我们能不能训练一个“评分员”模型来代替人类打分这就是奖励模型Reward Model的基本思路。我们用人类标注的数据训练一个模型让它学习人类偏好然后在强化学习阶段用这个模型代替真实奖励。奖励模型的好处是推理成本低、可以批量打分、可以反复使用。但它也有明显风险奖励模型本身有误差策略会专门寻找奖励模型的漏洞而不是做正确的事。这个风险不是理论上的而是实践中反复被验证过的。2.3 人类反馈最昂贵但最可靠的信号人类反馈是最原始的奖励来源。它的可靠性最高但成本也最高无法大规模标注而且标注一致性难以保证。因此现代工程实践通常采用“人类反馈 奖励模型”的组合方式先用少量高质量的人类反馈训练奖励模型再用奖励模型替代人类打分最后在关键节点引入人类审核来修正奖励模型。这条路线就是 RLHFReinforcement Learning from Human Feedback的雏形。小结一下奖励来源可靠性成本典型场景环境规则高低游戏、数学、代码测试奖励模型中中文本质量、审美、对话满意度人类反馈高高策略对齐、偏好校准3. 环境准备与工具链在进入实战之前我们先准备一套可以运行后续示例的环境。3.1 版本说明本文代码以 Python 3.10 为基础深度学习框架使用 PyTorch 2.x 系列。需要说明的是PyTorch 版本更新较快具体版本号请以你实际安装时的官方说明为准本文重点演示实现思路不绑定某个具体小版本。建议环境如下操作系统Linux 或 macOS 均可Windows 也可以运行但推荐 WSL 或云服务器Python3.10 或 3.11PyTorch2.xCPU 版本即可运行本文示例其他依赖numpy、datasets、tqdm如果你还没有安装 PyTorch可以使用官方安装命令生成符合本机环境的安装指令。为了快速验证思路这里不需要 GPU但如果要训练真实的奖励模型建议使用 GPU 环境。3.2 项目结构我们用一个简单的目录来组织代码rl_without_verifiable_rewards/ ├── data/ │ └── preference_data.jsonl ├── reward_model.py ├── train_reward_model.py ├── policy.py ├── train_policy.py └── utils.py本文后面所有代码都按照这个结构放置方便你对照路径理解。3.3 安装依赖创建一个虚拟环境并安装依赖python -m venv venv source venv/bin/activate pip install torch numpy tqdm4. 方案一训练奖励模型替代真实奖励先看第一个方案训练一个奖励模型用它为强化学习提供标量奖励信号。这是目前工程上最常用的做法。4.1 奖励模型的建模思路奖励模型本质上是一个回归模型输入一段文本或一个状态动作对输出一个标量分数分数越高表示质量越好。它的训练数据来自人类偏好。偏好数据的基本单元是一对样本同一个输入对应两个输出人类标注哪个更好。假设我们有输入 (x)、输出 (y_1) 和 (y_2)人类认为 (y_1) 优于 (y_2)那么奖励模型应该满足[ r(x, y_1) r(x, y_2) ]我们不需要人类给出绝对分数只需要相对比较。这正是偏好学习的关键思想绝对分数难以标相对比较容易达成一致。4.2 构造训练数据为了演示我们构造一个简单的偏好数据集。这里以“摘要质量”为例给定一段原文模型生成两个摘要人工标注哪个更流畅、更完整。数据格式采用 JSONL每一行是{ input: 原文文本..., chosen: 更好的摘要, rejected: 较差的摘要 }实际项目中这份数据需要由标注人员或用户反馈来生产。这里为了跑通流程我们可以临时用规则生成少量模拟数据。注意模拟数据只能用来验证代码流程不能代替真实数据。# utils.py import json import random def generate_demo_data(num_samples200): 生成模拟偏好数据仅用于流程演示 data [] for i in range(num_samples): topic f关于主题{i}的一段长文本描述了产品特性和使用场景。 good_summary f本文介绍了主题{i}的核心特性与适用场景内容简洁完整。 bad_summary f一些文字内容不太清晰。 data.append({ input: topic, chosen: good_summary, rejected: bad_summary }) return data def save_demo_data(pathdata/preference_data.jsonl, num_samples200): data generate_demo_data(num_samples) with open(path, w, encodingutf-8) as f: for item in data: f.write(json.dumps(item, ensure_asciiFalse) \n) print(f已生成 {num_samples} 条模拟偏好数据 - {path})4.3 奖励模型代码实现这里实现一个轻量级奖励模型。由于我们只是演示偏好建模的核心流程不使用大模型底座而是用 LSTM 对文本特征进行编码再接一个线性层输出分数。# reward_model.py import torch import torch.nn as nn class RewardModel(nn.Module): 简化版奖励模型输入 token 序列输出标量奖励 def __init__(self, vocab_size, hidden_size128, num_layers1): super().__init__() self.embedding nn.Embedding(vocab_size, hidden_size) self.lstm nn.LSTM(hidden_size, hidden_size, num_layers, batch_firstTrue) self.score_head nn.Linear(hidden_size, 1) def forward(self, input_ids, attention_maskNone): emb self.embedding(input_ids) out, _ self.lstm(emb) if attention_mask is not None: # 取每个序列最后一个有效位置的隐状态 lengths attention_mask.sum(dim1) - 1 batch_size input_ids.size(0) out out[torch.arange(batch_size), lengths] else: out out[:, -1, :] score self.score_head(out) return score.squeeze(-1)这里的关键点是奖励模型输出的是一个标量分数分数本身没有绝对含义我们只关心它对不同样本的相对排序。4.4 训练与验证训练奖励模型时我们使用对比损失。对于一对样本 ((x, y_{chosen})) 和 ((x, y_{rejected}))我们希望 chosen 的分数大于 rejected 的分数差距越大越好。这里使用的是 Bradley-Terry 模型的简化形式# train_reward_model.py import torch import torch.nn as nn from torch.utils.data import Dataset, DataLoader from reward_model import RewardModel def preference_loss(chosen_scores, rejected_scores): 偏好对比损失让 chosen 分数尽量高于 rejected 分数 logits chosen_scores - rejected_scores loss -torch.nn.functional.logsigmoid(logits).mean() return loss class PreferenceDataset(Dataset): def __init__(self, tokenized_data): self.data tokenized_data def __len__(self): return len(self.data[input_ids]) def __getitem__(self, idx): return { input_ids: torch.tensor(self.data[input_ids][idx]), chosen_ids: torch.tensor(self.data[chosen_ids][idx]), rejected_ids: torch.tensor(self.data[rejected_ids][idx]), }真实项目中你需要一个 tokenizer 将文本转成 token 序列这里略过词汇表构建细节。训练主循环如下model RewardModel(vocab_size5000) optimizer torch.optim.Adam(model.parameters(), lr1e-3) for epoch in range(3): for batch in dataloader: chosen_scores model(batch[chosen_ids]) rejected_scores model(batch[rejected_ids]) loss preference_loss(chosen_scores, rejected_scores) optimizer.zero_grad() loss.backward() optimizer.step() print(fepoch {epoch} loss: {loss.item():.4f})训练结束后奖励模型就可以对任意输入序列打分了。在强化学习阶段这个分数会被当作奖励信号传给策略优化器。5. 方案二基于偏好的强化学习RLHF/PbRL上面训练奖励模型的方法严格来说是“两步走”先训练奖励模型再在强化学习阶段使用它。现在很多大模型项目采用一种更直接的思路——不显式训练奖励模型而是直接从偏好数据中优化策略。这类方法统称为基于偏好的强化学习Preference-based RLPbRLRLHF 是它在人类反馈场景下的特例。5.1 Bradley-Terry 偏好模型Bradley-Terry 模型是偏好建模的经典工具。它的核心假设是每个候选都有一个“潜在强度”分数两个候选被选择的概率由它们的分数差决定。假设奖励模型输出分数为 (r(x, y))人类更喜欢 (y_1) 而不是 (y_2) 的概率被建模为[ P(y_1 \succ y_2 | x) \frac{\exp(r(x, y_1))}{\exp(r(x, y_1)) \exp(r(x, y_2))} ]这个概率形式就是 sigmoid 函数的作用对象因此训练目标可以写成最小化负对数似然即我们上一节代码中的 preference_loss。5.2 偏好数据与损失函数在 RLHF 框架中一般流程是用人类偏好数据训练一个奖励模型。用 PPO 等算法以奖励模型打分为奖励信号微调策略模型。训练过程中定期采样新的生成结果交给人类或奖励模型评估防止策略漂移。这里有一张简洁的流程示意人类偏好数据 ↓ 训练奖励模型 RM ↓ 强化学习PPO← RM 提供奖励 ↓ 更新策略模型 ↓ 采样新样本 → 定期回归人类评估这个过程比较重因为 PPO 的实现复杂度不低。幸运的是后来研究者提出了 DPODirect Preference Optimization它跳过了显式奖励模型直接用偏好数据优化策略。5.3 从偏好到策略优化DPO 的核心思想是不需要先训练一个奖励模型再把奖励反馈给策略而是把“偏好”直接转化为策略的优化目标。它的损失函数形式上可以理解为让策略尽可能提高被偏好样本的概率同时不要偏离参考策略太远。这是一个示意图真实的 DPO 损失涉及参考策略的 KL 散度项# dpo_loss.py 思路示意 def dpo_loss(policy_logps, ref_logps, chosen_mask, rejected_mask, beta0.1): policy_logps: 当前策略对样本的对数概率 ref_logps: 参考策略对样本的对数概率 beta: KL 散度正则系数 chosen_policy policy_logps[chosen_mask].sum(-1) chosen_ref ref_logps[chosen_mask].sum(-1) rejected_policy policy_logps[rejected_mask].sum(-1) rejected_ref ref_logps[rejected_mask].sum(-1) log_ratio_chosen chosen_policy - chosen_ref log_ratio_rejected rejected_policy - rejected_ref loss -torch.nn.functional.logsigmoid( beta * (log_ratio_chosen - log_ratio_rejected) ).mean() return loss这段代码是 DPO 损失的核心骨架。它没有显式训练奖励模型而是利用“当前策略与参考策略的概率比值”来隐式表达偏好。对于 AI Engineer 来说DPO 最大的吸引力在于训练复杂度低、资源消耗小在很多场景下效果接近甚至超过 PPO。但需要注意DPO 对数据质量要求很高偏好数据里的噪声会直接传导到策略优化过程不像 PPO 那样有一个独立的奖励模型做缓冲。6. 方案三过程奖励模型PRM6.1 结果奖励的局限在数学推理、代码生成这类任务中即使存在可验证的最终答案我们依然可能遇到一个问题最终答案对了但推理过程有严重错误。以数学题为例模型可能写了一段完全无关的中间推导最后蒙对一个答案。如果只根据最终答案给奖励模型就会学到“乱推导但碰巧答案对”的行为。这种现象在复杂推理任务中非常常见。更关键的是很多业务场景根本没有最终答案只有一步步的执行过程。比如让 AI 操作浏览器下单最终“下单成功”这个结果可能因为页面变化而无法准确判断但每一步“是否点击了正确的按钮”是可以评估的。6.2 过程奖励如何打分过程奖励模型Process Reward ModelPRM的思路是不只看最终结果而是对每个中间步骤分别打分。训练 PRM 需要的数据是步骤级别的标注给定一个推理过程每一步是否正确。然后奖励模型不再接收完整序列而是接收“当前已生成的步骤”输出这一步骤的质量分数。# process_reward.py 思路示意 class ProcessRewardModel(nn.Module): 过程奖励模型对每一步的隐状态打分 def __init__(self, base_model, hidden_size128): super().__init__() self.base_model base_model # 通常是一个 Transformer 底座 self.step_score_head nn.Linear(hidden_size, 1) def forward(self, step_hidden_states): # step_hidden_states: [batch, num_steps, hidden_size] scores self.step_score_head(step_hidden_states) # [batch, num_steps, 1] return scores.squeeze(-1)在训练阶段我们使用步骤级标签计算二分类或对比损失。在推理阶段将所有步骤的分数累加或加权得到整个轨迹的奖励。6.3 过程奖励的代码思路这里有一个重要的工程决策如何定义“步骤”。不同任务的步骤粒度不同。数学题的步骤可以是“每写一个等式”代码任务的步骤可以是“每完成一个函数”Agent 任务的步骤可以是“每次工具调用”。步骤定义越细标注成本越高但奖励信号越准确。实际项目中通常采用“适度粒度”原则先定义一个业务上可判定的最小动作单元而不是追求理论上的最优粒度。过程奖励的损失函数可以参考下面的伪代码def process_reward_loss(step_scores, step_labels): step_scores: 模型预测的每一步分数 [batch, num_steps] step_labels: 每一步是否正确 [batch, num_steps] (0/1) loss torch.nn.functional.binary_cross_entropy_with_logits( step_scores, step_labels.float() ) return loss相比结果奖励过程奖励能提供更密集的反馈信号缓解稀疏奖励问题。但它也有代价标注成本高、步骤定义难统一、奖励模型本身也可能出错。工程上通常把它与结果奖励结合使用。7. 完整实战无验证奖励下的文本生成策略优化下面我们把前面几节的内容串起来实现一个最小闭环在没有任何可验证奖励的情况下用一个奖励模型驱动策略梯度更新。这个示例做了大量简化目的是展示流程而不是追求 SoTA 效果。真实的大模型强化学习需要分布式训练、参考策略约束、KL 惩罚、大规模采样等复杂设计。7.1 任务定义我们定义一个简化的文本生成任务模型需要生成一句话人类偏好是“包含主题词并且长度适中”。这个偏好没有客观公式只能通过对比来定义。整个闭环分三步用模拟偏好数据训练奖励模型。用奖励模型为策略生成的样本打分。用策略梯度更新策略参数。7.2 训练奖励模型先复用第 4 节的数据构造和训练代码训练出一个 RewardModel。训练完成后保存模型权重torch.save(model.state_dict(), reward_model.pt)7.3 策略网络与策略梯度我们实现一个简单的策略网络它根据动作输出对应 token 的概率分布然后用 REINFORCE 算法更新。# policy.py import torch import torch.nn as nn class PolicyNetwork(nn.Module): 简化版策略网络输入状态输出动作分布 def __init__(self, state_dim, action_dim, hidden_size64): super().__init__() self.net nn.Sequential( nn.Linear(state_dim, hidden_size), nn.ReLU(), nn.Linear(hidden_size, action_dim), nn.Softmax(dim-1) ) def forward(self, state): return self.net(state)策略梯度的核心公式是用“动作的奖励”作为权重去放大或缩小对应动作的概率。当奖励来自奖励模型而不是环境时这个过程的本质不变。# train_policy.py import torch import torch.nn as nn from policy import PolicyNetwork def reinforce_update(policy, rewards, log_probs, optimizer): REINFORCE 更新奖励越高对应动作概率提升越明显 这里使用 (reward - baseline) 降低方差 baseline rewards.mean() advantages rewards - baseline loss -(log_probs * advantages).mean() optimizer.zero_grad() loss.backward() optimizer.step() return loss.item()为了让代码真正串联起来还需要一个完整的训练循环。示意如下policy PolicyNetwork(state_dim16, action_dim4) optimizer torch.optim.Adam(policy.parameters(), lr1e-3) reward_model load_reward_model(reward_model.pt) for epoch in range(50): states torch.randn(8, 16) # 模拟状态输入 probs policy(states) dist torch.distributions.Categorical(probs) actions dist.sample() log_probs dist.log_prob(actions) # 关键用奖励模型打分而不是环境给奖励 generated_seqs decode_actions(actions) # 伪代码把动作转成文本 rewards reward_model.score(generated_seqs) # 奖励模型打分 loss reinforce_update(policy, rewards, log_probs, optimizer) if epoch % 10 0: print(fepoch {epoch}, loss: {loss:.4f}, avg_reward: {rewards.mean():.4f})7.4 运行结果观察在这个简化例子里你会观察到几个现象初始阶段奖励分数较低且波动大因为策略还在随机探索。随着训练推进平均奖励逐渐上升说明策略学到了“高分样本对应动作”的分布。如果训练时间过长可能出现奖励高但实际质量下降的现象这就是奖励黑客的早期信号。最后一个现象尤其值得关注。它提醒我们奖励模型的分数只是真实偏好的近似策略优化会把近似误差放大。因此生产系统必须在训练过程中持续采样新数据、加入人类评估甚至定期重新训练奖励模型。8. 常见问题与排查思路在没有可验证奖励的强化学习项目中下面这些问题是高频出现的。我整理了它们的现象、原因和排查思路。问题现象常见原因解决思路奖励模型分数很高但人工评估效果差奖励模型过拟合标注数据学到了表面特征增加标注多样性做交叉验证定期人工抽样评估策略生成内容越来越单一策略“钻空子”集中生成奖励模型的盲区样本加入 KL 散度约束限制策略与参考模型偏离程度训练初期 loss 不下降偏好数据质量差标注噪声大清洗数据计算标注一致性提高数据质量奖励信号方差极大奖励模型没有规范化输出对奖励做标准化或使用 advantage 归一化人类偏好与奖励模型冲突奖励模型训练数据分布老化定期采集人类反馈迭代式重新训练奖励模型PPO 训练崩溃奖励模型打分不稳定或策略更新过大降低学习率增加 KL 惩罚系数增大采样批次过程奖励模型步骤粒度不一致步骤定义没有标准化建立步骤标注规范先小规模标注试运行排查时建议遵循以下顺序先检查数据偏好数据是否干净正负样本差异是否明显再检查奖励模型单独评估奖励模型的准确率和稳定性。最后检查策略训练看是否出现 reward hacking 的典型特征例如多样性下降、奖励曲线突增。9. AI Engineer 的工程最佳实践9.1 奖励信号架构设计没有可验证奖励不代表没有奖励信号。AI Engineer 要做的是把业务目标拆解成“可被人类或模型评估的信号层次”。一个常见的分层结构是第一层硬性规则信号。例如“是否包含敏感词”“是否超过最大长度”这类信号可以用程序判断。第二层弱监督信号。例如“是否包含关键业务实体”“是否符合基本格式”。第三层人类偏好信号。例如“表达是否自然”“观点是否清晰”这类信号交给奖励模型或直接用于偏好学习。不要一上来就用奖励模型替代所有信号。优先用规则把明显不合格的样本过滤掉再让奖励模型处理那些“规则无法区分”的样本。这样既降低了奖励模型的学习难度也减少了被攻击的面。9.2 防范奖励黑客奖励黑客是“无需可验证奖励”场景下最大的工程风险。常用防护手段包括KL 约束限制策略模型与参考模型的分布差距防止策略生成完全不自然的文本。奖励模型集成训练多个奖励模型取平均或取最小值降低单一模型的盲区被利用的概率。对抗性样本检测定期人工审视策略生成的高分样本找出奖励模型被骗的模式。标准答案验证对于存在部分可验证属性的任务保留规则验证器用来兜底。9.3 评估体系搭建没有可验证奖励时训练指标不能直接当评估指标。必须建立独立的评估集和评估流程离线评估固定一批测试输入记录策略输出用奖励模型和人工共同打分。在线评估在真实业务中做小流量 A/B 测试观察业务指标。定期回归记录历史策略的表现防止新策略在某个维度上回退。评估体系要尽量与训练奖励解耦。如果你用了奖励模型 A 做训练评估时最好引入人工判断或其他维度的指标避免“自己给自己打分”的循环论证。9.4 数据、标注与迭代这是“无需可验证奖励”路线里最容易被低估的部分。很多项目失败在算法之前先失败在数据上。建议从第一天就建立以下规范偏好标注必须有明确的指导手册说明“什么是更好”。每个样本至少两个人标注计算一致性不一致的样本要仲裁。数据按场景拆分成多个桶避免奖励模型被单一类型样本主导。记录标注时间、标注人员、样本来源方便回溯和分析。在实际项目中奖励模型的迭代频率通常高于策略模型。每当线上反馈出现新的失败模式就应该补充一批针对该模式的偏好数据重训奖励模型然后再做策略更新。10. 总结与学习路线本文围绕“强化学习无需可验证奖励”这个主题梳理了从问题本质到工程落地的一条完整链路。关键点回顾可验证奖励来自环境规则客观且低成本但很多真实业务不具备这个条件。没有可验证奖励时可以用奖励模型、偏好学习、过程奖励模型三种方案构建奖励信号。奖励模型把主观偏好映射成标量分数DPO 这类偏好学习跳过了显式奖励模型过程奖励模型为中间步骤提供密集反馈。工程落地的核心不是算法本身而是数据质量、奖励黑客防护和独立评估体系。如果你刚接触这个方向建议按下面的路线继续学习先吃透基础的策略梯度算法理解奖励信号如何驱动策略更新。再学习 Hugging Face TRL 库中 PPO、DPO 的实现和本文的简化代码做对照。然后用一个小规模开源偏好数据集完整跑一遍“奖励模型训练 策略优化”的流程。最后在真实业务中从规则信号叠加开始逐步引入奖励模型和人类反馈迭代。无验证奖励的强化学习并不是“没有奖励”而是把奖励的定义权从环境规则转移到了人类偏好和模型推断。谁能够更准确、更稳定地建模这份偏好谁就能让模型在那些“说不清楚好坏”的任务上持续进步。希望这篇文章能帮你把这个方向的第一段路走通。