介绍System One模型与 Jev：面向自动化的结构化决策

非官方中文译文（经授权发布）。本文经 TypeSafe AI 授权，是对 TypeSafe AI 原文《Introducing System One Models & Jev》的忠实中文翻译。原作者为 Diogo Almeida，原文发表于 TypeSafe AI；完整内容及最新版本请以原文为准。

Diogo Almeida，TypeSafe 创始人 · 2026 年 9 月 15 日

多年来，模型在聊天方面已经超越人类；但自动化究竟在哪里？

这是过去四年一直驱动着我的问题。在 OpenAI 时，我参与构建了让语言模型更擅长遵循指令、与人交谈的方法；这些工作后来成为 ChatGPT 背后的研究。当时我以为聊天模型或许会通向 AGI，但尽管宣传声势很大，我逐渐清楚地意识到：其中缺失了某个极其重要的部分。

经过两年的隐身研发、无数技术挑战和研究突破，我无比兴奋地宣布：今天，TypeSafe AI 发布首个System One模型。这是一类全新的前沿模型，专为快速做出可被软件直接使用的结构化决策而构建。

我们构建了一套完全聚焦自动化的新技术栈：包括新的模型架构、为实现最高效率而设计的并行采样器，以及一种我们称为校准决策强化学习（Reinforcement Learning for Calibrated Decisions，RLCD）的训练方法。

我们的首个公开模型是 Jev，今天起开放早期体验。在System One任务上，Jev 达到与现有 LLM 相近的智能水平，却快两个数量级，也高效两个数量级。Jev 放弃了字符串生成，转而针对结构化输出优化，因此不会产生幻觉。

可以把 Jev 看成一次前沿智能函数调用：输入非结构化状态，输出具有类型约束、带概率的决策。

不同寻常的主张需要不同寻常的证据，下面就给出凭据。💅

新旧前沿

维度	现有 LLM	System One模型 + Jev
优化方法	基于人类反馈的强化学习（RLHF）／基于可验证奖励的强化学习（RLVR）	用于校准决策的强化学习（RLCD）
优化目标	人类偏好：让人工评审更喜欢的文章与聊天回复。<br><br>可验证奖励：可被程序验证的输出。	校准后的决策：在System One任务中给出在认知上诚实的概率。
输入	非结构化数据（例如文本），强调连续的消息序列。	非结构化数据（例如文本），强调结构化的程序状态。
输出	字符串／生成文本。字符串很灵活，可以是聊天回复、代码、幻觉、拒答，甚至是类型安全的结构化值。若要供软件使用，回复还需要解析和验证；AI 也始终存在偏离轨道的风险。	类型安全的结构化值。可能的输出及其结构都可预先定义，模型不会发生类型错误。<br><br>每个答案都附带校准后的概率与置信度分数。
采样	串行：一次生成一个 token，每个 token 都依赖前一个。	并行：一次查询中生成全部输出；效率极高且面向硬件优化。
成本	输入 token：每百万 token 0.20～10 美元。<br>输出 token：约为输入的 5 倍成本。	输入 token：每百万 token 0.042 美元（每十亿 token 42 美元）。<br>输出 token：免费（成本低到无需计量）。
速度	前沿模型端到端响应时间为 3～329 秒。对人与模型的交互已经够快，但嵌入代码后会形成显著瓶颈。	TypeSafe 的端到端响应为 70～500 ms。面对符合System One形态的查询，在同等前沿智能水平下可快 40～200 倍。
置信度	即使要求给出置信度，模型也往往过度自信且不一致。若模型能在 95% 的情况下完成任务、却不能识别那 5% 的例外，就无法自动化此任务。	每个输出始终传达置信度与不确定性。经过校准：更高的置信度意味着更高的准确率；也更一致：相似输入会返回相似答案。
使用场景	人机协作任务：聊天机器人、Copilot、编码智能体。通用而强大，但因其自由度也需要人工监管。<br><br>可验证问题：数学证明、内核优化。正确性能够低成本自动验证时，LLM 可不断生成、测试、迭代直到找到可行解。<br><br>演示：字符串的灵活性使其很适合快速制作偶尔能工作的原型。	AI 驱动工作流／智能 if 语句：结构化输出可作为模糊决策规则嵌入普通软件：分类、路由、打分、提取，或在手写逻辑过于脆弱处进行分支。外层代码限制其自由度，更易组合成可靠系统。<br><br>对大数据做 MapReduce：将 PB 级数据转化为特征和洞见。<br><br>实时应用：100 ms 级速度使 AI 能用于 UX 至关重要的应用。<br><br>验证一切：为 LLM 提示词、推理轨迹及／或输出进行打分、评判、验证、护栏控制与越狱检测。

