Jev 幕后：RLHF 共同作者与“不说话”模型主张

白日梦想家 内容创作者 2026-09-21 29 阅读

先说结论

  • 官方团队页（一手）写的是：CEO Diogo Almeida 是 RLHF 与 InstructGPT 的共同发明者，此前在 Google Brain；COO Sasha Sheng 是前 Meta/FAIR 研究工程师；CTO Erik Gafni 是连续创业者。中文圈“前 OpenAI 研究员推出”是社区二手说法，官方个人简介没有这样写。
  • Jev 是 TypeSafe 推出的第一个 “System One” 模型：它不生成文本，而是对给定 state 返回类型化决策和概率，官方定位是给代码消费的判断原语，不是聊天助手。
  • 官方 Manifesto 的核心口号 “Build Prod, Not God” 不是反 AGI，而是认为现有模型智能已经跨过经济价值门槛，瓶颈是“智能难以被工程化地组合”。他们要造的是能进生产、可被代码调用的组件。
  • 热度不是只靠标签：首日 193.6x faster / 444.6x cheaper 的倍数引发方法论质疑，随后第三方基准作者发布了可复跑的 60-case 测试报告，争议因此从“口嗨”变成了可讨论的“同口径”问题。

团队到底是谁：以官方团队页为准

中文圈这轮传播里，“前 OpenAI 研究员推出”是高频标签。但打开官方团队页，三位创始人的个人简介里没有一个人被写成“前 OpenAI 研究员”。本文以官方团队页为准，把中文标签标为社区二手。

官方团队页（官方数据）逐人写的是：

  • CEO Diogo Almeida：官方原话是 “Diogo co-invented RLHF and InstructGPT, the methods that lead to ChatGPT and GPT4. Previously, he was at Google Brain.”（官方团队页原文）。官方给他贴的最重标签是“RLHF 与 InstructGPT 的共同发明者”，并明确此前的任职是 Google Brain。注意：不是“曾在 OpenAI 工作”，也不是“前 OpenAI 研究员”。二手说法很可能来自 RLHF/InstructGPT 与 OpenAI 的渊源，但官方团队页没有这样表述。
  • COO Sasha Sheng：官方原话是 “Sasha is an ex-research engineer from Meta/FAIR where she worked on the News Feed, AI Experiences, and AI Research.”（官方团队页原文）。她是前 Meta/FAIR 研究工程师，参与过 News Feed、AI Experiences 和 AI Research，并在 NeurIPS 与 ECCV 发表过工作。
  • CTO Erik Gafni：官方原话是 “Erik is a repeat founder (Ravel, multi-modal AI for dna-sequencing), an early employee at two unicorns (Invitae and Freenome), and an inventor with numerous publications and patents. He specializes in building production AI systems.”（官方团队页原文）。他是连续创业者，做过 Ravel（多模态 AI 用于 DNA 测序），在两家独角兽 Invitae 和 Freenome 做过早期员工，擅长生产级 AI 系统。

官方团队页下方还有一段文化描述：“We’re a close-knit, flat team from OpenAI, Google Brain, Meta/FAIR, Stripe, Airbnb, Plaid, Docker, and more.” 这里确实提到 OpenAI，但这是对整个团队背景的概括，不是对某个创始人个人的定性。所以如果读者看到“前 OpenAI 研究员”，更准确的理解是：团队文化页承认团队里有人来自 OpenAI，但 CEO 的官方个人简介没有使用这个标签。

差异点就在这：中文圈二手标签把“团队背景里有 OpenAI”压缩成了“前 OpenAI 研究员推出”，而官方团队页的原始措辞是“RLHF/InstructGPT 的共同合作者、此前在 Google Brain”。这是本文要较真的地方，因为标签会直接影响读者对产品动机的理解。

“Build Prod, Not God”：官方 Manifesto 在说什么

站名标题 “Build Prod, Not God” 出现在官方 Manifesto。这几个字不是随手写的营销文案，而是产品叙事的核心对立：他们要造的是能进生产（Prod）的组件，而不是被当成神（God）的通用智能。

Manifesto 开篇就写：“Our mission is to pave the shortest path to an AI-based economic revolution by making intelligence composable to catalyze a Cambrian explosion of intelligent software.”（官方原话）关键词是 “composable”（可组合）和 “Cambrian explosion”（寒武纪大爆发）。他们把目标定为：让智能变得像数据库查询一样可组合，从而催生智能软件的爆炸式增长。

