AI不一定要“聊天”，OpenAI前研究员研发只做决策的模型，绕开文本生成，响应速度快200倍

大模型一定要一个 token 接一个 token 地生成文字吗？

9 月 15 日，前 OpenAI 研究员 Diogo Almeida 在社交媒体上公布了自己过去两年一直秘密推进的项目——一种名为 Jev 的全新 AI 模型。和 ChatGPT、Claude 等主流 LLM 不同，Jev 不再生成自然语言，而是直接输出结构化判断、概率和置信度。

（来源：X）

这也是 Almeida 创办的 AI 初创公司 TypeSafe AI 推出的首款模型。2024 年离开 OpenAI 后，Almeida 与几位联合创始人组建 TypeSafe，此后一直保持隐身。直到这次发帖，公司才正式亮相，并同期披露完成 4,000 万美元种子轮融资，由 DCVC 领投，本轮估值约为 2 亿美元。

TypeSafe 将 Jev 归入一类名为 System One 的新模型，并给出了看起来相当不错的性能数据。其宣称，在特定结构化工作流中，Jev 最高可比前沿 LLM 快近 200 倍、便宜 400 多倍，甚至能把“幻觉”和类型错误率做到 0%。

而 Almeida 的背景让这条路线显得尤其有意思。在 OpenAI 期间，他参与了 2022 年 InstructGPT 的研究。这项工作将监督微调、人类偏好数据和 RLHF 结合起来，让 GPT-3 更能按照人的意图回答问题，后来 ChatGPT 也沿用了相近的 RLHF 路线。OpenAI 在 GPT-4 的贡献者名单中，也将 Almeida 列入“Foundational RLHF and InstructGPT work”一栏。

图｜Diogo Almeida（来源：Typesafe）

换句话说，他此前参与推动的是一条让大语言模型更擅长理解指令、生成符合人类偏好的自然语言回答的路线。如今，他却开始反过来追问这套范式在自动化场景里的局限：如果 AI 最终要进入软件后台持续做判断，是否还有必要每次都先生成一段文字，再把结果交给程序解析？

从生成文字到直接决策：Jev 想改变 AI 的输出方式

要理解 Jev，首先要区分人与 AI 交互和机器调用 AI 这两种场景。

ChatGPT、Claude 这类大语言模型，本质上是生成模型。接到输入之后，它们不断预测下一个 token，再用已经生成的 token 继续预测后面的内容，最终形成一段文字。即使用户要求的是 JSON、函数调用或者几个固定选项，底层仍然是在按照序列逐步产生 token。

这种设计非常适合聊天，因为人需要模型解释、推理、写作，也需要它处理几乎无法提前穷举的开放式问题。字符串是一种极其通用的接口，一段文字可以是文章、代码，也可以是工具调用。

可到了软件后台，情况会有所不同。比如一个电商系统需要连续判断：“这笔订单是否异常？”“应该进入哪个审核流程？”“这个客户的流失风险有多高？”软件最终需要的可能只是几个值，却要先等待 LLM 生成字段名、数字、标点乃至额外解释，然后再解析、检查这段输出，才能进入下一步。

Jev 想要直接去掉这个中间环节。TypeSafe 用一句话概括它的接口：“unstructured state in, typed probabilistic decisions out”，也就是输入可以是一段复杂的业务信息，输出则是预先定义好的判断结果和概率。

比如，一个客服系统收到一段用户投诉记录，传统 LLM 可能先生成一段文字：“这名用户有较高流失风险，建议转人工处理，并考虑退款。”程序还要再从这句话里提取“高风险”“转人工”“退款”这几个真正有用的结果。

Jev 的做法则更直接，系统可以事先规定只需要三个答案：是否有流失风险、是否转人工、是否退款。Jev 读取同样的投诉记录后，直接返回“流失风险 82%”“转人工 91%”“退款 37%”。程序拿到这些结果后，就可以直接进入下一步，不需要再解析一段自然语言。

在采样方式上，TypeSafe 称 Jev 使用了并行采样器（parallel sampler）。主流自回归 LLM 需要逐 token 生成，而 Jev 可以在一次查询中并行产生多个结构化结果。

