Jev取消排队：所谓“零幻觉”，究竟消掉了哪一种错误？

9 月 21 日，Jev 取消等待名单并向所有人开放，新账号赠送 5 美元额度，约合 1.19 亿输入 token。讨论也从“它是什么”转向“怎么接进生产”。可在把业务判断交给它之前，还有一个问题得先讲清楚：Jev 所谓的“不会幻觉”，究竟消掉了哪一种错误？
「术语解构」系列·后篇

Jev 全员开放当天，网络上流传的截图显示，部分登录请求返回 400 和 oauth_state_mismatch。从错误类型看，问题发生在鉴权流程附近，不属于 Jev 的模型推理错误。TypeSafe 尚未发布相关事故说明，目前无法确认影响范围和具体责任环节。

这件事倒是提醒了一个容易被忽略的事实——可靠是整条链路的属性。即使模型永远不会输出非法结果，前面的登录、后面的执行、旁边的重试仍然可能出错。模型自己这一环，也没有“零幻觉”三个字听上去那么稳。

放开的速度本身也值得记一笔。TypeSafe 称，Jev 上线后的 36 小时内处理了约 14 万个注册，6 天后取消等待名单，任何人都能直接注册。新账号赠送 5 美元额度，按当前每百万输入 token 0.042 美元计算，大约对应 1.19 亿输入 token。

上一篇介绍 Jev 时，讨论中出现频率最高的是“零幻觉”和“快数百倍”。现在热度还没退，话题已经变成如何把它接进真实系统。

这些标签里，最容易被误解的是“不会幻觉”。它很容易让人联想到一个不会胡说、判断可靠的模型。Jev 真正保证的范围要窄得多：它不会生成预定义类型之外的结果，却仍可能在合法答案里选错。

这一区别决定了它应该放在系统的什么位置，也决定了哪些业务适合交给它。

67.8%不是错误率，却足以说明它并不总是正确

TypeSafe 公布了一套 Workflow Evals，用四个结构化工作流比较 Jev 和多款前沿模型。

公开评测板显示，Jev 的聚合得分约为 67.8%，同一套评测中表现最高的对比模型约为 74.1%。Jev 没有拿到准确率第一，它的优势主要落在成本和速度上。

这两个百分比需要谨慎理解。评测中的参照答案并非来自人工标注的客观真值，而是取 GPT-6 Astra 和 Fable 5.1 在高推理档位下的预测平均值。TypeSafe 先假定工作流和参照标签成立，再比较各模型与参照结果的接近程度。因此，67.8%不能直接翻译成“Jev 答错了 32.2%”。更准确的说法是：

在 TypeSafe 自己设计的 System One 工作流中，Jev 与两个前沿模型所形成的参考共识仍有明显差距。

这足以拆掉一个误区。Jev 的“零幻觉”不等于“零错误”，也不代表它在语义判断上比所有前沿模型更准。

TypeSafe 给出的 193.6 倍速度优势和 444.6 倍成本优势，同样来自特定工作流、模型配置与对比基线。官方也承认，这些结果可能处于真实收益的高端。离开测试条件后，不能把这些倍数直接外推到其他业务。

“零幻觉”究竟消掉了什么

Jev 不生成自由文本。开发者需要提前定义问题类型和允许的答案，模型只能在这些答案中返回结果。举个例子，假设一张客服工单只能分给四个部门：

1
2
3
4
billing
shipping
returns
other

Jev 不可能突然返回第五个不存在的部门，也不会输出一段无法解析的 JSON，更不会在结果里夹带解释、Markdown 或未定义字段。

当工具名称和参数被预先定义成封闭的 Choice 选项时，Jev 也不会返回选项之外的工具名或类型。

这类错误可以叫结构性幻觉：

枚举值超出允许范围；
字段缺失或类型错误；
JSON 无法解析；
返回未定义的工具名称或参数类型；
模型偏离任务，开始生成无关文字。

Jev 通过封闭输出空间消掉了这类问题。官方所说的“类型错误在数学上不可能发生”，指的就是这一层。

另一类错误仍然存在：

把本该交给 billing 的工单判成 returns；
在证据不足时把概率压到某个错误选项上；
因问题边界模糊而错误分类；
被输入中的诱导文字影响；
换一种看似等价的问法，返回不满足预期关系的概率。

