AI Red Teaming 分析

原文link：https://arxiv.org/pdf/2507.05538

1. Introduction

• Red Teaming在AI领域的兴起
  随着生成式AI（如ChatGPT）快速发展，red teaming在AI安全、保障和可靠性等话题中受到广泛关注。最初，red teaming主要为军事或网络安全领域所用，近年逐渐成为AI治理讨论的核心内容之一。

• 本质与作用
  Red teaming是一种批判性思维训练，其目标是评估复杂方案的适用性和稳健性。它不仅局限于技术测试，更应涵盖治理结构、设计假设等，适用于管理、法律、风险等多类型团队。

• 局限性与反思
  当前AI red teaming实践过于聚焦于模型层面的缺陷，忽略了模型、用户与环境之间复杂互动带来的系统级和社会技术风险，与网络安全领域的最佳实践形成脱节。

• 拓展视角的必要性
  要在AI开发全周期内有效实施red teaming，需跳出纯技术视角，将其作为一种系统性、战略性的集体批判性思维活动，以促进更加健全的AI治理和风险管理。

---

1.1 What Red Teaming is and is not

• 团队与多学科协作
  Red teaming本质上是一个多功能、跨学科团队的协作活动，围绕两个核心问题展开假设性探讨：
  1. 系统是否服务于用户利益？
  2. 系统是否可能损害用户利益？

技术团队关注模型漏洞，政策专家关注合规，伦理学家关注价值对齐，领域专家评估现实影响。

• 区别于纯对抗测试
  Red teaming并非只是“捉漏洞”或“击败系统”，而是要反思“我们做了或没做什么，可能导致系统在真实世界失败”。

• 促进透明与无责文化
  这种协作方式强调无责、透明地发现盲点、错误假设和脆弱性，让组织在部署前能充分认识潜在失败模式。

• 系统性与生态视角
  有效的red teaming不仅关注产品本身，还评估开发流程、组织结构、激励系统和实际运营环境。其过程类似于论文写作，需要多轮修订和集体反思。

---

1.2 The Way Forward

• 反馈闭环与行动转化
  组织应建立系统流程，将red team发现的问题转化为实际改进，包括问题跟踪、风险排序、缓解措施实施及修复验证。如果缺乏反馈闭环，red teaming将流于形式。

• 持续性与动态适应
  Red teaming类似于软件验收测试，单次测试无法预见所有问题。AI系统在动态环境中运行，需持续监控、评估和适应性响应，超越初始测试阶段。

• 超越狭隘技术手段
  Red teaming目标远不止于保障AI模型的安全与可靠性，也不局限于传统渗透测试或模糊测试等单一手段。应作为开发全周期内的集体批判性思维方法，最大化效用、最小化风险。

---

2. History of Red Teaming

2.1 Military Origins

最初，红队起源于19世纪初普鲁士军队的兵棋推演（Kriegsspiel），在这种模拟演练中，蓝色代表本方，红色代表敌方，这一配色延续至今。美国在冷战时期通过RAND公司等机构将红队思想引入军事决策，红队代表苏联，蓝队代表美国。
红队制度化的重要节点包括：9/11事件后美国国防部的正式红队组建，以及堪萨斯州利文沃斯堡的专业化培训，这些措施旨在打破集体思维、强化批判性和逆向分析能力。

2.2 Adoption in Cybersecurity

随着红队理念的传播，20世纪80年代美国国家安全局（NSA）最早将其用于网络安全，派遣独立评估团队模拟攻击以查找保密系统的弱点。90年代“tiger team”概念出现，红队方法逐渐扩展到包括物理安全、社会工程等内容。

值得注意的是，现代网络安全红队不仅仅局限于技术测试，还涵盖了：

• 技术漏洞扫描与渗透测试
• 物理安全评估
• 社会工程攻击（如钓鱼、假冒）
• 复杂的红队-蓝队对抗演练
  这些方法已被NIST等标准组织纳入正式框架，并不断演化出自动化红队、对手模拟（MITRE ATT&CK）等新趋势。

2.3 Red Teaming AI

进入AI时代，红队概念被引入AI系统安全评估。AI红队通常是在受控环境下，通过与开发者协作，结构化地测试AI系统（尤其是大语言模型），以发现潜在缺陷和脆弱性。

然而，当前AI红队实践存在以下突出问题：

• 行业内对红队的范围、流程和评估标准缺乏统一，部分红队工作流于形式，风险缓解有限。
• 过度关注模型本身，忽视了模型在生产系统和实际社会环境中的表现及影响。
• 多数测试仅限英语环境，内部人员风险与多语言、多元文化挑战被忽视。
• 红队成员大多为技术背景，缺乏语言、法律、伦理等多领域能力，同时也面临长期接触有害内容带来的心理压力。

2.4 What’s Missing?

随着对AI风险治理的需求提升，研究者逐渐认识到仅靠红队无法解决所有AI安全挑战。行业正在探索“紫队”（violet teaming）等新模式，将红队的风险识别与蓝队的防御响应结合起来，强调多样性和实用性，提升对真实世界攻击的应对能力。

