红队测试（Red teaming）

什么是红队测试

红队测试（red teaming）指在模型部署之前，主动去试探它，看它会不会做出有害或不被期望的行为^[1]。它不是等用户碰到问题再修，而是由测试的一方站在攻击者的位置，想办法把模型的毛病逼出来。被逼出来的问题可能是冒犯性言论，可能是本不该复述的私人数据，也可能是要经过一整段对话才逐渐显现的伤害。

为什么要让机器写测试用例

手工做这件事有个明显的瓶颈。人工标注很贵，成本又限制了手写测试用例的数量和多样性^[1]。由少数几个人写出的一小批提示，往往只反映这几个人自己对「可能出什么问题」的想象。

2022 年 2 月，Perez 等人发表了一种把问题倒过来的方法：用一个语言模型来生成测试用例，再把这些用例打向另一个作为测试目标的语言模型^[1]。生成模型被要求给出那些很可能诱使目标模型做出有害行为的输入，然后检查目标模型的回答。这样就用手写速度慢、成本高的人工环节，换成了一个可以批量产出候选测试的机器。

回答怎么判

测试用例只有被看过才有用。这项工作由分类器（classifier）承担——它是一种经过训练、能把文本归入不同类别的模型，在这里用来识别冒犯性内容。跑在目标模型的回答上，这个分类器在一个 280B 参数的聊天机器人身上找出了数万条冒犯性回答^[1]。分类器比逐条人工阅读更便宜也更快，但它只能标出自己被训练去识别的东西。

同样的限制也适用于测试用例本身，作者的应对办法是让用例的产生方式多样化。

生成方法与实际发现的问题

论文探索了多种生成方法，从零样本生成（zero-shot generation）到强化学习（reinforcement learning），目的是产出多样性和难度各不相同的测试用例^[1]。零样本生成是不先给例子、直接让生成模型给出测试用例；强化学习则是在生成模型写出能成功诱出坏行为的用例时给它奖励。之所以要用好几种方法，是因为生成器如果只会一种套路，测出来的问题也就只有一种。

提示工程（prompt engineering）——也就是仔细撰写给生成模型的指令——让作者能够控制产出的是哪一类测试用例。借助这种控制，他们自动发现了几类不同的问题：聊天机器人以冒犯的方式谈论某些人群；把个人电话和医院电话当作自己的联系方式输出；泄露训练数据中的隐私内容；以及在整段对话过程中逐渐出现、而非出现在单条回答里的伤害^[1]。这些是不同性质的失效，能用同一条自动化流水线把它们找出来，是这个方法最实际的理由。

它的位置与边界

作者把这种基于模型的红队测试描述为众多工具中的一种，而且是颇有希望的一种；要在不良行为影响用户之前发现并修掉它们，需要的是多种工具的组合^[1]。它不能替代其他形式的测试，也不能单靠自己把问题解决干净。

局限是设计本身带来的。因为这种方法依赖事先设计好的分类器和提示，它能找到的是已经有人想到并写下来的那类伤害，并不保证覆盖未知的失效模式^[1]。换句话说，自动化红队测试可以在一个划定的「担忧清单」里搜得很彻底，但它无法告诉你这份清单是否已经完整。