不生成文本的模型有什么用：读 TypeSafe 的 Jev

1. 第一眼以为是分类 API，读下去发现不是

这周 X 上很多人转 TypeSafe AI 的发布：新公司、第一款模型 Jev，自称是一类新模型“System One Model”。创始人 Diogo Almeida 来自 OpenAI，做过 RLHF 与 InstructGPT 相关研究，公司刚走出 stealth 并开放 early access。

我第一反应是：这不就是个分类 API 吗？把官方博客、社区教程和自己上手试的结果对照着看才发现，值得写的原因不在分类本身，而在它回答了一个我平时绕不开的问题：

用 LLM 做判断时，真正贵的东西不是 token，而是字符串。

2. Jev 一句话是什么

Jev 不生成文本。它接收一份“状态”和几个“类型化问题”，一次性并行返回带概率的答案：

text8 行

state（工单、事件、检索片段……）
  + questions（你预先定义好的问题）
        ↓
Jev：对同一份 state 并行求值
        ↓
typed answers + probabilities + confidence
        ↓
你的代码：分支、排序、路由

官方文档只给了三个原语，Choice、Score、Noul：

text3 行

Choice：二选一或多选一，返回 choice + 每个选项的概率 + confidence
Score：在 2–10 级量表上打分，返回 score + 分布 + confidence
Noul：这句话对不对，返回 0–1 的概率

拿教程里的工单例子：

json3 行

state: "Stripe 接入失败 3 天了，丢单了，尽快帮忙！"
questions:
  is_urgent: 这件事是否紧急？

返回大概是 is_urgent = 0.999。代码拿到这个数字就能直接排优先级，不用解析任何文本。

多问几个问题几乎不增加耗时，每个问题独立对同一份 state 求值。教程里建议反直觉的一点：别省问题，一次问全，让代码决定用哪些答案。

社区把这个分工总结得很直接：大模型负责生成与推理，Jev 负责所有中间小判断——要不要再搜、这个结果有用吗、该不该转人工、下一个工具选谁。常见的挂法有四种：model routing（这次问谁）、context 压缩（这段留不留）、RAG 过滤（这条检索引文用不用）、agent 工具筛选（下一步调哪个工具）。共性都是小判断、大批量、对延迟敏感，正好落在 Jev 的主场。

工具链也已经有人铺了：jevify 专门扫描存量代码，找出脆弱的字符串解析和 LLM 顺手判断，逐个生成 question pack；typesafe-cli 这类 CLI 加 skill 的组合，方便在本地快速试验问题写法；还有人把 Jev 嵌进自己的写作改写 skill，当“重复 / 空泛检测器”用。这都是同一句话：把可封闭的判断从生成里拆出来。

3. 为什么不用 LLM 顺手做判断

因为 LLM 的输出是字符串，字符串可以是任何东西：正常答案、幻觉、拒答、格式错误。进业务系统之前，必须再过一遍解析和校验。官方博客的对照表把这点说得很直白：

对比角度	LLM	Jev
输出	自由文本，用前要解析校验	类型化答案，不可能出现类型错误
采样	逐 token 串行	一次并行返回全部答案
耗时	秒到分钟	70–500ms
费用	输出 token 更贵	输入 $0.042 / MTok，输出免费
置信度	问也白问，普遍过度自信	每个答案自带校准过的概率

类型安全在这里是数学保证：模型只给允许的选项打分，没有任何一条路径能输出第四个选项。官方说，一个反例就能证伪这条 claims，目前还没出现。

4. 真正打动我的是校准过的置信度

Jev 用 RLCD（Reinforcement Learning for Calibrated Decisions）训练，优化目标不是人类偏好，而是概率与结果的一致性：说 90% 的那些判断，大约 90% 是对的。

这行代码以前写不出来：

python4 行

if result["team"]["probability"] > 0.9:
    route_to(result["team"]["answer"])
else:
    send_to_human()

LLM 从不给你诚实的数字。一个任务能做对 95%，却不告诉你哪 5% 会错，就没法自动化。校准置信度把“做判断”和“决定信不信”分开了：模型负责前者，阈值写在你的代码里，改阈值不需要改提示词。

