TypeSafe AI 发布的 Jev 不生成任何文字，只在几百毫秒内并行给出带概率值的结构化决策。创始人 Diogo Almeida 是 ChatGPT 的联合发明人之一、RLHF 的重要贡献者，他用两年时间回答一个问题：模型这么聪明，自动化为什么还难落地。
你有没有想过，AI 模型最大的问题从来不是不够聪明，而是不够可靠？我们已经用了好几年的 ChatGPT、Claude、Gemini，它们能写文章、写代码、解释任何概念，聪明得让人叹服。但如果你真的要把它们嵌进一个生产环境里，让它每秒钟做几百次决策，你会立刻撞上一堵墙：它们太飘了。同样一个问题问两次，答案可能不一样。让它返回结构化的 JSON，它偶尔会幻觉出一个根本不在 schema 里的字段。让它判断一条用户消息该路由给哪个团队，它有时候会突然开始解释自己为什么这么选，而不是直接给你答案。这些问题在人机对话里还能忍，但放进自动化流程里，一次错误就能让整条链路崩掉。
就在前几天，一家叫 TypeSafe AI 的公司发布了一个叫 Jev 的模型，它彻底不走这条路。Jev 不生成任何文字，它只做一件事：给你一个带概率值的结构化决策。这家公司的创始人 Diogo Almeida 是 ChatGPT 的联合发明人之一，也是让语言模型学会听人类指令的核心技术 RLHF 的重要贡献者。他在 OpenAI 工作多年，然后离开，用两年时间重新想了一件事：为什么模型这么聪明，自动化却还是这么难落地？Jev 就是他给出的答案。我认为这个答案非常值得认真看一遍。
一、Jev 到底是什么要理解 Jev，先得理解它跟普通语言模型的本质区别在哪里。
我们平时用的所有大语言模型，不管是 GPT、Claude 还是 Gemini，工作方式都是一样的：输入一段文字，然后一个 token 一个 token 地往外吐字，每个 token 都依赖前面所有内容的上下文，一直生成到它觉得可以停下来为止。这种方式叫自回归生成（autoregressive generation），好处是极其灵活，几乎什么都能写，坏处是慢、贵、不可控，生成的内容你事先根本不知道会是什么形状。
Jev 完全不是这个架构。它不生成 token，根本没有自回归循环。你给它一段状态（state），可以是一封邮件、一段代码、一条用户消息，再给它一组问题，每个问题都有有限的选项，然后它在几百毫秒内把所有问题的答案全部并行计算出来，每个答案都带着一个校准过的概率值。TypeSafe AI 把这种模型叫做 System One Model，借用的是心理学家 Daniel Kahneman 在《Thinking, Fast and Slow》里提出的框架：系统一是快速的、直觉性的判断，系统二是缓慢的、深思熟虑的推理。我们之前用的所有大语言模型，都在模拟系统二。而 Jev 是第一个真正在做系统一的模型。
具体来说，Jev 支持三种问题类型。第一种叫 nule，是或否的判断，比如“这条消息是不是退款请求”，Jev 会告诉你是的概率是多少、否的概率是多少。第二种叫 choice，让它从几个选项里挑一个，比如“这封邮件应该转给哪个团队处理”，给它账单、技术、销售三个选项，它挑出最合适的那个并给出置信度。第三种叫 score，让它在一个量表上打分，比如“这个用户有多愤怒”，从冷静到愤怒给出一个分值。这三种类型组合起来，能覆盖掉几乎所有你需要 AI 来做判断的场景。
最关键的一点是：Jev 的输出永远是类型安全的（type-safe）。它从不产生幻觉，因为它根本没有机会随便输出什么，每个答案都必须落在你预先定义好的选项里。TypeSafe AI 把这说成是数学上的保证，不是工程上的优化，就是不可能出现类型错误。这对于构建可靠的自动化系统来说，意味着非常多。
二、为什么速度和成本的差距大到这个程度Jev 比现有语言模型快 20 到 200 倍，便宜 40 到 400 倍。第一次看到这个数字，我以为是营销话术，但仔细看了 TypeSafe AI 发布的技术细节后，发现这个差距是架构层面的必然结果，不是靠压缩或者量化省出来的。
核心原因在于并行采样。普通语言模型生成答案的过程是串行的，第一个 token 生成完才能生成第二个，依此类推，每一步都依赖上一步的结果，整个过程像一条流水线，快不了。但 Jev 完全不一样，它接收状态和问题之后，所有问题的所有答案是同时并行计算的，没有顺序依赖，充分利用了现代硬件做并行计算的能力。TypeSafe AI 专门为这种并行场景设计了采样器，整个模型架构从一开始就是为此而生的。
另一个原因是输出极度精简。普通语言模型输出的是字符串，字符串可以任意长，生成越多 token 越慢也越贵，而且 output token 的计费通常比 input token 贵好几倍。Jev 的输出是结构化的概率值，量极小，TypeSafe AI 甚至直接写在定价页面上：output token 免费，因为便宜到没有必要计费。实际测下来，端到端的响应时间在 70 毫秒到 500 毫秒之间，而主流语言模型做同类任务通常需要几秒到几十秒。
最直观的案例来自 Vercel。他们之前用 Gemini 2.5 Flash 这种已经算是“便宜快速”的小模型来做分类任务，换成 Jev 之后速度提高了 6 倍，准确率直接把评测拉满了。还有一个案例是用 Jev 来玩《毁灭战士》（Doom），让它实时读取游戏状态，每秒做十次决策，控制角色移动和射击，连续跑一小时的总成本只有 7 美元。如果换成普通大语言模型做同样的事，成本高出几个数量级，速度慢到游戏根本没法玩。
三、它解决了一个我们习以为常的深层问题我觉得 Jev 的出现戳中了一个大家平时不太说、但心里都清楚的问题：用大语言模型做自动化决策，其实从来都不可靠。
现在构建 AI agent 的通常做法是，把所有需要模型回答的问题塞进一个大 prompt，然后期望模型按照你的格式把答案返回出来。为了让模型返回结构化的 JSON，现在的 SDK 都支持所谓的“结构化输出”，理论上可以强制模型按照指定 schema 输出。但实际情况是，你仍然需要在代码里加上 try-catch，因为答案偶尔会被截断，模型偶尔会在 schema 里幻觉出一个不存在的字段，或者返回一个字面上符合格式但语义完全偏掉的答案。这些问题在测试环境里可能不显眼，但在生产里跑量上去之后，错误率就开始让人头疼了。
Jev 从根本上绕开了这个问题。因为它根本不生成字符串，幻觉这件事在架构层面就不存在。你能拿到的永远是一个合法的概率分布，落在你预先定义好的选项里，附带校准过的置信度。TypeSafe AI 特别强调了“校准”这个词，意思是置信度和准确率之间是有意义地对应的：Jev 说它有 90% 的把握，那它实际的准确率就应该在 90% 附近。普通语言模型给的置信度其实没什么参考价值，它们天生倾向于过度自信，告诉你它很确定，但实际上错了。
这种可靠性对于真正要落地的系统来说意义很大。如果你的系统有延迟保证，或者 Jev 的判断被埋在一个依赖链的深处，一次类型错误可能让整条链路挂掉。普通语言模型在这种场景里不是不行，而是你永远要为不确定性留一个口子，系统设计的复杂度因此上升很多。Jev 让你可以真正把这一层当成可信任的基础设施来用。
四、那些真正有意思的使用场景我看了很多开发者在 Jev 刚开放 early access 之后做出来的东西，挑几个我觉得最能说明问题的。
最实际的是各种分类场景。有人用 Jev 分类了一千多篇 AI 研究论文，把它们归入不同主题类别，方便后续检索，整个分类过程每篇花了 256 毫秒，总成本 8 美分。有人用它来分析简历和职位描述的匹配程度，跟小型语言模型相比，成本只有十分之一。还有人用它处理个人邮箱，几秒钟内读完几百封邮件，自动打上优先级标签，判断哪些需要回复、哪些是垃圾邮件。如果换成普通语言模型来做，同样的量可能要花几分钟，成本也高出一个数量级。
另一个让我觉得很有想象力的场景是 model router，让 Jev 来决定一条请求应该发给哪个语言模型处理。这其实是一个很高频的工程问题：简单的问题发给便宜的小模型，复杂的问题才用大模型，怎么判断“这条请求有多复杂”往往靠一个精心调过的 prompt，准确率参差不齐，维护起来也麻烦。换成 Jev 来做这个路由决策，快、准、便宜，而且不会有幻觉。一个真实案例是 Sentry 的内部 Slack 机器人，原本用一个很长的 prompt 来判断请求应该走哪个模型，改成 Jev 的两个问题之后，逻辑更清晰，速度也快了很多。
还有一个场景是用来做 guardrail，也就是在语言模型输出之后，用 Jev 快速验证这个输出有没有问题：有没有幻觉、有没有类型错误、是不是 jailbreak 攻击。这个场景以前要么用规则，要么再调一次小型语言模型来审查，前者覆盖不全，后者加了额外的延迟和成本。Jev 在这里是一个非常自然的选择，够快、够便宜，而且类型安全的输出让它自己不会引入新的问题。
最让我印象深刻的一个案例来自一位视频剪辑师 Brent，他完全出于好奇想试试 Jev 能不能帮他剪视频。Jev 本身不是视频编辑器，但它发现 Brent 用的是 Adobe Premiere Pro，就先尝试直接修改 Premiere Pro 的工程文件，发现这样不够，就自己写了一个可以装进 Premiere Pro 的插件，通过这个插件去控制剪辑操作。TypeSafe AI 的团队说他们第一次看到这个发生的时候都惊了。这个案例背后更大的启示是：不一定要为每个垂直场景单独造一个专用工具，让一个足够通用的智能体自己找到连接专业工具的路，这种思路打开了很多新的可能性。
五、传统软件、语言模型和 Jev 之间的关系我觉得有一个框架能帮助理解 Jev 在整个 AI 软件栈里的位置。
传统软件是完全确定性的，就是 if-then-else，输入什么、输出什么，不会有偏差。语言模型是非确定性的，给它同一个输入两次可能得到两个不一样的输出，这让它极其灵活，但也让它很难被集成进需要稳定性的系统里。Jev 处在这两者之间，TypeSafe AI 把这个位置叫做“AI 驱动软件的混合世界”。你用普通代码做确定性的逻辑，但在那些规则太硬写不了、太脆容易断的地方，嵌入 Jev 来做模糊判断。Jev 的输出是概率值，但这个概率值是类型安全的、校准过的，可以被你的确定性代码以可预期的方式处理。这让整个系统同时具备灵活性和可靠性，而这两个特性以前很难同时满足。
举个具体的例子。一个客服 agent 收到一条用户消息，传统做法是把这条消息扔给一个大语言模型，让它判断意图、决定路由、生成回复，全部在一次调用里搞定。问题是这一次调用里有太多可能出错的地方，而且你很难知道哪个环节出了问题。换一种方式：先用 Jev 在 100 毫秒内快速判断这条消息的意图和优先级，成本几乎为零，准确率很高。如果是简单的订单查询，直接走工具调用查数据库，根本不用动语言模型。如果是复杂的投诉，再调语言模型来生成个性化的回复。如果判断用户有恶意意图，立刻拦截。这种分层架构让整个系统更快、更省、更稳定，Jev 在第一层扮演了一个非常关键的角色。
我自己把这个理解成一种新的软件设计模式：过去我们在“完全人工逻辑”和“完全交给大模型”之间二选一，现在多了一个中间层，一个专门为决策而生的、轻量但可信赖的 AI 组件。这个中间层的出现，让很多以前因为延迟或者可靠性问题不敢上 AI 的场景，变得可行了。
六、训练方法是核心创新TypeSafe AI 把他们的训练方法叫做 RLCD，全称是 Reinforcement Learning for Calibrated Decisions，用于校准决策的强化学习。这个名字跟我们熟悉的 RLHF 和 RLVR 都不一样，值得花一点时间理解为什么。
RLHF 是 ChatGPT 背后的核心方法，让人类评估者给模型的输出打分，模型从这些分数里学习什么样的输出是人类觉得好的。这套方法非常适合训练对话能力，但它的目标函数是“人类偏好”，这天生就意味着模型会倾向于输出听起来有说服力的内容，而不一定是正确的内容。RLVR 换了一个思路，用可以程序化验证的奖励信号来训练，比如数学题对不对、代码能不能编译，这类任务有明确的正确答案，所以奖励信号干净。但它依然在生成字符串，仍然是自回归的。
RLCD 的目标是完全不同的：不是让人类觉得回答好，也不是让答案可验证，而是让模型输出的概率值是校准的（calibrated）。所谓校准，是指如果模型说它有 80% 的把握，那在所有它给出 80% 置信度的情况里，实际准确率就应该接近 80%。这是一个非常具体的、可以用统计方法验证的目标，跟“人类觉得这个答案好不好”完全不同。TypeSafe AI 认为，正是因为以前的训练目标都是为了生成让人类喜欢的文字，才导致模型在做决策判断这件事上天然不适合，它们没有被训练来给出诚实的概率，只是被训练来说出听起来正确的话。这个洞察我觉得说得非常准确。
七、如果把 Jev 用在应用里，能做什么我自己花了不少时间想这个问题：如果你是一个在做 B2B SaaS 或者消费类产品的团队，Jev 能真正帮你解决哪些实际的痛点？我觉得有几个方向特别值得认真看。
第一个方向是用户意图的实时识别。现在很多产品里都有搜索框、输入框、或者某种形式的对话入口，用户打进来的东西五花八门，你需要在几百毫秒内判断这个用户到底想干什么，是在查数据、提工单、找功能，还是在问一个需要人工介入的问题。以前这件事要么靠关键词匹配——太脆，一旦用户换个说法就抓不到——要么靠调一次大语言模型——太慢，一次调用就要等好几秒，用户体验直接垮掉。Jev 在这里是一个非常合适的选择，你把用户的输入当作 state 传进去，问它“这条消息属于哪个类别”，它在 200 毫秒以内给你答案，整个过程用户根本感知不到延迟。
第二个方向是智能路由。一个复杂的产品里通常有很多模块、很多流程，一条用户请求进来，应该触发哪个流程、调用哪个工具、唤起哪个 agent，这个路由决策往往是整个系统最容易出错的地方。现在的做法是写一个大 prompt 让语言模型来决定，但语言模型在这件事上并不稳定，同一条消息可能今天路由到 A，明天路由到 B，让工程师完全摸不着头脑。换成 Jev 来做路由，你把所有可能的路径列成 choice 选项，让它从里面挑，结果稳定、速度快、而且每个决策都有置信度，你可以在置信度低的时候设一个兜底逻辑，而不是让系统盲目往下走。
第三个方向是内容的实时审核和过滤。任何有用户生成内容的产品都需要这一层，不管是社区帖子、客户评论、用户上传的文件，还是 AI 生成的内容在发出去之前的自我审查。以前做内容审核要么靠规则库，要么靠专门训练的小模型，前者维护成本高，后者需要大量标注数据。Jev 可以让你直接用自然语言描述你的审核标准，然后让它对每一条内容打分，判断是否违规、属于哪个风险等级、是否需要人工复核。因为它够快够便宜，你完全可以对每一条内容都跑一遍，而不是抽检。
第四个方向是 AI 输出的验证层。这个场景我觉得在未来会越来越重要。随着越来越多的产品开始用大语言模型生成内容、做推荐、写报告，一个核心问题随之而来：这些输出怎么验证？靠人工审查显然不现实，靠规则也太脆，但如果你用另一个大语言模型来审查，成本和延迟都翻倍了。Jev 可以在这里扮演一个轻量的验证角色，你把语言模型的输出当作 state 传给 Jev，问它一系列问题：这个回答有没有回应用户的问题、有没有包含敏感信息、有没有出现幻觉的迹象、格式是否符合要求。每一个问题都是一次快速的结构化判断，整体加起来的时间和成本都可以接受，但能帮你在输出真正触达用户之前多加一道保险。
第五个方向是个性化体验的动态调节。这一点很多产品团队其实没有意识到。用户的行为在产品里是有信号的，他浏览了什么、点击了什么、在哪里停留了很久、在哪里立刻退出了，这些信号你能收集到，但怎么实时地把这些信号转化成产品行为的调整，一直是一个很难解决的工程问题。传统做法是用规则引擎，但规则写到一定复杂度之后根本维护不了。换一种思路：把用户最近的行为序列作为 state 传给 Jev，问它“这个用户现在更可能需要什么”，让它给你一个带概率的判断，然后你的代码根据这个判断动态调整界面、推荐内容、或者触发某个引导流程。这件事本来需要一个专门的推荐系统团队来做，现在你用 Jev 加几百行代码就能搭出一个够用的版本。
第六个方向是客服和支持流程的前置分诊。这个场景几乎每一家有用户的公司都会遇到。用户提交了一个工单，或者发了一条消息，在真正进入处理流程之前，你需要判断它的优先级、类型、情绪状态、是否需要人工介入，以及应该分配给哪个团队。这件事如果靠人工来做，是一个非常低价值的重复性工作；如果靠大语言模型来做，速度和成本都撑不住高频场景。Jev 在这里是一个几乎完美的选择，它可以在用户消息刚进来的瞬间完成所有这些判断，帮你把真正需要人工处理的工单从噪声里筛出来，同时把那些可以自动化解决的问题直接分发出去，整个过程对用户来说是无感的。
我自己最感兴趣的，是把上面这些场景叠加起来之后会发生什么。一个产品里可以同时有多个 Jev 判断在跑：用户消息进来，第一层 Jev 判断意图，第二层 Jev 决定路由，中间某个语言模型生成了回复，第三层 Jev 验证输出，最后回复发出去之前，第四层 Jev 做一次合规检查。整条链路里，语言模型只在真正需要它的那一步出现，其他所有决策节点都是 Jev 在用毫秒级的速度处理。这种架构在成本上、延迟上、可靠性上，都比“所有事情都扔给大语言模型”强得多，而且每一层出了问题你都能精确定位到是哪个判断出了错。
八、我自己的一点思考我觉得 Jev 的出现揭示了一个很多人没有明确说出来、但其实已经感受到的事实：我们过去几年对语言模型的使用方式，并不是语言模型最擅长的使用方式。
把所有问题都扔给一个生成文字的模型，让它同时做判断、做推理、做表达，然后再从它输出的字符串里解析出我们真正需要的结构化信息，这整个过程其实很别扭。我们是在用自然语言这个接口来模拟一个结构化决策系统，而语言模型本来不是为这个设计的。它被训练来生成人类喜欢的文字，不是被训练来给出诚实的概率。这两件事之间有一道很深的鸿沟。
Jev 做的事情，是把决策这件事从语言层剥离出来，还给了它本来应该有的形态：一个接收状态、输出概率决策的推理组件。这不是说语言模型没用了，而是两类东西各回各的位。需要理解、生成、对话的场景，继续用语言模型。需要分类、路由、判断、验证的场景，用 Jev 这类专门为决策设计的模型。这种分工本来就应该存在，只是以前没有合适的工具来承担决策这一层。
Diogo Almeida 在创始人声明里说，他在 OpenAI 的时候就意识到，对话模型可能不是通往自动化的路，尽管当时 ChatGPT 刚出来，整个行业都在为它疯狂。他花了两年在 stealth 状态下重新想这件事，结论是要从底层重新造一套东西，不是在现有模型上打补丁。我觉得这种从问题出发而不是从技术能力出发的思路，才是 Jev 最值得关注的地方。不是它现在有多完美，而是它指向了一个在架构上更合理的方向。
我自己判断，未来两三年里，Jev 这类 System One Model 会成为每个认真搭 AI agent 的团队标配的基础组件，就像现在没有人构建 web 应用会不用数据库一样。它现在看起来还是个新鲜玩意，但它解决的问题太真实了，成本和速度的差距太大了。这种东西一旦稳定下来，会很快变成理所当然的基础设施，而不是什么值得炫耀的新技术。
本文由人人都是产品经理作者【深思圈】，微信公众号：【深思圈】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议
天牛宝提示：文章来自网络，不代表本站观点。
