判定器

manifest.json

{ "verifier": { "kind": "rubric", "ref": "alice/arithmetic-correctness" } }

判定器决定一个任务是否完成。它永远是一个引用，指向已经拥有那个答案的东西 —— 从不是平台自己实现的东西。

三种 kind

Kind	`ref` 是	判断权在谁
`rubric`	一份 Rubric 的 `<owner>/<name>`	你们团队的成文标准
`plugin`	一个 `capability: environment` 插件里的 `module:callable`	你的代码
`endpoint`	一个 HTTP URL	你运行的一个服务

这里有意没有第四种，特别是没有内置的那种。

为什么平台从不充当判定器

这个仓库上一次长出内置打分器时，它写了自己的仿真管线和自己的权重，得出的判断和评测侧不一致，最后被整体回滚。一个住在控制面里的判定器，不管开始时多小，都会是”什么算正确”的第二个定义，而这两个定义会恰好在最要紧的时候不一致。

契约

不管哪种 kind，解析出来的判定器在平台这一侧长得一样：

VerifyFn = Callable[[Mapping[str, Any], Any], float]

两个参数：任务，以及 harness 提交的那份轨迹。一个返回值：奖励。

rubric
plugin
endpoint

{ "verifier": { "kind": "rubric", "ref": "alice/arithmetic-correctness" } }

平台裁判按指定的那个 rubric 版本给轨迹打分。它收到任务的 prompt、拉平后的轨迹文本，以及任务的 reference（如果有）。轨迹会替你拉平 —— 字符串还是字符串，message 对象贡献它的 content 或 text，列表会被拼接。各家 harness 的形状不同，而判定器契约关心的是模型产出了什么，所以这个折叠在这里做一次，而不是在每个作者的代码里做一遍。

{ "verifier": { "kind": "plugin", "ref": "verify:score_arithmetic" } }

verify.py

from typing import Any, Mapping

def score_arithmetic(task: Mapping[str, Any], trajectory: Any) -> float:
    expected = str(task.get("reference", "")).strip()
    answer = str(trajectory).strip().split()[-1] if trajectory else ""
    return 1.0 if answer == expected else 0.0

从一个 launcher 已经过三道摘要门校验过的 capability: environment 插件里 import。它是惰性 import 并缓存的：import 错误在第一个任务上暴露，那里它读起来像一个部署问题；如果在启动时暴露，它会看起来像环境本身坏了。返回值必须是 float() 能接受的东西。抛异常是可以的、也是正确的 —— 见下文。

{ "verifier": { "kind": "endpoint", "ref": "https://verifier.corp/score" } }

平台 POST JSON 并期待返回一个奖励：

Request

{ "task": { "prompt": "...", "reference": "..." }, "trajectory": "..." }

Response

{ "reward": 0.83 }

响应里没有 reward 字段、或它不是数字，是一个错误，不是零。默认超时 60 秒。

判定失败是错误，永远不是零

你的判定器答不出来时 —— 端点挂了、模块 import 不了、rubric 没了 —— 平台会抛异常。它不会上报 0.0 的奖励。

这是任何写判定器的人最需要知道的一条规则，为什么值得说白：一个被静悄悄置零的奖励，和一个真的答错了的回答完全无法区分。一次在第 400 步判定器悄悄坏掉的训练运行，会继续产出一条 reward 曲线、继续看起来合理，并在剩下几个小时里用噪声教模型。所以在你自己的判定器代码里：

def score(task, trajectory):
    if not task.get("reference"):
        raise ValueError("this task has no reference; it cannot be scored")   # 正确
        # return 0.0                                                          # 错误
    ...

错误会被包装成 VerificationError 并带上失败的那个引用，所以作业日志会点名是哪个判定器停下来、以及为什么。

怎么选

用	什么时候
`rubric`	对错是一件需要判断的事：质量、语气、一个解释是否站得住。另外，凡是你希望训练奖励和评测分数用同一把尺子的时候
`plugin`	对错可计算，而且计算便宜、本地：一次精确匹配、一个解析器、一个单元测试
`endpoint`	已经有东西在判这件事了 —— 一个编译服务、一个仿真器、一套内部评分系统。不要在插件里重写它

确认成功

tp env show alice/calculator-tasks@1.0.0

打印 manifest 声明的判定器。然后提交一次短跑，盯 Validation 标签页上的 reward 分布：对每条 rollout 都平在同一个值上的 reward 是一个返回常数的判定器，而它和一个模型完全做不到的任务看起来一模一样。

下一步

编写环境 · 编写评分标准 · 使用环境

开始

核心概念

训练模型

评测与服务

Agent 环境

扩展平台

协作

集成

参考

帮助

三种 kind

契约

判定失败是错误，永远不是零

怎么选

确认成功

下一步

​三种 kind

​契约

​判定失败是错误，永远不是零

​怎么选

​确认成功

​下一步

三种 kind

契约

判定失败是错误，永远不是零

怎么选

确认成功

下一步