你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
规划大型语言模型 (LLM) 及其应用程序的红队测试
本指南提供了一些潜在策略，用于规划如何在整个大型语言模型 (LLM) 产品生命周期内为负责任 AI (RAI) 风险设置和管理红队测试。
什么是红队测试？
术语红队测试在过去指用于测试安全漏洞的系统对抗攻击。 随着 LLM 的兴起，该术语已经超越了传统的网络安全范围，并在日常使用中演变为描述 AI 系统的多种探测、测试和攻击。 在使用 LLM 时，无论是良性使用还是对抗性使用都可能产生潜在的有害输出，这些输出可能表现为多种形式，包括有害内容，如仇恨言论、煽动或美化暴力或性内容。
为什么 RAI 红队测试是一个重要做法？
红队测试是使用 LLM 负责任地开发系统和功能的一种最佳做法。 虽然不能替代系统化的度量和缓解工作，但红队成员可帮助发现和识别危害，进而支持度量策略验证缓解措施的有效性。
虽然 Microsoft 对其 Azure OpenAI 服务模型进行了红队测试练习并实施了安全系统（包括内容筛选器和其他缓解策略）（请参见此负责任 AI 做法概述），但每个 LLM 应用程序的上下文将是唯一的，你还应对以下内容执行红队测试：
根据应用程序的上下文，测试 LLM 基本模型并确定现有安全系统中是否存在缺陷。
识别并缓解现有默认筛选器或缓解策略中的不足。
提供有关失败的反馈，以便进行改进。
请注意，红队测试不是系统测量的替代项。 最佳做法是先完成一轮手动红队测试，然后再进行系统测量并实施缓解措施。 如上所述，RAI 红队测试的目标是确定危害、了解风险面，并制定可告知需要衡量和缓解哪些危害的危害列表。
下面介绍如何开始和计划红队测试 LLM 的过程。 提前规划对于对于高效开展红队测试演练至关重要。
在测试之前
计划：谁将执行测试
召集队员，组建具有多样化红队成员的组
根据人员的经验、人口统计学特征和跨专业的专业知识（例如 AI 专家、社会科学、安全方面的专家），确定红队成员的理想组合。 例如，如果正在设计一个聊天机器人来帮助医疗保健提供商提供服务，则医学专家可以帮助识别该领域的风险。
招募具有良性和对抗性思维模式的红队成员
招募具有对抗思维和安全测试经验的红队成员对于理解安全风险非常重要，但作为应用程序系统的普通用户，并且从未参与过系统开发的成员可以就普通用户可能遇到的危害提供宝贵意见。
将红队成员分配到潜在危害和/或产品功能上
分配具有特定专业知识的 RAI 红队成员来调查特定类型的危害（例如，安全主题专家可以调查越狱、元提示提取以及与网络攻击相关的内容）。
对于多轮测试，决定是否在每轮切换红队成员分配，以便从每个危害上获得不同的视角，并保持创造力。 如果切换分配，则要给红队成员一些时间来熟悉他们新分配到的伤害指示。
在后续阶段，在开发应用程序及其 UI 时，你可能希望将红队成员分配给应用程序的特定部分（即功能），以确保覆盖整个应用程序。
考虑每个红队成员应该投入多少时间和精力（例如，良性情景测试所需的时间可能少于对抗性情景测试所需的时间）。
为红队成员提供以下内容可能很有帮助：
- 明确的说明可能包括：
- 介绍说明特定轮次红队测试的目的和目标：将要测试的产品和功能以及如何访问它们；要测试哪些类型的问题；如果测试更具针对性，则红队成员应该关注哪些领域：每个红队成员在测试上应该花费多少时间和精力：如何记录结果；以及有问题应与谁联系。
- 用于记录其示例和发现的文件或位置，包括如下信息：
- 示例出现的日期；输入/输出对的唯一标识符（如果可用），以便可重现测试；输入的提示；输出的描述或截图。
计划：要测试的内容
由于应用程序是使用基础模型开发的，因此可能需要在多个不同的层进行测试：
带有安全系统的 LLM 基本模型，用于识别在应用程序系统上下文中可能需要解决的任何缺陷。 （测试通常通过 API 终结点完成。）
你的应用程序。 （测试最好通过 UI 完成。）
LLM 基础模型和应用程序在缓解之前和之后都已到位。
以下建议可帮助你在红队测试期间选择要在各种阶段进行测试的内容：
可以首先测试基础模型，以了解风险面、识别危害并指导对产品的 RAI 缓解措施的开发。
迭代地测试产品的测试版本（使用和不适用 RAI 缓解措施）以评估 RAI 缓解措施的有效性。 （注意，手动红队测试可能还不足以进行评估，也要使用系统测量，但只能在完成第一轮手动红队测试后使用）。
尽可能多地对生产 UI 执行应用程序测试，因为这最接近实际使用情况。
报告结果时，请明确有哪些终结点用于测试。 在产品以外的终结点中完成测试时，请考虑在未来轮次中再次在生产终结点或 UI 上进行测试。
计划：如何测试
进行开放式测试，以发现各种危害。
RAI 红队成员探索和记录任何有问题的内容（而不是要求他们查找特定危害的示例）的好处，是使他们能够创造性地探索各种问题，以发现对风险表面理解的盲点。
从开放式测试创建危害列表。
- 请考虑创建危害列表，在其中包含危害的定义和示例。
- 将此列表提供给红队成员作为后续测试的指南。
进行引导式红队测试和循环访问：继续调查列表中的危害：识别新出现的危害。
如果有可用的危害清单，请使用该清单，并继续测试已知的危害及其缓解措施的有效性。 在此过程中，可能会识别到新的危害。 将这些项集成到列表中，并对改变衡量和缓解危害的优先事项持开放态度，以应对新发现的危害。
规划哪些危害应优先进行迭代测试。 有多种因素可以帮助你确定优先顺序，包括但不限于危害的严重性以及更可能出现这些危害的上下文。
计划：如何记录数据
确定需要收集的数据以及哪些数据是可选的。
确定红队成员需要记录哪些数据（例如，使用的输入；系统的输出；一个唯一的 ID（如果可用），以便在将来重现该示例；以及其他注释）。
在收集数据时要有策略，以避免给红队成员带来过多压力，同时又不会错过关键信息。
为数据收集创建结构
共享的 Excel 电子表格通常是收集红队测试数据的最简单方法。 此共享文件的一个好处是，红队成员可以查看彼此的示例，以获得自己的测试创意，并避免数据重复。
在测试期间
计划处于活动待机状态，而红队测试仍在进行中
- 准备好协助红队成员解决说明和访问问题。
- 监视电子表格上的进度并向红队成员发送及时提醒。
在每轮测试后
报告数据
定期与关键利益干系人共享简要报告，其中包括：
列出已确定的首要问题。
提供指向原始数据的链接。
预览接下来几轮的测试计划。
认可红队成员。
提供任何其他相关信息。
区分标识和度量
在报告中，请务必澄清 RAI 红队测试的作用是揭示和提高对风险面的认识，而不是系统测量和严格缓解工作的替代。 重要的是，人们不应将特定示例解释为该危害普遍性的指标。
此外，如果报表包含有问题的内容和示例，请考虑包括一个内容警告。
本文档中的指导无意也不应被解释为提供法律建议。 你所在的司法管辖区可能有各种适用于你的 AI 系统的监管或法律要求。 请注意，并非所有这些建议都适用于每个场景，相反，这些建议可能不足以满足某些场景的需求。