可以把边界概括成一句话：

Jev 是 schema-safe，不是 truth-safe；是 type-safe，不是 decision-safe。

类型合法解决了软件能不能读取结果的问题。语义是否正确，决定软件该不该相信它。后者仍需要评测、阈值、代码校验和人工复核。

真正该盯的是置信度，这里连着三个坑

Jev 不会给出非法答案，却完全可能给出错误答案。模型返回的不确定性，是识别风险的一个重要信号。

每个 Choice 和 Score 都会返回一个 0 到 1 的 confidence。官方建议，高置信度结果可以进入自动处理，低置信度结果则升级给人工或其他系统。

听上去很简单，让代码只接受模型有把握的结果，似乎就能把错误挡在门外。但这个信号很容易被误读。

坑一：confidence不是probabilities之外的第二意见

Choice 和 Score 会返回一组 probabilities，外加一个 confidence。

很多人会把 confidence 理解成模型在概率之外给出的额外自评，像是更高一层的把握。官方文档给出的定义并非如此。它是从概率分布直接计算出来的统计量，分布越集中，数值通常越高；概率越分散，数值越低。

Noul 没有单独的 confidence，它返回的数值本身就是命题为真的概率。假设同一张工单返回：

1
2
3
returns:  0.61
billing:  0.35
shipping: 0.04

模型选择 returns，因为它的概率最高。但 billing 仍占 0.35，这不是一次毫无悬念的判断，confidence也会偏低。

confidence 不会增加 probabilities 之外的信息，它只是把概率分布的集中程度压缩成一个数，方便代码设阈值。如果业务需要区分“两强相争”和“多个选项平均分散”，只保存 confidence 不够，完整概率分布也要留下来。

文档页面展示过一个三选项的近似公式，但那只是演示，不能据此推断真实接口只读取最高概率和选项数量。TypeSafe 没有公开生产接口的完整 confidence 计算方法。

坑二：校准不等于这一条是对的

Jev 的训练目标叫 RLCD，全称是 Reinforcement Learning for Calibrated Decisions，重点优化概率校准。

校准讨论的是一批预测的长期表现。模型给某类结果 0.8 的概率，理想情况下，这批结果长期约有 80%成立；给出 0.2 的那批结果，约有 20%成立。需要注意一下，主语是“这批”，不是“这条”。

眼前这个标着 0.8 的答案仍可能出错。校准可以帮助开发者估算长期风险、设置阈值和安排人工复核，却不能证明某一个结果正确。

还需要注意，官方的校准主张主要针对模型输出的概率。Choice 和 Score 中的 confidence 只是概率分布的汇总指标，不能自动解释成“这条答案正确的概率”。

想知道某个 confidence 阈值在真实业务里对应多高的准确率，必须拿自己的标注数据验证。在自己的生产环境中至少应该记录：

每个问题的完整概率分布；
实际调用的模型版本；
自动放行、人工复核和拒绝的结果；
不同概率区间的真实正确率；
各类任务的误报和漏报；
模型升级前后的概率漂移。

这些数据才能回答一个实际问题——Jev 在你的业务里，是否真的知道自己什么时候没有把握。

坑三：高confidence也不等于事实正确

confidence 描述的是模型输出有多集中，无法单独判断外部世界是否与模型结论一致。下面几种情况下，Jev 完全可能高置信地给出错误答案：

问题定义偏离了真正的业务目标；
选项之间边界重叠；
输入缺少关键证据；
线上数据与测试数据差异很大；
state 中混入提示注入或诱导文字；
模型升级后，原来的阈值不再适用。

高置信和错误结论并不矛盾。confidence 无法单独识别问题定义错误、输入污染或数据分布变化。它适合拦住模型自己也在犹豫的情况，却拦不住模型被带偏后仍然很确定的情况。后者需要在其他环节补上：

输入进入模型前，先过滤无关或不可信内容；
在 criteria 中写清选项边界和反例；
把数学、日期、权限和状态检查留给代码；
高风险操作继续要求人工确认；
定期抽查高置信度的自动放行结果。

最后一条很容易被忽略。只复核低置信度案例，只能发现模型犹豫时的错误；持续抽查高置信度结果，才能发现模型很确定却答错、数据分布已经变化或者阈值已经失效。

不要给整个系统只设一个阈值

