8.0
热点
AI SCORE
编程提效2026-08-04 00:30
AWS Bedrock 推出自动化规则优化能力
AWS ML Blog#AWS#自动化修复#AI 编程
Editor brief · 编辑速览
AWS Bedrock 现支持自动推理策略精炼，能自动诊断测试失败并提议形式逻辑修复，加速规则系统迭代。
在 Amazon Bedrock 中优化自动推理策略一直是一个手工循环：诊断、手工编辑、重新测试，然后重复。今天，我们宣布推出自动策略优化，它自动化了这个循环中的诊断和修复工作。优化引擎诊断失败的测试并提议形式逻辑修复。在任何更改生效之前，你需要批准每个更改。
Amazon Bedrock 护栏中的自动推理检查使用形式验证来证明答案的正确性。对于从自然语言到形式逻辑的明确翻译，它们的验证准确率高达 99%，如 GA 公告中报告的那样。开始时，你从源文档构建自动推理策略，并用测试用例进行验证。客户告诉我们，这种迭代调优是策略开发中最大的痛点。
在本文中，我们介绍两种新的优化模式：用于规则问题的迭代优化，以及用于语言问题的模糊变量优化。对于每种模式，我们展示完整的 API 工作流（启动、轮询、检索）和可重复的控制台工作流，用于将失败的策略转变为通过的策略。
自动推理检查将自然语言翻译成形式逻辑，然后应用自动推理技术生成结果：VALID、INVALID、SATISFIABLE、IMPOSSIBLE 或 TRANSLATION_AMBIGUOUS。有关策略如何工作的完整介绍，请参阅我们的 GA 公告文章。
对于本文，关键概念是两步验证管道。首先，翻译步骤使用策略中的变量描述将自然语言输入/输出映射到变量赋值。其次，验证步骤将你的形式规则应用于这些赋值。当测试失败时，根本原因存在于这两个步骤中的一个，每种优化模式针对其中一个。图 1 展示了整个管道的端到端流程。
图 1：自动推理检查如何在运行时验证响应。 自动推理检查使用策略的变量描述将自然语言翻译成变量，然后针对策略的形式规则验证这些变量以返回结果。这个两步管道是为什么优化有两种模式。
你通过附加测试来验证策略：每个测试是输入/输出文本加上你期望的结果。单独运行测试或批量运行。失败会告诉你策略在哪里与你的意图不符。
回顾两步管道：翻译（自然语言到变量赋值）然后验证（形式逻辑到结果）。失败的测试意味着其中一个步骤产生了你没有预期的东西。自动推理检查表面两个不同的失败信号，这些信号清晰地映射到每个步骤。
在规则问题失败中，翻译工作正常：正确的变量具有正确的值，但验证结果与你的预期不符。问题存在于你的规则中：一条规则太宽松、太严格或完全缺失。具体来说，你预期 INVALID 但得到 SATISFIABLE，因为缺失的或太宽松的规则让坏的答案通过了。或者你预期 SATISFIABLE 但得到 INVALID，因为过度严格的规则阻止了正确答案。
心智模型： 系统完美地理解了问题但应用了错误的逻辑。你需要修复规则。
当测试返回 TRANSLATION_AMBIGUOUS 时，验证引擎运行并根据它遵循的解释产生不同的结果。在某些情况下，翻译模型对如何将自然语言输入映射到策略的变量有分歧，每个竞争的解释导致不同的验证结果。结果显示两个或多个选项，每个都有自己的翻译和结论，加上 differenceScenarios 显示解释在实践中的分歧之处。常见的根本原因包括重叠的变量定义（"tenure" 与 "years of service" 相比）、模糊的描述和不一致的值格式（5 与 0.05 相比较 "5%"）。
此表总结了哪种优化模式解决哪种失败类型：
当系统无法确定单一翻译时，使用模糊变量优化。接下来的两个部分依次介绍每种模式：它做什么、何时使用、审查门如何工作以及如何以编程方式启动它。我们从迭代优化开始，因为规则问题失败是更常见的情况。
当测试因逻辑错误而失败（翻译是干净的但验证结果与你的预期不符）时，问题存在于你的规则中。迭代优化（ITERATIVELY_REFINE_POLICY）自动化了诊断和修复循环，因此你不需要手动追踪每条规则、假设修正并手工编辑形式逻辑。
考虑一个有 10–30 条规则的策略。以前，修复需要主题专家进行多轮手动诊断和 SMT-LIB 形式逻辑的手工编辑。这项工作现在压缩为单一的审查和批准步骤，无需手工编写形式逻辑。
迭代优化需要三个输入。第一个是你现有的策略定义（当前的规则、变量和类型）。第二个是源文档，包含描述事物应该如何工作的权威自然语言文本。第三个输入是可选的：自然语言反馈，包含显式指令描述你想要的更改。
例如，反馈字段可能包含："根据修订文档第 3 节中的规定，将亲假的任职要求从 12 个月更新为 6 个月。"
给定这些输入，优化引擎分析当前规则如何与源文档和你的反馈不同。它提议一组候选更改（新规则、编辑的规则、添加的变量）以使策略符合要求。
迭代优化，顾名思义，会进行迭代。在幕后，引擎生成候选更改、模拟其对已保存测试的影响、检查以前失败的测试现在是否通过，如果没有则进行调整。对于单个请求，这可能涉及多个内部循环，尤其是当一条规则中的修复涟漪到其他规则时。然而，迭代在内部进行：你看不到每个中间尝试，也不需要引导它。你收到的是收敛的结果：一个提议的 diff，显示完全哪些规则改变了、哪些变量改变了以及更改如何影响你的测试套件中的每个测试。
收敛后，审查策略更改屏幕出现。
然后你选择接受更改或放弃更改。接受会将更改写入你的 DRAFT 策略。放弃会保持一切原样。
迭代优化需要至少一个测试附加到你的策略。没有失败的测试信号，就没有东西来驱动优化。当翻译正确（正确的变量、正确的值）但验证结果不符合预期时，使用此模式。当结果是 TRANSLATION_AMBIGUOUS 时，不要使用它。那是一个语言问题，最好由模糊变量优化来解决。
优化作为异步构建工作流运行。使用 AWS SDK for Python (Boto3)，流程有四个步骤：导出当前策略定义、启动工作流、轮询完成情况和检索提议的更改。将 buildWorkflowType 设置为 ITERATIVELY_REFINE_POLICY。
iterativeRefinementContent 块接受一到五个源文档（必需）和最多 4,000 个字符的可选反馈：
import boto3
bedrock = boto3.client("bedrock")
# Export the current policy definition (required input to the workflow).
policy_definition = bedrock.export_automated_reasoning_policy_version(
policyArn=policy_arn,
)["policyDefinition"]
with open("hr-leave-policy.pdf", "rb") as f:
source_document = f.read()
response = bedrock.start_automated_reasoning_policy_build_workflow(
policyArn=policy_arn,
buildWorkflowType="ITERATIVELY_REFINE_POLICY",
sourceContent={
"policyDefinition": policy_definition,
"workflowContent": {
"iterativeRefinementContent": {
"documents": [
{
"document": source_document,
"documentName": "hr-leave-policy.pdf",
"documentContentType": "pdf",
}
],
"feedback": "Update the tenure requirement from 12 to 6 months per section 3.",
}
},
},
)
build_workflow_id = response["buildWorkflowId"]
API 调用立即返回 buildWorkflowId，而不是建议的更改。工作流从 SCHEDULED 状态转移到 BUILDING，直到达到 COMPLETED、FAILED 或 CANCELLED 状态。收敛通常需要一到几分钟，具体取决于策略的大小。轮询 get_automated_reasoning_policy_build_workflow 直到状态达到终端状态。然后使用 get_automated_reasoning_policy_build_workflow_result_assets 检索收敛的提议，请求 POLICY_DEFINITION 资源以查看更新的规则（以及 BUILD_LOG 以查看操作日志）：
import time
while True:
workflow = bedrock.get_automated_reasoning_policy_build_workflow(
policyArn=policy_arn,
buildWorkflowId=build_workflow_id,
)
status = workflow["status"]
if status in ("COMPLETED", "FAILED", "CANCELLED"):
break
time.sleep(10)
if status == "COMPLETED":
assets = bedrock.get_automated_reasoning_policy_build_workflow_result_assets(
policyArn=policy_arn,
buildWorkflowId=build_workflow_id,
assetType="POLICY_DEFINITION",
)
proposed_definition = assets["buildWorkflowAssets"]["policyDefinition"]
返回的策略定义是建议的 DRAFT，是完整的新定义。要提交它，使用此定义调用 update_automated_reasoning_policy。要查看更改内容，将其与启动工作流前导出的策略定义进行对比。控制台的"审查策略更改"屏幕包装了相同的启动-轮询-检索序列，在"接受更改"和"丢弃更改"按钮后面呈现 diff。
迭代细化处理规则问题，但并非每个失败的测试都是规则问题。当翻译本身不稳定时，再多的规则编辑也无法帮助。你需要修复策略用来描述其变量的语言。这就是歧义变量细化做的事。它遵循相同的异步启动-轮询-检索模式，并落在相同的审查和接受屏幕上。不同之处在于建议。它们围绕变量描述和合并展开，应用规则和类型更新以保持策略一致性。
当测试产生 TRANSLATION_AMBIGUOUS 结果时（参考本文前面的失败模式 2），竞争翻译导致不同的验证结果。歧义也可能来自经过验证的内容本身的措辞方式。本节重点关注策略变量中的歧义。
由于策略变量问题导致的翻译歧义，通常源于少数几个根本原因。重叠变量发生在两个变量描述同一概念时。例如，tenureMonths（"员工工作的月数"）和 monthsOfService（"员工的服务月数"）都捕获就业期限。因此，翻译模型在使用哪一个上存在分歧。不完整的描述在变量的描述过于模糊以至于无法指导翻译时出现。不一致的值格式化会造成歧义，当系统无法确定"5%"是应该变成 interestRate = 5 还是 interestRate = 0.05 时。逻辑烘焙到变量名中会造成混淆。一个像 timelyReportingNotFeasible 这样的名字已经包含了否定，所以表达正面情况需要对否定进行否定。翻译模型常常会丢弃其中之一。
这些只是最常见的模式。由于检测通过在翻译中使用策略的变量来工作，而不是针对已知问题的固定列表进行检查，导致翻译不一致的变量级问题可能会浮出水面。
运行歧义变量细化时，它会精确指出哪些变量描述或重叠定义导致了分歧，然后建议将多种解释合并为一个精确定义的精化描述。
这些精化的描述包含单位转换规则、同义词、替代措辞和显式格式指导。这个前/后示例说明了一个典型的建议：
如果检测到重叠变量，也可能建议合并：一个变量被删除，引用它的规则被更新以使用保留下来的变量。
就像迭代细化一样，你在应用任何东西之前审查建议的更改。
它还显示测试结果，之前返回 TRANSLATION_AMBIGUOUS 的测试现在产生明确的 VALID、INVALID 或 SATISFIABLE 结果。你选择接受更改或丢弃更改。在你批准之前，不会对你的 DRAFT 策略进行任何更改。
当测试产生 TRANSLATION_AMBIGUOUS 结果时，或者当你检查 VALID/INVALID 发现并发现翻译将值分配给了错误的变量时，使用歧义变量细化。当翻译是正确的但验证结果是意外的时，不要使用它。那是迭代细化的规则问题。
歧义变量细化使用相同的异步启动-轮询-检索模式。将 buildWorkflowType 设置为 RESOLVE_POLICY_AMBIGUITIES。此模式直接分析你的策略变量，不需要源文档或附加的测试，因此可以省略 workflowContent。当前策略定义在 sourceContent 中仍然是必需的。首先使用 export_automated_reasoning_policy_version 导出它，如前面的迭代细化所示：
response = bedrock.start_automated_reasoning_policy_build_workflow(
policyArn=policy_arn,
buildWorkflowType="RESOLVE_POLICY_AMBIGUITIES",
sourceContent={
"policyDefinition": policy_definition,
},
)
build_workflow_id = response["buildWorkflowId"]
与迭代细化一样，响应是 buildWorkflowId。轮询 get_automated_reasoning_policy_build_workflow 直到状态达到终端状态。然后使用 assetType="POLICY_DEFINITION" 调用 get_automated_reasoning_policy_build_workflow_result_assets 以检索建议的变量描述和合并：
while True:
workflow = bedrock.get_automated_reasoning_policy_build_workflow(
policyArn=policy_arn,
buildWorkflowId=build_workflow_id,
)
status = workflow["status"]
if status in ("COMPLETED", "FAILED", "CANCELLED"):
break
time.sleep(10)
if status == "COMPLETED":
assets = bedrock.get_automated_reasoning_policy_build_workflow_result_assets(
policyArn=policy_arn,
buildWorkflowId=build_workflow_id,
assetType="POLICY_DEFINITION",
)
proposed_definition = assets["buildWorkflowAssets"]["policyDefinition"]
这些更改保持为建议，直到你接受它们。
两种细化模式都共享一个不容商量的属性：在你说好之前，没有任何更改生效。细化引擎拥有建议权限。它可以分析、诊断和建议。你拥有提交权限。你决定什么到达你的 DRAFT 策略，最终到达生产环境。
无论你使用哪种细化模式，工作流都遵循相同的五步模式。首先，测试：针对当前策略运行你保存的测试。其次，检查：确定哪些测试与其预期结果不匹配。第三，建议：系统生成规则或变量描述的候选修复。第四，审查：你检查建议的 diff 及其对测试的影响。第五，应用：你接受更改进入 DRAFT，或拒绝，不做任何更改。
接受后，重新测试以确认修复解决了问题，而不破坏其他测试。这创建了一个棘轮：每个周期要么让你更接近通过的策略，要么给你新的诊断信息。
审查屏幕让你理解一个更改的影响，而不仅仅是更改本身。它同时回答两个问题：引擎建议了什么，该建议如何影响你关心的每一个测试？
建议分为三个部分。规则的更改列出了添加、编辑或删除的规则，以及每个规则的形式逻辑表达式。变量的更改显示更新的变量描述和添加或删除的变量，并将以前的措辞与建议的措辞并排显示，以便你可以直接比较两者。自定义变量类型的更改涵盖策略的枚举类型的更改。
在这些更改旁边，屏幕显示一个测试结果部分，列出了保存的测试及其之前和之后的结果。每行给出预期的发现以及测试是否在之前和之后通过。在一行上选择"查看发现"以查看发现本身。这个视图是屏幕上最重要的指标。如果你失败的测试现在通过了，你通过的测试仍然通过了，你可以有信心地接受。
应用更改后，生成保真度报告（GENERATE_FIDELITY_REPORT），以验证更新后的策略是否仍然忠实地反映源文档。该报告提供三项指标。覆盖率分数（0.0–1.0）表示源文档中有多少内容体现在策略中。准确率分数（0.0–1.0）表示规则与原始文档意图的吻合程度。逐规则依据会将每条规则关联到支持该规则的具体源文档陈述，并提供理由。
比较优化前后的保真度报告。如果准确率分数下降，说明建议的修复可能偏离了源材料，这是一个应当拒绝该修复或继续迭代的信号。
自动优化可以加快诊断失败和生成候选修复方案的工作，但不会扩大更改护栏执行内容的权限。在你决定接受之前，每项修复都只是建议。
你可以通过提供上下文来引导这两种模式，帮助系统更快找到正确的修复方案。
启动迭代优化时，你需要提供一份源文档，作为策略应编码内容的事实依据。控制台提供三种方式：Recently used 用于重新选择之前上传的文档；Upload 用于上传新的 PDF 或文本文件；Enter text 用于直接接受粘贴的内容。文档越清晰、越聚焦，生成的建议就越精确。
你还可以提供自然语言反馈，明确告诉系统需要修复什么。有效的反馈应当具体且可测试。“修复任职期限规则”这样的模糊反馈会给引擎留下过大的自由度。可以将其与一个具体且可测试的替代方案进行比较：“如果员工是全职员工，并且已经工作超过 6 个月（而不是 12 个月），则该员工应有资格享受育儿假。”
你的反馈会作为一项约束：系统生成的更改必须同时满足源文档和你的指导。如果两者存在冲突，系统会标记该冲突，供你审核。
你可以同时提供源文档和反馈。当文档内容密集时，反馈可以引导系统聚焦于真正相关的特定章节。
本节提供两个演练，分别对应一种优化模式。两者共同构成一套可重复使用的工作流，用于处理这两类失败。
要在 Amazon Bedrock 中结合 Automated Reasoning checks 使用自动策略优化，请确保满足以下先决条件：
一个有效的 AWS 账户。
确认 Automated Reasoning checks 可用的 AWS Regions，并且能够在其中一个区域访问 Amazon Bedrock。
拥有创建、查看和优化 Automated Reasoning 策略以及使用 Amazon Bedrock Guardrails 所需的 IAM 权限。
账户中已有一个根据源文档创建的 Automated Reasoning 策略，该源文档包含你希望执行的规则。有关分步说明，请参阅 Create your Automated Reasoning policy。该策略需要至少关联一个测试——迭代优化需要失败测试信号来驱动诊断。有关添加测试的方法，请参阅 Test an Automated Reasoning policy。
你的人力资源休假资格策略中有一项测试失败。助手报告称，一名任职 8 个月的兼职员工有资格享受育儿假。该测试预期结果为 INVALID，但策略返回了 VALID。
在 Amazon Bedrock 控制台中，导航到 Automated Reasoning 并打开你的策略。
选择 Tests 选项卡，然后选择 Validate all tests。图 2 展示了结果。四项测试中有三项通过，而育儿假测试因意外得到 VALID 结果而失败。
图 2：验证后的 Tests 选项卡，四项测试中有三项通过（75%）
打开失败测试的结果并检查转换内容，如图 3 所示。变量已被正确捕获：monthsOfContinuousService = 8. employmentStatus = PART_TIME.
monthsOfContinuousService = 8.
employmentStatus = PART_TIME.
图 3：失败测试的结果，其中转换内容显示变量已被正确捕获
结果为 VALID，因为唯一的支持规则规定，连续任职满 6 个月即可获得资格，并且没有任何规则排除兼职员工。转换结果没有问题，错误出在逻辑上，因此这是一个规则问题。
选择 Refine policy，然后选择 Automatically refine policy。
将优化类型设置为 Iterative Refinement。
使用以下三种方式中的任意一种提供源文档：Recently used。Upload（上传新版本）。Enter text（粘贴相关段落）。
Upload（上传新版本）。
Enter text（粘贴相关段落）。
你也可以选择添加自定义反馈，以聚焦修复目标，例如：“添加一条规则，明确规定兼职员工没有资格享受育儿假。”
输入准备就绪后，选择 Start。
图 4 展示了完成后的设置，其中已选择优化类型、关联源文档并输入自定义反馈。
图 4：包含源文档和自定义反馈的迭代优化设置
收敛完成后，将显示 Review policy changes 屏幕。在 Changes to rules 下，其中列出了两项更改：删除一条规则并添加一条规则。引擎删除了仅根据连续任职期限授予资格的规则：if monthsOfContinuousService is at least 6, then isEligibleForParentalLeave is true，并添加了一条排除兼职员工的规则：if employmentStatus is equal to PART_TIME, then isEligibleForParentalLeave is false
if monthsOfContinuousService is at least 6, then isEligibleForParentalLeave is true
if monthsOfContinuousService is at least 6, then isEligibleForParentalLeave is true
并添加了一条排除兼职员工的规则：
if employmentStatus is equal to PART_TIME, then isEligibleForParentalLeave is false
if employmentStatus is equal to PART_TIME, then isEligibleForParentalLeave is false
在 Test results 下，兼职员工测试从 Failed 变为 Passed，其他三项测试仍为 Passed。图 5 展示了你接受更改之前的屏幕。
图 5：Review policy changes 屏幕。Changes to rules 列出了被删除的仅限任职期限的资格规则以及新增的兼职员工排除规则，Test results 显示兼职员工测试从 Failed 变为 Passed，且没有