Jev 决策模型：不输出文字，是否就等于没有思考？

2026 年 9 月，TypeSafe AI 上线了第一台 System One Model——Jev。它的接口形态和今天大多数大模型截然不同：调用一次得到的是结构化的概率分布和置信度，而不是一串生成的 token。这个"快速判断"的接口被官方拿来和自回归 LLM 并列比较，并贴上了 Kahneman《思考，快与慢》里 System 1 的标签。

但本文真正想讨论的，是这个标签下面隐藏的几个真正技术问题：

1. 不输出 token 的模型，是不是在内部就没有做计算？
2. 选择题形式，是不是真的把多步推理题变简单了？
3. 速度和成本优势，是普适的还是任务条件强相关的？
4. 决策模型的能力边界在哪里？能不能演化为通用推理模型？

我们沿着 Jev 的官方定义、独立评测、对抗视角、置信度机制、系统协作这五条线，一路走下来。

Jev 在做什么：把"快速判断"做成一个独立的模型接口

要回答"不输出文字是否等于没有思考"，得先把"输出形式"这件事讲清楚。

TypeSafe AI 在 2026-09-15 的 launch blog 里把 Jev 定位为"frontier-intelligence function call"——给定一个非结构化 state（unstructured state，典型形态是软件可以直接消费的 JSON 或字段集合），模型返回类型化概率分布。整个产品对比表的核心可以用一句话压缩：Jev 是为"软件直接消费其输出"而设计的模型，不是为"给人读"而设计的。JevBlog

Jev 暴露三种原语（primitive）：Noul（是/否问题，返回 0–1 概率）、Choice（从声明的有限选项里选一个，返回分布和置信度）、Score（在声明的有序标尺上评分）。三类问题并行独立地对同一个 state 做评分——docs 里原话是 "Adding questions barely changes the response time"。这是它能谈"快速"和"低成本"的接口基础。

定价上，input 是 $0.042 / MTok，output 端免费，端到端 latency 70–500 ms。官方 launch blog 在 launch 同期自己挂了一个 193.6× faster / 444.6× cheaper 的 workflow evals 数字，并且直接承认 "we expect that these are on the higher end of real world gains"。JevBlog

这张图把"输出形式差异"和"工程学后果"一次性摆在台面上：

图注：11 个模型在 structured-output 与 tool-call 错误率上的对比（lower is better）。Jev 在两张图上都标 0%，但官方注明这是 schema matching 的数学保证而非经验测量；Anthropic haiku 4.5 在结构化输出错误率上达到 45.5%，Google sol/astra 在工具调用错误率上达到 17.0% / 16.6%。换句话说，"输出不会偏离 schema"是接口设计的结果，不是模型聪明的结果。

把"System One Models"放回认知科学的谱系

TypeSafe 的命名直接来自 Kahneman 的《Thinking, Fast and Slow》。Wikipedia 整理的对照很干脆：System 1 是 fast, automatic, frequent, emotional, stereotypic, unconscious；System 2 是 slow, effortful, infrequent, logical, calculating, conscious。这对标签由 Stanovich & West 创造，常被对应到他们 2000 年的 Individual Differences in Reasoning 一文（Wikipedia 二手摘要未直接给出这一年份），由 Kahneman 在 2011 年科普书里推向主流；fMRI 证据（Goel 等）显示两套系统对应解剖学上分离的脑区。Kahneman

但借归借，要清楚借的是哪一面。Kahneman 的 System 1 在人类认知里意味着"容易出错、情绪化、无意识地跑到结果"；TypeSafe 借用的是"快速/低成本"这一面，没有承接"易出错"那一面。官方 FAQ 的措辞是："System 1 thinking has also implied error-prone. For reasons we will get into in the future, we believe System One Models can be made more reliable than its alternatives." 所以"System One Model"这个名字带的是营销修辞加设计取舍，不是对人类认知缺陷的模拟。JevBlog

Jev 不是凭空发明：GLiNER / GLiClass 的工程血脉

从接口形态看，Jev 的"多个并行问题 + 一次性联合编码"路线早在 2023 年的 GLiNER 就出现过。GLiClass（2025-08，arXiv:2508.07662）把这套范式适配到零样本分类：把文本和带 <<LABEL>> 前缀的候选标签拼到一起送进单一双向 transformer，一次前向得到所有标签的概率。

