【搬运】Jev官方博客：Introducing System One Models & Jev

apd_csdn

墨衍会员 · AI 创作全网分发码龄7年

关注

转载 2026-09-21 14:45:04 93 阅读 AI 写同款· GEO 优化 ›

「文智助手」全场景办公AI助理AI+OPC全流程实践方案（大赛作品）阅读详情

原文：Introducing System One Models & Jev
开发者平台：https://console.typesafe.ai/home

Diogo Almeida，TypeSafe 创始人
2026 年 9 月 15 日
原文配图

多年来，模型在聊天方面已经达到超人水平，那么自动化究竟在哪里？

这是过去四年来一直驱动我的问题。在 OpenAI 工作期间，我参与构建了让语言模型能够理解指令、与人交流的方法。那项工作最终成为 ChatGPT 背后的研究基础。当时我以为，聊天模型或许会带来 AGI；但尽管外界充满炒作，我逐渐意识到，那里缺失了某种非常重要的东西。

经过两年的隐身研发、无数技术挑战和研究突破……我非常激动地宣布，TypeSafe AI 今天发布了我们的首个 System One 模型：一种全新的前沿模型，专门用于快速做出结构化决策，让软件可以直接使用。

我们构建了一套完全专注于自动化的新技术栈，包括全新的模型架构、用于实现最大效率的并行采样器，以及一种名为“校准决策强化学习”（Reinforcement Learning for Calibrated Decisions，RLCD）的训练方法。

我们的首个公开模型是 Jev，现已开放早期访问。与现有 LLM 相比，Jev 在 System One 任务上能够达到相近的智能水平，但速度和效率高出两个数量级。Jev 放弃了字符串生成能力，转而针对结构化输出进行了优化，因此不会产生幻觉。

可以把 Jev 想象成一个具备前沿智能的函数调用：输入非结构化状态，输出带类型的概率决策。

非凡的主张需要非凡的证据，下面就是我们的依据。💅

新旧两种前沿

	现有 LLM	System One + Jev
优化方式	人类反馈强化学习（RLHF）/ 可验证奖励强化学习（RLVR）	校准决策强化学习（RLCD）
优化目标	人类偏好：生成评审人员更喜欢的文章和聊天回复。可验证奖励：生成可以通过程序验证的输出。	校准决策：针对 System One 任务，给出具有认识论诚实性的概率。
输入	非结构化数据（例如文本），重点是顺序消息。	非结构化数据（例如文本），重点是结构化程序状态。
输出	字符串/生成文本。字符串灵活，几乎可以表示任何内容：聊天回复、代码、幻觉、拒绝，甚至类型安全的结构化值。要让软件使用这些回复，就必须进行解析和验证。同时，AI 始终存在偏离轨道的风险。	类型安全的结构化值。可能的输出及其结构都已预先定义。模型不会产生类型错误。所有答案都会附带经过校准的概率和置信度分数。
采样方式	顺序生成。一次生成一个 token，每个 token 都基于上一个 token。	并行生成。在一次查询中生成所有输出。效率极高，并且充分考虑硬件特性。
成本	输入 token：每百万 token 约 0.20–10 美元。输出 token：约为输入 token 的 5 倍价格。	输入 token：每百万 token 0.042 美元（每十亿 token 42 美元）。输出 token：免费（便宜到无需计量）。
速度	前沿模型的端到端响应时间为 3–329 秒。足以与人交互，但集成到代码中时会成为巨大瓶颈。	TypeSafe 的端到端响应时间为 70–500 毫秒。对于形态类似 System One 的查询，在相同前沿智能水平下，速度可以快 40–200 倍。
置信度	即使明确要求模型估计置信度，模型通常仍会过度自信且前后不一致。如果模型有 95% 的概率完成任务，却无法告诉你什么时候处于那 5% 的失败区间，就无法自动化该任务。	每个输出都会始终传达置信度和不确定性。经过校准：置信度越高，准确率越高。更加一致：对于相似输入会返回相似答案。
使用场景	人在回路中的任务（聊天机器人、副驾驶、编程代理）。通用且强大，但需要人工监督，因为它们的自由度也意味着可能偏离轨道。可验证问题（数学证明、内核优化）。当正确性可以低成本、自动化地检查时，LLM 可以生成、测试并迭代，直到找到可行方案。演示。字符串的灵活性非常适合快速制作原型，即使这些原型只能偶尔正常工作。	AI 驱动的工作流/智能 if 语句。结构化输出可以嵌入普通软件，成为模糊决策规则：在手写逻辑过于脆弱的地方进行分类、路由、评分、提取或分支。周围的代码限制了模型的自由度，使其更容易组合成可靠系统。大数据上的 Map-Reduce。将 PB 级数据转化为特征和洞察。实时应用。 100 毫秒级速度意味着可以在用户体验至关重要的应用中使用 AI。验证一切。对 LLM 提示词、推理轨迹和/或输出进行评分、判断、验证、设置护栏，并检测越狱。

证据/技术结果

我们喜欢怀疑论者，我们自己也是怀疑论者。有些主张很容易验证：

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

对于更大胆的主张，我们希望尽可能提供完整的背景和细节。

并列演示

我们的并列演示展示了模型与 LLM 之间的一个关键差异：Jev 会并行输出所有概率，而不是像自回归模型那样逐 token 生成。字符串极其强大且通用，但代价高昂。实际上，“放弃”字符串反而让我们获得了许多超能力！

并列演示截图

细节说明

