ChatGPT核心研发者推出新模型：不生成文字，输出Token免费！

做了两年，终于从隐身状态出来

　　Diogo Almeida并不是普通的AI创业者。

　　他此前在OpenAI工作，参与了InstructGPT、RLHF以及ChatGPT相关研究。

　　DCVC在TypeSafe AI宣布融资时也将其描述为ChatGPT、InstructGPT和GPT-4相关核心技术的共同创造者之一。

　　这部分工作后来成为ChatGPT的重要技术基础。

　　但也正因为参与过这段发展过程，Almeida对今天的大模型有了一个新的问题。

　　过去几年，模型在聊天上的能力已经越来越强，甚至在很多任务上超过人类。

　　可问题是：这些能力为什么没有进一步变成真正的大规模自动化？

　　这其实也是他过去四年一直在思考的问题。

Models have been superhuman at chat for years, so where is all the automation?

　　在OpenAI时，他原本也曾认为，聊天模型或许最终能够通向AGI。

　　但随着模型越来越强，他逐渐意识到，这里似乎还缺了一块非常重要的东西。

　　于是，离开OpenAI后，他没有继续做一个新的聊天模型，而是成立了TypeSafe AI。

　　公司从2024年中开始研发相关技术，过去两年一直处于隐身状态，直到这次Jev发布，TypeSafe才正式走到台前。

　　而他们想解决的问题，也逐渐清晰起来：让AI从和人聊天，进入直接被软件调用。

　　这也是为什么Jev从一开始就没有按照传统LLM的路线设计。

Jev，故意放弃生成文字

　　Jev不是ChatGPT的替代品。

　　甚至可以说，它故意放弃了ChatGPT最擅长的能力——生成自然语言。

　　TypeSafe把Jev定义为第一款System One Model。

　　它的输入可以是文本、JSON或者软件状态，但输出不是一段回答，而是开发者提前定义好的结构化决策。

　　例如，一个客服系统收到：“我的信用卡被重复扣款了。”

　　传统LLM可能生成一段文字：“这可能属于账单问题，建议转交Billing部门……”

　　程序随后还需要解析这段文字，再判断到底应该执行什么操作。

　　Jev则可以直接返回类似这样的结构化结果：

confidence: 0.82

　　AI直接告诉程序：应该选什么，以及我对这个决定有多确定。

　　TypeSafe认为，这种输出方式更适合软件直接调用。

　　因为软件并不需要一篇漂亮的小作文，需要的是一个可以直接进入if/else、工作流、数据库或者API调用里的结果。

　　TypeSafe把这种能力称为machine-native intelligence。

unstructured state in，typed probabilistic decisions out。

　　也就是输入非结构化状态，输出带类型约束的概率决策。

　　这也带来了Jev和传统LLM一个非常明显的区别。

　　传统LLM是一个Token一个Token地生成内容，输出可以是任何字符串。

　　Jev则提前定义好了输出空间。

　　模型只能在这个空间里做决策，并且每一个结果都会附带概率和confidence。

　　TypeSafe甚至直接把这一能力概括成了：Zero Hallucinations。

　　这里的零幻觉，主要指它的输出被提前限制在了一个确定的结构里。

　　比如开发者规定只能返回A、B、C，Jev就只能在这几个选项里做判断，不会突然蹦出一个D，也不会生成一段程序无法解析的文字。

　　所以，即使Jev最后选错了，它也还是会在规定的范围里选错。

　　这也是TypeSafe强调的type-safe。

　　对于需要大量调用AI的软件来说，至少不用再担心模型突然输出一个完全不符合接口要求的结果。

RLCD，是这套模型的另一张牌

　　除了模型架构，TypeSafe还推出了一套新的训练方法——RLCD。

　　全称是 Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习。

　　TypeSafe认为，今天的LLM之所以擅长聊天，很大程度上是因为它们被优化成了更符合人类偏好的回答机器。

　　RLHF，就是这条路线的重要组成部分，RLVR则更多关注那些可以被程序验证的结果。

　　而TypeSafe想优化的东西不一样：让模型做出决策的同时，准确表达自己有多大把握。

　　这就是RLCD的核心。

　　对于自动化系统来说，这一点很重要。

　　例如一个客服Agent需要判断用户的问题属于退款、物流还是售后，传统LLM可以生成一段分析文字，再由程序解析结果。

　　Jev则可以直接返回结构化结果和对应置信度。更重要的是，这个概率不是随便让模型估一个信心分。

　　TypeSafe希望做到的是calibrated confidence，也就是经过校准的置信度。

　　如果模型长期显示95%的置信度，那么这类判断就应该大致有95%的准确率。

　　这样一来，AI的不确定本身也就成为软件可以使用的信息。

• 高置信度 → 自动执行
• 中等置信度 → 调用更强模型
• 低置信度 → 转人工

　　这和传统LLM最大的不同就在这里。

　　以前的软件只能问模型：“答案是什么？”

　　TypeSafe想让软件进一步知道：“你有多确定？”

　　这样，模型才有可能真正成为软件工作流里的一个决策节点。

　　TypeSafe官方也将这种能力概括为：让智能成为一种可以被软件依赖的基础能力。

速度和成本，才是Jev真正夸张的地方

The gains aren’t free: Jev can't generate text.

　　Jev今天看起来这么快，并不是凭空获得的，它主动放弃了自由文本生成。

　　传统LLM需要一个Token接一个Token地生成内容，这天然属于串行过程。

　　Jev则针对结构化决策进行并行采样，一次查询可以同时生成多个输出概率。

　　TypeSafe官方介绍中，Jev的端到端响应时间约为70-500毫秒，在System One类型任务上，相同智能水平下可以达到约40-200倍的速度提升。

　　在TypeSafe公布的一组workflow演示中，Jev完成任务只用了约0.114秒，成本约0.000081美元。

　　对比LLM则需要约8.566秒，成本约0.01388美元。

　　对应下来，官方给出的结果是：193.6倍更快，444.6倍更便宜。

　　这也是TypeSafe官网“193.6x faster、444.6x cheaper”宣传数字的来源。

　　除了速度，Jev的价格也非常夸张。

　　TypeSafe目前公布的价格是：

• 输入：0.042美元/百万Token
• 输出：0美元。

　　官方甚至用了too cheap to meter来形容输出成本。

　　按照TypeSafe自己的对比，Jev的输入价格比Claude Fable 5.1低约238倍。

真正的野心，是Composable Intelligence

　　所以，TypeSafe真正想卖的，可能并不只是一个Jev。

　　Almeida反复提到一个概念：Composable Intelligence，可组合智能。

　　如果AI能稳定输出结构化决策，它就可以像软件里的一个函数一样，被直接塞进分类、路由、评分、审核和工作流。

　　TypeSafe把这种模式称为AI-powered workflows，甚至提出了一个很形象的说法：smart if-statements。

　　传统代码是：

manual_review()

　　未来也可以变成：

human_review()

　　AI负责判断，代码负责约束和执行。

　　Jev没有继续和GPT、Claude比谁更像人，而是试着成为软件可以直接调用的决定器。

　　这也是TypeSafe所说的Composable Intelligence。

　　最终的问题也很直接：当AI越来越多地进入软件系统，我们真的还需要每次调用都生成一段文字吗？