Wiki Notes

Appearance

质量门禁策略专题 ​

版本：v1.2

最后更新：2026-07-09

适用对象：需要把 AI 变更的发布判断从“经验拍板”变成“可重复执行门禁规则”的产品、研发、平台、交付与安全同学

很多团队已经会做评测、灰度和回归，但真正上线时仍然常常缺少最后一道明确判断：

  • 什么时候可以发
  • 什么时候必须拦
  • 拦住后谁来拍板

这也是为什么需要质量门禁策略。

根据 2026-07-08 可访问的 OpenAI Evaluation best practices、Production best practices、Working with evals、Building agents、Guardrails and human review，以及 NIST AI RMF Playbook 的官方资料，可以先建立一个关键共识：

  • 质量门禁不是多设几个阈值，而是把质量、风险、成本、稳定性和副作用一起翻译成发布规则。

1. 什么是质量门禁 ​

更实用的理解通常是：

  • 在变更进入生产前
  • 用一组明确规则决定是否允许发布、灰度或放量

重点不是“多设几个阈值”，而是：

  • 让发布判断从经验拍板变成可重复执行的规则

1.1 门禁真正拦的不是“代码”，而是“变更后的行为风险” ​

在 AI 系统里，被门禁评估的对象可能包括：

  • 模型切换
  • Prompt 变更
  • retrieval 调整
  • tool schema 变化
  • 安全策略变化
  • knowledge release batch

1.2 门禁的价值不是保守，而是可解释 ​

更成熟的门禁系统至少要回答：

  • 为什么过
  • 为什么不过
  • 特批是谁批的
  • 带风险放量时风险由谁接

2. 为什么评测通过不等于可以上线 ​

很多变更即使离线评测表现不错，也仍然可能带来：

  • 某类高风险样例退化
  • 成本突然升高
  • 引用质量下降
  • 工具调用模式异常
  • 高风险动作审批漏放

所以真正的上线判断通常需要结合：

  • 质量
  • 风险
  • 成本
  • 稳定性

2.1 离线通过不代表线上稳 ​

常见原因包括：

  • 流量分布更复杂
  • 用户输入更脏
  • 多轮状态更乱
  • 工具和权限边界更容易被触发

2.2 平均指标不代表关键场景安全 ​

例如：

  • 总体通过率不错
  • 但高风险审批场景下降了

在企业系统里，这通常依然是不允许直接全量上线的。

3. 哪些信号最适合进入门禁 ​

更常见也更有价值的通常包括：

  • 核心任务成功率
  • 高风险样例通过率
  • 结构化输出稳定性
  • 工具调用正确率
  • 人工接管率
  • 单任务平均成本
  • 延迟和超时率
  • 安全拦截表现

这些信号能同时覆盖：

  • 能不能用
  • 上线后会不会出问题

3.1 更适合做硬门禁的信号 ​

例如：

  • 高风险样例失败
  • schema 解析成功率明显退化
  • 审批绕过
  • 跨租户越权

3.2 更适合做观察门禁的信号 ​

例如：

  • 延迟略有抖动
  • 成本有上升但仍在预算内
  • 某些低风险场景体验小幅波动

4. 一个更实用的门禁分层 ​

更建议按三层设计，而不是只有一个“过 / 不过”。

4.1 硬门禁 ​

特点是：

  • 不满足就绝对不能发

典型适合：

  • 越权问题
  • 审批漏放
  • 高风险安全回归
  • 关键结构化输出失稳

4.2 软门禁 ​

特点是：

  • 可以带审批或限流灰度放行

典型适合：

  • 质量略有回退但可观察
  • 成本略有增长但仍可控
  • 某些低风险场景退化但高风险未退化

4.3 观察门禁 ​

特点是：

  • 不阻塞，但必须重点监控

典型适合：

  • 用户体验轻微变化
  • 新链路刚上线需要观察
  • 高敏感指标稳定但波动变大

这样做比单一阈值更贴近真实发布场景。

5. 为什么门禁要分场景而不是统一阈值 ​

不同能力的容忍度往往不同：

  • 高风险外部动作更看安全和误放
  • 内部知识问答更看准确率和引用质量
  • 高频基础问答更看成本和延迟
  • 结构化抽取更看 schema 成功率

如果所有能力共用一个门禁，最终通常会失真。

5.1 问答、RAG、Agent 和审批系统不该共用一套阈值 ​

