Jev：一个不生成文本的 AI 模型，TypeSafe 为什么要重新设计 LLM 的输出方式？

最近 TypeSafe AI 发布了一个很有意思的新模型Jev并把它称为第一款System One Model系统 1 模型。第一眼看到 Jev很容易把它理解成“一个更快、更便宜的小模型”。但把 TypeSafe 的官方发布文章、技术文档、API、workflow eval 和几个 demo 看下来之后会发现它真正想做的事情并不是把 LLM 再加速一点。它动的是一个更基础的问题如果一个软件系统真正需要的只是“判断”为什么一定要让模型先生成一段语言传统 LLM 的基本接口是Prompt → 一串 token → 文本哪怕程序最终只想知道这个客户是不是想退款这条安全告警是不是攻击这个工单应该转给哪个部门模型还是要先生成一段文本甚至是一个 JSON再由程序把结果解析回来。Jev 直接把这一步拿掉了。它的基本形式更接近State Questions → Decisions Probabilities不是“让 AI 写答案”而是“让 AI 做判断”。这也是 Jev 最值得看的地方。一、Jev 到底是什么从“生成文本”变成“直接做判断”先把 Jev 的输入输出讲清楚。假设我们在做一个航空客服系统当前收到一条消息{ ticket_message: My flight was cancelled. Can I get a refund?, refund_policy: Cancelled flights are eligible for a full refund. }这部分就是state。你可以把 state 理解成模型当前看到的“世界状态”。它可以是一段文本也可以组织成 JSON。安全系统里可以放告警、机器信息、进程信息客服里可以放聊天记录、订单、政策风控里可以放交易信息和账户历史。然后我们不让模型自由发挥而是明确告诉它针对这个 state我需要你做哪些判断例如Q1用户是不是在申请退款 Q2这个请求应该交给哪个部门 Q3用户当前情绪有多强烈Jev 目前把这些判断限制成三种 primitiveNoul、Choice 和 Score。NoulYes / No 判断例如Does the customer request a refund?Jev 不需要生成Yes, the customer appears to be requesting a refund because...它只需要给类似这样的结果Yes probability: 0.93也就是“我认为答案为 Yes 的概率是 93%。”Choice在给定候选项中选择比如程序规定returns shipping billing然后问Which team should handle this request?Jev 可以返回returns 0.61 billing 0.35 shipping 0.04最终答案是returns但更重要的是它没有只留下一个离散标签而是把整个概率分布保留下来了。这也意味着Jev 根本没有第四个答案可以输出。如果候选集只有returns / shipping / billing它不可能突然编出customer_success这里要区分一个经常被宣传语模糊掉的概念不能生成候选集之外的结果不等于不会判断错误。它不会输出一个不存在的类别但完全可能把 billing 错判成 returns。这才是更准确的“不会 hallucinate”的含义。Score有顺序的等级判断比如我们规定客户情绪0 calm 1 concerned 2 very angry假设 Jev 判断P(0) 0 P(1) 0.57 P(2) 0.43最终 score 就是0 × 0 1 × 0.57 2 × 0.43 1.43也就是说它不是神秘地“生成了 1.43”而是先预测每个等级的概率然后计算一个加权结果。这三种 primitive 基本把 Jev 的输出空间说清楚了二、真正特别的地方一次 state可以并行做很多判断如果 Jev 只是一个分类模型其实并不新鲜。更有意思的是同一个 state 可以同时对应很多 question。比如一个客服工单进来以后可以一次问是否要求退款 是否涉及支付问题 属于哪个业务部门 用户情绪怎么样 是否需要人工介入 是否存在欺诈风险这些问题共享同一份 state。但是它们之间没有自回归依赖。也就是说state → Q1 → answer1 → Q2 → answer2 → Q3 → answer3 → ...而不是answer1 → answer2 → answer3 → ...Q2 看不到 Q1 的回答Q3 也不会依赖前面已经生成了什么 token。TypeSafe 把背后的机制叫做parallel sampler。这就解释了他们官方那个 side-by-side demo。同样一段业务信息同样 27 个问题同时发给 Jev 和 LLM5.6-terra。左边 Jev 很快把所有判断都返回出来例如Revenue currently impacted? → 0.85 Integration issue present? → 0.90 Account health status? → watch Security concern present? → 0.84 Churn likelihood level? → ... ...右边的 LLM 即使也被要求输出结构化 JSON本质上仍然需要{ → → r → e → v → e → n → u → e → ...当然真实单位是 token不是字符但机制是一样的自回归生成。所以这个 demo 想证明的并不是Jev 比 GPT 更聪明。而是对于“一份状态 一大批独立判断”这种任务根本没必要通过一长串 token 把答案一个个写出来。TypeSafe 甚至很坦率地写了一个 Nuance这个 demo 的 state 特意设计得比较短、比较密集因此会让 Jev 的优势显得更明显。所以它首先是一个输出范式和 latency demo而不是一个完整的能力 benchmark。这点需要分开看。三、Jev 真正想进的不是聊天框而是传统软件 workflow理解 Jev 最关键的一个例子是官方的Security Incident workflow。这也是我一开始看最费劲、但看懂之后最能说明 Jev 思路的案例。假设安全系统收到一条告警某 Windows 主机出现 LSASS memory dump via comsvcs。传统 Agent 的思路可能是这里发生了什么 是否是攻击 风险多大 下一步应该怎么处置一次全交给模型。但 TypeSafe 的做法正好相反。第一步只让 AI 回答几个很小的问题例如Is this unauthorized activity? Does an existing record explain the activity? How strong is the evidence?也就是是不是未经授权 有没有正常业务记录可以解释 证据有多强在他们展示的某个 case 中Opus: unauthorized yes 0.92 Sol: unauthorized yes 0.93 Jev: unauthorized yes 0.56有意思的地方来了。三个模型离散答案都是 Yes。如果只看最终标签你甚至会觉得它们完全一致。但概率告诉我们0.92 / 0.93和0.56其实完全不是一个意思。第二步不是 AI 决定流程而是代码决定程序员提前写好了业务逻辑。可以粗略理解成if risk_is_low: close()elif risk_is_middle: notify_user()else: act()所以 Opus 和 Sol 因为判断更确定进入了ACTJev 因为判断比较保守进入NOTIFY USER这就是为什么官方 eval 页面顶部会看到Opus → REVOKE SESSIONS Sol → REVOKE SESSIONS TypeSafe → NOTIFY USER注意这不是三个模型直接被问“请选择最终动作”。这是它们前面几个局部判断不同导致普通代码走进了不同的 branch。第三步只有进入 Act才继续问更多问题Opus 和 Sol 接下来会继续被问凭据是否已经泄露 攻击者是否正在使用活跃 session 有没有恶意进程 有没有 persistence 是否正在外传数据 影响范围有多大官方这一层一共设计了 11 个 readings。而 Jev 因为上一层已经进入Notify User所以页面上你会发现它后面全是— — —这并不是 Jev 不会回答。而是程序根本没有再问它。因为它走的是另一条 workflow 分支。第四步Playbook 再根据判断执行动作如果真的进入 containment最终动作也不是模型自由写出来的。程序已经提前定义好BLOCK DESTINATION REVOKE SESSIONS DISABLE ACCOUNT ISOLATE HOST KILL PROCESS QUARANTINE FILE ...然后根据前面那些判断决定哪组规则被触发。于是整个系统实际是安全告警 ↓ Jev / LLM 做若干小判断 ↓ 普通代码 ↓ 是否继续调查 ↓ 再做一批小判断 ↓ 普通 Playbook ↓ 最终执行动作这就是 System One workflow 的核心。让模型负责“模糊判断”让代码负责“确定逻辑”。这和现在流行的 Agent 思路其实是有明显区别的。Agent 越来越倾向于把规划、工具调用、控制权交给模型Jev 则反过来把模型压缩成很多is_unauthorized(...) credentials_compromised(...) customer_is_angry(...) invoice_is_suspicious(...)这样的智能函数。四、为什么一定要输出 probability以及 RLCD 到底是什么如果最终程序还是要做 Yes / No那为什么 Jev 不直接给 Yes / No因为在真实系统里Yes, 0.51和Yes, 0.99完全不是一回事。比如一个安全系统可以写成P 0.60 → 暂不处理 0.60 ≤ P 0.85 → 转人工审核 P ≥ 0.85 → 自动执行再比如同样一个模型自动给邮件分类可以接受比较低的阈值。但冻结银行账户 隔离生产服务器 撤销用户 session就可以要求非常高的概率。所以 probability 并不仅仅是给用户“看看模型有多自信”。它本身就是业务逻辑的输入。这里就到了 Jev 目前最核心、但也最没有公开清楚的训练技术RLCD。全称是Reinforcement Learning for Calibrated DecisionsTypeSafe 对它的定位大致可以和 RLHF / RLVR 对比RLHF → 优化什么回答更符合人的偏好 RLVR → 优化能被程序验证的正确答案 RLCD → 优化正确判断 概率校准所谓calibration最简单的理解是如果模型长期在很多样本上说这个判断有 80% 概率成立那么理想情况下这批预测最后真的应该大约80% 是对的。比如预测概率约 0.2 的样本 → 大约 20% 最后为真 预测概率约 0.8 的样本 → 大约 80% 最后为真为什么这件事这么重要因为一个准确率 95%、但完全不知道自己什么时候错的模型和一个准确率也是 95%、同时能够可靠告诉你“这一批我只有 55% 把握”的模型对自动化系统的价值非常不一样。后者可以被程序自动执行高置信度样本 人工处理低置信度样本这也是 TypeSafe 为什么一直把calibrated uncertainty放在 Jev 的核心位置。不过这里必须说明目前的技术边界TypeSafe 现在只公开了 RLCD 的目标思想。真正的方法没有公开。目前看不到reward function 是什么 RL objective 是什么 calibration loss 是什么 训练数据怎么构造 RLCD 和 pretraining 怎么衔接所以我们知道它“想优化什么”但还不知道它“具体怎么算”。五、Benchmark 和几个 Demo 到底证明了什么TypeSafe 做了四套 workflow evalSecurity Incidents Agent Trace Observability Invoice Processing Customer Service其中最常被引用的是那张Accuracy vs Cost图。这张图其实只需要记住两条轴横轴cost per workflow 越左越便宜 纵轴accuracy 越上越高理想位置自然就是左上角。Jev 并不是图里 accuracy 最高的模型。例如一些大型模型 workflow 的 accuracy 比它高。它真正突出的地方是在相近 accuracy 下它的成本非常低。所以官方强调的是Pareto frontier在这一段价格区间里很难找到一个方案同时比 Jev 更便宜 而且 比 Jev 更准确这里还有一个特别值得注意的结果。同一个 LLM他们测试了两种使用方法workflow → 拆成很多小判断再用代码组合 prompt → 把整个业务逻辑写进一个 Prompt让模型自己推图里◇ workflow ○ prompt很多模型的 workflow 点明显高于 prompt 点。这说明一个很容易被忽视的问题Jev 的成绩里其实混合了两个因素。一个是Jev 这种模型本身。另一个是把复杂业务拆成很多小判断的 workflow engineering。即使换回普通 LLM这种 decomposition 本身也可能有明显价值。所以不能把所有提升都简单归因成“Jev 架构更强”。而且这套 benchmark 也不是没有局限。目前这些 workflow 没有完整的人类真实标签。官方采用强模型共识作为 reference再测不同模型和这个 reference 的一致程度。因此这里的 accuracy 更准确地说是与 reference consensus 的一致程度。而不是传统意义上严格的真实世界 ground-truth accuracy。这些 workflow 同时也是 TypeSafe 自己设计的。官方自己也承认这里面可能存在一定 bias。所以比较稳妥的结论是Jev 在 TypeSafe 定义的这一类“可分解、结构化、大量局部判断”的业务 workflow 上展示出了很高的 intelligence-per-dollar。而不是“Jev 已经证明全面超过 GPT 或 Claude。”这是两个完全不同的结论。除了 workflow他们还放了两个挺有意思的 demo。Doom实时 decision loop这个 demo 不是让 Jev 看 Doom 的画面。官方特别强调模型收到的是结构化的 textual state。例如可以理解成health 85 ammo 20 enemy_ahead true enemy_direction left being_attacked true然后不断问现在应该做什么模型做一次 Choiceshoot 0.71 turn_left 0.18 forward 0.07 ...程序执行动作游戏状态发生变化state_t → Jev → action_t → environment → state_t1再问一遍。官方 demo 大约做到了每秒 10 次查询。这个 demo 并不是在证明Jev 比传统 Doom Bot 更会玩。TypeSafe 自己都说完全不用 AI 的 Doom bot 可以玩得更好。它真正展示的是AI inference 已经可以便宜和快速到进入高频实时控制循环。Wikiracing高基数闭集选择另一个 demo 是 Wikipedia Racing。规则是从 Wikipedia 页面 A 出发只能点击当前页面真实存在的链接最终走到目标页面 B。一个页面可能有几百个链接。模型要做的其实就是当前这几百个合法链接里 哪个最有希望让我靠近目标这刚好是 Jev 的 Choice primitive 最擅长的场景。而且因为所有候选链接一开始就给定了它不可能生成一个当前页面根本不存在的链接。Jev 当前单次 Choice 最多支持 255 个候选项。如果页面链接更多他们会先做一轮 scoring再把筛选后的候选放进 Choice。所以Doom → 展示低延迟、高频判断 Wikiracing → 展示大量合法候选项中的闭集选择两个 demo 实际上分别展示了 Jev 的两个核心设计目标。六、Jev 真正的技术创新在哪里现在又有哪些东西还不知道看到这里很容易开始脑补 Jev 的网络结构Transformer Encoder ↓ 多个 classification heads ↓ Softmax但目前最好不要这么写。因为截至现在TypeSafe 真正公开确认的只有几个关键词new model architecture parallel sampler RLCD但以下内容都没有公开完整细节模型有多少参数 是不是 Transformer encoder / decoder 怎么设计 decision head 怎么做 parallel sampler 的具体数学形式是什么 RLCD 的 reward 是什么 loss 怎么写 预训练数据来自哪里 训练规模是多少也就是说现在可以确定 Jev 的接口范式和系统思想但还不能像读一篇完整 ML paper 那样从 architecture、objective、training、ablation 一路复现。所以现阶段我觉得 Jev 最值得关注的未必是“它到底用了哪个新 attention”。更重要的是它提出了一个不同的 AI 软件抽象传统 LLM 更像模型 通用生成器而 Jev 更像模型 概率判断原语程序员自己决定问题是什么 输出空间是什么 什么时候调用 多少概率才采取行动 什么情况下转人工 下一步控制流是什么模型只处理那些规则很难写但人看到上下文后又能够很快判断的事情。所以它和 Agent 的发展方向有一点非常有意思的张力。Agent 在不断扩大模型的控制范围自己规划 自己选择工具 自己执行 自己调整策略Jev 则反过来把模型的职责压得非常窄 但要求这个判断极快、便宜、可校准、可组合最终真正值得问的问题也许不是Jev 能不能取代 GPT而是我们今天究竟有多少 LLM 调用本质上根本不需要语言生成如果最后的软件真正只需要if probability threshold: do_something()那让一个自回归语言模型站在中间花大量计算去生成一段人类可读的 JSON也许确实不是最自然的方案。Jev 现在还远没有把这个问题完全回答清楚。尤其是它最关键的 architecture、parallel sampler 和 RLCD 仍然缺少完整技术公开现有 benchmark 也主要由 TypeSafe 自己设计。但它至少提出了一条很值得继续观察的路线AI 不一定非要“说话”。在很多软件系统里我们真正需要的也许只是一个足够聪明、足够快、足够便宜而且知道自己有多确定的判断函数。