Jev决策模型简介

Jev决策模型简介

Jev 是 TypeSafe AI 于 2026 年 9 月发布的托管 System One 模型：不生成回复、代码或摘要，只对给定状态与事先声明的问题返回类型化答案及概率，供程序直接分支。本文说明其输入输出、与聊天模型 JSON 输出的差别、适用负载，以及选型时的厂商绑定与场景匹配。指标与「更快更便宜」倍数来自厂商评测，落地须自测。

参考与延伸阅读：

• TypeSafe 官网：https://typesafe.ai/
• Introducing System One Models & Jev：https://typesafe.ai/blog/introducing-system-one-models-and-jev
• 卡尼曼《思考，快与慢》中 System 1 / System 2 的常用介绍：https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow

---

目录

• 1. 产品定位与命名
• 2. 请求与响应结构
• 3. 与聊天模型结构化输出的差别
• 4. 上下文、模态与调用方式
• 5. 任务形态并不新
• 6. 厂商绑定与数据出境
• 7. 场景匹配
• 8. 落地选型
• 9. 小结

---

1. 产品定位与命名

2026 年 9 月 15 日，旧金山实验室 TypeSafe AI 结束两年隐身期，发布公开模型 Jev，自称 System One Model。定位可以概括为：输入一段状态和一组事先写好的问题，输出带概率的类型化答案，而不是自然语言段落。

System One 借用卡尼曼《思考，快与慢》中的 System 1（快、直觉判断）与 System 2（慢、费力推理）。TypeSafe 将聊天与长文生成留给现有大语言模型（System 2），将分类、路由、打分、是否判断留给 System One。

Jev 借用经济学家威廉·斯坦利·杰文斯。蒸汽机效率提高后煤耗上升（杰文斯悖论）。厂商主张：当决策成本足够低时，软件会把模型判断嵌入此前不会调用模型的路径。

创始人 Diogo Almeida 曾参与将语言模型训练为「可遵循指令的对话」。发布稿的核心判断是：模型已经善于对话，业务自动化却未同比例出现，原因在于聊天输出是字符串，软件难以稳定消费。

---

2. 请求与响应结构

请求包含三块：model、state、questions。问题仅有三种原子类型。

类型	任务	返回
Choice	在给定选项中选择	选中项、每项概率、confidence
Score	落在有序量表的哪一档	分数、各档概率、confidence
Noul	是 / 否	noul，0 到 1 的概率

选项在请求中当场声明，不写死在分类头里。多个问题共用同一份 state。官方称并行求值，增加问题几乎不增加时延，费用主要按问题侧的少量 token 计。

客服工单示例（形状与官方演示同类）：

{
  "model": "jev-latest",
  "state": "客户：我被扣了两次钱，非常生气。",
  "questions": {
    "topic": {
      "type": "choice",
      "instructions": "这单主要是什么问题？",
      "criteria": {
        "billing": "扣款、退款、账单",
        "bug": "产品坏了、功能不可用",
        "other": "都不属于"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "要不要立刻转人工？"
    }
  }
}

响应不包含待解析的散文，形态接近：

{
  "answers": {
    "topic": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.97, "bug": 0.02, "other": 0.01 },
      "confidence": 0.95
    },
    "urgent": { "type": "noul", "noul": 0.91 }
  }
}

调用方读取 choice 与 noul 即可分支。Choice 最多约 255 个选项；Score 一般 2～10 档。

---

3. 与聊天模型结构化输出的差别

结构化输出与 function calling 已能把聊天模型约束为 JSON。差异主要在采样方式与训练目标。

聊天模型从左到右生成 token。即使最终结果是 {"topic":"billing"}，仍须按字生成，格式可能偏离 schema，还需校验。被问及把握程度时，口头置信度往往偏高且不稳定。

Jev 宣称放弃字符串生成，改为并行采样；训练目标是 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习），而不是 RLHF（偏好长文）或 RLVR（程序可验证对错）。「校准」指：模型报告约 90% 的那一批样本，长期看正确率大约为 90%。这不保证单次判断正确。

