第5章 · 鲁棒性评估与治理
第 5 章 · 鲁棒性评估与治理
章节摘要：防御做得再多，如果不知道怎么衡量"到底有多鲁棒"，就只是自我安慰。这一章解决两件事：一是怎么科学地评估一个模型的对抗鲁棒性——用哪些基准、哪些攻击强度、哪些指标，才能得到一个不骗人的结论；二是怎么把安全从"事后救火"变成"事前治理"——用红队对抗测试主动找漏洞，用负责任披露、威胁建模和合规框架把安全责任落到工程流程里。读完你会知道，鲁棒性不是一句口号，而是一套可以度量、可以迭代、可以纳入治理闭环的工程实践。
核心问题
阅读完本章，你应当能够：
- 说清鲁棒性评估为什么不能只看干净样本准确率
- 区分鲁棒性评估中的攻击强度、攻击预算与评估指标
- 描述红队对抗测试与常规安全测试的区别
- 理解威胁建模、负责任披露在 AI 安全治理中的角色
- 设计一个最小可行的模型安全评估与治理闭环
核心概念速览
没有度量就没有管理。鲁棒性评估的意义不是给模型发一张"安全证书"，而是持续暴露它离"真的安全"还有多远。
图 5-1：鲁棒性评估与治理闭环
子章节导航
5.1 鲁棒性评估与对抗测试
讲怎么用标准化的攻击库、扰动预算和指标，给模型的对抗鲁棒性打一个可复现的分数。重点是把"理论鲁棒"和"实战扛得住"区分开。
5.2 红队实践与治理框架
讲红队如何像真正的攻击者一样系统性地找模型的漏洞，以及如何用威胁建模、负责任披露和合规要求，把安全责任纳入研发与运营流程。
子章节之间的逻辑关系
5.1 先建立"怎么测量鲁棒性"的度量体系，5.2 再把测量结果放进"怎么治理安全"的工程闭环。前者是尺子，后者是用尺子的流程。没有 5.1 的尺子，治理就是空中楼阁——你不知道自己有多脆弱，自然不知道该投入多少防护；没有 5.2 的治理，尺子量出来的数字也只是一份报告，漏洞不会被修复、风险不会被跟踪。两节是"度量"和"行动"的配对，缺了任何一半，安全都落不了地。
5.1 鲁棒性评估 ──► 5.2 红队与治理 （怎么度量） （怎么治理）
贯穿本章的核心判断
评估与治理这章和前面几章有个根本不同：前四章都是讲"攻和防的技术"，这章讲的是"怎么把攻防技术变成可执行的工程能力"。技术会迭代，但"度量—发现—修复—复测"这套闭环不会过时。理解这一点，你才不会把这章当成可有可无的收尾，而是把它当成让前面所有攻防知识真正落地的"最后一公里"。几条判断贯穿全章。
没有度量就没有改进。 你说自己的模型"挺鲁棒的"，这句话在对抗机器学习里几乎没有意义——鲁棒性必须绑定具体的扰动预算、攻击强度和评估指标。一个在 8/255 的 Linf 预算下扛得住 PGD 的模型，换个预算或换个攻击可能瞬间崩溃。所以评估的第一原则是"数字要带上下文"，脱离预算和攻击谈鲁棒率，等于没谈。这条判断会反复出现在 5.1 节。
自动化评估有盲区，人的创造力补上。 自动化的对抗测试只能覆盖你已经想到的攻击类型，而真实攻击者不会按你的脚本出牌。红队的价值就在这里——用人的视角去找那些自动化工具发现不了的漏洞，比如业务逻辑层面的绕过、提示注入、组合攻击。这条判断是 5.2 节红队实践的核心动机。
安全是流程不是功能。 这是整章的总基调。鲁棒性评估给模型打分，红队找漏洞，治理框架保证漏洞被修、风险被控——三者合起来才是一个可持续运营的安全闭环。指望"装一个防御模块就一劳永逸"是不现实的，因为模型在迭代、攻击者在进化、业务在变化，安全必须跟着一起动。这条判断解释了为什么治理框架要和评估、红队配套，而不是单独存在。
读这一章要带的视角
和第 3 章一样，这章也充满取舍，但取舍的维度不同。第 3 章的取舍是"精度换鲁棒"这种技术权衡，这章的取舍是"投入多少评估资源""红队做多深""治理流程多重"这种工程与组织权衡。读的时候建议不断问自己：我的模型部署在什么场景，安全漏洞被利用的后果有多严重？我愿意为评估和红队投入多少人力和算力？我的组织能不能支撑起一个持续的治理闭环？
带着这些问题读，你会发现 5.1 节里"用什么攻击测"不再只是技术选择，而是"评估预算够不够"的工程决策；5.2 节里"红队做多久一次"也不只是流程设计，而是"威胁演化速度 vs 检测节奏"的博弈。这种把技术问题还原成组织决策的视角，是从"会用攻防工具"进阶到"能驱动 AI 安全落地"的关键。
前置知识与后续延伸
- 前置知识：需要理解第 2、3 章的攻防方法，知道攻击算法和防御手段的基本概念。如果你跳着读到了这章，建议至少回头看看 2.1 的 PGD 和 3.1 的对抗训练，因为评估和治理都会频繁引用它们。
- 后续延伸：本章是全文集的收束，之后可以结合附录的攻防方法速查表，把学到的评估与治理方法应用到具体项目里。一个实用的收尾练习是：拿你手边的一个模型，按 5.1 的三支柱做一次最小评估，再按 5.2 的四阶段跑一次简化红队，你会对"安全是流程"这句话有切身体会。