奖励函数写不动了，让 LLM 评审来打分：RULER 把 GRPO 推进 2048

Karpathy 之前判断，单个奖励数值告诉 agent 的信息太少。复杂任务里，一个成功结果可能掩盖浪费的步骤、糟糕的工具调用。这个判断正在被工程化。

传统 RLHF 靠人类偏好训练奖励模型，PPO 要同时维护策略、参考策略、奖励模型和 critic。DeepSeek R1 用 RLVR 和 GRPO 把可验证任务跑通：数学题对答案，代码跑测试，奖励是 0 或 1。GRPO 对同一 prompt 的多条回答做组内归一化，省掉 critic。

问题出在 agent 任务。RAG、客服、摘要、工具调用，很难用字符串匹配或编译器给分。手写奖励函数能跑，但规则要提前想到行为，权重难调，流程一变就要重写。更麻烦的是，训练出坏行为时，你很难判断是奖励函数测错了，还是数据、超参出了问题。

Avi Chawla 在 Daily Dose of Data Science 的文章里介绍了 OpenPipe ART 里的 RULER。它把评分标准写成自然语言，让 LLM 评审多条轨迹。同一场景生成 4 到 8 条轨迹，评审模型读系统提示，理解 agent 该做什么，再给这些轨迹相对打分。ART 把分数填进 Trajectory，交给 GRPO 训练。

关键在相对评分。LLM 做绝对打分容易漂，比较“这 4 条哪条更符合系统提示”更稳定。GRPO 本来就会对组内奖励做归一化，它关心哪条高于平均、哪条低于平均。RULER 的相对排序正好接上这个训练信号。

他们用这套设置训练 Qwen3 1.4B 玩 2048。agent 看棋盘，每一步选方向。他们没写一套规则给移动打分。做法是描述评审该看什么，让 RULER 比较完整尝试。最终仍是数值奖励，变化在奖励怎么定义。发现评审漏掉某种行为，就改描述，再看它的判断是否符合意图。

评论区有人问，评审模型和游戏原始分数在同一批运行里不一致的频率有多高。这个问题应该先查。LLM judge 也会幻觉，偏好也可能被策略钻空子。RULER 提供 debug 输出、磁盘缓存、自定义 rubric。评审用便宜模型也能起步，比如 Qwen3 32B 在不少任务上够用，成本比 o3 低。判断标准是否可靠，仍然要抽查。

Anthropic 的 Constitutional AI 用书面原则让 AI 评价输出，OpenAI 的 Universal Verifiers 也在往通用评审信号走，细节未公开。方向很清楚：优化算法已经够用，奖励信号的定义成了新瓶颈。

奖励信号的来源正在从手写代码迁移到可读的评审说明。这个迁移没有消除主观性，只是把主观性放到文本里，方便修改和检查。对 agent 训练来说，下一块硬骨头是定义什么算好，以及怎么验证评审真的在按这个定义打分。

GitHub: https://github.com/OpenPipe/ART

文章: http://x.com/i/article/2048280670825496576