发布稿中可核对的口径包括：端到端时延约 70～500 ms；输入约 0.042 美元 / 百万 token，输出按「便宜到可忽略」宣传；成功响应的取值一定落在调用方给出的选项内（结构上的类型错误为 0）。首页「约 194 倍更快、445 倍更便宜」来自其 workflow eval，官方也说明偏上限。

「Zero Hallucinations」不宜理解为判断不会错，更准确的含义是：不会生成 schema 之外的字段。选错类、打错分仍会发生。TypeSafe FAQ 亦承认会出错，因而提供 confidence，便于低把握时升级人工。

---

4. 上下文、模态与调用方式

公开口径大致为：

• 整请求（state 加全部问题）约 64k tokens
• state 加最长一条问题约 32k tokens（英文约十五万字符量级）
• 仅文本：字符串、JSON 对象或文本数组；不支持图、音频、视频
• 超限直接报错，而不是静默截断后再答

厂商关于 jaggedness（能力锯齿）的说明指出：无关细节增多时准确率下降，应在代码中先过滤，只送与问题相关的字段。它不是「上下文越大越懂」的长文档模型，而是短状态上的快速判断。中文每个 token 承载的字更少，同样 32k 能容纳的有效内容比英文更紧。

Jev 没有检索世界知识的能力。未写入 state 的事实，模型不可用。

早期需 waitlist。常见路径包括 TypeSafe 控制台申请密钥，或经 OpenRouter 一类网关（曾出现 api/alpha/decisions、模型名 ~typesafe/jev-latest / typesafe-ai/jev）。直连官方为 POST https://api.typesafe.ai/v1/systemone。

对调用方而言，这是托管 API，不是可下载微调的本地权重。公开口径通常宣称客户输入不用于训练或微调，但不等于零保留；服务主体在美国，零保留多出现在企业合同或网关的 ZDR 选项。请求本身已经出境。

产品定位接近「可编程的条件判断」：规则写不全、又不值得调用一轮聊天模型的分流、风险拦截、是否继续、固定标签打分。LangChain 可将其接成分类器，用于选模型或拦截工具调用，而不是生成长文。

不适合的任务同样明确：开放文本生成、从文档抽取短语、聚类、对照最新外部规章、依赖图像才能下的结论。那些任务需要生成、检索或长上下文。

---

5. 任务形态并不新

客服意图、工单路由、内容审核、是否拦截，在 2015 年之后就是分类问题。Rasa、Dialogflow、LUIS、BERT 分类头采用「标签冻在模型里，新增意图即重训」。

2019 年零样本 NLI 将标签推迟到推理时声明。Hugging Face 管道、NLI 编码器、SetFit、Semantic Router、cross-encoder 对 (文本, 标签说明) 打分，均属同一任务形态。Jev 的 Choice / Noul / Score 是同一任务的托管接口：候选标签写入 criteria，而不是写入分类头。

此后也有人用大模型 JSON mode 充当分类器，代价是更贵、更慢、格式偶发偏离、口头置信度偏高。Jev 的发布叙事主要针对这一路径，而不是针对 BERT。

因此：Jev 热度高，并不等于出现了「以前做不到」的能力。门禁、分流、是否继续，可用 NLI 零样本或微调小分类器覆盖同类形态。Jev 额外提供托管、多问并行、schema 不偏离、号称校准的概率、70～500 ms 时延。这些在每秒数十次的自动化中有价值；在一天仅数次的重决策中，溢价往往用不上。

不宜断言「NLI 效果等于 Jev」。校准、并行、毫秒级时延，NLI 默认并不具备。应表述为：并非必须等待 Jev 才能补上的能力缺口。

---

6. 厂商绑定与数据出境

截至公开资料，以「System One / 类型化决策、放弃生成」销售托管服务的，主要是 TypeSafe 的 Jev。接入通常需要厂商密钥，或经过 OpenRouter 一类网关。

这与「运行时选用某家聊天模型」不是同一绑定：

