什么是Jev?

发表于 |

最近几天，Jev 把时间线刷穿了：TypeSafe AI 出圈、LangChain 当天接集成、Vercel / Cloudflare 跟着上架。评论区两种声音最吵——「又一个便宜小模型」和「Agent 时代的 if」。

两种都没说准。Jev 故意不会聊天、不会写文、不会写代码。它干的事更土、也更狠：把程序里那些「语义上糊、规则写不死」的判断，变成带概率的结构化返回值。

一句话：Jev = 给软件用的「智能 if」——喂 state + 闭集 questions，一次并行拿回概率答案；模型负责模糊判断，代码负责精确动作。

先看缺口：Agent 里真正贵的是什么

Agent 环路上，真正烧钱、拖尾延迟的，往往不是最后那句回复，而是中间那一堆小判断：

决策点 真实例子
路由 工单去账单组、技术组，还是销售？
分级 P0 / P1 / P2？客户怒到什么程度？
门禁 这次 bash / 转账要不要拦？
选模 Luna 够不够，还是必须上 Sol？
校验 这段引用是否真的支撑结论？

以前两条路：

  1. 手写规则 / 传统分类器：快、便宜，语义一岔就碎。
  2. 聊天 LLM + structured output：聪明，但自回归吐 JSON，又慢又贵；schema 还可能歪，自报「95% 确信」常常虚高。

Jev 卡在这个缝里：模糊语义交给模型，权限、分支、副作用留给你的确定性代码。

1
2
3
4
5
6
7
8
state（当前上下文）
  + questions（你预先钉死的答案空间）
        ↓
   Jev（并行闭集判断）
        ↓
answers（noul / choice / score + 概率）
        ↓
你的 if / 路由 / 队列 / 确认框

什么是 Jev

Jev 是 TypeSafe AI 于 2026-09-15 开放 Early Access 的首个 System One Model。

项 现状
发布方 TypeSafe AI（创始人 Diogo Almeida，InstructGPT / ChatGPT 相关背景）
版本 jev-1.13.0（jev-latest / jev-preview 目前都指向它）
形态 托管 API，权重未开源
端点 POST https://api.typesafe.ai/v1/systemone

官方定位很硬：

放弃字符串生成，换取类型安全的结构化输出、并行采样、以及可校准的概率。

所以分工该这样记：

要做的事 用谁
写回复、写代码、多步规划、解释推理 生成式 LLM
分类、路由、打分、是否、门禁、选模 Jev
生产系统 LLM 负责「说 / 想」，Jev 负责「判」

最小请求：

1
2
3
4
5
6
7
8
9
10
{
  "model": "jev-latest",
  "state": "Stripe 接了三天一直失败，订单在掉，请尽快处理。",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "这条消息是否表达了紧迫性？"
    }
  }
}

返回不是解释，是程序能直接吃的数：

1
2
3
4
5
6
7
8
9
{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": {
      "type": "noul",
      "noul": 0.95
    }
  }
}

然后代码说了算：

1
2
3
4
5
6
if urgent >= 0.9:
    page_on_call()
elif urgent >= 0.6:
    queue_for_review()
else:
    normal_queue()

这就是 Jev 的产品哲学：模型给判断，代码握方向盘。

名字从哪来（两个隐喻够用）

  1. System One —— 借自卡尼曼《思考，快与慢》。System 1 是快、直觉式判断；System 2 是慢、刻意推理。Jev 被定位成软件里的「快判断层」；复杂推理仍留给推理模型。
  2. Jev —— 取自经济学家 William Stanley Jevons。杰文斯悖论：蒸汽机更高效后，煤的总用量不降反升——更便宜会创造更多用途。TypeSafe 的赌注是：决策单价掉一个数量级，你会在以前绝不会调 LLM 的地方塞满判断。

和 LLM structured output：表面像，骨子不同

维度 聊天 LLM + schema Jev
输出 仍在生成字符串，再校验 在你给定的答案空间上直接出分布
采样 自回归，逐 token 多题对同一 state 并行评估
类型错误 可能 schema 失败 / 截断 成功响应里不能出现 schema 外取值
概率 自报置信度常不可靠 训练目标含 概率校准（RLCD）
延迟（官方） 同形态问题可达数秒～数百秒 约 70–500ms 端到端
价格（官方） 输入常见 $0.2–$10 / MTok，输出更贵 输入 $0.042 / MTok，输出免费
擅长 生成、解释、开放规划 闭集判断、路由、门禁