不过，“全新架构”这个说法目前还有待考察。因为TypeSafe 只披露了“new model architecture”、并行采样器以及一套新的训练方法，却没有公开参数规模、网络结构、backbone、预训练方式和训练数据。Jev 内部究竟使用了多少 Transformer 或语言模型已有技术，现在还无法判断。目前能确定的，是它明显改变了输出接口、训练目标和采样方式。

与 Jev 配套的，是 TypeSafe 提出的一套新训练方法 RLCD（Reinforcement Learning for Calibrated Decisions）。它不再主要优化模型生成的回答是否讨人喜欢，而是训练模型在做结构化决策时，给出尽可能可靠的概率和置信度。

（来源：TypeSafe AI）

举个例子，如果模型对很多次判断都给出“90% 的把握”，那么统计下来，这些判断中大约应该有 90% 最终是正确的。也就是说，模型说自己有多大把握，最好就真的有多可靠，这就是所谓的 calibration（概率校准）。TypeSafe 认为，这比让模型只给一个“是/否”更适合自动化系统，因为程序可以根据置信度决定是自动执行、继续验证，还是交给人工。

这也决定了 Jev 目前瞄准的应用范围。TypeSafe 列出的场景包括分类、路由、评分、信息提取、业务流程分支、大规模数据处理，以及给其他 LLM 做 judge、guardrail 和越狱检测等。公司把它形容成一种“smart if-statement”：原本必须由程序员提前写死规则的地方，可以插入一个能够理解语义的概率判断。

为了展示低延迟，TypeSafe 甚至让 Jev 玩起了《毁灭战士》。不过这个 Demo 本身并没有证明什么新的游戏能力。模型读取的是已经转换成文本和数据结构的游戏状态，并没有直接处理画面，公司也承认，一个传统专用游戏 Bot 完全可以玩得更好。但展示的重点是模型可以每秒连续接受多次查询，在实时软件中反复做判断。

“快 200 倍”，但建立在特定任务上

Jev 发布时最吸引眼球的，是“20～200 倍更快”和“40～400 倍更便宜”这两组数字。

从技术原理看，这种差距并不难理解。Jev 面向的是结构化决策任务，不需要像传统 LLM 那样自回归生成几十甚至数百个 token，而是可以一次性给出一组概率或判断，因此响应时间和推理成本天然更低。

TypeSafe 也展示过这种差异。在一项与 GPT-5.6 Terra 的并排演示中，两边读取相同的业务信息，并回答一批结构化问题。Jev 可以一次输出所有概率，而 GPT-5.6 Terra 仍需逐 token 生成答案，因此速度差非常明显。不过，公司也主动说明，这项演示经过了高度简化：输入较短、信息密度高，问题也被整理成适合结构化判断的形式，这些条件都会放大 Jev 的优势。

图 ｜ 在同一组 27 个结构化判断中，Jev 一次并行返回所有结果，而传统 LLM 仍需逐 token 生成答案（来源：TypeSafe AI）

官网中“193.6 倍更快、444.6 倍更便宜”的数字，则来自 TypeSafe 自行设计的 workflow eval。4 个工作流都包含大量独立判断，但评测并没有采用现实世界的 ground truth，而是把 GPT-6 Astra 和 Fable 5.1 的预测概率取平均作为参考，再衡量 Jev 与这个参考值有多接近。

因此，这套 benchmark 更适合说明：在 TypeSafe 设定的结构化决策任务里，Jev 可以用更低的时间和成本，做到与前沿 LLM 相近的判断。它还不足以证明 Jev 已经拥有与这些模型相同的通用能力。

TypeSafe 自己也给这些数字留了余地。公司称，193.6 倍和 444.6 倍属于他们预计在现实场景中“偏高端”的收益，而且 4 个 workflow 由自己的模型能力团队制作，因此可能存在一定选择偏差。对照组中的 LLM 还要通过 TypeSafe 的 System One wrapper 输出完整概率，这也会增加一些延迟和成本。

