量化 (quantization)指标和人工评估能够提供模型性能和对齐 (alignment)度的有用信息，但它们通常评估的是模型在典型条件下的行为。为了细致验证RLHF调整过的模型的稳定性与安全性，尤其是在潜在的对抗性或意外场景下，可以运用红队测试和结构化安全测试。这些做法对于发现弱点并确保模型在部署时表现稳定且安全是必要的。
理解大语言模型 (LLM)的红队测试
红队测试，在大语言模型的背景下，是指有意地探查模型，以找到导致其表现出不良行为的输入或交互模式。与衡量预期任务性能的标准评估不同，红队测试积极寻找失败情况、盲区以及绕过模型对齐 (alignment)训练的方法。其目的不仅仅是测量失败率，更是弄清模型失败的方式和原因。
红队测试期间针对的不良行为可以包括：
- 生成有害、有毒、有偏见或不当的内容。
- 泄露训练期间使用的敏感信息。
- 协助进行有害活动。
- 在压力下产生事实不正确或荒谬的言论（幻觉 (hallucination)）。
- 表现出脆弱行为，即微小的提示变化导致截然不同（且更差）的结果。
- 未能遵守明确的负面限制（例如，“不要提及X”）。
红队测试方法
红队测试可以从非结构化探查到高度系统化的行动。常见方法包括：
-
手动对抗性提示： 人类专家，通常具有不同背景（例如，安全研究员、社会科学家、领域专家），专门设计提示以引出失败情况。这通常涉及：
- 越狱： 试图诱导模型忽略其安全指南（例如，通过角色扮演场景、情境或复杂指令）。
- 提示注入： 在看似无害的提示中嵌入 (embedding)恶意指令。
- 测试边缘情况： 使用不寻常的语言、复杂的推理 (inference)任务或突破模型知识或能力边界的请求。
- 利用已知偏见： 设计可能触发模型已学到的已知社会偏见的提示。
-
自动化和工具辅助方法：
- 使用其他大语言模型 (LLM)： 借助另一个语言模型自动生成潜在的对抗性提示。
- 模糊测试： 调整软件测试技术，生成大量略微变异的提示，以发现意外崩溃或行为。
- 基于梯度的攻击： （对于黑盒 (black box)模型不太常见，但如果可进行白盒访问则适用）使用梯度信息构建对抗性输入，类似于计算机视觉中使用的技术。
结构化安全测试
虽然红队测试通常是探索性的，但安全测试通常更具结构性。它涉及根据预定义的危害类别和旨在衡量模型对已知安全风险的抵抗力的特定测试用例来评估模型。类别通常包括：
- 毒性和仇恨言论： 测试是否生成辱骂性或歧视性语言。
- 偏见： 使用有针对性的提示评估不同人群（性别、种族、宗教等）之间的公平性。
- 错误信息/虚假信息： 检查模型生成或认可虚假或误导性信息的倾向，尤其是在健康或政治等敏感方面。
- 安全弱点： 探查潜在的滥用，例如生成恶意代码、钓鱼邮件或解释漏洞利用（通常与特定的“有害能力”评估相关联）。
- 隐私： 测试模型是否无意中泄露个人身份信息（PII）或机密数据。
安全测试通常使用经过精心筛选的挑战性提示数据集（例如，ToxiGen、RealToxicityPrompts）或根据安全政策或道德准则衍生的清单来测试模型。
将发现整合到RLHF循环中
红队测试和安全测试不仅仅是评估步骤；它们是迭代模型改进周期中不可分割的部分。当发现不良行为时：
- 数据生成： 有问题的提示和模型的不良输出可以用于创建新的训练数据。
- 偏好对： 提示、不良输出（标记 (token)为拒绝）以及可能手动编写的良好输出（标记为选择）可以形成新的偏好对，用于重新训练奖励模型。
- SFT 数据： 如果失败代表着明显的指令遵循失误或可以通过直接示例纠正的安全违规，则可以将提示和所需的安全响应添加到SFT数据集，用于下一轮微调 (fine-tuning)。
这个反馈循环使模型能够从对抗性测试中发现的错误中学习。
图示说明红队测试结果如何反馈到RLHF训练过程，以迭代改进模型安全性和对齐 (alignment)度。
迭代特性与挑战
红队测试不是一次性勾选完成的任务。随着模型的更新和再训练，新的弱点可能出现。此外，对抗性技术不断演变。有效的红队测试需要：
- 创造力和专业知识： 人类红队成员需要像对手一样思考。
- 视角多样性： 具有不同背景的团队更擅长发现不同的失败模式。
- 资源： 彻底的红队测试，特别是手动工作，可能耗时且昂贵。
- 避免过拟合 (overfitting)： 模型可能学会对抗红队测试中使用的特定技术，而不是解决底层的安全问题。改变方法很重要。
通过纳入严格的红队测试和安全测试，您可以超越标准的性能指标，主动发现和处理潜在危害，构建更值得信任且对齐 (alignment)度更稳定的语言模型。这是在考虑在应用中部署之前的重要一步。
