跳转到主要内容
rubric 是你们团队关于”什么算正确回答”的成文标准。凡是没有规则能判定对错的地方都用它:写作质量、 语气、内部规范、解释是否真的解释清楚了。 它之所以是一个对象而不是一段提示词,是因为同一份 rubric 既能当训练优化的奖励,又能当评测上报的 分数。这样训练时往上走的那个数,就是看板上的那个数,而不是一个会和它偏离的代理指标。
这一页讲怎么用。怎么写好一份 —— 准则、权重、版本 —— 见编写评分标准。
TunePlane 评分标准页

评分标准及其准则、版本和使用记录。

当训练奖励

最直接的路是上面的 trl/grpo-judge:平台裁判按这份 rubric 给每条回答打分,那个分数就是奖励。 对 agent 环境,改成把它声明为环境的判定器:
manifest.json
两种方式下打分都由平台裁判完成。你的训练代码不自己调 LLM。 两者都需要部署上开了 TUNEPLANE_JUDGE_ENABLED,它负责把裁判的端点和令牌注入作业。

当评测集

在一个 benchmark pack 里用 judge runner 声明它:
benchmark.yaml
对这个 runner,rubric 就是这个评测集的定义。换掉 rubric 就是换了一个评测集,所以它是一个声明 字段而不是一个命令行参数。

当安全评测

safety runner 用一份 rubric 判断模型是否拒绝了它该拒绝的东西。suite 说哪些 prompt 应该被拒绝, rubric 说什么算拒绝。 两者都属于你的部署。平台两个都不提供,因为提供任何一个都等于平台在下一个它没有立场下的判断。

让训练和评测用同一把尺子

诱惑在于:对着一份 rubric 训练、对着另一份稍有不同的评测,通常是因为有人在项目中途把训练用的那份 改精确了。在两边引用同一个 <owner>/<name>,让版本机制承载这个变化。
它列出哪些运行引用了哪个版本,以及是作为奖励还是作为分数。要回答”这两次运行是不是用同一把尺子判 的”,这是最快的路。 编辑一份 rubric 会让它的版本加一,并让裁判对它的缓存分数失效。旧的运行仍然指向它们实际用过的那个 版本,而那个版本的正文会保留下来,所以你还能读到它当时说了什么。

确认成功

按作业的方式解析这个引用。它能答,环境或 benchmark pack 就能引用它。 训练期间盯 Validation 标签页上的 reward 分布,不要只看均值。裁判给出的奖励塌到两个值上,说明 准则没有区分度。那是 rubric 需要改精确,不是模型。

下一步

编写评分标准 · Benchmark pack · agent 环境 · 评分标准页