做了一阵子大语言模型强化学习的实验，我越来越觉得，传统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/array） | 0-3 | 规则检查 |
| 信息忠实度 | 抽取出的信息是否和原文一致、有无无中生有 | 0-5 | LLM-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训练闭环
奖励分数有了，接下来要把它变成更新参数用的梯度。我用的算法是GRPO（Group Relative Policy Optimization），如果你用过PPO，理解起来不难：PPO需要一个价值模型来估计baseline，GRPO干脆不要价值模型，直接用同一个prompt采样出来的多个response之间的相对高低来构造优势。
GRPO的核心计算公式不复杂。假设同一组prompt采样了G个response，每个response得到对应奖励r_i，那么第i个response的优势函数就是：
def compute_advantage(rewards, eps=1e-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卡A800（80G），但说实话，跑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 torch==2.1.0 transformers==4.40.0 trl==0.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_rate=1e-6, per_device_train_batch_size=4, gradient_accumulation_steps=4, num_generations=8, # 每个prompt采样8个response max_prompt_length=1024, max_completion_length=1024, beta=0.01, # KL惩罚系数 temperature=0.7, logging_steps=1, save_steps=50, max_steps=500, )参数含义我不想一个个念说明书，重点讲两个。num_generations=8就是每组采8个样本做组内对比，这个值太小（比如2或4）会让advantage估计噪声很大，训练很不稳；太大又显著拖慢rollout时间，我试过16，效果没有本质提升，但时间差不多翻倍，所以8是性价比比较高的选择。
beta=0.01这个KL系数，别轻信默认值。7B模型在这个量级下，0.01偏保守，模型不会偏移参考模型太远，但收敛偏慢；如果加到0.05，模型会经常产生和参考模型差距过大的输出，容易变得“话多且跑题”。我最终定格在0.02，是在一个200条的小验证集上对比后选的。
learning_rate=1e-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实践里最值得花时间的一步。