因为它们的失败代价不一样。

5.2 更好的做法是维护门禁模板 ​

例如按场景沉淀：

  • RAG 模板
  • Agent 模板
  • 高风险动作模板
  • 高并发低风险问答模板

这样每个项目都不必从头造门禁。

6. 门禁策略为什么要和版本绑定 ​

如果没有版本记录，后续很难回答：

  • 哪个版本是因为哪条门禁被拦下
  • 哪个版本被特批放过
  • 哪个版本带着风险进了灰度

更稳妥的做法通常是：

  • 门禁结果、版本号和评测证据一起保存

6.1 至少应该绑定哪些版本对象 ​

例如：

  • model version
  • prompt version
  • retrieval version
  • tool schema version
  • safety policy version
  • release batch id

6.2 版本绑定的价值不只在审计 ​

还在于：

  • 出问题时能快速定位真正的变更对象

7. 门禁失败后到底应该发生什么 ​

更好的做法通常不是简单报错，而是：

  • 指出哪条门禁失败
  • 给出对应证据
  • 告知下一步是修复、灰度还是人工审批

7.1 门禁失败应该有标准分流路径 ​

常见分流包括：

  • 修复后重跑
  • 降级灰度
  • 风险 owner 特批
  • 转人工复核
  • 直接阻断发布

7.2 最差的情况是“没过，但没人知道怎么办” ​

这会让门禁系统迅速失去公信力。

8. 门禁规则最好和场景模板一起沉淀 ​

质量门禁很容易失效的一个原因是：

  • 大家都知道“要做门禁”
  • 但每次新项目上线时都从头再想一遍

更稳妥的做法通常是把门禁策略模板化，至少按这些场景沉淀默认模板：

场景更应强调什么
知识问答 / RAG引用质量、忠实性、权限与越权召回
Agent 工具调用工具选择正确率、参数稳定性、审批漏放
高风险写操作审批覆盖率、误执行率、补偿可行性
高并发基础问答成本、延迟、超时率、结构稳定性

8.1 模板化的价值是什么 ​

它能帮助团队：

  • 更快启动项目
  • 不轻易漏掉高风险检查
  • 在复盘时更容易横向比较不同项目

9. 门禁证据包应该长什么样 ​

很多团队把门禁结果做成：

  • pass
  • fail

这远远不够。

真正有用的门禁证据包应该至少包含：

  • 变更对象
  • 版本信息
  • eval 结果
  • 高风险样例结果
  • 安全回归结果
  • 成本与延迟变化
  • 灰度观察结果
  • 特批记录（如有）

9.1 证据包不只是支持放行，更要支持复盘 ​

因为真正困难的问题往往发生在：

  • 上线后一周
  • 灰度放大后
  • 某类场景被投诉后

此时门禁证据包就是最重要的历史依据。

10. 影子发布和灰度数据，应该进入门禁而不是停留在旁路 ​

很多团队会做 shadow 或 canary，但这些结果没有真正回到门禁判断里。

更稳妥的做法是：

  • 让灰度数据成为门禁证据的一部分

Google SRE 当前 Canarying Releases 在 2026-07-09 仍然强调：

  • 变更应先在小流量、可对照的生产段里暴露风险
  • canary 的价值不只是“先放一点”，而是要和 control 做比较

OpenAI 当前 Production best practices、Evaluation best practices 与 Evaluate agent workflows 则共同提醒：

  • 离线结果只能说明“在已知样本上表现如何”
  • 真正要上线时，还要验证真实流量中的 trace、grader、成本和副作用

10.1 shadow 更适合发现什么 ​

适合发现：

  • 行为差异
  • 工具调用差异
  • 输出结构差异
  • 新旧 Prompt / route / retrieval 配置的隐性分叉

10.2 灰度更适合发现什么 ​

适合发现：

  • 真实用户输入分布下的问题
  • 实际成本与延迟
  • 特定租户或流量段上的退化
  • 人工审批积压和人工接管负担

10.3 如果灰度结果不回门禁，就会发生什么 ​

最常见的结果是：

  • 看起来做了灰度
  • 但放量判断仍然凭感觉

10.4 一个更实用的放量阶梯 ​

更适合 AI 系统的最小放量链路通常是：

text
Offline eval
 -> High-risk regression suite
 -> Shadow comparison
 -> Small canary
 -> Progressive rollout
 -> Full release

