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