“System One 模型”与 Jev 是什么？

曾在 OpenAI 联合发明了 ChatGPT 与人类反馈强化学习（RLHF）的 Diogo Almeida，推出了一套完全不同的全新模型类别——“系统一”（System One）模型，并发布了该范式下的首款公开模型 Jev。

现有的主流大模型擅长聊天，却很难在代码里稳定运行自动化。Jev 的核心取舍是放弃逐字生成自由文本，专注输出预定义结构中的类别、分数、概率和置信度。它不是另一个负责聊天或写文章的模型，而是要成为可以嵌入程序控制流的快速决策组件。

“System One”源于丹尼尔·卡尼曼的《思考，快与慢》：系统一代表快速、直觉式的判断，与需要长时间推演的系统二相对。TypeSafe 借这个名字强调，它要解决的是大量需要低延迟反应的分类、评分和路由问题。Jev 的名字则来自经济学中的“杰文斯悖论”（Jevons paradox）：蒸汽机效率提高后，煤炭总消耗反而增长。它所表达的产品判断是，当一次智能决策的成本和延迟下降几个数量级，软件对智能判断的需求也会随之增长。

这套模型为什么会出现？因为为人机对话设计的自由文本生成机制，与自动化流水线追求的低延迟、固定接口和可控分支存在明显错位。

过去几年里，大模型在开放式对话和长文本创作上表现亮眼，但在需要确定性逻辑的企业后台代码中，落地进展却常不及预期。主流大模型主要依托 RLHF 对齐，核心目标是输出符合人类评审员偏好的自然语言。为了适配对话，模型必须具备自由生成任意字符串的能力，但这套机制一旦放入代码流水线，就会暴露出三个工程死穴：

响应延迟过高：传统大模型采用自回归逐 token 串行生成。TypeSafe 引用的前沿基准显示，端到端响应时间常在 3 秒到 329 秒 之间。面对屏幕前的人类用户这一耗时尚可接受，但在需要多级级联调用的程序内部，数十秒的等待会迅速累积至不可用。TypeSafe 用“快 100 倍”概括产品卖点；其给出的 Jev 端到端耗时范围是 70ms 至 500ms，实际倍数取决于比较模型与具体任务。

类型系统极其脆弱：大模型原生输出的是字符串，即便提示词要求输出 JSON，本质仍需下游代码反序列化校验。一旦出现多余前缀、格式损坏或意外拒答，底层一次解析异常就会让整条业务调用链崩溃中断。

缺乏可直接依赖的置信度估计：对话模型经由偏好对齐后往往表现得过度自信，自我评估前后矛盾。如果系统无法判断模型何时有十足把握、何时在盲目猜测，下游程序就无法安全地设置自动放行阈值或人工介入兜底。

在人类认知中，系统一并不天然代表可靠；快速直觉同样可能出错。TypeSafe 的技术主张是，当模型剥离自由文本生成、专注类型安全与概率校准后，至少可以从接口结构上消除格式错误与解析异常。至于语义判断是否正确，仍是另一层问题。

它和现有模型有什么区别？

Jev 并不是现有大模型的微调缩小版，而是一套从解码机制到训练范式全部重新构建的独立模型栈。

传统 LLM 架构：
[非结构化输入] ──> [自回归解码器（逐 Token 串行生成）] ──> [自由字符串（需外部校验，存在解析与幻觉风险）]

System One (Jev) 架构：
[非结构化状态] ──> [并行采样器（单次前向硬件加速）] ──> [预定义强类型概率（数学级零类型错误，自带校准置信度）]

Jev 最关键的架构取舍在于：彻底放弃自由文本生成。传统大模型采用自回归（Autoregressive）机制，每生成一个新 token 都必须依赖前一个 token，计算在时间维度上高度串行化。而 Jev 在发起查询前由调用端预先定义好输出结构，模型在前向传播中通过硬件感知的并行采样器（Parallel Sampler）单次计算出所有维度的数值输出。TypeSafe 称这使得其端到端响应耗时压缩到了 70ms 至 500ms，在官方口径中实现了相比传统大模型数十倍乃至上百倍的提速。

