測試策略：案例與 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 年」轉譯為 tenureMonths = 24，並將「全職」轉譯為 isFullTime = true。

提示

建立涵蓋有效和無效案例的測試。例如，如果您的政策陳述「員工需要一年的親職休假服務」，請針對正確陳述此規則的回應建立測試，並針對錯誤陳述不同需求的回應進行測試。

建議的測試工作流程

產生和檢閱案例。從這裡開始驗證您的規則是否正確。在繼續之前修正任何規則問題。
撰寫關鍵使用案例的 QnA 測試。專注於使用者最可能提出的問題，以及 LLM 最可能產生的回應。包含邊緣案例和邊界條件。
執行所有測試。檢查案例和 QnA 測試是否通過。
反覆運算。如果測試失敗，請判斷問題是在規則中（修正政策）還是在轉譯中（改善變數描述）。如需詳細資訊，請參閱對自動化理由政策進行故障診斷和精簡。

在主控台中自動產生測試案例

前往您要測試的自動推理政策 (例如 MyHrPolicy)。
選擇檢視測試，然後選擇產生。
在產生案例對話方塊中，檢閱產生的案例和相關規則。每個案例都會顯示一組根據政策規則，在邏輯上可行的變數指派。評估案例在您的網域中是否實際：
- 如果情況可能發生在您的網域中（令人滿意)，請選取拇指向上圖示。這會將案例儲存為預期SATISFIABLE結果的測試。
- 如果案例不可行，請選取拇指向下圖示。提供註釋說明原因 — 例如「員工需要至少 12 個月的留職期才能休親假，但此案例顯示 3 個月符合資格。」自動化理由檢查使用您的意見回饋來推斷會阻止此案例的規則變更。
- 如果您想要不同的案例，請選擇重新產生案例。
提示
若要檢查案例的正式邏輯版本，請啟用顯示 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. 針對輸入（選用），輸入使用者可能提出的問題。針對輸出，輸入基礎模型可能提供的回應。這些組合會形成一個 QnA 對，測試您的政策如何驗證真實的使用者互動。
2. 選擇您預期來自測試的結果 (例如有效或無效)。
3. （選用）選取可信度閾值，這是邏輯驗證的最低可信度層級。自動化推理檢查使用多個 LLMs將自然語言轉譯為問題清單。它只會傳回大量 LLM 轉譯支援的問題清單。可信度閾值定義翻譯要成為具備有效性結果的調查結果所需支援的最低百分比。低於閾值的問題清單會顯示為 TRANSLATION_AMBIGUOUS。
選取儲存以建立測試。

使用 API 建立 QnA 測試

使用 CreateAutomatedReasoningPolicyTestCase API 以程式設計方式建立測試。

policyArn (必要): 自動化理由政策的 ARN。
queryContent (選用): 產生內容的輸入查詢或提示，例如使用者問題。這提供驗證的內容。
guardContent (必要): 要驗證的輸出內容 — 將檢查準確性的基礎模型回應。
expectedAggregatedFindingsResult (選用): 預期的驗證結果（例如 VALID或 INVALID)。實際結果的判斷方式是依嚴重性排序問題清單，然後選取最差結果。從最差到最佳的嚴重性順序為：TRANSLATION_AMBIGUOUS、IMPOSSIBLE、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_AMBIGUOUS、IMPOSSIBLE、INVALID、SATISFIABLE、VALID。例如，具有兩個VALID調查結果和一個IMPOSSIBLE調查結果的測試具有的彙總結果IMPOSSIBLE。
執行結果 — 測試是否通過（預期和實際結果相符）或失敗。
調查結果 — 個別驗證結果。每個調查結果都包含翻譯的現場部署和宣告、可信度分數、變數指派，以及支援結論的政策規則。

實際解讀結果

下表摘要說明每個驗證結果的實際意義，以及當您在測試中看到該結果時應採取的動作。如需包括問題清單欄位和詳細說明的完整參考，請參閱驗證結果參考。

