一位业务负责人问我：「我们已经有评测系统了，为什么还要单独建一套交付门禁？评测跑不过不就是门禁不放行吗？」这个问题问在了要害上——业界把这两件事混在一起说了两年，直到 2026 年上半年集中出现的一批论文（Automated Self-Testing (2603.15676)、LLM Readiness Harness (2603.27355)、Test Before You Deploy (2604.27789)、Predicting LLM Safety Before Release (2607.07184)）才开始把两者的边界写清楚。这篇是决策地图系列里给「评测 ↔ 门禁」这对搭档补的注释：它们不是同一件事，也不是可以互相替代——它们是同一条质量回路上的传感器和执行器，各自有独立的收敛路径和失效模式。
一、先立骨架：一个是量，一个是拍板
评测系统和交付门禁的角色差别，用一句话就能锁死：
- 评测系统是传感器：把系统运行时的行为持续转成可比较、可归档的分数分布——它的产出是估计量（faithfulness=0.82±0.03、pass^8=25%、P95=1.4s），带误差条，不是二元判决。它像温度计。
- 交付门禁是执行器：在系统生命周期的某个「不可逆边界」上（合入主干、发布上线、放开工具权限），把当前评测分数与预先声明的阈值/契约做比对，做出离散动作——PROMOTE / HOLD / ROLLBACK。它像空调的继电器。
把这个骨架和 Google SRE 的错误预算模式对照一遍就能看出这不是新东西——Google SRE Book《Embracing Risk》 把「SLO 度量（传感器）」和「基于错误预算的发布决策（执行器）」分成两个独立子系统四十年前就写下了：SLO 是持续量，错误预算耗光才触发「本季度不允许上新」这个离散动作。SRE 世界的公理搬到 LLM 世界几乎不变，只是「传感器」的物理性质从 uptime/latency 换成了 faithfulness/pass^k，误差条从可忽略变成了主要难点。
这个骨架还回答了本系列的另一个反问：门禁篇 Gate 决策地图 讲的六道闸（输入/输出/行动/合入/发布/熔断），路由篇 Router 决策地图 讲的路由器，其实都是从评测信号「蒸馏」出的下游执行器：Router 是「优化型」执行器（选谁答），Gate 是「约束型」执行器（放不放行）。而评测系统是它们共同的上游传感器——门禁强度可以调，但传感器本身的分辨率决定了整条回路的上限。
二、七维度硬对照：把混淆一次拆干净
| 维度 | 评测系统 | 交付门禁 |
|---|---|---|
| 产物形态 | 分数/分布/趋势（带置信区间） | 二元或分级决策（PROMOTE/HOLD/ROLLBACK） |
| 触发频率 | 连续/周期性（每次候选变化、每天、每次 trace 采样） | 离散事件（每个 PR、每次发布、每次策略切换） |
| 判定属性 | 概率的、可失败的（判分器本身有假阳假阴） | 确定性的（阈值 + trend rule 一起编译成布尔） |
| 失效代价的方向 | 更怕假阴（漏检翻车）；假阳只是多研究几分钟 | 分对称：合入闸假阳=挡好代码（可恢复）、行动闸假阴=真钱损失（不可逆） |
| 数据结构 | 数据集（golden set/eval set）+ 打分记录 | 契约（threshold set、if-then 承诺、fail-open/closed 策略） |
| 责任主体 | 业务方给题和判分标准（平台产品化篇 的用户责任） | 平台方与业务方共同签署（SRE 错误预算 的组织协议翻版） |
| 收敛度 | 判定属性可形式化处 ✅（结构、编译、pass@k），文本质量 ⚠️（LLM-as-judge） | 结构收敛 ✅（if-then + PROMOTE/HOLD/ROLLBACK），阈值分歧 ⚠️（怎么定还是各家自研） |
这张表的价值不在每一行本身——它在于列间关系：评测系统的输出的分布形状，决定了交付门禁能采用什么样的决策规则。评测每次给你一个±0.1 的估计，你就没资格用「≥0.85 立刻 PROMOTE」这种硬阈值门禁，因为一次抖动就能穿过。这是本文后面「阻抗匹配定律」的伏笔。
三、五篇论文各回答什么问题
把 2026 年上半年这批 arXiv 论文按「传感器 vs 执行器」重新分组，就能看出学术圈已经悄悄把两件事分开做了——每篇都在补对方的漏洞。
HELM（2211.09110）——传感器方法论的祖师爷：斯坦福 HELM 最核心的贡献不是那张榜，而是「先画格子、再填数、空格显式留在图上」这个动作（这条我在覆盖地图篇里展开过）。HELM 之前主流模型平均只在 17.9% 的核心场景上被评测过，之后拉到 96.0%。它给出的是传感器怎么保证不留盲区的方法论。
Automated Self-Testing as a Quality Gate（2603.15676，Maiorano 2026-03）——第一次把执行器写成协议：这篇论文的功绩是把「PROMOTE / HOLD / ROLLBACK」写成一个确定性决策协议，并把它嵌入 CI/CD，用五个可操作的维度做条件——任务成功率、研究上下文保留度、P95 延迟、安全通过率、证据覆盖率。作者在一个内部多智能体系统的 38 次评测运行、20+ 次发布中检验了这套协议，最有意思的发现是：证据覆盖率是「重度回归」的头号判别指标——比任务成功率还灵敏。这一句话把「评测该输出什么维度给门禁用」这个之前被认为是审美问题的选题，变成了可量化的工程问题。
LLM Readiness Harness（2603.27355，同作者 2026-03）——把评测和门禁焊在一起的 harness：这篇论文的正确读法是「Automated Self-Testing 的姊妹篇」——它更侧重把评测、观测、CI 门禁做成一个可复用的readiness harness，输出的是「成本-效用前沿」（cost-utility frontier），而不是单一分数。它的元发现是：readiness 从来不是单一指标能回答的——你需要把多个维度的分布画到同一张图上，让决策者看到「多花 20% 成本换一档质量」的边际替换关系。传感器不给单数，给的是帕累托前沿；门禁不选点，选前沿上的运营点。
Test Before You Deploy（2604.27789，Chishti et al. 2026-04）——把门禁写成「兼容性契约」：这篇的问题设置极其现实：你用的是别人家的模型（OpenAI/Anthropic/自家 fine-tune），供应商会在你不知情的情况下把权重更新掉，行为漂移但版本号不变。作者提出把发布门禁重构为兼容性门禁（compatibility gate）——预先把「可接受行为」写成生产合同（production contract），按风险类别分组做回归测试，任何一个类别越界就触发人工复核工作流。这把控制权从「供应商决定何时发」翻转成「部署方决定何时接」。这是评测/门禁分工的另一个物证：评测在测传感器（模型行为分布），门禁在执行契约（部署方的权利）。
Predicting LLM Safety Before Release（2607.07184，OpenAI 2026-07）——补齐传感器最难的那一格：为什么单独讲这篇？因为它戳破了业界评测系统的一个不太光彩的秘密——大部分预发布评测跟真实部署的分布相隔十万八千里：题目通常是学术选文、agent 一眼就认得出是测试题（evaluation-awareness）、覆盖也不够广。作者的做法是「部署仿真」：拿之前部署过程中留下的、已脱敏的对话前缀，固定住前面几轮，用候选模型重生成下一个响应；然后审计新响应、估算「上线后误行为发生率」。他们的结论是：部署仿真的估计值明显比传统评测更接近生产流量，尤其在 evaluation-awareness 上——传统评测由于「太像考试」，模型会自动切换到考试模式，估出来的合规率是虚高的。这一篇把传感器的偏差（bias，不是方差）单独立成一个课题——门禁再准，传感器有系统性偏差，整条回路也是错的。
这五篇合起来讲的其实是同一件事：「评测=判断」和「门禁=决策」的分工在 2026 年才真正开始形式化——之前叫「evals in CI」的东西，实际上把两件性质不同的工作揉在了一个流水线里，导致设计取舍反复打架。
四、四种典型失配病理：你的组织在犯哪一种
把两者的角色错位，会体现为四种可以立刻自检的病理。把每一种和刚才五篇论文里的对应处方对照着看：
病理 A：只有传感器，没有执行器（评测分很好看，但线上照翻）
症状：pipeline 里跑了 20 个 benchmark，报表也漂亮，但真正合入 PR 时没有任何硬拦截——大家看看 dashboard 就点了「merge」。评测变成了博客用途，不是工程用途。
处方：抄 Automated Self-Testing 的 PROMOTE/HOLD/ROLLBACK 协议——每个维度声明阈值、组合规则、fail 后的默认动作、谁能 override。分数不进 GitHub Action 的 exit code，就等于没有门禁。
病理 B：只有执行器，没有传感器（门禁很严，但拦到的都是无关紧要的事）
症状：CI 里有一堆 pytest 断言，形式化程度很高，红绿分明；但它们只覆盖 JSON schema、字符长度、关键词过滤这些「表层结构」，从没测过任务能力、事实性、越权行为。门禁把不敏感的信号拦得死死的，敏感的信号根本没进门禁。这在覆盖地图篇里叫「格子上全是隐形空格」。
处方：抄 HELM 的方法论——先画格子再填数，空格显式留在图上；每一格评估自己有没有传感器，没有的补上；补完了再决定哪些接入门禁。
病理 C：传感器分辨率跟门禁阈值不匹配（阈值抖到无法解释）
症状：门禁定「≥0.85 就发」，但评测的估计误差是 ±0.05，导致相邻两次评测跑同一个模型，一次 0.84 一次 0.86，一次挡一次放，工程师失去信任。这就是我在评测生词篇里讲的分辨率定律：MDE ∝ 1/√n，题量不够就没法测出细小差异。
处方：门禁的阈值分辨率必须大于传感器的估计标准差——具体做法是让传感器一并输出 Wilson 下界或 Bootstrap 置信区间，门禁看下界而不是点估计。或者反过来：想在阈值处收窄 3 倍，就得把题量放大 9 倍。阈值抖 = 传感器给的分辨率不够，加数据；不加数据的所有阈值调整都是自我欺骗。
病理 D：传感器有系统性偏差，门禁完美执行但方向错（考试模式偏差 / evaluation-awareness）
症状：预发布评测里模型合规率 95%，线上灰度一开翻车率 12%。门禁流程一切按规矩走，但测的分布不是部署的分布——这正是 Predicting LLM Safety Before Release (2607.07184) 单独立成一篇的病理。
处方：加一条「部署仿真」链路——把历史 trace 前缀脱敏后作为评测输入，用候选模型重生成后续，再送进裁判。这条链路的产出要与「学术风格的评测集」独立打标签、独立报告，让门禁能识别「这两个信号一致时才 PROMOTE」。抄 Test Before You Deploy 的兼容性契约也可以——把「与上一版比在真实分布上不掉」写成硬合同。
五、把两者接起来：阻抗匹配定律
前面四种病理其实都是同一条定律的四个变种，把它一次说清楚——这是本文自己给的元规律：
传感器/执行器阻抗匹配定律：
评测的分辨率与代表性 ≥ 门禁的阈值精度与部署分布——两侧不匹配时，整条质量回路的实际强度取两者中的较弱值。
传感器的偏差是不可通过门禁弥补的——门禁能压方差（多次评测取均值/看下界），但压不了系统性偏差（分布不代表）。方差用统计学解决，偏差用「换数据源、加部署仿真」解决。
这条定律给出四个立刻可用的推论：
- 门禁的阈值精度上限 = 传感器的方差下限（不能声称你能拦 0.01 的差异，如果评测本身就是 ±0.05）。要么提精度（加题量、加多裁判、看下界），要么降门禁的野心（改成 rolling window trend 判定）。
- 门禁的判据代表性 = 评测集的采样代表性（如果 golden set 是 6 个月前手挑的，门禁再严也拦不住上周才出现的新翻车方式）。这是「评测集的漂移速度 ≥ 业务的漂移速度」——golden set 是活资产不是版本控制里的死文件。
- 传感器该出前沿而不是分：接受 Readiness Harness 的洞见——单指标决策一定错，输出 cost-quality 前沿，让门禁在前沿上选运营点。这也意味着门禁不能只写「≥0.85」，还要声明「在成本≤X 的前提下」。
- 门禁的失效模式必须锚在不可逆性上（Gate 决策地图篇 的边界定律）：判定器超时/失败时，门禁默认放行还是默认拦截，要看下游是不是不可逆——合入闸 fail-open 是合理的（阻塞开发很痛）、行动闸 fail-open 是灾难（放行了转账没法撤）。这与传感器的选型无关，是门禁自己的合同条款。
六、总合成 + 侧重点差异一句话总结
| 层次 | 评测系统的侧重点 | 交付门禁的侧重点 |
|---|---|---|
| 动机 | 让「模型行为」变得可比较、可归档、可复现 | 让「发布决策」在概率系统里也能自动化 |
| 抽象 | 场景 × 指标格子图（HELM）、分数分布、成本-效用前沿 | if-then 承诺、契约、PROMOTE/HOLD/ROLLBACK 协议 |
| 核心难点 | 覆盖率、分辨率、代表性（防偏差） | 阈值定义、失效模式、fail-open/closed、组织授权 |
| 判成熟的信号 | 空格显式、Wilson 下界、部署仿真链路上线 | 阈值有历史依据、有 override 台账、有回滚演练实测数据 |
| 失败时对方要做什么 | 传感器精度不够，门禁只能改成看趋势/多次投票 | 门禁位置错，传感器再好也没执行的地方 |
| 不能相互替代的证据 | 就算门禁完备，也需要评测持续监测线上漂移 | 就算评测很全，也需要门禁在特定边界上做拍板 |
给出一句可以背下来的差异定义：评测系统回答「现在这个候选到底怎么样」，交付门禁回答「基于当前这份候选，现在这个不可逆动作要不要做」。前者是判断，后者是决策——判断是连续的、可校准的、允许失败的；决策是离散的、可争议的、必须留台账的。
七、诚实的提醒 + 亲手实验
本文所有关键数字（HELM 的 17.9%→96.0%、Automated Self-Testing 的 38 次评测/20+ 次发布/证据覆盖率是重度回归头号判别、Predicting LLM Safety 的部署仿真估计值更接近生产流量、SRE 错误预算 的耗尽即冻结发布协议）都有明确来源，无一亲手复现。
这一篇的最小验证实验半小时可完成：把你手上正在用的 LLM 应用的最近 10 次发布拉出来，为每次发布回答三个问题——（1）当时评测有没有跑；（2）跑完的分数有没有触发任何硬拦截；（3）如果分数低了 0.05，会不会改变发布决策？ 三个问题里有一个答不上来，就说明你有前面那四种病理里的至少一种。这十个数据点就是你的第一份「传感器/执行器阻抗匹配」诊断表，比读十篇论文更能定位你自己的位置。
至此评测决策地图系列的骨架也算画全了：覆盖地图（测什么）→ 决策图（信号往哪流）→ 路由篇 / 门禁篇（信号的两个执行器）→ 传感器/执行器（本篇：把两者的接口讲清）→ 施工图 → 数据规格书 → 实操教程 → 平台产品化（怎么把这一整套做给别人用）。评测和门禁不是一件事，但它们是同一条回路的两端——回路好不好用，看的是两端谁的分辨率、代表性、失效模式先掉链子。
参考来源
arXiv 论文
- Bommasani et al., Holistic Evaluation of Language Models (HELM, 2211.09110)
- Maiorano, Automated Self-Testing as a Quality Gate: Evidence-Driven Release Management for LLM Applications (2603.15676)
- Maiorano, LLM Readiness Harness: Evaluation, Observability, and CI Gates for LLM/RAG Applications (2603.27355)
- Chishti, Oyinloye, Li, Test Before You Deploy: Governing Updates in the LLM Supply Chain (2604.27789)
- Williams et al. (OpenAI), Predicting LLM Safety Before Release by Simulating Deployment (2607.07184)
框架与工程实录
系列前作与本站相关文章