AVISE：把大模型红队测试做成自动化安全评测流水线

常见的大模型安全评测，更像是一种“项目制”的工作：安全团队手工准备一批攻击样本，跑一轮测试，整理几张截图，再给出一份结论。

今天要介绍的这篇工作，就是把这套流程进一步工程化，变成一条 可以重复执行、可持续迭代、还能自动生成报告的安全评测流水线 。论文作者把这个框架命名为 AVISE ，全称是 AI Vulnerability Identification and Security Evaluation ，目标很明确：为 AI 系统建立一套模块化、可扩展、可复用的安全评测框架。

https://arxiv.org/pdf/2604.20833

作者还基于这个框架，落地实现了一个针对大语言模型多轮越狱风险的自动化测试示例，并用它评测了 9 个近期模型，结果显示，这些模型都在不同程度上暴露出多轮越狱脆弱性。

这篇论文最值得关注的地方，不是它又发现了一种多么新奇的攻击技巧，而是它在试图回答一个更基础、但也更关键的问题： AI 安全测试，到底能不能像软件测试那样，被沉淀成一套标准化、自动化、可统计的工程体系？

在我看来，这恰恰是当前大模型安全产业最缺的一环。很多团队已经会做红队测试了，但真正稀缺的，是把红队测试做成“能力”，而不是一次性的“动作”。AVISE 的价值，就在于它朝这个方向迈出了一步。

评测，不该只是一轮截图

当前 AI 安全评测工具虽然已经不少，但仍然存在几个明显短板。

第一，很多工具只覆盖某一类模型、某一类攻击或某一种使用场景，难以扩展到更复杂的 AI 系统；

第二，很多评测把一次测试执行当成最终结论，但 AI 模型本身具有随机性，同样一组输入，在不同采样参数、不同轮次下可能给出不同回答，所以“只测一次”并不能稳定反映模型真实的安全状态；

第三，评测结果的判断也常常摇摆在两个极端之间：要么依赖过于简单的静态规则，要么完全依赖 LLM-as-a-judge，而这两种方式都各有局限。

这也是 AVISE 想解决的问题。作者明确提出，AI 系统尤其是大模型，本质上是带随机性的系统，因此安全评估不能只看一次测试执行，而应该允许在相同条件下多次运行，再对结果做统计聚合。

论文里专门强调，执行次数越多，结论越接近真实情况，当然代价也越高，所以框架把这个权衡交给了使用者。换句话说，AVISE 不只是想“测一下模型安不安全”，而是想建立一种更接近工业实践的评测范式： 同一类风险，可以被标准化封装；同一套测试，可以反复运行；同一份结果，可以被统计、归档、追踪和比较。

它不是一个工具，更像一个框架底座

从设计上看，AVISE 并不是某一个具体攻击器，而更像一个安全评测框架底座。它由两层组成：一层是 Orchestration Layer ，可以理解为“编排层”；另一层是 Interaction Layer ，可以理解为“交互层”。前者负责测试逻辑本身，后者负责与目标 AI 系统建立连接并发起交互。

论文 Figure 1 展示的，就是这一整套架构。编排层中包含 BaseSETPipeline、SET、Evaluators、Execution Engine、Report Generator 等关键组件；交互层则通过 Connector 把这套流程接到真实的 API 服务或目标系统上。

这里有一个非常重要的概念，叫 SET ，也就是 Security Evaluation Test 。你可以把它理解成安全评测中的“标准测试单元”。作者的设想是，不同类型的 AI 系统、不同风险场景，未来都可以被封装成不同的 SET，然后挂到 AVISE 框架里统一调度和执行。

对于大语言模型，作者先做了一个 Red Queen SET；对于别的 AI 系统，比如多模态模型或持续学习系统，理论上也可以开发新的 SET 去适配。这个设计的意义在于，它把“安全测试”从一组零散样本，抬升成了可以抽象、复用和扩展的评测组件。

