Amazon AWS 自动化修复 Bedrock 策略，但最终决定权仍在人手中
- Ethan Carter
- 2小时前
- 讀畢需時 13 分鐘
尽管让软件重写自身合规逻辑存在风险，Amazon AWS 仍为 Bedrock Automated Reasoning 策略新增了两条自动优化路径。该系统可以诊断失败测试、提出正式规则修复方案，并改进含义模糊的语言表述。不过，任何拟议变更都必须经人工审核和接受后才会生效。
这一审批边界是此次公告最重要的部分。Amazon Bedrock 现在可以完成更多此前需要专家手动检查变量、规则、类型和测试结果的诊断工作。AWS 自动化的是修复建议，而不是将策略所有权交给不透明的优化循环。
这一举措给手动规则编写流程带来压力，包括依赖电子表格、基于提示词的检查，或由专家手工编辑正式表达式的团队。它也检验了 Automated Reasoning 背后的一项更大承诺：企业能够获得比普通模型评估更强的保障，而不必将每次策略更新都变成一个形式化方法项目。
Amazon AWS 对 Bedrock 策略优化做了哪些改变
新的工作流程会将失败的策略测试转化为可审核的修复建议，而不再只向用户提供诊断结果。
Automated Reasoning 策略会将领域要求表示为变量、自定义类型和逻辑规则。Bedrock 使用这一正式定义来检查 AI 生成的声明是否符合已编码的要求。这不同于基于模型的评分器，后者通过另一个概率模型估算质量。
AWS 在 re:Invent 2024 上以预览形式推出了 Automated Reasoning 检查功能。该服务随后正式发布，并支持测试管理、场景生成和扩展的文档处理。AWS 表示，其推理检查可处理最多 120,000 个 token 的源材料，大约相当于 100 页内容。
最新的优化能力解决的是团队发现策略未按预期运行后该如何处理的问题。测试失败可能是因为正式规则缺少某个条件，也可能是因为 Bedrock 将自然语言映射到了错误变量，或发现存在多种合理的翻译方式。
这些属于不同的失败类别，因此 AWS 提供了两条优化路径：
规则优化针对策略的正式结构。它可以建议添加、更新或删除规则、变量和自定义类型。
语言优化针对含义模糊或不够精确的描述。它可以修订变量描述和类型定义，使后续翻译能更一致地将语言映射到策略概念。
两条路径都会生成拟议变更，而不是立即覆盖当前生效的定义。在控制台中，用户必须先进入审核页面，才能接受结果。通过 API，应用程序会获取生成的策略定义，然后再显式更新草稿。
这种分离很重要，因为语法有效的修复仍可能编码出错误的业务决策。员工福利策略可能可以正确编译，却应用了错误的任职年限门槛。金融策略可能消除了看似的冲突，但该冲突实际上代表一项有意保留的例外。
因此，这项公告改变的是编写策略的瓶颈，而不是问责模式。Bedrock 可以检查失败原因并起草修复方案，但领域负责人仍需决定拟议逻辑是否符合权威来源。
AWS 记录了多种可能的工作流程状态，包括 SCHEDULED、PREPROCESSING、BUILDING、TESTING、COMPLETED 和 FAILED。返回的工作流程标识符可让客户端在请求生成资产前监控这一异步过程。
该服务还会在构建后生成质量报告。报告能够识别含义模糊的描述、彼此断开的规则组、未使用变量和相互矛盾的关系等结构性问题。这些信号有助于团队区分局部测试失败与更广泛的建模缺陷。
这形成了一个更完整的闭环：编码源文档、运行测试、检查失败、请求修复、审核拟议定义，并重新运行测试套件。这个闭环此前已经存在，但其中更多诊断和翻译工作现在都在 Bedrock 内部完成。
规则优化将测试反馈转化为正式变更
规则优化是影响更大的一种模式，因为它能够改变决定某项声明通过或失败的逻辑。
以员工休假政策为例。源文档规定，全职员工只有在服务满 12 个月后才具备育儿假资格。生成的策略却包含以下表达式：
该规则遗漏了任职年限。一项涉及新入职全职员工的测试会返回批准，而预期结果应为拒绝。这个失败并非仅仅是语言问题；正式模型既缺少相关变量，也缺少必要条件。
AWS 将注释描述为附加到策略元素上的定向修正。支持的操作包括添加、更新或删除变量、规则和自定义类型。用户还可以通过 addRuleFromNaturalLanguage 以自然语言提交规则，让 Bedrock 将其翻译成正式逻辑。
修正后的定义可能会添加名为 tenureMonths 的整数变量，并将原始表达式替换为：
控制台工作流程从策略的测试套件中开始：
在 Amazon Bedrock 控制台中打开 Automated Reasoning 策略。
选择一项失败测试并检查其发现结果。
确认前提、声明和预期结果代表预期场景。
如果测试本身不完整，则修改测试条件。
重新运行测试，以验证修订后的场景是否表达了预期行为。
选择应用注释或优化策略的选项。
让 Bedrock 根据测试反馈启动策略构建工作流程。
审核对规则、变量和类型提出的每一项变更。
仅在变更符合源策略时接受它们。
针对修订后的草稿重新运行已保存测试和生成的场景。
第三步和第四步值得注意。失败的测试并不总能证明策略有误。测试可能遗漏必要前提、使用不准确的预期结果，或者以改变含义的方式表述声明。
因此，AWS 建议在应用注释前先检查发现结果。其优化指南建议用户在适当情况下先修改并重新运行测试。如果修订后的测试产生预期结果，该反馈就可以支持一项定向注释。
API 通过 StartAutomatedReasoningPolicyBuildWorkflow 提供相同能力。规则修复使用 REFINE_POLICY 工作流程类型。请求必须包含完整的当前策略定义，而不仅是正在变更的元素。
简化后的 AWS CLI 请求如下所示：
生产请求会用完整草稿定义替换空数组。策略架构版本必须为 1.0，这与资源的 DRAFT 或编号策略版本不同。
成功响应包含两个值：
应用程序可以使用 GetAutomatedReasoningPolicyBuildWorkflow 轮询工作流程，或通过列表操作检查工作流程。处理完成后，它会通过 GetAutomatedReasoningPolicyBuildWorkflowResultAssets 获取生成的策略定义。
典型的获取命令遵循以下模式：
获取操作并不会使拟议定义成为权威定义。客户端应将结果与当前草稿进行比较，向获得授权的审核者展示差异，并重新运行相关测试。
审核通过后，客户端可以使用已审核定义调用 UpdateAutomatedReasoningPolicy。这项显式更新相当于在控制台中接受变更。
该工作流程支持比盲目替换整个策略更精确的操作。变量注释包括 addVariable、updateVariable 和 deleteVariable。规则注释包括 addRule、updateRule、deleteRule 和 addRuleFromNaturalLanguage。
自定义类型操作涵盖添加、更新和删除。updateFromRulesFeedback 和 updateFromScenarioFeedback 等反馈注释可让用户描述规则或场景出现错误行为的方式。
这一范围很有用，但也提高了审核负担。删除重复变量可以改善翻译一致性；删除一条看似相似的规则，也可能抹去一项有意保留的例外。即使生成的表达式通过了 Bedrock 的结构检查，每项建议仍需进行语义审核。
语言优化在进入求解器前消除歧义
语言优化针对的是自然语言句子转化为正式前提和声明的边界，而这往往是策略失败最不显眼的来源。
正式逻辑只能评估提供给它的概念。在评估发生之前，Bedrock 必须将用户输入和 AI 回复翻译为策略定义的变量。
含义模糊的描述会削弱这一翻译步骤。假设某项策略同时包含 tenureMonths 和 monthsOfService，且两者描述几乎完全相同。“她在这里工作了两年”这句话可能会映射到任一变量。
底层规则可能是正确的，但测试仍可能返回 TRANSLATION_AMBIGUOUS。这一结果意味着系统发现了多种合理的正式解释，并不表示该声明有效或无效。
语言优化会检查描述和自定义类型中的这些重叠情况。它会建议更清晰的措辞、合并概念，或进行其他旨在减少歧义的定义变更。目标并非文风润色，而是在自然语言与正式架构之间建立更稳定的映射。
控制台工作流程比定向规则修复更短：
在 Bedrock 控制台中打开 Automated Reasoning 策略。
转到 Definitions 页面。
检查质量报告中的警告。
选择 Resolve ambiguities。
等待 Bedrock 分析变量描述和类型定义。
审核拟议的语言变更。
将每项建议与原始源文档进行比较。
仅接受保留预期含义的变更。
重新运行包含不同措辞和边界情况的测试。
API 使用相同的构建工作流程端点，但工作流程类型为 RESOLVE_POLICY_AMBIGUITIES。请求包含完整的当前定义：
随后，客户端监控工作流程，并使用 POLICY_DEFINITION 资产类型获取拟议定义。它还可以获取 QUALITY_REPORT 资产，以了解哪些结构性问题触发了这项建议。
构建工作流程 API将工作流程内容视为联合类型。一次请求中只能出现一个受支持的内容成员。客户端不应将消除歧义内容与其他工作流程载荷组合，并期望两项操作同时运行。
语言优化不同于 ITERATIVELY_REFINE_POLICY。迭代优化工作流使用源文档和可选的自然语言反馈来改进现有策略。当权威文档发生变化，或用户希望引导更广泛的优化时，该工作流尤其适用。
例如，修订后的员工手册可能会降低任职年限门槛并增加丧亲假。客户端可以提供完整的当前定义、更新后的文档，以及说明这些变更的反馈。
一个简化请求采用以下结构：
AWS 将这项操作与 INGEST_CONTENT 区分开来。迭代优化将文档作为上下文，用于改进已有定义。内容摄取则从新材料中提取新规则，并可将其合并到现有策略中。
这一区分能够避免一种常见的实现错误。新的手册章节通常应通过摄取进入系统；而旨在修正现有逻辑的修订章节，则属于迭代优化。
语言修复仍应通过多种表述进行测试。修订后的描述可能消除一种歧义，却产生另一种。团队应纳入同义词、缩略语、否定表述以及接近决策边界的取值。
保留一份可搜索的源条款、测试证据和已接受修订记录，也有助于审查人员还原定义变更的原因。工程团队可以在技术知识库中组织这些证据，而不必将策略决策与其支撑文档分离。
人工审批是功能，而非限制
自动诊断降低了正式策略维护的成本，但审批关卡能防止优化错误演变为组织规则。
形式化验证有时被描述为数学确定性。这个说法需要明确边界：引擎能够对接收到的形式化策略进行严谨推理，但无法保证该策略完全准确地反映法规、临床指南、合同或内部流程。
这就是经典的规格说明问题。求解器可以正确判定某个输出遵循有缺陷的规则。数学验证的是与模型的一致性，而不是模型源假设的真实性。
自动优化并不会消除这一限制。它可以发现两个变量存在重叠、某组规则彼此脱节，或失败测试暗示缺少条件。但它无法独立决定哪种解释才符合组织的正当策略。
因此，人工审查界面承担三项职责。
第一，它建立变更控制。审查人员可以看到 Bedrock 提议的是新增条件、删除规则、重命名变量，还是修改类型定义。
第二，它保留领域所有权。工程师可以验证语法和工作流行为，而律师、临床医生、合规官或策略负责人则验证其含义。
第三，它支持审计追踪。团队可以保留失败测试、拟议注释、已接受定义及后续测试结果，作为策略变更原因的证据。
AWS 自身文档建议对生成的策略信息进行人工审查。从自然语言文档中提取内容具有非确定性，因此不同运行可能在规则、变量和类型上产生差异。
最安全的运行模型至少包括四项控制措施：
对语义变更要求由指定的策略负责人审批。
将拟议定义同时与当前版本和源条款进行比较。
重新运行完整回归测试套件，而非仅运行触发优化的测试。
仅在审查和测试完成后发布带编号的策略版本。
应用程序在启动工作流时还应使用幂等令牌。可选的 clientRequestToken 会在重复使用同一令牌时防止重试创建重复操作。
工作流限制同样需要规划。AWS 文档指出，一项策略最多支持两个构建工作流，且同一时间只能有一个工作流处于进行中状态。客户端可能需要在启动新的构建前删除较早的工作流。
由于策略定义可能包含敏感业务逻辑，加密和访问控制仍然至关重要。Bedrock 支持客户自主管理的 AWS KMS 密钥，但调用身份和密钥策略必须授予所需的解密、描述和数据密钥权限。
这些保障措施并不会让策略维护在通常意义上实现自动化。它们实现的是受监督的自动化。系统执行分析并生成候选工件，而人员控制状态变更。
这种模式比可自我修改的护栏更容易辩护。如果生产故障自动削弱了捕获该故障的规则，攻击者就可能通过精心构造的输入或误导性反馈影响策略。
审查关卡会中断这一路径。它还使团队能够拒绝那些虽提高测试通过率、却让形式化策略偏离其来源的修复方案。
一个值得怀疑的问题是，组织会将审查视为真正的控制措施，还是例行确认界面。自动提议可能造成自动化偏见，尤其是在审查人员缺乏阅读形式化表达式经验时。
团队应以多种形式呈现拟议变更：形式化表达式、通俗语言说明、源条款以及受影响的测试场景。缺少这些上下文的绿色接受按钮只会转移瓶颈，而无法解决瓶颈。
压力从编写逻辑转向治理变更
Amazon AWS 正在让形式化策略修复变得更易获得，但组织如今必须建立与变更速度提升相匹配的审查实践。
直接竞争对手并非某个云平台或模型供应商，而是许多治理团队采用的人工路径：手工编写规则，逐一检查失败案例，并依赖少数专家修复形式化模型。
基于提示词的护栏提供了另一条路径。它们可以要求模型遵循策略，或让第二个模型判断是否合规。这些方法更容易起步，但其决策仍具有概率性，并可能随措辞或模型版本而变化。
Automated Reasoning 使用显式变量和约束。这种结构支持反例、可满足性分析和可审计的发现结果。它也要求忠实的规格说明，因此会带来更多的设置和维护工作。
优化旨在降低这部分维护成本。如果 Bedrock 能够可靠地将测试反馈转化为范围有限、可供审查的补丁，领域专家就能减少将普通策略语言翻译为求解器表达式所花的时间。
AWS 报告的一则客户案例展示了预期结果。金融服务提供商 PitCrew 表示，其已编码 40 项 Automated Reasoning 策略，并在三个生产代理中使用它们的组合。其合规工作流会根据形式化约束检查营销材料和监管表单。
据该公司称，一项审查流程从两周缩短至 30 分钟。此前进入三天队列的营销和社交内容，据报可在 30 秒内完成审核。这些是特定实施案例中客户报告的结果，并非一般性能保证。
这一用例揭示了优化为何重要。监管材料会变化，客户策略各不相同，边缘案例会在部署后出现。无法高效修复的策略，要么会过时，要么会在形式化系统之外累积人工例外。
不过，更快的修复也可能加剧策略变动。团队可能频繁接受局部修复，却不检查每项变更如何影响其他规则组。随着时间推移，定义可能在内部保持一致，却变得难以让人理解。
质量报告可以帮助识别彼此脱节的规则集、冲突元素和模糊描述。它无法取代版本纪律或回归测试。
评估该功能的组织应衡量的不只是已接受建议的数量。有用的指标包括：
无需修改即被接受的拟议变更比例。
因改变预期含义而被拒绝的比例。
已接受修复引入的回归失败。
在真实用户表述之间出现的翻译歧义。
从测试失败到经过审查的策略更新所需时间。
领域负责人审批与工程师审批之间的差异。
这些指标能够揭示优化是否减少了专家工作，还是仅仅将其转移到审查环节。它们也能暴露引擎反复提出看似合理、但在语义上错误的变更的情况。
该功能应尤其适用于受监管的应用，因为其规则具有权威来源，且决策需要解释。医疗资格认定、财务披露、员工福利、保险保障和合同要求都符合这一模式。
它不太适合“乐于助人”或“写出吸引人的文案”这类宽泛偏好。这些目标缺乏形式化评估所需的精确变量和约束。
核心权衡仍然是能力与治理之间的平衡。自动修复扩大了可参与策略开发的人群范围，同时也增加了审查人员可能在未充分追踪后果的情况下批准的变更数量。
Amazon AWS 自动化优化后应关注什么
接下来的考验在于，当策略规模超出受控示例时，Bedrock 的提议是否依然范围有限、可解释且忠实可靠。
第一个信号是实际部署中的接受质量。AWS 应展示领域专家在多大程度上原样接受、修改或拒绝拟议修复。高接受率并伴随稳定的回归结果，将支持优化减少形式化编写工作的说法。
高拒绝率则意味着诊断虽有用，但语义修复仍属于专家工作。仅有接受率还不够，因为审查人员也可能批准不佳建议。结果必须包括回归情况和后续生产发现。
第二个信号是来自大型互联策略的证据。公开示例采用了易于理解的规则，例如休假资格和医院风险评估。企业级定义可能包含例外、交叉引用、自定义类型，以及跨越多个章节相互作用的要求。
修复一个失败场景，可能改变多个遥远规则的后果。测试应揭示引擎是否识别出这种更广泛的影响，以及其审查界面是否让这些影响可见。
第三个信号是 AWS 如何扩展集成和治理能力。有价值的补充包括更丰富的策略差异对比、审批角色、必需审查人员、源条款可追溯性，以及已接受变更与受影响测试之间更清晰的关联。
跨账户治理也值得关注。AWS 已扩展集中式 Bedrock 保障措施，但其已记录某些跨账户强制执行场景中涉及 Automated Reasoning 检查的限制。更广泛的支持将决定大型组织能否在不同团队之间一致地治理这些策略。
对开发者而言，眼下的行动很实际。先从一项范围明确的策略开始，保留权威文档，并为预期批准、拒绝、歧义和边缘条件创建测试。只有在确认测试本身正确后，才触发规则优化。
随后，应将每项提议都作为策略决策审查，而非代码生成的便利功能。获取策略定义和质量报告，将其与当前草案比较，重新运行完整测试套件，并为已接受结果进行版本控制。
对于企业采购方，应询问由谁批准变更，以及被拒绝的提案如何记录。还应了解审阅者是否能同时看到正式差异、通俗解释、来源证据和回归影响。
Amazon AWS 缩短了从失败到候选修复方案的路径。但更棘手的问题仍在组织层面：你的团队能否像 Bedrock 如今生成这些变更一样，认真审查正式的策略变更？
