测试策略：场景与 qnA 测试在控制台中自动生成测试场景使用 API 自动生成测试场景在控制台中手动创建 QnA 测试使用 API 创建 QnA 测试运行测试了解测试结果

测试自动推理策略

测试可以验证您的政策规则是否正确，并且自动推理检查可以将自然语言准确地转化为形式逻辑。您可以通过发送自然语言语句进行验证，然后检查反馈来测试策略，以确保翻译使用正确的变量并确保规则产生预期的结果。

有两种互补的测试方法：生成的场景和 question-and-answer（qnA）测试。每种方法都针对验证管道的不同部分。推荐的工作流程是从场景开始验证规则的正确性，然后添加 QnA 测试以验证翻译的准确性。

测试策略：场景与 qnA 测试

自动推理检查分两个步骤验证内容：首先，基础模型将自然语言转换为形式逻辑；然后，数学技术根据您的策略规则验证逻辑。每种测试方法都针对此管道中的不同步骤。

生成的场景（测试规则正确性）

生成的场景直接测试策略规则中编码的语义。它们消除了方程式中自然语言翻译的不确定性，从而隔离了规则本身是否正确。

场景是根据您的策略规则生成的，它们代表了根据这些规则在逻辑上可能的情况。它们经过排序，首先显示出最多的 likely-to-be-wrong场景。对于每个场景，您都要查看变量分配并决定：

竖起大拇指 ——这个场景是现实的，确实应该是可能的。将其另存为SATISFIABLE测试。
竖起大拇指 — 有些不对劲。考虑到你的领域知识，这种情况应该是不可能的。提供自然语言反馈来解释原因，自动推理检查将尝试推断出必要的规则更改。

示例：您的保单规定，任期超过12个月的全职员工有资格享受育儿假。可能会显示生成的场景isFullTime = true, tenureMonths = 3, eligibleForParentalLeave = true。如果这种情况不可能（因为3个月少于12个月），你可以竖起大拇指并解释说员工至少需要12个月的任期。这表示缺少规则或规则不正确。

使用场景作为测试的第一步。在你花时间编写 QnA 测试之前，它们可以帮助你发现规则问题。

QnA 测试（测试翻译精度）

QnA 测试验证了整个管道 end-to-end：自然语言翻译和规则验证同时进行。它们模仿真实的用户互动，捕捉场景无法检测到的翻译问题。

每个 qnA 测试包括：

输入（可选）-用户可能会向您的应用程序提出的问题。
输出-基础模型可能生成的响应。
预期结果-您期望的验证结果（例如，VALID或INVALID）。

示例：对于同样的育儿假政策，QnA 测试可能是：input = “我已经在这里全职工作了 2 年。我可以请育儿假吗？” ，输出= “是的，你有资格休育儿假。 “，预期结果 = VALID。这将测试自动推理检查是否正确地将 “2 年” 转换为 “全职” 转换为isFullTime = true。tenureMonths = 24

提示

创建涵盖有效和无效场景的测试。例如，如果您的政策规定 “员工需要工作1年的育儿假”，请为正确说明此规则的回复创建测试，并测试错误地陈述不同要求的回复。

在控制台中自动生成测试场景

转到您要测试的自动推理策略（例如，MyHrPolicy）。
选择查看测试，然后选择生成。
在 “生成方案” 对话框中，查看生成的场景和相关规则。每个场景都显示一组变量分配，根据您的策略规则，这些变量分配在逻辑上是可能的。评估您的领域中的场景是否现实：
- 如果您的域名中可能发生这种情况（可以满足），请选择竖起大拇指图标。这会将场景保存为预期SATISFIABLE结果的测试。
- 如果不可能出现这种情况，请选择大拇指向下图标。提供解释原因的注释，例如，“员工需要至少 12 个月的任期才能享受育儿假，但此情景显示 3 个月有资格休育儿假。” 自动推理检查使用您的反馈来推断出可以防止出现这种情况的规则更改。
- 如果您想要不同的场景，请选择 “重新生成场景”。
提示
要检查场景的形式逻辑版本，请启用 Show SMT- LIB。这对于准确了解涉及哪些规则和变量赋值非常有用。
选择 “保存并关闭” 以保存测试，或者选择 “保存并添加” 以继续查看场景。
如果您为任何场景提供了注释（竖起大拇指反馈），请选择应用注释。自动推理检查将启动构建工作流程，根据您的反馈将更改应用于您的政策。
在查看策略变更屏幕上，查看对策略规则、变量和变量类型的拟议更改。然后选择接受更改。

