生成式AI安全防护最佳实践指南

像专家一样构建安全的生成式AI应用：某机构服务防护机制最佳实践

在将生成式AI应用部署到生产环境时，许多组织都面临着在安全性与准确性、性能和成本之间寻求平衡的挑战。过于严格的防护会阻止合法用户请求，导致客户流失；而过于宽松的防护则会使应用暴露于有害内容、提示词攻击或意外数据泄露的风险中。找到恰当的平衡点不仅仅是启用功能，更需要深思熟虑的配置和持续的优化。

某机构服务防护机制提供了实施负责任AI的强大工具：涵盖文本和图像的内容过滤（包括提示词攻击预防）、主题分类、敏感信息保护、上下文相关性检查以及自动推理检查。本文将展示如何配置这些功能以获得更高效的性能，实施最佳实践以保护应用，并有效监控部署，在安全性和用户体验之间维持恰当的平衡。

使用某机构服务防护机制的最佳实践

为充分发挥某机构服务防护机制的作用，建议采纳以下最佳实践。

1. 选择合适的防护策略

在生产工作流中选择哪些防护策略取决于具体的应用场景，但以下基础策略能为大多数应用提供适宜的保护。

• 内容策略：可拦截包含仇恨、侮辱、性、暴力、不当行为等有害内容，帮助应用维持内容安全。建议所有生产部署都启用此策略。
• 图像内容过滤：除了文本，内容过滤器还可应用于图像，将相同的内容审核策略同时应用于生成式AI应用中的文本和图像。这种多模态能力有助于在全部六个内容过滤类别（仇恨、侮辱、性、暴力、不当行为和提示词攻击）中拦截有害的视觉内容。配置时，可选择将过滤应用于仅文本、仅图像或两者。
• 提示词攻击预防：有助于识别可能试图削弱安全功能和开发者指令的“越狱”尝试、提示词注入攻击和提示词泄露攻击。建议启用此策略以维护应用安全。
• 敏感信息策略：提供对个人身份信息的屏蔽或移除功能，有助于保护客户数据并支持合规性工作。
• 词汇策略：拦截特定词或短语，常用于过滤亵渎性语言、行业特定限制性术语或自定义词汇。
• 主题策略：帮助执行自定义的负责任AI策略，维护组织指南的合规性，并控制对话范围与主题。
• 上下文相关性：对于特定用例，可添加上下文相关性检查，以验证响应是否受可信参考材料的支持，有助于减少内容摘要时的模型幻觉，并维持对话的相关性。
• 自动推理策略：可用于强制执行法规要求的合规性，针对特定业务规则验证输出，并实现超越关键词匹配的复杂过滤。

从与核心安全和合规要求相符的基础策略开始，然后根据特定用例需求添加专业策略。定期审查和调整策略有助于改进保护，同时维持所需的功能。

1.1 选择恰当的保护层级

防护机制目前为内容策略、提示词攻击预防和主题策略提供两个保护层级：经典层级和标准层级。对于大多数用例，标准层级是更佳选择。它提供了更强的鲁棒性、更高的准确性、更广泛的语言支持、更高的配额，并通过根据负载将流量引导至不同区域来提高可用性。

1.2 使用检测模式无影响地测试防护行为

在让防护机制干预生产应用之前，可以使用防护检测模式在真实客户流量上测试其行为。在此模式下，防护机制会评估所有内容并在跟踪响应中报告识别结果，但不会执行任何拦截操作。通过检测模式，可以了解防护机制在真实流量上的表现，并根据需要更新配置。对行为满意后，即可将防护更新为适当的拦截或屏蔽模式。

2. 配置内容策略的过滤强度

某机构服务防护机制内容策略提供四种过滤强度级别，以帮助在内容安全与应用功能之间取得平衡：无、低、中、高。不同的过滤强度反映了防护机制对输入包含有害内容的置信度。如果配置为低过滤强度，防护机制将仅在其对输入有害性具有高置信度时进行拦截。相应地，若配置为高过滤强度，则即使是低置信度的输入也可能被拦截。

2.1 推荐的过滤强度选择流程

