Jev：当模型放弃说话

它是什么

TypeSafe AI 的官方介绍里有一句话概括得很紧：Jev 是一个 frontier-intelligence function call，非结构化的 state 进，类型化的概率决策出。 这句话同时说明了它的野心和它的边界，它把模型当成一个可以被代码直接调用的函数，代价是放弃生成。

创始人 Diogo Almeida 在 OpenAI 参与过 InstructGPT 和早期的 RLHF，也就是让模型学会「好好说话」的那批工作。三年后他做的第一件事是让模型闭嘴。 36氪转载量子位时的标题写得很刻薄，也很好笑：亲手教了 AI 小半辈子好好说话，临了直接喊 AI 闭嘴。

1.1 三种原语

官方文档把接口拆成三个 primitive，名字都很短，能力边界也很硬。

拿一个客服场景做例子。输入是一段 state 加三个问题，返回的是概率，中间没有任何一段文字被生成出来。

这个例子是我按官方 primitives 的定义和几个公开 demo 拼的示意，不是官方原文。要看清的是结构：程序拿到的是三个可以直接进 if 判断的值，而不是一段需要解析的 JSON 文本。 输出空间在调用之前就已经存在，这是它和 Structured Outputs 最实质的区别。用 JSON Schema 约束 LLM 是在解码阶段屏蔽非法 token，物理上保证不写出 schema 之外的字段； Jev 干脆不产生 token，选项只有 refund / rebooking / information 的时候，cancel_account 这个输出在接口里根本不存在。

1.2 一次调用，多个问题

每个问题对同一份 state 独立求值，互相看不到对方的答案。官方文档给的说法是加问题几乎不改变响应时间，也不会造成 context rot。 这一点在 Agent 场景里很实际：一轮任务跑完，你可能同时想知道「目标完成了吗」「有没有调用危险工具」「用户是不是在抱怨」「输出合规吗」。 以前这是四次模型调用，现在是四个字段。

原子化是这个设计的前提。官方文档的原话是，一个问题应该问一件具体、边界清楚的事，颗粒度接近「一个知识丰富的人在几秒内能给出的直觉判断」。 如果一个问题需要展开推理或者同时权衡几个独立因素，就该拆开，再在代码里用自己的公式组合。 这样做的附带好处是调整权重时改的是代码里的系数，不是重写提示词。

1.3 「零幻觉」的边界

官方原文是 optimized for structured outputs and can't hallucinate。这句话得拆成两半读，两半的成立程度差很远。

成立的一半是类型安全。输出空间在调用前定义好，模型不可能返回选项之外的标签。官方说这是数学上不可能，至今没被反例推翻。 对于埋在依赖链里、或者有延迟保证的系统，这个属性确实值钱：一个幻觉出来的工具调用最多让人烦，但如果它出现在三层依赖之下，整套东西会直接不可用。

不成立的一半是事实正确。类型对不等于内容对。给 A、B、C 三个选项，它一定选其中一个，但正确答案是 A 的时候它可能选 B。 量子位把这一点说得很准：类型正确而事实不一定正确。知乎上一位答主干脆把这套话术反过来用，用同样的逻辑去强制 LLM 做结构化输出，也能宣称消灭了幻觉问题。

还有一个更少被提到的坑：Noul 不会弃权。强制二选一、又不给 unknown 或 needs_review 出口时，它会给一个偏低的概率，而不是说不知道。 用它当判断器，兜底出口得自己设计。

1.4 名字的来历

System One 借的是卡尼曼《思考，快与慢》里的系统一和系统二。系统一是快速直觉，系统二是慢速推理。 当下的模型基本都在卷系统二，长思考、思维链、自我反思，越写越长。Jev 反过来做系统一。

官方承认「系统一」这个词在心理学语境里往往隐含「容易出错」，但他们的说法是 System One Model 可以做得比替代方案更可靠，理由留到以后讲。 Jev 这个名字取自杰文斯悖论：威廉·斯坦利·杰文斯观察到蒸汽机效率提高之后，煤的总消耗量反而上升了。他们的类比是，智能的单位成本每降一个数量级，就会解锁更多以前舍不得调用模型的场景。

这只长着象鼻的企鹅该不该单独发一张船票，是后面所有争论的起点。

它为什么快

速度来自一个很朴素的动作：不生成。这个动作同时解释了它为什么便宜，也画出了它能做什么的边界。

2.1 省掉的不只是几个 token