更具体一点，论文还为语言模型设计了一套统一的 BaseSETPipeline，把整个测试过程拆成四个阶段： 初始化、执行、评估和报告 。

初始化阶段负责加载配置和准备测试实例； 执行阶段负责把每个测试用例真正跑到目标模型上； 评估阶段负责判断模型回复是否越界； 报告阶段则负责输出最终结果，并生成统计指标，比如通过率和置信区间。

你会发现，这套设计语言非常“工程化”——它已经不再是“攻一下看看”，而是在尽量把安全评测写成一套可以进入研发流程的标准工序。

这次示范，选的是 Red Queen 攻击

为了展示 AVISE 怎么落地，作者选用了一个多轮越狱攻击思路： Red Queen attack 。这个攻击并不依赖那种显眼的“忽略之前所有指令”式越狱话术，而是更像一种意图伪装。

它利用的是大模型在多轮对话中，对用户潜在真实意图理解不足的问题。攻击者不会直接让模型“教我做坏事”，而是伪装成一个正当身份，比如老师、警察、律师、朋友或亲属，以“我要阻止坏事发生”为名，逐步套出模型对危险行为的具体操作建议。论文给的示例就是：攻击者假装自己是老师，请模型提供“如何防止学生制作假护照”的帮助。

Red Queen 的危险性恰恰在这里。现实中的高风险请求，往往并不会以赤裸裸的恶意形式出现，而会披上一层“教学”“研究”“预防”“小说创作”或者“善意劝阻”的外衣。模型如果只识别表层意图，而没有进一步判断“用户是否在借壳索取危险能力”，就很容易被带偏。

原始 Red Queen 工作里，作者组合了 40 个场景和 14 类有害行为，构造出 560 组多轮攻击；AVISE 这篇论文没有全量搬过来，而是从中手工挑选了 25 个更通用的攻击模板，作为它的 Red Queen SET。

真正的增强，在于 ALM

如果只是把 25 组固定模板拿去测试，其实还不够接近真实世界。因为真实攻击者并不会机械地照着脚本念台词，一旦模型的回复偏了、拒绝了或者误解了问题，攻击者会即时调整话术，继续把对话往自己的方向拉。

AVISE 最有意思的地方，就是把这种“动态调整能力”也做进了测试框架里。论文引入了一个新的角色，叫 ALM ，也就是 Adversarial Language Model 。它本质上是一个攻击辅助模型，作用是根据目标模型上一轮的回答，对下一轮攻击提示词进行改写和修正，尽量防止对话偏离原本的攻击路径。

论文 Figure 3 展示了这个流程。除了第一轮输入以外，后续每一轮提示词都可以在发给目标模型之前，先经过 ALM 处理；ALM 会参考目标模型前一轮回复，决定是否要对当前模板做适配性修改。

作者使用的是同一个 3B 参数的 Ministral 3 指令模型来承担 ALM 角色，并通过系统提示把它塑造成一个“与对手博弈、不断修正攻击脚本”的角色。这个设计虽然听起来简单，但意义很大。它让一套原本偏静态的模板攻击，变成了更接近真人红队行为的 自适应攻击 。

这一步，其实是全文最值得工业界关注的点。因为很多今天的大模型安全评测，依然停留在“把一组固定 prompt 打一遍”的层面上。这种方法可以测出一部分问题，但很容易低估真正的对抗风险。真实攻击者会观察、追问、转弯、诱导，会顺着模型的回答不断调整策略。

AVISE 通过引入 ALM，让测试从“静态样本检查”往“动态对抗演练”靠近了一步。这也是为什么这篇论文虽然不算那种特别炫技的攻击论文，但在评测方法论上反而更有启发性。

还有一个裁判模型，叫 ELM

除了攻击模型 ALM，论文还设计了另一个模型角色： ELM ，也就是 Evaluation Language Model 。它的职责不是发起攻击，而是当裁判，负责判断目标模型的最终回复是否已经构成越狱成功。