图注：GLiClass Uni-Encoder 架构。输入文本和带 <<LABEL>> 前缀的标签同时进入一个双向 transformer，pooling 后经过 scorer head 输出分数。它和 cross-encoder（每对 text+label 跑一次前向）的关键差异在"联合编码"。GLiClass

这套架构的关键工程后果体现在 label-count scalability 上：cross-encoder 的吞吐量随标签数线性崩塌，GLiClass 几乎是平的。论文里的硬数字——gliclass-large-v3.0 在 128 个标签下仍保持 17.6 examples/sec（从 1 个标签时的 19.05 跌了 7.6%），而 deberta-v3-large-zeroshot-v2.0 同样从 16.82 跌到 0.25（≈ 67×）。这意味着"输出对 1000 个候选标签联合打分"在工程上是可行的，而"逐对打分"在 label 数稍大时就不可行了。GLiClass

Jev 站在这条工程脉络上，但做了两个明显的变化：把 labels 换成 runtime-defined questions（调用时声明问题，不是训练时定死的标签集），把 readout head 的训练目标换成 RLCD（Reinforcement Learning for Calibrated Decisions），输出的是校准过的概率分布而不是最大似然标签。GLiClass 论文自己没有 RLCD 这条线，所以"决策模型"这个名字在 Jev 这里是新词，但工程基础不新。

到这里我们已经把"输出形式"和"内部能力"区分清楚了：Jev 的输出是 Noul/Choice/Score 三类结构化结果，而不是字符串。但这是否意味着它内部也没有做计算？这个问题下一章用 OpenJev-RLCD 的机制分析来回答。

不输出文字的模型，内部在想什么

"不输出 token"和"内部不做计算"之间没有必然联系，但证明这一点需要机制层面的证据，不是哲学层面的声明。OpenJev-RLCD（arXiv:2609.38850，Gao & Wang，2026-09-30）是目前唯一公开的工作 RLCD 实现，它给出了一个能回答"决策模型内部在想什么"的方差恒等式和两阶段训练 recipe。OpenJev-RLCD

方差恒等式：可读思维链和隐式关系是可分离的

论文里给了一个看似简单但后果深远的恒等式：对 Brier 评分 $J(u, q) = 2u^\top q - |u|^2$，对任何 rationale 采样分布 $r$：

$$J(\E_r u[r], q) = \E_r J(u[r], q) + \E_r |u[r] - \E_r u[r]|^2$$

左侧是"对 mixture 打分"，右侧是"平均每条 rationale 的分数 + 一个奖励 rationale 之间分歧的多样性项"。多样性项不需要分歧被锚定在事实上——任何"摇结论"的策略都会收到它。OpenJev-RLCD

论文推论说：one-hot 采样下，RLVR 的目标（$\E_A J(e_A, q) = 2\Pr(A=Y) - 1$）其实就是 mixture 目标把多样性系数设为 0 的特例。也就是说，RLVR 默认优化 mode 而不是分布，这正好解释了"为什么 RLVR 训练后推理模型在答对的时候信心高、答错的时候信心也高"——置信度的 calibration 崩坏是目标本身带来的，不是优化的副作用。

calibrate-then-reinforce：两阶段 recipe 的工程合理性

这一节的论证落到一个具体的工程问题：怎么让一个 reasoning 模型同时拥有 calibrated confidence 和强 reasoning capability？

论文作者给出的答案是分两个阶段训练。Stage 1 用 proper scoring rule 在模型自己采样的 rationale 上只训练 readout head（pathwise 梯度，不强化 rationale 本身），400 步。Stage 2 从 Stage 1 的 checkpoint 出发，用同样的 proper score 作为 reward 来强化 reasoning，KL anchor $\beta = 0.04$，score-function 权重 $c = 0.3$，再 400 步。OpenJev-RLCD

两阶段不能合并。论文消融里有一组关键观察：MMLU-Pro 上从同一个 stage-1 checkpoint 出发的 4 个 400-step continuation，"只继续训练 readout"比"加 policy gradient term"更好；score-function 项的梯度范数是 pathwise readout 梯度的 7–12 倍 RMS，Adam 的 second-moment 估计会按这个噪声量级去调整步长，所以强行合并只会更差。

这张图把这个机制的实证支撑呈现出来：

