红队测试
借鉴军事概念的AI安全测试方法，指组织专职团队或外部研究者扮演攻击者角色，主动挖掘模型的安全薄弱点，完整测试需覆盖数百至数千种攻击场景
核心事实
时间轴 (近 90 天)
AI代理集群引入红队测试后，可同时探测大量攻击面、生成多样化攻击载荷，但同时也带来了误报率高、结果验证困难等新问题。
同一推文作者表示，团队正将类似AI代理集群方法应用于红队测试，以发现并修复基础设施中的漏洞。
LangChain推出了红队测试方法，例如发送语义相似的两个查询，若回应语义不同则说明其中一个有误。
对于 AI 安全研究者，此类越狱合集可作为红队测试的素材来源，帮助评估模型对恶意提示的抵抗力。
在前沿实验室中，红队测试通常覆盖偏见、toxicity、越狱（jailbreak）、提示注入等风险维度，其结果用于指导对齐微调和发布决策。
安全工作的评估往往依赖红队测试和漏洞赏金计划，这些机制能够暴露系统在真实攻击场景下的弱点。
Pramin Pradeep建议的落地顺序是：先建立Agent注册与可见性，再落地红队测试，最后补齐生产可观测性。
containment 关注基础设施被谁触碰，而传统模型安全（如对齐、红队测试）关注模型「做什么」，两者处于不同层次且缺一不可。
微调前的黑盒安全评估在下游适配之前，行为B₃在标准红队提示下的激活率可能为0%，审计会误判为安全，但微调可能改变激活阈值使B₃涌现。
OWASP建议将红队测试纳入智能体开发生命周期，定期更新攻击库，并测试“最坏情况”场景以评估损害范围是否被有效限制。
还有 40 条时间轴事件
全部知识事实 (20)
AI安全研究已形成多个技术分支：可解释性（mechanistic interpretability）、红队测试（red teaming）和形式化验证（formal verification）
90%已验证红队测试源自军事演习中的对抗模拟概念，在AI领域指由专业人员或社区成员主动尝试攻破、欺骗或规避AI系统安全机制以发现漏洞
90%已验证设计不良的AI Agent可能陷入目标→调用API→失败→重试→循环的闭环，在无人监控下持续消耗资源并累积费用
90%已验证OpenAI、Anthropic、Google DeepMind等头部AI实验室都已建立了专门的红队测试流程，并将其作为模型发布前的必要环节
90%已验证AI领域模型能力的可信评估依赖标准化基准测试，常见评测集包括MMLU、HumanEval、MATH、GPQA
80%已验证在AI语境下运行时安全意味着对模型每次推理和每个工具调用进行监控，检测输出是否符合预设策略约束
75%已验证各AI实验室自行设计红队测试并发布安全报告，方法论、测试集和评分标准各异，导致基准碎片化
75%已验证OpenAI在发布GPT-4时曾与专业生物安全机构合作进行红队测试
75%已验证红队演练源自军事和网络安全领域，指由专业人员扮演攻击者角色对系统进行对抗性测试
75%已验证红队演练源自军事和网络安全领域，在AI安全语境中已发展出Prompt层面攻击、训练基础设施安全测试、模型自身能力风险测试等多个层次
75%已验证AI红队测试面临涌现能力的特殊挑战，模型在特定提示词组合下可能展现训练时未被预期的能力，使穷举式测试几乎不可能实现
70%已验证安全对齐（Safety Alignment）是指通过RLHF、监督微调等技术手段引导模型输出符合人类价值观内容并拒绝有害请求的训练过程
65%已验证红队测试（red-teaming）指模拟真实攻击者行为，主动寻找系统漏洞与弱点，该概念最早源于冷战时期的军事演习
65%已验证红队测试（Red-teaming）在LLM场景中指系统性地用边界案例、恶意提示、越狱指令等方式探测模型安全边界，测试维度包括提示注入、有害内容生成、隐私泄露、幻觉触发
65%已验证红队（Red Team）专注于模拟真实攻击者，评估企业防御体系的实际效果
65%待验证领先的AI实验室通常会在模型部署前进行数周到数月的红队测试，并邀请外部安全专家、伦理学者和领域专家参与
70%待验证红队测试涵盖越狱测试、危险能力探测和对抗性输入测试等多个层面，源自军事术语
70%待验证AI安全领域正从整体基准测试的一刀切评估转向领域特异性的精细化治理趋势
70%待验证利用AI寻找目标函数漏洞的能力可以主动暴露目标设定中的缺陷，作为红队测试的延伸
60%待验证红队测试（Red Teaming）源自军事和网络安全领域，在AI领域指由专业团队模拟对手攻击手段来检验模型的安全边界，OpenAI、Google DeepMind、Anthropic等公司在模型发布前都会组织专业的红队对抗测试
60%