解析 Jev：数据工程师的系统一利器

中文旁白 · 1080p · 字幕已内嵌为轨道 · MP4

文章：Jev 是什么——把“判断”做成一次函数调用的系统一模型

假设你手上有 5000 万条商品评论，需要逐条判断情感倾向，并检查有没有违规内容。用前沿 LLM 跑一遍，光 API 费用就可能上万美元，还得排队等上好几天。这类任务每一条都只需要一个简短的结论，却要付生成整段文字的代价。

Jev 就是冲着这个问题来的。它是 TypeSafe AI 在 2026 年 9 月正式发布的模型，创始人 Diogo Almeida 是前 OpenAI 研究员，参与过后来成为 ChatGPT 基础的指令跟随研究。TypeSafe AI 把 Jev 称为首个公开的“系统一模型”（System One Model）：它不写文章、不写代码，只针对你提出的问题给出带概率的判断。按厂商的说法，上面那 5000 万条评论用 Jev 处理，大约 20 美元、几个小时就能完成。

这篇文章是视频内容的文字版，按顺序说明 Jev 的输入输出长什么样、为什么能又快又便宜、它的训练目标“校准”是什么意思，以及数据工程师在流水线里可以怎么用它。最后也会讲清楚它的局限，尤其是目前的数字大多来自厂商自报。

用 LLM 做结构化判断，难在哪里

LLM 是逐个 token 生成文字的。哪怕只是一个“是或否”的判断，模型也要把完整回复一个字一个字地吐出来。视频里引用的延迟是一次 3 到 30 秒，输出 schema（预先约定的输出格式）越复杂越久，放到百万级的批量任务里根本扛不住。

生成出来的文字还得再做 JSON 解析和校验。格式错误、多出来的字段、模型编造的内容，都要靠额外的代码去防。成本同样是问题：输入和输出都按 token 计费，任务量一大，账单就很吓人。

“系统一”和“系统二”这两个词来自 Kahneman 的《思考，快与慢》：系统一是快速的直觉判断，系统二是缓慢的深度推理。用这个框架看，问题在于我们一直在拿系统二的慢推理引擎，去做本该属于系统一的快判断。

输入一段状态，输出三种带概率的答案

Jev 的输入不是对话消息，而是一段非结构化的“程序状态”，可以是文本，也可以是结构化数据。输出则不是自由文本，只有三种固定的原语，每一种都附带校准过的概率。

第一种是 Choice，从你预先声明的最多 255 个选项里选一个，并返回每个选项的概率分布。第二种是 Score，在一个有序刻度上打分，比如“平静—不满—非常生气”。第三种是 Noul，也就是是或否的二元判断，返回 0 到 1 之间的概率。

以客服消息为例，你可以把消息文本作为状态传进去，同时问三个问题：该由哪个团队处理（Choice），是否紧急（Noul），客户有多生气（Score）。创始人的说法是，把 Jev 看成一次前沿智能的函数调用：非结构化的状态进去，类型化的概率决策出来。也可以把它理解成 AI 版的 if 语句。

一次前向传播：为什么快，为什么不会格式出错

Jev 又快又便宜的关键在于只做一次前向传播。传统 LLM 要自回归地逐个 token 解码，输出越长，推理时间越久。Jev 则在推理之前就把输出空间里的所有候选答案枚举好，然后在单次前向传播中同时计算每个候选的概率，直接取概率最高的那个。

因为没有逐 token 生成的步骤，输出从结构上就不可能出现格式错误，也不可能冒出 schema 之外的内容。厂商自报的延迟是 70 到 500 毫秒，比前沿 LLM 快 40 到 200 倍，但这些数字目前还没有独立验证。至于底层架构，官方没有公开，外界有各种猜测，都未证实。

RLCD：让模型说的置信度等于实际准确率

光快还不够，判断得准才有用。Jev 的训练方法叫 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习）。它和 RLHF 不同，RLHF 优化的是人类偏好，让回答更合人的心意；也和 RLVR 不同，RLVR 针对的是有确定正确答案、可以自动验证的问题。

RLCD 的目标是“校准”：让模型声称的置信度尽可能等于它实际的准确率。天气预报是个好比方——把所有预报“70% 会下雨”的日子拿出来统计，其中大约 70% 真的下了雨，这个预报就是校准良好的。

如果置信度真的可靠，就可以直接拿来当阈值：高于某个值自动处理，低于某个值升级给人工或更贵的 LLM 复核。

在数据流水线里怎么用

最直接的用法是 map 式批量打标，对百万级的评论和工单做分类、打分和路由。在 RAG（检索增强生成）场景里，可以用它给检索出的文档片段打相关性分，决定哪些段落进入 LLM 的上下文。它也能当 LLM 输出的护栏，用 Noul 快速判断生成内容是否合规、是否存在幻觉。

其中最有价值的是按阈值分流：置信度高于 0.9 的自动处理，低的送人工或更强的 LLM 复核。这样昂贵的算力只花在真正拿不准的少数案例上。

价格方面，厂商公布的是输入每百万 token 0.042 美元（约 4 美分），输出完全免费，因为根本没有生成 token 的步骤可以计费。前面 5000 万条评论约 20 美元的估算就是这么来的。接入也不复杂，用官方 SDK 三行代码就能跑起来。目前 Jev 处于早期访问阶段，从等待名单逐步开放。

局限：输出格式正确，不等于判断正确

首先，类型安全不等于判断正确。Jev 不会输出错格式，但完全可能在 schema 之内选错答案。其次，它不给自然语言理由，在需要可解释性和监管审计的场景下，这是硬伤。

再来看基准数字的来历。目前所有基准都是厂商自报的，没有独立第三方验证，引用时务必注明。厂商在内部 4 个工作流评测中，以 GPT-6 Astra 和 Fable 5.1 两个模型的平均结果作为参照，而不是独立标注的真值。结果如下：

从表上看，Jev 的优势在速度和成本，准确率与同档 LLM 持平，比更强的模型低几个百分点，并不突出。定价能否持续也存疑，厂商自己承认目前的极低价格可能处于补贴阶段。另外，校准效果依赖实际部署的数据分布，在流水线里串起来的多个判断，错误也不会自动互相抵消。

所以上线前一定要准备黄金数据集（人工确认过正确答案的样本），检查准确率、漏报率和校准程度，不要盲目信任任何模型。

小结

Jev 不是要替代 LLM，两者解决的是不同层次的问题。生成文本、写代码、做复杂推理是系统二的领地，仍然属于 LLM；Jev 把“判断”这件事做成了便宜、快速、类型安全的函数调用，这是系统一的定位。

它的名字取自经济学家 Jevons。Jevons 悖论说的是，资源的使用效率提高，总用量反而会增加。当判断变得足够便宜，流水线的每个节点都可能加上判断逻辑，这也正是数据工程的趋势。

需要再强调的是，本文里的速度、价格和准确率都来自厂商公布的资料，尚待独立验证。比较稳妥的做法是先拿非关键路径上的分类任务试水，用黄金数据集验证校准效果，再决定是否扩大规模。官方介绍见 TypeSafe AI 的发布文章。

旁白由我本人的声音克隆生成，画面为示意。日文版在 /ja/。