2026年9月，前OpenAI核心研究员迪奥戈·阿尔梅达（Diogo Almeida）发布决策模型Jev。在1565封德语和英语商务邮件的分类测试中，Jev总体准确率96.4%，Gemini 3.8 Flash以98.5%领先仅2.1个百分点。但Jev的响应时间只有70到500毫秒，成本仅为每百万输入token 0.042美元，输出token完全免费。邮件分类基准测试中，错误发生的模式比准确率数字更有参考价值。
准确率落后2%，这笔账反而更划算
企业软件采购邮件分类系统时，最常问的问题是“准确率多少”，仿佛准确率就是一切。
当企业花了大价钱部署了一套Gemini方案，每天处理上万封德语商务邮件，工程师们发现账单和延迟才是真正的噩梦。Gemini每次分类调用需要3到329秒不等，对于一条每天要跑几十万次分类判断的自动化流水线来说，这个等待时间直接卡住了整条生产线的吞吐量。
Jev走的是一条完全不同的技术路线，响应延迟压到了70到500毫秒，企业可以在一个批次里同时发出几百个分类请求，系统并行处理所有判断，一次性返回结果。Gemini需要逐一生成分类标签的文本，Jev则在一次前向传播中同时输出所有类别的概率分布。
但是，Gemini的98.5%准确率确实更高。如果每个错误分类都要人工介入，Gemini的错误率更低意味着更少的人力成本。然而，1565封邮件中的错误数量差距大约是20到30封，按每个错误消耗5分钟人工审核来算，每天额外的人工成本可能还不如Jev省下的API调用费用多。
这就怪了！一个准确率更低的模型，在生产环境里的综合成本反而更低！
并行采样凭什么比逐字生成快100倍
要理解Jev为什么这么快，得先搞清楚它到底在做什么。普通的大语言模型像一位逐字念稿的播音员，每说一个字都要看一眼前面说了什么，按顺序一个token接一个token地生成。500个token的回答需要500次顺序计算，每次计算都依赖上一次的结果，这就是延迟的根本来源。
Jev的架构走了另一条路。它采用并行采样机制，不是把输出当成一串需要逐字拼装的文字，而是把问题拆成若干有类型的判断字段，一次性广播到多个并行处理通道里，单次前向传播同时计算所有字段的答案。
接收一封德语询价邮件，加上一组有类型的问题，比如“这封邮件属于哪个类别”“紧急程度如何”“是否需要人工介入”。模型不会写出一段解释文字，它直接输出三个结构化的答案，每个答案附带一个校准过的置信度分数。
这个设计彻底绕开了自回归生成的计算瓶颈。代价是Jev不能写任何自由文本，不能解释自己的判断，不能处理输出空间未知的任务。它的输出只能是预先定义好的选项之一、一个分数、或者一个带概率的布尔值。
这种限制是不是太苛刻了？
前OpenAI研究员、RLHF技术共同发明人阿尔梅达用了一个电灯泡的类比，发明电灯之后，人们不应该把一切都做成灯泡，而是应该继续发明电子器件和整个电力系统。聊天模型擅长跟人对话，但软件需要的不是对话，是一个决策。
校准置信度才是真正的胜负手
Jev最被低估的设计不是速度，是每个答案都带一个校准过的置信度分数。
这个概念叫做“校准决策强化学习”（Reinforcement Learning for Calibrated Decisions，简称RLCD），是TypeSafe AI为Jev开发的专用训练方法。传统的RLHF训练优化的是人类评分员更喜欢哪个答案，RLCD优化的却是另一件事：模型说70%的置信度时，在大量预测中应该大约有70%是对的。
为什么这个指标重要？想象一个保险公司的理赔系统，自动审批低风险案件，高风险案件转人工。如果用普通语言模型，它会自信地给出判断，但不告诉你这个判断有多可靠。系统不知道该在什么时候信任它，结果就是所有判断都需要人工抽检。
用Jev就完全不同了。系统可以直接设定一个阈值，置信度高于90%的判断自动执行，低于这个线的转人工审核。这个能力看起来简单，但它把AI从一个“需要被监督的助手”变成了一个“可以被编程的决策组件”。
但是，校准本身也有风险。一个模型可以非常自信地犯错，校准置信度并不能解决“系统性偏差”的问题。迪奥戈·阿尔梅达在Hacker News讨论中坦承，Jev确实会“自信地犯错”。如果一个类别在训练数据中代表性不足，模型可能以高置信度给出错误分类，而这个错误在置信度分数上根本看不出来。
事情没那么简单！
错误发生的位置比错误数量更重要
邮件分类测试中最值得关注的结果，不是96.4%和98.5%之间那2个百分点的差距，是错误集中在哪些类别上。
测试覆盖了10个类别，包括订单、报价请求、发票纠纷等。Jev在等权重准确率上从96.4%降到了92.0%，Gemini 3.8 Flash从98.5%降到了96.9%。等权重意味着每个类别的重要性被拉平了，Jev和Gemini之间的差距从2.1个百分点扩大到了4.9个百分点。
这说明什么？Jev的错误更集中地发生在某些特定类别上。如果这些类别恰好是高频次、可以批量处理的简单任务，那么实际影响很小。如果错误集中在低频但高价值的类别上，比如发票纠纷这种需要立刻处理的问题，那问题就大了。
从邮件分类的工程实践来看，类别不均衡是一个普遍难题。真实商务邮件的类别分布天然偏斜，订单和咨询占绝大多数，发票纠纷和投诉只占很小比例。一个在整体准确率上表现不错的模型，完全可能在少数关键类别上表现糟糕。
这就引出了一个更根本的问题，在生产环境中，你真正需要的不是整体准确率最高的模型，而是错误分布最可预测、最容易兜底的模型。
如果Jev的错误都集中在“把报价请求误分类为一般咨询”这类低风险类别上，加一条后处理规则就能修复。如果Gemini的错误散落在所有类别中，没有任何模式可循，那反而更麻烦，因为你不知道下一次错误会出现在哪里。
生产环境的“足够好”跟基准测试的“最好”是两码事
企业选型时经常掉进一个陷阱：用基准测试的排名来做生产决策，忽略了部署成本、延迟容忍度和错误模式的差异。
Jev在这个测试中的表现其实可以用一句话概括，它在大多数类别上“足够好”，而且它在“发现自己不确定”这件事上比Gemini更有优势。一个置信度只有60%的分类结果会被系统自动转人工，Gemini的输出格式里没有这个信号。
速度上的差距也是数量级的。70到500毫秒的响应时间意味着Jev可以在用户提交工单的瞬间完成分类和路由，用户感受到的是“系统秒回”。Gemini的3到329秒延迟在异步批处理场景下可以接受，但在实时客服、在线订单处理这些场景下就是灾难。
等等，如果Jev这么厉害，为什么它在总体准确率上还是输给了Gemini？
因为Jev从根本上就不是为了“赢”分类准确率而设计的。它的设计目标是让软件工程师能把AI当成一个可靠的“if-else语句”来用，你知道它会给出四种答案，每种答案附带一个概率，你可以根据概率来写业务逻辑。这是一种工程上的可预测性，跟统计学意义上的准确率是两回事。
从独立测试机构Every的评测来看，Jev在速度上比Claude Fable 5.1快约25倍、成本约为其1/580，但在植入缺陷的识别测试中只找到了7个中的6个，而Fable 5.1全部找到。Every的评语是“不错，但不完美”，这是目前第三方独立测试中最诚实的评价。
谁在生产环境里真的用上了
Roman Ismagilov在邮件分类任务上测试了Jev，准确率介于Luna和Terra之间，他用的词是“考虑到速度，令人难以置信”。这个评价指向了一个关键点，Jev不是要全面取代Gemini，它是在一个特定的任务切片里找到自己的位置。
Filippos K.提出了一个值得认真对待的问题：Jev的分类结果是否可复现？重复运行同样的邮件，是否会得到不同的结果？对于一个需要审计追踪的业务系统来说，如果每次运行结果都在几个百分点内浮动，系统就没法设定稳定的决策阈值。
这个问题触及了RLCD训练的一个隐含假设。校准意味着“长期来看”置信度和准确率是对应的，但在单次运行中，模型的输出可能因为并行采样的随机性而产生波动。TypeSafe还没有公布关于复现性的详细数据，这可能是未来部署时最大的未知数。
另一个值得关注的信号来自Yuntian Deng的评论，他提到了一个叫做ProgramAsWeights的方案，可以把你对类别的英文描述编译成分类器权重，然后在本地CPU上运行，不需要每次调用外部API。这意味着对于数据敏感的供应商邮件场景，企业可以在自己的基础设施上运行分类逻辑，这是云端API方案无法提供的选项。
这笔账最后还是要回到业务需求本身。
一封邮件分类错误导致订单延迟发货一天的损失，跟API调用成本之间的比值，决定了你应该选哪个方案。如果一个错误分类的代价是几百块钱，那Gemini的2个百分点准确率优势值得你付出几十倍的延迟和成本。如果错误分类只是标记错了文件夹，用户花两秒钟重新归档，那Jev的速度和成本优势就是压倒性的。
测试中最悬而未决的问题还没有答案，那1565封邮件里，Jev究竟在哪些类别上犯了错？这些错误是否集中在同一个模式上？如果答案是“错误均匀分布在所有类别中”，那Jev的置信度分数就没有太大实际价值。如果答案是“错误集中在特定的低频类别上”，那加一条针对性的规则就能把准确率拉到跟Gemini持平的水平。
这个问题的答案，可能比96.4%和98.5%这两个数字重要得多。而目前公开的信息里，还没有人能回答它。