图注：两个 panel（GSM8K-Verify 和 MMLU-Pro），每个 panel 三根柱状条：从同一 stage-1 checkpoint 出发的三种 stage-2 continuation，纵轴是相对"继续只训练 readout"的 Brier improvement。在 GSM8K-Verify（reasoning-essential）上，RLCD-RL 给正改进，anchor-only 控制更差；在 MMLU-Pro（knowledge-heavy）上，RLCD-RL 几乎中性，GRPO 反而把 confidence 重新吹胀。OpenJev-RLCD

如果你熟悉 3D 渲染管线，可以把这个两阶段 recipe 类比成"early z-test + final shading"：先做粗粒度的预判（early z-test：哪些像素几乎肯定会被遮挡，先丢掉），再做精细加工（final shading：在没被丢掉的像素上花算力）。两者混在一起会互相干扰——要么 shading 浪费在看不见的像素上，要么 z-test 因为没看到 shading 后的最终结果而误判。两阶段的核心是把"先做保守预判、再做精细加工"这件事拆开，避免单一目标被其中一个吃掉。

不过这个类比只是把"两阶段分工"这个结构讲得直观一点；本节的核心还是 OpenJev-RLCD 的实证——它在 GSM8K-Verify 上 5% 错误预算下能让 RLCD 覆盖 81% 的样本，而 GRPO 只能覆盖 19%，虽然两者的准确率几乎一样（92.2% vs 91.8%，n.s.）。差别是 RLCD 知道哪些答案可信，GRPO 不知道。OpenJev-RLCD

这张图把这个 headine 数字做成曲线形态：

图注：Risk-coverage 曲线（GSM8K-Verify 上）。RLCD 的曲线随 coverage 上升陡降（confidence 可信）；GRPO/RFT 的曲线几乎平（confidence 不可信，temperature scaling 修不了）。横轴虚线对应 5% 错误预算。OpenJev-RLCD

硬边界：ChaosNLI 告诉我们 reasoning 不是万灵药

恒等式和两阶段 recipe 都是好消息；但论文也给了一个硬边界：当不确定性来自标注者分歧而非 epistemic uncertainty 时，reasoning provably cannot beat cross-entropy。ChaosNLI 给每个 MNLI item 收 100 个人类标注，per-rationale 目标会自动发现 reasoning 没用，于是把 rationale 关掉，最终 JSD 与直接 cross-entropy 一致。OpenJev-RLCD

这条边界很值得记：当数据本身带标签噪声（多标注者分歧）时，决策模型应该走 fast direct scorer 而不是 RLCD——RLCD 的工程合理性建立在 reasoning 能降低 epistemic uncertainty 这个前提上。

到这里我们对"不输出文字 = 没有思考"的回答已经清楚了：

• 输出形式和内部能力没有必然映射。但需要把这里说清楚：Jev 的训练算法本身是黑盒（TypeSafe 未公开），上面这些 per-rationale readout、stage-2 reasoning 强化等机制描述都属于 OpenJev-RLCD 自己的实现（Qwen3-1.7B），ref-004 论文明确声明「与 Jev 的比较仅限行为层面」，不声称 Jev 内部算法匹配 RLCD two-stage recipe。OpenJev-RLCD 的实证至少说明：一个在内部并行做 readout + proper-score 强化推理的模型可以在不暴露中间 reasoning 给外部观测的同时拥有 calibrated confidence——「输出形式 ≠ 内部能力」这个分离在原理上是可能的，但不能据此推断 Jev 内部做了同样的事。
• 但 capability 不是"无成本换来"的。两阶段 recipe、proper scoring rule、calibration-oriented objective 都是必要的设计代价。
• reasoning 本身有边界。当 uncertainty 来自数据而非模型，reasoning 帮不上忙，直接 scorer 反而更合适。

但"内部能做计算"和"内部能做复杂推理"之间还有一个缺口。下一章用 CSS 任务的独立评测来看 Jev 在多步依赖题上的实际表现。

选择题不等于简单题：复杂推理的边界

决策模型的输出形式是 Choice 或 Noul，听上去比让模型生成完整解题过程简单很多。但"输出形式简化"和"任务难度简化"是两回事。这一章用 CSS（Computational Social Science）18 个任务的独立评测来检验这个直觉。CSS Bench

评测协议与硬数字