每一层都不该只问“过没过”，而要问：

  • 这一层新增了什么证据
  • 哪些证据会直接阻断下一层

10.5 promotion criteria 最好显式写出来 ​

例如：

  • offline -> shadow：关键任务通过，高风险回归不过线即阻断
  • shadow -> canary：结构差异、tool diff、approval diff 在容忍范围内
  • canary -> rollout：真实成本、延迟、审批积压、关键桶指标稳定
  • rollout -> full：高风险桶、长尾桶、人工抽检都没有出现新问题

这样做的价值是：

  • 放量不再是“今天大家感觉还行”
  • 而是“我们已经拿到了哪些新证据”

11. 门禁不只是“质量阈值”，还要覆盖安全、副作用和回滚准备度 ​

很多团队会把门禁做成纯质量门槛。

但在企业 AI 系统里，更应该一起看的还有：

  • 审批漏放率
  • 敏感内容误放率
  • 工具误执行率
  • 人工接管率
  • 回滚可行性

11.1 高风险系统的“副作用门禁”很重要 ​

例如：

  • 是否触发了不该触发的外发
  • 是否错误修改了工单状态
  • 是否产生不可逆写操作

这类问题就算“文本质量不错”，也不能上线。

11.2 很多系统真正缺的是 rollback gate ​

更成熟的团队上线前还会额外回答：

  • 失败时能否在几分钟内切回旧版本
  • 旧 Prompt / model / retrieval / tool schema 是否仍可用
  • approval / guardrail 策略能否同步回退
  • 新知识批次是否支持撤回或冻结

如果这些答案不清楚，很多所谓“可灰度发布”其实只是：

  • 带着未知代价试错

11.3 门禁最好同时包含 release readiness ​

除了模型表现本身，还要确认：

  • 监控是否已经接好
  • 告警是否已经绑定 owner
  • trace 字段是否足够支持复盘
  • runbook 是否已经更新
  • 业务方是否知道这次改动的影响范围

这部分如果缺失，门禁通过也只是“模型通过”，不是“系统可发布”。

12. 门禁和风险分层路由最好联动 ​

风险分层路由决定：

  • 什么请求走什么链路

门禁则应该决定：

  • 这条链路现在可不可以放量

12.1 高风险链路应使用更严格门禁 ​

例如：

  • 更高的通过要求
  • 更少的特批空间
  • 更强的人类在环
  • 更短的灰度放量步长

12.2 低风险链路可以更灵活 ​

例如：

  • 更适合快速灰度
  • 更适合按成本与延迟调优
  • 更适合先试新的模型路由或缓存策略

12.3 更稳的做法是维护 gate profile ​

你可以把不同变更对应的门禁直接配置成不同 profile：

gate profile典型变更更关注什么
model-switch-gate新模型替换旧模型关键任务通过率、成本、延迟、长尾退化
prompt-rewrite-gatePrompt 大改、system / developer instruction 重写结构化稳定性、风格漂移、工具选择差异
retrieval-change-gate切片、rerank、filters、索引或 chunk 策略调整引用质量、忠实性、权限过滤、空检索率
tool-routing-gate工具白名单、schema、router 策略变化tool correctness、参数稳定性、误执行率
guardrail-policy-gate新 guardrail、审批阈值、风险策略调整误放率、误杀率、审批积压、人工负担
knowledge-release-gate知识批次、新语料、新版本文档覆盖率、新鲜度、错误传播、撤回能力

gate profile 的意义不在术语，而在于：

  • 门禁终于不再是一张全公司共用的扁平表

13. 门禁需要明确“谁能拍板”，而不是默认大家一起拍 ​

很多团队真正卡住的不是指标，而是：

  • 谁能决定不过就不过
  • 谁能决定带风险灰度
  • 谁对误放后的后果负责

13.1 质量门禁里最少要有三类 owner ​

角色主要职责
Release owner推动本次变更上线，整理证据包，响应门禁失败
Gate owner维护门禁规则、阈值、模板和执行器
Risk owner对特批、带风险放量和高风险链路负责

高风险变更里，通常还需要：

  • Security / Approval owner
  • Business owner
  • On-call owner

13.2 特批不等于跳过门禁 ​

更好的特批应该至少记录：

  • 哪条 gate 失败
  • 为什么仍然要放
  • 风险由谁承接
  • 放量范围多大
  • 观察窗口多久
  • 哪些条件触发立即暂停或回滚

