发布 3 天登顶 HN：不生成一个字的模型 Jev，我把它的源码和黑料都扒了一遍

GreenTea
0 阅读4分钟

typesafe-jev-structured-decision-anime-illustration_1789715746.png

声明：本文所有数据截至 2026-09-18，模型 9 月 15 日才发布，处于早期访问阶段。性能数据基本来自官方自报，我尽量标注了来源和水分。

上周五（9.15），一家叫 TypeSafe AI 的公司在 HN 上发了篇博客，一天冲到 1863 分、491 条评论。主角是个叫 Jev 的模型，卖点听起来很离谱：

  • 不生成文本。只输出"选择 + 置信度"
  • 输出 token 免费，输入 $0.042/百万 token
  • 延迟 70~500ms，官方宣称比 LLM 快最多 193.6 倍、便宜 444.6 倍
  • "零幻觉" ——类型错误在数学上不可能发生

我第一反应是骗子，第二反应是去看 HN 评论，然后发现创始人 Diogo Almeida 本人在评论区挨个答疑（他的 ID 是 CompleteSkeptic，顺带一提，这个名字和 Dario Amodei 的对仗程度被 HN 网友吐槽了很久），Browser Use 团队三天内就把官方集成做了出来，还冒出来好几个独立复现项目。

这篇文章是我这两天把官方文档、HN 讨论、源码、第三方实测翻完之后的调研笔记。结论先放这里：方向大概率是真的，数据有水分，"零幻觉"是文字游戏，当"带概率的智能 if 语句"用是赚的，当小号 GPT 用是要翻车的。

一、Jev 到底是个啥

名字来自《思考，快与慢》：LLM 是 System 2——慢、深、逐 token 推理；Jev 想做 System 1——快、直觉、直接给判断。"Jev" 则取自经济学家 Jevons（智能越便宜 → 用例越爆发的 Jevons 悖论）。

关键认知：这不是"加了输出限制的 LLM"，而是一类新模型。创始人在 HN 的原话：

it is just a model, no harness yet ;) it is a structured data model, but technically not a language model (it doesn't generate language)

两者的调用链完全不同：

LLM 的用法：
  prompt ──自回归逐token生成──▶ JSON字符串 ──解析/校验/失败重试──▶ 决策
Jev 的用法：
  state ──一次前向传播，所有问题并行──▶ 带类型的答案 + 概率分布
LLMJev
训练方法RLHF / RLVRRLCD（校准决策强化学习）
输出自由文本，需解析验证Choice / Score / Boolean，结构先于生成存在
采样方式逐 token 自回归所有答案一次并行算出，单次查询
端到端延迟3~329s70~500ms
幻觉会编造不会产生类型外的值（但会错，后文细说）
置信度过度自信、不稳定每个答案带校准过的置信度

二、API 长什么样：三种原语

整个模型只有三种问题类型（官方文档叫 primitives）：

类型回答的问题返回
boolean（Noul）是还是否？P(true)，0~1
choice选哪个选项？选项 + 全分布 + 置信度
score打几分？分数（可落在两级之间）+ 分布 + 置信度

一个真实的请求长这样（客服工单分诊场景）：

{
  "state": {
    "ticket": { "subject": "重复扣款", "messages": ["我被人扣了两次钱，赶紧处理"] },
    "order": { "id": "A-104", "charges": [49, 49] },
    "refund_policy": "重复扣款可全额退款……"
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems"
      }
    },
    "is_urgent": { "type": "noul", "instructions": "The message conveys urgency" },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated is the customer?",
      "criteria": ["Calm", "Frustrated but civil", "Very angry"]
    }
  }
}

三种类型混着发，一次请求全部并行返回。官方文档里有几个特别值得划线的细节：

  1. 问题 ID 不会发给模型。ID 只是给你的代码用的 key，模型只看 instructions，所以 instructions 必须自包含。可以用 `ticket.messages[0].text` 这种点路径直接引用 state 里的字段。
  2. 13 个问题合并成一次请求，比拆 13 次调用便宜 11.5 倍、快 9.6 倍。因为所有问题共享 state 且独立并行评估，加问题几乎不增加延迟——只多付问题本身的 token。官方管这个叫 speculative fan-out：把代码可能需要的所有问题都发出去，代码自己挑着用。
  3. state + questions 共享约 32K token 预算。
  4. boolean 没有 confidence 字段，P(true) = 0.5 只表示"五五开"，不是"中等程度"。想量化程度（比如愤怒等级）请用 score。
  5. 只吃文本，不支持图像/音频；训练以英语为主，中日韩文本可接受但准确率更低——这对中文场景是个实打实的限制。
  6. choice 的选项基数上限 255，再高要用两段式（先独立打分再显式选择）。

