毫秒级AI决策的陷阱：选项顺序制造假自信，开源校准让它学会犹豫
现在每个人都在谈论像 Jev 这样的 System 1（系统一）模型……“Jev 现在太火了。”
System 1 风格的分类已经出现在大量场景中，从智能体的工具编排到数据预处理。以下是我脑子里完成任何工作的选择栈：
- 如果可以，写确定性代码
- 如果可以，使用 XGBoost 或传统机器学习算法
- 🆕 如果可以，使用 System 1 风格的决策模型 🆕
- 使用（System 2）LLM 或 SLM
你甚至可以同时使用所有这些系统：为基于特征的多臂老虎机预处理数据，或者把尚未编码进确定性代码的模糊决策卸载出去，作为 LM 智能体暴露的工具。这是一个有趣的时代。
作者：Hussain Chinoy (@ghchinoy) 与 Alan Blount (@zeroasterisk)
我的队友 Hussain 受这个火花启发，问：如果我们在 Google DeepMind 的开放权重 DiffusionGemma（26B-A4B-it）上构建一个零样本决策引擎，并把它推到其概率具有足够不变性、足以门控真实生产流量的程度，会发生什么？🤯
结果是一个引人注目的个人项目 dgem（Apache 2.0）和一个交互式 Decision Studio（在笔记本电脑上运行 dgem serve）。在这个过程中，Hussain 发现了双向扩散模型为选项打分时的一个根本盲区。他的第一个答案是 Invariant Decision Calibration（IDC），我们持续改进、大规模测量，并把它演进为今天 dgem 随附的 hesitation-gating（犹豫门控）。
你现在就可以使用 dgem、部署它，也可以选择微调它；它基于开放权重，完全开源。继续阅读，了解我们如何得出这些示例，请保持关注，因为我们很快还会带来更多。
1. 单遍 vs. 逐词：为什么从左到右的模型会漂移
看看一个标准聊天 LLM（逐词、从左到右生成文本）如何对一张复合企业支持工单进行分类：
“URGENT: Production API returning 502 Bad Gateway for 40 mins. If not resolved in 15 mins we will dispute our USD 45,000 Q3 enterprise invoice and cancel renewal.”
要填三个结构化字段（urgent、urgency_score 和 department），逐词生成的聊天模型必须按顺序生成 25 个以上的 token（2,480 毫秒）。更糟的是，随着它从左到右书写，注意力会从工单开头的“502 Bad Gateway”故障漂移到结尾的“USD 45,000 invoice”账单争议，最终锁定 urgency_score: 4 和 department: Billing。一旦逐词模型承诺了较早的 token，就无法回头。
DiffusionGemma 的工作方式更像相机传感器，而不是打字机。dgem 不是一次写一个词，而是把你的 JSON schema 变成一个填空模板（[MASK] 槽位），并在单遍中同时解析所有空位（约 125–450 毫秒）：
urgent: “yes”（99.7% 置信度，明确）
urgency_score: “5”（94.3% 置信度，明确）
department: “Technical”（75.5%）vs. “Billing”（24.5%），犹豫度 51%，非常不确定，因为这张工单混合了实时 API 故障和账单争议
由于 DiffusionGemma 同时查看整张工单和全部三个空位（双向注意力），字段保持一致，而且你能从这一次前向传播中获得每个选项的精确概率切分。第三个字段才是真正有趣的：模型在告诉你它不确定。记住这一点。
2. 为什么原始置信度与香农熵还不够
大多数路由系统假设：如果香农熵（衡量模型概率在选项间分散程度的指标）接近零，模型就是确定的，可以直接快速退出。
Hussain 用 ChaosNLI、JevBench、Jev Decision Index（by multimodalart / apolinario）以及一个 50 例对抗性校准套件测试了这个假设，结果发现一种静默失败模式：选票顺序（选项 A）首位偏差（Ballot-Order / Box A Primacy Bias）。本质上，选项的排列顺序不应该成为决策的原因。
当你给 DiffusionGemma 一个 100% 无内容的空白提示（[REDACTED / CONTENT-FREE CALIBRATION PROBE]），并提供选项 A 和 B 时，它不会输出 50% / 50%。由于指令微调偏向第一个选项槽位，原始未掩码 logits 分配为：
2 个选项（A 或 B）：88.3% 给槽位 'A“，11.7% 给槽位 ”B“（在阅读任何内容前就接近 9:1 的偏差）
3 个选项（A、B 或 C）：78.3% 给槽位 ”A“（超过公平 33.3% 的两倍）
4 个选项（A、B、C 或 D）：49.3% 给槽位 ”A'（接近公平 25.0% 的两倍）
在 ChaosNLI 中真正模糊的条目上，这种“选项 A 习惯”会让一场抛硬币式的判断显得比实际更自信：在一项小型探测中，仅仅重排选项就改变了 4 个条目中 2 个的答案。一个朴素的熵门控会让其中一些直接通过，触发错误的提前退出（False Early Exit）——尽管反转选项顺序有 50% 的概率（4 个中的 2 个）会翻转模型的答案。
3. 用 Invariant Decision Calibration (IDC) 提高速度与置信度
为了让置信度分数可信，同时不牺牲单遍速度，Hussain 在 dgem 中内置了 Invariant Decision Calibration（IDC）：
清零刻度（Null-Prior De-Biasing，--null-prior-debias）：就像在称面粉前按一下厨房秤的去皮键（TARE），dgem 会先测量模型在空白提示下的选项 A 偏差一次，并在对你的提示打分前减去它（0.1 毫秒）。在我们的实验中，它：
- 将排列多类 Brier 误差降低 90.2%
- 将 50 例护栏准确率从 88.0% 提升到 90.0%（毒性分类从 83.3% 提升到 100.0%）
一遍同时问两个方向（Dual-Mirror Canvas，--dual-mirror）：在逐词 LLM 中，测试正向（A..D）和反向（D..A）选项排序需要 2 倍的前向传播。由于 DiffusionGemma 并行解开所有 [MASK] 槽位，dgem 可以把正向和反向选项放在同一张画布上，额外 GPU 延迟为 0 毫秒（125.0 毫秒 vs. 129.0 毫秒）。在我们的实验中，它：
- 消除了选项反转导致的答案翻转（翻转率从 50% 降到 0.0%）
- 在单遍看起来错误地自信时捕捉隐藏的 50/50 抛硬币式判断（正向与反向的差距跳升 66.8 倍，标记出来交给处理）
在小规模探测集上，两者看起来都很好。然后我们做了你应该总是做的事：在更大规模上重跑所有内容（231 个 JevBench 条目、重复运行、在同一会话中测量运行间噪声）。情况变得更加细致。这些修正并不能可靠地改善决策，而且在一种情况下，仅仅命名镜像问题本身就会轻微改变模型的答案。所以 IDC 不断演进：我们保留了经得起考验的部分，淘汰了没有效果的部分，最终得到的是 hesitation-gating（犹豫门控），并在每个版本中继续优化。
犹豫门控在模型清晰时直接回答，在模型犹豫时交给更大的模型或人，并把 dgem 的概率作为提示/参考一并传递。
犹豫度百分比：熵被缩放到 0–100%，因此一个 2 选项问题和一个 26 选项问题共用同一把标尺。Studio 将其标注为清晰（Clear，<16%）、部分不确定（Somewhat unsure，16–50%）或非常不确定（Very unsure，>50%），比如上面的 department 字段。仅凭犹豫度本身，区分错误答案与正确答案的 AUROC 约为 0.85（231 个 JevBench 条目）。
它在实时环境中有效：预先固定 35% 的阈值，把犹豫条目交给 gemini-3.8-flash，安全得分为 81/100，忠实度得分为 86/100，同时只转交 8–32% 的条目。快速路径的中位耗时 105 毫秒，而 Gemini 为 3.1 秒；每 1,000 次决策的成本约为 $0.02 vs. $1–2（13 个评测套件，每个 n=100）。
在 JevBench 上离线：把犹豫度高于 16% 的 39% 条目转交出去，将 dgem 从 187–189 提升到 231 个中的 221 个（Gemini 回答每一个条目为 225）。该阈值是在相同条目上选择的，并且是可调的。
IDC 的经验教训现在内置于产品中：
- 排序偏差会被测量和监控。每个版本都会在多个基准套件中打乱选项顺序，并针对测得的噪声底限报告额外翻转；犹豫门控已经能捕捉其中大多数重要情况。
- 校准是按领域进行的。最佳 temperature 在约 1.2 到 3.6 之间，具体取决于领域；因此你可以通过配置在每个策略的留出决策上拟合一个值，而不是相信单个全局值或不得不诉诸微调。
- 模板是提示的一部分。使用中性的问题 id，不要跨问题复用选项字母；两者都有可测量的影响，现在已成为模板规则。
- 提示布局很重要。把输入放在问题之前（v0.2.0 以来的默认值）将留出 XNLI 从 0.662 提升到 0.699（n=4,500），将类型化决策从 0.674 提升到 0.728（n=2,000）。
- 宽分类法。两阶段淘汰赛对阵表可以突破每问题 26 个选项的限制，最多 255 个选项；在一个 22 请求的 Decision Index 面板上，覆盖率从 16/22 提高到 22/22。
null-prior 和 dual-mirror 开关仍作为可选研究工具保留在 CLI 中。
4. 使用场景
分类模型并不新鲜，但当前的兴趣和新增强的能力，正是一个好时机来思考我们应该在哪里部署“System 1”风格的快速决策模型。
几个我目前正在考虑的场景：
智能体的 LLM 上下文窗口预编译器：在唤醒前沿 System 2 LLM 或把原始用户输入塞进提示之前，你可以用单遍 System 1 模型对意图、紧急程度以及必要上下文是否存在进行打分（例如，在智能体浪费一整轮去猜测之前，先对可疑邮件标记 missing_sender_metadata）。
智能体的工具调用与结果处理编排（在 LLM 轮次之前）：X 上有两种围绕 Jev 风格模型的模式已经火起来了：在确定性代码中把它们用作“语义化 if 语句”，以及过滤大型 MCP 工具目录（在 LLM 轮次开始之前，把 50+ 个可用工具缩小到 2 或 3 个相关 schema，这样工具定义就不会撑大上下文窗口）。你可以在工具调用的两侧运行完全相同的快速检查：在提议的工具调用执行之前门控它是否有依据且安全，并在嘈杂的工具输出（日志转储、搜索结果、API 负载）落回智能体的对话历史之前对其进行分类或剪枝。
知识图谱或 LLM 维基的实体抽取，把自然语言或任意输入 schema 解析到本体：把凌乱的笔记、会议记录或任意第三方 JSON/CSV schema 转成干净的知识图谱或结构化 LLM 维基，通常会卡在实体解析和分类体系映射上。与其付费让生成式 LLM 逐词重写每条记录，不如用一个双向模板在一次并行传播中完成候选实体分类、把任意源字段映射到你的规范本体类型，并为关系边（depends_on、supersedes、owned_by）打分。当你的本体有几十或几百个类别时，dgem 的两阶段淘汰赛对阵表可以让你解析多达 255 个目标类别，而不会让延迟爆炸。当你的本体缺少某个类别时，dgem 的分类体系发现（--suggest-expansions）会提出一个新选项，而不是强迫不匹配。
策略引擎：在前一个例子的基础上，一旦你有了本体，就可以用它来做安全。因为 System 1 模型把输出概率严格限制在策略模板中的选项上（例如“allow”“deny”或“escalate”），负载中的不可信文本无法通过提示注入让分类器生成自由格式指令。而借助 Invariant Decision Calibration（Null-Prior Tare + Dual-Mirror 检查），策略引擎知道它何时不够自信：当正向和反向的选项顺序不一致时，它拒绝猜测，并自动向另一个系统、一个 System 2 模型或人类（human in the loop）请求更多细节。
决策分解：我还见过一些原型，把更复杂的设计问题分解成一系列原子决策。这里显然有过度扩展的机会，并且在规划和设计方面 System 2 模型更好的时候，伸手去够 System 1 模型可能是错误的；但基于“语义化 if 语句”的想法，我们可以应用一致且结构化的流程，快速提出一堆小问题，并迅速获得好结果。
5. 接下来是什么
dgem 目前是零样本的：你通过编辑策略模板来改变它的行为，无需重新训练。下一步，我们关注更精细的按领域校准、更多决策模板，以及在零样本准确率达到平台期的领域做轻量微调（例如，专注于答案读取的小适配器）。与之前所有事情一样，这些都会以这个基础准确率为基准来衡量，并且只有在超过零样本时才会发布。
想试试吗？
克隆这个 GitHub 仓库，在 Cloud Run GPU（NVIDIA L4 / RTX Pro 6000）或本地 Apple Silicon Metal 上运行 DiffusionGemma（26B-A4B-it），在 Decision Studio（dgem serve）中体验 Hussain 的交互式四场景概念演示。
你在做什么项目？
欢迎在下方分享你的演示。👇