Wiki Notes

Appearance

安全回归测试专题 ​

版本：v1.4

最后更新：2026-07-09

适用对象：正在做 AI 应用发布门禁、红队样例沉淀、Prompt / 模型 / 工具变更验证，以及需要把“修过的安全问题不能再回来”做成持续工程机制的评测、平台、安全与运维同学

很多团队做完一次红队测试后会松一口气，但真正生产里的关键问题是：

  • 修过一次的风险，会不会过几周又回来

这就是为什么安全工作不能只停留在：

  • 找到问题
  • 修掉问题

而必须进入：

  • 把问题固化为发布门禁

安全回归测试关注的不是“发现新问题”本身，而是：

  • 已知高风险问题能否被长期、稳定地压住

1. 什么是安全回归测试 ​

更实用的理解通常是：

  • 把历史事故样例、红队失败样例和高风险边界样例固化下来
  • 在每次系统变更后自动重跑
  • 如果关键防线退化，就阻断发布或升级

这和一般质量评测的差异在于：

  • 一般质量评测问的是“现在整体效果好不好”
  • 安全回归测试问的是“上次修好的坑这次有没有复发”

2. 为什么安全回归测试和普通 eval 不一样 ​

普通 eval 往往更关注：

  • 正确率
  • 通过率
  • 主观质量

安全回归测试更关注：

  • 历史风险是否复发
  • 高风险边界是否退化
  • 拒绝 / 审批 / 拦截路径是否仍然有效
  • 防线变化是否在预期内

也就是说，安全回归测试本质上更接近：

  • 防线稳定性验证

而不是：

  • 一次性能力打分

3. OpenAI 当前安全资料对回归测试给了哪些启发 ​

根据 OpenAI 当前在 2026-07-08 可访问的：

  • Safety best practices
  • Safety checks
  • Red teaming
  • Guardrails and human review

这些资料共同表达了一个很清晰的观点：

  • 安全不是一次测试，而是持续测试、持续对抗、持续验证

把这句话翻成工程语言，就是：

  • 红队负责找漏洞
  • 回归负责防止漏洞回来

所以一个成熟团队不应该只停留在“做过红队”，而应该继续做到：

  • “红队失败样例已经进入持续回归”

4. 安全回归测试的样例应该从哪里来 ​

最值得沉淀的通常不是公开 benchmark，而是离你生产环境最近的样例。

4.1 真实事故样例 ​

价值最高，因为它已经证明：

  • 这是你系统真会踩到的坑

4.2 红队失败样例 ​

价值也很高，因为它通常代表：

  • 系统已经被证实存在可利用路径

4.3 审批与 guardrails 漏放样例 ​

例如：

  • 本该审批却自动放行
  • 本该拒绝却继续执行

4.4 高风险边界样例 ​

例如：

  • prompt injection
  • 敏感数据诱导
  • 高风险工具误调用
  • 跨租户访问

4.5 告警和人工接管记录 ​

很多高价值回归样例并不是来自正式事故，而是来自：

  • 告警
  • 工单
  • 人工接管备注

5. 哪些变更最应该强制跑安全回归 ​

尤其这些改动后，不应省略安全回归：

  • 模型版本切换
  • Prompt 大改
  • 工具 schema 或权限变更
  • guardrails 规则调整
  • 检索和知识库更新
  • 审批规则变更
  • 路由与策略阈值调整

因为很多安全问题并不是“安全代码被删了”，而是：

  • 整体行为边界变了

6. 更实用的安全回归集结构应该怎么拆 ​

建议不要只维护一个混合大表，而是按风险面分桶。

6.1 输入与注入类 ​

覆盖：

  • jailbreak
  • prompt injection
  • 恶意角色诱导
  • 恶意附件或文档提示

6.2 数据泄露类 ​

覆盖：

  • PII 泄露
  • 机密内容外泄
  • 越权检索
  • 跨租户召回

