前OpenAI研究员Diogo Almeida结束两年隐身，发布新模型Jev。他曾是InstructGPT论文共同作者，参与过早期RLHF与GPT-4相关工作。如今他给出的答案很直接：也许AI根本不需要这么爱说话。
Jev来自Type Safe，是首款System One Model，直接放弃自由文本生成。官方数字很夸张——速率提升20-200倍，开销最高降至原来的1/400，输出Token免费。
一封邮件，两条路径
假设你收到一封用户邮件，想知道三件事：是否投诉？问题紧不紧急？该转给哪个部门？
普通Transformer会先阅读，再一个Token一个Token地写出回答：“根据用户的描述，这封邮件属于……”程序还得从这段文字里重新提取信息，解析成字段，再决定下一步。
Jev省掉了中间这段话。你提前规定好程序需要哪些结果，它读取输入后直接给出类型确定的结构化判断，以及每个判断对应的概率和置信度。
Type Safe的概括是：非结构化状态进去，带类型的概率决策出来。
更关键的是，这些结果可以并行产生。老牌LLM采用自回归生成，每个Token依赖前一个Token；Jev的目标里没有一整段文章、代码或解释，自然不需要慢慢“写”完答案。
用并行计算替换顺序计算，官方称Jev端到端响应时间约70-500毫秒，输入价格每百万Token 0.042美元，输出当下免费。
在公司自己的workflow eval中，最高测出193.6倍速率优势和444.6倍开销优势。这组数字需要加限定条件：可能已接近现实业务流回报的高位，且验证workflow来自内部团队，Type Safe自己也承认。
外部实测看起来也不错。Every的评测负责人Mike Taylor拿Jev检查了37篇文档，一口气做完777次独立判断，总耗时不到0.7秒。
其中一个写作品质判断任务中，Jev用时约0.35秒，Fable 5.1需要8.83秒；前者约快25倍，开销约低580倍。至少在这类高度结构化的判断题上，它展现了惊人的效能曲线。
做RLHF的人，开始反思RLHF
Jev背后的调参方式更有意思。Type Safe给它起了一个新名字：RLCD，Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习。
这个名字本身就是在回应RLHF。RLHF的核心逻辑是：让人类评价多个答案，然后调参模型生成更受人喜欢的结果。这条路线让原本只会预测下一个Token的语言模型逐步学会遵循指令或解释问题，最终变成聊天助手。InstructGPT当年用的正是这套思路。
Almeida现在觉得，当模型要进入软件系统时，“人的偏好”未必是最重要的调参目标。
一个聊天助手面对不确定的问题，可以写几段听起来很完整的回答。但如果它处在一个每天自动执行数百万次的业务流里，真正重要的问题或许只有两个：答案是什么？这个答案到底有多确定？
RLCD因此把校准放到核心位置。简单来说，如果一个模型长期对一类判断给出90%的置信度，那么这些判断最好真的有大约90%是对的。这样，软件才能围绕概率继续写逻辑：
95%以上，直接执行；70%，交给更强的模型继续判断；40%，送给人类。
AI由此更像一个能插进程序里的模糊if语句。这也是Type Safe所说的composable intelligence：智能不必每次都以一整段自然语言出现，它可以变成软件内部随时调用的一项能力。
不说话，就没有幻觉了？
Type Safe甚至有一个更激进的宣传：Jev不会幻觉。
此幻觉非彼幻觉。我们一般说Transformer带来幻觉，想到的是它一本正经地编出一个不存在的人名、论文或事实。Type Safe这里强调的其实是另一类问题：模型产出了程序根本没有定义、也无法处理的输出。
比如让AI判断一封邮件属于投诉、退款还是咨询。它仍然是在生成字符串，理论上可以突然回答一个选项中并不存在的“严重投诉”——普通Transformer即便被要求按固定格式回答，也可能出现这种情况。
对人来说，这或许只是增加阅读量和理解难度；但进入自动化系统后，下游程序根本不知道该怎么处理这个凭空出现的新类别。
Jev从源头上砍掉了这种可能。它不自由生成字符串，所有可能的输出及其类型都提前定义好了。如果程序只允许投诉、退款、咨询三个答案，它就只能从这三个答案中挑选，不会临时创造第四个。这就是Type Safe所说的type safety。
官方甚至明确注明，Jev的0% hallucination并非跑了海量验证后统计得到的经验数据，而是直接把这一数字记为0%！因为schema matching本身就是被确保的。
玩笑归玩笑，如果把幻觉换回我们更熟悉的定义，Jev和这个问题也并非毫无关联。
Transformer为什么会一本正经地胡说？一个很重要的原因是，语言模型最初学习的任务就是预测下一个词。训练数据里的每句话，并不会额外附上一张真/假标签。对于海量低频、模糊或模型本身并不知道的信息，它仍然可以根据语言规律生成一个很像正确答案的答案。
更麻烦的是，后续的调参和评测通常还会奖励猜一个答案。OpenAI去年专门研究过这个问题：如果一道题答错和回答“不知道”都拿不到分，那么猜一个细化答案至少还有蒙对的概率。久而久之，模型更容易学会在不确定时继续回答，而不是将自己的不确定性暴露出来。
也就是说，我们平常所说的幻觉，危险的不只是一个错字。模型明明并不确定，但最终输出了一句看起来相当确定的话。
普通LLM内部当然也存在概率分布，但用户或下游程序最终拿到的，一般已经是一段生成好的自然语言。无论模型原本只有51%的把握，还是有99%的把握，最后都可能变成同样一句：答案是A。
Jev想保留其中的不确定。它不只输出一个最终选择，反而强调typed probabilistic decisions：把结构化答案连同概率一起交给程序。
RLCD调优的也正是这种calibrated decisions——让模型给出的概率尽可能真实映射自己的把握级别。Type Safe将其描述为epistemically honest probabilities。
同样面对投诉/退款/咨询三个选项，程序拿到的可以不只是“投诉”，反而类似于：投诉92%、退款5%、咨询3%。
自动化系统就不必硬着头皮继续执行，可以把任务升级给更强的模型——如果最高概率只有45%的话。
这不会让Jev神奇地不再犯错，但至少会让系统知道什么时候更可能犯错。
这也是校准对自动化特别重要的地方。前面的type safety确保答案不会超出程序的处理边界，这里的calibration则进一步告诉程序：这个答案到底有多值得相信。
一个解决程序能不能处理，一个解决程序要不要执行。
从这个角度看，Jev确实也带来了一条压低广义幻觉风险的想法：不要逼模型在每一次不确定时都交出一个斩钉截铁的最终答案，反而把不确定性本身也当作输出的一部分，让系统能够选择执行、升级或者放弃。
不过，校准仍旧不等同于没有幻觉。OpenAI有关幻觉的研究特意提醒过这一点：一个模型完全可能每次都答错，但每次都诚实地告诉你“我只有0%把握”——它的概率可以十分校准，答案照样全错。所以，calibration并不是幻觉率本身的衡量指标。
这也引发了一些质疑：Jev表现真有这么好？
一个JSON分类器，值1200万浏览？
Jev的爆火引发了一些吐槽。帖子发出来没多久，Hugging Face研究员Niels Rogge就评论：一个JSON分类器竟然有1200万次浏览？是啊，我们正处于泡沫中。
说得也不是完全没道理。扒开System One Model、RLCD、0% hallucination这些新名词，Jev实际上做的很多事情大家都挺熟悉。分类、打分、路由、结构化输出，本来就是Transformer业务流里最常见的一批任务。
甚至发布不到一天，就有人用Qwen 2.5-1B做出了一个相似实现。工程师Harsha Gundala的说法相当挑衅：他们隐身开发了两年，我隐身开发了两个小时……
这个开源实现同样可以让JSON中的多个字段并行完成判断，并直接从预设候选中计算概率。作者甚至强调，不需要任何新的调参。
这也是Jev最先脱掉的一层马甲：并行做结构化选择，并不一定需要一个全新的模型。
而宣传中的零幻觉也颇有玩文字游戏的意味。最后只剩下Type Safe始终在强调的校准（Calibrated），这也是最难验证的地方。
普通模型当然也能从logits中得到概率，而当模型说自己有80%把握时，我们希望它真的有80%的概率判断正确。Type Safe觉得RLCD解决的正是这件事。
但截至当下，RLCD的具体调参方式、reward function，以及更系统的概率校准指标都还没有完整公开。
当下圈子对Jev的质疑就集中在这几个方面：并行结构化输出本身并没有开创性，0% hallucination偷换了hallucination的定义，而RLCD的calibration还没有公开证据。
不过这些质疑没有真正动摇Jev所指向的问题。恰恰相反，它们甚至从另一个路径印证了这条路线的意义。
如果一个工程师真的能花两个小时，在一个1B小模型上做出类似的结构化并行判断，那首先说明的未必是Jev没有技术含量。它同时意味着：这类能力可能根本不需要一个昂贵、复杂、无所不能的Transformer才能实现。
这正是Jev一开始想探讨的问题。我们早已习惯了把越来越多任务交给通用Transformer，但对有的任务来说，过去几年。
不追求回答所有问题，甚至主动放弃了聊天、写作和自由生成，Jev恰恰是把这些最普通、数量最大、也最容易被忽略的判断单独拿出来。
AI产品最常见的出场方式是刷新benchmark：更强的推理、更高的得分、更长的上下文，用一张张榜单证明能力上限。
Jev走的是另一条路。它把模型能力压到一个刚好够用的级别：判断但不产出一大段解释，一个小模型能做完的任务，它甚至很难用更强来形容。
这种产品更像是在贴地飞行。它不追求展示AI能做到多惊人的事情，反而紧贴真实业务流里那些数量庞大、重复出现、又对延迟和开销敏感的问题，把等待时间和token都省下来。
所以一个看起来并不炫目的JSON分类器，最后反而能取得2400万浏览。
证明一个模型足够强，当然是一种吸引人的方法；证明一个模型解决了人们每天都会遇到的问题而且能力恰好够用，可能是另一种。
将来，随着模型能力越来越强，产品不止需要展示能力上限，也许还需要关心另一个问题：面对各类任务，怎么给用户提供一个最简单、最直接、最不绕弯子的处理办法。
工程视角：什么时候该用Jev这类模型
如果你在运维或测试岗，日常最烦的往往不是模型不够聪明，而是它太爱说话。
日志分类、告警路由、工单打标、异常摘要——这些任务本质上是结构化判断，不是聊天。用通用LLM跑，你得到一段自然语言，还得写正则或再调一次模型来解析，延迟和成本都上去了。
Jev这类模型的价值就在这里：输入非结构化状态，输出带类型的概率决策。
但有几个坑得提前说清楚。
第一，schema必须提前定义好。Jev不会临时创造新类别，这既是优点也是限制。如果你的业务分类体系还在频繁变动，每次加字段都要重新定义schema，灵活性不如自由文本模型。
第二，校准需要验证。模型说90%置信度，不代表真的90%正确。上线前至少要做一轮校准测试：把历史数据跑一遍，按置信度分桶，看每个桶的实际准确率是否接近声称的概率。
第三，不要在生产环境直接信任单次输出。建议设置阈值：高置信度直接执行，中等置信度交给更强模型复核，低置信度转人工。这套逻辑本身就是Jev设计的用法。
第四，注意输入分布漂移。Jev在训练分布内表现稳定，但如果线上输入和训练数据差异变大，概率校准会失效。定期用新数据做校准检查，比盯着准确率更有意义。
测试验证怎么做
如果你要评估Jev或类似结构化输出模型，别只看准确率。
先构造一个带标签的测试集，覆盖所有预定义类别，包括边界样本。然后跑批量推理，记录每个样本的输出概率和最终选择。
关键指标有三个：
分类准确率——最终选择对不对。
校准误差——预测概率和实际正确率之间的偏差。
拒识率——模型在低置信度时是否真的会“犹豫”。
判定标准可以这样定：如果模型在90%置信度桶里的实际准确率在85%-95%之间，校准基本可用；如果偏离超过10个百分点，说明校准有问题，需要重新调参或换模型。
另外，并行结构化输出的延迟优势在批量场景下最明显。单条请求可能看不出20-200倍差距，但当你一次要处理几千条日志或工单时，差距会非常直观。
实测这样更稳：先用小批量验证schema和阈值，再逐步放大流量。不要一上来就全量切换。
这条路线的边界
Jev不适合什么场景？
需要生成解释、摘要、对话的任务，它做不了。需要开放式推理、多步规划的任务，它也不擅长。它的定位很窄：结构化判断。
但恰恰是这个窄定位，覆盖了自动化系统里数量最大的一批任务。
过去几年，我们习惯用通用模型解决所有问题，代价是延迟、成本和不确定性。Jev提醒了一件事：有些任务，模型不需要更强，只需要更准、更快、更便宜。
这不是替代通用LLM，而是补上它不擅长的那一块。
至于RLCD的校准效果到底如何，等Type Safe公开更多细节再说。在那之前，保持怀疑，但别忽略它指向的问题。