对于已经获得 TypeSafe 早期访问权限的用户，可以查看实际查询。
- 查询经过了高度简化，并且 questions 被选用为具有描述性、便于人类理解的键，因此屏幕上的输出更容易看懂。
- state 也是一段短小、密集且信息丰富的文字，用来强调采样方法上的差异。较短的输入对我们的模型更有利。
对于眼尖的读者，在录制的运行过程中，Jev 唯一与 GPT-5.6 Terra 不一致的地方是“流失可能性等级”（Churn likelihood level）。在我们看来，实际答案确实存在真实的歧义。
本例使用了默认推理设置的 GPT-5.6 Terra，因为我们发现，平均而言，它的智能水平与 Jev 最为接近。
有趣的是：正是类似的演示让我们决定全力投入 System One 模型这一方向。

工作流评测

我们创造了一种新的评测方式，用来衡量 AI 在代码内部工作的效果。我们不针对某个真实标签分类进行优化，也不允许测试框架和模型发生变化——因为这可能通过调整测试框架而导致过拟合。

相反，我们假设存在一个正确的计算图，也就是一个用代码表示的“工作流”，然后使用规模最大、最聪明、最昂贵的外部模型的预测结果作为参考概率。

换句话说：每个模型都使用相同的工作流。我们测试它们与最聪明模型的平均结果相比如何——在本例中，参考模型是 Astra 和 Fable。

Jev 的表现远超图表范围，在近两个数量级的范围内占据了帕累托前沿。我们还将它与那些通过生成提示词、在思维链中完成所有逻辑的模型进行了比较；但这种方式通常明显不如直接使用工作流本身。

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

最可靠的真实世界工作流，通常包含许多相互独立、经过拆解的问题，其细粒度行为依赖概率，而不是离散决策。最终结果可能是离散分支，但要得到最终答案，需要大量领域专用工程，并且这些工程必须以高度一致的方式执行。

有关所有细节——示例、分歧、完整查询和每个工作流——请访问我们的工作流评测网站。

工作流评测图表

工作流评测补充图表

细节说明

我们主页上“速度快 193.6 倍、便宜 444.6 倍”的说法就来自这里；我们预计，这些数字处于现实世界收益的较高端。
这些工作流的内容并不是为了让我们的模型看起来更好而刻意选择或构造的，也不在我们的训练分布中。不过，它们由模型能力团队的成员制作，因此仍可能存在一定偏差。
我们使用 GPT-6 Astra 和 Fable 5.1 的平均结果作为参考答案，这会让参考结果偏向 OpenAI 和 Anthropic 的模型。我们很可能低估了自家模型和 DeepSeek 模型的相对表现。
LLM 使用的是我们的 System One LLM 封装器，它会限制 LLM 输出与我们 API 兼容的结构化决策。我们发现，这是从 LLM 获取决策最准确的方式，但它通常比在没有概率的情况下直接给出决策更慢、更昂贵。

幻觉与类型安全

幻觉和类型安全本质上相互关联，而我们认为，类型安全是自动化的基本要求。

在代理中，一个虚构的工具调用可能只是令人不便；但如果它出现在一个具有延迟保证的系统中，或者深埋在依赖链的好几层之下，那就绝对无法接受。现有模型——无论多么聪明——仍然会产生幻觉，也会出现类型错误。

细节说明

LLM 的数据来自 OpenRouter，因此这里几乎肯定存在偏差：更复杂的查询可能会被路由到更好的模型。
我们的数据并非经验测量结果。由于模式匹配是有保证的，因此我们可以有把握地在图表中加入 0%。

有趣的演示

也许我们这项工作最令人兴奋的地方，是它能够带来全新的使用场景。我们还有更多内容要展示，但这里先介绍团队最喜欢的几个案例。

Doom

我们很喜欢这个 Doom 演示所展现的实时智能，以及代码加 AI 能做到的事情。负责开发的工程师曾担心每秒发出 10 次查询——这最终大约需要每小时 7 美元——但我们其他人都认为，这个成本比预期低！这个项目非常有趣，因此我们不仅计划发布深入的操作讲解，还打算举办一些活动，一起围绕它进行开发。

细节说明

该演示使用的是带有文本的数据结构形式的结构化状态，而不是图像（目前还不是）。
不使用 AI 的 Doom 机器人可能玩得更好，但我们希望机器人能够对不同形式的游戏状态做出反应；更重要的是——能够遵循指令，实在太酷了！

Wikiracing

这款游戏的目标是：从一个 Wikipedia 页面出发，只使用沿途遇到的链接，抵达指定的另一个 Wikipedia 页面。每一步都可能需要在数百甚至数千个链接中进行选择！这是展示“每秒智能量”的绝佳场景，也能展示在高基数选择中避免幻觉所带来的累积收益。

细节说明

据我们所知，第二个和第三个挑战都以“Rubber Duck”（橡皮鸭）开头，完全是随机的。作者直到团队指出这一点时才注意到。
这里的加速幅度通常比前面的演示小得多，因为本次比较使用的是模型的非推理模式（Astra 除外，它使用了最低推理设置）。这也是 Jev 往往能用更少步骤完成任务的原因之一——这代表着更高的智能水平。这样设置是为了让演示更容易观看。启用推理功能后，LLM 在这项任务中的表现会好得多。
Jev 支持最高 255 的基数。对于基数更高的选择，我们会采用两阶段系统：先独立评分，再明确做出选择，因此偶尔会出现速度下降。