护栏是LLM应用架构中重要的控制机制，在模型的输入和输出边界上运行，以强制执行安全策略和行为限制。与修改模型内部参数 (parameter)（例如RLHF或DPO）的对齐 (alignment)技术不同，护栏充当外部包装或过滤器，在已部署的系统中提供实际的防御和控制层。它们是系统级安全设计的重要组成部分。
可以将护栏看作检查点。在用户提示到达LLM之前，输入护栏可以检查它。在LLM生成响应之后，但在发送给用户之前，输出护栏可以审查它。这种预处理和后处理允许基于预定义的规则或分类进行干预，且独立于LLM的内部状态。
护栏的类型
护栏通常分为两类：输入和输出。
输入护栏
这些护栏在LLM处理用户提示之前对其进行分析。它们的主要目的是防止有害、恶意或违反策略的输入触发不良模型行为。常见功能包括：
- 提示验证： 对长度、格式或禁用字符进行基本检查。
- 敏感数据检测： 识别并经常编辑个人身份信息（PII），例如姓名、地址、电话号码或信用卡详细信息。这通常通过使用正则表达式（regex）或命名实体识别（NER）模型来实现。
- 有害内容过滤： 检测包含仇恨言论、骚扰、露骨内容或宣扬非法行为的提示。这通常涉及关键词列表、正则表达式模式或专门的文本分类器，这些分类器经过训练可以识别有毒或不安全的语言。
- 提示攻击检测： 识别尝试操纵LLM的行为，例如越狱提示或提示注入攻击。这可能涉及查找已知的对抗模式、异常格式，或使用针对此类攻击示例训练的分类器。
输出护栏
这些护栏在向用户展示LLM生成的响应之前对其进行分析。它们的目的是确保输出是安全的、合规的和有用的。常见功能包括：
- 内容过滤： 类似于输入过滤，检查LLM的输出中是否存在有害、有毒或不适当的内容，即使模型已进行对齐 (alignment)，也可能生成这些内容。
- 事实和基础检查： 尽管有难度，但一些护栏会尝试检测潜在的幻觉 (hallucination)，尤其是容易验证的幻觉，例如无效的URL或无意义的声明，有时通过与知识库交叉引用或执行网络搜索（尽管这会增加延迟）。
- 格式和合规性强制： 确保输出符合所需格式（例如JSON，特定的对话结构）、长度限制，或避免生成特定的不允许信息（例如重复先前编辑的PII）。
- 主题限制： 防止模型偏离禁止的主题或生成超出其指定范围或功能的响应。
- 重复控制： 检测并可能阻止过于重复或表明模型陷入循环的响应。
实施策略
实施护栏需要根据具体要求、对延迟的容忍度和所需的精细程度选择合适的工具和技术。
-
基于规则的系统：
- 机制： 使用正则表达式、关键词列表、字典和预定义的逻辑规则。
- 优点： 实施简单，计算成本低，透明（易于理解为何被标记 (token)）。对明确的违规行为有效（例如，特定的禁用词、PII模式）。
- 缺点： 脆弱，容易被同义词或创造性措辞绕过，难以处理上下文 (context)（例如，编程中的“执行”与暴力行为），列表和规则需要手动更新。
-
基于模型的系统：
- 机制： 采用机器学习 (machine learning)模型（通常是更小、专用的分类器），这些模型经过训练用于检测特定类别，例如毒性、情感、PII、主题相关性或提示注入模式。这些模型处理输入或输出文本并产生分类或分数。
- 优点： 比简单规则更能处理上下文，对措辞的变化更具适应性，可以通过使用新数据重新训练来更新。
- 缺点： 引入延迟，需要机器学习专业知识进行训练和维护，透明度较低（“黑箱”问题），容易受到针对护栏模型本身的对抗性攻击。
-
混合方法：
- 机制： 将基于规则的检查用于简单情况下的速度和确定性，与基于模型的检查结合用于更复杂的检测。例如，对PII使用正则表达式，对有害语言使用毒性分类器。
- 优点： 在性能、覆盖范围和复杂性之间提供平衡。
- 缺点： 需要仔细集成并管理不同组件的配合。
-
外部API：
- 机制： 使用专门从事内容审查、PII检测或其他安全相关任务的第三方服务。
- 优点： 使用外部专业知识，可能减少内部开发工作。
- 缺点： 引入外部依赖，潜在的数据隐私问题，增加网络延迟，产生费用。
涉及护栏的典型流程可能如下所示：
请求流程图，显示输入和输出护栏在LLM处理前后充当检查点。被拒绝的请求可能被完全阻止或被修改（例如，PII编辑）。
护栏实施中的难点
- 准确性权衡： 调整护栏需要平衡误报（阻止安全内容）和漏报（允许不安全内容）。过于严格的护栏会降低用户体验；过于宽松的护栏会损害安全性。
- 延迟： 每次检查都会增加处理时间。复杂的模型或外部API调用会显著增加应用程序的整体响应时间。选择高效的实施方案很重要。
不同护栏类型引入的延迟示例。简单方法速度更快，而基于模型或外部检查会增加更多开销。
- 适应性和维护： 对手不断设计新方法来规避固定规则或已知的模型弱点。护栏需要持续监测、评估（使用第四章的方法），并使用新规则、模式或重新训练的模型进行更新。
- 上下文 (context)盲点： 尤其是对于基于规则的系统，理解语言的真实上下文仍然困难。一个在某种上下文中被认为有害的词，在另一种上下文中可能是无害的。
- 组合： 确保多个护栏（例如PII过滤器和毒性过滤器）在没有意外干扰的情况下正确配合可能很复杂。
最佳实践
- 分层防御： 在输入和输出阶段实施多个、多样化的护栏。将快速、简单的检查与更精细的检查结合起来。
- 可配置性： 设计具有可调阈值或参数 (parameter)的护栏，以便根据应用程序的风险承受能力和观察到的性能进行调整。
- 监测和日志记录： 精心记录护栏活动。跟踪护栏何时触发、对什么内容触发，并尽可能收集用户反馈。这些数据对于发现弱点和提高准确性非常有价值。
- 故障安全设计： 决定当护栏失效或超时时系统应如何行为。应该阻止请求（失效关闭）还是允许请求（失效开放）？选择取决于具体风险。
- 定期更新： 将护栏定义（规则、列表、模型）视为需要根据新威胁、评估结果和红队发现进行定期审查和更新的动态组件。
- 透明度（谨慎使用）： 考虑是否以及如何告知用户护栏何时修改或阻止内容。虽然透明度可以建立信任，但它也可能向对手暴露漏洞。平衡透明度与安全需求。
实施有效的护栏是一个持续的工程、评估和适应过程。它们不是一个完美的解决方案，但提供了必要的控制层，用于构建更安全、更可靠的LLM应用。当它们被集成到包括评估、仔细的模型对齐 (alignment)和良好系统设计原则在内的全面安全策略中时，效果最佳。
