Jev 架构深度拆解：1 万次 API 调用逆推出的决策模型

你在 X 上看到的关于 Jev 的解读，八成都说偏了。

2026 年 9 月 17 日，作者 Archer 发了一篇标题很直白的文章——《Jev's Architecture Unmasked》。他花了一万多条请求，对 TypeSafe 的 Jev（也就是他们口中的 System One 模型）做黑盒探测，试图搞清楚一件事：一个不生成文本、直接吐概率的模型，内部到底长什么样。TypeSafe 既不开源权重，也不公开研究细节，所以这篇文章从头到尾都是逆向推测。

但它的价值恰恰在这里。作者把每一句结论的证据等级标得很清楚：哪些是 TypeSafe 自己公开说过的、哪些是他实验测出来的、哪些是纯推断。这种「把猜测和证据分开写」的做法，比一堆"我觉得它一定是某某架构"的暴论靠谱得多。

我读完最大的感受是：很多人把 Jev 当成"又一个更快的分类器"，其实它赌的是一个完全不同的问题——LLM 生成的置信度声明根本不可信，而决策系统恰恰最需要可信的概率。下面我把这篇长文的骨架和关键实验逐个拆开讲。

本文提纲

  1. 先说清楚：Jev 到底在解决什么问题
  2. 它的 API 长什么样：state、questions、候选答案
  3. 组件一：用 readout 结束推理，不做 decode loop
  4. 组件二：共享 state，隔离 questions
  5. 组件三：一条 causal backbone
  6. 组件四：让选项先互相影响，再选择
  7. 组件五：先训练分布，再算 confidence
  8. 组件六：稀疏容量，为什么八成是 MoE
  9. 组件七：把分支当批次调度，而不是对话
  10. 这套逆向的确定性分级，以及哪里会翻车

先说清楚：Jev 到底在解决什么问题

普通 LLM 会把「90% confident」当成一段文本来生成。它产出这几个词的概率，并不等于它对答案有 90% 的把握。可我们偏偏拿这套东西去搭风控、内容审核、工单路由、风险评估——花钱做逐 token 生成，然后把一句没校准过的置信度声明当成软件可以据以行动的概率。

Jev 的主张是把这两件事拆开：保留预训练 LLM 的知识，但把"生成的置信度声明"换成"从内部表示直接读出的决策概率"。这些概率是针对真实结果训练出来的。你给它共享的 state、若干 questions、以及每个问题的允许答案，它并行返回概率分布，不生成任何文本。

这一下同时解决两个问题：决策信号的可靠性，和产出信号时浪费的算力。

作者的探测结论大致是：一个因果 Transformer（很可能用了稀疏 MoE），被改造成做决策——共享 state 编码、隔离的问题分支、直接概率读出，取代文本生成。他在文中的原话是，黑盒 API 让"给幽灵盖上一层毯子、摸出大致轮廓"变得出奇地容易。

一句话总结这套设计的信息流：

MERMAID_BLOCK_0

state 编码一次进绿色格子（每一层保留的信息），每个彩色问题格并行构建、只 attend 到共享 state，问题之间互相看不到。readout 把每个问题最终表示直接变成答案概率，全程不生成文本。

它的 API 长什么样：state、questions、候选答案

作者给了一个示意请求（概率是编的，只是展示 API 结构）：

{
  "state": "My payouts have failed three times. The bank says everything is fine. Can someone please fix this?",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "payments": "Payout failures and payment processing",
        "account": "Login and account access",
        "other": "Something else"
      }
    },
    "escalate": {
      "type": "noul",
      "instructions": "Does this message require urgent human attention?"
    }
  }
}

一个合理的结果可能是：路由给 payments 0.91，而紧急升级只有 0.42。这是两种不同的不确定性——软件可以自动把工单路由出去，同时把升级交给另一套策略。这就是这套接口真正的意义：概率让下游策略变得显式。如果误升级成本是 1、漏掉紧急case成本是 9，那么只要 p(urgent) > 0.1 就升级。这个计算有没有意义，完全取决于概率在这个工作流里准不准。

