用 Rubric 打分

同一份成文标准，同时供给训练 reward 和评测分数。

Rubric 及其评分维度、版本与使用记录。

rubric 是你团队关于「什么算正确答案」的成文标准。 凡是没有规则能判定对错的地方就用它：写作质量、语气、内部规范、一段解释是否真的解释清楚了。

它值得做成一个对象的原因是：同一份 rubric 可以既是训练在优化的 reward，又是评测报告的分数。 这样训练过程中往上走的那个数，就是看板上的那个数——而不是一个会慢慢跑偏的代理指标。

这一页讲的是使用 rubric。要写好一份——维度、权重、版本管理—— 见编写 rubric。

​

作为训练 reward

把它声明成某个环境的 verifier：

manifest.json

{ "verifier": { "kind": "rubric", "ref": "alice/answer-quality" } }

每次 rollout 都按它打分，分数就是 reward。打分由平台裁判完成， 你的训练代码自己不调用任何 LLM。

需要部署开启 FORGE_JUDGE_ENABLED——是它把裁判端点和 token 注入作业的。

​

作为评测基准

在 benchmark 包里用 judge runner 声明它：

benchmark.yaml

schema: forge/benchmark/v1
name: answer-quality
title: Answer quality · customer support
runner: judge
suites: [support-questions]
rubric: alice/answer-quality
metrics:
  - key: weighted_score
    label: Weighted rubric score
    primary: true

sf bench run my-bench -m run:run-4f2a91 --suites answer-quality

对这个 runner 来说，rubric 就是这个基准的定义。 换个 rubric 就是另一个基准，所以它是一个声明字段而不是一个 flag。

​

作为安全评测

safety runner 用一份 rubric 判定模型该拒的有没有拒。 suite 说哪些 prompt 应当被拒绝，rubric 说什么算拒绝。两者都属于你的部署—— 平台哪一个都不提供，因为提供任何一个都等于它替别人下了一个它没资格下的结论。

​

让训练和评测保持诚实

诱惑在于：用一份 rubric 训练，用另一份稍有不同的 rubric 评测—— 通常是因为有人在项目中途把训练那份磨精确了。不要这样做。 两边引用同一个 <owner>/<name>，让版本机制承载这个变化：

curl -H "Authorization: Bearer $SF_TOKEN" \
  https://starforge.your-company.com/api/rubrics/alice/answer-quality/usage

这会列出哪些 run 引用了哪个版本，以及是作为 reward 还是作为分数。 要回答「这两次 run 是不是按同一套标准判的」，这是最快的办法。

编辑 rubric 会让版本号加一，并让裁判对它的分数缓存失效。 旧的 run 仍然指向它们当时真正用过的那个版本，而修订全文被保留，所以你还能读到那个版本当时写了什么。

​

确认成功

curl -H "Authorization: Bearer $SF_TOKEN" \
  "https://starforge.your-company.com/api/rubrics/resolve?ref=alice/answer-quality"

按作业的方式解析这个引用。它能答，环境或 benchmark 包就能引用它。

训练过程中，看 Validation 页上的 reward 分布，而不只是均值。 裁判打出的 reward 塌缩成两个值，通常意味着维度没有区分度—— 要磨的是 rubric，不是模型。