---

3 Implementation

任何红队活动都应成为更大范围、协同的风险与安全管理体系的一部分。这包括在模型开发和系统建设前进行的“pre-mortem”（事前预演）及全面风险评估，以及将AI特有的安全流程融入模型开发生命周期。组织应让相关安全团队参与强化模型及其关联系统的安全性，并在整个开发、部署、生产及退役阶段，安排蓝队与红队协作，确保安全始终是优先事项。

作者提出，AI系统的红队工作应在两个互补的层面展开：

• 宏观层面（system-level）：覆盖AI系统的全生命周期。
• 微观层面（model-level）：聚焦驱动AI系统的核心模型。

---

3.1 Macro-level (System) Red Teaming

宏观层面的红队工作强调对AI系统全生命周期的风险识别和系统性评估。红队不仅关注模型本身，更聚焦于从项目立项到系统退役的每一个关键环节，提前发现和缓解可能导致系统性失败的隐患。

3.1.1 立项阶段（Inception）

• 检视问题定义及AI解决方案适用性，防止“AI万能论”。
• 提出关键问题：AI是否必要？利益相关方各自的动机与影响？可能带来的副作用？系统上线后如何被对手利用？
• 分析生态环境，包括法规、竞争、社会背景及下游影响。
• 模拟技术成功但商业、伦理或社会失败的场景，评估被滥用、误用或引发大规模后果的可能性。
• 强调明确“好”的标准，要求利益相关方不仅说明系统应该做什么，也要界定其“绝不能做什么”，以揭示未察觉的假设和约束。

---

3.1.2 设计阶段（Design）

• 将抽象概念转化为具体架构、线框和技术规范。
• 红队需识别接口、架构选择及与现有系统集成的系统性脆弱性。
• 关注组件间意外交互、异常场景、数据流被篡改或劫持，以及算法、框架、第三方组件的选择风险。
• 人机交互需特别审视，挑战用户行为假设，防止系统被误用或过度依赖。
• 检查不确定性表达、错误处理和用户自主性维护。
• 监督与治理机制要在设计初期嵌入，确保监控、可解释性和控制机制不是事后补救。

---

3.1.3 数据阶段（Data）

• 数据是AI系统基础，需全面审查数据及数据管道。
• 红队关注数据采集、存储、访问控制、数据溯源和生命周期管理。
• 挑战数据代表性和质量假设，防止训练数据系统性忽视某些群体或场景，避免模型偏见及性能缺陷。

---

3.1.4 开发阶段（Development）

• 关注实现选择和开发实践如何引入系统性脆弱性和风险。
• 审查开发环境安全，特别是供应链风险（如第三方库依赖、开发工具被攻击等）。
• 强化代码和模型工件的安全与版本管理，防止未授权修改。
• 模型训练/微调过程中需评估超参数选择、优化流程及数据损坏等风险。
• 与现有系统集成的接口点是复杂攻击面，需进行对抗性和失效模式测试，超越功能性验证。

---

3.1.5 部署阶段（Deployment）

• 严格审查部署基础设施和更新流程，识别多种失效模式的关键控制点。
• 模型工件分发和更新机制需防范安全漏洞和版本不一致。
• 部署失败和回滚需测试平滑降级，防止全系统失效。
• 生产环境面临不同于开发环境的挑战，如级联故障、资源耗尽和性能瓶颈。
• 对外依赖带来可靠性风险，需设计断路器和回退机制。
• 实际用户行为与开发假设有差异，可能暴露新攻击面和安全风险。

---

3.1.6 运维阶段（Maintenance）

• 评估监控与告警系统，防范多种失效模式。
• 不仅监控基础技术指标，还需关注性能退化、偏差漂移和安全相关行为变化。
• 异常检测系统可能产生误报，掩盖真实问题。
• 需持续跟踪输出质量、公平性和安全关键指标。
• 模型漂移是系统可靠性和安全的根本威胁，需权衡重训练时机和服务连续性。
• 组织特有的运维风险随成熟度演变，传统IT响应流程或不适用于AI系统。

---

3.1.7 退役阶段（Retirement）

• 系统退役时，红队需重点审查数据保留与销毁实践，兼顾安全、隐私和经验传承。
• 训练数据和日志既带来隐私风险，也有助于未来改进。
• 安全的数据销毁需平衡法律要求与经验保留；备份数据既有泄露风险，也包含重要洞见。
• 用户迁移过程存在过渡风险，如通知混淆导致安全事故。
• 系统依赖和操作流程可能因底层系统移除而失效，继任系统需覆盖全部用例与故障处理。
• 退役后遗留风险长期存在，组织记忆可能保留过时假设，影响新系统安全与可靠性。

---

3.2 Micro-level (Model) Red Teaming