三、为什么快？为什么"零幻觉"要打引号？

快的原因很朴素：没有自回归。  LLM 生成 100 个 token 要跑 100 次前向；Jev 对所有问题只跑一次前向，答案（可以理解为读概率头/logits，而不是采样成文字）并行出。输出因此"too cheap to meter"——输出 token 干脆免费。

"零幻觉"是语义游戏，但也不是纯吹。  它的准确表述是：模型不可能输出选项集合之外的值（分布永远定义在你给的 criteria 上，这是数学保证），所以不存在"编造字段、编造选项、编造 JSON"这种 LLM 特有的幻觉。但是——它可以在选项之内高置信度地选错。错误形式从"编造文本"变成了"自信地做错决定"，后者其实更隐蔽，后面第四节有实测打脸案例。

架构官方没公布，只给了 RLCD 这个名词。目前可信度比较高的拼图来自两个地方：

  • HN 上引擎圈大佬们的推测：本质是 Transformer encoder + 分类/回归头，"每个问题相当于一次单 token 补全，直接读 logits"，再针对校准做了后训练；
  • 独立复现项目 jevlike（717 星）实现的同形架构，画出来是这样：
                 ┌──────────── context tokens（state 编码）────────────┐
  option A ──▶  [attention 池化] ──▶ 共享打分头(dot product) ──▶ score ┐
  option B ──▶  [attention 池化] ──▶ 共享打分头            ──▶ score ┼─▶ softmax ──▶ P(A),P(B),P(C)
  option C ──▶  [attention 池化] ──▶ 共享打分头            ──▶ score ┘

每个选项作为 query 去 attend state 的 token，一个共享打分头出分，softmax 归一化。这正是"基数 255 上限"的来源——选项是在 softmax 维度上展开的。如果 Jev 真是这个形态，那它确实"不是语言模型"（不预测下一个 token），但也不是什么魔法，护城河问题就变得尖锐（见第五节）。

另外 HN 有人发现官网首页藏了段 base64 的雷神之锤快速平方根倒数代码——一个叫 typesafe 的网站放了个 type punning 的算法，团队是懂梗的。

四、AI SDK 底层是怎么调的（源码扒皮）

这是我这两天觉得最有意思的部分。AI SDK 7.0.105+ 加了个实验性 API experimental_evaluate，Jev 是第一个原生接入的模型。我直接去 vercel/ai 仓库把链路翻出来了：

import { experimental_evaluate as evaluate } from 'ai';


const result = await evaluate({
  model: 'typesafe-ai/jev',        // 字符串 ID → 默认走 Vercel AI Gateway
  state: 'The support agent issued a full refund to the customer.',
  questions: {
    refunded: { type: 'boolean', instructions: 'Was a refund issued?' },
  },
  providerOptions: { gateway: { zeroDataRetention: true } },
});


result.answers.refunded            // { probability: 0.97 }
result.providerMetadata.typesafe.confidence  // choice/score 才有置信度

字符串模型 ID 会解析到 Gateway 的 GatewayEvaluationModel，它干的活非常薄——就是把 state 和 questions 原样 POST 出去（源码）：

// packages/gateway/src/gateway-evaluation-model.ts（节选）
async doEvaluate({ state, questions, headers, abortSignal, providerOptions }) {
  const { value: responseBody } = await postJsonToApi({
    url: `${this.config.baseURL}/evaluation-model`,   // 就一个端点
    headers: combineHeaders(..., {
      'ai-evaluation-model-specification-version': '4',
      'ai-model-id': this.modelId,                    // typesafe-ai/jev
    }),
    body: { state, questions, ...(providerOptions ? { providerOptions } : {}) },
    successfulResponseHandler: createJsonResponseHandler(gatewayEvaluationResponseSchema),
    ...
  });
  return { answers: responseBody.answers, /* rounding / usage / providerMetadata */ };
}

响应 schema 用 zod 定义得很清楚——每种问题一个判别联合：

