RubricRL实践：用评分规则替代奖励模型的大语言模型强化学习

做了一阵子大语言模型强化学习的实验我越来越觉得传统RLHF里那个奖励模型Reward Model阶段又贵又难调。最近反复试下来RubricRL这个思路是真的能落地——它直接把“评分标准”本身当成奖励信号不做黑盒奖励模型。这篇就围绕我实际做的RubricRL实践把核心原理、打分细节、训练参数、踩坑记录全部展开讲。适合正在碰大语言模型后训练、想绕开奖励模型直接上强化学习的工程师和研究者也适合那些对RLHF一直“看得懂、跑不动”的同学按这篇的思路你可以从零把它跑通。1. 项目概述为什么选RubricRL这条路1.1 传统RLHF的痛点奖励模型是个黑盒先聊一个很现实的问题。大语言模型做强化学习最常见的路径是RLHF先收集人类偏好数据训练一个奖励模型再用PPO让策略网络跟着奖励模型走。这条路径本身没有问题很多公开模型也是这么训出来的但在实际动手时你会发现三个非常磨人的点。第一个痛点是偏好标注贵。奖励模型需要大量“哪个回答更好”的对比数据这个标注不是普通打标签标注员得对任务本身有理解。比如让模型做信息抽取、写JSON结构、遵循多条件指令这种任务的偏好标注普通外包很难做准一个人一天标不了几百条而且不同标注员之间一致性很差。第二个痛点是奖励模型的泛化问题。奖励模型训在离线偏好数据上策略模型在训练过程中会不断生成超出分布的数据。奖励模型对这些新样本的打分往往不可靠经常会出现“模型学会了刷高分但实际效果变差”的情况这就是所谓的奖励黑客reward hacking。第三个痛点是可解释性基本为零。奖励模型输出一个标量分你根本不知道模型为什么得了低分是格式不对、信息漏了、还是回答态度有问题出了问题只能靠猜调优效率很低。我一开始也走的是传统RLHF路线后来算了一笔账做一个垂直任务的奖励模型光是整理偏好对就要一两周训RM还要卡还得反复校验RM本身有没有学歪。于是我换了个思路——既然奖励模型的本质是给“回答好不好”打分那我能不能直接告诉模型“我认为好回答应该满足哪些标准”这就是RubricRL的出发点。1.2 RubricRL的核心用评分规则替代奖励模型Rubric这个词本身来自教育评估领域意思就是评分细则。一个作文评分rubric可能会写内容完整性占40%结构清晰度占30%语言表达占20%错别字扣分项占10%。评卷老师不凭感觉打分而是按照这个细则逐项给分。RubricRL就是把这个逻辑搬到大语言模型强化学习里。我先定义一组可判定的评分维度然后针对每个维度分别打分最后加权合成一个奖励值。这个奖励值直接拿来做策略梯度更新不需要单独训练奖励模型。我之所以推荐这个方案核心在于三个优势。第一成本大幅下降——不用专门准备偏好对也不训RM省卡省时间。第二可解释性极强——每次打分都能拆开看是哪个维度拉了后腿训练过程中也能实时监控模型在哪些维度上进步、哪些维度上作弊。第三干预能力强——觉得某个维度权重低了直接改权重继续训不需要重新训练任何模型。当然代价也不是没有。RubricRL最大的风险是“用户如何定义rubric本身就是一项工程”。如果评分标准设计得不合理奖励信号会给错方向模型也会学歪。所以在实践中rubric的设计要和任务深度绑定这件事偷不得懒。1.3 我的实验任务与基线设定我在这次实践里选的任务是“多约束指令完成 JSON结构化输出”非常贴近实际业务场景。具体讲给模型一段文本、一个待提取信息的需求同时要求它输出一个特定结构的JSON里面每个字段的类型、是否必须、是否可为空都有明确要求另外还附带一些约束比如“如果原文没有该字段请填null而不是猜”或“金额字段必须保留两位小数”。我选这个任务的原因是它天然适合RubricRL既有硬性格式标准JSON可解析、字段齐全、类型正确又有语义层面的要求信息抽取是否准确、是否过度推断两种能力刚好能对应不同打分方式。基础模型我选了Qwen2.5-7B-Instruct中文能力强跑RL不用太夸张的显存。基线是同样的prompt集做一轮有监督微调SFT。后面所有RubricRL的收益都是跟这个SFT基线比出来的。这样设置的好处是我可以清楚知道提升来自RL而不是因为prompt更详细了。2. 核心机制拆解Rubric怎么变成强化学习的奖励2.1 Rubric维度设计从任务里拆标准在真正动手写训练代码之前最花时间的是rubric设计。我建议每个任务至少拆出三个维度不要贪多维度太多会让奖励信号变得稀疏且难收敛。针对我的信息抽取JSON任务我最终用了四个维度维度判定内容分值范围判定方式格式合规JSON是否可解析、根节点类型是否对象0-3规则检查字段完整必填字段是否全部出现0-3规则检查字段类型正确字段值类型是否匹配要求string/number/array0-3规则检查信息忠实度抽取出的信息是否和原文一致、有无无中生有0-5LLM-as-Judge为什么把“信息忠实度”设为最高分5分因为在我这个业务场景里模型为了刷格式分数最容易出现的行为就是编内容。如果忠实度权重不高模型会发现“只要把JSON写整齐即使内容胡编也能得高分”这就会诱发奖励黑客。把最本质的能力维度给出最高权重是rubric设计的核心心法。另外我还加了一个负向惩罚项如果模型在回答里输出JSON之外的闲话比如“好的我来为您处理”直接扣分。结构化任务中模型多废话不仅影响下游解析还会消耗不必要的token。这个惩罚项在强化学习阶段比在SFT里的效果显著得多。2.2 两种打分方式规则检查与LLM-as-Judge把rubric变成实际分数我采用的是“规则 大模型评审”混合策略。两类标准用两类方式各管各的。规则检查这部分很简单写函数就行用json.loads解析输出检查是否是合法JSON遍历必填字段检查字段是否存在用isinstance检查类型。规则检查的好处是零成本、零延迟、完全确定。缺点是只能覆盖硬性标准对语义无能为力。语义层的“信息忠实度”我用的是LLM-as-Judge方案。具体做法是用一个比被训练模型更强的模型我用的是Qwen2.5-72B-Instruct的在线API也在本地用vLLM部署过把原始文本、模型抽取结果、rubric说明放进judge prompt让judge模型按0到5分输出一个整数分数。这里最关键的技巧是让judge输出结构化结果。我要求它先输出一个简短的reason再输出分数格式是JSON。解析起来方便同时reason可以留作训练日志方便我事后看模型为什么得低分。judge打分时temperature我固定成0并且每条样本采样两次、取较小值这样能尽量避免judge自己的随机性对训练造成干扰。提示judge模型和策略模型不能是同一个否则“球员兼裁判”很容易刷分。我在实验里试过让7B模型自己judge自己训练几个step后分数全线飘高但实际效果并没有变好。2.3 从分数到优势函数GRPO训练闭环奖励分数有了接下来要把它变成更新参数用的梯度。我用的算法是GRPOGroup Relative Policy Optimization如果你用过PPO理解起来不难PPO需要一个价值模型来估计baselineGRPO干脆不要价值模型直接用同一个prompt采样出来的多个response之间的相对高低来构造优势。GRPO的核心计算公式不复杂。假设同一组prompt采样了G个response每个response得到对应奖励r_i那么第i个response的优势函数就是def compute_advantage(rewards, eps1e-4): # rewards: [G] 同一prompt下G个采样的奖励 mean rewards.mean() std rewards.std() eps advantages (rewards - mean) / std return advantages同一组的样本共用同一组基线组内互相竞争。这个设计天然适合generation任务同一个prompt下好的response得正优势差的得负优势模型会被推着往相对更好的方向走。GRPO省去了价值模型显存占用比PPO小很多代码也更简单特别适合在单机多卡环境下跑中型模型。我的训练主体就是围绕GRPO展开的后面实操部分会更详细地讲配置。KL散度惩罚用来控制策略模型不能偏离参考模型太远公式上是在策略梯度loss外面加一项β·KL(π_θ || π_ref)β一般取0.01到0.05之间我在后面会专门说这个超参是怎么调崩又调回来的。3. 实操全过程从数据准备到训练跑通3.1 环境与依赖搭建先交代一下我的硬件环境。训练机是8卡A80080G但说实话跑7B模型做GRPO并不是很吃显存4卡甚至单卡也能跑只是速度慢一些。如果你卡不充裕降低per_device_batch_size、缩短max_length都能缓解。软件环境我用的是Python 3.10 PyTorch 2.1 TRL库。TRL从0.7.0版本开始已经内置了GRPOTrainer不用自己写训练循环省了很多事。推理采样阶段我同时装了vLLM用来给策略模型从rollout加速。judge打分如果需要本地跑72B模型vLLM也是必须的不然推理速度能急死人。pip install torch2.1.0 transformers4.40.0 trl0.9.0 vllm accelerate deepspeed如果你之前没用过TRL我建议先跑一遍它自带的示例把RLHF的pipeline跑通了再换成自己的rubric奖励函数。跳过这一步直接上手自定义奖励出了bug会非常难排查。3.2 数据构造prompt、rubric与参考答案数据这块我分成两部分prompt集和judge用的rubric模板。prompt集我准备了800条训练prompt和200条测试prompt。每条prompt由三部分组成一段原始文本新闻、客服对话、商品评论等、一个抽取需求描述、若干输出约束。举个例子{ instruction: 请从以下评论中抽取信息并按JSON格式输出。, text: 这个耳机音质不错但戴久了耳朵疼续航大概5小时性价比可以接受。, constraints: [ 输出字段音质评价、舒适度评价、续航小时数(数字类型)、总体评价, 如果原文没有提到某个字段填null, 只输出JSON不要任何额外文字 ] }prompt模板需要做得尽量一致不要每个样本都换一套说辞。模型在RL阶段会记住prompt的结构模式如果模板不一致它会很困惑收敛速度明显变慢。rubric模板则是给judge模型看的我把它做成了一个通用模板加维度说明的形式。通用模板规定judge必须按0到5分打分、只能输出JSON维度说明则描述“信息忠实度”具体看什么——是否与原文一致、是否引入了原文不存在的实体、是否推测性填补等。实操心得不要直接在RL训练时用自然语言prompt当rubric传给judge要把rubric转成结构化描述最好每个维度一段附上正例和反例。judge也是一个模型给的例子越具体它打分越稳定。3.3 奖励计算模块实现自定义奖励函数是接入TRL GRPOTrainer最关键的一步。它的输入是一段prompt文本、模型生成的response列表和一组info信息输出是对应每个response的奖励值列表。我实际写的奖励函数大概长这样def rubric_reward(prompts, responses, infos): rewards [] for prompt, response, info in zip(prompts, responses, info): r_format check_json_format(response) # 0-3 r_fields check_required_fields(response, info) # 0-3 r_types check_field_types(response, info) # 0-3 r_faith judge_faithfulness(prompt, response) # 0-5调用judge模型 total (r_format * 1.0 r_fields * 1.0 r_types * 1.0 r_faith * 1.5 - extra_text_penalty(response)) rewards.append(total) return rewards注意reward范围。如果你最后要传给GRPO做组内归一化reward的绝对值范围其实不太重要重要的是组内的相对关系。但我在实践中还是把总分数控制在了0到12之间避免reward太大导致归一化前梯度不稳。还要提及一个细节check_required_fields这类规则检查要写成容错型比如允许JSON对象里有额外字段但必填字段缺失时扣分不要赶紧打0分否则奖励太稀疏模型在探索阶段梯度几乎为零训练推进很困难。我在早期版本中必填字段缺一个就直接0分结果模型连续几百个step的reward全是0策略完全没动静。后来改成“每缺一个字段扣1分”训练立刻活了过来。3.4 训练配置与关键参数用TRL的GRPOTrainer核心配置如下from trl import GRPOTrainer, GRPOConfig training_args GRPOConfig( output_dir./rubric_rl_qwen7b, learning_rate1e-6, per_device_train_batch_size4, gradient_accumulation_steps4, num_generations8, # 每个prompt采样8个response max_prompt_length1024, max_completion_length1024, beta0.01, # KL惩罚系数 temperature0.7, logging_steps1, save_steps50, max_steps500, )参数含义我不想一个个念说明书重点讲两个。num_generations8就是每组采8个样本做组内对比这个值太小比如2或4会让advantage估计噪声很大训练很不稳太大又显著拖慢rollout时间我试过16效果没有本质提升但时间差不多翻倍所以8是性价比比较高的选择。beta0.01这个KL系数别轻信默认值。7B模型在这个量级下0.01偏保守模型不会偏移参考模型太远但收敛偏慢如果加到0.05模型会经常产生和参考模型差距过大的输出容易变得“话多且跑题”。我最终定格在0.02是在一个200条的小验证集上对比后选的。learning_rate1e-6也要注意。做SFT时很多人习惯用2e-5、1e-5但RL阶段lr过高会直接毁掉已经学会的生成能力。我第一次跑RL时用了5e-6前50步还行100步之后模型开始输出重复token后来降到1e-6才稳住。3.5 训练过程观察我把训练跑起来之后记录了几个值得关注的信号。首先是reward曲线。前50个step平均reward快速上升从5.2涨到7.1左右这个阶段模型主要是在学会“输出一个完整JSON”这个格式很容易看到提升。但从第80个step开始reward曲线进入平缓期增长非常慢。这时候不要急着提lr模型正在从“格式正确”往“内容准确”爬这是最费步数的阶段。其次是KL散度变化。TRL日志里会输出kl值我观察到训练开始时KL大约0.02到200步后慢慢涨到0.08左右说明策略在持续偏离参考模型。如果某个时刻KL突然猛增通常意味着模型开始走极端这时候最好回到前一个checkpoint并调高beta。我还顺手做了一个干预测试训练到200步时采样20条测试prompt看生成结果发现大部分输出格式正确但有几条在“原文没有提到价格”的情况下模型会编造一个“价格合理”的评价这就是我刚才说的奖励黑客苗头。我立即把judge打分时的“信息忠实度”提示词改得更严格并在reward里追加了“出现原文中不存在的实体时额外扣1分”的规则后续训练就明显好转了。这种动态调整rubric的能力正是RubricRL比传统RLHF优越的地方问题定位精准、改动成本低两条就能干预训练方向。4. 常见问题与避坑实录4.1 模型输出坍塌成“好的这是结果”这是我在实验中最先遇到的坑。训练大约150步后模型学到的最优策略居然是输出“好的这是结果{...}”这样一句话来回说JSON部分反而没有真正抽取信息。原因有两个。第一reward里没有充分惩罚“格式外废话”模型发现多说一句“好的”也不扣分。第二KL惩罚系数太低模型可以在很短时间内走偏。我的解决方法是双管齐下在奖励函数里加入extra_text_penalty只要模型输出不以{开头、不以}结尾就按“非JSON字符数量”扣分同时把beta从0.01提到0.02让模型不能偏离参考模型过远。改完这两处坍塌现象基本消失。这个坑说明了一个通用原则RS强化学习里模型一定会找到奖励函数中的漏洞。你需要提前假设“模型会如何作弊”并在reward里堵住这些漏洞而不是等它出现了再改。4.2 奖励分数方差大训练不稳定训练中期我遇到一个很烦的现象同一个prompt下8个采样的reward分数忽高忽低组内标准差特别大导致advantage计算出来噪声很大模型像是在乱撞。排查后定位到judge模型打分的方差问题。judge本身也是一个模型它的打分虽然temperature设为0但仍然会对格式、措辞差异产生敏感特别是0分和1分、4分和5分这种临界分数经常不稳定。我的处理办法是每条response的judge评分从1次采样改为3次取中位数而不是平均值。中位数比均值更抗离群点训练稳定性好很多。另外我把judge的评分等级从“0-5分”改成了“0-3分”0分有明显违背、1分部分正确、2分基本正确、3分完全忠实。乍一看细粒度下降但实际训练效果反而更稳说明奖励信号的一致性比分辨率更重要。4.3 规则检查与语义评审互相冲突有一类问题特别隐蔽模型为了满足规则检查把输出内容“削足适履”。比如约束要求“如果原文没有某字段填null”模型确实填了null但同时又漏掉了原文里明明有的字段导致信息丢失。这就是规则检查和语义忠实度之间的冲突。规则检查管“形状”语义评审管“内容”两者在边界场景经常打架。模型会尽量满足规则检查的硬性要求因为这部分分数稳定、容易拿到费劲拿语义分反而难。解决办法是把规则检查设计得更宽松必填字段如果填了null且原文确实没有该信息不扣分如果原文有该信息但模型填了null在语义评审中重点扣分。同时把“信息忠实度”的权重从1.5提升到2.0让模型意识到“内容准确”比“格式好看”更重要。这版调整后测试集上信息提取的准确率又上了一个台阶。4.4 训练后模型反而变笨另一个值得警惕的坑是RL训练后模型在目标任务上变强了但在通用能力上明显变弱。比如你问它“解释一下什么是回调函数”它可能机械地往JSON格式上靠或者回答变得异常简短。这个现象的原因很直接RL的目标函数只有一个如果rubric完全没有覆盖“通用能力”这个维度模型就会把本来用于通用能力的容量让位给目标维度。这是所有task-specific RL的通病。我的缓解办法有三个。第一训练数据里塞入10%的普通指令数据它们的reward直接设为固定中等分让模型不要在这些样本上剧烈更新。第二每一轮评估不只看目标任务指标还要跑一个通用能力小测试集10道问答、10道代码题。第三如果通用能力下降太明显回退到RL训练前的checkpoint降低lr和beta重新训。问题核心原因解决手段输出坍塌奖励函数漏洞、KL过低加冗余惩罚、提高beta训练不稳judge打分方差大多次采样取中位数、降低评分粒度规则与语义冲突规则检查过严放宽规则约束、提高语义权重模型变笨RL目标单一化混入通用数据、设置通用评估集5. 扩展思路VLM、本地部署与后续实验方向5.1 在视觉大语言模型上做RubricRL做完这个文本任务后我又把同样的思路迁移到视觉大语言模型VLM上目标任务是“图像描述生成”。在这个场景下传统奖励模型的问题更加突出人类偏好标注图片描述标注成本比文本还要高而且不同人对“好描述”的标准更难统一。Rubric模板在VLM上可以直接这样定对象存在性描述中出现的物体是否真实存在于图像中、属性准确性颜色、数量、位置等属性是否正确、空间关系正确性“左边”“后面”这类空间词是否与实际一致、描述丰富度是否只说了“图片中有一个苹果”而漏掉其他关键元素。这套rubric对缓解幻觉特别有效。强化学习阶段让模型为了“对象存在性”得分就必须强制自己只描述图像中实际存在的实体模型会逐渐学会“不确定的东西宁可不写”。我在VLM实验里得到的初步结论是幻觉率比SFT基线降低了约20%到30%后续我还打算把这类rubric做成通用评估模板在不同图像数据集上验证。5.2 训练后蒸馏与本地部署大语言模型RL训练完成的7B模型性能不错但直接往业务线部署还是有点重。我的做法是先做知识蒸馏把7B模型在4000条高难度任务数据上的输出当作soft label训练一个3B或1.5B的小模型再做4bit量化最后用vLLM或llama.cpp在本地CPU/小显存环境部署。蒸馏过程相比从头SFT有两个明显优势一是小模型学到的不仅是正确答案还包含大模型在RL阶段学到的“如何权衡格式和内容”的行为模式二是数据效率高几千条就够不需要重新标注海量数据。部署阶段如果用的是支持量化的小模型本地跑起来非常轻量一张16G消费级显卡轻松带6B级别模型纯CPU跑1.5B模型配合量化也能做到秒级响应。这种“RL训练7B → 蒸馏3B → 量化4bit → 本地部署”的路径是我目前比较推荐的低成本落地方式。5.3 还能怎么玩领域定制和自动化Rubric生成最后聊聊后续扩展方向。RubricRL最有价值的地方是它的可定制性。同一个框架把rubric维度从“信息抽取忠实度”换成“客服回答同理心”、“法律文书格式合规”、“代码注释完整度”就能适配完全不同领域的目标。做医疗问答可以加“是否包含免责声明”的惩罚项做客服助手可以加“是否在未解决用户问题时简单道歉了事”的检测维度。另一个我准备尝试的方向是用更强的大模型自动生成rubric初稿人工只负责校准。具体做法是把任务描述喂给一个能力更强的模型让它生成候选维度、分值范围和判定标准然后我在50条验证数据上测试这些rubric的判别能力只保留能区分“好回答”和“坏回答”的维度。这样可以把设计rubric的时间从几天压缩到几个小时。我个人实际做下来最大的体会是RubricRL这套东西真正的瓶颈不在强化学习算法而在评分标准的设计能力。算法本身已经很成熟GRPO工程化也好做但一个高质量的rubric需要你同时理解任务、理解模型、理解数据。如果让我再做一次这个实验我会先把20条典型样本的“好答案”和“坏答案”打印出来一条一条分析差异来源再动笔写rubric而不是一上来就堆代码。这个过程看似繁琐却是整个RubricRL实践里最值得花时间的一步。