组件一：用 readout 结束推理，不做 decode loop

第一个组件最简单：用预测头取代解码循环。

TypeSafe 的发布公告自己说了："Jev outputs all probabilities in parallel instead of autoregressively generating by token." 文档里暴露三类输出：有限选择（choice）、yes/no 决策、有序评分（score）。这些天然就是固定数值输出。

但作者发现一个容易骗过人的字段：API 依然返回 output_tokens，听起来像是"生成了多少 token"。它不是。对于 yes/no 问题，这个计数精确匹配一个公式：4 个共享 token + 每个答案 15 个 + 每个问题标识符的 token 长度。可 TypeSafe 文档说，这个标识符"不发给底层模型、也不用于推理"。一个会随模型根本没见过的文本变化的计数，只能是推理结束后、从序列化响应里算出来的。而且返回值不参与计算——答案是 0.0 和 0.01 成本一样，尽管每个数字位本来都算一个 token。

更关键的证据：这个计数背后的 tokenizer 跟测试的 192 个公开 tokenizer 都不匹配。它跟 Jev 自己的普通文本输入计数器一致，只在长串空白和标点时不同。所以 output_tokens 就是个计费字段，跟 Jev 是否生成文本无关。延迟也不跟它走：一个 200 选项的问题（1,911 output tokens）和一个 2 选项的问题返回得一样快，服务器耗时只随输入长度增长。

那 readout 具体怎么算？取最后一个隐向量 h，产出 logits：

z = W·h + b
p_i = e^{z_i} / Σ_j e^{z_j}

K 是允许答案的数量。W 把表示变成答案分数，softmax 把分数变成分布。yes/no 决策一个标量加 sigmoid 就够了。

有个细节很有意思：这些类别不必是固定概念（比如"payments"），而是选项槽——第一选项、第二选项、第三选项。分支负责给每个槽位赋予含义，应用代码再把概率映射回调用方的 option key。这样新产品不用为每个客户的标签重训一个头。

作者也提醒：这不等于 Jev 里有个单独命名的分类器模块。语言模型的词表头本身就是一个矩阵加 softmax，从这个矩阵里挑 K 个保留标签行，就能实现和专用 K 类头一样的计算。

要区分的是"读出概率"和"生成描述概率的文本"。生成的 "91%" 是 token 序列；分类器的 0.91 是预测分布里的一个条目。两者都可能校准很差，都不会因为格式而自动可信。

组件二：共享 state，隔离 questions

第二个决策点是：算力在哪里复用。

作者测到的最硬的证据之一，是 token 记账严格可加：一个最小 yes/no 问题用 268 个输入 token，两个用 276 个。这符合"公共前缀 + 问题后缀"的结构。

更有信息量的是把证据在两个区域之间搬动。state 一开始写"今天天气很好，公园里全是人"，然后兄弟问题里放了句"这个请求的秘密代码是 ZEBRA-7741"。探测问的是另一个问题里提到的代码是什么。结果：秘密在兄弟问题里时，概率是 0.00；把声明挪进 state，概率升到 0.90–0.92。

这个干预很有用：把声明跨过 API 边界搬动，就改变了它的效果。它支持"问题之间有行为隔离"以及"每个问题都能读共享 state"。但它没有暴露确切的 attention mask——分开的模型调用、树形 mask，或别的限制信息流的机制，都能产生同样结果。

服务侧测量补充了另一块拼图：问题数到 100 左右，服务器耗时几乎不变；超过之后稳步上升，而且按 token 算，问题文本的成本大约是 state 的两倍。这符合"state 只算一次、问题工作批处理"的模式。