z.discriminatedUnion('type', [
  z.object({ type: z.literal('choice'),  choice: z.string(), probabilities: ... }),
  z.object({ type: z.literal('score'),   score: z.number(),  probabilities: ... }),
  z.object({ type: z.literal('boolean'), probability: z.number() }),
])

AI SDK 拿到响应后还会做概率校验：分布求和必须为 1、score 必须等于分布的加权均值，默认容差 1e-6。也就是说"类型安全"这个约束在 SDK 层又兜了一道底。

还有个容易忽略的点：evaluate 不是 Jev 专属 API。OpenAI/Anthropic/Google 的模型也实现了 evaluationModel 接口——但走的是"一次 prompt 评估所有问题"的 LLM 适配器（默认 reasoning: 'none'），并没有 Jev 那种逐问题独立并行的语义。这套设计基本明牌了 Vercel 的判断：evaluate 是在给 "System One" 这个接口形态铺路，Jev 只是第一个原生实现。

一句话总结这层抽象：generateText 是"帮我写"，evaluate 是"帮我判"。后者没有流式、没有批量无关输入、没有部分成功——因为它压根不是聊天。

顺带一提，不走 AI SDK 的话，TypeSafe 原生 HTTP API 也就一个端点：POST /v1/systemone，SDK 默认模型别名是 jev-latest。

五、X 和社区这三天都在拿它玩什么

  • Doom（官方 demo） ：把游戏状态喂成结构化数据，每秒查 10 次"往哪走、开不开枪"，成本约 $7/小时。HN 评论两极："游戏 QA 要变天了" vs "你们 reinvent 了外挂"。
  • Browser Use 官方集成 jev-ultrafast（2 天 2700+ 星） ：浏览器 agent 的动作空间被做成"操作 + 目标"两组 choice 问题，一次网络往返出两个决策，全程无截图。Google Flights 完整搜一遍苏黎世→伦敦机票只要 7.1 秒（含加载等待）。
  • 宝可梦对战：X 上 @sid19arya0 的实测，Jev 打赢了 Opus 5，成本约 1/820，速度快约 10 倍。作者还发现它的第二、第三选项也是合理战术。
  • Claude Code 上下文压缩插件 fast-jev-compaction（一天 1500+ 星） ：思路相当聪明——不找 LLM 写有损的压缩小作文，而是把整个对话塞进 state，对每个工具调用并行发两个 noul 问题（"这个调用还有用吗？这个结果还需要原文吗？"），按置信度阈值决定保留/截断/删除，保留下来的内容 100% 原文，路径、报错、命令一个字不丢。作者称 TypeSafe 联创也下场点赞了。
  • 模型路由：用 Jev 分类意图、估算难度，把简单请求路由给便宜模型、难的升级给贵模型（HN 上有人开源了路由 demo）。这是目前公认最稳的用法。
  • 复现热潮：jevlike（独立训了个同形模型，还能从图像 patch 打分玩 Doom）、Mini-Jev（本地 LLM 模拟 Jev 接口）、open-jev（Gemma 3 4B）、Sokit（Jev 版 LangChain）、DSPy 插件……一个闭源模型发布三天长出这些，说明"这个接口形态有需求"是行业共识。

关于"贪吃蛇/自动驾驶"的 demo 我没找到一手出处，DNF。可以确认的是 HN 上"这玩意能不能开车"的讨论很热（好几个人对标 Tesla FSD 的技术栈），Doom 这类实时控制 demo 是同一路线。

六、泼冷水时间：扑克桌上的鱼

光看 demo 容易上头，说两个实测翻车的。

第一个是扑克，做得非常扎实。作者用德州扑克求解器当地面真值，测了 150 个决策点：

  • Jev 与求解器最优解的吻合率只有 63% ；
  • 手持天顺（nuts，怎么打都不会输的牌）时，16 次运行 16 次全下（正确动作是 check），置信度 ~62%；
  • 最扎心的是置信度倒挂：在它错得最离谱的地方给出最高置信度（0.86），在它最接近正确的地方反而只有 0.09。而且错误高度可复现——这不是噪声，是系统性偏差；
  • 只有把结论直接喂进 state（比如 "Flush, Ace high"、"hero has 0 outs"），它的判断才明显改善。它没法从原始牌面自己推理出"我输了"，得有人把答案嚼碎喂到嘴边；
  • 在一个具体陷阱点上，关掉思考的 Haiku 4.5 都能选对，Jev 不行。作者的暴论：一个"能 check 就 check"的一行规则都能打赢 Jev。

