System One Model

摘要

System One Model 把软件中的一类语义判断单独拿出来：输入状态和问题，返回受约束的答案与概率。本稿从四个层次分析它，再与普通 LLM、Structured Outputs 和典型监督式分类模型比较，最后核对 Jev 与开源实现的代码和 benchmark。

问题

客服工单里，程序最后要做的动作可能只有一个：把请求放进技术支持队列。先让 LLM 写一段分析，再从分析中解析出部门，是绕了一圈。

System One Model 要解决的就是这段绕路。它不负责写一封漂亮的回复，而是直接回答软件下一步需要的窄问题：属于哪个队列、是否需要升级、风险处在哪个等级。

这篇文章要追问的不是“Jev 能做什么”，而是：它到底改变了 AI 的哪一层？ 是接口，还是推理路径？是训练目标，还是底层模型？如果这些部分可以分别复刻，Jev 的独特之处又在哪里？

定义

System One Model 是 TypeSafe 提出的一种模型类别，Jev 是 TypeSafe 发布的第一个公开模型。官方给出的定义是：输入一个状态，针对预先定义的问题返回带类型的答案和概率，供软件直接使用。[1][18]

它把三个问题放进了接口：模型是否直接判断候选结果，概率和不确定性是否属于输出的一部分，以及代码如何组合判断、设置阈值并执行动作。

System One Model 不是 LLM 的替代品，传统分类任务也不必全部换成它。它处理的是中间地带：程序需要理解语言，但不需要一段自由文本。

四个层次

公开资料能确认四层。

接口层

state + question definitions
              ↓
Choice / Score / Noul
              ↓
typed answers + probabilities

这部分在 TypeSafe 文档和多个开源实现里都能看到。

state 可以是一段文本，也可以是 JSON 对象、对话记录、订单和政策组成的组合数据。问题由调用方定义，包含判断目标、答案类型和候选项含义。[19]

例如，一个退款流程可以把这些材料放进同一个 state：

{
  "ticket": "我被重复扣款了，请退还多扣的部分。",
  "order": {
    "charges": [49, 49]
  },
  "refund_policy": "重复扣款可以退款。"
}

然后提出几个不同的问题：

客户是否明确要求退款？
订单是否存在重复扣款？
政策是否支持退款？

Choice、Noul 和 Score 规定了答案的范围：模型不能在 Choice 中临时发明一个没有定义的部门，程序也不需要从解释文字里找出模型选了什么。[20]

推理层

TypeSafe 官方描述了 parallel sampler；开源实现则出现了几种不同路线：

直接读取候选 token 的 logits
共享 state 的前缀缓存
双向编码器中的候选 marker
每个候选项一个 NLI pair
兼容 API 的单 token 推理服务

它们都减少了自由文本生成，但内部计算方式并不相同。

训练层

TypeSafe 把自己的训练方法称为 RLCD，即面向校准决策的强化学习路径。官方解释是：模型不只要选对，还要让概率在大量预测中接近真实频率。[23]

但目前公开资料没有告诉我们：

Jev 使用了多少参数
底层是否是某种 encoder-only 结构
state 与 question 如何在内部编码
parallel sampler 具体如何实现
RLCD 的完整损失函数是什么
训练数据如何生成和筛选

因此，下面这种说法是不严谨的：

Jev 本质上就是某种 Encoder 模型。

更稳妥的说法是：

从公开接口和推理方式看，Jev 明显偏向条件决策和并行评估；但底层网络结构和训练细节仍未公开。

软件架构

落地时可以把组件分层：

用户、文档、业务数据
          ↓
        state
          ↓
  System One Model
  判断、评分、概率
          ↓
      传统代码
  阈值、路由、权限、状态机
          ↓
自动执行 / 人工审核 / LLM 解释

LLM：处理开放式理解、生成、解释和复杂推理
System One Model：处理大量边界明确的小判断
传统代码：处理精确计算、日期、权限和确定性规则
人工或推理模型：处理高风险、低置信度和超出模型边界的情况

这样分层后，软件可以把需要概率判断的部分交给模型，把精确计算和确定性规则留在代码里。

和现有方案的区别

普通 LLM 在做什么

普通 LLM 生成 JSON 时，仍然可能按 token 逐步写出：

{
  "department": "technical",
  "is_urgent": true
}

它要依次生成括号、字段名、冒号、字符串和值。即使接口保证 JSON 合法，模型做的仍然是序列生成。

Jev 的公开定位不同。TypeSafe 称它使用了新的模型架构和 parallel sampler，目标是在一次查询中直接得到多个结构化结果，而不是逐 token 生成回答。[1]

可以把两种路径画成这样：

普通 LLM：
状态 → 生成第一个 token → 生成第二个 token → 生成更多 token → JSON