6.3 工具与动作类 ​

覆盖：

  • 高风险工具误调用
  • 参数越界
  • 审批前执行
  • 不该自动执行的写操作

6.4 审批与 guardrails 类 ​

覆盖：

  • 审批链绕过
  • guardrail 误放行
  • 拒绝后继续执行
  • 转人工路径失效

6.5 输出与策略类 ​

覆盖：

  • 不安全回答
  • 不合规领域建议
  • 引用与风险提示缺失
  • 结构化输出绕过约束

这样每次退化时，团队能更快知道：

  • 是哪一层防线出了问题

7. 一个样例不应该只保存“问题文本” ​

安全回归样例如果只有：

  • 输入问题

通常是不够的。

更推荐至少带上：

  • sample_id
  • risk_type
  • scenario
  • input
  • context_source
  • allowed_tools
  • expected_decision
  • expected_approval_state
  • expected_output_pattern
  • severity
  • source
  • introduced_by_incident

如果是 RAG 或 Agent 场景，还建议补：

  • 检索数据域
  • 工具调用路径
  • 是否应拒绝 / 转人工 / 暂停

这样一条安全样例才真正可重放、可维护、可解释。

8. 安全回归如何接进工程发布流程 ​

更稳妥的流程通常是：

text
Code / Prompt / Config Change
 -> Run safety regression suite
 -> Compare against baseline
 -> Check blocking policies
 -> Block / gate release if regressed

也就是说：

  • 回归不是上线前临时跑一下
  • 回归应该是发布门禁的一部分

8.1 更适合做门禁的对象 ​

  • 高风险集
  • 历史事故集
  • 红队失败回归集

8.2 更适合做观察的对象 ​

  • 探索性新样例
  • 灰度期新告警样例
  • 尚未定性的歧义样例

不要一开始就把所有安全样例都做成阻断门禁，否则很容易运营不下去。

9. 安全回归和 guardrails 的关系是什么 ​

guardrails 是：

  • 运行时防线

安全回归是：

  • 检查这些防线是否还在、是否稳定、是否被绕过

如果没有安全回归，团队经常会产生一种错觉：

  • 规则还在，所以系统一定安全

但真实情况往往是：

  • 规则还在，行为边界已经变了

10. 不同风险面该看不同信号，而不是只看 pass/fail ​

10.1 输入和注入类 ​

更应该看：

  • jailbreak 成功率
  • prompt injection 绕过率
  • PII redaction 稳定性

10.2 工具和动作类 ​

更应该看：

  • 工具误调用率
  • 高风险操作放行率
  • 审批前执行率

10.3 数据与泄露类 ​

更应该看：

  • 跨租户误召回率
  • 敏感数据外泄率
  • traces / logs 落敏率

10.4 审批和策略类 ​

更应该看：

  • 审批触发率
  • guardrail 命中率
  • 审批超时率
  • 拒绝后仍执行率

这说明安全回归的结果不该只是一列“通过/失败”，而应该保留足够的解释信号。

10.5 还要显式区分 false allow 和 false block ​

很多团队只盯着：

  • 有没有放过不该放过的内容

但真实系统里另一个同样重要的问题是：

  • 会不会拦住本来应该通过的正常请求

更稳妥的分法通常是：

指标更关注什么更常见后果
false_allow_rate不该通过却通过越权、泄露、误执行、合规风险
false_block_rate应该通过却被拒绝 / 转人工客诉、转人工激增、审批积压、体验退化

这对 guardrails、approval policy 和 tool gate 尤其关键，因为：

  • 漏放会出事故
  • 误拦会把系统拖回纯人工

11. 安全回归套件最好有明确的 suite contract ​

如果回归集只是“很多样例”，后面很容易失控。

更稳妥的做法通常是给每个 suite 定一个最小契约：

yaml
suite_name: approval_guardrail_regression
owner: ai-safety
risk_bucket:
  - approval_bypass
  - guardrail_false_allow
