强化学习项目在真实业务里落地时第一个卡住团队的问题往往不是算法选型而是奖励函数怎么设计。很多入门教程都假设环境会自动返回一个明确的分数游戏赢了加 1输了减 1小车立住不倒就有持续回报。但 AI Engineer 面对的实际任务比如让大模型写出更贴心的回答、生成更符合品牌调性的文案、把一个多步骤任务拆解得更有条理并没有一个可以自动判定好坏的分数。这类任务的奖励信号不可验证强化学习要运行下去就必须换一条获取学习信号的路径。这篇文章围绕“没有可验证奖励时强化学习还能不能学、怎么学”展开。先解释可验证奖励的含义和边界再梳理 RLHF、RLAIF、DPO、过程监督等替代方案的核心原理然后给出一个最小的 DPO 训练示例最后整理失败模式、排查思路和工程落地清单。适合正在做 LLM 对齐、智能体工作流、推荐策略或者任何需要把用户反馈变成优化目标的 AI Engineer。1. 可验证奖励并不是强化学习的默认条件1.1 可验证奖励的定义与典型例子可验证奖励Verifiable Rewards指的是系统可以依据一个确定性规则不依赖人类主观判断直接计算出奖励数值。判断标准是外部的、程序化的奖励函数本身不需要被训练出来。典型例子包括数学题答案与标准答案是否一致代码提交能否通过预先编写的单元测试围棋、象棋、电子游戏对局是否获胜搜索推荐任务中用户是否点击或转化安全过滤任务中文本是否命中违规词表。这些场景的共同点是“对错可以被机器判定”。对 AI Engineer 来说这意味着奖励信号是免费的只要写清楚规则即可。数学推理和代码生成类强化学习之所以最近频繁出现根本原因就是这个结果可以被程序自动打分整个训练闭环不需要额外养一个评估模型。1.2 为什么“Verifiable Rewards”在大模型训练里被频繁提起最近一段时间数学推理和代码生成类任务频繁出现在强化学习公开案例中。原因并不神秘这类任务的结果可以被程序自动判定奖励函数不需要学习训练流程天然比 RLHF 简单很多。流程通常是让策略模型对一道数学题采样多个答案用规则判断对错把“正确”或“错误”作为奖励再用强化学习算法更新策略。这套流程被较多资料称为 RLVRReinforcement Learning with Verifiable Rewards。它的优势十分明显奖励不需要人工标注成本低奖励可复现同一答案在任何一次运行中得分一致没有奖励模型也就减少了一整类“奖励模型被钻空子”的问题。但要注意这套思路成立的前提是任务结果可以被自动判定。一旦把场景换成“这段回答是否更贴心”“这条文案是否符合品牌调性”外部裁判就不存在了奖励信号从“可验证”变成了“需要被近似”。1.3 不可验证奖励的典型场景与判断标准不可验证奖励通常出现在以下场景任务目标本身是主观判断比如回答质量、文案风格、友好程度结果没有唯一标准答案比如开放式问题、多步骤推理中的局部动作判断依赖长期效果比如用户满意度、复购率短时间无法获得判断成本太高比如每条样本都需要专家评审无法规模化。在这些场景里如果把奖励写死成一个公式往往会得到走捷径、钻空子的策略。奖励函数不是“没用”而是“写不准”。下面用一张表对比两类奖励维度可验证奖励不可验证奖励判定方式程序、规则自动判断人工评估或模型近似典型示例数学答案、单元测试、游戏胜负回答质量、文案风格、安全偏好奖励函数可以直接定义需要学习或近似常见训练路线RLVR、基于规则的奖励RLHF、RLAIF、DPO、过程监督主要风险奖励稀疏、奖励泄漏奖励模型偏差、奖励黑客、过优化判断一个任务能否使用可验证奖励有一个很实用的检查方法找两个有经验的工程师让他们独立判断同一条模型输出是否合格。如果两个人几乎总能给出相同结论这个任务有很大概率可以用规则做可验证奖励如果两个人经常争论那就必须走学习奖励信号的路线。2. 没有可验证奖励时强化学习的四条学习信号路线2.1 RLHF先训练奖励模型再优化策略RLHFReinforcement Learning from Human Feedback是目前最广为人知的替代方案。它的核心思路是人类无法给出精确分数但能给出相对偏好比如“回答 A 比回答 B 更好”。大量偏好数据可以训练出一个奖励模型让奖励模型去近似人类意图然后再用这个模型给策略打分。完整流程分四步收集一个问题或指令的多条候选回答让标注人员对候选回答做两两比较或排序用偏好数据训练一个奖励模型用 PPO 等策略优化算法让策略在该奖励模型下获得更高分数同时约束策略不要偏离原始 SFT 模型太远。奖励模型在常见实现中就是一个文本分类头输入是“问题 回答”输出一个标量分数。对于偏好对 (x, y_w, y_l)其中 y_w 是更优回答y_l 是更差回答训练损失通常写成L -log σ( r(x, y_w) - r(x, y_l) )这个损失的含义是让好回答的分数尽量高于差回答。差值越大sigma 值越接近 1损失越小。奖励模型本质上是在学习“什么叫做好”的排序而不是在拟合一个绝对分数。2.2 RLAIF用模型替代人类做偏好标注人类标注成本高是 RLHF 落地时最现实的瓶颈。RLAIFReinforcement Learning from AI Feedback的思路是用一个更强的模型来模拟人工判断对候选回答做偏好标注或逐项打分。工程上常见做法是编写一套判断规则让一个评分模型或大模型按照规则输出“A 更好”或“B 更好”然后把这些模型标注结果当作偏好数据继续走 RLHF 的后续流程。这里要注意RLAIF 不等于不需要人类。人类把判断标准浓缩进 prompt 规则里模型只是扩大了标注规模。评价模型的偏见会传递到奖励模型再传回策略模型所以需要在最终阶段保留人工抽样审核。实际项目中RLAIF 和人工标注经常混合使用人工只处理模型判断不自信的样本。2.3 DPO绕开奖励模型的直接偏好优化DPODirect Preference Optimization是另一条重要路线。它的核心洞察是RLHF 中的奖励模型和策略模型共享同一个语言模型底座因此可以把“最大化奖励 KL 约束”的优化目标改写成直接关于策略的偏好损失不需要显式训练奖励模型。DPO 的损失可以写成L_DPO -E[ log σ( β * log(πθ(y_w|x)/πref(y_w|x)) - β * log(πθ(y_l|x)/πref(y_l|x)) ) ]其中 πθ 是正在训练的策略πref 是冻结的参考模型。直观理解如果策略让好回答的概率相对参考模型上升得越多同时让差回答的概率上升得越少损失就越小。DPO 对 AI Engineer 的工程价值非常大因为它把强化学习问题简化成了数据工程问题不需要在线采样训练数据和普通 SFT 数据一样是静态的不需要单独的奖励模型省了一套模型的训练和部署不需要实现 PPO 那样的 critic、advantage、buffer 等组件。代价是它的表达能力受限于离线数据。如果策略在训练中采样出了数据分布之外的新行为DPO 无法针对这些行为做实时反馈。2.4 过程监督不要只等最终结果很多任务的结果客观但过程长、中间步骤多最终奖励又稀疏。数学推理题可以只判最终答案对错但学生可能在第三步就走错方向机械臂任务可以只在到达目标时给加分但大部分时间它都在原地徘徊学不到任何梯度。过程监督Process Supervision的思路是不只对最终结果给奖励也对中间每一步给反馈告诉策略模型“这一步是不是朝着正确方向前进”。即使每一步没有客观分数也可以通过人工标注或模型判断来产生过程奖励。在机械臂强化学习实战中常见做法是设计势函数奖励potential-based reward shaping给“靠近目标位置”的行为一个渐进奖励而不是只在终点给一次性奖励。这类奖励并非严格可验证但它的信号密度高能显著降低探索难度。工程上的原则是奖励可以稠密但要保证“更接近目标”的方向和势函数方向一致否则会引导策略走上错误路径。3. 落地时需要设计的数据、模型和训练组件3.1 数据格式决定后续所有环节没有可验证奖励时学习信号最终都会落到数据上。常见的数据格式有三种数据格式标注成本适合算法说明偏好对chosen / rejected较低RLHF 奖励模型、DPO标注者只需要做二选一排序ranking中奖励模型排序损失多候选回答排序信息量大于单对打分rating较高回归型奖励模型需要标注者给出绝对分一致性容易受主观影响工程上最推荐的是先做偏好对。原因有两个一是标注者做相对比较比做绝对打分更容易保持一致二是偏好对同时支持奖励模型训练和 DPO。真正的难点不在格式而在数据质量chosen 和 rejected 之间的差异要足够明显差异太小会让模型学不到有效边界prompt 的分布要和线上请求一致否则训练的是“别人的任务”。3.2 奖励模型的结构、训练与评估奖励模型在结构上通常复用语言模型在最后一层加一个线性头输出标量。输入是 prompt 和回答拼接后的序列输出是一个分数。训练时用偏好数据计算 pairwise ranking loss。训练完成后评估不能只看损失下降还要在 held-out 偏好集上计算准确率。这里有一个很重要的实践人工抽样检查奖励模型对“长度”“格式”“关键词”等无关特征的依赖。如果奖励模型发现只要回答更长就加分那么策略模型会很快学会输出冗长但空洞的文本这就是典型的奖励黑客。3.3 策略优化算法选型PPO、DPO、GRPO 怎么选算法选型取决于团队能投入多少工程成本。下面按复杂度和适用场景整理算法是否需要奖励模型是否需要在线采样工程复杂度适用场景DPO否否低偏好数据充足团队刚起步RLHF PPO是是高需要持续迭代数据追求稳定上线GRPO否但需要评分信号是中奖励可自动计算或可用规则评分离线强化学习如 IQL不强依赖在线奖励否中只有历史日志数据无法在线交互GRPO 近期的流行和可验证奖励密切相关它对同一 question 采样多组输出用组内相对好的输出作为正例不需要训练 critic 网络。如果奖励来自外部规则GRPO 会让工程链路明显变短。3.4 KL 约束和参考模型为什么不能省无论走 RLHF 还是 DPO参考模型reference model和 KL 约束都不能省。原因是奖励模型只是真实偏好的近似策略模型如果被允许无限远离初始分布就会专门去钻奖励模型的盲区。RLHF 的标准优化目标可以写成max E[ r_φ(x, y) ] - β * KL(πθ(y|x) || πref(y|x))第一项是追求奖励模型高分第二项是惩罚策略偏离参考模型。β 越大策略越保守越接近参考分布β 越小策略越激进越容易过优化。实践中 β 通常从 0.01 到 0.5 之间调整推荐先做小范围网格搜索观察奖励模型分数和人工评估分两条曲线的背离点。4. 最小可运行示例用 DPO 训练一个偏好对齐模型这一节给出一个最简的可运行示例目的是让不熟悉 DPO 的读者先跑通流程再决定是否进入 RLHF 和 PPO。4.1 环境准备与依赖示例使用 Hugging Face 生态的 transformers、datasets 和 TRL。先创建虚拟环境并安装依赖python -m venv .venv source .venv/bin/activate pip install torch transformers datasets trl peft accelerate版本约束以当前官方文档为准。示例代码只演示流程实际项目要根据本地 CUDA、显存和模型情况调整。4.2 构造偏好数据集DPO 训练集需要三个字段prompt指令、chosen更优回答、rejected更差回答。这里刻意构造两条数据from datasets import Dataset data { prompt: [ 请用一句话解释什么是强化学习中的奖励函数。, 给领导写一封简短的请假邮件。, ], chosen: [ 奖励函数是环境或评估者反馈给智能体的数值信号用来衡量当前动作的好坏。, 领导您好我明天因个人事务请假一天相关工作已交接给同事感谢您理解。, ], rejected: [ 奖励函数就是给奖励。, 我明天不来了。, ], } dataset Dataset.from_dict(data) print(dataset)注意数据量只有两条无法训练出真正可用的模型。这里只是为了跑通流程。真实项目至少需要数千条偏好样本且要覆盖线上 prompt 的主要分布。4.3 加载模型并初始化 DPO TrainerDPO 需要两个模型待训练的策略模型和冻结的参考模型。初始时两者通常相同都使用 SFT 后的模型权重from transformers import AutoModelForCausalLM, AutoTokenizer from trl import DPOConfig, DPOTrainer model_name Qwen/Qwen2.5-0.5B-Instruct # 示例模型实际按硬件和应用场景选择 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) ref_model AutoModelForCausalLM.from_pretrained(model_name)0.5B 级别的模型适合学习流程生产环境需要更大模型和更规范的训练框架。4.4 启动训练与关键参数说明training_args DPOConfig( output_dir./dpo_output, per_device_train_batch_size1, max_steps50, logging_steps10, save_steps20, beta0.1, learning_rate5e-6, bf16True, ) dpo_trainer DPOTrainer( modelmodel, ref_modelref_model, argstraining_args, train_datasetdataset, tokenizertokenizer, ) dpo_trainer.train()几个参数需要理解beta控制对参考模型的 KL 约束强度。beta 越大策略越保守。learning_rateDPO 在偏好数据上的学习率通常比 SFT 小常见范围在 1e-7 到 1e-5 之间过大会导致语言能力退化。max_steps示例中只有两条数据跑几十步已经足够验证流程真实训练的步数要依据验证集早停决定。4.5 推理验证与效果检查训练完成后用同一个 prompt 生成输出from transformers import pipeline pipe pipeline( text-generation, modelmodel, tokenizertokenizer, ) prompt 请用一句话解释什么是强化学习中的奖励函数。 result pipe(prompt, max_new_tokens64)[0][generated_text] print(result)判断 DPO 是否起作用不能只看生成效果还要看 chosen 和 rejected 之间的概率差。TRL 在训练日志中会输出“chosen 的 log-prob 减去 rejected 的 log-prob”相关指标。该差值越大说明模型越倾向于生成偏好数据中的优质回答。4.6 这个示例离生产还差哪些环节示例跑通只代表代码链路正常距离生产还差很多环节数据规模和质量需要成规模的偏好数据、标注一致性检查、prompt 去重评估集需要独立的 held-out 偏好集避免只靠训练 loss 判断人类审核训练前后都需要人工抽样对比输出部署和回滚模型版本要可回滚训练异常要有告警日志监控线上生成质量、长度、拒绝率等都要有监控。学习阶段先用小模型跑通链路业务阶段再逐步放大是风险最低的路径。5. 没有可验证奖励时的失败模式与排查链路没有可验证奖励意味着训练信号来自奖励模型或偏好数据这两者都可能出错。下面按频率最高的四类问题给出排查思路。5.1 奖励黑客与奖励模型盲区现象训练过程中奖励模型打分持续上涨但人工评估质量没有提升甚至出现大量重复文本、空话套话。原因奖励模型基于统计特征打分策略模型学会了利用这些特征而真实偏好并不完全等于这些特征。排查方式检查策略输出中是否存在高频重复模板分析奖励模型对相同语义、不同写法的输出的分数差异人工抽看高奖励和低奖励样本找出奖励模型的判断依据。处理建议加强 KL 约束在奖励模型训练数据中加入对抗样本上线前做红队测试专门用极端 prompt 检测策略是否会钻空子。5.2 奖励过优化现象训练步数增加奖励模型分数越来越高但验证集和人工评估分数从某个点开始下降。原因奖励模型是近似函数策略模型越靠近奖励模型盲区真实质量越差。这是 RLHF 固有的过优化问题不是代码 bug。处理建议使用早停以人工评估或 held-out 奖励准确率为准调大 beta在训练曲线上同时绘制奖励模型分数和人工评估分观察背离点并以背离点作为保存 checkpoint 的位置。5.3 偏好数据质量不足现象训练后模型没有明显提升甚至某些 prompt 上的输出明显退化。原因标注不一致chosen 和 rejected 差异太小prompt 分布和线上不一致数据去重不彻底。排查方式计算标注者一致性如 Cohens Kappa低于 0.6 时数据可信度很低随机抽取偏好对人工判断“好回答”是否真的显著好于“差回答”对比训练数据 prompt 的领域分布和线上请求分布。5.4 训练不稳定与语言能力退化现象loss 震荡、输出乱码、模型复读某一段话、chosen 和 rejected 的 log-prob 差值异常大。原因学习率过大参考模型没有被冻结beta 设置不当数据中 prompt 格式不统一模型过小或数据太少导致过拟合。处理建议回退到 SFT 模型重新训练降低学习率确认 ref_model 使用 .eval() 且参数冻结在 DPO 训练中定期在通用指令数据上做评测防止语言能力崩塌。四类问题可以整理成一张速查表问题现象常见原因检查方式处理建议奖励分数涨但人工评分降奖励模型盲区抽看高奖励样本加强 KL加对抗样本训练后期质量下降奖励过优化画双指标曲线早停调大 beta提升不明显、输出退化偏好数据质量差计算标注一致性重新清洗数据loss 震荡、复读学习率或 beta 不当检查训练曲线降低学习率冻结参考模型6. 什么场景必须用可验证奖励什么场景可以用替代信号6.1 优先使用可验证奖励的场景只要结果能被程序确定性判断就应该优先使用可验证奖励。典型场景包括数学推理、代码生成、SQL 生成、信息抽取匹配、游戏策略、仿真控制等。优先使用不是因为可验证奖励一定效果最好而是因为它成本低、可复现、排查容易。遇到奖励稀疏时可以叠加过程监督或势函数奖励不必直接放弃可验证信号。6.2 只能依赖替代信号的场景主观评价类任务无法获得可验证奖励必须依赖人工偏好或模型偏好。这类场景包括对话质量的 helpfulness、harmlessness文案风格、创意、语气产品推荐中的用户长期满意度智能体在复杂任务中是否选择了合理路径。在这些场景里最危险的做法是“强行把主观问题变成规则问题”比如用“回答包含关键词就加分”。规则越简单策略越容易钻空子。6.3 混合奖励设计示例实际生产项目中可验证奖励和替代信号通常同时存在。一个常见的混合设计是final_reward α * rule_score β * reward_model_score - γ * KL(πθ || πref)其中 rule_score 来自规则判断比如是否包含违禁内容、是否满足格式要求reward_model_score 来自奖励模型评估风格和帮助性KL 项约束策略不要偏离参考模型。这种设计的关键是确定 α 和 β 的比例。如果规则可验证性高比如安全和合规α 应该更大如果任务是纯主观风格β 更关键。工程上建议先分别上线两个信号观察各自对策略行为的影响再逐步调整权重。7. AI Engineer 的落地清单与后续学习路线7.1 可复用的强化学习落地清单无论选择 DPO、RLHF 还是 GRPO下面这份清单都可以直接用于项目启动阶段[ ] 明确任务结果是否可以自动判定是否真的需要引入学习信号[ ] 如果结果不可验证确定学习信号来源人工偏好、模型偏好、过程监督[ ] 设计偏好数据格式准备标注规范计算标注者一致性[ ] 划分训练集、验证集和 held-out 评估集[ ] 训练好奖励模型后评估它在 held-out 集上的准确率并排查对长度、格式等无关特征的依赖[ ] 设置参考模型和 KL 约束记录初始策略和原始 SFT 模型的距离[ ] 训练过程中同时监控奖励模型分数、KL 距离和人工评估分[ ] 以人工评估分作为早停依据不盲目追求奖励模型分数[ ] 训练完成后做红队测试和样本审核[ ] 部署前准备模型版本回滚机制上线后建立线上质量监控。这份清单的核心理念是在没有可验证奖励时奖励模型分数只是可监控的代理指标人工评估才是最终验收标准。7.2 后续扩展方向理解 DPO 之后接下来可以按四条线扩展第一学懂 PPO 和优势估计。DPO 绕开了很多强化学习组件但生产环境中对训练稳定性要求较高时RLHF PPO 仍然是不可绕开的经典方案需要理解 actor、critic、reference model 和 advantage 之间的关系。第二学习离线强化学习。很多业务只有历史日志数据无法在线探索或试错。IQL 等离线强化学习算法可以在固定数据集上学习策略适合推荐、对话和定价类场景。它的核心挑战是处理分布外动作的价值估计偏差。第三关注基于模型的强化学习。当真实环境交互成本高时可以先学一个世界模型在想象轨迹里训练策略。模型本身也能提供稠密奖励信号但需要评估模型误差是否会积累到策略上。第四研究元强化学习。如果系统需要频繁适配不同用户的偏好元强化学习可以让策略在少量反馈下快速调整。这类方向更接近算法科研建议在有强化学习基础后再深入。对新手最有价值的练习路径是先跑通本文的 DPO 示例再找一个数学评测集实现 RLVR随后回到 RLHF 亲自实现一次 PPO 对齐训练。三个过程走完奖励信号从“可验证”到“不可验证”的差异会变得非常直观。这篇文章最想传递的技术判断是强化学习能不能跑通关键不在于有没有一个现成的奖励函数而在于团队能否为任务构造一个持续可靠的学习信号。可验证奖励是特例不是默认条件人类偏好、模型判断和过程监督才是多数真实任务要依赖的路径。AI Engineer 在实际项目中应该先判断任务是否可验证再决定用规则奖励、奖励模型还是直接偏好优化最后把人工评估作为整个训练闭环的锚点。