“零幻觉”的 AI，为什么仍然会判断错误？

如果一个审批模型只允许返回“通过”“拒绝”“补充材料”，它确实不会突然输出程序不认识的第四种状态。但该拒绝的申请被判成“通过”，仍然完全符合格式要求。

读到 Jev 发布文中的“零幻觉”时，我最在意的就是这个区别。TypeSafe 在图表说明中写明，0% 并非来自错误率实测，而是依据输出符合 schema 的保证。Schema 可以理解为程序接受的结构和取值规范。这是有价值的接口约束，却不能直接解释为判断不会出错。TypeSafe 发布文

选错类别通常称为误分类，未必属于狭义的生成式幻觉。术语需要分清，但对一个实际执行决定的软件来说，后果仍然存在：格式正确的结果，也可能触发错误动作。

先分清输出里的三个数

界面上出现“置信度 0.987”，容易让人以为答案已经接受了额外核验。实际上，它可能只是对模型输出分布的一种概括。

Jev 的 Choice 和 Score 会返回概率分布，以及由这个分布计算的 confidence。官方将后者描述为衡量分布集中程度的统计量；它并不是另一套审查流程给出的证据，也不能直接等同于所选答案的正确率。Noul 则不带这个字段。Confidence 文档

在使用这些结果之前，至少应当分开：

• 某个选项的预测概率：模型给这个答案多少概率。
• 接口里的 confidence：按产品定义，把整个分布概括成一个数。
• 实际正确率：拿一批预测与真实标签对照后，答对的比例。

例如，A、B、C 分别得到 0.98、0.01、0.01，表示模型在这组候选中明显偏向 A。要进一步说“这类预测有 98% 是对的”，还需要实际结果支持。也不能把 confidence = 0.98 直接翻译成“98% 正确率”，因为那未必是这个字段的定义。

候选范围也会影响解释。如果正确答案不在选项里，模型可能非常确定地选出最接近的一个。对存在这种情况的任务，需要考虑“以上都不是”或“材料不足”，并检验模型能否识别它，而不是仅仅增加一个选项就认定问题解决了。

校准回答的是：报出的把握与长期结果是否相符

假设一个助手预测包裹能否明天到达。它给出 80% 到达概率的那批包裹，长期看约有八成按时到；给出 50% 的那批，约有一半按时到。这样的概率才有助于安排事情。

让预测概率与实际发生频率相匹配，就是校准关注的问题。它是已有的研究方向，softmax 能把输出转成概率分布，却不会自动保证这些概率校准良好。Guo 等人的校准研究

TypeSafe 把校准列为 RLCD 的训练目标，也说明这种性质针对预测群体，不能保证单个答案正确。这里要把厂商的训练目标与自己的业务表现分开，前者不能替代后者的评估。官方训练说明

校准也不等于有很强的区分能力。假设总体有八成包裹准时到，一个完全不看包裹信息的助手，对每件都报 80%，也可能在这个总体上校准得不错。但它没有帮助你找出最可能迟到的那一批。

所以要同时看几件事：能否判断对，能否区分不同案例，报出的概率是否与结果相符。一个漂亮的平均值，无法独自回答全部问题。

阈值怎么设，取决于错误会造成什么

先做一个假设算例：如果某组自动判断的真实正确率确实是 99%，一万次判断对应约一百次错误的期望数量。能否接受，取决于这些错误发生在哪里。

客服消息分错队列，可能只需要转交；未经核实就公开发布一条内容，可能难以完全撤回。发现错误的速度、纠正成本和影响范围不同，合适的自动化程度也不同。

这就是为什么“置信度大于 0.9 就执行”不能作为通用规则。首先要确认这里的 0.9 是什么量，再判断它在当前任务上对应怎样的表现，最后才结合后果设定执行条件。TypeSafe 的文档也要求按具体用例测试阈值。阈值使用说明

提高阈值通常会减少自动处理量，但剩下的结果是否更可靠，仍需看数据。实际使用时，可以同时记录两个指标：系统自动处理了多少请求，以及被自动处理的这部分里错了多少。只报告其中一个，都容易误导。

这里尤其要留意少数重要任务。普通请求占绝大多数时，总体成绩可能很好，权限变更等少数任务却表现很差。自动化范围应根据实际错误分布决定，不能让平均分掩盖关键部分。

验证概率，要比较一批结果，也要看它们来自哪里

如果想知道“90%”是否可信，可以准备一批未参与调参的已标注案例，将相近的预测概率放在一起，比较各组的平均预测概率与实际正确比例。这里针对的是所选答案的预测概率，不能不加区分地拿任意 confidence 分数充当正确概率。

分组时应保留样本数。十个案例中的九个正确，与一万个案例中的九千个正确，比例相同，证据量却不同。一个小分组的偶然结果，不能直接当成稳定规律。反过来，在一批报 99% 的预测中发现一次错误，也不能单凭这一例宣布校准失败。

阈值可以在开发数据上选择，再用独立数据检查；如果边看结果边改阈值，最后仍用同一批数据宣告可靠，就容易得到过于乐观的结论。准备自动执行的那部分，也应单独看错误类型和样本覆盖。

这种结论始终带着适用范围。普通客服消息上的结果，未必能迁移到缩写密集的技术报告。关于分布变化的研究表明，不确定性估计与校准可能随输入环境改变而退化。Ovadia 等人的研究

连问题的表达方式也可能改变数值含义。Jev 1.13 文档明确提醒，不要把 Noul 上调好的阈值直接移到 Choice；分别提出一个问题及其否定，也不保证两次输出恰好相加为 1。不能把不同查询当成同一个联合概率模型随意运算。Jev 1.13 限制说明

因此，记录模型版本、问题定义、候选和数据范围，有助于判断旧结果还能用到哪里。发生实质变化时，检查受影响的部分即可，无须每次重新证明整个系统。

概率无法补上一条尚未查询的记录

还有一种错误，单靠校准也解决不了。

开发者在提交说明中写“测试全部通过”，模型读完后给出很高的放行概率。这最多说明模型根据现有材料倾向于放行，不能证明它已经查询过测试平台。

对应哪个提交、执行了哪些用例、是否超时，都需要实际记录。若系统暂时没有权限读取，正确的状态应是“尚未核实”。低概率与缺少证据并不是一回事，高概率也不能把缺失证据变出来。

我愿意用概率帮助决定哪些请求可以自动处理、哪些值得再查一步。但会把“模型怎样判断”和“系统已经取得什么证据”分开记录。这样遇到错误时，才能知道该改的是模型、问题定义、数据，还是根本没有完成的核实步骤。

2026 年 9 月 27 日修订。包裹、审批场景与示例数字均用于解释概念，不是 Jev 的实测成绩。