X 上有人用游戏实测验证了这点：只接受高置信度的走子，低置信度按既定规则兜底，24 次里约 81% 的高置信度走子是对的。概率和正确率确实同向变化。

落地时有一点值得坚持：同时保留原始置信度和校准后置信度。前者是模型当时的确定程度，后者是历史上这种确定靠不靠谱。调阈值、算校准误差、复盘线上事故，都靠这一对数字对得上。

5. “不会幻觉”要准确理解

容易误读的一句声明，拆开说才严谨：

Jev 不会返回 schema 之外的值，这是结构保证，不是统计结论。
Jev 仍然会答错，错的是合法值。但答错时概率通常偏低，可以被阈值拦截后转人工。
官方自称的 0%，自己也承认不是测出来的，是断言；拿来对比的 45.5% 是单个离群模型，多数模型在 0.58%–13.2% 之间。

所以正确的表述是：它消灭的是“编造答案”这类故障，而不是“判断失误”。后者靠校准概率去兜。

6. 它的位置是级联的前端，不是 LLM 的替代品

几篇教程的共识很一致：别想着替换 LLM。标准用法是级联：

text5 行

Jev：路由、分诊、打分、守卫（System 1，快而多）
  ↓ 难的少数
LLM：写作、推理、解释（System 2，慢而少）
  ↓ 发出前
Jev：再检查一遍回复是否合规

落回我的后端视角，这和标注质检里的条件更新是一个味道：检查逻辑不靠调用方自觉，靠服务端说了算。Jev 承担“便宜且诚实的判断”，Java 服务继续管权限、状态、审计与兜底动作。Agent 负责理解意图、提出动作，但动作能不能执行，由确定性规则和置信度阈值决定。

从这里出发，真正值得追的问题其实只有一个：

Agent 热路径里的封闭决策，什么时候由这类小判断模型完成，什么时候必须升级到慢而贵的推理模型？

重点不是“更快分类”，而是判断质量、校准、弃权、自动化安全与服务成本五项一起看。

7. 先别急着抄，局限同样具体

官方文档有个少见的诚实页面讲失效模式，教程们也都强调了，出发前先看：

text5 行

按字面答题：否定、限定词都照单全收，题没写清楚就是你的问题
不会算数：计数、日期先后、距离都不靠谱，数字判断留给代码
context rot：state 里塞无关材料，准确率会掉，先检索过滤再判
state 默认非对抗：用户可控内容能带偏答案，威胁模型自己处理
不生成：要摘要、要代码、要解释，找 LLM

基准方面，官方 workflow 评测以 GPT-6 Astra 与 Fable 5.1 的均值做参考答案，且 LLM 侧用的是自家 wrapper（更准但更慢更贵），193× 快、444× 便宜这类数字大概率是上限。看趋势可以，别当生产承诺。

上手试下来，最顺的还是工单分诊那一类：状态短、问题明确、错了可转人工，正好是校准概率的主场。

8. 从演示到生产：还缺的三样东西

Jev 的演示停在“返回带概率的答案”，生产系统要的是“答案可以直接执行”。中间至少还缺三样：统一的返回形状、单独的校准层、独立的策略层。

一条典型的热路径长这样：

text22 行

State / Evidence
      │
      ▼
Candidate Builder
      │
      ▼
Decision Model
      │
      ▼
Probability Distribution
      │
      ▼
Calibration
      │
      ▼
Policy Gate
 ┌────┴────────────┐
 │                 │
High Confidence    Uncertain
 │                 │
 ▼                 ▼
Execute        System-2 Reasoner

返回形状值得先定下来，而且每个返回同时带原始置信度和校准后置信度。下面三段 JSON 是按这个思路整理的示意，不是官方接口原文：

Choice，以工具路由为例：

json11 行

{
  "primitive": "choice",
  "decision": "kubernetes",
  "distribution": {"kubernetes": 0.82, "prometheus": 0.10, "loki": 0.05, "github": 0.01, "none": 0.02},
  "confidence": 0.82,
  "calibrated_confidence": 0.76,
  "abstain": false,
  "fallback_required": false,
  "calibration_profile": "mcp-router-v1",
  "latency_ms": 24.7
}

