在金融、医疗、法律场景里，模型对齐经常卡在奖励信号。语气是否自然，可以靠偏好数据判断；法条是否仍然有效、计算结果是否与原始数据一致、必填字段有没有缺失，通常能直接核验。法律助手引用废止条文时，表述再流畅，也不该拿到高分。
CS336 对齐技术指南梳理的常见 RLHF 流程，是先收集同一提示下的优劣回答，用 Bradley–Terry 等配对方法训练标量奖励模型，再交给 PPO 更新策略。处理“更有帮助”“更自然”这类主观偏好时，这条路有用。到了垂直业务，链路就显得偏长：专家标注、奖励模型拟合、PPO 联调，任何一环偏了，最后都可能表现为模型行为不对。
GRPO 省掉 Critic，奖励信号还在
DeepSeek-R1 让 GRPO 进入了更多工程团队的视野。它会针对同一个 Prompt 采样一组回答，再根据每个回答与组内平均奖励的差距计算优势，不再单独训练价值网络，也就是 Critic。
这里容易混淆两个环节。GRPO 取消了 Critic，评分仍然要做。每个候选答案都需要奖励信号，来源可以是训练好的奖励模型，也可以是计算器、数据库、代码验证器，或者几种方式的组合。超智咨询的对齐技术指南也将 GRPO 放在 RLHF、DPO 之后讨论，其简化重点在策略优化结构，并不意味着奖励凭空消失。
垂直任务的切入点正是在这里：当错误能够被程序识别，团队可以把一部分专家判断写成验证器，再把验证结果交给 GRPO。
领域知识 → 可执行验证器 → 奖励分数 → GRPO 更新
一套奖励函数，先拆成三个检查
以金融审计模型为例，奖励函数可以从格式、数值和合规三类检查开始：
def reward(answer, source):
checks = {
'format_ok': has_required_index(answer),
'number_ok': numbers_match(answer, source),
'compliance_ok': not hits_forbidden_terms(answer),
}
return combine(checks)
对应到原始规则，可以这样处理：
- 缺少指定的财务报表索引，直接记 0 分；
- 计算结果与源数据不一致，扣 1 分；
- 触发违规表述，扣 2 分。
0、-1、-2 只是示意权重，不是通用配方。更重要的是，每次得分都能追到具体规则：哪个字段没找到、哪一步计算不一致、哪条合规检查被触发。奖励异常时，工程师和领域专家不用猜测黑盒模型在想什么，可以直接查看日志和测试样本。
法律 AI 也能采用类似做法。模型输出法条编号后，通过 API 检查条文是否存在、状态是否为“现行有效”，通过后再给正向奖励。不过，这条规则只能验证引用是否有效，不能证明整段法律分析都正确。检索失败和法条失效也要分开处理，避免数据库或接口故障被误记成模型错误。
医疗 AI 更需要收窄规则范围。若奖励条件写成“答案越详细、引用文献越多，得分越高”，模型很容易堆砌术语，甚至生成不存在的文献索引。可执行奖励适合检查文献是否存在、格式是否完整等明确项目，不宜把完整的临床判断压缩成几条正则表达式。
组内第一名，也可能只是错得少
假设同一个 Prompt 生成了 64 个候选答案。如果 64 个答案都错了，其中一个只是格式更完整、引用更多，它仍可能高于组内平均分，并从其他 63 个答案中胜出。相对得分能找出组内差异，却不会自动保证绝对正确。
这也是 Reward Hacking 最常见的入口。模型不会理解规则制定者的真实意图，只会寻找更容易拿分的输出方式。正式训练前，奖励函数至少要经过几轮针对性检查：
- 放入“内容错误但格式完美”的样本，确认它拿不到高分；
- 把正确性设为门槛，格式、简洁度和表达质量放在后面评分；
- 同时设置正向条件和可核验的负向条件，避免单一指标被刷分；
- 随模型能力变化调整阈值，并保留规则版本和人工抽检记录。
奖励函数本身也要做单元测试。否则，模型训练得越充分，利用规则漏洞的能力可能越强。
28B 对 14B，只能算一笔粗账
标准 PPO 通常包含 Policy、Reference、Reward 和 Critic 四个角色。如果假设它们都是 7B 模型，纸面上的模型规模可以写成约 28B；采用代码奖励的 GRPO 只保留 Policy 和 Reference，则约为 14B。
这个算法只能说明角色数量，不能直接等同于显存占用或训练总成本。优化器状态、梯度、激活值、KV Cache、量化方式、LoRA、序列长度和卸载策略都会改变实际账单。有的实现还会共享部分结构，Reference 和 Reward 也可能只参与推理。
GRPO 确实省掉了 Critic 及其训练状态。如果奖励全部由代码给出，独立 RM 的训练也可以省下。但成本会转移到采样侧：一组生成 64 个候选答案，需要消耗更多生成 Token，还要保存和处理相应的 rollout 数据。
因此，没有模型长度、组大小、卡型和框架版本时，“Batch Size 提升 2—3 倍”或“训练吞吐提升 40%—60%”都不能当作通用结论。奖励模型标注需要“数十万至数百万元”的说法也缺少统一口径，至少要交代样本量、专家成本和复核流程。无论是 3B 端侧模型还是 7B 模型，都应该用相同任务和训练配置做对照测试。
URPO 先别拿缩写替代证据
谈 URPO 或国产算力适配时，硬件名和算法名不能代替测试数据。就给出的可引用材料看，还没有足够信息确认 URPO 的正式定义，也没有摩尔线程、昇腾 910C 在同一训练配置下的对照结果。
同样，“FP8 能显著缓解显存碎片”或“优化缓存后 AllReduce 不再卡住”也需要可复现实验支撑。模型规模、训练框架、序列长度、组大小、精度和通信方式没有对齐，单独比较卡型没有太大意义。
从训练流程可以确定的是，GRPO 会把更多压力放到组采样和长序列生成。具体到摩尔线程或昇腾 910C，应先固定模型、数据和训练参数，再测生成吞吐、显存峰值与通信耗时。
先挑那些确实能验的任务
金融 AI 中的数值计算、法律 AI 中的法条状态、结构化输出中的字段完整性，都是比较合适的起点。它们有外部数据源，也能说明一条答案为什么得分或扣分。医疗 AI 可以先处理文献存在性、输出格式等可核验部分，诊断质量仍需更谨慎的评测和人工复核。
如果奖励要求只能写成“更专业”“更可信”“更像专家”，代码验证器还没有准备好。能够写成“法条状态为现行有效”“计算结果与源数据一致”“指定字段全部出现”，才有适合 GRPO 的落脚点。
算法跑起来只是第一步。长期要维护的是验证器：规则从哪里来、哪一条被命中、为什么扣分、更新后是否误伤正常答案，都要能查清楚。