另一个值得注意的说法是，TypeSafe 宣称 Jev 可以避免传统 LLM 常见的幻觉和类型错误。这里更准确地说，是 Jev 的输出空间被提前限定，因此不会生成 schema 之外的字段或工具名称。公司在结构化输出和工具调用测试中把 Jev 的错误率标为 0%，但也明确说明，这个 0% 并非经验测试结果，而是来自 schema matching 的机制保证。

图 ｜ TypeSafe 对比 Jev 与多款前沿模型的结构化输出和工具调用错误率，并称 Jev 可从机制上避免格式和类型错误（来源：TypeSafe AI）

这并不代表 Jev 的判断永远正确。如果可选答案只有 A、B、C，它可以保证不会输出 D，但仍然可能在 A、B、C 中选错。因此，“不会幻觉”更适合理解为不会产生越出预设结构的输出，而不是不会犯语义或判断错误。

RLCD 也是类似。TypeSafe 希望通过这种训练方法，让模型给出的概率更加可信，这个方向对自动化系统确实重要。不过目前公开材料还没有给出足够完整的校准指标和外部测试，因此它到底能把概率校准做到什么程度，还需要后续论文或独立评测来验证。

但这不等于模型永远不会判断错误。如果可选答案只有 A、B、C，Jev 可以保证绝不会输出 D，可它依然可能坚定地选择 A，而真实答案其实是 B。TypeSafe 自己也注明，其图表中的“0%”并非经验测试测出来的，而是基于 schema matching 的结构保证。

RLCD 的概率校准也面临类似问题。这个方向本身很有价值，但目前公开材料里还看不到足够完整的 ECE、Brier Score、reliability diagram，也没有系统展示模型在领域变化、输入分布偏移之后，置信度是否仍然可靠。

Jev 想证明的，是另一种 AI 分工方式

不过在质疑之外，Jev的出现，也确实带来了一个更有意思的角度。

过去几年，LLM 逐渐成为 AI 应用里的通用接口。分类可以问 GPT，审核可以问 GPT，信息提取可以问 GPT，Agent 不知道下一步做什么，同样可以再调用一次 GPT。生成模型够通用，开发者不需要为每个环节单独训练模型。

但这种便利很可能带来另一种浪费：我们开始用一个擅长“生成任何东西”的模型，去完成大量其实只需要“做一个判断”的工作。

当然，过去也已经有分类器、reranker、reward model 和各种专用判别模型，它们都可以比大型生成模型便宜得多。

TypeSafe 押注的是更进一步的可能性：能不能把过去高度专用的判别模型，做成一个通用的基础模型。它既能读取复杂的自然语言和程序状态，又能跨任务完成大量不同判断，并给出足够可靠的概率，同时保持远低于生成模型的成本和延迟。

如果这个假设能够成立，AI 软件未来可能出现更明确的分工。大型语言模型继续负责开放式生成、复杂推理和长程规划；另一类像 Jev 这样的模型，则被埋进代码深处，每秒完成大量分类、路由、检查和决策。一个 Agent 内部可能不需要每一步都调用最昂贵的前沿 LLM。

这也是为什么，Jev 最值得关注的指标可能最终不是“快多少倍”，而是它能覆盖多少原本必须交给前沿 LLM 的判断。

如果只能处理几个高度结构化的工作流，它更接近一个高效的专用模型平台；如果能够跨行业、跨数据分布保持接近前沿模型的判断能力和概率校准，那么 TypeSafe 才真正证明了一类新的软件原生 AI 接口具有存在价值。

参考链接：

1.https://typesafe.ai/blog/introducing-system-one-models-and-jev

2.https://typesafe.ai/

3.https://www.dcvc.com/news-insights/typesafe-emerges-from-stealth-with-a-new-way-of-doing-ai/

4.https://www.forbes.com/sites/the-prompt/2026/09/15/this-200-million-startup-wants-to-fix-ais-overconfidence-problem/

5.https://openai.com/contributions/gpt-4/

6.https://arxiv.org/abs/2203.02155

7.https://github.com/openai/following-instructions-human-feedback/blob/main/README.md

文章来自于"DeepTech深科技"，作者 "张锦怡"。