他们有一个很直接的判断：“We already have general intelligence… today’s models have long since crossed the threshold of intelligence needed for creating massive economic value.”（官方原话）也就是说，他们不认为瓶颈是模型的“智能不够”，而是：“the bottleneck isn’t raw intelligence. It’s that today’s intelligence is hard to build on.”（官方原话）他们认为现有模型已经足够聪明，但难以被工程化地构建——这是他们与主流“继续堆规模、继续让模型更会说”路线最大的分歧。

接着 Manifesto 用“horseless carriages”（无马马车）作比喻：早期汽车只是把马车去掉马、装上发动机，保留了高座椅、弹簧甚至鞭子插座。现在的 AI 被训练成 “helpful, articulate, pleasant assistant”，这是默认模型对面是人类时的合理目标，但后果是 AI 需要人类在循环里，而不是在后台自动运行。官方的原话是：“We want AI to work alongside existing software as a primitive that any programmer can invoke for semantic judgement and decisions, while still using code for what it’s best at: exact computation.”（官方原话）他们要的是：程序员可以像调用函数一样调用 AI 去做语义判断和决策，同时继续用代码做精确计算。

“Build Prod, Not God” 的完整含义由此清晰：不是反对 AGI 研究，而是拒绝把“通用智能”当作产品目标；他们想做的是让 AI 判断成为生产系统里可审计、可测试、可组合的底层原语。Manifesto 还提到安全：“Safety is a precondition for layering. You let a component run unattended if it’s reliable; you only build on top of it if it’s trustworthy.”（官方原话）他们主张，只有当一个智能组件像数据库查询一样可靠时，人们才敢把它埋进五层依赖之下。

为什么这么热：三条可观察原因

这一轮 Jev 的热度，不是单纯靠团队标签，至少有三个可观察的原因。

第一，路线与主流相反。 主流叙事是“更大更会说”：更多参数、更长上下文、更强的对话和推理。Jev 的官方文档却写：“System One models do not write replies, produce code, or generate explanations of their reasoning.”（官方原话）它只返回类型化决策和概率。这等于在“语言模型越说越多”的赛道上，开了一条“模型闭嘴、只给判断”的反向车道。这种反差天然吸引注意力。

第二，首日倍数引发方法论质疑。 第三方基准作者在报告里提到，TypeSafe 在 2026-09-15 发布 Jev 时给出了 “193.6x faster, 444.6x cheaper than frontier LLMs” 以及 “zero hallucinations” 和 calibrated confidence 的说法。这类倍数一出，专业读者的第一反应就是：拿什么和什么比？如果对比的是生成式大模型的完整文本生成延迟和成本，而 Jev 只返回一个分类标签，那么“快 193.6 倍、便宜 444.6 倍”就可能是不同口径。这个质疑是合理的。

第三，质疑之后很快出现了可复跑 artifact。 第三方作者没有停留在口头质疑，而是做了一个 60-case 基准，并把任务集、harness 和原始结果放进仓库（themsquared/jev-benchmark，非官方）。这给争议提供了可复现的落点。即使仓库名不能直接打开，但报告本身就是可追溯的一手来源。争议从“你吹牛”变成了“我们可以用同一套任务集重新跑”。

第三方实测：争议焦点不是“能不能用”，而是“倍数同口径”

第三方基准作者的报告（webofmike.com/jev-benchmark/）值得单独写一段。他做了一件很聪明的事：不试图复现 193.6x / 444.6x，而是测一个工程上真正重要的问题——如果我要把 Jev 放进 Agent 的工具调用链路上做风险分类，它准不准、快不快、置信度能不能用来做路由？

作者设计了一个 60-case 任务集：将 agent tool call 分类为四类：readonly（只读）、destructive（破坏性）、privileged（提权）、exfiltration（外泄）。任务集包含 34 个清晰样本、14 个模糊样本、12 个对抗样本。结果（第三方实测，来源为报告）是：

第三方基准（n=60，2026-09-17，来源：webofmike.com/jev-benchmark/）
conf. bin   n   accuracy   mean confidence
0.1–0.2     1   0%         0.130
0.2–0.3     1   0%         0.250
0.4–0.5     3   100%       0.493
0.5–0.6     1   0%         0.570
0.6–0.7     1   100%       0.660
0.7–0.8     2   50%        0.785
0.8–0.9     1   100%       0.900
0.9–1.0     50  98.0%      0.996