System One：
状态 + 问题 → 直接计算候选结果的分布 → 类型化答案

这里的“直接计算”是公开接口和项目实现共同展示出的方向，但 Jev 的底层网络没有公开，不能据此断言它具体使用了哪一种 Transformer 结构或某种固定的 encoder 架构。

候选读出

如果软件只需要判断“技术支持”还是“账单支持”，让模型生成一段 JSON 本身就是额外工作。需要的结果可能只需要两个候选分数：

technical: 0.91
billing:   0.09

开源项目 SemIf 证明，现有 LLM 也可以在不生成 JSON 的情况下，直接读取候选 token 的内部得分。它把候选项映射成单 token 标签，读取模型最后位置的 logits，再在声明的候选项中重新归一化。项目自己的测试中，同一个 Qwen3.5-4B、同一个状态和 21 个问题，直接读候选分数比生成 JSON 数组快很多。[8]

问题在于：Jev 的价值主要来自新模型，还是来自“不生成完整答案、只读取决策位置”的推理路径？公开资料还不能给出确定答案。

Structured Outputs

OpenAI 对 Structured Outputs 的定义是：让模型的返回值遵守开发者提供的 JSON Schema。它解决的是输出格式、字段完整性和枚举值合法性。[24]

例如，Structured Outputs 可以保证返回值符合：

{
  "department": "technical",
  "is_urgent": true
}

但它并不自动保证：

technical 这个判断是正确的
0.93 这个置信度有统计意义
多个字段之间相互独立
模型已经针对概率决策进行过专门训练

区别在这里：

维度	LLM + Structured Outputs	System One Model
主要解决的问题	输出必须符合 JSON Schema	模型直接完成受约束的决策
模型的原始目标	生成文本	输出决策分布
输出空间	可以是任意业务对象	由 Choice、Score、Noul 等问题类型定义
概率	可以额外要求模型返回，但不自动校准	概率分布和置信度是核心结果
文本解释	可以继续生成解释	不以生成解释、代码或回复为目标
失败方式	JSON 合法但语义错误	类型合法但判断错误或概率不可靠

TypeSafe 自己也公开了一个 System One Adapter，用普通 LLM API 模拟 TypeSafeClient 的接口。这个项目支持 Structured Outputs、概率模式、概率归一化和格式错误重试。这说明，普通 LLM 可以模拟 System One 的接口；TypeSafe 仍然把直接决策模型作为另一条产品路线。[17]

所以，Structured Outputs 约束的是“怎么写出来”，System One Model 试图重新定义的是“模型要计算什么”。

如果让普通 LLM 多生成一个字段：

{
  "confidence": 0.93
}

这个数字不会因为它被放进 JSON，就自动变成校准概率。

传统分类模型

System One Model 也不是传统分类器的换名。

传统分类器

典型的监督式固定标签分类模型通常解决一个固定问题：

输入文本 → 固定标签

例如：

工单文本 → billing / technical / sales

它的特点通常是：

标签集合在训练前就确定
任务比较固定
输入分布和输出关系由训练数据定义
换一个任务，通常需要重新训练或微调
概率是否可靠，往往需要额外校准

System One 的变化

System One Model 更像一个可以在请求时定义判断问题的模型：

状态 + 当前问题定义 → 当前任务的结构化判断

同一个模型今天可以判断工单部门，明天可以判断政策是否适用，后天可以判断邮件是否包含敏感信息，而不必为每个任务单独训练一个分类器。

维度	传统分类模型	System One Model
任务定义	通常训练前固定	可以在请求中定义
标签和等级	固定输出类别	由问题中的候选项或等级定义
输入	针对固定特征分布	可以是文本或结构化 state
多任务	常需多模型或多头	一次请求可以提出多个问题
概率	可能只是分类分数	试图把概率和置信度作为核心输出
部署	固定任务上可以非常便宜	换取任务灵活性，模型本身更复杂
失败方式	固定任务外泛化较弱	问题定义、候选描述和领域差异会影响判断

但这不代表 System One 一定更好。

如果一个业务只需要长期稳定地判断“是否垃圾邮件”，传统分类器可能更便宜、更快，也更容易用真实数据做评估。System One Model 的价值在另一类场景：业务有很多需要自然语言理解的小判断，但每个判断都不值得单独训练一个模型。

证据与边界

Benchmark

jabr/classifier-benchmark 提供了一套统一的 Choice、Noul、Score 测试。这里的 v1 和 v2 是测试集版本，不是模型版本；仓库页面把 v2 标为 preliminary。[10]

模型	v1 micro	v2 micro	v1+v2 micro
Jev	0.974	0.964	0.965
Von	0.923	0.666	0.687
GLiNER2	0.795	0.688	0.697
Laya	0.615	0.585	0.587

