Jev 拒绝写出哪怕一个字：TypeSafe AI 的决策模型有何作用，以及迄今无人验证的部分

Jev 是 TypeSafe AI 的首款模型，读者很可能是在一张成本表而非聊天框里第一次遇见它，因为它根本没有聊天框。Jev 由 Diogo Almeida 于 2026 年 9 月 15 日推出——他是 InstructGPT 论文的合著者之一，而那篇论文正是让 ChatGPT 表现得像个助手的工作——它完全不生成文本。它接收一段状态（一封电子邮件、一行日志、一张支持工单、一个包含游戏坐标的 JSON 数据块）以及一组带类型的问题，并返回带类型的答案：从你提供的选项集合中做出选择、按评分标准给出的分数，或是是/否概率，每个答案都带有自己的置信度值。没有自然语言表述，没有代码，没有解释。TypeSafe 的宣传主张是，这种狭窄性本身就是产品，因为它换来了生成式模型无法匹敌的速度和价格——在公司自己的发布材料中，它比“可比的 LLM”快 20 到 200 倍、便宜 40 到 400 倍，价格为每百万输入 token 0.042 美元，输出计费为零。

头48小时内公布的最有用的那个数字，并不属于上述任何一个。它来自 Every：该公司的评测负责人让 Jev 处理了27篇已发表的 Every 文章，外加10篇AI风格的对照文章，一次性向全部37份文档提出21个问题：不到0.7秒完成777次判断，成本约四分之一美分。第二项测试由 Every 的CEO操刀，用12段合成文本——六段干净，六段故意植入缺陷——接受四项写作检查。Jev 的结果是每段中位耗时0.35秒，而 Claude Fable 5.1 在高强度模式下为8.83秒：速度约快25倍，成本约为其1/580。它抓出了七个植入缺陷中的六个。Claude Fable 5.1 七个全中。Every 的结论是“不错，但不完美”，而这正是对 Jev 最诚实的一句话概括——出自迄今任何人发表的唯一一项独立测试：速度与成本方面的说法经受住了第三方检验，准确率方面的说法则比前沿水平低一档，而样本量之小，意味着谁都不该据此得出可用于生产的结论。

关于这篇内容所依据的证据类型，有必要说明一下，因为对于如此新的模型来说，各层级之间的差距异常之大。Jev 是真实且可调用的：有已记录的端点、Python SDK、模型别名和已公布的价格。这次发布由厂商宣布，并非泄露，也没有人猜测它是否存在。但 TypeSafe 主打的每一项性能声明都来自 TypeSafe 自己，架构未公开，权重也未发布，而支撑 20-200x 这一标题的基准测试仪表盘是一组内部工作流评估，而非公开排行榜。已有一家外部机构对其进行了测试。本文将有厂商数据、独立数据和未解问题明确区分开来，而不是把它们平均成一个并不存在的共识。

TypeSafe 实际交付了什么

Jev 是 TypeSafe 所称的 System One 模型中的第一个——这个名字借自丹尼尔·卡尼曼认知中快速、直觉的那一半，与聊天机器人所模仿的较慢的审慎模式相对。TypeSafe 所提出的对比，针对的是那种标准做法：强迫文本生成器输出结构化内容，然后再把该文本解析回代码可以信任的东西。Jev 完全跳过了文本。TypeSafe 自己的文档直言不讳地指出：“大语言模型（LLM）旨在生成供人类阅读的文本。当你需要模型做出一个你的代码将要消费的判断时，这就会造成不匹配。”

输出面就是三个原语，除此之外别无他物。你提出的每个问题都必须是其中之一：

• 选择 — 从你提供的列表中挑选一个选项，返回所选选项，以及每个候选的概率和一个置信度。每个字段的选项上限为 255；超过此上限时，TypeSafe 记录了一种两阶段模式：先独立为各候选评分，然后再进行选择。

• 评分——将状态置于有序评分标准中，返回等级、每个等级的概率以及置信度。文档中的示例是0-1尺度上的流失风险。

• Noul —— 由“no”和“null”拼合而成的合成词 —— 一个单一的“是/否”断言，返回其为真的校准概率。

