Jev 是什么：理解 TypeSafe 的 System One 决策模型

Jev 是一个面向软件决策的 AI 模型：输入当前状态和事先定义好的问题，输出选项、分数或概率，让程序据此走下一步。 例如，它可以判断一条工单该交给哪个团队，而撰写回复仍交给生成式模型。官方概念说明

TypeSafe AI 在 2026 年 9 月 15 日发布 Jev，并将这类模型命名为 System One Models。这个名字借用了《思考，快与慢》中快速、直觉式判断的概念，是厂商提出的产品与技术定位。发布公告

本文依据截至 2026 年 9 月 22 日的官方资料整理。性能数字均注明来源；文中的演算与请求示例用于解释机制，未调用付费 API 做实测。

1. 它解决什么问题？

想象一个处理客服工单的程序，需要回答三个问题：工单属于什么类型、用户是否要求人工、问题有多严重。每个答案都很短，最终只是程序里的一个条件分支。

Jev 将这种调用组织成三个部分：

部分	含义	工单例子
state	待判断的文本或结构化状态	用户消息、订单记录、已知故障
questions	问题及允许的答案	从账单、技术、其他中选一个
answers	对应问题的类型化结果	选中的类别及各类别概率

这些字段和调用方式由官方 API reference 定义。HTTP 响应仍可使用 JSON；“不生成文本”描述的是模型输出机制，不意味着网络接口不再传输 JSON。

从应用架构看，可以把它理解成一个支持自然语言条件的概率判断函数。开发者负责定义状态、候选答案与后续动作，模型负责处理其中难以穷举规则的语义判断。

2. 三种输出：Choice、Score、Noul

Choice：在候选项中选择

当问题是“应该交给哪个团队”，候选项可以是 billing、technical、other。Choice 返回选中的选项、所有选项的概率，以及概括分布集中程度的 confidence。当前每个 Choice 最多支持 255 个选项。Choice 文档

下面是自拟的概率示意，不是实测返回值：

billing   = 0.78
technical = 0.17
other     = 0.05
choice    = billing

应用可以看出：账单团队最有可能合适，但技术问题仍有一定可能性。候选空间不完整时，应留出“其他／信息不足”的出口，否则模型只能在给定选项里挑一个。

Score：沿着有序标准评分

Score 使用 2～10 个有文字描述的等级，返回等级索引的概率加权平均。Score 文档

例如，自定义故障等级为：0 表示外观问题，1 表示功能受损但有替代方案，2 表示功能完全阻断。如果假设概率为 0.10、0.65、0.25，那么：

\[ \mathrm{score}=0\times0.10+1\times0.65+2\times0.25=1.15. \]

这里的 1.15 是量表位置，不能解释为“影响了 115% 的用户”。同样的平均分可能来自不同分布：全部概率落在等级 1，与等级 0、2 各占一半，平均分都是 1，含义却不同。

Noul：返回“是”的概率

Noul 回答单个是非问题，例如“用户是否明确要求人工”。返回值接近 1 表示倾向于“是”，接近 0 表示倾向于“否”，接近 0.5 表示两种答案概率相近；它没有额外的 confidence 字段。Noul 文档

不要把“用户是否愤怒”的概率 0.8 理解为“愤怒程度 80%”。前者是对命题的判断，程度问题应当定义 Score 量表。

3. 与 LLM 输出 JSON 有什么区别？

两者都可以给业务代码提供结构化结果。TypeSafe 自己也发布了 System One Adapter，用其他 LLM API 提供兼容接口，因此“能返回 Choice 或 Score”本身不足以证明模型机制独特。

区别主要在优化目标与生成路径。TypeSafe 将 Jev 描述为采用新架构、并行采样器和 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习）的模型；其目标是直接返回决策与概率。官方介绍了训练方向，但本文查阅的材料没有给出足以复现训练的完整损失函数、数据配方和架构细节。官方 AI primer、发布公告

对应用开发者，可以用下面几个维度比较：

比较维度	通用生成式模型的结构化调用	Jev
任务表达	可以组合文字、代码、参数与结构化字段	以预定义的选择、量表、是非问题为核心
问题拆分	可让模型生成一份完整结果	适合把状态拆成多个明确判断
输出解释	可以要求模型给出文字解释	当前不生成推理解释
应用逻辑	取决于程序如何使用结果	由程序组合概率并控制分支

Jev 的输出范围和不生成解释的限制见 System One 文档。我的判断是：它的产品价值在于降低大量小型语义决策的调用成本；是否值得替换现有方案，需要在同一工作流里比较任务质量、总成本和延迟。

4. 概率校准与 confidence，不能混为一谈

概率校准是一种跨样本的统计性质。 假设模型对 100 个案例都给出“是”的概率 0.8，良好校准意味着这些案例中大约 80 个实际为“是”。这不保证某个具体案例正确。RLCD 强调的正是让概率与实际结果相匹配。AI primer

confidence 则是从 Choice 或 Score 的概率分布计算出来的集中程度指标。官方文档没有在该页面公开具体计算公式，因此不能自行认定它就是最大概率、归一化熵，或“这次答对的概率”。Confidence 文档

这对实践有三个直接影响：

1. 概率和 confidence 分开记录。 一个描述候选结果，一个概括分布形状。
2. 阈值用业务数据确定。 需要知道多少案例能自动处理，以及被自动处理的案例里还会错多少。
3. 高置信不替代权限检查。 模型确信用户想退款，不代表身份、订单状态、退款额度已经满足执行条件。

