AI 应用上线后，总会有用户尝试让它说出不该说的话、做出不该做的事。与其等问题在生产环境中暴露，不如在上线前主动出击。红队测试（Red Teaming）就是让一组人扮演攻击者，用各种方法系统性地寻找 AI 系统的弱点。 它已经成为负责任的 AI 开发流程中的重要环节，对于面向公众或具备工具调用能力的应用尤其必要。

红队测试的目标

红队测试不是为了证明系统“绝对安全”，而是为了：

  • 发现未曾预料的失败模式和攻击路径；
  • 评估现有防护措施的有效性；
  • 为整改工作提供具体案例和优先级；
  • 在上线前形成风险认知，决定哪些风险可以接受、哪些必须解决。

确定测试范围

开始之前，先明确：

  1. 测试对象：是基础模型本身，还是包含系统提示、检索、工具调用的完整应用？对大多数企业来说，应该测试完整应用；
  2. 威胁模型：谁可能攻击？普通用户的好奇试探、恶意用户的蓄意攻击，还是通过外部内容进行的间接攻击？
  3. 关注的风险：根据应用场景确定重点，例如客服机器人重点关注品牌声誉和信息泄露，编码 Agent 重点关注命令执行和凭证安全；
  4. 成功标准：什么样的输出算作“攻击成功”，需要事先定义清楚。

常见攻击类别

越狱

通过角色扮演、虚构场景、多轮诱导、编码转换等方式，让模型绕过安全限制，输出违规内容。

提示注入

直接注入试图覆盖系统指令；间接注入通过网页、文档、邮件中的隐藏指令劫持模型行为。详见提示注入攻击与防御。

系统提示与数据泄露

诱导模型泄露系统提示词、内部配置、知识库中的敏感文档，或其他用户的信息。

越权操作

对具备工具调用能力的应用，测试能否诱导模型调用未授权的功能、访问其他用户的数据或执行高风险操作。

有害与不当输出

包括歧视性言论、危险信息、不实的专业建议（医疗、法律、金融），以及与品牌形象严重不符的内容。

幻觉与误导

在关键事实上制造错误，例如编造产品政策、价格、承诺，可能导致实际的商业或法律后果。相关分析见大模型幻觉的成因。

资源滥用

诱导模型生成超长输出、陷入无限循环调用，造成成本失控或服务不可用。

测试流程

1. 组建多样化的团队

除了安全工程师，还应包括产品、业务、法务人员，以及熟悉目标用户群体的成员。不同背景的人会想到不同的攻击方式。

2. 人工探索

由红队成员手动尝试各类攻击，记录有效的攻击手法和对应输出。人工测试擅长发现创造性的、意想不到的问题。

3. 自动化扩展

把人工发现的有效攻击模式整理成模板，用程序批量生成变体进行测试；也可以使用大模型自动生成攻击提示，并用另一个模型判断攻击是否成功。自动化能够大幅提升覆盖面，判定方法可参考 LLM-as-a-Judge。

4. 记录与分级

对每个发现的问题记录：攻击输入、模型输出、复现步骤、严重程度、影响范围。按严重程度和发生可能性排序。

5. 整改与回归

针对问题采取措施：调整系统提示、加强输入输出过滤、收紧工具权限、增加人工确认环节。整改后，把这些攻击案例加入回归测试集，防止问题在后续版本中重现。

持续进行而非一次性

模型版本更新、提示词修改、新增工具和数据源，都可能引入新的漏洞或让旧漏洞重现。红队测试应该：

  • 在重大版本上线前执行；
  • 自动化部分纳入持续集成流程；
  • 定期组织人工红队演练；
  • 结合线上监控中发现的异常案例不断补充测试集。

小结

红队测试通过主动模拟攻击，帮助团队在上线前发现 AI 应用的安全和质量问题。明确范围与威胁模型、覆盖主要攻击类别、人工探索与自动化扩展结合、记录分级后整改并回归，是一套可以逐步建立起来的实践。它与日常的质量评测相辅相成，共同保障 AI 应用的可靠性。