# Jev 输出格式不会错，决策就一定对吗？

**Summary:** TypeSafe 的 Jev 在四工作流评估中仅用 0.4 秒返回带概率的类型化决策。我喜欢这种受约束的接口，但有效的 Schema 无法告诉我这个决策是否正确。

- Canonical: https://markhuang.ai/zh/news/jev-schema-guarantee-wrong-decision
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-15
- Section: News
- Tags: Jev, TypeSafe AI, 结构化输出, AI 自动化, 模型校准
- Source: [TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![不规则的玻璃碎片进入精密机器，出来时变成固定决策轨道上的完美形状](https://cdn.markhuang.ai/news/jev-schema-guarantee-wrong-decision/hero.webp)

*Jev 将每个输出约束为软件可接受的形状。机器能保证格式合适，却不能保证方向正确。*

[TypeSafe AI 于 2026 年 9 月 14 日发布的上线博文](https://typesafe.ai/blog/introducing-system-one-models-and-jev)介绍了 Jev，这是其首个 System One 模型。与逐个 token 生成文本不同，Jev 接收自然语言状态并返回带概率的类型化决策。TypeSafe 给出的指标是：端到端响应时间 70 至 500 毫秒、每百万输入 token 0.042 美元、输出 token 免费。

我认为 TypeSafe 做了一个有意思的取舍。不生成文本，就彻底消灭了一整类格式错误的输出，模型也更容易塞进普通代码里。但这并不意味着决策就是对的。集成 Jev 的团队现在得自己扛答案空间、行动阈值，以及置信度不够时的退路。

该公司的[四工作流评估](https://evals.typesafe.ai/)把这种吸引力具体化了。四个任务下来，图表显示 Jev 与共识标签的一致性达到 67.8%，每个案例约 0.0004 美元，耗时 0.4 秒。TypeSafe 说这个测试是他们声称速度提升高达 193.6 倍、成本降低 444.6 倍的基础。这些是厂商自己跑出来的结果，不是独立测量，但数字够大，值得仔细看看这个接口。

## 保证止步于类型边界

TypeSafe 说 Jev“不会产生幻觉”。这个说法成立，但前提是你对“幻觉”的定义足够窄。因为所有可能的输出都事先定义好了，模型没法跑偏去写散文，不会凭空多出一个字段，也不会返回错误的数据结构。这个保障很有价值——写过 LLM 重试逻辑的人都知道，JSON 看着像那么回事、应用还没开始解析就报错，这种输出有多折腾人。

TypeSafe 自己的[System One 文档](https://docs.typesafe.ai/concepts/system-one)把界限划得更仔细：校准度是在一批预测上整体衡量的，并不保证单条答案正确。退款分类器可以对一个错误结论返回完全合法的置信度；路由模型可以信心十足地把工单丢进错误的队列。两个回答都符合 Schema。

这个区别很关键，因为类型安全和语义准确性在不同的地方会出问题。Schema 验证器可以立刻拒绝格式错误的数据，但它判断不了客户是不是被重复扣款，也判断不了某个事件是否需要隔离处理。第二个问题需要结果数据、与错误成本挂钩的阈值，以及不确定案例的处理出口。

## 基准测试仍是内部测试

TypeSafe 值得肯定的一点是，他们在亮眼的数字旁边也写了注意事项。参考标签来自 GPT-6 Astra 和 Claude Fable 5.1 在高思考模式下的平均响应——Jev 和其他模型对比的是这个共识，而不是经过验证的真实情况。上线博文还提到，这些工作流由 TypeSafe 模型能力团队的成员创建，所以即使公司说没有故意挑选对 Jev 有利的任务，偏见仍可能存在。

测试涵盖安全事件分类和其他三个结构化工作流，每个工作流在汇总图表中权重相等。这告诉我的是：在 TypeSafe 自己的测试环境里，每种配置与参考模型有多接近。但它还没告诉我，当我的标注本身有噪声、业务规则变了、线上输入偏离了调参时用的样本时，Jev 会怎样表现。

这和我在[模型构建对比](https://markhuang.ai/news/model-build-offs-need-failure-rates)里关心的评估边界是一回事：发布的分数可以帮你拿到下一次测试的预算，但替代不了工作负载自身的失败率。这里的情况更紧迫，因为校准后的概率可能直接变成自动操作，而不是展示给人看的建议。

早期的[Reddit 讨论](https://www.reddit.com/r/singularity/comments/1wh9wt6/diogo_has_finally_come_out_of_stealth_and_cooked/)也反映了这种不确定。几个人在问 Jev 到底能干什么，也有人觉得那张四工作流的图太模糊。我不会把一个刚开的帖子当市场调研看，但它确实暴露了产品的传播难题：大家听到“前沿模型”就期待一个聊天机器人，而 Jev 卖的其实是一个更窄的决策原语。

## 置信度需要操作策略

校准后的概率之所以有用，恰恰是因为代码可以针对不同代价设定不同的阈值。2022 年一篇关于[校准选择性分类](https://arxiv.org/abs/2208.12084)的论文点出了其中的陷阱：不确定性估计本身也可能变得不可靠，尤其是训练分布和部署分布不一致的时候。论文提出的应对方式是选择性预测——系统在对自己的置信度没把握时，选择不出结果。

这也是我会怎么评估 Jev。先从有已知结果的历史案例入手，分别测准确性和校准度，然后根据每种错误的实际代价来定行动阈值和审查阈值。上线之后，我会把被拒绝和被人工覆盖的案例都留下来。这些是判断阈值是否还管用的证据。

```mermaid

flowchart LR
    A[非结构化状态] --> B[Jev 类型化概率]
    B --> C{确定性策略}
    C -->|高于行动阈值| D[执行有限操作]
    C -->|不确定或高风险| E[升级审查]
    D --> F[记录结果]
    E --> F
    F --> G[审核校准度和阈值]
```

这个流程里的确定性策略是产品本身的一部分，不是外面包的胶水。如果一条欺诈标记能冻结账户，它的阈值就该和整理收件箱的标签完全不同。置信度不决定什么代价可以接受——决定这件事的是应用负责人。

## 我会首先在哪里尝试 Jev

我会从高频、范围有限、且可逆的决策入手。比如分流客服工单、给待审内容排优先级、或者判断一条 LLM 输出要不要再过一轮验证。Jev 的低延迟让反复检查成本可控，类型化输出也能让外围代码简洁不少。但第一次部署时，最终决定权不会交给它。

我也不会拿 Jev 去跟通用 LLM 比写作、写代码或解释性的任务。TypeSafe 的文档写得很清楚，Jev 不做这些事。公平的比较对象是同样用于这个决策的窄域 LLM 调用、现有分类器、或者手写规则。Jev 只有在判断力更好、校准度更高、或维护成本更低——低到足以抵消引入新依赖的代价——时才算赢。

> **Info:**
>
> 我的采用原则：Schema、阈值、升级路径、结果日志都得有人管，然后才让 Jev 做有边界的决策。类型合法只是安全论证的起点，不是终点。

TypeSafe 抓到了生成式 AI 系统一个真实的问题。对于需要在机器速度下做出可预测决策的软件来说，自由文本是一个很别扭的接口。Jev 的做法有吸引力，因为它把软件解读输出的自由度压低了。但相应地，搭工作流的人必须把"接下来可能发生什么"讲得更清楚。这个权衡我愿意试。但我不会因此就觉得机器不会再做出糟糕的决策了。