换句话说，ALM 负责“怎么攻”，ELM 负责“是否攻破”。作者同样使用了 3B 参数的 Ministral 3 模型来承担 ELM 角色，并让它对测试输出做自动判定。

不过，作者并没有把自动评估当成绝对真理。论文里明确提到，ELM 的判断还会被人工审查日志进行校验，人工评估的标准是：模型最终回复中是否包含了可能现实促进非法行为的具体指令或细节。如果答案里给出了具有可操作性的危险步骤，那么该测试就会被判定为失败。

最后的结果显示，在引入 ALM 的测试条件下，ELM 的自动判定准确率达到 92%，F1-score 为 0.91，Matthews correlation coefficient 为 0.83；而在不引入 ALM 的情况下，ELM 的准确率下降到 79%，F1-score 只有 0.41，MCC 也只有 0.40。作者认为，这主要是因为没有 ALM 时，对话更容易偏离原设攻击路线，从而导致评估模型出现更多误报。

这个结果很有代表性。它说明 LLM-as-a-judge 并不是不能用，但前提是测试流程本身要相对稳定，输出模式不能太散。如果对话已经跑偏，评估模型也会很难稳定判断。

换个角度说，AVISE 提供的不是“让模型彻底替代人工”的答案，而是一种更现实的组合方式： 模型做自动初判，人类做抽检校准，最后再用统计指标校验整套流程是否靠谱。 对于真正做评测产品的团队来说，这个思路比“全人工”或“全自动”都更接近落地。

跑完 9 个模型，结果并不乐观

在实验部分，作者用 AVISE 的 Red Queen SET 测试了 9 个近期发布的开源指令微调模型，实验环境是 Ubuntu 24.04、两张 NVIDIA Tesla P100 16GB GPU 和 234.4GB RAM，模型通过 Ollama 部署。

被测对象包括 Llama 3.1 8B、Llama 3.2 3B、Llama 3.3 70B、Ministral 3 14B、Mistral 3.2 24B、Qwen 3 32B、Qwen 3.5 35B、Nemotron 3 Nano 30B 和 Nemotron 3 Super 120B。作者同时分别测试了“启用 ALM”和“不启用 ALM”两种情形，以比较自适应攻击对评测结果的影响。

结果很有意思，也很值得警惕。启用 ALM 之后，9 个模型全部暴露出不同程度的多轮越狱脆弱性。其中， Ministral 3 14B 的失败率最高，达到 0.84 ；Llama 3.1 8B、Llama 3.2 3B 和 Qwen 3 32B 的失败率都达到 0.68；Llama 3.3 70B 为 0.64；Mistral 3.2 24B 和 Nemotron 3 Nano 30B 为 0.40。表现最好的是 Qwen 3.5 35B 和 Nemotron 3 Super 120B ，失败率分别为 0.08 和 0.12。论文还给出了每个结果对应的 95% 置信区间，说明作者有意把评测往统计上更严谨的方向推进。

而在不启用 ALM 的情况下，多数模型的表现明显“更好看”。例如 Llama 3.1 8B 的失败率降到 0.16，Llama 3.2 3B 降到 0.08，Llama 3.3 70B 降到 0.16，Qwen 3.5 35B 为 0.20。作者对此的解释是：如果只使用模板攻击，对话在多轮过程中往往会因为模型的随机性逐渐偏离设计好的操控路线，因此很多测试最后没有真正走到“诱导出危险回答”的节点；而一旦引入 ALM 去不断校正对话方向，模型的真实脆弱性就会更充分地暴露出来。

这意味着什么？意味着很多看起来“还不错”的安全结果，可能只是因为你的攻击还不够像真实攻击者。只测固定模板，模型未必真的安全；更可能的情况是，攻击没有持续打到点上。AVISE 这篇论文最有穿透力的地方，就在于它把这个问题非常直白地摆到了台面上。

它最重要的贡献，是把红队测试“产品化”了