blocking: true
run_on:
  - model_change
  - prompt_change
  - tool_schema_change
  - approval_policy_change
pass_criteria:
  max_false_allow_rate: 0.00
  max_false_block_rate: 0.03
  min_approval_trigger_rate: 0.99
required_artifacts:
  - trace_ids
  - sample_ids
  - policy_version
  - grader_version

11.1 为什么要有 suite contract ​

它至少能回答：

  • 这套回归到底负责拦什么
  • 什么变更必须跑
  • 不过线时谁负责处理
  • 用什么阈值判断

这样安全回归才不只是“安全团队建议跑一下”。

11.2 blocking 和 observing 最好分开 ​

不是所有安全样例都要一开始就做阻断门禁。

更常见的分层是：

  • blocking suite：历史事故、越权、审批漏放、不可逆动作误执行
  • observing suite：新型攻击、灰度新告警、还在定规则的歧义样例

这样既能守住高风险底线，也不至于把探索性样例直接变成发布阻塞。

12. baseline 不应该每次都自动漂移，最好冻结 ​

很多回归体系会不小心把“当前结果”直接当成“下次基线”，这很危险。

更稳妥的做法通常是：

  • 为高风险 suite 冻结基线窗口
  • 只在明确评审后升级 baseline
  • 记录 baseline 对应的模型、Prompt、policy、retrieval、grader 版本

12.1 baseline freeze 主要防什么 ​

它主要防两类问题：

  • 系统逐步退化，但因为每次都拿最近一次结果比，所以没人发现
  • 误把一次带风险特批的结果变成默认标准

12.2 哪些对象最好和 baseline 一起冻结 ​

  • model version
  • prompt version
  • tool schema version
  • guardrail / approval policy version
  • retrieval config version
  • eval / grader version

如果这些对象没冻住，后面就很难回答：

  • 这次到底是系统退化了，还是评测尺子换了

13. 怎样把事故复盘真正变成下次门禁 ​

更成熟的做法通常是：

  1. 事故发生后先止血。
  2. 把根因相关样例从日志、trace、审批记录中抽出来。
  3. 补齐样例字段、严重级别和预期处理结果。
  4. 加入对应风险桶。
  5. 在相关变更上强制重跑。

这样“事故教训”才会真正变成：

  • 下次发布门禁

而不是：

  • 一次性会议纪要

13.1 incident backfill 最好固定成流水线动作 ​

更建议把事故回灌做成固定检查项：

  • 是否补了 sample
  • 是否补了 grader / rule
  • 是否更新了 suite contract
  • 是否更新了 release blocker 规则
  • 是否同步更新 runbook 和 changelog

这样复盘的产物才会真正进入工程系统，而不是停在文档层。

14. 安全回归和红队测试应该如何分工 ​

更实用的理解通常是：

红队测试 ​

负责：

  • 找新的攻击面
  • 探索未知失败路径
  • 构造极端样例

安全回归 ​

负责：

  • 把已知风险长期看住
  • 防止历史漏洞复发
  • 让发布变更有稳定门禁

所以理想闭环是：

text
Red Team Discovery
 -> Reproduce
 -> Fix
 -> Add to Regression Suite
 -> Gate Future Releases

14.1 不要把红队集和阻断回归集完全混成一套 ​

更好的做法通常是：

  • 红队集保持探索性和进攻性
  • 回归集保持稳定、可比较、可解释

否则很容易出现：

  • 样例太飘，门禁无法稳定执行

15. 样例维护最容易忽视的三个问题 ​

15.1 样例老化 ​

随着：

  • 模型变化
  • 工具变化
  • 知识库变化

一部分样例会失去代表性。

15.2 样例污染 ​

如果训练、调优或 Prompt 设计直接过度针对某一批回归样例，可能出现：

  • 回归集分数好看，但实际风险没真正下降

15.3 样例缺 owner ​

