OpenAI RLHF 元老两年闭关，带着不会聊天的模型 Jev 归来

0# 发生了什么

9 月 15 日，在旧金山隐身两年的 TypeSafe AI 结束潜行状态，发布了公司第一款产品 Jev，并带着约 4000 万美元种子轮融资一起亮相，领投方是 DCVC。

创始人兼 CEO Diogo Almeida 此前在 OpenAI 和 Google Brain 工作，被业内认为是 InstructGPT、RLHF 训练路径的共同发明人之一，也参与过 ChatGPT 和 GPT-4 的相关工作。他在发布贴文里写道，在共同发明 ChatGPT 之后，他一直在想，为什么超人类聊天模型没有带来 AGI。TypeSafe 把 Jev 归入一个新品类，System One Model，这个命名借自卡尼曼《思考，快与慢》里那个快、直觉、模式识别的系统一。Jev 这个名字则来自经济学家威廉·斯坦利·杰文斯，他提出的杰文斯悖论认为，一样东西变便宜之后，消耗量往往不降反升，这也是 TypeSafe 对这款产品的赌注。

它是怎么工作的

Jev 不生成文字。你交给它一段状态，可以是工单、日志、邮件或结构化数据，再定义几道类型化的问题，它会并行给出答案，不走传统大模型那种逐字生成再解析的流程。

问题只有三种原语。Choice 从预设选项里选一个，返回选中项和每个选项的概率，上限 255 个选项，超过之后官方采用两阶段做法，先给候选项打分过滤，再在小范围里做选择。Score 按有序量表打分。Noul 判断一句话是否为真，返回一个 0 到 1 的概率。三者可以在同一次请求里并行提问。

比如客服场景，一封投诉邮件进来，可以同时问该转给哪个部门、是否构成退款请求、情绪紧急程度如何，一次返回就能让代码决定下一步动作，不需要从大模型的散文里抠结构。Almeida 自己在发布当天的演示里，还放了一段用 Jev 实时玩 Doom 和一段维基百科竞速的演示，后者用的就是高基数选择下的两阶段打分法。

速度上的差异来自架构。常规大模型逐 token 生成，Jev 用的是并行采样器，一次计算里对所有问题给出分布。Almeida 本人给出的口径是比同类聊天模型快 20 到 200 倍，便宜 40 到 400 倍，输出 token 永久免费。训练方法上，TypeSafe 用的是 RLCD，面向校准决策的强化学习，和 RLHF 优化人类偏好不同，RLCD 优化的是概率本身是否可信，宣称九成把握的判断，长期看应该大约九成正确。官方也提醒，校准是在一批预测上统计出来的，不保证单次判断一定对。

早期开发者在用它做什么

产品发布不到 48 小时，社区里已经出现几类典型用法，风评也不是清一色叫好。

LangChain 团队很快发了一篇集成博文，把 Jev 落地成两个场景，接入方式是一个叫 TypeSafeClassifier 的分类组件，配合模型路由中间件和 AutoMode 护栏。一是模型路由，用 Jev 快速判断任务难度，简单任务走便宜模型，难任务才调旗舰模型，路由判断本身就是一种分类任务，正好是 Jev 的甜点区。二是自动模式护栏，在工具真正执行前用 Jev 做一道风险检查，博文把这一层护栏比作给自动驾驶装了个反应极快的刹车，慢思考模型负责开车，快模型负责随时踩闸。同一篇博文里点名了三个社区实践：Browserbase 团队做的浏览器自动化、开发者 Jarrod Watts 的实时交易 agent、开发者 Ryan Vogel 的大规模邮件分类。

企业场景里最直观的一个案例来自 Box CEO Aaron Levie，他发了一段演示：从 Box 里取出一份事故报告，问它是否面向客户、严重程度如何，再把文件自动分流进升级、观察或复核三个目录，并写回一条元数据。他形容这个过程几乎瞬间完成，成本几乎为零，并列举了保险理赔、合同管理、贷款处理、安全审查、客户日志分析等类似场景。

也有开发者算了笔实在账。有人在 24 小时里花了 3.40 美元测试 Jev，认为这事不该看成 Jev 对抗现有大模型，而应该是 Jev 加上大模型，大模型在思考和规划上浪费了不少 token，很多本该用更快模型做的小决策，现在可以交给 Jev。他还提到 Jev 在提示词层面就能学会任务，不用像微调大模型那样准备训练集，给一条示例就够；也判断现在 32K 的上下文偏小，如果未来做到百万级，检索场景会更好用，不过这属于他的个人预期，还没有官方口径印证。