使用 API 自动生成测试场景

使用 GetAutomatedReasoningPolicyNextScenario API 根据您的策略规则获取生成的测试场景。

policyArn（必需）: 自动推理策略的 ARN。
buildWorkflowId（必需）: 生成的场景的生成工作流程的标识符。使用 ListAutomatedReasoningPolicyBuildWorkflows API 检索最新的构建工作流程。

示例：


aws bedrock get-automated-reasoning-policy-next-scenario \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

响应包括生成的场景，其中包含变量分配和相关的策略规则。查看场景并使用 CreateAutomatedReasoningPolicyTestCase API 将其另存为测试，或者在场景显示规则问题时使用注释 APIs 提供反馈。

在控制台中手动创建 QnA 测试

转到您要测试的自动推理策略（例如，MyHrPolicy）。
选择查看测试，然后选择添加。
在添加测试对话框中，执行以下操作：
1. 在 Input（可选）中，输入用户可能会问的问题。在输出中，输入基础模型可能提供的响应。它们共同构成了一对 QnA，用于测试您的策略如何验证真实的用户互动。
2. 选择您期望从测试中获得的结果（例如有效或无效）。
3. （可选）选择置信度阈值，这是逻辑验证的最低置信水平。自动推理检查使用多种方法 LLMs 将自然语言转化为调查结果。它仅返回由很大一部分法学硕士翻译支持的结果。置信度阈值定义对于将翻译视为具有有效结果的调查发现，所需的最低支持百分比。低于阈值的发现浮出水面为. TRANSLATION_AMBIGUOUS
选择保存来创建测试。

使用 API 创建 QnA 测试

使用 CreateAutomatedReasoningPolicyTestCase API 以编程方式创建测试。

policyArn（必需）: 自动推理策略的 ARN。
queryContent（可选）: 生成内容的输入查询或提示，例如用户问题。这为验证提供了上下文。
guardContent（必需）: 要验证的输出内容 — 将检查其准确性的基础模型响应。
expectedAggregatedFindingsResult（可选）: 预期的验证结果（例如，VALID或INVALID）。实际结果是通过按严重程度对发现结果进行排序并选择最差结果来确定的。从最差到最佳的严重性顺序为：TRANSLATION_AMBIGUOUSIMPOSSIBLE、INVALID、、SATISFIABLE、VALID。
confidenceThreshold（可选）: 逻辑验证的最低置信度。

示例：


aws bedrock create-automated-reasoning-policy-test-case \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --query-content "Can I take a leave of absence if I'm a part-time employee?" \
  --guard-content "No, only full-time employees are eligible for leave of absence." \
  --expected-aggregated-findings-result "VALID" \
  --confidence-threshold 0.8

示例响应：


{
  "testCaseId": "test-12345abcde",
  "policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk"
}

运行测试

在控制台中运行测试

转到您要验证的自动推理策略（例如，MyHrPolicy）。
选择查看测试。
请执行以下操作之一：
- 要运行所有测试，请选择 “验证所有测试”。
- 要运行单个测试，请选择测试旁边的 “操作” 按钮，然后选择 “验证”。

使用 API 运行测试

使用 StartAutomatedReasoningPolicyTestWorkflow API 运行测试，使用 GetAutomatedReasoningPolicyTestResult API 检索结果。

policyArn（必需）: 自动推理策略的 ARN。
buildWorkflowId（必需）: 要执行测试的生成工作流程的标识符。使用 ListAutomatedReasoningPolicyBuildWorkflows API 检索最新的构建工作流程。
testCaseIds（可选）: 要运行的测试标识符列表。如果未提供，则会运行该策略的所有测试。

示例：


# Run tests
aws bedrock start-automated-reasoning-policy-test-workflow \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

# Get results for a specific test
aws bedrock get-automated-reasoning-policy-test-result \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690 \
  --test-case-id test-12345abcde

响应包括详细的测试结果以及验证结果和执行状态。要列出构建工作流程的所有测试结果，请使用 ListAutomatedReasoningPolicyTestResults API。

了解测试结果

测试完成后，您会收到一组调查结果。每项发现都代表了从您的测试输入中提取的事实主张，以及验证结果、使用的变量赋值和支持该结论的政策规则。有关查找结构和所有验证结果类型的详细说明，请参见调查结果和验证结果。

测试结果剖析

每项测试结果包括：