自回归模型的成本是串行的。输出长度为 L 的时候，要经历约 L 次相互依赖的解码步骤，每一步都得等上一步采样完。哪怕答案只是一个枚举值，前面也得先生成一串解释再收敛到那个值。 Agent 流程里最典型的浪费就在这里：程序真正需要的可能只有三个字段，模型却走完了「生成一段字符串」的整条路径。

Jev 的做法是把这条路径整个拿掉。state 只编码一次，问题之间互相独立，所有候选在一次前向里并行求值，切出 logits 做 softmax 就得到概率。 Markdown 拼装、格式校验、解析失败重试，全都不存在需要的理由。

70 到 500 毫秒这个区间要带条件看。它随 state 长度、字段数和候选数变化，官方自己说评测大多跑在美西的笔记本上。 知乎上有人补了一刀：国内访问美西，海底光缆那 120 毫秒躲不掉，200 毫秒打底。速度优势是真的，但它是服务端算出来的数，端到端要加上你自己的网络。

2.2 开源复现证实了什么

官方没有公开网络结构、参数规模、训练配方和 RLCD 的具体算法。所以能看的只有复现。社区里比较有代表性的有三个。

这三个项目加在一起能证实一件事：并行类型化决策这个接口形态，用普通的小模型就能复现，不需要什么秘密架构。 jev-on-a-laptop 的作者把结论写得很克制，也说得很清楚：typed outputs 和 100% schema 有效是 by construction 的；但「calibrated confidence」这一点在他们的测量里不成立，候选 logits 上的原始 softmax 只是一个置信度代理，不是训练过的校准。

不能证实的部分同样重要：官方 Jev 的内部结构、参数规模、RLCD 的训练目标。这些只有厂商叙事和第三方复现两种证据，两者不能互相替代。

2.3 复杂度总要有人还

官方首页那组 193.6 倍更快、444.6 倍更便宜，出自他们自建的四条 workflow eval，参考答案取 GPT-6 Astra 与 Fable 5.1 的平均。 官方自己承认这是实际收益的偏高端，工作流由模型能力团队制作，可能存在偏差。 第三方复现里更实在的数字是 3.4 到 7.9 倍，官方宣传里的 20 到 200 倍是另一个量级。

群里有人说了一句很到位的总结：复杂度不是随便压掉的，压掉都是有代价的。代价具体有三项。

• state 理解和候选编码没省。候选越多、描述越长，成本还在涨。255 个候选和 2 个候选不是一个价，官方也承认高候选数要走两段式，会有偶发的额外耗时。
• 它不解释。Jev 不生成文本，所以判断错了不会给你理由。调试只能回头读自己写的 criteria，任何需要审计或对客展示的环节都得再挂一个生成模型。
• context rot 存在。官方文档直接写了这一条：state 里塞进与问题无关的材料时准确率会下降。Agent 的 trace 又长又杂，这条会经常生效。

群里的七场争论

下面这些是 9 月 20 日两个技术群里关于 Jev 的讨论，加上我补的背景和证据。观点零散，但基本能归到三个技术命题上，我放在最后一张表里。

3.1 泛化分类器，还是聪明的 if 语句

我理解是一个泛化的分类器。实操起来结合到真实工作流其实问题一大堆。

max

你可以认为是 Jev 就是一个聪明的 if 语句。相当于能做 fuzzy logic。

bruce

两种说法指向同一个定位，只是乐观程度不同。传统分类器的 label space 在训练时就冻结了，分猫和狗就只能分猫和狗，要改成分飞机和汽车就得重训。 Jev 的类别由自然语言在运行时定义，状态、字段名、候选描述一起进模型，所以任务迁移不用重训。

知乎上有一句话说得很完整：Jev 把 Agent 里大量「小型判断 Agent」吸收到了一个模型调用里。 以前一轮流程里七八个判断要调七八次模型，现在是一次请求、七八个字段。

max 的后半句才是重点：定位成立不等于落地顺利。它在概念上解决了一个真实摩擦，落地还要面对准确率、网络、重试、可观测性这些具体问题。这两件事不冲突。

3.2 大号 BERT，和没人卷的赛道

这个赛道还没人卷，大号的 bert。

max

一半对。接口形态上确实像：共享编码主干加多任务输出头。BERT 那篇论文的摘要写的就是「双向编码器加一个输出层即可适配多种任务」， 这个结构描述和 Jev 对外表现出的行为高度一致。