下面这种写法看起来简单，实际风险很高：

1
2
if confidence > 0.8:
    execute()

同一个 0.8，放在不同动作上，风险完全不同。

判断用户想打开哪个页面，选错通常可以恢复；决定是否拦截一封邮件，误判会影响正常沟通；批准转账、退款或者删除数据，后果更重。TypeSafe官方文档给出的思路是同时看判断结果和置信度，再按后果分档：

低风险、可逆的操作，可以在相对较低的阈值下自动执行；
中等风险操作，需要用户确认、补充信息或进入复核队列；
高风险、不可逆的操作，即使置信度很高，也要经过确定性校验或人工确认；
置信度过低时不执行，转给人工或更强的推理模型。

阈值没有通用答案。0.8、0.9、0.95 都只是起点，最终数值取决于误报和漏报分别会造成多大损失。拿自己的数据测过，才能知道哪个阈值可用——说到底还是那句，标称不等于实测。

官方列出的“毛边”比营销词更值得读

TypeSafe 专门维护了一页 Jev 1.13 jaggedness，列出当前版本已经知道的薄弱点。这份文档比“零幻觉”更接近生产说明书。

同一个命题，换一种问题类型，数值不能照搬

官方用一张客服工单演示“用户是否在请求退款”。

使用 Noul 提问，结果是 0.22；换成 yes/no Choice 后，yes的概率只有 0.01。两种表达看起来在问同一件事，输出数值却不能直接比较。

在 Noul 上调好的阈值，不能原样搬到 Choice。

一个命题和它的否定，概率不一定相加等于1

另一组官方示例中：

1
2
是否在请求退款：0.72
是否在请求退款以外的东西：0.47

两者相加得到 1.19。这是两个分别执行的语义判断，模型没有承诺它们处在同一个联合概率空间里，也不保证两者满足互补关系。需要满足算术恒等式时，只问一次，再由代码计算补集。不要分别向模型提问，然后期待它自己维持数学一致性。

它很按字面办事

Jev 回答的是开发者实际写出来的问题，不会自动补全隐藏在脑子里的条件。范围词、否定词、隐含前提和多层间接关系都会影响结果。

每次看到错误答案后，如果都需要补充解释“我真正想问的是……”，这部分解释就应该写进 instructions 或 criteria。

数学、计数和日期留给代码

官方明确承认 Jev 不擅长：

统计字符、词语或列表项数量；
精确数学计算；
比较日期先后和时间跨度；
从 Score 插值反推出精确数值。

Jev 可以帮助判断文本提到了哪个月份，或者一句话是否表达了紧急程度。具体日期计算、金额比较和数量统计仍应由代码完成。

state默认不是可信区域

Jev 不会自动把 state 中的文字当成潜在攻击内容。恶意指令、诱导性表述和为自己辩护的文本，都可能改变判断结果。

Jev 被用来检查用户输入、网页内容、邮件或 Agent 轨迹时，需要把提示注入当成真实风险，不能只依赖模型自己的置信度。

LangChain的第三方测试说明了什么

除厂商自评外，LangChain 测试过 Jev 能否充当 Agent 评判器。

测试集由 5 条固定的天气 Agent 轨迹组成，每条轨迹重复评判 100 次。Jev 在二元 does_pass 判断上，500 次结果都与一名人工评审给出的标签一致；连续质量评分的方差也比三款对比模型低 92 至 913 倍。平均一次调用约 0.44 秒，成本约 0.00035 美元。

这个结果说明，Jev 在范围明确、答案封闭的评判任务中，确实表现出较低成本和较强重复性。质检、路由、分类和 Agent 运行复核，很可能是它最早站稳的位置。

实验的范围也很窄。500 次判断来自 5 个独立案例的重复运行，不能当成 500 个不同业务样本。人工 oracle 只有一名评审，测试也没有覆盖中文、长上下文、复杂行业规则和对抗输入。

它证明了 Jev 值得测试，不足以证明 Jev 在通用判断任务上拥有 100%准确率。

它会成为新品类，还是被大模型吸收

TypeSafe 创始人在 TechCrunch 采访中称，Jev 采用 Transformer 架构，只使用合成数据训练，并通过 RLCD 学习校准决策。公开资料尚未披露完整架构、参数规模、训练数据配方和权重。