Jev 还强制两个上限：每个分支（state + 一个问题）约 32,768 token，整个请求约 65,536 token。请求上限把 state 只算一次——一个 23k token 的 state 配 5,000 个问题也能塞下。如果每个问题都处理一份自己的 state 拷贝，这个请求就超过一亿 token 了。作者推测它塞进一条最多 2¹⁶ token 的打包序列，state 放一次、问题跟在后面，每个分支限 2¹⁵ 上下文窗口。

自然的实现是前缀 KV cache + 独立的因果后缀（prior art 是 Hydragen 和 DeFT）。这套设计还澄清了一个表面矛盾：隔离的问题可以在同一个加速器上一起评估——"并行"描述的是调度方式和答案之间没有依赖，不一定意味着一问题一 GPU。

组件三：一条 causal backbone

实验其实分不清因果解码器和双向编码器——两者的最终决策都能读到整个输入。作者还是假定它是因果解码器，理由很充分：Jev 的知识广度（MMLU-Pro 84.6%）需要前沿规模的预训练，而这个规模上每个模型都是因果解码器；TypeSafe 也把 RLCD 描述成对预训练语言模型做后训练。

至于底座是哪个预训练模型，tokenizer 不说。Jev 的 token 计数跟 415 次探测里测试的 192 个公开 tokenizer 都不匹配。它把每个数字单独拆开，先查整个 chunk 再合并：8 算一个 token，但 16 算四个。它的词表跟 OpenAI 的 o200k 很接近——所有 Jev 算作单 token 的字符串在 o200k 里也是单 token——但数字拆分和几处合并规则排除了 o200k 本身。最接近的公开匹配是 Qwen，415 个探测里一致 348 个。

那决策到底能读到什么？作者做了个参考卡实验：把一张参考卡塞进某个问题的选项里，让 Jev 选出条件被满足的选项。他测了两个参考值、全部六种选项排列，外加一个用 route = east/west 的第二模板，每个重复两次。对照组把参考卡放进共享 state。

结果非常有说服力：

参考卡位置 正确数
最前 12 / 16
中间 11 / 16
最后 16 / 16
移进 state 48 / 48

参考卡放最后时，每次试验都选对，正确答案的平均概率约 0.88。放最前或中间时，概率在 0.5 附近散得很开，尽管最终决策总能读到参考卡。作者说这是顺序敏感，不是恢复出了 attention mask。

最能说明问题的是换值对照：卡放最后时，只把 amber 改成 indigo，就改变了哪个更靠前的选项胜出——而那些更早的描述和 state 完全没变。一个"从每个选项自己的文本和 state 独立打分、再归一化"的模型，没有渠道让这个事实去改变早先选项的相对排序。结果支持存在一条让选项影响联合决策的路径。

组件四：让选项先互相影响，再选择

这是全文最漂亮的一个实验。在一个问题内部，证据指向另一条信息边界：备选项被当成有序列表一起读，后面跟一个决策位置。

为什么允许这种交互？像"以上都不是"这种选项依赖其他选项。普通选项也能澄清问题——"payments / account / other"和"bank / payment provider / customer"定义的是不同的决策。

最强的证据是一个无关选项实验。先给四个可能的支付失败原因：bank、provider、customer、unknown。然后追加第五个："坏天气导致的"。如果一个选项获得独立、不变的 logit、服务器用同样的 softmax 温度，那加第五个选项只会改变归一化，改不了两个已有选项之间的 odds（分母会约掉）。这给出了一个可证伪的预测。

作者在十个随机 block 里重复实验，把均值 log-odds 从 +0.38 打到 +0.11。十个 block 全部下降，平均变化 −0.28，描述性的 95% paired t 区间约 −0.36 到 −0.19。

这是反对"固定独立 logits + 不变 softmax"的证据。它没有唯一确定机制——当加入选项的描述从"坏天气"改成"野鸟"时，位移更小、不显著，所以也可能是 set-dependent 的温度。但一个能读到完整列表的 readout 天然解释了它：加一个选项就改变了它读到的上下文。FIRST 列表式排序方法就是这么干的。