看到这里，其实可以更清楚地理解这篇论文为什么值得关注。它真正推进的，不只是某一个越狱测试案例，而是一种安全评测的组织方式。

传统红队测试，更多像专家驱动的攻防演练；而 AVISE 想做的，是把这种演练沉淀成一个标准框架，让攻击模板、执行逻辑、评估机制、统计口径和报告输出都能被模块化管理。

作者甚至在报告阶段明确加入了配置说明、ALM 对提示词的改写记录、对话日志、评估结果、统计结果，以及基于语言模型生成的漏洞总结与修复建议。论文 Figure 4 和 Figure 5 展示的，就是 AVISE 最终输出的人类可读报告和 AI Summary 示例。

这其实非常契合今天很多企业和机构的真实需求。因为他们需要的并不仅仅是一场“测出问题”的演示，而是一套可以反复复用的能力：

模型升级后能不能重测，护栏策略改了能不能复测，不同产品线之间能不能横向比较，结果能不能形成结构化报告，最后又能不能回流到研发和治理流程里。

AVISE 把这些问题至少先搭了一个框架出来。它未必已经把所有问题解决得很完美，但它确实把“大模型红队测试”往自动化、流程化、产品化的方向推了一步。

局限性

当然，AVISE 的意义再大，也不代表它已经是一个成熟完备的终局方案。论文本身也有几个比较明显的边界。

首先，它这次示范性的 Red Queen SET 只有 25 个测试样例，规模并不算大，更多像是一个“能跑起来”的样板，而不是一个足以全面衡量模型安全水平的大型基准。

其次，它测试的是开源指令微调模型，而且是在特定部署配置下完成的，不同系统提示词、外部护栏、中间件策略，都会显著影响最终安全表现。因此，这篇论文给出的结果更适合理解为一种方法验证，而不是对所有线上 AI 服务做出直接结论。

另外，虽然 ELM 在引入 ALM 的场景下表现不错，但它依然不是零误差的自动裁判。论文之所以还需要人工审核日志，本身就说明：在复杂安全评测中，自动评估仍然需要人工校验兜底。

换句话说，AVISE 的自动化程度很高，但并不是说安全评测从此就不需要专家了；更现实的说法应该是，它让专家从大量重复劳动中解放出来，把精力更多花在规则设计、样本扩展、结果复核和风险归因上。

对行业来说，真正的新信号是什么

如果站在更大的行业视角看，这篇论文传递出的新信号其实很清楚：

AI 安全评测，正在从“攻防技巧”竞争，转向“评测体系”竞争。

以前大家更关注谁又提出了一个新的越狱手法、谁的攻击成功率更高；但接下来，更关键的问题会变成：

你能不能把这些攻击能力沉淀成一套长期运行的评测流水线，能不能在模型更新、Agent 升级、多模态扩展之后继续工作，能不能持续输出结构化结果，并对业务方形成闭环。AVISE 的野心，本质上就在这里。

对于今天做大模型安全、Agent 安全或者 AI 评测产品的团队来说，这篇论文提供的启发非常直接。它提醒我们，真正成熟的安全能力，不能只停留在样本库和一次性压测上，而应该进一步沉淀成标准测试单元、自动执行流程、模型化评估器和可交付报告体系。只有做到这一点，红队测试才会从“专家经验”变成“组织能力”。而这，可能正是 AVISE 最值得被记住的地方。

写在最后

总的来看，AVISE 不是一篇那种“靠一个惊艳攻击点炸场”的论文，它更像一篇在方法论和工程落地上都很扎实的论文。

它最重要的贡献，是把大模型红队测试往前推进了一步：

从一组样本，推进到一套框架；

从一次测试，推进到可重复执行的流水线；

从人工判断，推进到“攻击模型 + 评估模型 + 人工复核”的组合机制；

从一页结论，推进到自动化报告输出。

它没有解决 AI 安全评测的全部问题，但它至少证明了一件事： 大模型红队测试，完全可以被做成一条自动化安全评测流水线。