厂商 workflow eval 有「约 200× 更快、400× 更便宜」一类 headline——那是他们选的工作流上的 Pareto 上沿。当作上限，用你自己的 state 体量测一遍。

还有一句要拆开听：「不能幻觉」。

  • 类型层面：不会吐出你没定义的选项——结构性保证。
  • 语义层面：仍可能判错。合法但错误的类别，是业务错误，不是 schema 错误。

幻觉没了类型形状，不代表判断永远正确。自动化系统里，这两件事必须分开处理。

RLCD：为「说 0.9 就得大约九成对」训的

TypeSafe 把后训练叫 RLCD（Reinforcement Learning for Calibrated Decisions）：

方法 主要优化什么
RLHF 人类更喜欢的回答（聊天、文风）
RLVR 可程序验证的正确性（数学、代码等）
RLCD 闭集决策 + 概率与真实频率对齐

校准是群体统计：大量「说 0.9」的样本里，大约应有九成成立。它不保证某一个 0.9 一定对。

公开材料没有完整损失公式、可靠性图、ECE 等第三方复现。生产上仍要：用你的标注集画 confidence–accuracy 曲线，自己定阈值。

三种原语：Noul / Choice / Score

一次请求可塞很多题；官方强调它们对同一 state 独立并行——多加几题主要多付一点输入 token，延迟几乎不怎么涨。这才是「智能 if 可以铺满流水线」的物理基础。

Noul：是不是？

返回 noul ∈ [0, 1]，表示「是」的概率。没有单独的 confidence 字段。

1
2
3
4
5
6
7
8
9
10
{
  "refund_requested": {
    "type": "noul",
    "instructions": "客户是否明确要求退款？",
    "criteria": {
      "true": "明确要求退钱或取消扣款",
      "false": "只是抱怨或询问政策，未要求退款"
    }
  }
}

坑：

  • 靠近 0.5 往往是「分不清」，不是「中等程度」。要量程度，用 Score。
  • 问题写成「高分 = 是」；别绕双重否定。
  • noul=0.72 ≠「业务成功概率 72%」，只是「这句话像不像在要退款」。

Choice：在这些里选哪个？

无序分类。返回 choice、完整 probabilities、以及反映分布集中度的 confidence。最多 255 候选。

1
2
3
4
5
6
7
8
9
10
11
12
{
  "department": {
    "type": "choice",
    "instructions": "哪个团队应处理这条消息？",
    "criteria": {
      "billing": "扣款、发票、退款、订阅",
      "technical": "故障、宕机、集成问题",
      "sales": "询价、升级、新开户",
      "other": "以上都不适用"
    }
  }
}

候选可能不全时，务必留 other / none——否则模型只能硬选一个。criteria 写边界，不写形容词。

Score：落在哪一档？

有序等级（2–10 档）。score 是等级编号的概率加权均值，可以落在两档之间。

1
2
3
4
5
6
7
8
9
10
11
{
  "severity": {
    "type": "score",
    "instructions": "问题有多严重？",
    "criteria": [
      "外观问题，不影响功能",
      "功能受损，但有替代路径",
      "阻断使用，没有 workaround"
    ]
  }
}

写 Score 的关键：描述可匹配的情境，别写「中等 / 较高」。每个等级尽量一个维度；「又准时又聪明又资深」应拆成多个 Score，在代码里合成。

Confidence：第二个决策轴

Choice / Score 的 confidence 来自概率分布形状：

  • 集中在一个选项 → 高
  • 摊得很开 → 低

它回答「模型有没有清晰偏好」，不是「这次一定正确」。生产里常见三档：

1
2
3
4
5
6
7
8
9
if answer.confidence < 0.5:
    route_to_human()
elif answer.choice == "check_balance":
    show_balance()
elif answer.choice == "approve_transfer":
    if answer.confidence > 0.9:
        confirm_then_execute()
    else:
        ask_user_to_confirm()

阈值跟错了的代价挂钩：查余额可以松，转账必须紧。先保守，用线上回流再调——别把官方 demo 里的 0.5 / 0.9 当圣杯。

State 怎么喂才不废物

state 可以是字符串、JSON 对象或文本数组。实践建议：

  1. 尽量用对象，问题里用反引号点路径：`order.charges`，减少指代歧义。
  2. 只塞本题需要的字段。无关历史、整本长文档会稀释信号（同样有 context rot）。
  3. 预算（官方）：整请求约 64K token；state + 最长单题 ≤ 约 32K。
  4. 目前只吃文本，没有图 / 音 / 视频。
  5. 英文效果官方最好；中文等 CJK 可用但不等同——关键路径单独评测。
  6. 问题 ID 不进模型。refund_requested 当 key 只方便你读代码；真正生效的是 instructions。