有两种 readout 都符合证据：final-position head（从决策 token 的表示给每个选项槽打分）和 pointer-style scorer（把决策表示和每个选项自己的最终隐状态比较）。API 最多接受 255 个选项（2⁸ − 1），适合一个固定 256 槽的头——但这是请求校验强制的，不是模型本身。注入的假选项从没顶掉真选项，说明选项边界有文本无法伪造的标记。

代价在普通任务里也看得见：反转选项顺序会把一个技术支持分类的概率从约 0.84–0.89 挪到 0.93–0.96。对一个上线的决策策略来说这很要命——阈值卡在 0.9 附近时，标签和证据一模一样，动作却可能变。任何实现这套设计的系统，评测里都该放 permutation 测试。

组件五：先训练分布，再算 confidence

第五个组件是训练目标。直接数值输出省了解码，但便宜的概率仍然可以是坏概率。

校准问的是：给一堆 case 都打了 0.8 的 urgent 概率，是不是真有大约 80% 确实 urgent？它是跨 case 的属性。单个预测准不准，没法从这一次结果好不好看出来。

TypeSafe 把自己的训练方法叫 RLCD（Reinforcement Learning for Calibrated Decisions），发布会说它优化的是"System One 任务上具有认识论诚实的概率的答案"，公司 primer 把 RLCD 描述成从预训练语言模型出发的后训练路径。具体配方没公开。

作者提的自然目标是 log loss（−log p(y)）或 Brier loss。两者都是 proper scoring rules：在期望意义上，报告真实条件分布会让损失最小。Gneiting & Raftery 2007 给了形式化定义。不过 properness 不是部署保证——有限数据、模型局限、优化误差、分布漂移都会让校准不完美，Guo et al. 2017 就是讲神经网络校准问题和事后修正的。

实测数据：在 1,200 条 MMLU 样本上，十分位 ECE 是 0.0313，大多数预测挤在接近确定的位置（990 条落在 0.9–1.0 这档）。新生成的数学题给了额外变化：三位数乘法准确率 86.7%、平均 top 概率 0.83；两步文字题准确率掉到 32%、平均 top 概率也掉到 0.30。难题上模型更没底，这在方向上是好事。

还有一个关于 API 里 confidence 字段的、异常清晰的发现。官方的 Python adapter 对 Choice 的 confidence 是按这个公式算的：

c = (p_max − 1/K) / (1 − 1/K)

K > 1 时，三个选项、最大概率 0.8，算出来是 0.7。它衡量的是领先答案比均匀分布高出多少，不是另一个学出来的"答案正确"估计。训练产出预测分布，普通算术产出这个摘要字段——把这两个东西分开，能避免一个常见误解：分布很集中，也可能是自信地错。

组件六：稀疏容量，为什么八成是 MoE

作者预期 Jev 用稀疏 mixture-of-experts Transformer。在被选中的层，router 把每个 token 送过一小部分前馈网络，于是模型能存很多参数、却只激活其中一部分（Shazeer et al. 2017 的 conditional computation）。

稀疏专家从外部观测不到，但作者认为它是大概率选择：

  • prefill-only 的模型受算力限制，而这正是稀疏路由省的东西；
  • MoE 通常的服务成本大多消失了——没有逐 token 解码（那里内存带宽是瓶颈、多数专家反正都会激活），也没有长期 KV cache 和专家权重抢内存；
  • 测量数据也指向这个方向：Jev 处理约 30k token 用了大约 160ms；一个 dense 70B 模型在 8×H100 节点上需要约 1 秒，而活跃参数约 10B 的 MoE 能对上；
  • 近期最强的基座模型（DeepSeek-V3、Qwen3、GLM-4.5、Kimi K2、gpt-oss）全是 MoE。