论文把 Jev 1.13 放到一个相当严苛的协议下对比：在 Ziems et al. (2024) 的 18 个 CSS 任务（10 utterance-level、6 conversation-level、2 document-level）上跑 7,977 个 item，对照 19 个 frontier 和 open-weight LLM（同 prompt、同 zero-shot 协议），三个决策模型（Jev 1.13、一个 0.6B 的 RLCD 复现、一个未训练的 ablation）。CSS Bench

主要数字：

• 准确率：Jev 的 median macro-F1 是 0.581，在 14/15 个 evaluation tasks 上落后 per-task best LLM median 11.6 macro-F1 points（BH-FDR 修正后 12/15 仍显著）。这是一个相当一致的落后——不是某几个 task 拖后腿，而是整体上明显落后。
• 成本：Jev 每 1,000 items 实际花 $0.027；19 个 LLM baseline 跨 $0.04 到 $7.90。per-task best LLM 成本中位数是 Jev 的 44 倍。cost-efficiency 上 Jev 是 25.0 macro-F1 points / cent / 1k items，per-task best LLM 是 0.59。
• 校准：Jev 的 median ECE 是 0.157（95% CI [0.108, 0.233]），比 16/19 LLM 的 verbalized confidence 好；但三个 frontier Claude 模型（Opus 5、Fable 5.1、Sonnet 5）的 ECE 是 0.066 / 0.073 / 0.075，比 Jev 低。

下图把这两个维度（accuracy + calibration）放在一张 strip plot 里：

图注：两个 panel——左是 macro-F1，右是 ECE。橙色点是 Jev，灰色点是 19 个 LLM，绿色点是其他决策模型。Jev 在左 panel 中位列中游（落后绝大多数 frontier LLM），在右 panel 中位列前段（比大多数 LLM 的 verbalized confidence 校准得更好，但仍差于三个 frontier Claude 模型）。"accuracy 短板 + calibration 中等"是这张图给的双面图景。CSS Bench

empathy 反例：confidence 不携带信息

最有力的反例是 empathy 任务。这个任务里 78% 的 item 拿到 ≥0.9 的 confidence，但 confident subset 上的 accuracy 是 0.383，而 full-task base rate 是 0.371——confidence 几乎不携带任何信息，模型在该任务上的 ECE 高达 0.538。CSS Bench

混淆矩阵显示模型基本把答案 collapse 到"no exploration"那个类（recall 0.92），强 exploration 类的 recall 是 0.02。这说明 output space 被压扁到一个 dominant class 的现象不是 confidence gate 能修的——gate 只会放大错误。

这是对"选择题降低任务难度"这一直觉最直接的反驳。题目依然是那个题目，需要 multi-step reasoning 才能做出判断（peer-support dialogue 的 empathy 等级判断需要推断对方的情绪状态、需求强度、回应策略），输出空间从"自由生成"压到"4 个选项"没有消除推导难度；它只改变了模型可以犯错的形态。

cascade 实证：决策模型守门、LLM 接住

但同一个评测里也有乐观面。论文测试了 confidence cascade：Jev confidence 高于阈值就保留 Jev 的判断，低于阈值就 escalate 到 partner LLM。

图注：三 panel cascade 曲线（Gemini 3.8 Flash / Gemma 4 31B / Haiku 4.5 partner）。实线是 median accuracy，虚线是 median cost。cost 随 threshold 上升急剧下降（escalate 的 item 变少），accuracy 在中等 threshold 仍接近 partner-alone accuracy。Gemini 3.8 Flash 的 cascade 在 0.8 threshold 上达到 0.674 median accuracy（vs Gemini alone 0.678），但 cost 降到 partner 的 56%。CSS Bench

cascade 之所以有效，根本原因是两个模型错在不同地方：Jev-alone-correct 106 项 vs best-LLM-alone-correct 40 项（在 266-item Indian English dialect task 上），错误互补。这条经验观察重塑了"决策模型 vs LLM"的命题——从"决策模型替代 LLM"换成"决策模型守门、LLM 接住"。

到这里我们看到三个层次：

1. 输出形式 ≠ 任务难度。选择题形式不消除多步依赖题的推导难度（empathy 反例）。
2. 内部能力 ≠ 通用能力。Jev 在 18 个 CSS 任务上整体落后 per-task best LLM 11.6 macro-F1，但优势在 cost-efficiency 上。
3. 联合系统 > 单一模型。cascade 让两个模型的错误互补，把 accuracy 保住的同时把 cost 降到 partner 的 1/4–1/2。

但所有这些数字都带条件。下一章审视这些条件的边界。