目前可以确认的是产品形态：

输入自然语言或结构化文本；
输出封闭答案空间上的概率；
多个问题并行判断；
不生成自由文本；
代码负责组合结果和执行动作。

这种能力是否必须依赖一个独立的模型类别，目前还没有定论。现有大模型配合约束解码、结构化输出和概率校准，也能覆盖一部分相似任务。如果前沿模型以后原生提供低成本的校准决策模式，Jev 的一部分能力可能成为通用模型的标准功能。

Jev 能否长期站住，取决于它的效率优势是否稳定存在，以及它能否在有人工真值、跨行业、跨语言的第三方测试中保持优势。

哪些任务适合先交给Jev

任务类型	适合先交给 Jev	不适合一开始交给 Jev
路由与分流	工单和消息路由、是否转人工的预判断	需要多步推理的复杂政策判断
检索与匹配	RAG 文档相关性判断、候选实体匹配	答案空间无法提前定义的开放问题
质检与安全	Agent 轨迹质检、内容安全初筛、LLM 输入输出检查	必须给出证据和解释的审计任务
特征处理	语义特征提取	需要精确计数、金额或日期的数值特征
高风险决策	可作为辅助判断或风险信号	付款、退款和审批的最终决定
输入模态	文本及结构化文本	图片、音频和视频的直接理解

中文场景还要再加一道限制。这一点在Jev的官方TypeSafe 模型页中明确做了说明，Jev 的主要训练语言是英语，包括中文在内的 CJK 文字可以处理，但表现并不等同。中文业务上线前，需要用自己的真实数据重新测准确率、校准和阈值。

写在最后

Jev 取消等待名单以后，注册和试用已经没有太高门槛。5 美元额度足够跑大量输入，但有价值的测试不是随便丢几个问题看答案，而是挑一组有人工标签、接近真实业务的数据。

测试时至少保留四样东西：

输入状态和问题定义；
完整概率分布；
模型版本；
人工确认的真实结果。

可以先从低风险任务开始，分别计算误报、漏报和不同概率区间的正确率。高风险动作继续由代码和人控制。模型版本升级后重新测试，不要默认旧阈值继续有效。

所谓“零幻觉”，消掉的是输出越界和格式失控，并没有消掉错误判断。这已经很有价值，只是离放心把重要决定交出去，还差一整套工程工作。

手上有哪些高频判断，答案范围很明确，又适合先让 Jev 试一试？

资料边界说明

核查日期：2026 年 9 月 22 日。

主要资料：

口径说明：

67.8%和74.1%来自 TypeSafe 公开工作流评测，参考标签由 GPT-6 Astra 与 Fable 5.1 的预测形成，不是独立人工真值准确率。
193.6 倍速度优势和 444.6 倍成本优势，是厂商特定工作流中的高端结果。
上线约 36 小时处理约 14 万个注册、6 天后取消等待名单，来自 TypeSafe 自述及 explainx 对公开信息的整理。
“不会幻觉”仅指输出受到类型和预定义答案约束，不代表语义判断不会出错。
开放首日的登录报错来自网络流传的用户截图。现有信息只能说明错误发生在鉴权流程附近，不能确定影响范围，也不能归因于具体服务商。
LangChain 的 100% oracle 一致率来自 5 个固定案例各重复 100 次的窄测试，不代表通用准确率。
Jev 的完整架构、参数规模、正式 confidence 算法和训练数据细节尚未公开。
取消等待名单、赠送额度、价格和模型版本均属于时间敏感信息，正式发布前应再次核对。

67.8%不是错误率，却足以说明它并不总是正确#

“零幻觉”究竟消掉了什么#

真正该盯的是置信度，这里连着三个坑#

坑一：confidence不是probabilities之外的第二意见#

坑二：校准不等于这一条是对的#

坑三：高confidence也不等于事实正确#

不要给整个系统只设一个阈值#

官方列出的“毛边”比营销词更值得读#

同一个命题，换一种问题类型，数值不能照搬#

一个命题和它的否定，概率不一定相加等于1#

它很按字面办事#

数学、计数和日期留给代码#

state默认不是可信区域#

LangChain的第三方测试说明了什么#

它会成为新品类，还是被大模型吸收#

哪些任务适合先交给Jev#

写在最后#

资料边界说明#