这一架构重构同时在接口层消除了类型结构错误。传统大模型的输出空间涵盖整套自然语言词表，而 Jev 的输出空间在推理前就已由预定义模式（Schema）完全限定，输出端直接映射为离散类别或标尺的数值概率，因此结构与类型的匹配由接口本身保证。但需要说明的是，这仅能保证输出格式符合预定义结构，并不证明模型的语义判断一定正确。

在训练算法上，现有工业界主要采用两条路线：一条是优化人类阅读偏好的 RLHF，容易导致模型为了迎合人类而过度自信；另一条是面向可验证奖励的强化学习（RLVR），依赖能够被代码单元测试低成本验证的目标（如数学证明或代码编译），但这往往导致模型在缺乏确定性测试用例的真实业务场景中泛化能力不足。

为此，TypeSafe 提出了“面向校准决策的强化学习”（RLCD，Reinforcement Learning for Calibrated Decisions）。RLCD 不考察文字表达是否生动，而是将优化目标定位于“校准决策”（calibrated decisions），官方称其目标是使更高置信度对应更高准确率（higher confidence means higher accuracy），输出具备认识论诚实性的概率分布。不过，官方材料并未公开具体的训练实现细节与独立校准曲线；按其设计设想，面对模糊或模棱两可的边界样本，模型会输出更为平坦分散的概率分布，以便下游工程代码设定阈值进行分支跳转与兜底拦截。

TypeSafe 宣称 Jev 比传统大模型快 100 倍、便宜 100 倍且输出 token 免费。按其公布的早期访问定价，Jev 每百万输入 token 为 0.042 美元（折合每十亿 token 42 美元），输出端确实标为免费；但官方也明确承认，这一定价是否可长期持续仍需时间检验，且百倍降本宣称在官方四工作流实测中也因任务而异（在相近准确率对比中，Terra 成本约高 76 倍）。

它主要用来干什么？成为代码里的“智能判断节点”

在实际工程系统中，完全依靠硬编码规则过于脆弱，而把全流程托付给单体大模型又容易失控。Jev 的核心定位是嵌入常规代码控制流里的“模糊语义判断节点”：代码掌控全局控制流，模型仅负责给出带概率的局部语义裁决。

它最直接的用途，是替代代码中难以穷举规则的“智能 if-else”：对请求进行路由和分类，对风险、满意度或匹配度评分，从非结构化输入中提取受限字段，或者判断某一步是否需要人工介入。低延迟让它也能进入实时交互；低单价适合批量处理大量记录；固定候选和概率输出则使它可以充当其他大模型前后的安全护栏。

在官方 SDK 及开源适配器中，底层语义决策被抽象为三种标准类型原语：

Noul（布尔判定）：输入非结构化文本与判定条件，输出该命题成立的概率，用于处理二元判断。

Choice（离散分类）：在一组明确定义的候选集合中进行单项选择，返回涵盖所有类别的完整概率分布及综合置信度得分。系统原生最高支持 255 个类别的选择；面对更大范围的候选集时，系统会先并行评分再进行离散抉择。

Score（有序评分）：在预设的连续标尺或有序评级（Rubric）上进行打分，返回当前评分值、各档位的离散分布及置信度，适用于严重程度、情感满意度或契合度量化。

以企业日常的员工费用报销审核为例，可以清晰看出两种范式的差异。

在传统大模型方案中，开发者通常将全部业务规范塞进一段长提示词：“每笔报销需附发票凭证；若凭证无法辨认则打回；判断属于餐饮、差旅还是设备采购；餐饮报销超过 75 美元且明细与报销说明不符时需经理审批；其余直接通过。”这种单体提示词要求模型在思维链中一步推导出最终动作，多步逻辑杂糅极易发生推导漂移。

而在 System One 架构下，该业务被拆解为一个由确定性代码和语义原语共同构成的计算图：

                    [收到报销申请与票据]
                             │
                             ▼
         [Q1: Noul] 票据图像或文字是否清晰可读？
                  /                     \
       (否 / 低概率)                     (是 / 高概率)
              /                                 \
       [打回要求重新上传]                  [Q2: Choice] 支出属于何种类型？
                                                │
                                    ┌───────────┼───────────┐
                                    ▼           ▼           ▼
                                  [差旅]      [设备]      [餐饮]
                                    │           │           │
                                    │           │           ▼
                                    │           │    [Python 原生代码]
                                    │           │     金额是否 > $75 ?
                                    │           │      /          \
                                    │           │   (否)          (是)
                                    │           │    │             │
                                    │           │    │             ▼
                                    │           │    │   [Q3: Noul] 发票明细
                                    │           │    │   与申报描述是否吻合？
                                    │           │    │      /            \
                                    │           │    │  (吻合)          (不符)
                                    │           │    │    │                │
                                    ▼           ▼    ▼    ▼                ▼
                                     [ 系统自动核准通过 ]           [ 触发经理二次审批 ]

