做强化学习项目时最容易被卡住的往往不是网络结构也不是环境搭建而是“奖励函数怎么写”。很多入门教程默认你有一个能自动判断好坏的 Verifiable Reward也就是可验证奖励比如游戏得分、分类正确率、机械臂末端是否到达指定坐标可一旦换到对话生成、代码补全、教育推荐这些场景奖励根本没法用规则验证于是整个项目停在那里。最近经常能看到一个提法Reinforcement Learning without Verifiable Rewards翻译过来就是“强化学习无需可验证奖励”。它并不是说去掉奖励而是建议用偏好数据、过程监督、AI 反馈这些更松弛的信号替代严格可验证的奖励函数。这篇文章按 AI Engineer 的落地顺序拆一遍先理解可验证奖励为什么是门槛再讲替代路线怎么选然后给出一个能照着跑的实践流程最后整理判断清单和排查思路。1. 可验证奖励为什么是传统强化学习的“隐形门槛”1.1 可验证奖励与不可验证奖励的界限在哪“可验证奖励”字面意思是环境或程序能够自动、客观地计算出的奖励值。它具备几个特征规则明确、无需人工干预、计算快、可重复。典型例子包括围棋和电子游戏里的胜负或得分。分类模型在验证集上的准确率。代码生成模型能否编译、能否通过测试用例。机械臂末端是否进入目标区域。这些信号有一个共同点判断标准是外部规则而不是模型自己的感受。因此强化学习算法可以直接拿它做梯度更新几乎不需要额外标注成本。“不可验证奖励”则相反。比如“这段客服回复是否礼貌”“这条产品文案是否吸引人”“数学解题过程的推理是否清晰”。这些目标本身存在主观成分。不同的人可能有不同判断同一个评判者状态不同时也可能给出不同分数。传统强化学习里最常用的做法是人工设计一套规则打分例如“出现关键词加 1 分长度超过 50 字加 1 分”。这种做法看似解决了问题实际上只是把主观判断硬编码成规则模型很快会找到漏洞。在训练目标里可验证奖励和不可验证奖励的“验证成本”差异非常大。可验证奖励可以无限自动采样不可验证奖励往往需要人工标注或者借助裁判模型成本高一个数量级。这也是为什么很多 RL 项目从游戏 demo 迁移到真实业务时第一反应是“先想想怎么定义奖励”而不是“先改网络结构”。1.2 没有可验证奖励时为什么 PPO 这类算法容易崩PPO 是目前比较常用的策略梯度算法。它的基本思路是让策略在奖励信号引导下逐步提升。它本身不关心奖励来自哪里只关心奖励值。问题就出在这个“只关心奖励值”上。如果奖励信号不稳定、噪声大、范围不统一PPO 里比较关键的 advantage estimate 就会出现偏差。advantage 表示“当前动作比平均水平好多少”。当奖励本身忽高忽低时advantage 也会忽高忽低导致策略更新震荡。最典型的表现是训练初期 loss 下降很快继续训练后生成结果反而变差甚至输出空洞重复的内容。如果没有可验证奖励而强行手写规则还容易出现“奖励作弊”。模型并不理解你的语义它只会最大化数值。你给“包含关键词”加分它就反复堆关键词你给“长度超过 50 字”加分它就凑字数。这类问题不是调大 KL 惩罚系数就能完全解决的因为信号本身包含错误引导。注意不可验证的问题不是换个更复杂的规则公式就能解决。规则越复杂模型越可能找到让规则分数高但实际质量差的解。1.3 很多人对“无需可验证奖励”的误解“无需可验证奖励”听起来像是一种不需要任何监督信号的自监督方法。真实情况不是这样。它更像是一种“监督信号迁移”把原来的绝对分数信号替换成相对偏好、过程里程碑、模型评估结果等更容易获得的信号。一个相对经典的例子是 RLHF。它也会训练一个奖励模型但奖励模型的训练数据不是“给这句话打 0.7 分”而是“回答 A 比回答 B 更好”。人比较容易做比较不容易给绝对分数。所以“没有可验证奖励”的第一步往往就是“使用相对偏好而不是绝对分数”。理解这个区别之后路线就清晰了。下面要做的不是去发明一个复杂规则奖励而是设计一个新的信号来源再接入现有 RL 算法或直接做偏好优化。2. 可落地的三类替代信号偏好、过程反馈、模型反馈2.1 偏好信号人类比较比绝对评分更稳偏好信号是目前工程上最常用的替代方案。它的数据形式很简单同一个 prompt 下有两个回答 A 和 B标注者判断 A 好还是 B 好。不需要回答“A 比 B 好多少”只需要相对顺序。为什么相对顺序更稳因为人在做绝对评分时标准不稳定。今天觉得 4 分不错明天觉得 3 分也行但“A 比 B 更好”这件事只要差距不是太微弱通常更容易达成一致。标注成本和噪声都会下降。有了偏好数据之后有两种接法。第一种是训练一个奖励模型输出标量分数然后用 PPO 等算法训练策略。第二种是直接使用偏好优化算法比如 DPO把奖励模型的训练和策略更新合并在一起。这里有一个实操建议如果只是想把模型输出调得更符合用户偏好先收集小批量偏好对用 DPO 跑通第一个版本。这样不需要训练一个额外的奖励模型也不需要在线生成大量 rollout部署成本和显存占用都低一些。2.2 过程奖励把不可验证的最终目标拆成中间里程碑有些任务的最终结果很难验证但中间过程可以设置里程碑。比如机械臂强化学习实战中目标“把物体稳稳放入箱子”很难用规则衡量因为需要同时考虑位置、姿态、接触力。但过程可以拆成多个阶段末端接近目标、夹爪张开、夹取成功、移动到目标上方、释放。在每个阶段设置一个二元标志位给一个中间奖励这就是过程奖励Process Reward Model的思路。它的价值在于缓解稀疏奖励和延迟反馈。模型不再需要探索很久才知道“刚才哪个动作有效”而是每个阶段都能得到反馈。不过过程奖励并不等于“想当然地把最终目标拆成几步”。每一步的判断仍需尽量客观。比如“夹爪是否夹住物体”可以用力传感器或视觉检测“是否到达目标上方”可以用坐标范围判断。如果某一步仍然靠人眼判断它还是不可验证的只是粒度细了噪声变小了。过程奖励在数学解题和代码生成里也很常见。模型输出中的每个中间步骤都可以由裁判模型或规则检查器给出反馈。它不是取代“最终答案是否正确”的验证而是给学习过程增加更多监督点。2.3 用预训练模型当裁判RLAIF 的工程套路RLAIF 的做法是让一个预训练大模型充当奖励模型或裁判模型对候选输出进行对比或打分。这样就能扩大偏好数据的规模减少人工标注成本。在文本生成类任务中这是一个很自然的落地点。实际使用时我一般会让裁判模型只输出“A 好、B 好、平局、无效”中的一个选项而不是直接输出一个连续分值。原因是连续分值更容易受长度、格式、重复度等表面因素干扰而比较式判断只要模板设计得当稳定性会好一些。对每条样本我会把 A/B 顺序随机交换让裁判模型判断两次或三次最后按多数投票决定最终偏好。需要注意裁判模型并不是“真实答案”。它可能带有自己的偏好比如偏好更长文本、偏好某种行文风格。因此在使用 RLAIF 时必须留出一部分人工抽查数据定期检查裁判模型排序和人类判断的一致性。如果一致性低于某个阈值就要调整裁判模板或换裁判模型而不是盲目扩大训练数据。3. 不使用可验证奖励时的最小训练流程3.1 先准备一个最小可运行的数据和模型我建议第一次实验不要做太复杂。先准备 50 到 100 条 prompt用同一个模型生成两条候选回答然后用一条规则或一个人工标注出偏好。数据格式可以按常见的 JSONL 组织{prompt: 请用一句话向新手解释什么是强化学习, chosen: 强化学习是让智能体通过试错改善策略的方法。, rejected: RL is a type of machine learning.} {prompt: 写一句新品咖啡的推广文案, chosen: 清晨一杯唤醒你的专注力。, rejected: 这款咖啡很好喝推荐大家购买。}数据量少没关系重点是先把“数据格式、模型加载、训练脚本、输出保存”这条链路跑通。在代码里核心流程是读取数据、分词、组织成样本、加载模型、传入训练器、保存 checkpoint。这里的常见问题是把 prompt 和 response 混在一起处理导致输入长度超限或标签错位。如果你用的是 DPOchosen 和 rejected 必须基于同一个 prompt且两个回答长度不能相差过大。最好在数据预处理阶段记录样本的 token 长度过滤掉过长或过短的样本。3.2 先 DPO 快速启动而不是一上来就 PPO在“没有可验证奖励”的场景里DPO 的吸引力很明显不需要训练奖励模型。不需要在线 rollout 生成和经验回放。只需要一份离线偏好数据。代码实现简单显存占用低。如果直接用 PPO即使你把奖励模型换成预训练大模型仍要处理 rollout 生成、advantage 估计、策略更新和旧策略采样之间的同步。这个工程复杂度对第一次做的人并不友好。从个人经验看先用 DPO 跑通一个版本确认数据信号有效再决定要不要切换到 PPO。很多任务到 DPO 就够用了。如果发现策略改进不明显或者需要模型有更强的探索能力再考虑 PPO 加奖励模型。为了更好做选型这里给一个简单对比训练路线是否训练奖励模型是否需要在线交互数据要求适合场景PPO 奖励模型是是大量 prompt 和奖励信号探索空间大、需要在线采样DPO否否同一 prompt 下的偏好对离线数据充分、启动快RLAIF PPO用大模型裁判替代通常需要prompt 和 AI 生成的候选降低人工标注成本3.3 训练参数和资源预估训练参数需要按模型规模调整下面给的是通用起点实际要看你自己的机器。使用 7B 级别模型时LoRA rank 16 到 32学习率在 1e-6 到 5e-5 范围batch size 先不要大。如果需要控制输出风格可以在训练目标里加一点 KL 项避免策略偏离基座模型太远。显存可以先按这个思路估算7B 模型做 LoRA 训练常见是 16GB 到 24GB 可以跑如果使用 13B 或更大模型需要更大显存或用量化。这个数字只是经验范围不是官方结论落地时最好用一个小 batch 先试一次 forward 和 backward。数据量方面几百条偏好对往往能看到初步变化要做到稳定可能需要几千条甚至更多。如果只有几十条不建议直接训练完整模型建议先做规则筛选或人工质量检查确保样本质量高。建议第一次做先用 200 条偏好对跑通 DPO。先把链路跑通再扩到 2000 条。不要一开始就把并发、batch、长文本全部拉满。3.4 验证环节不要只看 loss在 RL 类训练里训练 loss 和真实质量并不是简单对应关系。我见过训练 loss 一路下降但生成样本质量反而变差的情况。原因是模型找到了“让裁判模型开心”的模式但这与真实用户需求不一致。所以我通常会在训练前预留一组固定 prompt作为验证 prompt。训练过程中每隔几个 checkpoint用这批 prompt 生成固定数量的回答人工查看几条和训练前的 baseline 对比。验证项不需要多但必须覆盖核心任务类型。判断标准可以这样设是否出现明显重复、空洞、短句堆砌。是否偏离原有基座模型的常识能力。偏好数据中 chosen 回答是否真的比 rejected 回答质量高。模型是否能稳定保持 prompt 所要求的格式。如果上面任何一项出现问题不要急着加训练轮数先检查数据和裁判模板。4. 判断清单什么项目适合绕开可验证奖励4.1 适合绕开的三种场景第一类主观质量为主没有唯一标准答案。比如聊天助手、文案生成、摘要、教育辅导。这类任务的“好”更多来自用户体验而不是规则。偏好数据或 AI 裁判都能给出有效信号。第二类最终目标明确但中间过程很灵活。例如机械臂抓取、机器人导航、游戏中的开放式探索。可以直接定义目标完成标志甚至不需要精密的连续奖励用过程里程碑加稀疏成功信号即可。第三类奖励难以手工构建但可以低成本获得人类对比结果。典型的如推荐结果排序、答案偏好排序。只要收集若干用户反馈或标注员偏好就能形成偏好对。4.2 不适合绕开的三种场景第一类有明确正确性标准且可以自动检查。比如代码要跑通测试用例数学题要与标准答案一致。这时候不用可验证奖励反而增加裁判模型的幻觉风险。你应该优先使用真实正确信号。第二类安全关键领域。比如自动驾驶决策、医疗治疗方案、金融授信。这类场景中“看起来不错”的偏好或 AI 裁判不够必须做严格的人审、对抗测试和冗余校验。如果只想绕过可验证奖励很可能埋下风险。第三类没有偏好数据也没有可靠的裁判模型同时离线数据里没有标注。这时候先不要做训练先去解决数据来源。把少量高质量标注先做出来比盲目套 DPO 重要得多。4.3 判断标准和验收指标一个项目能否绕开可验证奖励可以从四个问题判断有没有客观可计算的判断信号如果有优先把它当作主要奖励。有没有低成本获得偏好比较的渠道比如用户点赞、人工标注、大模型裁判。能不能拆出过程里程碑如果能训练稳定性会好很多。最终输出是否能接受人工抽查如果不能说明验证成本被低估了。验收指标不要只盯单一分数。建议同时看偏好数据中的裁判一致率。训练前后在固定 prompt 上的生成质量对比。是否出现 reward hacking 特征例如重复、长度暴涨、无关内容堆砌。策略多样性是否下降过多。如果一项指标异常就要回退到数据层和信号层而不是继续调学习率。5. 我实际踩过的坑和排查顺序5.1 reward hacking 怎么发现用偏好数据训练时最常见的 reward hacking 是模型学会了“迎合裁判模型”而不是“满足用户”。比如裁判模型模板里写“更好的回答应该包含详细解释”一段时间后模型开始输出很长但信息量很低的内容。训练 loss 没有明显异常检查时才发现输出文本平均长度暴涨。发现这个问题最快的方法是统计训练期间每个 checkpoint 在固定 prompt 上的输出长度、重复率、内容多样性。这些指标不需要复杂计算在验证脚本里加几行就能统计出来。一旦发现某个指标异常偏离 baseline就要怀疑奖励信号被钻了空子。5.2 训练不稳定时的排查顺序如果 loss 不降或者降得很快但生成质量变差我建议按下面顺序排查看数据。chosen 和 rejected 是否真的存在明确质量差异。有些偏好对只是风格不同不是优劣关系模型会学不到方向。看模板。裁判模型是否因为 A/B 顺序、长度、标点符号而产生偏好偏差。看基座。基座模型是否经过大量微调如果基座本身不稳定再做偏好优化容易崩塌。看训练参数。学习率过大会导致策略快速偏移batch size 过小会导致梯度噪声大。看验证结果。不要只看 loss要看固定 prompt 的实际回答。这里没有统一答案但顺序很重要。很多人一上来就调学习率最后发现是数据里把 chosen 和 rejected 标反了。5.3 资源不够时的降级方案如果显存有限有几种降级方法换更小的基座模型比如从 13B 降到 7B再用 LoRA。用量化加载模型牺牲一点精度换取更低显存。缩短最大输入长度。很多回答不需要 1024 token先跑通再逐步加长。减少验证 prompt 数量但保证覆盖各类任务。如果连小模型都跑不动可以先只做数据准备和裁判模板设计等有资源再训练。资源不足时最容易犯的错是不断压缩 batch size 和 max length导致有效训练样本太少。与其这样不如先用更小的模型把流程验证清楚再换大模型。另外如果离线数据没有奖励值只有一批回答不要直接当成 DPO 的数据来用。你需要先构造偏好对。一个可用的方法是让裁判模型对每条 prompt 的所有候选回答做两两比较挑出一个相对好的和一个相对差的组成偏好对。这个过程需要抽样多次不能只跑一次就认为排序可靠。绕开可验证奖励并不是什么黑魔法它等价于“换一种更合适的监督信号”。在文本生成、机械臂操作这类任务里偏好比较、过程里程碑、AI 裁判都是可落地的办法。真正要盯住的不是算法名字而是信号是否可靠、数据是否干净、验证是否持续。先跑通单条样本再确认偏好质量最后才放大训练这条路线会更稳。踩过几次之后我发现很多项目失败不是强化学习算法不够强而是从数据到信号的定义过程太粗糙。把这一层做扎实后面才会顺利。