用 Jev 当评判模型：给 LLM 回答打出带类型的判定

这个评判工具检查什么

上面的示例是在评判一个客服机器人的回答：它本应依据知识库里的一段说明来作答。一次调用里问了三个问题：

三个问题仍然只收 1 点，而且它们针对同一份 state 并行作答，多问几个几乎不增加延迟。示例里的回答和参考资料相矛盾——它说免费账户不能用 API——所以值得看的是 correct 有多明显地偏向"否"，以及 verdict 选的是 reject 还是 revise。

怎么写好评判问题

一个 Noul 只管一种失败。 "这个回答好不好？"把准确性、语气和完整度揉成一个概率，拿到了也没法据此行动。"回答是否与参考资料矛盾？"只有一个含义。你关心的其他失败，各自再加一个 Noul，比如"回答是否承诺了政策不允许的事？"

给 Noul 写上 criteria。 用 true 和 false 各一句描述告诉 Jev 界线在哪里：

{
  "type": "noul",
  "instructions": "Does `answer` state or imply something that contradicts `reference`?",
  "criteria": {
    "true": "The answer asserts a fact the reference contradicts.",
    "false": "Everything the answer claims is supported by, or absent from, the reference."
  }
}

严重程度重要时用 Score。 大多数输出都是"部分正确"时，一个每级带简短描述的五级评分表，比是非题更能把回答排出先后。

把决策放进 Choice。 直接问 ship / revise / reject，拿到的是一组针对行动的概率分布，比自己组合三个数字更好分流。另外两个问题留着做日志和调阈值。

更多关于问法的内容，见设计 Jev 能回答的问题。

从一次检查到流水线里的一步

1. 收集标注样本。 50 到 200 条真实回答，每条由人标好好坏，就足以看出 Jev 的概率在哪里把它们分开。
2. 定三个区间，而不是一个阈值。 Jev 有把握的直接放行，中间区间升级给更强的评判模型或人工，其余拦下。在公开试验中，这种做法让 Jev 独自处理掉了约 80% 的队列。
3. 记录模型版本。 每次响应都带有 model 字段（例如 jev-1.13.0）。把它和每条判定一起记下，版本变化时重新校验阈值——JevStation 在部署层固定模型，不需要你在请求里指定。
4. 从流水线里调用。 同样的评估可以用 API Key 通过 System One API 调用，扣点规则和试验台一样。

信任之前先验证

• 拿自己的标注对比，而不是拿示例。 在别人数据上好用的阈值，不是你的阈值。
• 测试问法。 一个 Noul 和它的否定问法，或者同一个意思写成 Noul 和写成 Choice，可能给出不同的概率。阈值要在你实际上线的那组问题上调。
• 关注中间区间。 如果大多数回答都落在两个阈值之间，说明问题太笼统——拆开它。

哪些时候 Jev 不是合适的评判模型

• 你需要写出来的理由，给审核人、审计记录，或者反馈给被评判的模型。
• 判定涉及计数、算术或日期。 TypeSafe 自己把这些列为弱项。
• 被评判的系统能调用评判模型。 分数便宜又稳定，反而让对方很容易摸索出什么能蒙混过关。

这些局限背后的证据，以及本页引用的试验数字，都带出处整理在用 Jev 当评判模型：一个是非题能抓住什么、会漏掉什么。