这种架构将数值比较 amount > 75 直接交还给 Python 运行时处理，杜绝了模型看错数字的风险；票据清晰度与语义匹配度则交由 Noul 和 Choice 节点独立运算。这种模式体现了系统的核心理念：确定性逻辑交给代码，语义理解交给模型。

为了方便开发者将现有 LLM 迁移测试，官方开源了 Python 适配库 system-one-adapter。官方 README 目前仅给出了 Noul 的实际调用示例（Choice 与 Score 的构造参数签名尚未在 README 中完整公开）：

from system_one_adapter import SystemOneAdapterClient, Noul

# 初始化客户端，启用结构化输出与概率归一化
client = SystemOneAdapterClient(
    structured_outputs=True,
    llm_answer_mode="probabilities",
    normalize_probabilities=True,
)

# 传入待处理的非结构化上下文与 Noul 布尔问题
response = client.system_one(
    state="本书印刷精美且内容详实，但外包装严重破损导致封面折损。",
    questions={
        "is_positive": Noul(instructions="整体评价是否属于正面好评？"),
    },
    provider="openai",
    model="gpt-4o-mini",
)

# 响应结果自动封装为强类型对象，内含耗时与概率诊断
print(response.answers)
print(response.usage.latency)

能达到什么效果？官方评测与原型演示

为了评估模型在代码集成环境下的表现，TypeSafe 没有采用传统公开学术基准，而是自建了工作流评测。团队认为公开榜单容易诱发针对测试集的优化，也无法直接反映模型作为业务组件嵌入系统时的表现。

官方构建了“工作流基准”（Workflow Evals），在固定的代码计算图内测试模型表现，涵盖四大典型企业场景：

安全事件告警分流（Security Incidents）：当终端或服务器触发安全告警时，结合机器历史档案，裁决自动关闭、转交人工分析师还是实施网络隔离。

Agent 轨迹可观测性（Agent Trace Observability）：在客服智能体处理完客户工单后，遍历其全量上下文与工具调用日志，判定是否需要人工介入及紧急程度。

供应商发票核验（Invoice Processing）：比对发票票面信息、采购订单及入库单据，决定直接放行支付、暂扣核实还是打回退票。

客户服务动态路由（Customer Service）：根据用户多轮沟通上下文与账户实时状态，决定智能体下一步的具体执行动作。

由于真实业务语义不存在天然唯一的真值标准，评测基准以两款前沿大模型——GPT-6 Astra 与 Claude Fable 5.1 在开启 High Thinking 深度推理模式下的判定均值，作为事实上的参照共识标签。其余模型均采用默认推理配置参测。

评测得出了一个清晰结论：在这四个样例任务的等权平均里，每个参测模型拆成结构化工作流后，都比让同一模型用一个单体提示词完成全流程更准确、更便宜、更快。这个结论只覆盖这套 harness 与样例任务，不能直接外推到所有业务。

在同等工作流配置下，TypeSafe 官方公布的四项等权平均总览如下。所有准确率都相对于团队自建的“共识标签”，并非外部公认真值；除两款参考模型外，参测模型使用各自提供商的默认推理设置。

在官方评测公布的四个工作流等权平均总览中：Jev 的综合准确率为 67.8%，平均耗时 0.4 秒，单次成本为 0.0004 美元；与之准确率相近的 OpenAI Terra 准确率为 67.9%，耗时需 10.1 秒，成本为 0.0304 美元。在此项可直接复算的总览对比中：在相近准确率下，Terra 相比 Jev 耗时约 25 倍（10.1s 对比 0.4s），成本约 76 倍（$0.0304 对比 $0.0004）。

