Jev 决策模型调研：不写字的 System One

摘要

「让模型做判断」正在从「生成一段文字再解析」里被剥离出来，变成一个独立的模型类别。我们记录六个事实：

1. (1) Jev 是不写字的决策模型：TypeSafe 的 System One 旗舰，输入一段 state（文本 / JSON / 数组）加一组 questions，一次前向返回每个问题的类型化答案 + 校准概率——不生成任何文本。[E01]
2. (2) 三种原语覆盖绝大多数判分动作：Choice（多选一）、Score（按 rubric 打分，score = Σ i·p_i）、Noul（命题真假，0–1）。方法论一句话：「Atomic questions, composed in code」。[E01]
3. (3) 为什么要把判分从生成模型里拿出来：LLM-as-a-judge 慢（2–3 秒）、贵、结果飘；同一批样本上 Jev 单次约 0.44 秒、整套判断成本 $0.34（对手 $0.39 / $2.90 / $28.17）、结果方差低 92–913 倍。[E02]
4. (4) 能干啥：eval 裁判、模型路由、护栏与工具门控、上下文 / 记忆管理、分类分流，以及「三个 Yes/No 打通超级马里奥」这类通用决策。[E01,E02,E04]
5. (5) 最新进展是 Decision 3.0 与生态爆发：vLLM Semantic Router 发布 5 个 Apache-2.0 决策模型（0.85B–26.09B），d3 文本榜 64.1 登顶；社区库里已有 174 个验证工具、962 个核验仓库。[E04,E05,E06,E07]
6. (6) 自己的小模型已经能训：基于 Qwen3.5-4B（即 d3-mini 的底座）或更小的 Qwen3-0.6B，走「去 LM head + 候选头 + LoRA + 温度校准」四步；AgentJev-0.6B 已用 0.6B 在单卡训练，并在 Typed Decisions 上做到 79.25%。[E04,E08]

「是什么」见第 1 章，「为什么」见第 2 章，「能干啥」见第 3 章，最新进展见第 4 章，自训练路线见第 5 章。

1 是什么：不写字的 System One

一句话定义。Jev 是 TypeSafe 的旗舰模型，也是官方所称的第一个 System One 模型——你发送 state 和一组类型化问题，拿回代码能直接用的结构化答案。它不生成文本，这是理解全部好处的起点。[E01]

名字的来历。「System One」取自 Kahneman《思考，快与慢》：系统一是快、直觉、反射式的判断，系统二是慢、推理、生成式的思考。LLM 是系统二（写字、推理、解释），Jev 要补的是系统一——在几十毫秒内给出一个可设阈值的判断。[E01]

1.1 调用形状：state + questions → 类型化决策

调用简单到一句话：给它一段 state（可以是纯文本，也可以是序列化成稳定 JSON 的对象），再给它一组命名 questions，它返回每个问题的类型化答案和校准概率。当前 Jev 只接受文本输入（字符串 / JSON / 数组），图片、音频、视频尚不支持——这一点和第 4 章的 Decision 3.0 多模态能力形成对照。[E01]

两个关键性质：答案一定"合法"——选出来的一定是列表里的某一项，分数一定落在固定区间，所以不存在格式错误，也不存在幻觉；每个答案都带概率——用它当过滤门槛，高置信直接采信，低置信才升级人工或交给 LLM 细看。[E02]

1.2 一次调用，答完所有问题

原始响应长这样（POST /v1/systemone，模型 jev-latest）：

对同一个 state 上的多个问题，Jev 并行处理、相互隔离：加问题几乎不增加延迟。这不是"更小的 LLM"，而是另一种东西——它的能力边界是"从给定选项里选一个，或打一个分"，代价是复杂推理明显弱于 reasoning 模型，也不能写代码、聊天、做摘要。[E01,E04]

2 为什么：判分不该用生成模型

现在的 Agent 评测，判分环节十有八九是 LLM-as-a-judge：让一个前沿大模型读一段输出，然后生成一段 JSON，里面写着 {"score": 8}。这个做法能跑通，但三个毛病一直甩不掉。[E02]