没有 owner 的回归集最容易变成：

  • 一堆历史失败文本，没人维护、没人清理、没人解释

15.4 缺少样例淘汰和升级机制 ​

高风险样例不应该永远只增不减。

更稳妥的做法通常是：

  • 标记 active / deprecated / replaced
  • 保留淘汰原因
  • 记录由哪次变更或事故替代

这样回归集才不会越积越乱。

16. 线上告警、trace 和人工审批记录要回灌回归集 ​

安全回归如果永远只靠人工写样例，增长速度会很慢。

更好的做法通常是把这些线上信号持续回灌：

  • prompt injection 告警
  • guardrail 漏放 / 误杀告警
  • 审批超时和审批绕过
  • 高风险工具误执行
  • 客诉工单和人工接管备注

16.1 哪些线上信号最值得优先回灌 ​

  • 真事故
  • 高风险 near miss
  • 灰度期异常样例
  • 被人工纠正的高价值错误

16.2 线上回灌不要只回文本 ​

更建议连这些对象一起保存：

  • trace id
  • policy version
  • tool call path
  • retrieval context
  • approval event timeline

这样后面复盘和重放会容易得多。

17. 建议最少跟踪哪些安全回归指标 ​

17.1 回归有效性 ​

  • 高风险样例通过率
  • 历史事故复发率
  • 红队失败样例重复命中率

17.2 防线运行性 ​

  • guardrail 命中率变化
  • 审批触发率变化
  • 审批超时率

17.3 数据风险 ​

  • 跨租户误召回率
  • PII 落敏率
  • 敏感输出漏放率

17.4 运营健康度 ​

  • 新增高风险样例速度
  • 无 owner 样例比例
  • 回归执行覆盖率

17.5 发布拦截健康度 ​

  • 本月被 blocking suite 拦下的次数
  • 特批放行次数
  • 带风险灰度次数
  • baseline 更新频率

这些指标能帮助团队判断：

  • 回归到底是在保护生产，还是已经被绕过

18. 哪些情况应该直接 block release ​

安全回归最怕的一种情况是：

  • 明明失败了
  • 但不知道什么程度必须阻断

更建议至少把这些情况直接定义成 release blocker：

  • false_allow_rate > 0 且涉及高风险工具、审批漏放、越权或泄露
  • 历史事故样例复发
  • 拒绝后继续执行
  • 审批前执行
  • 跨租户误召回
  • 新增不可解释的高风险行为差异

18.1 哪些情况更适合带观察灰度 ​

例如：

  • 某类 jailbreak 误杀率略上升
  • guardrail 命中率变化但高风险漏放未增加
  • 某些低风险桶 false block 上升但仍在预算内

这样团队才不会把所有安全变化都混成同一种处理方式。

19. 最常见的反模式 ​

  • 做过一次红队就结束
  • 样例写在文档里，不进入自动回归
  • 只测文本，不测工具、审批和数据路径
  • 高风险变更不强制跑回归
  • 失败后没有真正阻断发布
  • 只看总 fail 数，不看严重级别和风险桶
  • 事故复盘不回流到回归集
  • baseline 每次跟着结果自动漂移
  • 只看 false allow，不看 false block

20. 建议的建设顺序 ​

第一阶段：先从历史事故和高风险链路建集 ​

不要先追大而全，先抓最值钱的样例。

第二阶段：把 blocking suite 接入发布门禁 ​

至少覆盖：

  • 模型变更
  • Prompt 变更
  • 工具与权限变更
  • guardrail / approval policy 变更

第三阶段：冻结 baseline 和 suite contract ​

让回归结果真正可比较、可追溯。

第四阶段：把告警和 trace 回流进来 ​

让安全回归从静态样例库升级成真实运营闭环。

第五阶段：再扩展红队和灰度观察集 ​

把探索性样例与阻断门禁分层管理。

21. 推荐搭配阅读 ​

22. 重点官方资源 ​

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