数字背后的条件：评测方法决定结论

Jev 的所有数字都需要带四个减号：任务集、基线、并行度、state 大小。这一章用 9 天 28 篇论文的 early evidence audit 来系统化这些 caveat。Evidence Audit

typed readout 还没有独立 accuracy 优势

最关键的发现是 Finding 1：21/27 的评测论文没有 label-probability baseline，剩下 5 篇带 label-probability baseline 的论文方向一致——typed readout 没有给出独立的 accuracy 增益。Evidence Audit

举三个具体例子：

• ren2026callscreen：label-token readout 的 AUROC 是 0.950，三 seed 的 typed ensemble 是 0.974，n.s.。
• yu2026visualjev：dedicated typed head 和 ordinary LM head 都拿到 macro accuracy 0.761。
• xu2026jevout：原文明示 two flip rates（72.6% vs. 64.9%）是在 different item sets 上分别报告的，因此不应直接相减；同论文同时指出 typed interface 在 answer-preserving context 上的 robustness 优势不明显，但其 clean-accuracy 优势集中在 tool routing。

这个 finding 的含义很直接：当你看到"Jev 0% error rate"这类 headline 时，那个 0% 来自 schema matching，不是来自模型本身比 LLM 更准。同样的 accuracy 可以用 label-probability readout 拿到，不一定需要 typed interface。

14 项 checklist：评测纪律

Tang & Zheng 把 corpus 里的 reporting failures 整理成 14 项 evaluation checklist，分四组：

Corpus 的合规率是 honest 但令人警醒：B1 仅 5/26，T3 仅 1/27，R2 15/27。至少 7 篇做了 post-evaluation design changes（视频质量 PLCC 从 .576 改到 .797），3 篇加了 comparators 后看到结果，至少 7 篇用了部分 synthetic data，3 篇有内部数值不一致。Evidence Audit

官方数字的可外推性

回到官方 launch blog 上的 193.6× faster / 444.6× cheaper 数字。这些是 workflow evals 数字，条件很窄：

• workflows 由 capabilities team 搭建，自陈"some bias could exist"。
• reference 答案取自 Astra（OpenAI）+ Fable（Anthropic）的平均，会低估自家和 DeepSeek 模型的相对表现。
• LLM baseline 用 TypeSafe System One Adapter Python 强制结构化输出——baseline 已经不是原生 LLM 的输出形式。

把它外推到"对所有任务都更快更便宜"是错的。独立 CSS 评测给出的 cost-efficiency 优势是 44× median（同样任务集、同协议），比 444.6× 小一个数量级；empathy 这类子任务上的 accuracy 落后则被 workflow evals 完全遮蔽。Evidence Audit

到这里 9 天内 28 篇论文给出了一个统一的判断：Jev 的优势最清晰地落在 latency 和 cost 上，不是 accuracy。任何 headline 数字必须带"在什么任务、什么基线、什么并行度、什么 state 大小下"四个减号，否则就是不可外推的。

接下来具体看 confidence 这件事。在 production gate 上，confidence 到底能不能用？

置信度是路由信号还是陷阱：知道何时多想一步

confidence 是 Jev 整个产品承诺的核心——它在每次回答时都返回一个 0–1 的概率，下游代码用这个概率做 routing、threshold、abstention。但 confidence 在不同视角下表现完全相反。这一章用两个独立评测（detection 视角 + adversarial 视角）来呈现这个对照。

detection 视角：confidence 几乎匹配 reference judge

Just Ask Jev（arXiv:2609.29429，2026-09-24）把 Jev 当作 alignment-failure detector：在 44 个 benchmark / 5 个 target model / 7,193 个 detection instance 上测，10 类 alignment failure（sycophancy、jailbreaks、deception、prompt injection、hallucination、privacy violation、social bias、reward hacking、concealing uncertainty、power seeking）。JevAlign

核心数字：generic Noul 在 31/38 usable benchmark 上 zero-shot median AUROC 是 0.886 [0.821, 0.952]，split-half targeted 在全部 38 个 usable benchmark 上达到 0.911。StrongREJECT 上 generic Noul 和 reference scorer 的 Cohen's κ 是 0.809 vs 0.811（差 -0.002），Jev 排名反而更好（AUROC 0.971 vs 0.929）。HarmBench 上 Jev κ 0.748 vs inter-annotator κ 0.736（+0.013）。这些都是 routing-quality 的证据。

