把 Agent eval 的裁判从 LLM 换成 Jev：更快、几乎免费、结果还稳
把 Agent eval 的裁判从 LLM 换成 Jev：更快、几乎免费、结果还稳
上一篇我们聊 System One 时留了个尾巴：它是一种只给概率、不生成文本的决策接口。这篇就把它用在一个最痛的地方——Agent eval 的裁判。
现在的 Agent 评测，判分环节十有八九是"LLM-as-a-judge"：让一个前沿大模型读一段输出，然后生成一段 JSON，里面写着 {"score": 8}。这个做法能跑通，但三个毛病一直甩不掉：慢、贵、结果飘。
Jev 换了一条路：语言任务继续交给 LLM，决策点交给 Jev。判分，本质上就是决策，不该用生成模型来做。
目录
- 一、LLM-as-a-judge 的三宗罪
- 二、Jev 到底是什么
- 三、为什么"判分"不该用生成模型
- 四、怎么迁移：三条路径
- 五、把 eval 写成"题型"
- 六、收益实测
- 七、边界：什么时候还得用 LLM judge
- 八、上手
一、LLM-as-a-judge 的三宗罪
先看看现在这套为什么会卡。
第一宗罪：慢。 judge 要"先生成、后解析"。它得先吐一段解释，再吐一段 JSON，然后你 json.loads。一次判分动辄 2–3 秒；如果一条评测样本要判好几个维度，就是好几倍。
第二宗罪：贵。 每一步都在烧 token。让它判 1000 条、每条 5 个维度，账单能吓你一跳——而且这些 token 花出去只为了得到一个布尔值，性价比极低。
第三宗罪：飘。 最要命的。同一个输入，换个温度、换个 seed、甚至只是再跑一次，结果就可能不一样。于是一个很常见的场景出现了：你改了产品代码，评测分数涨了 3 个点，你以为是改进——其实只是 judge 这次心情不同。
更隐蔽的是格式塌陷：生成式输出偶尔会漏字段、多字段、JSON 不合法，你还得写一堆容错代码去"抢救"它。
二、Jev 到底是什么
Jev 是 TypeSafe AI 的 System One 决策模型。它不是语言模型，不生成文本——这是理解全部好处的起点。
它的调用形状简单到一句话：给它一段 state（可以是文本，也可以是结构化对象），再给它一组 questions，它返回每个问题的类型化答案 + 校准概率。
curl -sS https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "jev-latest",
"state": "用户反馈：付款后订单一直显示待处理，客服也没回复。",
"questions": {
"sentiment": {
"type": "choice",
"instructions": "这条反馈的整体情绪是？",
"criteria": {
"positive": "满意或赞扬",
"neutral": "陈述事实，无明显情绪",
"negative": "不满或抱怨"
}
}
}
}'问题有三种原语，正好覆盖 eval 里绝大多数判分动作：
| 原语 | 回答什么 | 返回字段 | 典型 eval 用法 |
|---|---|---|---|
| Choice | 从给定列表里选一个 | choice / probabilities / confidence |
分类、意图、路由对不对 |
| Score | 按有序 rubric 打分 | score / probabilities / confidence / legend |
1–5 分、A/B/C 档 |
| Noul | 某个命题是否为真 | noul（0–1 概率） |
是否幻觉、是否遵循指令 |
关键在这两点：
- 答案被"类型化"——选出来的一定是列表里的某一项，分数一定落在一个固定区间。不存在格式错误，不存在幻觉。
- 每个答案都带概率——
confidence或noul的 0–1 值告诉你"它有多确定"。你可以拿这个值当过滤门槛：高置信直接采信，低置信才升级人工或交给 LLM 细看。
原始响应长这样：
{
"model": "jev-1.13.0",
"answers": {
"sentiment": {
"type": "choice",
"choice": "negative",
"confidence": 0.98,
"probabilities": { "positive": 0.01, "neutral": 0.01, "negative": 0.98 }
}
},
"usage": { "input_tokens": 428, "output_tokens": 73 }
}三、为什么"判分"不该用生成模型
把这件事想成两条生产线：
- 生成模型：输入文本 → 输出文本。它的活是"写"。
- 决策模型：输入 state + 问题 → 输出概率分布。它的活是"判"。
"这条回答有没有幻觉？"——这是判断题。"给这段回答打 1–5 分"——这也是判断题。用生成模型做判断题，等于让一个作家去当裁判：他能写出一篇漂亮的判决书，但你真正要的只是那个"是/否"，而写判决书这一步既慢又贵，还引入了随机性。
graph TD
A["Eval sample: state + question"] --> B["LLM judge: generate reasoning then JSON"]
B --> C["Parse JSON, retry on format errors"]
C --> D["Slow, expensive, high variance"]
A --> E["Jev: one forward pass over state and questions"]
E --> F["Typed answer plus calibrated probability"]
F --> G["Fast, cheap, low variance"]Jev 的做法是一次前向、直接给概率。没有"生成解释"这一步，也就没有了解析、重试和格式塌陷。
DeepEval 官方博客把这套分工总结成一句话，很适合贴在评测流水线旁边：
language tasks stay with the LLM; decision points go to Jev. （语言任务留给 LLM，决策点交给 Jev。）
四、怎么迁移：三条路径
你不需要推翻现有的评测框架，按现状挑一条路径即可。
路径 A：LangSmith（最少改动）
如果你用 LangSmith 跑评测，官方已经把 Jev 接成 evaluator 了：
- 在 LangSmith 里填入 TypeSafe API Key。
- 新建一个 evaluator，类型选 LLM-as-a-Judge Evaluator。
- Provider 选 TypeSafe，模型选
jev-latest。 - 定义 state——放你要判的材料（模型输出、上下文），注意这里不要写"打分指令"。
- 加 questions——每个问题对应一个 feedback key，比如
is_faithful、tone_score。 - 开始跑。
好处是结构完全没变，只是把"裁判"从一个生成模型换成了决策模型。
路径 B：DeepEval（保留现有指标）
DeepEval 支持三种模式，可按指标切换：
| 模式 | 含义 | LLM 调用 |
|---|---|---|
llm（默认） |
纯 LLM judge | 有 |
hybrid |
LLM 负责抽取，Jev 负责决策 | 部分 |
system_one |
整个 test case 交给 Jev | 零 |
pip install typesafe-sdk
export TYPESAFE_API_KEY=...
# 全局切换
deepeval set-eval-mode hybrid
deepeval set-eval-mode system_one也可以只对某个指标生效：
from deepeval.metrics import FaithfulnessMetric
metric = FaithfulnessMetric(eval_mode="hybrid")推荐的迁移顺序是 llm → hybrid → system_one：先让 Jev 接管最确定的那几个决策点（比如忠实性的"是/否"），跑稳了再扩大。原则是——能确定判的就别让 LLM 生成。
路径 C：直接调 API（最灵活）
不想被框架绑住，就直接把判分写成一个 question 集合。SDK 调用示例：
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
with TypeSafeClient(model="jev-latest") as client:
response = client.system_one(
state=model_output,
questions={
"is_grounded": Noul(
instructions="这段回答是否完全由给定上下文支撑？"
),
"tone": Score(
instructions="语气是否专业得体？",
criteria=["很差", "一般", "不错", "很好"],
),
"verdict": Choice(
instructions="这次回答该判通过、需修改还是拒绝？",
criteria={
"pass": "可以接受",
"revise": "方向对但有瑕疵",
"reject": "有事实错误或违规",
},
),
},
)
print(response.nouls["is_grounded"].noul) # 0.97
print(response.scores["tone"].score) # 0.67
print(response.choices["verdict"].choice) # pass五、把 eval 写成"题型"
迁移的核心动作，其实只有一件事：把"生成一段评分文字"改写成"回答几个固定问题"。几条经验：
1. 一个问题只问一件事。 别写"这条回答是否准确、完整且语气好？"——拆成 is_accurate / is_complete / tone_score 三个问题。Jev 对同一个 state 上的多个问题是并行处理的，加问题几乎不增加延迟。
2. 用 Noul 做二值门。 "是否有幻觉""是否越权调工具""是否泄露隐私"——这些是布尔命题，直接上 Noul，拿来 noul >= 0.5 就是 yes。
3. 用 Score 做 rubric。 把 1–5 分写成一个有序的 criteria 列表，Jev 会返回期望位置 s = Σ i·P(i)，再归一化到 [0,1]。评分标准变成代码里的常量，不再藏在 prompt 里。
4. 用 confidence 做门槛。 高置信直接采信，低置信再走人工或 LLM：
if response.nouls["is_grounded"].noul >= 0.5:
verdict = "grounded"允许歧义时可以设三档：> 0.65 判 yes、< 0.35 判 no、中间标 borderline 单独看。system_one 模式下，metric.confidence 取的是最不决断的那个答案的置信度，正好可以拿来筛出"需要人看"的样本。
六、收益实测
LangSmith 的官方对比（Jev vs GPT-5.6 Luna、GPT-5.6 Terra、Claude Sonnet 4.6）：
| 指标 | Jev | LLM judges |
|---|---|---|
| 单次延迟 | 约 0.44 秒 | 2.16–2.83 秒 |
| 单次成本 | 约 $0.00035 | 高出一个数量级 |
| 整套判断成本 | $0.34 | $0.39 / $2.90 / $28.17 |
| 结果方差 | 低 92–913 倍 | 基准 |
| 与人类评审的一致性 | 逐项吻合 | — |
注意最后两行——"稳"这件事是有硬数据的。同一批样本重复判分，Jev 的方差比 LLM judge 低两个数量级，而且逐条决策与人类评审一致。这直接解决了第一节说的"第三宗罪"。
通用口径：TypeSafe 官方给的端到端延迟是 70–500ms（对比前沿 LLM 的 3–329 秒），整体约 193.6× 更快、444.6× 更便宜；LangSmith 文章里的说法是 约 200× 更快、约 450× 更便宜。
价格结构：输入 $0.042 / 百万 token（即 $42 / 十亿），输出 token 免费。因为判分不生成文本，输出几乎为零——这就是"基本免费"的来源。
把前面用户的三条诉求对上：
- 速度快 → 0.44 秒 vs 2–3 秒，约 5–6 倍；端到端口径下可达约 200 倍。
- 基本免费 → 输出免费 + 输入极低，单次约 $0.00035。
- 稳定一致 → 方差低 92–913 倍，逐项与人评审一致。
七、边界：什么时候还得用 LLM judge
Jev 不是要取代 LLM judge，而是把决策点从生成模型里剥出来。这几种情况，该用 LLM 还是用 LLM：
- 需要"读长文本、给理由"的开放式判断——比如"这段代码设计是否优雅"。生成模型能写清理由，Jev 只给分。
- 开放式问答里的细粒度语义比对——需要自由文本作为中间产物时，
hybrid模式（LLM 抽取 + Jev 决策）比纯system_one更合适。 - 两个裁判的分数不能直接比。 DeepEval 明确提醒：
system_one模式下的分数是 Jev 派生的，和 LLM 链路的比值不可互换。迁移时应把它当成同一指标的两种裁判，各自看趋势，别把新旧分数混在一张图里比大小。 - 阈值要显式校准。 Jev 给的是校准过的概率，但"多高算通过"是你的业务决定，别照搬 0.5。
八、上手
最快验证——直接调 API：
curl -sS https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"jev-latest","state":"<你的样本>","questions":{...}}'接进框架：
- LangSmith：加 TypeSafe provider，模型选
jev-latest。 - DeepEval：
pip install typesafe-sdk→deepeval set-eval-mode hybrid。 - SDK：Python 用
typesafe-sdk，JS/TS 用@typesafe-ai/sdk；AI SDK 7 提供experimental_decide。 - Agent skill：
npx skills add typesafe-ai/skills --skill typesafe-ai。
迁移清单，照着做就行：
- 列出评测里所有判分动作。
- 每个动作改写成一个 Choice / Score / Noul 问题。
- 用
hybrid模式先跑，把最确定的决策点交给 Jev。 - 对比新旧裁判的一致性和延迟。
- 稳了再推进到
system_one，并把低置信样本单独筛出来。
一句话收尾：
别再用 AI 当作家来写判决书了——让 AI 当裁判，直接给出判词和把握。
评测这条链路最该便宜的环节就是判分。把生成模型从裁判席上换下来，换成 Jev 这样的决策模型，你会立刻感受到三件事同时发生：跑得更快、账单更小、分数终于能信了。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