13.3 特批最好有过期时间 ​

很多团队的问题是：

  • 一次特批
  • 永久放行

更稳的做法通常是：

  • 特批只覆盖某次发布、某个租户桶、某个灰度比例、某个观察窗口

这样特批才是“风险借款”，而不是“永久豁免”。

14. 门禁契约最好机器可读，而不是只写在会议纪要里 ​

如果门禁只是 PPT 或文档，人一忙就会绕过。

更稳妥的做法通常是把门禁写成：

  • CI / release pipeline 可读取的规则
  • dashboard 可展示的证据项
  • 审批系统可记录的状态对象

14.1 一个最小 gate contract 示例 ​

yaml
gate_profile: tool-routing-gate
change_bundle:
  model_version: gpt-5.5-2026-07
  prompt_version: prompt.router.v3.4.0
  tool_schema_version: toolset.billing.v2.1.0
  guardrail_version: guardrail.exec.v1.8.2
required_checks:
  offline_eval:
    min_pass_rate: 0.92
  high_risk_regression:
    max_false_allow_rate: 0.00
  schema_parse_success:
    min_rate: 0.995
  canary_cost_delta:
    max_increase: 0.10
  approval_backlog:
    max_p95_minutes: 8
promotion:
  canary_percentages: [1, 5, 20, 50, 100]
rollback:
  owner: ai-oncall
  trigger:
    - high_risk_false_allow_rate > 0
    - tool_misfire_rate > baseline * 1.5
exception:
  approvers:
    - risk_owner
    - business_owner

这类结构的价值在于：

  • 能直接挂到 pipeline
  • 能直接挂到审批状态机
  • 出事时能直接回看“当时到底用什么规则放行的”

14.2 门禁对象最好是 release bundle，而不是单个文件 ​

更贴近真实系统的发布对象通常不是一条 Prompt，而是一整个 bundle：

  • model
  • prompt
  • tool schema
  • retrieval config
  • guardrails
  • approval policy
  • dataset / eval suite

如果只对其中一个对象做门禁，很多联动风险会漏掉。

15. 常见反模式 ​

15.1 只有一个全局阈值 ​

这通常会让不同场景全部失真。

15.2 门禁只看离线结果 ​

却不看灰度和运行副作用。

15.3 门禁失败后没有标准动作 ​

这样团队很快会绕过门禁。

15.4 只保留 pass / fail，不保留证据 ​

这会让后续复盘几乎失去依据。

15.5 特批没有留痕 ​

这在企业里非常危险。

15.6 门禁只拦模型，不拦系统组合变更 ​

现实里很多问题来自：

  • Prompt + tool schema
  • retrieval + guardrail
  • approval policy + router

如果只盯模型，真正高风险的组合变化会被漏掉。

15.7 门禁只看平均值，不看高风险桶和长尾桶 ​

AI 系统最常见的问题不是平均分突然崩，而是：

  • 某个高风险桶退化
  • 某个租户桶异常
  • 某类长尾请求明显误放

16. 更建议的建设顺序 ​

第一阶段：先把高风险样例和硬门禁建起来 ​

至少先拦住：

  • 越权
  • 审批漏放
  • 不可逆误执行
  • 关键结构化失稳

第二阶段：把版本对象和证据包绑起来 ​

让每次发布都能回答：

  • 发了什么
  • 用什么证据放的
  • 失败时回什么

第三阶段：把 shadow / canary 真正接进门禁 ​

让真实流量证据进入放量判断。

第四阶段：把特批、暂停灰度、回滚都制度化 ​

让“例外情况”也能被治理。

第五阶段：把事故与复盘结果回流到 gate profile ​

让每次事故都能改进下一次发布。

17. 推荐搭配阅读 ​

18. 重点官方资源 ​

以下资源已按 2026-07-09 复核可访问：

19. 落地检查清单 ​

  • 是否按场景拆分 gate profile，而不是只有一套全局阈值
  • 是否区分硬门禁、软门禁和观察门禁
  • 是否把 release bundle、版本和证据包绑定
  • 是否把高风险样例、shadow 和 canary 结果纳入门禁
  • 是否为失败定义标准分流路径与 rollback trigger
  • 是否记录特批、风险承接责任和过期时间
  • 是否明确 release owner、gate owner、risk owner
  • 是否把事故和复盘结论真正回写到门禁模板