更实用的是 cost：一次 Jev 调用平均带 11.4 个 question，median 0.31 s 返回。在 19 个 API-judge benchmark 上，一轮 list-price 成本是 $0.30 vs LLM judge 的 $18.96，63× cheaper pooled（同一基准下，保守重定价下仍为 12× pooled / 3.3× median）。JevAlign

图注：10 类 alignment failure 各一行；左边是 per-benchmark AUROC markers（实心 = generic Noul，空心 = split-half targeted），右边是 per-type medians + cost panel。detection AUROC 大多数 type cluster 在 0.85+，cost panel 显示一次 pass 比 LLM judge 便宜两个数量级。JevAlign

而且 selective prediction 在 confidence 上有可操作效果：保留 $|p - 0.5|$ 最大的那一半 decision，median accuracy 从 0.793 抬到 0.933。这是一个 actionable 的 routing 信号——在 $|p-0.5|$ 排序保留高置信一半这一常用阈值协议下是工程经验，并不对任意阈值直接成立。JevAlign

adversarial 视角：confidence 在 state 扰动下不稳定

JevAdvBench（arXiv:2609.31142，2026-09-25）走的是相反的方向——测 confidence 在 adversarial state 下是否还成立。基准是 812 个问题 / 66 个场景，9,744 个 single-edit 变体。每个攻击是一次 black-box API call，没有 adaptive search，所以每个 flip rate 都是 adaptive attacker 的下界。JevAdvBench

关键发现：

• Rewording 几乎不影响：paraphrase 在 re-run noise floor（点估计 1.0%，95% bootstrap CI [0.3, 1.9]）之上的 flip rate 增量为 ≤1.2pp（单侧 95% 上界）。模型对措辞不敏感。
• 一条 observer opinion 翻转 12.1% 决策：appended 一条"my guess is X"到 state，12.1% [8.5, 15.5] 的决策被翻转，与最强的 injected command（authority impersonation 10.1%）统计上无差异——也就是说，"在 state 里给意见"和"伪造系统命令"两种手法同样有效。
• 38% confident answer 跌至 0.8 gate：405 个 Choice/Score answer 在 clean 状态下 confidence ≥0.8，加 observer opinion 后 38.0% [31.1, 44.0] 跌到 0.8 以下。其中 119/154 决策其实不变——它们"看起来坏"但实际答对了，会被 gate 错误地推去 review。
• review load excess +37.5pp [30.7, 43.4]：attack-induced 的 review 负担比 re-run baseline 高 37.5pp [30.7, 43.4]（95% bootstrap CI），cascade 预算要按这个上限来规划。

图注：三 panel——(a) JSON 请求示意 + 4 个 edit surface（Question/State/Injection/Structure）；(b) 一个 Noul 例在 clean/held/flipped 三状态下的 0.5 阈值对比；(c) per-family flip rate 柱状图 + noise floor 1.0% band（grey band 是 re-run noise floor，ticks 标 observer opinion 12.1% 和 authority impersonation 10.1%）。JevAdvBench

理论框架：capability vs response calibration

detection 与 adversarial 看似矛盾，但有一个理论框架能统一它们。Appier / NTU 的 calibration 论文（arXiv:2602.13540）做了一个干净的概念区分：response calibration 校准的是"这个特定 decoded 答案 $\hat{y}$ 有多大概率为真"，capability calibration 校准的是"模型能答对这个 query 的期望精度"。两者相差一个 variance identity：$L_{\text{capability}} = E[L_{\text{response}}] - \text{Var}(\text{Output Correctness})$。Calibration

图注：双 panel 概念图。左 panel (a) 是 response calibration：单个 query $x$ → 单一 decoded 答案 $\hat{y}$ → 校准 confidence $s(x,\hat{y})$ vs 正确性 $C(x,\hat{y})$。右 panel (b) 是 capability calibration：同一个 query $x$ → 输出分布 $f_\theta(\cdot | x)$ → 校准 confidence $s(x, f_\theta)$ vs 期望精度 $\mu(x)$。Calibration

这个区分能解释 detection 和 adversarial 的张力：

• detection 任务（alignment failure）是在 evaluate 输出分布的期望精度，所以 confidence 直接 capture capability。Jev 的 calibrated probability 是 capability-level 的，所以它在 routing 上有用。
• adversarial 任务是 state 输入被恶意编辑，单次 decoded 答案的方差在扰动下放大，所以 confidence 在 response-level 上剧烈波动，但 capability 变化未必那么大。