• 模型红队的目标：

  1. Boundary seeking（边界探索）：识别模型能力的极限。
  2. Generating edge cases（生成边缘案例）：揭示模型意想不到的能力或局限。
  3. Discovering risks（发现固有风险）：在实际部署前识别模型内在风险。

• 最佳实践与方法论：

  • 引用 Inie 等人的研究，提出了12种策略和35种技术，划分为5大类，将技术知识与创造性问题解决相结合。
  • 这种结构与网络安全领域的TTP（战术、技术与程序）框架类似。

• 多元参与的重要性：

  • 有效的模型红队需要纳入多样化用户视角和社区声音，不仅仅依赖大规模对抗性提示测试。
  • 不同群体和场景下，AI系统的脆弱性表现不同，多样化参与对全面风险发现至关重要。

• 宏观与微观红队的互补：

  • 宏观与微观红队是互补的，两者结合才能全面覆盖AI系统风险。
  • 宏观层面的洞见可指导微观测试重点，微观发现也能反哺宏观风险评估。

• 协作与全生命周期覆盖：

  • 理想的AI红队应在开发全生命周期持续应用，技术与非技术专家通力协作，挑战假设、识别盲点。

---

4 A Systems Perspective

AI红队不仅仅是技术层面的实践，还需要运用系统理论，关注宏观（系统级）和微观（模型级）红队工作的协调，并将其整合进AI系统所处的更广泛社会技术环境。作者提出了“元级红队”（Meta-level Red Teaming）的概念，旨在应对由技术组件、组织环境和部署环境的复杂交互带来的新型和突发风险。

4.1 Recommendation 1: Adopt Systems-Theoretic Perspectives

Miehling等人的观点认为，当前AI开发过于关注单一模型能力，忽视了系统整体的涌现行为，容易低估真实能力和未被发现的风险。对于智能体系统，不应只测试各组件的孤立表现，而要分析多组件交互如何导致系统层面出现意外的功能或风险。智能体系统由多个“agent”构成，这些agent在与人类、其他agent和环境的持续互动中展现出复杂的行为，反馈回路贯穿不同层级。因此，红队工作必须绘制这些交互模式，识别只在多智能体协作、人机协作和环境适应中才会出现的系统级脆弱性。

4.2 Recommendation 2: Pair Red Teaming with Testing

AI红队应纳入更广义的测试、评估、验证与确认（TEVV）体系。AI红队本质上是TEVV的子集，应结合成熟的软件TEVV实践，并考虑AI的特殊性。传统的AI基准和评估方法难以覆盖实际部署中的人类和社会因素。AI红队应同时关注第一序效应（如准确性、毒性、偏见等直接输出）和第二序效应（如用户行为变化、社会影响、劳动力转型等长期后果）。因此，红队要超越静态、单轮测试，设计能够捕捉多元用户与AI在现实环境中持续交互时涌现行为的评估场景。

4.3 Recommendation 3: Coordinated Disclosure Infrastructure

建立AI缺陷的协调披露机制。AI系统的故障和漏洞可能在不同模型和系统之间转移，需多利益相关方共同参与缓解。组织应建立标准化披露流程，包括缺陷报告模板、评估者操作规范，并为善意红队和研究者提供安全港保护。披露机制应整合进TEVV文档和可追溯性管理，确保红队发现能持续反哺验证和安全保障，同时应对AI生态系统中供应链跨系统的系统级挑战。

4.4 Recommendation 4: Design Bidirectional Feedback Loops

建立宏观与微观红队信息双向交流的正式流程。宏观层面的部署环境和组织背景应系统性地指导微观测试重点，微观发现的漏洞应反向促发宏观风险的重新评估。对于智能体AI系统，需测试微观模型行为与宏观工具、部署场景和多智能体交互的关联，考虑agent通过工具与环境的“感知—运动”接口，形成更高层次的认知能力。

4.5 Recommendation 5: Threat Modeling for Emergent Risks

AI威胁建模应从单一组件扩展为多层次，覆盖技术、社会和涌现行为维度。系统理论指出，每个组件既要理解其自身属性，也要考虑其对整体系统行为的影响。多智能体系统的威胁建模需关注复杂交互、协调机制及由协作产生的涌现行为。红队和TEVV框架需开发能表示对手如何利用系统交互中涌现特性的威胁模型。例如，智能体间共享不确定性和表征可能催生元认知能力，而这些能力可能以单一组件测试无法预见的方式被利用。

4.6 Recommendation 6: Monitor for Behavioral Drifts

复杂系统行为随时间动态变化，AI红队应成为持续性过程，关注系统演化和环境变化带来的新缺陷和脆弱性。对于智能体AI系统，尤其要关注因环境交互带来的认知、因果推理和元认知能力提升后的行为变化。组织应建立长期监控机制，不仅关注技术性能，还要跟踪行为模式和交互动态，确保系统持续满足安全和保障要求。这与TEVV中持续验证的要求一致，且需关注长期后果和涌现行为，这些往往只有在持续部署中才能显现。