但也有反例。一位开发者把 Jev 接成 Codex 的模型路由器，想让简单任务自动分流到便宜模型，起初效果不错，任务能按难度更合理地分配。但他后续做了缓存命中率的实测，发现频繁切换模型让缓存命中率从固定用一个模型时的 99.35% 掉到了 32%。这很关键，因为推理接口里重复发送的历史 token 命中缓存时价格会便宜十到十五倍，频繁换模型相当于不断打断这条缓存链路，省下的模型差价很可能被打散的缓存吃掉。他的结论是，不搞清楚这笔账之前不建议这么用。

接入渠道上，除了官网排队申请，目前已经能通过 OpenRouter、Vercel AI Gateway、Cloudflare Workers AI、Netlify AI Gateway 这几个第三方平台间接调用 jev-latest，LiteLLM 也提供了透传接入。

公司想回答的问题

TypeSafe 的解释是，过去所有模型的训练默认对面坐着一个人，读它输出的是人，而软件真正需要的是可以直接写进分支逻辑的判断，不是又一段漂亮的话。他们内部把这件事总结为做生产，而不是继续追逐不断后移的通用智能门槛。杰文斯悖论是他们押注的另一半，一旦一次判断的成本足够低，软件不会减少调用智能的次数，而会在每个循环、每条工单前都多问一句。

和过去技术路线的对比

传统前沿模型训练主要靠 RLHF 或 RLVR，目标是让输出更符合人类偏好或者通过某些可验证的检查。Jev 的 RLCD 换了一个优化目标，校准概率而不是取悦评分者，这决定了它的输出形态从一开始就是为了被代码消费，而不是被人阅读。

Jev 发布仅一天后，另一家团队 Cua 就开源了一个体积 2.8MB、参数量只有 70.6 万的填表专用模型 CUA-S1-FORMS，在自己的填表评测上跑出 99.7%，同一评测下托管版 Jev 是 83.6%，而且免费、不到 1GB 内存就能本地跑起来。

这个对比经常被拿来当作 Jev 的反例，但换个角度看，它更像是验证了 Jev 打开的那个品类：给重复的计算机操作训练一个足够小、足够专的模型，再由一个更强的 agent 在多个专科模型之间做调度，表单、CRM 更新、数据录入、浏览器操作、文档分拣、界面判断，理论上都可以各自拆出一个小模型。

那些倍数和边界需要注意什么

最容易被反复转发的两个数字，193.6 倍更快、444.6 倍更便宜，来自 TypeSafe 自己做的工作流评测，对照基线是把 GPT-6 Astra 和 Fable 5.1 包进同类接口后取平均概率，而不是人工标注的真实答案，四组评测工作流也是由公司自己的模型能力团队设计的，存在选择偏差的可能。TypeSafe 自己也承认，真实世界的增益大概率会低于这个峰值。

一个更贴近真实使用的案例来自有开发者分享的记忆过滤实践：把 Jev 当作 agent 工具日志的过滤器，给每条工具调用打分，代码改动和关键失败保留，类似检查解析器、读了两百多行这种空转记录直接砍掉——不是压缩总结，是直接丢弃。据其反馈，一次实测把大约 15.6 万 token 的上下文砍到 6.2 万，占用比例从 78% 降到 31%。这是单人分享的个案，不是官方数据，但方向和 Jev 官方宣传的过滤场景是一致的。

能力边界上，Jev 明确不做生成，写不出回复、代码或者摘要，官方文档把生成列为失败模式之一。所谓不会产生幻觉，准确说是它吐不出没有在 schema 里定义过的类型，但选错选项、给错分数完全可能发生，类型安全不等于事实正确。它也不解释自己为什么这么判断，返回的只是一个概率和置信度，涉及合规审计、需要说明理由的场景，单靠一个置信度分数并不够。前面 Codex 路由的例子也提醒了一件容易被忽略的事：接入 Jev 本身几乎不花钱，但它可能在别的地方，比如提示缓存上，制造出看不见的新成本。

现在能怎么用

官方渠道是官网排队，获批后在控制台生成密钥。一条社区总结的接入路径是，申请资格通过后，让 Codex 安装 TypeSafe 的技能包，在后台建好 API Key，之后提问时加一句"使用 TypeSafe skill"就能调用。着急尝试的开发者也可以先走 OpenRouter、Vercel AI Gateway 这类已经接入的第三方平台。

真正决定效果的不是密钥，而是怎么把一个模糊的需求拆成三道原子问题。阈值、重试、人工介入这些逻辑都得写在 Jev 之外——它本身不调用任何函数，也不决定下一步该做什么。$