除上述四个工作流的等权平均总览外，官方评测页面后续还依次列出了四个单项工作流：安全事件（Security Incidents）、智能体轨迹可观测性（Agent Trace Observability）、发票核验（Invoice Processing）以及客户服务（Customer Service）。官方数据显示，Jev 在大幅削减时延与成本的同时，保持了与主流前沿大模型相当的决策质量。

两个原型演示：高频决策与受限候选选择

依托低延迟与强类型特性，官方展示了几个传统大模型难以胜任的原型场景：

Doom 实时控制：在官方演示中，工程师将经典游戏 Doom 运行中的实时状态提取为结构化数据并输入 Jev，模型以每秒 10 次（10 queries/s）的频率输出下一步动作；TypeSafe 称驱动该游戏智能体每小时的总体调用开销约 7 美元。

维基竞速挑战（Wikiracing）：规则是从一个维基百科词条出发，仅通过点击词条内部超链接跳转到达指定词条。每一步操作往往面临大量候选链接。传统生成式模型在自由输出文本时可能伪造页面中不存在的链接；而在 Jev 中，由于候选集合受到严格的类型与模式约束（仅在给定的合法候选链接集合内打分选择），因此结构上杜绝了生成非法链接的情况。官方称其以更少的步数完成了路径寻找，但这源于候选集合受类型约束的结构保障，并不代表在所有语义层面零幻觉。

现在的局限性是什么？

尽管官方基准表现优异，但在系统选型与实际落地前，仍需审慎评估其背后的技术假设与边界条件。 三层“可靠性”的工程边界：在系统选型中，必须清晰区分三个层面的“可靠性”，避免将局部机制推论为全流程正确：

1. Schema 与类型安全（Type Safety）：Jev 的零类型错误源于输出空间直接绑定预定义模式（Schema），输出端直接映射为离散类别或标尺数值，接口在结构上杜绝了 JSON 损坏或格式漂移；这是目前唯一能够从机制上保证的结构可靠性。
2. 概率校准（Probability Calibration）：RLCD 以“更高置信度对应更高准确率”为训练优化目标，旨在让模型输出诚实反映把握度的概率分布；但这属于模型训练目标与官方主张，目前没有公开充分的训练细节与独立校准曲线，不可等同于已验证的绝对事实。
3. 业务语义正确性（Semantic Correctness）：无论类型格式如何安全、置信度如何标定，模型推断本质上仍属统计概率，并不保证业务逻辑判定绝对正确。在生产落地中，仍必须由用户自建针对业务的评测基准（eval）、配置严谨的决策阈值与人工介入兜底机制。

基准与环境考量：官方公布的亚秒级时延主要测试于美西服务机房与同地域开发环境，对于跨国或长距离调用的团队而言，物理网络往返延迟（RTT）会在总耗时中占据明显份额。此外，官方坦言超低定价策略能否长期持续仍需商业检验；以 Astra 与 Fable 5.1 作为评估参照系，也在客观上偏向了特定模型家族的逻辑偏好。

架构适用边界：Jev 放弃的是自由字符串生成能力，因此不能直接承担自由对话、开放式问答或文本创作。它更适合作为高吞吐的语义路由网关、实时交互逻辑以及确定性系统内的特征提取器。

对于系统架构师而言，Jev 的价值不是取代传统大模型，而是促成了智能架构的分层演进：极速、廉价的系统一模型负责处理绝大部分确定性的数据流转与边界防御，而将昂贵、擅长深思的长思维链大模型保留在最关键、最需要推演的专家级节点上。

常见问题解答

Jev 是否只是把现有大模型做了轻量化剪枝或蒸馏？
不是。Jev 既不是轻量化小模型，也不是传统意义上的自回归大语言模型。它的输出空间、采样器和训练算法全部重构，专注于分类与概率校准任务，因此脱离了传统 LLM 的帕累托前沿曲线。

为什么官方不公布通用公开学术基准（如 MMLU）的成绩？
官方认为通用公开榜单容易导致提示词过拟合，无法反映模型作为函数组件嵌入生产代码时的真实表现。团队主张用户针对自身业务工作流构建评测，直接检验类型稳定性与校准精度。

Jev 的训练数据来自哪里？
TypeSafe 称数据由内部自行制作，并表示不会用客户传入数据训练。