本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
通过添加 Amazon Bedrock 护栏中的自动推理检查功能来提高准确率
Amazon Bedrock 护栏中的自动推理检查功能会根据您定义的策略以数学方式验证自然语言内容，确保严格遵守护栏的要求。这些检查可帮助您系统性拦截有害或不合规的内容，以防用户收到这样的内容。与模式匹配方法不同，自动推理可提高准确率和减少误报，尤其是在复杂的策略要求下。对于注重查准率的客户，可通过清晰的逻辑表述来自定义策略规则，以提高护栏机制的有效性。
大型语言模型 (LLMs) 面临的一个关键挑战是确保其响应的准确性。未经验证，有时 LLMs 会产生幻觉或不准确的信息，从而破坏信任。
Amazon Bedrock 护栏中的自动推理检查功能使用数学方法来解决该问题：
-
检测 LLM 响应中的幻觉
-
突出显示未明确说明的假设
-
解释为何准确的陈述是正确的
当您需要在以下场景中证明 LLM 响应的事实依据时，此功能特别有用：
-
医疗保健和人力资源等受监管行业
-
规则复杂的应用（抵押贷款审批、分区法）
-
需要可审计的人工智能响应的合规场景
Amazon Bedrock 护栏中的自动推理检查功能无法抵御提示注入攻击。这些检查功能完全按照您发送过来的内容进行验证，如果提供恶意内容或被篡改过的内容作为输入，验证将基于该内容的原样进行（垃圾输入、垃圾输出）。要检测和阻止提示注入攻击，请将内容筛选条件与自动推理检查功能结合使用。
自动推理只会分析和检测与自动推理策略相关的文本。它会忽略其余内容，也无法告诉开发人员答案是否偏离主题。如果您需要检测偏离主题的响应，请使用其他护栏机制组件，例如主题策略。
注意
Amazon Bedrock 护栏中的自动推理检查功能已在美国（弗吉尼亚州北部、俄勒冈州和俄亥俄州）和欧洲地区（法兰克福、巴黎和爱尔兰）区域正式推出。
注意
Amazon Bedrock 护栏中的自动推理检查功能是对 Amazon Bedrock 护栏的其他功能（如内容筛选条件和主题策略）的补充。有关更多信息，请参阅护栏机制组件。
Amazon Bedrock 护栏中的自动推理检查功能目前仅支持英语（美国）。
Amazon Bedrock Guardrails 中的自动推理检查不支持直播。 APIs
限制和注意事项
在实施自动推理检查功能之前，请注意以下重要限制：
-
文档复杂性：源文档应结构合理，且包含明确、无歧义的规则。包含嵌套条件或矛盾表述的高度复杂的文档，可能无法清楚地提取为形式逻辑。输入文档的大小限制为 5Mb 和 50,000 个字符。您可以拆分较大的文档，并将每个部分合并到您的保单中。文档中的图像和表格也会影响输入字符的数量。
-
处理时间：自动推理验证会增加应用程序响应的延迟。请预留额外的处理时间，尤其是对于包含大量规则的复杂策略。
-
策略范围：每个策略都应专注于特定领域（例如，HR、财务和法律），不要试图在单一策略中涵盖多个不相关的领域。
-
变量限制：策略的变量过多或规则交互过于复杂，可能会达到处理限制或返回 TOO_COMPLEX 结果。
-
自然语言依赖性：验证的准确率，在很大程度上依赖于用户提示和模型响应中的自然语言转换为策略的形式逻辑变量的效果。
-
非线性算术：如果约束条件涉及使用非线性算术（例如，无理数或指数）进行推理，则自动推理检查可能会超时或返回 TOO_COMPLEX
最佳实践
请遵循以下最佳实践，尽可能提高自动推理策略的有效性：
-
从简单开始：从涵盖核心规则的针对性策略开始，然后逐渐提高复杂性。在每个阶段都进行全面测试。
-
撰写全面的变量描述：要说明用户如何自然地引用概念，而不仅仅是源文档中的技术定义。
-
测试边缘案例：创建专门针对边界条件、异常情况和用户可能遇到的特殊场景的测试。
-
监控置信度阈值：从较高的置信度阈值（0.8-0.9）开始，然后根据您对误报和漏报的容忍度进行调整。
-
定期策略维护：在业务规则发生变化时，或通过测试和生产使用发现漏洞时，审查和更新您的策略。
-
记录注释：跟踪策略修改及其背后的原因，以供将来查阅和团队知识分享。
定价
Amazon Bedrock 护栏中的自动推理检查功能的费用根据处理的验证请求数量计算。有关当前定价信息，请参阅 Amazon Bedrock 定价页面
每次验证请求都会产生费用，无论结果如何（例如，VALID、INVALID、TRANSLATION_AMBIGUOUS）。要优化成本，请采用以下方法：
-
使用合适的置信度阈值来实现准确率和处理要求之前的平衡
-
如果适合您的使用案例，请考虑缓存相同或相似的查询的验证结果
-
监控使用模式并调整策略，减少不必要的验证请求
用于策略操作的跨区域推理
自动推理利用跨区域推理来优化策略创建和测试操作的性能与可用性。特定 API 操作会自动将处理任务分配到您的地理边界内的各个 AWS 区域，以确保可靠的服务交付。
以下自动推理 API 操作采用了跨区域推理：
-
StartAutomatedReasoningPolicyBuildWorkflow– 在从源文档创建和编译策略期间调用 -
StartAutomatedReasoningPolicyTestWorkflow– 在策略验证和测试过程中调用
这些操作调用大语言模型，从源文档中提取形式逻辑规则，并将自然语言构造转换为结构化逻辑表示。为确保最佳性能和可用性，系统根据以下地理路由原则分配请求处理：
-
美国区域：来自美国东部（弗吉尼亚州北部）、美国西部（俄勒冈州）或美国东部（俄亥俄州）的 API 请求可以在任何受支持的美国区域处理。
-
欧盟区域：来自欧洲地区（法兰克福）、欧洲地区（巴黎）或欧洲地区（爱尔兰）的 API 请求可以在任何受支持的欧盟区域处理。
重要
客户数据保留在原始地理边界内（美国或欧盟），并按照 AWS 数据驻留承诺进行处理。跨区域推理仅在相同地理区域内路由请求，来优化性能和服务可用性。
跨区域推理以透明方式运行，无需客户进行任何配置。无论处理请求的具体区域如何，API 功能都保持一致。
要使用 Amazon Bedrock 护栏中的自动推理检查功能，请按照以下步骤操作：
-
上传包含您要强制执行的规则的源文档
-
查看包含自动识别的概念和规则的已提取策略
-
测试和优化策略以确保其正常运行
-
部署策略来验证基础模型的响应
工作流的直观表示如下：
Source Document → Extracted Policy → Testing → Deployment → Runtime Validation (rules) (formal logic) (verify) (activate) (check responses)
策略
自动推理策略是准确验证的基础，它包含从源文档自动提取的逻辑规则和变量。这些策略作为您业务规则的数学表示，使系统能够有条理地验证基础模型响应是否符合您定义的约束条件。要在应用程序中执行自动推理检查功能，您需要将护栏配置为使用与您的特定领域和验证要求相符的策略。
Rules
规则是自动推理从您的源文档提取的逻辑。可能会写成 if-then 语句。下面是规则格式的一些示例：
<claim> is true if <premise>
注意
重要提示：未采用 if-then 格式的规则，可能会因为设定整个环境中的底层公理而产生意想不到的后果。例如，如果某条规则只是简单地规定 accountBalance > 5，那么无论验证内容如何表述，账户余额都不可能等于或小于 5。该规则在逻辑上否定了这种情况的存在。这可能会导致意想不到的验证结果：内容被错误地标记为不符合要求，因为它与规则所确立的公理冲突。为了避免这种情况，在构造规则时，请使用描述关系的条件语句（if-then 格式），而非绝对的约束条件。
变量
变量代表自动推理策略中的概念，可在将自然语言转换为形式逻辑时向其赋值。您的策略规则定义约束条件，明确对这些变量来说哪些是有效值，哪些是无效值。
变量有名称、类型和描述。例如，关于员工福利的策略可能有一个名为“employee_age”、类型为“整数”、描述为“员工年龄”的变量。该变量可以根据输入应用程序的提示中的自然语言被赋予一个值（如 25）。
例如，HR 策略中的 is_full_time 变量可能具有描述“每周工作超过 20 小时的员工”，这是直接引用自源文档的内容。在使用聊天机器人时，用户更有可能会说“我是全职员工”，而不是“我每周工作超过 20 个小时”。
从自然语言到形式逻辑的翻译的准确率，在很大程度上取决于变量描述的质量。虽然完善的翻译可以实现良好的推理流程，不过清晰全面的变量描述可确保用户提示得到正确解读。如果没有完整的变量描述，自动推理可能会返回 NO_DATA，因为它无法将输入的自然语言转换为其形式逻辑表示。
变量描述必须考虑到这种情况。例如，全面的变量描述可以说“每周工作超过 20 小时的员工属于全职员工。用户输入‘全职’时将该值设置为 true，用户输入‘兼职’时将该值设置为 false。”
预定义变量类型
下表介绍了策略中可以包含的预定义变量类型。
| Type | 说明 |
|---|---|
|
BOOL |
布尔变量可以为 true 或 false。例如，在休假策略中，您可以使用 |
|
INT |
数值型 |
|
NUMBER |
|
|
enum |
枚举变量是用户定义的类型，可以存储从自定义类型中定义的一组固定选项中选择的单个值。例如，在请假政策中，您可以使用枚举变量来存储 |