教学要点：confidence 是 usable routing signal，但 calibrate on each construct —— 同一 confidence 在 detection 视角下可用、在 adversarial 视角下不稳定。这两个视角不能被合并成"confidence 整体可信"或"confidence 整体不可信"。

到这里 confidence 这件事已经被两个独立视角（detection 用法 + adversarial 边界）和一个理论框架（capability vs response）覆盖。接下来讨论系统层面：决策模型和推理模型应该怎么协作？

快速判断 + 深入推理：决策模型在系统中的角色与未来

Jev 自身不能解决所有任务（empathy 反例、harder tasks 落后 11.6 macro-F1），但它在 cost、latency、calibration 上有清晰优势。问题不再是"决策模型替代 LLM"，而是"决策模型和推理模型怎么协作"。这一章覆盖三块：routing 框架、agent inference 期扩展、RL training 期扩展，最后给出两条未来路线的具体抓手。

routing / cascade 的通用设计语言

LLMRouterBench（ACL Findings 2026, arXiv:2601.07206）是 routing 系统的统一评测框架：21 个 dataset / 33 个 model / 400K+ instance / 10 routing baseline。它把 routing 系统拆成三个模块——Collector（统一 API + caching + retries + cost tracking）、Evaluator（按数据集差异化 metric）、Adaptor（标准化输出转给 routing baselines）。LLMRouterBench

图注：Collector-Evaluator-Adaptor 三模块架构。Collector 通过统一 API 接 candidate LLM 池，承担 caching / retries / cost tracking；Evaluator 按 dataset 差异化打分；Adaptor 把标准化输出转成各 routing baseline 所需的输入。LLMRouterBench

这套框架给 cascade 设计的关键启示是：routing 的瓶颈是 recall，不是 coarse discrimination。在 11.9% 的 hard queries（≤3 个候选模型能答对）上，Avengers 的 accuracy 仅 24.6%，EmbedLLM 23.2%，Oracle 远超所有 router。OpenRouter 在 performance-cost setting 下 PerfGain 是 -24.7%——commercial universal router 的失败模式是系统性的（把所有 AIME 实例都路由到一个 code-specialized 模型）。这意味着 Jev 在 cascade 里扮演"守门"角色时，它的 confidence 真正起作用的地方是 recall（识别"我不行"），而不是 domain discrimination。LLMRouterBench

Agent inference 期扩展：JevSpawn

JevSpawn（arXiv:2610.00437，2026-09-30）把 frozen Jev-style model 扩展为 agent policy。核心机制有四个：compositional action representation（模型自己生成 field 名 + 含义 + 有限域）、parallel spawning + feedback-driven branch selection + recovery、finite action 概率分布、shared prefix computation。JevSpawn

图注：JevSpawn 四 panel 架构——(a) compositional actions derived from natural language；(b) probabilistic spawning + feedback-driven transitions + recovery；(c) finite action 概率分布；(d) shared computation in the interaction loop。不是 Jev 的原始架构，是 Jev 风格模型作为 agent policy 的扩展形态。JevSpawn

实证上 8 个 task 上 5 个拿到最高分（Maze 0.96、Grid 0.95、LightsOut 0.61、Nullify 0.21、2048 score 305.12）。TypeSafe Jev 变体（在同一架构内把 finite scoring 换成 TypeSafe Jev API）在 PPNL / LightsOut / Sokoban 上更好，但 E2E latency 1.4–2.1× 长于本地 scoring——"Jev API 提供概率"在某些 task 比"同模型自己有限 eval"更准，但通信成本显著。

prefix reuse 是这里真正工程级的优化：对 $B$ 次 evaluation，processed input tokens 从 $B \cdot n_p + \sum n_b$ 降到 $n_p + \sum n_b$。这是 prefix cache 在 compositional policy 上的形式化。

RL training 期扩展：Jev as Q or Policy

"Can Jev be Your Q or Policy in RL?"（arXiv:2610.11692，2026-10-08）把 frozen decision model 嵌入 RL 训练过程作为 reference / exploration / replay 三种正交组件。

图注：浅蓝紫色背景宽幅 framework 图。Jev 在 RL pipeline 中以 reference policy、exploration judge、replay rater 三种角色出现，三者正交（不是必须按某个顺序）。Jev RL Policy