第一宗罪：慢。judge 要「先生成、后解析」——先吐一段解释，再吐一段 JSON，然后在代码里解析。一次判分动辄 2–3 秒；一条样本判好几个维度就是好几倍。[E02]

第二宗罪：贵。每一步都在烧 token，而这些 token 花出去只为了得到一个布尔值，性价比极低。[E02]

第三宗罪：飘。同一个输入换个温度、换个 seed、甚至只是再跑一次，结果就可能不一样。于是常见场景出现了：你改了产品代码，评测分数涨了 3 个点，你以为是自己改得好——其实只是 judge 这次心情不同。更隐蔽的是格式塌陷：生成式输出偶尔漏字段、多字段、JSON 不合法，你还得写一堆容错代码去"抢救"。[E02]

2.1 分工：语言任务留给 LLM，决策点交给 Jev

把这件事想成两条生产线：生成模型输入文本、输出文本，它的活是"写"；决策模型输入 state + 问题、输出概率分布，它的活是"判"。「这条回答有没有幻觉？」是判断题；「给这段回答打 1–5 分」也是判断题。用生成模型做判断题，等于让一个作家去当裁判——他能写出一篇漂亮的判决书，但你真正要的只是那个"是/否"，而写判决书这一步既慢又贵，还引入了随机性。[E02]

DeepEval 官方博客把这套分工总结成一句话，很适合贴在评测流水线旁边：language tasks stay with the LLM; decision points go to Jev.

2.2 竞争假说：为什么会生成模型在判断题上会输？

至少有两个可检验的解释，现有证据还不能完全区分：假说 A（解码开销）——生成模型必须把答案写成一段话，再被解析回来，这中间的每一 token 都是浪费；假说 B（采样随机性与无校准）——生成式采样的输出没有概率语义，同一个输入两次跑可能不一致，也没有一个内建的置信度。[E02]值得注意的是，Jev 走的正是"一次前向、直接给概率"的路子，恰好同时消掉了这两个来源——这既支持假说 A，也支持假说 B，因此这两组证据本身无法把两者分开。能确定的是：结果方差低 92–913 倍这个硬数据，是"稳"的直接证据，而不是解释。[E02]

3 能干啥：把判断放进最热的路径

决策模型不是要取代 LLM，而是把"决策点"从生成模型里剥出来。下面是当前落地的六类场景——共同点是：这些判断原本要么写死规则，要么让大模型"把布尔值聊出来"再解析。[E01,E02,E04]

3.1 迁移的三条路径（以 eval 裁判为例）

你不需要推翻现有的评测框架，按现状挑一条路径即可：

迁移的核心动作只有一件事：把"生成一段评分文字"改写成"回答几个固定问题"。经验有四条：一个问题只问一件事；用 Noul 做二值门；用 Score 做 rubric（评分标准变成代码里的常量，不再藏在 prompt 里）；用 confidence 做门槛（允许歧义时可设三档：>0.65 判 yes、<0.35 判 no、中间标 borderline 单独看）。[E02,E03]

边界也要说清楚：需要"读长文本、给理由"的开放式判断（比如"这段代码设计是否优雅"）仍该用 LLM；system_one 模式下的分数是 Jev 派生的，和 LLM 链路的比值不可互换，迁移时应把它当成同一指标的两种裁判、各自看趋势；阈值要显式校准，别照搬 0.5。[E02,E03]

4 最新进展：Decision 3.0 与生态爆发

截至 2026-10，这条线上最重要的进展是 Decision 3.0——vLLM Semantic Router 团队把"路由决策"做成了一族开源小模型；同时 Jev Decision Index 排行榜给出了横向坐标，社区库也长出了规模。[E04,E05,E06,E07]

4.1 Decision 3.0：五个尺寸，一次返回一组概率

一共五个尺寸，全部 Apache-2.0，覆盖从边缘到数据中心的整条线。底座是 Qwen：27B 的 d3 建在 Qwen3.8-27B 上，其余四个建在 Qwen3.5 的 0.8B / 2B / 4B / 9B 检查点上——其中 d3-mini（4.54B）就是 Qwen3.5-4B，也是第 5 章自训练的直接对标。[E04]