证据／技术结果

我们喜欢怀疑论者，因为我们自己也是。

有些主张很容易验证：

**单次调用速度：**我们确实这么快；不过已发布的评估通常是在美国西海岸的笔记本电脑上运行（服务目前也部署在这里）。
**单次调用成本：**定价是透明的。我们无法证明价格没有补贴；定价能否长期持续需要时间来证明，不过我们预计价格会降低、而不是上涨。
**没有类型错误：**只要一个反例就能证伪这个说法，但从数学上说这不可能发生。

对于更大胆的主张，我们希望尽可能提供细致的说明。

并排演示

这段并排演示展示了我们的模型与 LLM 的一个关键差别：Jev 并行输出全部概率，而不是逐 token 自回归地生成。字符串极其强大、通用，但成本也高；“放弃”字符串实际上带来了许多超能力！

补充说明

已获得 TypeSafe 早期访问资格的用户可查看实际查询。
- 该查询经过高度简化；questions 使用了描述性、易读的键，以便屏幕上的输出便于理解。
- state 也是一段简短、密集且细节丰富的文字，用来强调采样方法的差异。相对较短的输入对我们的模型更有利。
对细心的读者：在录制的运行中，Jev 与 GPT-5.6 Terra 唯一的分歧是“客户流失可能性等级”。我们认为这个问题的实际答案确实存在歧义。
此例使用默认推理设置的 GPT-5.6 Terra，因为我们发现平均而言，它在System One任务上的智能水平最接近 Jev。
有趣的是：一个相似的demo曾促使我们坚定投入System One模型这一方向！

工作流评估

我们设计了一种新型评估，用来衡量 AI 在代码中的实际表现。我们不针对某个“真实标签”做优化，也不允许测试框架和模型改变（否则可能通过工程化测试框架而过拟合）。相反，我们假设存在一张正确的计算图（即用代码表示的“工作流”），并以规模最大、最聪明、也最昂贵的外部模型预测出的概率作为参照。

换句话说：每个模型都获得相同的工作流。我们测试它与最聪明模型平均结果的接近程度（这里是 Astra 与 Fable）。

Jev 的表现远超常规：在近两个数量级的范围内占据帕累托前沿。我们还比较了让模型通过生成提示词、在思维链里完成全部逻辑的方案；但这种做法通常明显不如直接使用工作流。

这里的调用明显比上面的并排演示复杂得多，因为它们更能代表实现真正业务自动化所需的生产负载。下面是我们发布的 4 个工作流中最简单的一个：

最可靠的真实世界工作流通常包含许多彼此独立、已拆解的问题；其细粒度行为依赖概率而非离散决策。最终结果仍是离散分支，但要得出最终答案，中间会涉及许多依赖领域知识的工程工作，而且必须高度一致地执行。

完整细节——示例、分歧、完整查询与每个工作流——请参见 workflow evals 网站。

补充说明

首页所说的“快 193.6 倍、便宜 444.6 倍”来自这里；我们预计这接近真实世界收益的较高水平。
这些工作流的内容并非故意挑选或构造来突出模型优势，也不在训练分布内。但它们由模型能力团队成员制作，因此仍可能存在偏差。
我们采用 GPT-6 Astra 与 Fable 5.1 的平均值作为参考答案，这会使答案偏向 OpenAI 和 Anthropic 的模型；我们很可能低估了自家模型和 DeepSeek 模型的相对表现。
LLM 使用我们的 System One LLM 包装器，它约束 LLM 输出与 API 兼容的结构化决策。我们发现这是让 LLM 做决策的最准确方式，但比不带概率地给出决策更慢、也更昂贵。

幻觉与类型安全

幻觉和类型安全内在相关；我们认为后者是自动化的基本门槛。智能体出现一次幻觉式工具调用或许只是麻烦，但若它位于有延迟保证的系统中，或深埋在依赖链的多层之下，就完全不可接受。现有模型无论多聪明，仍会产生幻觉和类型错误。

补充说明

LLM 的数字来自 OpenRouter；其中几乎肯定存在偏差：更复杂的查询可能被路由到更好的模型。
我们的数字不是经验统计。模式匹配是有保证的，因此可以确信地在图中标记为 0%。

有趣的演示

我们工作的最令人兴奋之处，或许是它能够开启新的使用场景。还有很多内容想展示，先分享团队最喜欢的两个：

Doom