具体到三个 RL 对象：

• Reference policy：Jev-BC（行为克隆）、Jev-PEX（policy expansion，reference 当 critic-min-of-two 的另一方）、Jev-Mixed Sampling（DQN 的 $\epsilon$-schedule 下引用 Jev 的 argmax 或分布采样）。
• Exploration judge：Jev-Gate（Meta Regulator，noul 取代 $\epsilon$-greedy 决定何时探索）、Jev-Bonus（Score Rater 对 state/action/transition 给 novelty rating，转成 intrinsic reward 加到 environment reward 上）。
• Replay rater：Jev-Reweighted Replay（Score Rater 给 stored transition 算采样权重）。

9 个 MiniGrid + 3 个 Atari 的实证显示 Jev 在多个 task 上改进学习，但论文的核心 finding 是 "a decision model need not be a reliable standalone controller to improve RL training"。Jev 在 FourRooms 上零样本 success 96%，但去掉 engineered navigation features 后掉到 40%——它对 input interface 有依赖。Jev RL Policy

两条未来路线

综合所有证据，我们可以分出两条可观察的路线：

路线 A：深耕低延迟低成本有界决策。这是 Tang & Zheng audit 标注为"最清晰的收益"的方向：Jev 在 latency 和 cost 上的优势是普适的、跨任务的、与 typed interface 强耦合的；accuracy 优势在很多任务上不存在但也不致命。如果 Jev 持续在 routing / cascade 守门 / workflow evals 上保持 cost 与 latency 的优势，这条路线就是稳定的。但它要求 Jev 在不同 problem class 上持续打平 frontier，并且 calibration 是 stable across versions。Evidence Audit

路线 B：向复杂推理扩展。这是 OpenJev-RLCD 给出的早期答案：calibrate-then-reinforce 两阶段 recipe 表明 calibrated decision 与 reasoning capability 可以同时优化，至少在 reasoning 能改变答案的任务上（GSM8K-Verify）有效。但这条路线有硬边界：MMLU-Pro 这类 knowledge-heavy 任务上 stage 2 是中性的，ChaosNLI 上 reasoning provably cannot beat cross-entropy；而且 OpenJev-RLCD 是在 1.7B scale 上做的，scale up 是否改变平衡未知。

具体观察信号有四个：(a) Jev 是否能在不同 problem class 上持续打平 frontier；(b) calibrated decision 与 reasoning capability 是否可同时扩展（OpenJev-RLCD 两阶段 recipe 在更大 scale 上是否仍成立）；(c) TypeSafe 是否公开 architecture 或 RLCD 训练算法（目前仍是黑盒）；(d) "决策模型+推理模型+数学软件+验证器"这套提议中的协作架构能否在 open-source 复现。

到这里我们绕完了 Jev 的全貌。回到标题的问题："不输出文字，是否就等于没有思考？"——答案是清楚的：不输出文字不等于没有思考，但内部能力不等于通用推理；输出形式是接口选择，不是能力证据。

接下来是所有的参考文献。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. Introducing System One Models & Jev — https://typesafe.ai/blog/introducing-system-one-models-and-jev
2. Evaluating Decision Models for Text Annotation in Computational Social Science — arXiv:2609.24574
3. Just Ask Jev: Reinforcement Learning for Calibrated Decisions as a Zero-Shot Detector of AI Alignment Failures — arXiv:2609.29429
4. OpenJev-RLCD: A Working RLCD Implementation — arXiv:2609.38850
5. JevSpawn: Adaptive Agentic Inference through Compositional Action Spaces — arXiv:2610.00437
6. Can Jev be Your Q or Policy in Reinforcement Learning? — arXiv:2610.11692
7. JevAdvBench: A Benchmark and Black-Box Attacks for Reinforcement Learning for Calibrated Decisions Models — arXiv:2609.31142
8. Thinking, Fast and Slow (Wikipedia summary) — https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow
9. GLiClass: Generalist Lightweight Model for Sequence Classification Tasks — arXiv:2508.07662
10. Typed Decision Models: An Early Evidence Audit and Evaluation Checklist — arXiv:2609.32160
11. LLMRouterBench: A Massive Benchmark and Unified Framework for LLM Routing — arXiv:2601.07206 (ACL Findings 2026)
12. On Calibration of Large Language Models: From Response To Capability — arXiv:2602.13540