左右滑动查看更多
计划:谁将执行测试
-
分配具有特定专业知识的 RAI 红队成员来调查特定类型的危害(例如,安全主题专家可以调查越狱、元提示提取以及与网络攻击相关的内容)。
-
对于多轮测试,决定是否在每轮切换红队成员分配,以便从每个危害上获得不同的视角,并保持创造力。如果切换分配,则要给红队成员一些时间来熟悉他们新分配到的伤害指示。
-
在后续阶段,在开发应用程序及其 UI 时,你可能希望将红队成员分配给应用程序的特定部分(即功能),以确保覆盖整个应用程序。
-
考虑每个红队成员应该投入多少时间和精力(例如,良性情景测试所需的时间可能少于对抗性情景测试所需的时间)。
计划:要测试的内容
-
带有安全系统的 LLM 基本模型,用于识别在应用程序系统上下文中可能需要解决的任何缺陷。(测试通常通过 API 终结点完成。)
-
你的应用程序。(测试最好通过 UI 完成。)
-
LLM 基础模型和应用程序在缓解之前和之后都已到位。
-
可以首先测试基础模型,以了解风险面、识别危害并指导对产品的 RAI 缓解措施的开发。
-
迭代地测试产品的测试版本(使用和不适用 RAI 缓解措施)以评估 RAI 缓解措施的有效性。
-
尽可能多地对生产 UI 执行应用程序测试,因为这最接近实际使用情况。
计划:如何测试
-
考虑创建危害列表,在其中包含危害的定义和示例。
-
将此列表提供给红队成员作为后续测试的指南。
计划:如何记录数据
-
确定红队成员需要记录哪些数据(例如,使用的输入;
系统的输出;一个唯一的 ID(如果可用),以便在将来重现该示例;以及其他注释)。
-
在收集数据时要有策略,以避免给红队成员带来过多压力,同时又不会错过关键信息。
-
准备好协助红队成员解决说明和访问问题。
-
监视电子表格上的进度并向红队成员发送及时提醒。
报告数据
-
列出已确定的首要问题。
-
提供指向原始数据的链接。
-
预览接下来几轮的测试计划。
-
认可红队成员。
-
提供任何其他相关信息。
区分标识和度量
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论