真正有趣的地方不在于任何一个原语，而在于它们如何组合。三者都可以混在单个 API 调用中，而且每个问题都会基于对同一状态的一次共享读取并行求值。TypeSafe 的文档称，添加问题“几乎不会改变响应时间”，独立测试也在实践中证实了这一点——横跨 37 份文档的 21 个问题都落在同样的 0.7 秒内。这正是每次判断成本骤降的原因：你不是在为更长的生成付费，而是在为一次处理付费。

实际可用范围，正如文档所载以及早期用户所反馈的那样：请求预算约为 32,000 个 token，TypeSafe 的文档中描述为约 150,000 个英文字符；发布时不支持图像或音频输入；其请求与响应的格式并非 OpenAI chat-completions 的惯例，因此调用它需要专用客户端，而不是仅替换 base URL。访问方式为早期访问等候名单加一个浏览器演练场，模型别名为 code>jev-latest/code>

RLCD 的意思是已校准，而非首选

TypeSafe 用一种它称为 RLCD——即“校准决策强化学习”（Reinforcement Learning for Calibrated Decisions）——的方法来训练 Jev，依据的是该公司自己的文档。这个缩略语还太新，早期报道对它的展开各不相同，因此有必要明确它究竟命名的是什么，因为这一区分正是整项研究主张的关键所在。

RLHF 针对的是人类偏好的输出进行优化。RLVR 针对的是可验证的正确性进行优化，即那种测试用例能通过的正确性。RLCD 针对的是校准进行优化：一个自称有 70% 置信度的模型，就应该在大约 70% 的情况下是对的。这与“正确”是不同的目标，也正是为什么每个 Jev 的回答都会附带一个概率分布，而不只是一个答案。它所预期的失效模式是：模型知道自己什么时候不知道，这样你的代码就能决定该如何应对。

在实践中，这为你换来的是一个控制面。文档中记录的模式是三个置信区间——在顶部自动执行，在中间标记或确认，在底部转接给人工——而阈值存在于你的代码中，而不是模型中。这些区间是否可靠，是一个关于你自身数据的实证问题，而这正是TypeSafe明确告诉你要自己去回答的问题，并指出置信阈值因用例而异，应针对你自己的标注样本进行测试。这条说明是文档中最重要的一句话，也是下一节存在的原因。

这些数字，按产生它们的人排序

大多数关于 Jev 的报道正是在这一点上变得含糊，因此值得明确说明来源。以下内容中，哪些来自供应商，哪些来自独立测试者，哪些则完全未知。

• 厂商报告、未经复现——那些引人注目的速度与成本宣称。端到端延迟为 70-500 毫秒，而前沿 LLM 调用则为 3-329 秒；快 20-200 倍，便宜 40-400 倍；单个最佳情况工作流结果宣称快 193.6 倍、便宜 444.6 倍。TypeSafe 承认这些是最佳情况数据，而非普遍适用的数字。

• 厂商报告，并可在价目表上核实——每百万输入 token 0.042 美元，即每十亿 42 美元，输出免费。输出免费的原因是机制性的，而非促销性的：没有需要计量的自回归解码，因此没有可计费的输出 token。作为规模参照，同一批发布材料给出的典型前沿模型输入价格为每百万 0.20 至 10 美元，而输出价格通常约为输入价格的五倍。

• 厂商报告，来自一项内部基准测试——TypeSafe 自己的工作流仪表板，涵盖四项任务共 711 个案例，其参考答案取自 GPT-6 Astra 和 Claude Fable 5.1 的平均判断，而非基准真值。在该仪表板上，Jev 的总体得分为 67.8%，而最佳对比对象为 74.1%。细分来看：安全事件 61.7%，对比 Opus 5 的 66.2%；智能体轨迹可观测性 71.6%，对比 76.6%；发票处理 61.8%，对比 79.1%；客户服务 76.0%，对比 78.3%。在该图表中，Jev 在成本和延迟两列胜出，在准确率一列落败。该仪表板本身指出可能存在测试框架偏差，并且 TypeSafe 表示，其有意跳过公开排行榜，转而采用与产品更新挂钩的一次性评估。

• 独立测量、小样本——上文所述的 Every 测试：0.7 秒内完成 777 次判定，成本约四分之一美分；11 个实验中共完成 1,709 次判定，总成本不到一美分；在一项 12 段落的分类任务上，速度约为 Claude Fable 5.1 的 25 倍，成本仅为其 1/580，却漏掉了对照方捕获的七个植入缺陷中的一个。Every 自己的结论是，在将其投入生产环境之前，它希望能进行一次远比这更彻底的准确性检查。