作为一个自拟的二元决策例子，设误判为“是”的代价为 9，漏判的代价为 1，正确判断代价为 0。若概率已校准，且只有执行“是”或“否”两条路径，选择“是”的条件为：

\[ 9(1-p)<p\quad\Longrightarrow\quad p>0.9. \]

这个 0.9 来自假设的错误代价，不是 Jev 的推荐阈值；如果还可以补充证据或人工复核，就应把第三条路径及其成本一起考虑。

5. 为什么受到关注？如何看待速度与价格？

官方发布材料给出的端到端响应时间为 70～500 ms，并展示了特定工作流上约 193.6 倍提速、444.6 倍成本改善的结果。公告同时说明：延迟测试通常在美国西海岸完成，这些倍数可能位于现实收益的高端；工作流参考答案来自强模型的平均预测，不能等同于经过人工确认的业务真值。发布公告及评测说明

截至本文核验日期，官方模型页列出 jev-1.13.0：输入价格为 每百万 token 0.042 美元，输出免费；仅支持文本。上下文总预算为 64k token，同时 state 加最长单个问题不得超过 32k token。官方还说明当前英语表现最好，中文等语言需要单独评估。Models 文档

按上述标价自行估算，如果每次调用实际计费输入为 2,000 token，那么一百万次调用的输入费用约为：

\[ 10^6\times\frac{2000}{10^6}\times0.042=84\ \text{美元}. \]

这只是模型输入费用，不包含重试、检索、监控和回退模型。一次传入更多问题也会增加输入 token。

由此可以理解它受到关注的工程原因：当一次判断足够便宜，开发者就能在更多中间步骤增加分类、相关性筛选和结果检查。不过，对一个实际 Agent，我会优先测量完整任务的成功率、P95 延迟和每个成功任务的成本，而不会直接套用厂商公布的倍数。

6. 一个最小请求，以及它在 Agent 中的位置

下面是自拟的工单判断请求，字段依据官方 API reference。它只请求判断，不执行退款或其他业务操作。将该 JSON 作为请求体发送到 POST https://api.typesafe.ai/v1/systemone，并按文档配置 Bearer API key。

{
  "model": "jev-1.13.0",
  "state": {
    "message": "The export page is broken. Please connect me to a person."
  },
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team best matches the issue in state.message?",
      "criteria": {
        "technical": "Software bugs and broken functionality",
        "billing": "Charges, invoices and payments",
        "other": "Neither category fits or there is insufficient information"
      }
    },
    "wants_human": {
      "type": "noul",
      "instructions": "Does state.message explicitly request a human support agent?"
    }
  }
}

两个问题可以在同一次调用中提交。官方说明问题针对共享状态并行评估；有依赖的后续判断仍需由程序组织，不能指望问题之间自动完成多步推理。Choice 文档

一种适合评估的应用流程是：

用户请求 + 必要业务状态
          ↓
Jev：类别判断 / 是非判断 / 评分
          ↓
程序：检查概率、业务规则和权限
          ├─ 证据充分 → 进入对应处理流程
          ├─ 信息不足 → 补充信息或人工复核
          └─ 需要文字 → 交给生成式模型撰写

在这个设计中，Jev 提供判断信号，代码决定信号如何影响流程。开始接入时，可以先让它在历史样本或旁路流量上打分，比较人工标签；再根据错误成本决定自动处理范围。模型版本、问题表述和阈值应一起记录，便于发现行为变化。

7. “零幻觉”的边界与当前局限

输出符合类型，和判断符合事实，是两个不同要求。 就算只能在 technical 与 billing 中选择，也仍然可能把技术问题选成账单问题。发布公告对“零幻觉”的具体支撑是 schema 匹配保证，不能由此推出零误判。发布公告

官方的 Jev 1.13 局限说明 还列出了以下问题：

局限	对应用设计的影响
数学、计数和日期比较不可靠	让代码完成精确运算
多层间接关系、双重否定容易出错	提供直接问题与明确条件
无关上下文过多会降低准确率	先检索、过滤，再组织状态
对抗文本可能影响判断	将注入样本纳入评估，保留独立执行约束
不同问题间的逻辑恒等关系不保证成立	在代码中维护互斥、补集与一致性

尤其需要留意提示注入：官方明确表示当前模型不会默认把 state 当成恶意内容防御。一个只能返回合法选项的模型，仍可能被输入中的指令诱导选择错误选项。因此，把 Jev 放在 Agent 的检查环节可以作为一种实验设计，但不能仅凭输出类型受限就认定它能承担完整的安全边界。

8. 对 Agent 工程有什么启发？

我的理解是，Jev 展示了一种值得验证的分工：将高频、答案空间有限的语义判断独立出来，把精确规则、状态管理和执行留在代码里，把开放式生成留给生成式模型。

例如，检索系统可以先判断片段是否相关，再让生成模型组织回答；客服系统可以先分类工单，再由业务流程处理；Agent 可以先检查候选动作是否满足某些语义条件，再由程序验证权限。这里列举的是架构思路，实际收益取决于任务分布与验证结果。

对研究者而言，更值得追问的是：RLCD 的校准在领域迁移后能保留多少？低成本判断能否真正改善长流程的累计错误？加入回退后，整体收益是否仍然成立？这些问题需要可复现的评测来回答。

如果准备尝试，我会从一个已有标注、输入简短、候选答案清晰的分类任务开始，同时保留现有方案作对照。先确认它在自己的数据上能做对什么，再决定把多少业务流程交给它。