对 AI 系统做红队测试

常规的评测衡量的是系统在按预期使用时是否正常。红队测试衡量的是不按预期使用时会发生什么。

两者都必要，而后者常被跳过，因为它要求你故意去弄坏自己做出来的东西。

该探哪些地方

六个类别，覆盖实际会发生的失效模式。

经由内容的注入。 在系统会读到的任何东西里埋进形似指令的文本——检索增强生成（RAG） 语料里的一份文档、一个网页、一条文件注释、一段消息正文。看它会不会被照做。对任何带工具的系统，这都是价值最高的一项测试。参见提示注入。

访问控制。 索取属于另一个用户、另一个租户、另一个权限级别的数据。核实过滤确实发生在检索环节，权限是拿已认证的用户去校验，而不是拿请求去校验。用一个真实的低权限账号测试，别用管理员账号。

数据泄漏。 设法套出 system prompt、其他用户的内容，或者语料库里这个用户本不该看到的细节。默认 system prompt 是能被套出来的，然后确认里面没有敏感信息。

边界行为。 落在预期范围之外的请求。文档助手会不会给法律建议？编程工具会不会聊不相关的题目？过于宽松和过度拒绝都算发现。

资源滥用。 超大的输入、专门拉长输出长度的请求、高频重复调用、刻意触发长推理的 prompt。确认各项上限和速率限制扛得住。

agent 特有的失效。 对任何带工具的系统：不可能完成的任务、有歧义的任务、工具故障，以及能不能不经确认就走到不可逆的操作。参见Agent 如何失效。

怎么组织

把要测的项写下来。 没有章法地测一通，只会找到零散的问题，还会漏掉整个类别。按上面六个方向列一份清单，更全面，也能重复执行。

用真实权限级别的账号。 拿管理员身份测访问控制，什么也证明不了。

反复试。 系统是非确定性的。第一次失败的尝试，第三次可能就成功了；一次复现不出来，也不构成安全的证据。

让没参与搭建的人上手。 搭建者测的是自己预料到的东西。没有先入之见的人，才能找出那些想当然的假设。

能自动化的就自动化。 把每一项发现都变成测试用例。模型可以围绕一个奏效的手法生成变体，用来检验你的修复是覆盖了这一类，还是只挡住了这一个——这个区别才是关键。

把发现变成修复

按修复本身的性质来分类，因为大多数发现并不是 prompt 的问题。

架构。 注入能触达一个破坏性工具，说明这个工具本就不该从不可信内容那边够得着。改拓扑，不是改 prompt。

强制校验。 访问控制的失败要靠代码兜底——一段不管模型产出了什么都会执行的权限检查。

校验。 输出畸形或不安全，说明缺了一道输出检查。

上限。 资源滥用，说明该设限制。

Prompt。 有些发现确实是 prompt 的问题：范围没说清、没给它拒绝的许可。这是最小的一类，却是人们最先想到的一类。

一个粗略的检验标准，看修复是不是真的：如果一个人铁了心换个说法就能绕过去，那就是个 prompt 层面的修复，本该做成架构层面的。

红队测试做不到什么

它证明不了安全。 没找到问题，只说明你用的手法没找到问题。

注入无法彻底封死。 对会读取不可信内容的系统，红队测试确定的是攻击者能拿到什么，而不是他能不能进来。设计时要做的是让前一个问题的答案是「拿不到多少」。

手法在进化。 半年前的测试集漏得掉近期的套路。定期重跑，模型更新之后也要重跑——厂商侧的改动会让行为漂移，而版本号根本不变。

从哪里开始

如果只做一件事：把形似指令的文本放进你的 RAG 语料里，看系统会不会照做。 对任何同时有检索和工具的系统，这一项测试就能找出后果最严重的那一类问题。

然后用一个真正低权限的账号查一遍访问控制。这两项就覆盖了实际出问题的大多数情形。

要点回顾

• 红队测试检的是非预期用法，常规评测检的是预期用法。两者都不可少。
• 六个方向：内容注入、访问控制、数据泄漏、边界行为、资源滥用、agent 失效。
• 用真实的低权限账号，反复试，并让没参与搭建的人上手。
• 大多数发现需要的是架构或强制校验层面的修复，而不是改 prompt——如果换个说法就能绕过你的修复，那这个修复就是错的。
• 它证明不了安全，而且手法在进化——模型更新后要重跑。
• 从往自己的语料里注入开始，然后是访问控制。

下一篇： 模型供应链风险