有 Jev 与没有 Jev：一次可复现的结构化判断实测
TL;DR：让 LLM 做分类/打分/判定这类"给代码用的决策"，通用大模型是用一坨 JSON 文本把结论"说"出来，你再解析回去；Jev 这类 System One 模型是直接把带校准概率的类型化答案"交"给你。同一批客服工单、同一条真实 API，前者花了 5–11 秒、自报 0.9 的置信度却对真正模糊的样本过度自信，后者 1.3 秒并行评估 3 个问题、知道自己哪里不确定，成本还便宜约 10 倍。
1. 问题：LLM 是文本生成器，而代码需要的是决策
大语言模型被训练出来"生成给人类读的文本"。但当你的代码需要模型做一个判断——这条工单归哪个部门、这个评论是几分愤怒、这封邮件是否紧急——就会出现错配：
- 你想让模型输出一个
{department: "billing", confidence: 0.9}这样的结构化决策； - 模型实际输出的是"billing, confidence: 0.9, 我认为……"这样的文本；
- 于是你要写 prompt 教它 JSON 格式、开
response_format、写解析容错代码、维护一份 schema，还得祈祷它别在格式上犯浑。
一句话：结构是外围代码强加给模型的，而不是模型的原生输出。
2. 什么是 Jev / System One
Jev 是 TypeSafe 的旗舰模型，也是第一个 System One 模型。它不是文本生成器，而是决策模型：你把一段 state（比如客户消息）加上一组 typed questions（问题带类型）发给它，它并行、独立地评估每个问题，直接返回类型化答案：
| 问题类型 | 语义 | 返回 |
|---|---|---|
| Choice | 从给定集合选一个 | choice + 每个选项的概率 + confidence |
| Score | 按有序描述打分 | score + 每档概率 + confidence |
| Noul | 这个陈述是否为真（yes/no） | noul，0–1 的概率 |
没有文本生成，没有解析。多个问题在一次调用里并行评估，加问题几乎不增加耗时，也不会有"上下文互相污染"。
3. 实验设计（可复现）
任务：客服工单分流——对每条客户消息判定三个问题：
urgency（Noul：是否紧急/时间敏感）department（Choice：billing / technical / sales）frustration（Score：平静 / 有情绪但克制 / 非常愤怒）
测试集（5 条，覆盖不同难度）：急迫的技术故障、轻松的学生优惠咨询、暴怒的重复扣款投诉、语气平淡的 API 故障询问、一条"登录失败 + 订阅要续费"的歧义工单。
两条路径，完全相同的输入与问题定义：
- ✅ 有 Jev：
POST /api/v1/systemone，modeljev-1.13（一次调用并行评估 3 问） - ❌ 无 Jev：
POST /api/v1/chat/completions，通用模型deepseek/deepseek-chat-v3.1，一段 ~15 行的 system prompt 要求输出相同结构的 JSON +response_format: json_object，返回后自行解析
4. 结果总览
| 指标 | ✅ 有 Jev | ❌ 无 Jev | 差距 |
|---|---|---|---|
| 单条平均延迟 | 1.34s（并行评估 3 问） | 8.05s（生成 JSON 文本再解析） | 快 ~6 倍 |
| 5 条总成本 | $0.000091 | $0.000921 | 便宜 ~10 倍 |
| 输出 token | 71/条（结构化答案） | ~120/条（JSON 文本） | — |
| 需要写的解析/容错代码 | 0 | prompt + response_format + 解析器 | — |
| JSON 解析成功率 | 原生类型，无解析环节 | 5/5（本模型 + json_object，见 §6 免责） | — |
| 校准概率 | 有，且知道自己不确定 | 自报 confidence，不可靠 | 见 §5 |
两边 5/5 的最终结论（紧急/部门/愤怒等级）完全一致。所以差距不在"谁更聪明"，而在下面四处。
图：同批 5 条工单 × 2 条路径的真实调用对比（绿=有 Jev，黄=无 Jev）。
5. 四个真正拉开差距的地方
5.1 校准：这是最要命的一条
c4，一条真实的 API 故障工单：
“Since the latest update our API calls return 500s intermittently around peak hours. Is this a known issue? We’d like a status update.”
这条消息情绪很轻、也不算紧急。看两者的表现：
- Jev：frustration 判定在"平静 0.57 / 克制 0.43"之间摇摆，
confidence: 0.35—— 它诚实地承认自己不确定。 - 通用 LLM：给出 frustration=1（平静），并自报 confidence: 0.9。
这就是"校准"的区别。通用 LLM 的 self-reported confidence 是"说出来的话"，不是经过校准的概率；而 Jev 的概率分布是可以直接拿去做置信度门控（confidence-gated routing）的：if confidence < 0.5: 转人工。
c5，一条真正的歧义工单（登录失败 + 订阅续费）：
“I can’t log in and my card is about to be charged for renewal next week. Who do I talk to?”
- Jev：department = billing 0.84 / technical 0.16，
confidence: 0.76—— 分布如实反映了两难的拉扯。 - 通用 LLM：billing 0.7 / technical 0.25 / sales 0.05，自报 0.8。
Jev 的 0.76 置信度在提示你"这里有歧义，路由时小心"；LLM 的 0.8 只是它嘴上的数字。
5.2 延迟：一次并行 vs 生成一坨文本
Jev 一次请求内并行评估全部 3 个问题，1.15–1.54s；通用 LLM 要先生成一段 120 token 的 JSON 文本，4.9–11.1s。在你需要串行处理大量工单/请求时，这个差距直接变成吞吐量差距。
5.3 成本：结构化答案便宜约 10 倍
Jev 输出只有 71 个 token（类型化字段），通用 LLM 输出 ~120 token 的 JSON 文本。本实验 5 条用例：$0.000091 vs $0.000921，约 10 倍。
5.4 schema 脆弱性：没有 Jev 时的"日常摩擦"
无 Jev 这条路我真实踩了一个坑：Jev 的 Score 是 0 索引（legend: 0=平静, 1=克制, 2=愤怒），而我的对照 prompt 用了 1–3。两边语义结论对得上，但我必须自己在心里记住这个偏移——这就是"结构由外围强加"的代价：schema 漂移、索引不一致、字段缺失，都是解析层每天都在处理的事。
6. 免责与公平性
- 本实验选了 JSON 能力很强的模型（deepseek-chat-v3.1）+ 开了
response_format: json_object，所以 5/5 解析成功。换成更弱的模型、或忘了开 JSON mode，无 Jev 那条路的解析失败率会显著上升——这恰恰是"结构靠强加"的脆弱性。 - Jev 的能力边界：它只做结构化判断，不生成文本。需要模型"写一段解释/总结/长文"时，还是要通用 LLM 或两者组合（Jev 判定 + LLM 润色）。
- 概率是否真正"校准"（预测概率=真实频率）需要更大样本的评测，本实验只演示了行为差异；但 Jev 的设计目标就是经校准的决策模型，而通用 LLM 的 self-confidence 公认不可靠。
7. 什么时候用，什么时候别用
用 Jev 当你的"分类/打分/判定层"：
- 路由（intent routing）、工单/邮件/评论分流
- 审核、内容风控、紧急度判定
- 任何"给代码分支用的判断"，尤其是你想用概率做门控的场景
- 高吞吐、对延迟敏感
还是交给通用 LLM：
- 需要生成文本/解释/摘要
- 开放式的、无法拆成原子问题的判断
- 一个判断要综合大量独立因素 → 先拆成多个原子问题用 Jev 分别打分，再用你的公式加权（TypeSafe 官方也推荐这种 composite scoring）
8. 最小代码示例
# 有 Jev：类型化答案直接可用，零解析
curl https://openrouter.ai/api/v1/systemone \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "jev-1.13",
"state": "WHY DID YOU CHARGE ME TWICE?! I want my money back NOW.",
"questions": {
"urgency": {"type": "noul", "instructions": "The message conveys urgency or time-sensitivity"},
"department": {"type": "choice", "instructions": "Which team should handle this?",
"criteria": {"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions"}},
"frustration": {"type": "score", "instructions": "How frustrated does the customer appear?",
"criteria": ["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"]}
}
}'
# 有 Jev：代码直接分支，还能做置信度门控
r = client.system_one(model="jev-1.13", state=msg, questions=qs)
if r.answers["urgency"]["noul"] > 0.8:
route_to("urgent_queue")
if r.answers["department"]["confidence"] < 0.6:
route_to("human_review") # 歧义样本，人工兜底
9. 结论
LLM 是文本生成器，不是决策器。当你需要给代码用的判断时，"无 Jev"的路线是在逼一个文本生成器输出 JSON，再写一整套解析容错代码去兜底；"有 Jev"的路线是让模型直接交出类型化 + 带校准概率的答案。
本次实测：最终判定一致，但 Jev 在置信度校准、延迟、成本、schema 稳定性四个维度全面胜出，而它唯一的代价是"不生成文本"——这本就不是这类任务需要的。
数据与方法：5 条客服工单 × 2 条路径，真实 API 调用。Jev 经 OpenRouter System One 端点（
typesafe/jev-1.13）调用；对照组deepseek/deepseek-chat-v3.1。脚本与原始结果可复跑。交互版对比图见 下图。
1008
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