結果	代表什麼意思	處理方式
`VALID`	根據內部部署和您的政策規則，回應中的宣告在數學上證明正確。調查結果包括`supportingRules`證明宣告的內容，以及`claimsTrueScenario`示範宣告的真偽。	如果這是預期的結果，則測試會通過。檢查 `untranslatedPremises`和 `untranslatedClaims` 是否有部分未驗證的輸入 - `VALID`結果僅涵蓋翻譯的宣告。
`INVALID`	宣告與您的政策規則相衝突。調查結果包含`contradictingRules`顯示違反了哪些規則。	如果這是預期的結果，則測試會通過。如果未預期，請檢查規則是否正確，或翻譯是否指派了錯誤的變數。檢閱 `contradictingRules`以了解導致結果的規則。
`SATISFIABLE`	宣告與您的政策一致，但無法解決所有相關規則。在某些情況下，回應是正確的，但不是全部。調查結果同時包含 `claimsTrueScenario`和，`claimsFalseScenario`顯示宣告為 true 和 false 的條件。	比較兩個案例以識別缺少的條件。這通常表示回應不完整 - 沒有錯誤，但不會提及所有要求。考慮您的測試是否應該預期，`SATISFIABLE`或回應是否應該更完整。
`IMPOSSIBLE`	自動化理由檢查無法評估宣告，因為內部部署是矛盾的，或政策本身包含衝突的規則。	檢查測試輸入是否包含矛盾的陳述式（例如，「我是全職和兼職」)。如果輸入有效，則可能與您的政策相衝突 - 檢查品質報告是否有衝突的規則。請參閱對自動化理由政策進行故障診斷和精簡。
`TRANSLATION_AMBIGUOUS`	從自然語言轉譯為正式邏輯並不明確。用於轉譯LLMs 與如何解譯輸入不同。調查結果包含替代解釋，以協助您了解分歧。	這通常是變數描述問題。檢閱替代解釋以了解分歧之處，然後改善相關的變數描述。常見原因：重疊的變數、模糊的描述或模棱兩可的輸入文字。請參閱對自動化理由政策進行故障診斷和精簡。
`TOO_COMPLEX`	輸入包含太多自動推理檢查的資訊，無法在其延遲限制內處理。	簡化測試輸入。如果問題仍然存在，您的政策可能過於複雜，請考慮將其分割成多個聚焦政策，或簡化涉及非線性算術的規則。
`NO_TRANSLATIONS`	輸入無法轉譯為正式邏輯。這通常表示輸入與您政策的網域無關，或者政策沒有變數來建立輸入中概念的模型。	如果輸入應該與您的政策相關，請新增缺少的變數並更新您的規則。如果輸入實際上是離主題，則預期會得到此結果 - 您的應用程式應該分別處理離主題內容（例如，使用主題政策）。

測試失敗的偵錯秘訣

當測試失敗（實際結果與預期結果不符）時，請使用下列方法來診斷問題：

請先檢查翻譯。查看調查結果中的內部部署和宣告。是否已指派正確的變數？這些值是否正確？如果翻譯錯誤，問題就在您的變數描述中，而不是您的規則中。例如，如果「2 年」翻譯為 tenureMonths = 2 而非 tenureMonths = 24，則變數描述需要指定單位轉換。
檢查規則。如果翻譯看起來正確，問題就在您的政策規則中。查看調查結果contradictingRules中的 supportingRules或，以識別涉及哪些規則。將它們與您的來源文件進行比較。
檢查未翻譯的內容。查看 untranslatedPremises和 untranslatedClaims。如果未翻譯輸入的重要部分，您可能需要新增變數來擷取這些概念。
檢查可信度分數。低可信度分數表示翻譯模型不一致。這表示此類型輸入的變數描述不明確。

如需詳細的故障診斷指引，請參閱對自動化理由政策進行故障診斷和精簡。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

政策最佳實務

對政策進行故障診斷和精簡