1. 初始配置：从高过滤强度开始，以建立最大程度的保护。
2. 评估：使用具有代表性的样本流量（预期的用户流量）测试实现，以识别误报率、评估对合法内容的影响、衡量用户体验。
3. 调整：如果初始配置产生过多误报，将过滤强度降低至中，用样本流量重新评估，如有必要，继续调整至低。

3. 制定有效的拒止主题：黄金法则

1. 清晰精准：明确定义主题，例如“与投资、出售、交易或购买加密货币相关的问题或信息”，而非模糊描述如“投资建议”。
2. 定义而非指示：避免使用命令式短语，如“拦截所有与加密货币相关的内容”，而应描述为“所有与加密货币相关的内容”。聚焦于主题是什么，而非希望系统做什么。
3. 保持正面：切勿使用否定句式定义主题（例如“除投资建议外的所有内容”）。防护机制应有明确、肯定的定义以识别目标。
4. 聚焦主题而非词汇：拒止主题旨在从上下文层面捕捉主题和概念，并非设计用于捕捉特定名称、实体或单个词汇。对于这些用例，应使用敏感信息过滤器或词汇过滤器。
5. 提供示例短语：添加一些代表希望被主题过滤器拦截的输入类型的示例短语。例如，对于拦截投资建议的拒止主题，可以添加“推荐一支会暴涨的股票”或“你能建议我把钱投到哪里吗？”。

4. 在内置过滤器之外进行自定义

对于某些应用，提供的内容过滤器类别或内置个人身份信息类型可能无法完全覆盖防护需求。此时，有两个选择：

• 创建自定义拒止主题：如果用例需要拦截超出既有内容过滤器类别的内容，可以定义量身定制的拒止主题。例如，如需拦截政治讨论，可以创建一个定义为“任何与政治或选举相关的内容”的拒止主题。
• 创建自定义正则表达式过滤器：如果内置的个人身份信息类型无法覆盖需要捕捉的敏感数据模式，可以定义正则表达式过滤器来填补空白。例如，要拦截所有“月/日/年”格式的日期，可以添加相应的正则表达式模式。

5. 选择合适的实施方法

某机构服务防护机制提供多种方式来保护应用，每种方式适用于不同的架构模式和控制需求。

• 独立ApplyGuardrail API实现最大灵活性：当需要在应用逻辑的任意节点精确控制防护机制的评估位置和方式时，可调用ApplyGuardrail API。此方式可与任何大语言模型配合使用，可在关键检查点实施防护：预处理多源用户输入、验证AI工作流中间输出、过滤检索增强生成管道中的检索文档，或在交付前后处理大语言模型响应。对于延迟敏感型应用，可将输入验证调用与大语言模型推理调用并行化，然后一起处理结果。但这意味着即使防护机制会拦截输入，也需要为两个调用付费。而串行方式可在防护干预时完全跳过推理调用，节省成本。可以根据应用的具体风险状况设计自定义保护策略，在不同上下文、用户状态或工作流阶段应用不同的防护配置。
• 与推理API的原生集成：当将某机构服务防护机制与InvokeModel、Converse等推理API配合使用时，系统会自动处理双重检查点模式。首先将用户输入发送给防护机制以根据定义的策略进行评估。若拦截输入，则返回配置的消息；若允许输入，则继续调用模型。模型生成响应后，系统会在结果返回给用户前再次通过防护机制评估输出（包括适用的依据来源）。这些原生集成简化了实施，同时保持了全面的保护。
• 重要提示：每次ApplyGuardrail API调用都会产生独立费用，因此在设计架构时需考虑成本。定价基于已配置保护所消耗的文本单元或处理的图像数量。

6. 管理多轮对话中的防护

对话式AI中最常见的陷阱之一是对对话历史过度应用防护。如果每一轮都评估整个聊天历史中的每一条消息，那么对话早期一个被拦截的主题可能会阻碍用户继续对话，即使后续的新问题是完全有效的。

设想一个配置了拦截“香蕉”讨论的防护场景：

用户：你们卖香蕉吗？

聊天机器人：抱歉，模型无法回答您的问题。

用户：我能预订航班吗？

如果防护评估整个对话历史，第二个问题也会被拦截——仅仅因为“香蕉”仍然存在于聊天记录中。用户因此被卡住，无法从一次失误中恢复。

