HiSEN

hisenyuan's Blog

0%

Jev 是什么，和千问小模型相比差在哪

Posted on In Symbols count in article: 4.8k Reading time ≈ 4 mins.

1. 缘起

2026 年 9 月 15 日，TypeSafe AI 发布模型 Jev。它不生成文字，给定一段材料与若干预设问题，直接返回选项和概率。创始人 Diogo Almeida 为 InstructGPT 论文作者之一。发布三天内，GitHub 上出现十余个围绕它的项目。

它要解决的问题：Agent 跑一次任务，中间要做几十上百次小判断，比如下一步点哪个按钮、这封邮件归哪个队列、这条命令危不危险。这些判断的答案通常只是一个选项或一个数，但交给大模型做，模型得先把答案写成一句话，程序再解析回来。成本花在两处用不上的地方：把答案写成文字，以及每问一个问题都把同一份材料重读一遍。

2. 它是什么

2.1 和传统大模型的区别

大模型处理文字分两步。

第一步是读：把输入的文字逐层算一遍，转成模型内部的表示。这一步叫编码（prefill）。

第二步是写：在读过之后得到的内部表示上，一个字一个字地生成答案。这一步叫解码（decode）。

传统大模型两步都做。Jev 只做第一步，读完直接在内部表示上读出答案的概率。TypeSafe 官方把这条路线称作 System One，和生成类模型边写边想的 System Two 相对。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
传统 LLM：读完还要写

  材料 + 问题
       │
       ▼
   读（编码）
       │
       ▼
   写（解码）          { → " → q → u → e → u → e → " → …
   （循环）            每写一个字，都要接回上文才能算下一个
       │
       ▼
  {"queue": "payments"}
       │
       ▼
   程序解析这段文本

───────────────────────────────────

Jev：读完直接给答案

  材料 + 问题
       │
       ▼
   读（编码）
       │
       ▼
   读出概率           payments 0.91 / account 0.06 / other 0.03

「读」和「写」的耗时性质不同。

读是并行的。整段材料一起算，整个模型只需从显存读进来一次，这一次读入就用在了全部字符上。字符越多，这笔开销摊得越薄。

写是串行的。每写一个字都要把整个模型重新读一遍，而这一遍里只算出一个字，算力基本用不上。写 N 个字，模型就读 N 遍。

一份讲解给了具体比例：在一张 A100 显卡上，读可以一次处理 500 个字符、耗时约 50 毫秒，摊到每个字符 0.1 毫秒；写每产出一个字符要 10 毫秒，差两个数量级。实际服务会把多个请求攒成一批一起算来摊薄这笔开销，但单个请求上的差距就是这么悬殊。

所以生成类模型的延迟随输出长度增长，Jev 没有这一段。旁证：200 个选项的问题和 2 个选项的问题，返回延迟几乎一样。

2.2 输入和输出

一次请求分两段，state 放材料，questions 放问题。questions 里每一项就是一个问题，各带类型、问法和预设答案：

1
2
3
4
5
6
7
8
9
10
11
{
  "state": "我的提现连续失败三次，银行说一切正常",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "分给哪个团队？",
      "criteria": { "payments": "提现失败", "account": "登录", "other": "其他" }
    },
    "escalate": { "type": "noul", "instructions": "需要人工介入吗？" }
  }
}

问题分三类：Choice 从候选里选一个，上限 255 个；Score 按有序等级打分，2 至 10 级；Noul 做是/否判断。

响应按问题 id 逐项返回，没有文本：

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "model": "jev-latest",
  "answers": {
    "queue": {
      "type": "choice",
      "choice": "payments",
      "confidence": 0.87,
      "probabilities": { "payments": 0.91, "account": 0.06, "other": 0.03 }
    },
    "escalate": { "type": "noul", "noul": 0.42 }
  },
  "usage": { "input_tokens": 96, "output_tokens": 34 }
}

answers 下每一题返回一个对象：Choice 给选中的选项和各选项概率，Score 给加权后的分数和等级说明，Noul 只给一个 0 到 1 的数，是答案为「是」的概率。

0.91 这个数可以直接接阈值。Archer Hume 的报告里给了推法：设误升级一次代价为 1，漏掉一个紧急工单代价为 9，那么 p(紧急) > 0.1 时就该升级。代价比一变，阈值跟着变。

这条策略成立的前提是概率可信：模型说 0.9 的那批样本里，得真有约九成判断正确。TypeSafe 称 Jev 的概率经 RLCD（面向校准决策的强化学习）训练，让概率在训练时就对齐真实结果。这个声称未经独立验证：官方没公开训练细节，公开的测量只有 Jev 自己的基准记录。

还有两处容易看错。confidence 由 probabilities 的分布形状算出，集中就高、摊开就低，与「模型有多确定」不是一回事，Noul 类型没有这个字段。usage 里的 output_tokens 只是计费字段，不代表真生成了 token。

结构和字段名照官方文档，示例数值是示意。

2.3 一次读，多个问题

同一份材料上往往要问好几件事。已部署的 pi-jev 每收到一条编码 Agent 要执行的命令，就同时问四件事：

  • 这条命令有破坏性吗
  • 会把本地数据或密钥发出去吗
  • 超出用户要求范围了吗
  • 用户如果不想要，损害有多大