除了尺寸，这一代还有两个变化：多模态输入——能读文本和 JSON，也能读图片（PNG / JPEG / WebP，每张最高 1.6 百万像素，一次可带多张，每个问题都能看到全部图片）；跑上 Mac——有人把小的几个尺寸转成 Core ML，决策不出机器、没有按次成本、没有网络往返。安装锁 transformers==5.17.0，加载需 trust_remote_code=True。[E04]

4.2 排行榜：Jev Decision Index 0.3.1

Decision 3.0 对标的是一块叫 Jev Decision Index 0.3.1 的榜（它排的是 TypeSafe Jev 决策系统的开源复现）。文本榜 2026-10-10、视觉榜 2026-10-09。[E04,E05]

这一代最漂亮的故事是「以小博大」：d3-flash（9B）拿到 59.0，直接超过 Decision 2.0 的 27B（55.9）；相比 Decision 2.0，公开套件的提升从 +8.0（27B）一路到 +15.1（0.8B）——越小的模型，进步越大。视觉上 d3 拿到 71.6（对手 Perplexity Decider v1.1 为 70.6）。[E04]

但要诚实读：d3 的数字是团队内部评估，其他对手用的是榜单实测；各档并不是全面领先——d3-lite 文本第一但视觉只排第三（41.1，落后 JPT-0.8B 的 42.1），d3-nano 视觉第一但文本输给 LiquidAI d1-3B（35.8 vs 40.1）。别把"9B 超过上一代 27B"直接读成"全面碾压"，选型还是得按自己的负载测。[E04]

4.3 生态：awesome-jev 与 962 个仓库

围绕 Jev 的社区生态在 2026 年快速长起来。awesomejev.org 收录了 174 个经"三重经验基准"验证的生产工具、935 个共识雷达候选，给出的平均反射延迟是 25 ms、成本优势 130×；jevbest.com 则从 962 个已核验仓库里做了分类。[E06,E07]

社区里已有一批高星项目：浏览器操作 browser-use/jev-ultrafast、上下文压缩 tamaratran/fast-jev-compaction、以及对标的开源实现（laya、NanoJev、agent-jev 等）。同时，awesome-jev 列表本身也已分叉出多份（awesome-jev-tools、awesome-jev-by-typesafe、awesome-typesafe-jev 等）。[E06,E07]

5 训练自己的决策小模型：以 Qwen3.5-4B 为例

这一章回答用户最实际的问题：怎么基于 Qwen3.5-4B 训一个自己的 decision 小模型。先说结论——路线是现成的，架构就三步（去 LM head、换候选头、加 LoRA），训练管线四步（合成数据、分层 LR、单卡 BF16、温度校准），社区已有 0.6B 和 2B 两份可复现的先例。[E08,E09]

5.1 为什么是 Qwen3.5-4B

Qwen3.5-4B 正好是 Decision 3.0 里 d3-mini（4.54B）的底座——它「兼顾速度与准确」，在 2016 个抓动作的规模上单卡可训、本地可跑，是一个甜点位置：小到方便做实验，又大到能真正干活。[E04,E09]如果你只想先跑通流程，可以先用 Qwen3-0.6B 级别的骨干把管线走一遍，再放大到 4B。[E08]

5.2 架构：去掉 LM head，加一个候选头

决策模型的架构和 LLM 只差一个头：取一个预训练好的 LLM 躯干，去掉 LM head（拿掉它生成文本的能力），换上一个小的候选头。两条已被验证的路线：[E08,E09]

• 排列等变头（permutation-equivariant head）——AgentJev-0.6B 路线：每个候选在其最后一个 token 处被读取，头对整个选项集合打分，选项顺序不会偷偷引入排名偏见；softmax 按问题计算。[E08]
• pointer head——Strands Decider 2B 路线：把每个选项位置的 hidden state 与 <answer> 位置的 hidden state 做打分对比；这个头只有一百万多一点参数，躯干用 rank-16 LoRA 微调。[E09]