• 选择 Claude、GPT 或国产聊天模型，属于调用方环境。
• 在业务链路中再写死一家决策厂商，等于默认多绑定一家、多一条出境路径。未公开的业务原文会进入对方决策 API。

公开口径往往是：输入不用于训练或微调，但未必零保留；主体在美国；零保留多在企业合同或网关 ZDR。对敏感文本，这三项须单独做法务评估，不能只依据发布稿。

若产品原则是不强绑定特定模型厂商和网关，在只有一家决策模型可购的阶段暂不引入，与原则一致，并非拒绝分类任务本身。本地 NLI 或自训分类器不经过该链路。

---

7. 场景匹配

Jev 的设计点是 高频、低延迟、短状态、决策成本低。官网对比「约 8 秒的聊天模型」与「约 100 毫秒的决策」。状态变长时，厂商亦称准确率容易下降，要求先过滤再送。32k / 64k 的预算只够已经筛选过的摘要，筛选规则仍由上游系统完成。

另一类负载是 低频、高责任、高上下文：一次判断需要阅读完整仓库或长文档，错误带来合规或资金后果，每天仅数次。此时：

• 省掉入口数秒分类，用户几乎无感，却要增加密钥、出网与数据条款。
• 先截断再送分类 API，会误伤「口头很短、材料在其他文件中」的情况，也会放行「写得很像、事实未核对」的文本。
• 长文档模型对着完整材料做入口判断，通常比把材料压缩成短 state 更贴合场景。

维度	更接近 Jev / 高频 NLI	更接近长文档模型或规则
调用频率	每秒到每分钟多次	每案几次
输入	短工单、短状态、固定字段	多文件、代码、长文、图表（Jev 不支持图像）
输出	固定标签、是否、分数	长文、抽取、检索式、开放列表
错误代价	可降级人工、可重试	高，需要出处和复核
时延是否瓶颈	是	通常不是

内容审核、客服意图、判断两段话是否蕴含，属于左列：标签可枚举、文本短、可以本地运行。将同一套打分套到右列（生成、抽取、聚类、对照外部最新规则、对照整本长文做合规判断），属于任务改写，不是能力升级。

决策模型做不到、却常被写入「赋能表」的类型包括：

• 抽取 / 生成：Jev 不生成文字。最多对「候选词中保留哪些」打勾，前提是候选已经存在。
• 聚类：几何问题，不是 Choice。
• 对照全文做合规判断：表面是一个 Noul，实际需要引文级核对长文和附件。截断后的「是 / 否」当作「已初检」，风险高于不做。
• 跟上最新外部规则：模型没有世界知识，规章未进入 state 则不可用；整份规章塞入又会触发上下文噪声。

---

8. 落地选型

规则即可拦截：字数、文件是否存在、必填字段为空，用规则。两个极端样本（两句空概念与写满数字和步骤的文本）用规则也能分开，不能证明必须上校准模型。

标签稳定且有标注：微调小分类器仍最清晰，可本地部署。

标签常变、需要零样本：本地 NLI 或句向量路由。假设句应写具体；嵌套量规不要当成互斥三分类硬拦截。

确为短状态、高 QPS、错误可降级：再评估托管决策 API。可将 Jev 作为可选后端，同一份 schema 也可接 NLI；默认路径不宜写死出网密钥。

真正的问题是生成时有没有出处：那是引用约束，不是入口分数。分类器回答「像不像写完」；业务规则需要的是「未出现过的内容不许编造」。入口放行之后，生成模型仍可能补细节。

---

9. 小结

要点	结论
定位	不生成文字，返回类型化 Choice / Score / Noul，供程序分支
相对聊天 JSON	并行采样与 RLCD 校准是产品主张；「零幻觉」指不越出 schema，不是判断永不出错
新颖性	任务形态是意图识别与零样本分类；新增的是托管接口、并行与时延
绑定	目前公开可买的 System One 托管服务很少，引入等于多一条出境决策链路
场景	高频短状态才匹配；低频、高责任、高上下文不宜先截断再决策