TypeSafe 新发布的 Jev，主打不生成文字，只返回选项、概率和置信度。光看这些功能，我确实会觉得，拿个 base 模型后训练，再接个分类头，也能做啊。分类器已经是很成熟的技术了。 预训练模型接分类头，本来就可以直接输出分类概率。把答案限制在 A/B/C，也能保证它不会输出 D。所谓零幻觉如果指的是这个，和模型能不能选对是两回事。 Jev 允许开发者用自然语言定义问题和候选项，可以理解为估计 p(选项 | 输入状态、问题、候选集)。这比只认固定标签的业务分类器通用，但同样可以作为 base 模型的多任务后训练目标。难点在于换到没训练过的任务以后，判断质量还能保留多少。 它把同一份输入上的多个问题独立、并行求值，省掉了逐 token 写出完整答案的过程。直接给候选项打分，确实可能比生成一整段 JSON 快很多。但分类头本来也不需要生成文本，单凭这个对比看不出新架构的贡献。公开材料也没说明底层如何共享计算，一次 API 调用不等于只跑一次前向传播。 它的训练方法 RLCD 强调概率校准。给出 80% 概率的那组预测，长期看应该大约有 80% 正确。分类准确率高，不代表概率可信，一个正确率 90% 的模型，也可能动不动就报 99% 的把握。 这个目标有实际意义。程序需要根据概率决定自动执行还是转人工，同样选 A，51% 和 99% 应该触发不同处理。 但校准也有成熟方法。交叉熵、Brier score 可以用于训练概率预测，温度缩放可以做后处理。目前这些公开材料没有给出 RLCD 的奖励函数、训练配方和消融实验，还没法判断它相对常规训练加校准，多解决了什么问题。 Jev 的 confidence 也是从选项概率分布计算出来的统计量。分布很集中，说明模型偏向某个答案，不能单凭这一点认定它可靠。 如果它能让开发者直接用自然语言定义分类任务，省去准备数据、训练和部署的工作，同时保持低延迟、低成本，这个产品当然有意义。成熟技术做成好用的服务，本身就能解决问题。 不过，既然主张新架构和新训练方法，就应该和经过多任务后训练、带分类头和校准、支持批量推理的模型比较。在未见任务上测准确率、校准误差，以及相同错误率下能自动处理多少请求，再比较延迟和成本。这样的结果才能说明 Jev 到底做到了什么。