Noul 只给 true / false 是不够的。重试、升级、审批、补证据这些分支写得出来，前提是返回里有双边概率、用到的阈值和是否弃权：

json9 行

{
  "primitive": "noul",
  "decision": true,
  "p_true": 0.91,
  "p_false": 0.09,
  "calibrated_p_true": 0.84,
  "threshold": 0.80,
  "abstain": false
}

Score 也不适合当成连续回归。严重程度这类问题用有序分档更诚实，再附一个期望值方便排序：

json6 行

{
  "primitive": "score",
  "distribution": {"info": 0.01, "warning": 0.11, "high": 0.68, "critical": 0.20},
  "decision": "high",
  "expected_score": 2.07
}

9. 模型、校准、策略分三层

分层的理由很实际：上层只关心 choice / noul / score 三个调用，不关心底下是微调模型、专用分类头、编码器，还是直接用 LLM 做结构化输出。实现可以换，调用方的分支、阈值和审计逻辑不用跟着重写。

校准应该单独一层。模型只给原始概率，校准层再按场景做温度缩放或保序回归。同一个模型在工具路由和审批场景下，错判的代价完全不同，校准参数值得按“模型 × 问题类型 × 业务域”分别拟合，而不是全模型共用一个系数。

策略再单独一层。阈值不是模型属性，而是策略属性：只读工具可以覆盖 80% 的请求、容忍约 2% 的风险；破坏性写操作可能只覆盖 40%，要求风险压到 0.1%，并继续复用 OPA、人工审批、沙箱这些已有控制。判断层只输出校准概率与弃权信号，不自己重新发明安全控制。

可观测性也值得从第一天留好。每个决策记一次 agent.decision span，带上问题类型、原始与校准置信度、阈值、动作、延迟和是否升级。以后 Agent Trace 里看到的应该是这样一串：“19ms 的工具路由 → kubectl → 11ms 的证据判断 → 1.8s 的慢速推理 → 9ms 的审批判断”。

10. 除了准确率，生产里更值得看三个数字

Agent 的决策大致分四类：工具路由（选谁）、审批（过不过）、严重程度（排多前）、升级（本地执行还是转慢速推理）。评测时值得把“选得不够理想但可接受”和“选了不该选的危险动作”分开记，前者是体验问题，后者是安全问题。

除准确率与校准误差之外，三个数字对生产更直接：

误自动化率。FAR = 答错且自动执行 / 自动执行，再看高置信度错误率 P(答错 | 置信度 ≥ τ)，τ 取 0.90 / 0.95 / 0.99。总体 93% 说明不了什么，置信度 0.95 以上的自动动作错了多少，才决定能不能半夜自动扩容。
风险-覆盖率曲线。阈值从 0.50 扫到 0.99，看覆盖率下降时风险是否单调下降。阈值选型交给策略，不写死在模型里。
决策成本。至少记录 P50 / P95 / P99 延迟、显存、输入与生成 token、吞吐。最后看的不是准确率第一名，而是单位成本下的性价比曲线。

验证可以从几百条工具路由样本起步，先覆盖换序、改写、加干扰项这类便宜的扰动，链路跑顺再扩大。真正有区分度的问题往往不是谁准确率最高，而是哪些样本根本不适合快判断，必须升级。

11. 三个值得继续追的问题

顺着这个思路，有三个问题比“准不准”更有价值：决策专用的后训练到底值多少钱；抛弃生成词表头、换专用分类头是否值得；Agent 的判断到底需不需要自回归大模型，一个几百 M 参数的编码器是否够用——如果够用，它的延迟和校准可能反而是最适合生产的那一个。

收束成一句话：这类模型的意义不是替代推理模型，而是把 Agent 运行中可封闭定义、可校准、可验证的判断，从生成式推理里拆出来，用低成本模型完成；当不确定性、开放性或风险超过策略边界时，再显式升级到慢速推理。

参考资料

← 返回文章