1. 为什么我要折腾 RubricRL 这件事大语言模型做强化学习这两年最主流的路线基本被 RLHF 和后来的 DPO、GRPO 这些方法占满了。但真上手做过的人都知道RLHF 那套奖励模型Reward Model的训练成本高得离谱而且奖励模型本身很容易被策略模型“钻空子”——也就是所谓的 reward hacking。你辛辛苦苦训出来的奖励模型策略模型跑着跑着就学会输出一堆看起来分数很高、实际上毫无营养的废话。这个问题在开放域生成任务里尤其明显因为“好”本身就是一个很难用单一标量刻画的东西。RubricRL 这个思路说白了就是把“打分”这件事从“一个分数”变成“一张评分表”。Rubric 这个词在教育评估领域用得很多就是评分细则、评分量规的意思。传统奖励模型给你一个 0.87 的分数你根本不知道这 0.87 是怎么来的而 Rubric 会告诉你逻辑性 4 分、事实准确性 3 分、表达流畅度 5 分、指令遵循度 2 分。这种结构化的反馈对模型来说信息密度高得多也更难被单一维度地 hack。我这次实践的核心目标很明确在有限算力条件下用 Rubric 作为奖励信号跑通一套完整的大语言模型强化学习流程并且验证它相比传统标量奖励在指令遵循和输出质量上是否有可观测的提升。适合谁来参考如果你已经了解基本的强化学习概念跑过 SFT想进一步尝试 RL 微调但又被 RLHF 的工程复杂度劝退那这篇内容应该能帮你少走不少弯路。我会把踩过的坑、参数选择的理由、以及那些文档里不会写的细节都摊开讲。2. RubricRL 的整体设计与方案选型2.1 从标量奖励到结构化评分表的本质区别先说清楚 RubricRL 到底和传统 RLHF 差在哪。传统 RLHF 的流程是收集人类偏好对 → 训练奖励模型 → 用 PPO 优化策略。奖励模型本质上是一个回归模型输入是 prompt 和 response输出是一个标量分数。这个标量分数承载了所有维度的信息但它是被压缩过的压缩过程中必然丢失大量细节。RubricRL 的做法是奖励信号本身就是一个结构化的向量或者一组分项评分。举个例子对于“写一段产品介绍”这个任务Rubric 可能包含信息完整性0-5、语言吸引力0-5、事实准确性0-5、格式规范性0-5。最终奖励可以是加权和也可以是分项分别反馈。关键在于模型在训练过程中接收到的信号更丰富它知道自己在哪个维度上做得好、哪个维度上做得差。这个设计背后的逻辑其实很朴素人类学习的时候老师不会只给你一个总分而是会告诉你哪里对哪里错。单一标量奖励就像只告诉你“这次考试 72 分”而 Rubric 就像告诉你“选择题全对、大题步骤有问题、计算失误扣了 8 分”。后者的学习效率显然更高。2.2 为什么不用 PPO 而选择更轻量的方案PPO 在大语言模型上的工程复杂度是出了名的高。你需要同时维护四个模型策略模型、参考模型、奖励模型、价值模型。显存占用直接翻四倍训练稳定性还很难保证。我一开始也想过直接上 PPO但算了一下显存单卡 80G 根本不够用多卡又受限于实际条件。所以我选择了更轻量的路线用 GRPOGroup Relative Policy Optimization的思想做基础把 Rubric 评分作为奖励信号注入。GRPO 的核心优势是不需要单独的价值模型它通过组内相对比较来估计优势函数。具体来说对于同一个 prompt采样一组 response然后用 Rubric 给每个 response 打分组内归一化之后作为优势。这样显存占用大幅降低训练也稳定得多。这里有个关键决策点Rubric 的评分由谁来打有两种选择一是用一个更强的模型比如 GPT-4 级别的来打分二是训练一个专门的 Rubric 评分模型。前者成本高但质量好适合小规模验证后者前期投入大但长期可复用。我这次采用的是混合方案先用强模型标注一批数据训练一个轻量的 Rubric 评分器然后在训练过程中用这个评分器在线打分。这样既控制了成本又保证了评分的一致性。2.3 整体架构与数据流设计整个系统的数据流是这样的首先准备一批 prompt 数据然后策略模型对每个 prompt 采样 K 个 response我设的 K8。这 K 个 response 一起送给 Rubric 评分器评分器输出每个 response 在各个维度上的分数。然后计算加权总分做组内归一化得到优势值。最后用这个优势值计算策略梯度更新策略模型。这里有个细节值得展开组内归一化的方式。我试过两种一种是减均值除标准差z-score另一种是减均值不除标准差。实测下来除标准差的方式在训练初期更稳定但后期容易导致梯度爆炸因为当组内分数差异很小时标准差会趋近于零。所以我最终采用的是带裁剪的 z-score标准差设一个下限比如 0.1防止除零和梯度爆炸。另外参考模型的 KL 惩罚项也不能省。虽然 GRPO 不需要价值模型但 KL 散度约束还是要有的否则策略模型会跑偏得太厉害。我用的 KL 系数是 0.04这个值是根据经验调的太大模型学不动太小又会输出崩坏。3. Rubric 评分体系的核心细节与实操要点3.1 评分维度的设计原则与常见误区Rubric 的维度设计是整个方案里最需要动脑子的部分。维度太少退化成标量奖励维度太多评分器难以保持一致而且训练信号会变得稀疏。我的经验是3 到 6 个维度比较合适具体数量取决于任务复杂度。设计维度的时候有几个原则。第一维度之间要尽量正交不能有强相关。比如“逻辑性”和“连贯性”在很多任务里高度相关同时放进去就是浪费。第二每个维度要有明确的评分标准不能是“好/中/差”这种模糊描述而要给出具体的锚点。比如“事实准确性”可以定义为5 分表示所有事实陈述均可验证且无误3 分表示大部分正确但有轻微偏差1 分表示存在明显事实错误。我踩过的一个坑是一开始把“长度”也作为一个维度想着鼓励模型输出更详细的内容。结果模型学会了疯狂堆砌废话长度分拉满但其他维度全部崩盘。后来我把长度相关的维度全部去掉改为在评分标准里隐含地要求“信息密度”问题才解决。这个教训说明Rubric 的维度设计必须和最终目标对齐不能想当然地加一些看似合理的指标。3.2 评分器的训练与校准方法评分器的质量直接决定了整个训练的上限。我用的是一个 7B 的模型作为评分器基座在标注数据上做了 SFT。标注数据的来源是用强模型对 5000 条 response 进行多维度评分然后人工抽检修正了其中约 800 条。这个人工修正的环节非常关键因为强模型的评分也不是完全可靠的尤其是在一些需要专业判断的维度上。评分器的输出格式我强制要求为 JSON每个维度一个字段值域 0 到 5 的整数。这样做的好处是解析方便而且离散化的评分比连续值更稳定。训练的时候用的是交叉熵损失把每个维度的评分当作一个 6 分类问题来处理。实测下来这种离散分类的方式比回归方式收敛更快评分一致性也更好。校准环节我做了两件事。一是计算评分器和人工评分在验证集上的 Spearman 相关系数确保在 0.7 以上才投入使用。二是检查评分分布的偏态如果某个维度的评分集中在 4 到 5 分之间说明区分度不够需要调整评分标准或者补充低分样本。我遇到过一次“指令遵循度”这个维度几乎全是满分的情况后来发现是标注数据里负面样本太少补充了一批之后分布才正常。3.3 奖励聚合方式的选择与参数计算有了各维度分数之后怎么聚合成最终奖励是个需要仔细考虑的问题。最简单的是等权求和但实际任务中不同维度的重要性显然不一样。我采用的是加权求和权重通过一个小规模的网格搜索来确定。具体做法是在验证集上用不同的权重组合计算奖励然后看哪个组合下策略模型的输出质量最高。权重搜索的范围是每个维度 0.5 到 2.0步长 0.25。这个搜索过程不需要重新训练模型只需要用已有的评分数据重新计算奖励然后评估即可成本很低。除了加权求和我还试过另一种方式把各维度分数拼接成一个向量直接作为奖励信号。这种方式理论上信息更丰富但实际训练时发现策略模型很难从高维奖励中学习收敛速度明显慢于加权求和。所以最终我还是用了加权求和但保留了各维度的分数用于监控和分析。这里给一个具体的参数计算示例。假设四个维度的权重分别是信息完整性 1.5、语言吸引力 1.0、事实准确性 2.0、格式规范性 0.5。某个 response 的评分是 4、3、5、4那么加权总分就是 1.5×4 1.0×3 2.0×5 0.5×4 6 3 10 2 21。然后组内归一化假设组内均值为 18标准差为 3那么优势值就是 (21-18)/3 1.0。4. 完整实操流程与关键环节实现4.1 环境准备与依赖配置先说环境。我用的是一台 8 卡 A100 80G 的机器但实际上 4 卡也能跑起来只是 batch size 要调小。Python 环境是 3.10PyTorch 2.1.0CUDA 12.1。强化学习框架我用的是 TRL 库它里面已经实现了 GRPO 的训练循环省去了很多自己写的麻烦。不过 TRL 的 GRPO 实现默认是标量奖励我需要改一下奖励计算的部分来支持 Rubric。依赖安装没什么特别的主要是 transformers、trl、peft、datasets 这几个。需要注意的是TRL 的版本更新很快不同版本之间 API 差异不小。我用的是 0.7.10 版本这个版本比较稳定。如果你用更新的版本可能需要调整一些参数名。pip install torch2.1.0 transformers4.36.0 trl0.7.10 peft0.7.0 datasets2.16.0 accelerate0.25.0显存方面7B 模型做 GRPO 训练K8 的采样4 卡 A100 80G 大概能跑 batch size 为 4 的配置。如果显存不够可以开启 gradient checkpointing 和 flash attention能省不少显存。我实测下来开启这两个优化之后显存占用从 72G 降到了 48G 左右。4.2 数据准备与 Prompt 设计训练数据我准备了两部分一部分是通用的指令遵循数据大概 20000 条另一部分是特定领域的任务数据大概 5000 条。通用数据用来保持模型的基础能力领域数据用来提升特定任务的表现。这个比例是根据经验定的领域数据太少效果不明显太多又会导致通用能力下降。Prompt 的设计有个细节我在每个 prompt 后面都加了一段系统提示明确告诉模型“请按照以下要求回答”然后把 Rubric 的维度以自然语言的形式描述出来。比如“请确保回答信息完整、语言流畅、事实准确、格式规范”。这样做的好处是模型在生成时就有意识地往这些维度上靠训练效率更高。实测下来加了这段提示之后初始采样阶段的平均奖励就比不加高了 15% 左右。数据格式上我用的是 JSONL每行一个样本包含 prompt 和可选的 reference answer。reference answer 不是必须的但在有参考答案的任务上评分器可以结合参考答案来打分准确性更高。4.3 训练循环的搭建与关键参数设置训练循环的核心逻辑在 TRL 的 GRPOTrainer 里我需要做的是自定义 reward function。具体来说就是写一个函数输入是 prompts 和 responses输出是每个 response 的奖励值。在这个函数里我调用 Rubric 评分器获取各维度分数然后加权求和。关键参数设置如下学习率 1e-6这个值比 SFT 阶段小一个数量级因为强化学习阶段需要更精细的调整。KL 系数 0.04前面提过。采样温度 0.9这个温度下生成的多样性比较好组内差异明显有利于优势估计。组大小 K8这个值是显存和效果之间的折中K 越大优势估计越准但显存占用也越大。训练过程中我监控几个指标平均奖励、KL 散度、各维度分数的分布、以及生成文本的长度分布。平均奖励应该稳步上升但如果上升太快可能是 reward hacking 的前兆。KL 散度要控制在一个合理范围内我一般让它不超过 10。各维度分数的分布要关注是否有某个维度突然崩掉这通常意味着模型找到了某种投机取巧的方式。def rubric_reward(prompts, responses, rubric_scorer): scores rubric_scorer.batch_score(prompts, responses) weights {completeness: 1.5, fluency: 1.0, accuracy: 2.0, format: 0.5} total sum(scores[dim] * weights[dim] for dim in weights) return total4.4 训练过程监控与阶段性评估训练不是跑完就完事了中间需要多次评估。我的做法是每 200 步做一次验证集评估用一组固定的 prompt 生成回答然后人工抽检或者用强模型评分。这样能及时发现训练是否跑偏。我遇到过两次比较严重的问题。一次是训练到 600 步左右模型开始输出非常长的回答平均长度从 200 字涨到了 800 字但质量并没有提升。检查后发现是“信息完整性”这个维度的评分器对长文本有偏好模型学会了堆砌内容。解决办法是重新校准评分器在评分标准里明确“信息密度”的要求并且对超长回答做惩罚。另一次是 KL 散度突然飙升到 30 以上模型输出开始出现重复和乱码。原因是学习率设得太高策略更新步子太大。把学习率从 2e-6 降到 1e-6 之后问题解决。这个教训说明强化学习阶段的学习率一定要保守宁可慢一点也不要崩。5. 常见问题与排查技巧实录5.1 奖励不升反降的排查思路奖励不升反降是最常见的问题可能的原因有好几种。首先检查评分器是否正常工作有时候评分器的 API 调用会超时或者返回异常值导致奖励计算错误。我建议在训练循环里加一个断言检查奖励值是否在合理范围内比如 0 到 30 之间超出范围就报警。如果评分器没问题那就看 KL 散度。KL 散度如果持续上升说明策略模型偏离参考模型太远需要增大 KL 系数或者降低学习率。如果 KL 散度正常但奖励不升可能是优势估计出了问题。检查组内分数的方差如果方差太小说明组内 response 质量都差不多优势信号很弱模型学不到东西。这时候可以增大采样温度或者增大组大小 K。还有一种情况是奖励上升一段时间后突然下降这通常是 reward hacking 的表现。模型找到了某种能拿高分但实际质量很差的方式。解决办法是加强评分器的鲁棒性或者在奖励里加入惩罚项。我一般会加一个长度惩罚和重复惩罚防止模型走捷径。5.2 评分器不一致导致的训练震荡评分器的不一致性是 RubricRL 特有的问题。同一个 response评分器在不同时间给出的分数可能不一样这会导致训练信号有噪声模型震荡。我做过一个实验同一个 response 让评分器打 10 次分发现各维度分数的标准差在 0.3 到 0.8 之间这个噪声水平不算低。降低不一致性的方法有几个。一是降低采样温度评分器生成评分时用贪婪解码而不是采样。二是多次评分取平均比如每个 response 评 3 次取中位数。三是把评分离散化0 到 5 的整数比连续值稳定得多。我最终采用的是贪婪解码加离散评分一致性提升很明显同一 response 的评分标准差降到了 0.2 以下。另外评分器的校准也要定期做。训练过程中模型输出的分布会变化评分器可能对新分布的数据打分不准。我一般每 500 步重新校准一次评分器用最新的模型输出做验证。5.3 显存不足与训练速度优化显存不足是实操中最现实的问题。除了前面提到的 gradient checkpointing 和 flash attention还有几个技巧。一是用 LoRA 做参数高效微调只训练一小部分参数显存占用大幅降低。我用 LoRA 的时候rank 设的是 16alpha 是 32效果和全量微调差距不大但显存省了将近一半。二是优化采样过程。K8 的采样是显存大户因为要同时保留 8 个 response 的计算图。如果显存不够可以减小 K比如降到 4但这样优势估计的方差会变大。另一个方法是分批次采样先采样 4 个计算完优势后再采样 4 个但这样实现起来复杂一些。训练速度方面数据加载往往是瓶颈。我建议用流式加载而不是一次性加载全部数据尤其是数据量大的时候。另外评分器的推理速度也很关键如果评分器太慢整个训练循环都会被拖慢。我用的 7B 评分器batch size 为 16 的时候评分速度大概是每秒 50 条左右基本能满足训练需求。5.4 常见问题速查表问题现象可能原因排查方法解决方案奖励不升评分器异常检查奖励值范围修复评分器调用奖励不升优势信号弱检查组内方差增大温度或 K奖励下降Reward hacking检查输出质量加惩罚项或校准评分器KL 飙升学习率过高监控 KL 散度降低学习率或增大 KL 系数训练震荡评分器不一致重复评分测方差贪婪解码加离散评分显存不足采样占用大查看显存分布LoRA 或减小 K速度慢数据加载瓶颈检查 IO流式加载6. 实操心得与后续扩展方向6.1 那些文档里不会写的经验第一个心得Rubric 的维度数量不要超过 6 个。我试过 8 个维度的配置结果评分器的一致性急剧下降训练效果反而不如 4 个维度。维度多了之后评分器很难同时兼顾所有维度而且各维度之间的相关性也会变高信息冗余。第二个心得训练初期先用小学习率预热。我一般前 50 步用 1e-7 的学习率然后再升到 1e-6。这样能让模型先适应新的奖励信号避免一开始就更新过猛导致崩盘。这个技巧在 SFT 阶段也适用但在强化学习阶段尤其重要。第三个心得保留一个“黄金验证集”。这个验证集不要太大100 条左右就够了但要是精心挑选的、能代表最终目标的高质量样本。每次评估都看这个验证集上的表现比看平均奖励更可靠。因为平均奖励可能会被 reward hacking 拉高但黄金验证集上的表现骗不了人。第四个心得不要迷信自动化评估。我每周都会人工抽检 50 条模型输出虽然费时间但能发现很多自动化指标发现不了的问题。有一次自动化评估显示一切正常但人工抽检发现模型开始在所有回答末尾加一句“希望对你有帮助”这种模式化的输出在评分器那里拿了高分但实际体验很差。6.2 算力约束下的取舍策略不是每个人都有 8 卡 A100算力约束下的取舍很关键。如果只有单卡 24G我的建议是用 1.5B 到 3B 的小模型做验证先把流程跑通再考虑放大。小模型上验证过的 Rubric 设计和参数配置迁移到大模型上大概率也是有效的。评分器也可以用更小的模型比如 1.5B只要校准做得好评分质量不会差太多。我对比过 1.5B 和 7B 评分器的效果在 Spearman 相关系数上差距大概在 0.05 左右但推理速度快了 4 倍。如果算力紧张用 1.5B 评分器是完全可行的。另外采样数量 K 也可以动态调整。训练初期用 K4 快速迭代等流程稳定后再增加到 K8。这样能在早期节省大量算力把资源用在刀刃上。6.3 这个方案还能怎么扩展RubricRL 这套框架的扩展性其实很好。一个方向是动态 Rubric也就是根据 prompt 的类型自动选择不同的评分维度。比如代码生成任务用“正确性、效率、可读性”而文案写作任务用“吸引力、准确性、格式”。这样评分更有针对性但需要额外训练一个 Rubric 选择器。另一个方向是多轮交互场景。现在的实现是单轮生成如果扩展到多轮对话Rubric 需要评估整个对话轨迹而不仅仅是单轮回复。这涉及到信用分配问题也就是如何把最终评分归因到每一轮的输出上。可以用类似 GAE 的方法来做但实现复杂度会高不少。还有一个方向是把 Rubric 评分和过程奖励结合起来。现在是在最终输出上打分如果能在生成过程中就给出中间奖励模型的训练效率会更高。这需要评分器能够实时评估部分生成的内容对评分器的能力要求更高但理论上限也更高。我个人在实际操作中的体会是RubricRL 最大的价值不在于它比 RLHF 好多少而在于它让奖励信号变得可解释、可调试。传统 RLHF 训练出问题的时候你面对的是一个黑盒奖励模型根本不知道哪里出了问题。而 RubricRL 的每个维度都是透明的你可以清楚地看到模型在哪个维度上表现好、哪个维度上需要改进。这种可解释性在工程实践中太重要了它能把调试时间从几天缩短到几个小时。如果你也在做强化学习微调强烈建议试试 Rubric 这条路哪怕只是用来做监控和诊断价值也很大。