接到 Agent / Harness：这才是热度的理由

Jev 最有感的地方，不是「替代 LLM」，而是把 Agent 环上那些高频小判断拆出去。

LangChain 已提供 TypeSafeClassifier（langchain-typesafe），以及实验性中间件：

  • Model routing：用 Jev 在 cheap / powerful 模型间选型。
  • Auto Mode / 工具门禁：执行 bash 等高风险工具前，先过一道风险判断。
1
2
3
4
5
6
7
8
9
10
11
┌─────────────────────────────────────┐
│  LLM：规划、生成、工具参数、解释     │
└──────────────┬──────────────────────┘
               │ 每一步旁边的「判」
               ▼
┌─────────────────────────────────────┐
│  Jev：路由 / 打分 / 是否 / 门禁      │
└──────────────┬──────────────────────┘
               │
               ▼
         你的确定性代码与工具

也适合：客服分拣、邮件 triage、简历初筛、引用是否支撑结论、贵模型调用前的便宜门禁。

接入示意（LangChain）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
from langchain_typesafe import Noul, Choice, Score, TypeSafeClassifier

classifier = TypeSafeClassifier()  # 读 TYPESAFE_API_KEY

resp = classifier.invoke({
    "state": {
        "ticket": "导出按钮在 Safari 设置页会崩，Chrome 正常。"
    },
    "questions": {
        "urgent": Noul(instructions="是否需要立刻处理？"),
        "category": Choice(
            instructions="这是什么类型的工单？",
            criteria={
                "bug": "功能异常或崩溃",
                "feature": "新需求",
                "billing": "账单相关",
                "other": "其他",
            },
        ),
        "severity": Score(
            instructions="严重程度？",
            criteria=[
                "外观问题",
                "有 workaround 的功能受损",
                "阻断使用",
            ],
        ),
    },
})

print(resp.nouls["urgent"].noul)
print(resp.choices["category"].choice, resp.choices["category"].confidence)
print(resp.scores["severity"].score)

原生 SDK / curl 走同一 System One 端点；也可经 Vercel AI Gateway 的 typesafe-ai/jev 试用。

生产钉死版本号（如 jev-1.13.0），别只绑 jev-latest——置信度阈值会跟着别名一起飘。

规格速查（公开资料）

项目 值
版本 jev-1.13.0
输入价 $0.042 / 百万 token
输出价 免费
上下文 ~64K / 请求
Choice 上限 255
Score 档位 2–10
默认限流（会动态调） 250k 输入 token/s，1200 RPM
访问 Early Access / 等待名单；权重未公开

参数量、网络结构、训练数据明细、论文：尚未公开。写进架构评审时，把「厂商声明」和「你自己测到的」分开写。

什么时候不要用 Jev

  • 需要生成散文、代码、计划书、解释。
  • 需要开放式多步推理、复杂数学证明。
  • 答案空间事前定不下来，或候选经常爆炸式变化。
  • 专业窄域且还没在自己的分布上验证校准。
  • 把概率数字直接当「业务 KPI 成功率」。

工程上我会怎么用（个人判断）

如果明天要在现有 Agent / 客服系统里落地，顺序大概是：

  1. 先拆决策点：把「该不该调大模型」「该不该执行工具」「工单去哪」从 prompt 里抠出来，改成闭集题。
  2. 先上 Noul / Choice：边界清晰、收益立刻可见；Score 等标注稳定后再铺。
  3. confidence 双轴：低置信走人，高置信自动，中间确认——阈值用你的错判代价定。
  4. 钉版本 + 回放集：10～50 条真实 case 做回归；别名升级当发版事件处理。
  5. LLM 仍是大脑：Jev 替代的是环上的分类器，不是生成器。

这波热度的底层叙事，不是又一个榜上分数，而是：

决策单元成本掉下来之后，软件里可以塞多少个「智能 if」。

小结

Jev 不是「下一个 GPT」，而是把 AI 从「会聊天的同事」推进到「能嵌进 if 的函数」：

  1. 闭集：答案空间你先定好。
  2. 并行：多题共享 state，一次拿回分布。
  3. 概率 + confidence：让不确定性能进业务代码。
  4. 和 LLM 互补：生成留给 LLM，判断留给 Jev。

参考

（资料整理截止约 2026-09-21；价格、限流、别名指向以官方控制台与文档为准。）