• 未知——架构。发布时没有论文，没有参数数量，没有训练算力披露，没有权重。TypeSafe 表示，这些细节目前“暂不公开”，论文可能会在之后发布。

这些层级所呈现的规律是一致的，而且并不是 200 倍这个标题所暗示的那种规律。所有独立数据和厂商数据都一致表明，Jev 要便宜得多，也快得多。但任何地方的数据，包括 TypeSafe 自己的数据，都没有显示它比同价位对标的前沿模型更准确。在厂商自己的仪表盘上，它大致落在一个优秀中端模型的水平。真正站得住脚的对比不是“用百分之一的价格获得前沿模型般的智能”，而是“以每次调用不到一美分的成本，获得接近中端模型的判断力，而且快到可以在每一个回合都运行。”

“零幻觉”意味着什么，又不意味着什么

TypeSafe 的发布材料中有一张图表，显示 Jev 的工具调用错误率为 0%，而对比模型则具有非零错误率；此外，“抗幻觉”这一说法也随该模型一同传播。两者都属实，但两者的适用范围都比字面看上去更窄。

这种保证是结构性的。每个可能的答案都会在模型运行之前被枚举出来——你提供了选项列表、评分标准或真/假命题——因此不存在任何空间可以输出声明类型之外的值。格式错误的工具调用不是 Jev 能产生的东西。这是一种真正的工程特性，对于任何花了一周时间围绕 JSON 解析失败编写重试逻辑的人来说，它值真金白银。

这并不是在声称它一定正确。一个符合模式的答案仍可能是错的：Jev 可以很自信地把账单投诉转到技术队列，而输出在格式上完全没问题，却毫无用处。Almeida 本人也说过同样的话，承认自信地犯错是可能的。把这两个事实放在一起看的有效方式是：Jev 消除了来自输出格式的那一类错误，而对来自判断的那一类错误则完全无能为力。这意味着准确率问题完全是一个校准问题，而校准恰恰是你必须亲自测量的东西。

如何在您自己的数据上检验校准声明

校准是少数几种只需几百个样本、无需机器学习基础设施就能妥善检查的模型特性之一，而且它是 Jev 接触生产路径之前唯一重要的测试。过程很短。

拿几百个你已经标注好标签的案例。向 Jev 提出那个真正重要的问题——路由决策、风险评分、缺陷检查——然后按它报告的置信度把答案分桶。接着检查 0.9 置信度分桶是否在大约 90% 的情况下是对的，0.7 分桶是否大约 70% 是对的，以此类推。校准良好的模型会画出一条对角线。一个只是自信的模型会把所有结果都聚在 0.9 以上，却只有 70% 的时候是对的，而正是这种形态会悄悄破坏自动化流水线。

同一个测试会告诉你该用哪些阈值。如果 0.9 这个分桶在你的数据上真有 90% 的准确率，你就可以把它自动化。如果你的中间地带是一团糨糊，那就把它转给人工，或者交给生成式模型，让那条昂贵的路径去处理这些模棱两可的情况。这种拆分——把廉价模型用在有把握的大多数上，把昂贵模型用在不确定的剩余部分上——正是 Jev 所主张的实际架构，也正是为什么最好把这个模型理解为一个组件，而不是一种替代方案。

成本是多少，详细算一遍

定价简单到足以推算，这很少见。输入为每百万 token 0.042 美元。输出免费。在文档所述的约 150,000 字符请求预算下，单次最大规模调用的花费远低于一美分。

两个已披露的数字能让人对规模有个概念。一位早期用户跑了大约 5,000 次请求，花费约 2 美元。那场 Doom 演示——Jev 用游戏状态的文字描述而非原始像素来操控一个机器人——以每秒约 10 次调用的速率运行，每小时花费约 7 美元。而 Every 在 37 份文档上做出的 777 次判断，花费约为四分之一美分，正是这个数字让那个有意思的用例变得清晰可辨：在这个价位上，检查智能体循环中的每一轮不再是一项成本决策，而成了默认做法。