第二个是迷宫。HN 用户发现 Jev 连单步迷宫都解不稳，推测训练分布里压根没有空间推理。

第三是护城河问题。Sean Goedecke 的分析流传很广：快结构化输出这事现在就能做——约束解码 + 只生成一个受限 token + 预填充，他自己用 Qwen2.5-1.5B 就拿到 2-3 倍加速。如果 Jev 本质是"encoder + 打分头"，各家实验室随时能跟进。另外它没有思维链、没有测试时计算，智能上限被锁死在"非推理 LLM"水平，别指望它scaling出新智能。

还有一点要记得：官网那些 193.6x/444.6x 全是自报。评测的参考答案是 GPT-6 Astra 和 Claude Fable 5.1 开高推理模式的平均，工作流还是自家团队手搓的。官方在另一篇博客里把"拒绝刷榜"讲得头头是道（顺便把各家 benchmark 作弊史捋了一遍，Llama 4 私有变体、GLM-5.2 设计榜那事儿都有点名），姿态是好姿态，但截至发文，官方那套成本/速度数据依然没有独立复现。X 上倒是流传一份自称"一万次 API 调用黑盒探测"的结果（MMLU-Pro 准确率 84.6%、1200 道 MMLU 题上期望校准误差仅 0.0313、推测是稀疏 MoE 约 100 亿活跃参数），我翻了 HN 和搜索引擎都没找到原始出处，无法核验，刷到先当故事听——这大概就是热门模型发布后信息环境的常态。

七、所以，什么场景值得上？

我的判断（结合官方文档 + 社区实测）：

适合：

  • LLM 前置层：意图分类、模型路由、难度估算、漏斗过滤——HN 上的共识是能替掉 pipeline 里 40~70% 的 LLM 调用；
  • 一句话个性化与"语义列"：用户一句"不看引战、不看币圈"就是个私人邮件/评论分类器；简历初筛、评论属性抽取这类批处理，整张表扫一遍几分钟几美元，之后就能用 SQL 查；
  • 验证/护栏：审 LLM 输出、测越狱、查引用——每次检查成本是 LLM 调用的零头；
  • 高频实时决策：游戏 AI、agent 每步动作选择（browser-use 已经给出最佳实践）；
  • 大语料 map-reduce：$0.042/MTok 的输入价，扫库才扫得起。

不适合：任何需要生成文本、需要推理链、需要从原始信息推出隐含结论、或者你没有标注数据、没校准过置信度就敢全自动执行的场景。

上之前的三条军规：

  1. 拿你自己业务的 50~100 个带答案样本做私有评测。demo 表现不可外推，扑克实测的教训就是逐用例验证；
  2. 校准置信度（Vercel changelog 原话也是这个建议），低置信度的请求一律路由去人工。官方文档其实自己承认了：校准是针对预测群体衡量的，不保证单个答案正确——所以阈值必须在你自己的数据上调；
  3. 善用 speculative fan-out（一次发全部问题）和 composite scoring（多个 score 加权合成复杂判断），把"判断逻辑"放在代码里而不是模型里。
// 概率路由的标准姿势（来自 AI SDK 官方文档）
const { choice, probabilities } = result.answers.department;
if ((probabilities?.[choice] ?? 0) >= 0.9) {
  route(choice);              // 高置信 → 自动执行
} else {
  queueForHumanReview(result); // 低置信 → 人工
}

八、写在最后

Jev 让我兴奋的点不是"它多聪明"——它不聪明，扑克都打不明白。而是那个引用了 Nelson Elhage 的思路：快的软件不是把旧事干得更快，而是催生全新的任务。当"往任意决策点注入一次 100ms、一厘钱的智能判断"变成一个 API 调用，会有大量以前不值得做的程序变得值得做。这是把它叫做"新的计算原语"而不是"新模型"的原因。

三天时间：HN 1863 分、Browser Use 官方下场、一堆复现项目——方向被认可的速度前所未有。但它是 v1：闭源、只有文本输入、置信度要自己校准、护城河存疑、所有性能数据自报。适合现在做的事情是拿边缘场景试水，而不是把核心链路押上去。

以上。有实测过的兄弟欢迎评论区交流，尤其想看中文文本上的准确率实测（官方只说"非英语会更低"，这个"更低"到底多少，值得有人测一测）。

参考链接

avatar
文章
阅读
粉丝