作者很诚实地标明：这是推断，不是测量。专用硬件能让 dense 模型达到同等速度，benchmark 分数也可能高估了模型实际掌握的知识。而且重建里其他部分都不依赖它——换成 dense Transformer，接口、共享 state、隔离分支、readout 全都照旧。

组件七：把分支当批次调度，而不是对话

最后一个组件是服务引擎，把问题分支当成独立工作项：它们的后缀可以打包成 batch，同时读共享 state 的表示。应用代码再把数值输出和问题标识符对上、序列化响应。

测量揭示了重复相同答案之间的小差异，包括同一请求里的重复问题之间。这意味着不能假设 API 层是确定性的（数值 kernel、动态批处理、路由、或故意引入的随机性都可能影响直接 readout）。响应的 key 顺序也以少数几种固定模式变化，多 worker 不同 hash 序是个合理猜测——但这个侧信道定不出 worker 数、KV cache 在哪、用什么数值精度。

对这套架构重要的是：答案之间没有依赖链。模型不用等写完队列分类再开始估计紧急度。两者都依赖 state，谁都不消费对方生成的答案。

但依赖限制依然存在：如果后一个问题的确需要前一个的答案，应用就必须引入另一个决策阶段，或者把联合决策塞进一个问题里。共享上下文不消除工作流的逻辑结构。

这套逆向的确定性分级，以及哪里会翻车

作者自己把结论按确定性分了级，这点特别值得学：

  • 公开描述过：直接概率输出。
  • 可观测行为：问题隔离、选项顺序效应。
  • 越来越具体的解释：KV 共享、因果注意力、final-position 或 pointer readout、稀疏专家。

哪些实验能翻掉哪些结论：参考卡实验钉死了"决策能用放最后的选项"；假选项测试说明输入格式的花招伪造不了选项边界。要区分 readout 到底是槽头还是 pointer，需要一个 200 选项的中等难度任务；要确认稀疏专家，可能得等官方披露，或者超出 API 能给的证据。对校准来说，留出的工作流数据 + 漂移下重复评测比再刷一个 benchmark 分数重要得多。

还有几处得替作者说清楚的失效边界：

第一，这是黑盒逆向，不是官方架构。 所有机制——KV 共享、因果注意力、readout 形态、稀疏专家——都是"和观测一致"的解释，不是"被证明"的事实。作者反复强调：行为上的成功永远无法唯一确定一个 attention mask。

第二，延迟数字来自 x-envoy-upstream-service-time 响应头。 那是上游服务时长，包含未知的排队和执行边界，而且服务是共享的，不是隔离的硬件 benchmark。作者明确说本地 wall-clock 测量不作为架构证据。

第三，概率普遍按两位小数返回，重复问题共享条件、误差可能相关。 那位 −0.28 的 log-odds 位移来自"单个场景的探索性研究"，区间是按十个 block 算的 paired t 区间，请求噪声和 list-dependent 温度都还是潜在贡献者。

第四，MMLU 上的好校准是"在测试分布上"的结论，不等于未来任意客户工作流上的校准保证。样本选择、分箱、响应取整都会影响估计。

即便如此，作者的最终画像依然清晰：一条因果 Transformer，共享 state 前缀、隔离的问题后缀、listwise 选项处理、类型化数值 readout，以及朝预测分布对齐的训练。稀疏专家是大概率底座，但设计里其他部分都不依赖它。

它的价值来自把计算图和任务对上：一个决策服务需要读证据、比较允许的结果、暴露不确定性。Transformer 能做这件事，而不必先把每个决策变成一句话。

参考文档与链接

你觉得"不生成文本、直接吐概率"这条路，会成为决策类 AI 的默认形态吗？评论区聊聊你的判断。觉得拆得还算清楚，点个赞让更多人看到。

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。

posted @ 2026-10-17 09:40  iTech  阅读(3)  评论(0)    收藏  举报