「没人卷」不成立。零样本分类这条线一直在做，Reddit 上有人直接点名 GLiClass 这类开源项目，说 2020 到 2026 年一直有做同样事情的开源实现，只是没人给它起个新名字。 开放词汇检测（prompt-ovd）也是相邻的工作，用 CLIP 类别嵌入提示 Transformer 解码器，在 OV-COCO 和 OV-LVIS 上比 OV-DETR 快 21.2 倍。

真正可能的差距不在方法，在数据量和工程化程度。群里 shiqi 的判断是目前证据最能支持的版本：

速度上的差距，我感觉也不会是 Jev 有什么独特的优化，他的主体框架大概率还是 transformer，甚至可能就是基于开源 LLM 后训练的。只要模型够小速度就够快，效果靠大量数据的后训练来提升。

shiqi

官方文档里说 Jev「不是小模型」，也没说是不是 transformer。所以这仍是推测，只不过是目前信息量最高的那个推测。

3.3 谁有资格做安全护栏

和他的名字 Jev 的含义一样，就是个悖论。现在 SOTA 模型比 Jev 聪明得多。如果 SOTA 模型做不到安全护栏和意图识别，Jev 就更不行了，只会让工作流出更多错。

max

大模型网关就是这个要求。不是要求不高。你没见过什么是智能路由吧。

bruce

这一场最激烈，也最容易被混成一团。里面其实是两个不同的命题。

命题一说 Jev 比 SOTA 聪明，没有人这么主张，官方也没这么主张。官方的说法是「System One 类任务上同级智能」，而且补了限定： 理想搭配需要一个 System Two 模型先做战略判断、生成策略，再作为输入喂进来。

命题二说 SOTA 做不好的判断，Jev 也做不好。这一条不成立。判断质量取决于训练数据和任务边界，跟通用智能水平是两回事。 一个在几百万条工单上做过概率校准的中等规模模型，在「这封邮件要不要升级处理」这件事上，完全可能比一个从没针对这个任务校准过的前沿模型更稳。 LangChain 的实验给了一个具体例证：在二元的 does_pass 判定上，Jev 在 500 次重复里和人工标注完全一致，而 Claude Sonnet 4.6 是 80.0%。

bruce 的乐观也有边界，因为路由任务对错误的容忍度差别极大。「该发给财务还是客服」判错，成本是一次转单；「这条 shell 命令是不是 rm -rf /」判错，成本是数据没了。 bruce 提的堡垒机实时命令判断是真实场景，也正因为后果不可逆，这个位置要的是模型概率加上一道代码规则和一道人工确认，少任何一层都不够。

这一场可用的结论是分层：低后果、高频、答案空间封闭的判断可以下沉给 Jev；高后果、不可逆的判断，模型输出只能当输入信号，最终否决权留在代码和人工手上。

3.4 速度优势会被吃掉吗

准不准是一回事，能不能省 token 也是个问题，网络波动也是个问题，当多个问题一叠加，他最大优势「速度」就没了。

max

这句话里有三条批评，成立程度很不一样，得拆开看。

「多个问题一叠加就没速度」这一条不成立，而且正好说反了。Jev 的设计就是冲着这个问题去的：每个问题对同一份 state 独立求值，加第 14 个问题几乎不增加响应时间。 它和「连调 14 次 LLM」是完全不同的成本曲线，Langfuse 那篇实测里也写了这一点：再加一道问题，只是多付问题本身的 token。

网络和重试是真的。70 毫秒是服务端算力给出的数，实际端到端要加上海底光缆、TLS 握手、排队和重试。有知乎答主给出的实测口径是 200 毫秒打底。

还有一条群里没说但同样真实：如果判断结果要落库留痕、要参与级联判断，整条链路延迟是这些环节之和，单点快的边际收益会被摊薄。 真正吃到红利的是高并发批处理，比如给上百万条日志打风险分、把一大批广告素材做结构化分档；不是每天几百次的低频单请求链路。 新浪科技那篇报道里有个具体的例子：一位开发者用 Jev 分析 37 个品牌的 724 条实时广告，产生 8724 次判断，大约 40 秒跑完，token 成本约 9 美分。 这种形状的负载才是它的主场。

3.5 搜广推会不会翻天覆地

要是做搜广推策略的话，其实一直都是在做分类器。关键是 100ms 的速度，放在实际业务里，如果分类效果足够好，那么现在 bert、fm、多头这些东西可能真的翻天覆地了。

一蓑烟雨