预期结果-您在创建测试时设置的结果。
实际结果-运行测试的汇总结果。这是通过按严重程度对发现结果进行排序并选择最差结果来确定的。从最差到最佳的严重性顺序为：TRANSLATION_AMBIGUOUSIMPOSSIBLE、INVALID、、SATISFIABLE、VALID。例如，包含两个VALID发现和一个IMPOSSIBLE发现的测试的汇总结果为IMPOSSIBLE。
执行结果-测试是通过（预期结果和实际结果匹配）还是失败。
调查结果-个人验证结果。每项调查结果都包含翻译后的前提和主张、置信度分数、可变分配以及支持该结论的政策规则。

对结果的实际解释

下表总结了每项验证结果在实践中的含义以及当您在测试中看到该结果时要采取的措施。有关包括查找字段和详细说明在内的完整参考资料，请参阅验证结果参考。

结果	含义	操作
`VALID`	考虑到前提和您的保单规则，答复中的说法在数学上被证明是正确的。调查结果包括`supportingRules`证明这些说法和`claimsTrueScenario`证明这些说法是真实的。	如果这是预期结果，则测试通过。检查`untranslatedPremises`并`untranslatedClaims`检查输入中未经过验证的部分，`VALID`结果仅涵盖翻译后的索赔。
`INVALID`	这些索赔与您的保单规则相矛盾。调查结果包括`contradictingRules`显示违反了哪些规则。	如果这是预期结果，则测试通过。如果意外，请检查规则是否正确，或者翻译是否分配了错误的变量。`contradictingRules`请查看，了解哪些规则导致了结果。
`SATISFIABLE`	这些索赔与您的政策一致，但并未涉及所有相关规则。在某些条件下，答案是正确的，但不是所有条件下都是正确的。调查结果包括a `claimsTrueScenario` 和a `claimsFalseScenario` 显示了主张的真实和错误的条件。	比较两种方案，找出缺失的条件。这通常意味着响应不完整——这没有错，但它没有提及所有要求。考虑您的测试是否应该预期，`SATISFIABLE`或者响应是否应该更完整。
`IMPOSSIBLE`	自动推理检查无法评估索赔，因为前提相互矛盾或政策本身包含相互矛盾的规则。	检查测试输入是否包含相互矛盾的陈述（例如，“我是全职的，也是兼职的”）。如果输入有效，则您的政策中可能存在矛盾之处，请查看质量报告是否存在冲突规则。请参阅对自动推理策略进行故障排除和完善。
`TRANSLATION_AMBIGUOUS`	从自然语言到形式逻辑的翻译模棱两可。 LLMs 用于翻译的复数在如何解释输入内容上存在分歧。该发现包括其他解释，以帮助您理解分歧。	这通常是一个变量描述问题。查看备选解释以了解分歧所在，然后改进相关的变量描述。常见原因：变量重叠、描述模糊或输入文本不明确。请参阅对自动推理策略进行故障排除和完善。
`TOO_COMPLEX`	输入中包含的信息太多，无法在延迟限制内进行自动推理检查。	简化测试输入。如果问题仍然存在，则您的策略可能过于复杂，可以考虑将其拆分为多个重点策略或简化涉及非线性算术的规则。
`NO_TRANSLATIONS`	输入无法转换为形式逻辑。这通常意味着输入与您的策略的域无关，或者策略没有变量来对输入中的概念进行建模。	如果输入内容应与您的政策相关，请添加缺失的变量并更新您的规则。如果输入的内容确实偏离了主题，那么这个结果是意料之中的 —— 你的应用程序应该单独处理题外内容（例如，使用主题策略）。

失败测试的调试技巧

当测试失败（实际结果与预期结果不符）时，请使用以下方法来诊断问题：

请先检查翻译。看看调查结果中的前提和主张。分配的变量是否正确？这些值是否正确？如果翻译错误，则问题出在你的变量描述中，而不是你的规则上。例如，如果 “2 年” 被转换为 “2 年” tenureMonths = 2 而不是tenureMonths = 24，则变量描述需要指定单位换算。
检查规则。如果翻译看起来正确，则问题出在您的政策规则中。查看调查结果contradictingRules中的supportingRules或，以确定涉及哪些规则。将它们与您的源文档进行比较。
检查是否有未翻译的内容。看看untranslatedPremises和untranslatedClaims。如果输入的重要部分未被翻译，则可能需要添加变量来捕捉这些概念。
查看置信度分数。低置信度分数表示翻译模型存在分歧。这表明此类输入的变量描述不明确。

有关详细的故障排除指南，请参阅对自动推理策略进行故障排除和完善。

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

文档惯例

策略最佳实践

对您的政策进行故障排除和完善