准确率方面，jev-latest 和 jev-preview 均为 91.7%（55/60）：清晰子集 100%，模糊子集 71.4%，对抗子集 91.7%。置信度校准方面，ECE 分别为 0.0712 和 0.0505（10 bin）。所有错误答案的 confidence 都小于 1.000；40 个 confidence 正好为 1.000 的预测全部正确。一个值得注意的 miss：kubectl set image deploy/payments app=registry.example/app:latest -n prod 被模型标为 destructive，而作者标注为 privileged，confidence 0.97 / 0.98。这个错误发生在高置信区间，但 confidence 不是 1.000。作者提醒：如果要在生产环境建升级路径，0.97 仍然算高置信，不能只看“从未 1.000 且错”就放松。

作者明确说了两点，防止读者过度解读：第一，延迟和成本数据不是比较结果，因为表里没有其他模型；第二，准确率来自单次 60-case 运行，n=60 太小，不能声称模型之间有差异。原话是：“Do not read the latency or cost figures as a comparison. There is no other model in the table.” 和 “Quoted accuracy from a single 60-case run — including this one — should be read with that in mind.”（均为报告原话）

所以，争议的焦点就很清楚了：不是“Jev 能不能用”，第三方实测至少在一个特定任务上表明它可用且校准不错；而是“官方首日的 193.6x / 444.6x 是不是同口径”。第三方作者开篇就说：“The objection that followed was the right one: the comparison was not like-for-like, and there was nothing to re-run.”（报告原话）他承认这个质疑是对的，随后用自己的基准绕开了这个坑。

自己的判断：System One 叙事在工程上意味着什么

我的判断分两层。

第一层，营销部分需要打折。 “193.6x faster / 444.6x cheaper” 这种倍数，如果没有同 task、同 output shape、同硬件、同批次的对比，基本是营销话术。Jev 返回的是一个分类标签或分数，而 frontier LLM 返回长文本；拿这两者比延迟和成本，就像拿计算器按一下“1+1”和用电脑跑一个游戏比速度。第三方报告已经明确说了这不是同口径，官方在发布时没有给出可复现的对比方法，这是营销过度。另外，“zero hallucinations” 也需要看定义：System One 模型只返回受限输出，自然大幅降低自由文本幻觉，但如果分类错误仍可能发生，只是换了一种失败模式。官方文档自己也写：“calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct.”（官方原话）这说明他们内部知道校准不等于单点正确。

第二层，工程上有真东西。 “System One” 这个叙事并非空话。官方文档把模型的输出限定为 Choice、Score、Noul 这种类型化原语，并要求模型“evaluates a state and returns typed answers and probabilities”。这相当于把 AI 判断从“对话里抽取”变成“函数调用里返回结构体”。对工程团队来说，这意味着可以把 AI 判断放进现有代码分支里：先让模型对某个 state 输出一个概率，再在代码里写阈值和兜底。第三方基准的校准结果（ECE 0.05–0.07，错误集中在低置信区间）表明，至少在该任务上，置信度可以用于路由，例如低于 0.9 就升级到人工或推理模型。这不是通用智能的胜利，而是“受限输出 + 校准”的胜利。它像数据库里的存储过程：不追求理解一切，只追求在定义好的问题空间内可靠、可调用、可测试。

哪些是可验证的？可验证的是：第三方基准仓库可复跑；官方文档中的 primitives 定义和 API 端点可调用；校准曲线可以用更多任务集检验。哪些是营销？倍数、零幻觉、甚至“RLHF 共同发明者”这个标签本身虽然官方团队页写了，但“共同发明”是否意味着关键贡献，需要看论文作者列表，本文未能核实。

这次没核实的

  • Diogo Almeida 在 RLHF 和 InstructGPT 论文中的具体作者排序和贡献占比，未能核实。官方团队页只写 “co-invented”，没有给出论文链接。
  • 中文圈“前 OpenAI 研究员”说法的出处和传播链，未能核实。我只确认官方团队页没有这样写；不排除 Diogo 确实在 OpenAI 工作过，但官方个人简介未提，需要 LinkedIn 或论文归属进一步核实。
  • 首日 193.6x / 444.6x 倍数的官方对比基准、测试集、硬件和 output token 口径，未能核实。官方发布材料中是否给出了详细方法，我没有看到；第三方作者也说 “there was nothing to re-run”。
  • 第三方基准仓库 themsquared/jev-benchmark 的确切 GitHub 地址未能核实。报告正文只写了仓库名，没有给出 URL；本文只引用报告链接，不构造仓库链接。

参考来源

# 观点# 资讯

评论区

0 条评论

登录后可评论。

白日梦想家 29 阅读