这个判断的动机成立，代价被低估了。搜广推的主体不是语义判断，是稠密 ID 特征的预估：用户历史、物料统计、实时反馈、预算约束。 这类任务上 FM、双塔、多任务塔的优势是 label 稳定、特征密集、可回放、成本可控，Jev 不解决其中任何一条。

更现实的组合是分工。确定性特征工程和 CTR 预估继续负责主排序，Jev 负责开放语义、少样本、规则难穷举的门控层： 内容是否合规、query 与商品是否相关、新类目冷启动怎么分级、流量进哪条实验策略。前者要的是可解释、可回放、稳定收益，后者要的是能泛化到长尾。

群里 Meteora 的说法方向一致，但落点不同：

开源复现效果还是差一些；大模型虽然也能做，但速度上还是有差距。比较认同一蓑烟雨的看法，对现有深度学习分类器的冲击应该是最大的。

Meteora

冲击力最大这一点我同意，但有一处不能被忽略：稠密 ID 场景的验收标准里，可解释性是最硬的一条。Jev 不解释，这条恰好是它的短板。 反过来，它擅长的开放语义和冷启动，又正是传统预估模型最弱的地方。两者接的位置不同。

3.6 多标签能一次前向吗

群里阿郑问了一句：多标签问题它也能一次 forward 搞定吗。

不能直接用 Choice。Choice 是互斥选择，概率会被归一化，天然只允许一个赢家，这会丢掉「促销、高客单、需人工审核」同时成立的语义。 正确做法是拆成多个独立的 Noul，或者显式训练一个多热输出头。官方文档的建议方向也是这个：把问题拆到原子级，再在代码里组合系数。

这条在工程上很容易被写错，因为多标签和单选在接口上长得很像。拆成多个 Noul 之后还有一个附带好处：每个标签的概率可以独立设阈值，不会被其他标签的概率挤占。

3.7 四个被混用的名词

群里出现过几个名词，指向的方案差别很大，混着用会让结论完全不同。这里逐个说清。

3.8 三个绕不开的技术命题

把七场争论压一下，剩下的其实是三个问题。每个问题的现有证据强度不一样，我一并标出来。

shiqi 和 Meteora 说的这两条也解释了为什么 Nimble 的对比训练能生效：一致率从基座 66.36% 提到 90.12%，靠的是构造只差一处事实的成对样本，逼模型抓住真正影响判断的那个信息，而不是加大推理步数。这条路子和「让模型多想一会儿」是不同的解法。

数字、口径与用法

围绕 Jev 的数字很多，来源口径差别很大，横向比较时容易出错。下面按出处分开列，同时标出每组数字能支持什么、不能支持什么。

4.1 六组数字，六种口径

有一个反例要单独记一笔，它说明 Jev 不是所有场景都划算。Reddit 上有人说，在复用输入指令的场景里，由于输入缓存计价，Luna 这类模型在某些任务上比 Jev 更便宜。 Jev 的输入单价 $0.042 / MTok 很低，但它每次都要完整编码一遍 state，如果同一份长上下文要反复用几十次，缓存带来的折扣可能反超。选型时得自己实测一遍，别照搬总账。

4.2 四条路线怎么选

这张表不是替代关系，是按任务分位置。有个很实际的判断标准：如果这个任务的标签空间在调用之前就能枚举出来，而它又高频，就不该用 LLM。 真正被浪费的不是那几次 token，是每次都走一遍「生成整段再解析出三个字段」的流程，以及每次解析失败都要重试的那部分。

4.3 落地清单

结语

Jev 引起讨论的地方不是它的智能，是它的接口。把判断从生成里拆出来这件事本身成立，而且卡住的是 Agent 工程里最好数的那部分摩擦： 一轮流程七八个枚举值，以前要付七次完整生成的账，还要为每次解析失败准备重试。

官方架构没有公开，所以它到底是新的模型族，还是训练得足够好的大号分类器，目前只有厂商叙事和第三方复现两种证据，两者互相替代不了。 能确定的是它该待的位置：高容量、低延迟、动作集封闭的路由、分类、评分、核验。它站在超大模型前面当一层概率控制面，不站在代码和人的位置上做最终决定。

至于它会不会成为 Agent 的新技术路线，群里没吵出统一答案，我也给不了。但群里有一句我认为是对的，我把它引在这里：

单次快决策的价值永远是简单问题。复杂度也不是随便压掉的，压掉都是有代价的。

归鸿

一个模型放弃说话换来速度，这件事不神秘。真正要算清楚的是它压掉的那部分复杂度，是不是恰好压在了你不需要的地方。

参考资料