这才是支持 Jev 的真正论据。每轮都做一次验证——这次工具调用是否与上一次矛盾、这个输出是否与用户声明的意图一致、这是否应该触发警示——用前沿模型在技术上一向可行，但规模化后在经济上荒谬至极。在每百万 token 收费 0.042 美元且不收取输出费用的情况下，同样的验证流程在每一轮都变得负担得起。这里的价值不在于 Jev 比前沿模型思考得更好，因为它并没有。价值在于它思考得足够便宜、足够快，因而可以被持续咨询。

有必要直说，因为这是显而易见的下一问：OrcaRouter 并不提供 Jev。TypeSafe 的模型处于早期访问阶段，需排队等候，并且使用自己的请求格式，因此任何要测试它的人都得直接通过 TypeSafe。路由层真正适用的地方，是工作流的另一半。Jev 所针对的模式是两个模型，而非一个——Jev 做出带类型的决策，而生成式模型负责需要散文、代码或解释的那部分。OrcaRouter 覆盖的正是那个生成式的一半：15 家供应商的 197 个模型都挂在同一个兼容 OpenAI 的密钥下，按供应商目录价透传，0% 加价，因此厂商降价在发布当天就会落到我们这边。Jev 形态工作流的两半都能在无需第二份合同的情况下测试，而当决策组件尚未经过验证时，故障转移路径正是防止一次糟糕的校准结果演变成生产事故的关键。

Jev 不适合的地方

供应商异常清晰地说明了这些限制，这使得本节很容易如实撰写。Jev 无法生成自由文本。它不能编写代码。它无法进行对话。它没有聊天界面，没有图像输入，上下文预算约为 32,000 个 token——比它在价格上被拿来比较的长上下文模型低一个数量级。选择字段最多 255 个选项。而如上所述，“无幻觉”特性关乎的是输出格式，而非真实性。

总体而言，它只适用于相当狭窄的场景。适合：大批量分类与路由、护栏与验证环节、延迟敏感型决策、并行给大型文档集打分，以及任何正确答案确实是一个选项、一个刻度上的数值或一个布尔值的地方。不适合：任何形式的开放式生成、长上下文推理、多轮对话，或任何正确答案是一句话的任务。如果你的问题无法归结为一个类型化的问题，那么 Jev 并不是解决它更便宜的方式——它根本不是解决它的方式。

对于这种表述框架，还有一条合理的批评值得延续下去。把 Jev 称为前沿模型，是在借用该模型尚未赢得的信誉：它不会写代码、不能聊天，也写不出一个句子，而对比图表以前沿模型作为基线，准确率那一栏却讲述了另一番情况。更站得住脚、也真正有证据支持的说法是，TypeSafe 把结构化决策的速度与成本边界向外推进了一大截。做到这一点已是相当可观的成就。这与打造一个能与 GPT-6 Astra 或 Claude Fable 5.1 匹敌的模型是两回事。

什么会改变这张图？

三件事，大致按它们的重要程度排列。

• 已发表的架构论文或开放权重。关于 Jev 如何实现其速度的一切目前都是黑箱，而所谓并行求值就是其机制的说法——Almeida 所打的类比是，用并行求值取代串行计算，就像 Transformer 取代循环神经网络那样——只是一种断言，而非已被证明的结果。在设计公布之前，速度是事实，而解释则是营销。

• 更大样本的第二次独立评估。Every 的测试是现有最强有力的证据，它们就决定性的准确率问题覆盖了 12 个段落。再在几百个已标注案例上进行一次独立运行，就能判定七个缺陷中漏掉一个究竟是噪声，还是真实的错误率。

• 一项针对真实、杂乱输入的校准审计。迄今为止发布的所有内容都使用的是干净的测试框架。对于一个全部价值主张都建立在可信置信度分数之上的模型而言，悬而未决的问题是：这些分数在真正模糊的案例上——也就是连人工审阅者也会犹豫的那些案例——究竟表现如何。正是这个数字决定了 Jev 是否可以安全地用于自动化，而目前还没有人公布过它。

在那之前，合理的姿态应是具体的，而非笼统的。Jev 是一个真实存在、已发布且异常便宜的模型，在输出可靠性上具有真正的结构性优势，准确率大致处于中游水平，其校准声明看似合理，被其供应商明确建议自行测试，且仅在小型样本上得到独立验证。如果你的工作流中有一步可以归结为一个被问得足够频繁、以至于动用前沿模型会显得浪费的类型化问题，那么这是提出该问题最便宜的方式之一——而它返回的置信度值才是你在信任它之前需要测试的部分，而不是速度。