v1 包含 8 个任务、78 个样本；v2 包含 49 个任务、869 个样本；合并结果共有 947 个样本。表格使用仓库当前归档结果，不是本机重新运行得到的数字。[10]

表里最明显的变化是 Von：

v1 上接近 Jev
v2 扩展到更多任务后明显下降

Von 在 v2 的弱项包括 grammar issue、commit intent、reading level、symptom triage 和 formality level。它在某些固定路由任务上表现很好，但跨领域迁移并不稳定。

Jev 也不是所有任务都满分。它在 warranty claim、grammar issue、weather severity 等任务上同样出现下降。区别在于，Jev 的整体下降幅度更小。

测试集的边界

jabr 的 v1 样本是合成数据，由多个 LLM 生成和交叉检查；测试集公开后，模型也可能在训练中见过类似样本。[10] GLiNER2 是另一种本地、schema-driven 的信息抽取和分类编码器，也被纳入这套比较；它可以作为传统“结构化编码器”基线，而不能直接当成 System One Model。[16]

TypeSafe 自己的 workflow eval 也采用了不同方法：它假定程序 harness 正确，再使用 GPT-6 Astra 和 Claude Fable 5.1 的高推理结果生成参考共识，而不是使用人工逐条标注的客观真值。[14]

因此，benchmark 更准确的含义是：

在这套问题定义、harness、模型版本和测试样本上，哪个系统更接近参考结果。

它不能直接代表真实业务准确率。

另一篇独立测评在相近的 78 个问题上得到的 Von 结果明显低于仓库 headline 结果，并指出包装器修复会显著改变分数。[11] 这说明模型版本、适配器、问题描述和测试代码都可能影响最终结论。

另一个独立 benchmark JevBench 用 242 个 typed decisions 同时报告 accuracy、ECE、Brier、延迟、答案是否合法、概率是否精确求和，以及同一问题改写后的答案一致性。它的 v1.3 结果中，Jev accuracy 为 96.3%，openjev-sglang 为 95.5%；这组数字和上面的 jabr 测试不能直接横向合并，但足以说明 accuracy 不是 calibration 的替代品。[25]

概率与置信度

容易误读的是“返回 probability”这件事：它不等于返回可靠概率。

TypeSafe 的文档解释，校准描述的是一批预测的统计关系：如果许多判断都给出 0.8，长期来看大约应有 80% 正确；它不保证某一个具体判断一定正确。[21] 当前 Jev 文档还注明，英语是主要训练语言，中文等 CJK 语言虽然可以使用，但准确率不一定相同，需要用自己的数据测试。[22]

这里还要区分 confidence。Choice 和 Score 的 confidence 是由输出概率分布派生的摘要指标；Noul 只返回“为真”的概率，不单独提供 confidence。[20]

Jev 1.13 的官方限制页还明确提醒：

不要把 Noul 的阈值直接搬到 Choice
不要期待一个问题和它的否定满足简单的互补关系
不要用 Score 去恢复精确数值
不要让模型负责日期比较、计数和数学
不要默认长 state 里的无关信息不会影响判断
对抗性内容可能改变答案[13]

所以，“不会幻觉”只能作很窄的理解：

模型不会输出候选集合之外的任意字符串。

它仍然可能在候选集合内部选错。类型错误减少了，语义错误没有消失。

外部评价

支持者看重的是工程收益。TechCrunch 记录的开发者反馈集中在低延迟、低成本、可用于模型路由和 Agent 监控的概率输出。[2]

怀疑者则认为，Jev 的接口很有价值，但其中一部分速度收益可能通过普通 LLM 的单 token 读出、候选项限制和前缀缓存实现；“不会幻觉”更多是类型边界，而不是语义判断不会错。[3]

这两种评价针对的是不同问题：一种看它能不能带来新的软件形态，另一种看它是否需要完全独有的模型架构。开源项目已经复刻了接口和部分推理路径，但 benchmark 还没有证明它们复刻了 Jev 的整体质量。

结论

System One Model 处在聊天模型和固定分类器之间。它把几件事放在了一套接口里：

用结构化问题定义模型要判断什么
用受限答案空间减少自由文本解析
用并行或缓存推理减少无意义的生成
用专门训练让概率更接近真实不确定性
用代码负责组合、阈值和最终动作

Jev 的闭源实现把这些部分放在了一起。Von 和 Laya 尝试重新训练开源决策模型；SemIf 和 openjev-sglang 则复刻了“只读候选结果”的推理路径。它们已经证明 Jev 的接口和部分推理方法可以被复刻，但现有公开证据还不足以证明某个开源项目同时复刻了 Jev 的判断质量、延迟和概率可靠性。

我更愿意把它写成一句话：