Jev 与 LLM-as-a-Judge 对比：评测该用哪个？
如果你现在在跑 LLM 评测，大概率用的就是 LLM-as-a-Judge：把评分标准贴进一个聊天模型，让它给输出打分，然后祈祷回复能被解析。TypeSafe AI 在 2026 年 9 月发布了 Jev——一个专为判断题、选择题、打分题设计的 System One 判断模型——这套流程从此有了一个专用替代品。这篇对比两种做法，说明专用判断模型会如何改变你评测回路的可靠性和成本结构。
TL;DR： LLM-as-a-Judge 是让聊天模型客串评测员，你 inherits 的是散文输出、格式漂移和生成成本。Jev 是判断模型：打分是它的原生题型之一，答案以带 confidence 的结构化 JSON 返回，输出极短让单次评测成本很低。推荐做法是 Jev 当默认打分器，聊天 LLM 只留给少量需要书面论证的场景。
LLM-as-a-Judge 的痛点
这些问题不致命，但在生产里每一个都会出现：
- 输出解析。 judge 用散文回答。你写正则，或者在 prompt 里写”只回 JSON”，然后处理那些偏偏加了开场白的运行。
- 格式漂移。 prompt 稍微改一下，分数格式就跟着变。每个消费分数的地方都得做防御性解析。
- 位置偏置与长度偏置。 聊天 judge 偏爱先出现的选项和更长的答案——这是这个模式的经典失败形态。
- 评分标准被稀释。 rubric 要和 prompt 里其他内容抢注意力；上下文一长，模型会悄悄忽略其中一部分。
- 单次打分成本。 你按生成 token 付费，买到的是一段最终浓缩成一个数字的话。
Jev 改变了什么
Jev 就是为这类问题设计的。打分是它的原生题型——你定义量表，模型返回量表上的数字——与判断题（yes/no/unclear）和选择题（N 选一）并列。对评测真正重要的差异：
| 维度 | LLM-as-a-Judge（聊天模型） | Jev（判断模型） |
|---|---|---|
| 输出 | 需要解析的散文 | 结构化 JSON：answer + confidence + rationale（示例数据，example fixture） |
| 量表处理 | rubric 写成散文，分数格式即兴发挥 | 你定义量表，响应里回带 scale 字段 |
| confidence | 不给，除非 prompt 诱导 | 每个答案自带 |
| 成本形态 | 按生成计价的段落 | 短结构化输出；实时价格见 OpenRouter |
| 偏置面 | 位置、长度、遵循 rubric 等偏置 | 有界答案空间降低了偏置，但不能归零 |
| 书面理由 | 整段输出就是理由 | 一个简短的 rationale 字段 |
rationale 字段值得强调：你依然拿得到”为什么”，只是从一篇作文变成一个有界字段。下面是通过 OpenRouter 的 OpenAI 兼容端点发起打分调用的样子：
# Confirm the exact model slug on the OpenRouter model page
curl https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "typesafe/jev-1.13",
"messages": [
{
"role": "user",
"content": "Scoring question (1-10): does this product FAQ answer fully resolve the question? Answer: \"...\""
}
]
}'请求体是标准 chat completions 结构，评测语义体现在问题的措辞里。
解析后的结果——示例数据（example fixture），正式字段名以官方文档为准：
{
"answer": 8,
"scale": [1, 10],
"confidence": 0.86,
"rationale": "The answer covers the main symptom and the fix but omits the account-level permission prerequisite."
}Python 版本，简短但生产可用：
import json, os, requests
resp = requests.post(
"https://openrouter.ai/api/v1/chat/completions",
headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
json={
# Confirm the exact model slug on the OpenRouter model page
"model": "typesafe/jev-1.13",
"messages": [{"role": "user", "content": "Scoring question (1-10): does this product FAQ answer fully resolve the question? Answer: \"...\""}],
},
timeout=30,
)
grade = json.loads(resp.json()["choices"][0]["message"]["content"])外层是标准 OpenAI 兼容响应壳；grade 是示例数据（example fixture）——响应形态为示例，正式字段名以 typesafe.ai 官方文档为准。
实际好用的混合模式
“完全替换”很少是正确框架。效果最好的是两层设计：
- Jev 给所有样本打分。 每个候选输出都过一次打分或判断调用。单次评分成本低、解析永不崩，每次打分都带 confidence。
- confidence 决定升级。 低于阈值的样本交给聊天 LLM 做完整的书面评审——或直接转人工。阈值怎么定，《Jev 置信度与兜底策略》有完整方法。
- 聊天 LLM 处理残余。 只有模糊样本才为生成的散文付费。
简历筛选场景就是这个结构：Jev 按固定量表批量给匹配度打分，只对你信任的分数段安排面试。完整流程见 resume fit scoring 那个 case。
什么时候聊天 judge 仍然是对的选择
- 你的 rubric 需要跨多份长文档做比较推理，并给出书面论证。
- 你需要 judge 给作者产出反馈文字，而不只是一个分数。
- 你在原型阶段、rubric 每小时都在变——标准未定之前，用散文迭代更快。
本文适用版本 Jev 1.13。