两者共享的工程属性是零解码：隐状态直接到 logits，没有输出词表步骤，所以没有 JSON 需要修复。AgentJev 还做了共享前缀复用——状态只编码一次，同问题的所有选项从该前缀分支，64 选项场景下中位延迟从 609.65ms 降到 298.91ms，骨干 token 操作降 92.4%。[E08]

5.3 训练管线：四步

5.4 小模型真的够用：AgentJev-0.6B 的成绩

最反直觉也最聪明的一步，是不靠人工标注，靠"已知分布的概率环境"程序化生成训练数据——分布已知，标签就精确、不可能出错。[E08]这条路线的结果证明小模型是够用的：

AgentJev-0.6B 在 Typed Decisions 上做到 79.25%（Laya 77.00%，bootstrap 95% 区间 [+0.65, +3.90] 优势；TypeSafe Jev 1.13.0 零样本为 72.7%）。[E08]而 Strands 团队选 2B 的另一个理由是：20 亿总参数像是一个甜点位置——他们在 JevBench 的简单任务上做到了 100% 正确，本地中位延迟约 115ms（RTX 3090）/ 153ms（M3）。[E09]

5.5 上手建议

如果你想训自己领域的决策模型，路径很具体：保留架构（Qwen 小骨干 + 候选头）与训练管线（分层 LR + 温度校准），只换掉数据生成——比如你的领域是工单分类，就让 synth.py 生成带已知 gold 的工单场景。[E08]单卡从 0.6B 起步，跑通后再放大到 Qwen3.5-4B。

注：上例取自 AgentJev-0.6B 的官方用法 [E08]；放大到 Qwen3.5-4B 时，训练配置、显存与批大小需按你的硬件重新标定。

6 方法、数据来源与局限性

6.1 方法与数据来源

事实来源。Jev 的官方定义与三种原语取自 docs.typesafe.ai（introduction / concepts/system-one）[E01]；延迟、成本、方差来自 LangSmith 的官方对比，经本号《把 Agent eval 的裁判从 LLM 换成 Jev》整理 [E02]；Decision 3.0 的模型表、底座、延迟与 Core ML 数据来自其官方发布 [E04]；排行榜为 Jev Decision Index 0.3.1（文本榜 2026-10-10）[E05]；生态规模为 awesomejev.org 与 jevbest.com 的公开计数 [E06,E07]；自训练两份先例为 AgentJev-0.6B 与 Strands Decider 2B [E08,E09]。

读数日期。时效数据均标注采集时间；榜单与生态计数属于会迅速变化的量。

6.2 局限性

榜单口径不统一。Decision 3.0 的 d3 分数是团队内部评估，竞争对手用的是榜单实测数据；两类数字严格来说不可直接比较。本报告在 Figure 4.1 中并排展示时已标注，但读者引用具体分值前应回到原始口径。[E04]

「9B 强于上一代 27B」是特定基准上的结论。它在某些任务上很强、在另一些上未必（d3-lite 视觉第三、d3-nano 文本落后），不等同于全面领先。本报告不把它主张为通用结论。[E04]

生态计数含噪声。962 个仓库、174 个验证工具都是社区自组织的统计，包含大量低质、重复或刚起步的项目，"数量"不等于"质量"或"采用度"。[E06,E07]

训练教程是"可复现的路线"而非逐行官方 recipe。五步管线整理自 AgentJev-0.6B 的开源训练代码与其说明 [E08]，并对照了 Strands Decider 2B 的架构描述 [E09]；具体的超参、数据配比会随领域变化，本报告未在 Qwen3.5-4B 上亲自复现。[E08]

样本偏差。本报告以官方文档、官方博客与 GitHub 生态为主，偏英文与开源社区；闭源的商业决策模型（如各云厂商的内部 judge）只在机制层面提及。

数据速查表

本文提到的决策模型一页对照。

榜单分为 Jev Decision Index 0.3.1（文本 2026-10-10）；Typed Decisions 为 400 cases / 2000 questions。口径差异见第 6 章。