解决方案：与其检查完整对话历史，不如将防护配置为仅评估最新的用户输入或有限数量的最近几轮对话。这种方法允许对话自然流动，让用户从被拦截的交互中恢复。此外，通过避免在不同轮次中多次评估相同内容，可以降低成本和延迟。

如果在防护中仅评估最后一轮对话（此例中为“我能预订航班吗？”），那么对话将继续顺畅进行，用户可以无障碍地越过之前的防护干预。使用此策略，可以通过保持对话自然来维持对话流畅性并改善用户体验。

LiteLLM、LangChain AWS等工具中的防护集成要么默认仅评估对话的最后一轮，要么提供一个标志来执行此操作。

使用带guardContent的Converse API进行多轮对话

以下示例演示了如何通过在guardContent块中包装仅最新用户消息，在多轮对话中选择性评估最新消息。在此方法中，对话历史作为普通文本传递（不会被防护评估），而只有最新的用户输入被包装在guardContent中：

import boto3
bedrock = boto3.client("bedrock-runtime", region_name="<aws region>")

# 对话历史（先前的消息不会被防护评估）
messages = [
	{ 
			  "role": "user",
			  "content": [
				{"text": "你们卖香蕉吗？"}
			]
	},
	{ 
			  "role": "assistant",
			  "content": [
				{"text": "抱歉，我无法帮助处理这个主题。"}
			]
	},
	{ 
			  "role": "user",
              "content": [
				{ # 只有这个块会被防护评估
				  "guardContent": { "text":
						{ "text": "我能预订去巴黎的航班吗？" }
					}
				}
				]
	}
]

response = bedrock.converse(
	modelId="<bedrock_model_id>",
	guardrailConfig={
		"guardrailIdentifier": "your-guardrail-id",
		"guardrailVersion": "1",
		"trace": "enabled" },
	messages=messages
)

# 对话自然进行，因为只有“我能预订去巴黎的航班吗？”被评估，而不是先前被拦截的香蕉话题
print(response['output']['message']['content'][0]['text'])

在此示例中，即使对话历史包含先前被拦截的主题（“香蕉”），用户也能自然继续对话，因为只有包装在guardContent中的最新查询被防护评估。需评估的最佳对话轮次可能因用例和安全要求而异，某些攻击可能跨越多个对话轮次。建议从单轮评估开始，并根据应用需求进行调整。

7. 在生产环境中使用防护数值版本

创建防护时，某机构服务会自动创建一个标记为“草稿”的版本。可以通过CreateGuardrailVersion API创建额外的数值版本（版本1、版本2）。版本号由服务在创建新版本时自动递增。每个数值版本都是创建时“草稿”防护版本策略的不可变快照。对“草稿”版本策略的任何修改都不会影响现有的数值版本。强烈建议在生产应用中使用数值版本而非“草稿”版本。“草稿”版本专为开发和测试设计，在生产中使用可能导致以下问题：

• 服务中断：当操作员使用UpdateGuardrail API修改“草稿”版本时，防护会进入“更新中”状态。在此期间，任何使用“草稿”防护的推理调用都将收到验证异常，提示防护未处于“就绪”状态。
• 保护不一致：对“草稿”版本设置的更改可能立即影响生产应用，可能损害预期的保护控制。

要在ApplyGuardrail调用中使用数值版本，请将guardrailVersion字段的值设置为版本号。

通过在生产中使用数值版本，有助于保持防护更一致和可预测的行为，同时保留在“草稿”版本中测试和迭代新策略的灵活性。

结论

有效实施某机构服务防护机制需要深思熟虑的配置和对应用独特风险状况的深刻理解。通过选择合适的策略和保护层级、通过迭代测试调整配置、选择适合架构的实施方式、以及使用数值版本安全部署，可以在安全性、成本和用户体验之间取得平衡。将防护视为一个活的系统——从强大的基线开始，在真实流量上使用检测模式进行测试，并随着应用的演进进行调整。遵循这些经过实战检验的实践，将有助于确保生成式AI应用保持安全、高性能，并准备好自信地扩展到生产环境。FINISHED