它给前三个问题各设了阈值，概率分别超过 0.90、0.70、0.85 就拦下这条命令。

若分开调用，这段材料要被完整读四遍：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
传统 LLM：材料读 4 遍

  问第 1 件     读材料 ──► 写答案
  问第 2 件     读材料 ──► 写答案
  问第 3 件     读材料 ──► 写答案
  问第 4 件     读材料 ──► 写答案

───────────────────────────────────

Jev：材料读 1 遍

  读材料（1 次）
      │
      ├─► 问题 1
      ├─► 问题 2
      ├─► 问题 3
      └─► 问题 4
          问题之间互不可见，只共享同一份材料

问题之间互不可见，这一点有实测：把验证码写在另一个问题里，再问某个问题该验证码是什么，返回概率 0.00；把同一句移进 state，概率升到 0.90 以上。

2.4 边界

  • 答案必须提前封闭，选项由调用方给出
  • 写不出任何文字
  • 没有推理过程，需要解释的场合用不了

3. 和千问小模型相比差在哪

最常被问到的问题：拿千问小模型来做同样的判断，效果是不是一样。把两者的差别按维度摆开：

对比维度Jev千问小模型自建结论
输出形态与解析直接读概率，无生成生成文本后解析，可用语法约束保证格式自建能复现
多个问题的成本state 只读一次需自己复用材料读过的部分自建能复现
响应速度官方 70～500 毫秒实测 1.023 秒自建慢一档
判断准确率0.883，官方公布0.845，实测 4B / 3090差 3.8 个点
概率校准称经 RLCD 校准，未独立验证未复现，数值未校准Jev 独有
部署方式托管服务，邀请制模型开源，单卡可跑各有取舍

六项里，输出和成本两项能完全复现，速度和准确率能复现但各差一档，只有校准是 Jev 独有，而这一项恰好也没被独立验证过。所以「用千问也能做」这句话，除了校准之外基本成立。

表里的数来自两个第三方项目：速度和准确率是 SemIf 测的（一张 3090、一个 4B 模型），校准是 SemIf 和 mini-Jev 的结论。自建那边是第三方在自己机器上跑，Jev 那边出自官方公布，两边不是同一条件。

校准这行的差距，mini-Jev 给了对照：让模型生成概率数值，准确率只有 0.346；改成直接读选项打分，升到 0.896。

官方还公布过 193.6 倍、444.6 倍的加速数字。这两个数字是自家设计的四类工作流上与特定模型比较的最大差距，换个任务不成立；官方基准里 Jev 得 67.8%，对照的前沿模型在 68%～74%，准确率处于中间。

4. 和现有 Agent 架构的结合点

凡是「看一眼材料、做一个答案受限的判断」的步骤，都可能换成 Jev。按 Agent 循环里的位置排：

在 Agent 里的位置判断什么现状
入口 · 意图路由这条输入该走哪条链路jev-router 已落地
循环内 · 下一步动作点哪个按钮、调哪个工具jev-browser 已落地
循环内 · 是否继续这步完成了吗、要不要重试官方列出，无实例
执行前 · 护栏这条命令危不危险pi-jev 已落地
执行后 · 校验上一步输出对不对官方列出，无实例
上下文 · 批次预筛哪些材料值得进上下文jev_map 已落地
离线 · 批量标注大批材料跑同一组问题SemIf 实测用法

意图路由对应表里第一行。官方有 Intent Routing 模式，实例是 jev-router，给 Claude Code 和 Codex 逐回合挑模型：简单的活给快档，难的给强档。

执行前护栏对应表里第四行。这类判断原本靠规则或小模型，规则覆盖不了措辞变化，小模型在长文本上读不准。可用的是 pi-jev 的命令闸门，LangChain 的 AutoModeMiddleware 也能在执行前拦下工具调用。官方把这类用途归在 Universal Verification 下，范围更宽：验证其他 AI 的输入、抽取结果、推理链和工具调用。

有个前提：Jev 发布才三天，表里的项目都是这三天里写的，没有一个有生产环境的运行时长。位置是按架构逻辑推的，不是从运行数据里总结的。

5. 参考

  • TypeSafe 官方文档 · API 契约、三种原语的定义，以及 confidence 是从概率分布算出的统计量
  • TypeSafe AI primer · RLCD 与 RLHF、RLVR 的并列关系，官方一手
  • TypeSafe Patterns · Intent Routing、Speculative Fan-Out 等模式的官方定义
  • jev-router · 给 Claude Code 与 Codex 做逐回合模型路由
  • LangChain TypeSafe 集成 · TypeSafeClassifier 与执行前拦截的 AutoModeMiddleware
  • Archer Hume 逆向工程 · 200 选项与 2 选项延迟相同、问题隔离实验、由代价推阈值的例子；作者自述为黑盒推测，非官方披露
  • SemIf · 单张 3090 复现同一接口，模型阶梯与共享 state 实测；项目自述为独立研究，与 TypeSafe 无关
  • mini-Jev · 直接读选项打分与生成 JSON 的对照实验，预注册
  • pi-jev · 编码 Agent 命令闸门的四个问题与实际阈值
  • Prefill — Computational Deep Dive · 读与写两段为什么耗时差这么多，A100 上 500 字符读约 50 毫秒、单字符写约 10 毫秒的出处
Related Posts