我们很喜欢它如何展示实时智能，以及代码 + AI 能做到什么。负责该演示的工程师曾担心每秒发起 10 次查询（最终成本约为每小时 7 美元），但团队其他人都觉得这比预期低！这个演示太有趣了，我们不仅打算发布深入讲解，也会举办一些活动来一起动手开发。

补充说明

演示基于以文本表示的数据结构化状态，而不是图像（目前还不是……）。
非 AI 的 Doom 机器人可以玩得更好；但我们想要的是能对不同游戏状态表示做出反应的机器人，而且最重要的是——能遵循指令真的很酷！

维基竞速（Wikiracing）

游戏的目标是从一个 Wikipedia 页面出发，只能沿途中遇到的链接前进，抵达指定的另一个页面。每一步都可能要在数百到数千个链接中选择！它非常适合展示的不只是“每秒智能水平”，还包括在高基数选择中不产生幻觉所带来的复利优势。

补充说明

据我们所知，第二与第三个挑战都以 “Rubber Duck” 开头完全是巧合；作者直到团队指出才注意到。
这里的加速比通常明显小于前面的演示，因为比较对象使用的是非推理模式（Astra 除外，它设为最低推理档）。这也是 Jev 往往以更少步骤完成的原因——这表示更高的智能水平。这样设置是为了使演示更容易观看；启用推理时，LLM 在这项任务上的表现会好很多。
Jev 支持最高 255 的基数。对于选择数更高的情况，我们会采用两阶段系统：先独立打分，再作显式选择，因此偶尔会变慢。

下一步

Jev 仍处在早期阶段。我们还有更多内容在路上，并且非常期待持续交付 🔥。

今天，我们开放早期体验，并尽可能快地邀请等候名单中的开发者。我们希望听到你需要自动化哪些决策、Jev 在何处表现出色、又在哪些地方不足。告诉我们你想构建怎样的科幻未来！

创办 TypeSafe，是因为我们相信 AI 需要一个让软件能够依赖的接口。我们迫不及待地想看到新的使用场景持续扩散到社区与经济之中。

一份常见问题（FAQ）

“System One模型”和 “Jev” 这两个名字从何而来？

灵感来自 Daniel Kahneman 的《思考，快与慢》。模型类别名称借用了“快速、直觉的系统 1 思考”和“缓慢、审慎的系统 2 推理”之间的区分。

“系统 1 思考”也常被视为容易出错。我们将在未来进一步说明原因，但我们相信，System One模型可以比其他替代方案更可靠。

Jev 的名字来自 William Stanley Jevons。我们预期机器智能会走上与煤炭类似的道路：蒸汽机效率提高之后，煤炭需求反而增加。智能成本每下降一个数量级，就会解锁多出若干数量级的使用场景。

为什么需要新的训练算法？

在“基于人类反馈的强化学习”（RLHF）阶段，每家实验室都在为同一项任务优化：产出人类评审者更偏好的文本。这对聊天产品是正确的任务，对自动化却是错误的任务。这正是我们所说的最苦涩的教训：针对正确任务进行优化，比数据、算力或算法更重要。

RLVR 非常适合能够用简单程序验证的任务，但大多数现实世界中的判断任务并不符合这种形态。这往往会导致尖峰式、缺乏稳健性的智能。

Jev 擅长哪些使用场景？

我们已经发现 Jev 能在不同行业中用于多样化的场景。我们在文档中概述了一些，也很期待看到开发者还会构建出什么。

Jev 只是一个更小的 LLM 吗？

Jev 既不小，也不是 LLM；因此它能位于智能帕累托曲线之外。

Jev 在公开基准上的表现如何？

我们刻意选择不发布针对公开基准的性能表现。事实上，我们计划只在产品更新时进行一次性的评估。

既然我们正在为模型开辟一个新的前沿，就希望推动更有用的最佳实践：

不要赋予公开基准任何权重。
鼓励用户为自己的使用场景创建评估（System One任务更容易评估）。
披露评估中的细微差别与限定条件。
即使你领先，也应弱化基准的重要性。

关于我们如何看待为基准优化，请参阅这篇博客文章。

训练数据来自哪里？

TypeSafe 的核心是一家数据研究实验室，而 AI 中最大的成果正是以这种方式取得的。所有数据都由我们自行制作。即使你要求，我们也不会用你的数据训练（没有冒犯的意思）。我们确实做了一些相当复杂的事情，但如果你想了解更多，我们就得先雇用你。

这些结果有点疯狂——它是如何做到的？

请参阅我们关于 AI 最苦涩教训的博客文章。简短的答案是：你会得到你所优化的结果。LLM 被优化为出色的聊天机器人和 Copilot，因此在人类参与其中的任务上达到了超人水平；而我们优化的是System One接口。