翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 自動推論ポリシーをテストする
テストでは、ポリシーのルールが正しく、自動推論チェックが自然言語を正式なロジックに正確に変換できることを検証します。検証のために自然言語ステートメントを送信し、フィードバックを検査して、翻訳が正しい変数を使用し、ルールが期待される結果を生成することを確認します。
補完的なテストアプローチには、生成されたシナリオとquestion-and-answer (QnA) テストの 2 つがあります。各 は検証パイプラインの異なる部分をターゲットとします。推奨されるワークフローは、ルールの正確性を検証するためのシナリオから開始し、翻訳の正確性を検証するための QnA テストを追加することです。
## テスト戦略: シナリオと QnA テスト
自動推論チェックでは、2 つのステップでコンテンツを検証します。まず、基盤モデルが自然言語を正式なロジックに変換し、次に数学的な手法でポリシールールに照らしてロジックを検証します。各テストアプローチは、このパイプラインの異なるステップを対象としています。
### 生成されたシナリオ (テストルールの正確性)
生成されたシナリオでは、*ポリシールールでエンコードされたセマンティクスを直接テストします*。自然言語翻訳の不確実性を方程式から削除し、ルール自体が正しいかどうかを分離します。
シナリオはポリシールールから生成され、それらのルールを考慮して論理的に可能な状況を表します。これらは、間違いの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 = "I've been working here for 2 years full-time。親休暇を取ることはできますか？」、出力 =「はい、親休暇の対象となります。」、期待される結果 = `VALID`。これは、自動推論チェックが「2 年」を に`tenureMonths = 24`、「フルタイム」を に正しく変換するかどうかをテストします`isFullTime = true`。
**ヒント**
有効なシナリオと無効なシナリオの両方をカバーするテストを作成します。たとえば、ポリシーに「従業員が親休暇に 1 年間のサービスを必要とする」と記載されている場合、このルールを正しく記述するレスポンスのテスト*と*、別の要件を誤って記述するレスポンスのテストを作成します。
### 推奨されるテストワークフロー
1. **シナリオを生成して確認します。**ここから始めて、ルールが正しいことを確認します。続行する前にルールの問題を修正してください。
1. **主要なユースケースの QnA テストを記述します。**ユーザーが尋ねる可能性が最も高い質問と、LLM が生成する可能性が最も高い回答に焦点を当てます。エッジケースと境界条件を含めます。
1. **すべてのテストを実行します。**シナリオと QnA テストの両方が合格することを確認します。
1. **反復します。**テストが失敗した場合は、問題がルールにあるか (ポリシーを修正) 翻訳にあるか (変数の説明を改善) を判断します。詳細については、「[自動推論ポリシーのトラブルシューティングと絞り込み](address-failed-automated-reasoning-tests.md)」を参照してください。
## コンソールでテストシナリオを自動的に生成する
1. テストする自動推論ポリシー (**MyHrPolicy** など) に移動します。
1. **[テストを表示]** を選択し、**[生成]** を選択します。
1. **「シナリオの生成**」ダイアログで、生成されたシナリオと関連するルールを確認します。各シナリオは、ポリシールールに応じて論理的に可能な一連の変数割り当てを示しています。シナリオがドメイン内で現実的であるかどうかを評価します。
+ シナリオがドメインで発生する可能性がある場合 (*満足できる*場合）、サムズアップアイコンを選択します。これにより、`SATISFIABLE`結果を期待するテストとしてシナリオが保存されます。
+ シナリオを実行できない場合は、サムズダウンアイコンを選択します。その理由を説明する注釈を入力します。たとえば、「従業員は親休暇に少なくとも 12 か月の在職期間が必要ですが、このシナリオは 3 か月の資格を示しています」などです。自動推論チェックでは、フィードバックを使用して、このシナリオを妨げるルールの変更を推測します。
+ 別のシナリオが必要な場合は、**シナリオを再生成**を選択します。
**ヒント**
シナリオの正式なロジックバージョンを確認するには、**SMT-LIB の表示**を有効にします。これは、関連するルールと変数の割り当てを正確に理解するのに役立ちます。
1. **保存して閉じる**を選択してテストを保存するか、**保存して別の を追加して**シナリオのレビューを続行します。
1. シナリオに注釈 (フィードバックのサムダウン) を指定した場合は、**注釈の適用**を選択します。自動推論チェックは、フィードバックに基づいてポリシーに変更を適用するビルドワークフローを開始します。
1. **ポリシー変更の確認**画面で、ポリシーのルール、変数、変数タイプに対して提案された変更を確認します。次に、**[変更を受け入れる]** を選択します。
## 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 テストを手動で作成する
1. テストする自動推論ポリシー (**MyHrPolicy** など) に移動します。
1. **[テストを表示]** を選択し、**[追加]** を選択します。
1. **[テストを追加]** ダイアログで、次の操作を行います。
1. **入力** (オプション) には、ユーザーが尋ねる可能性のある質問を入力します。**Output** には、基盤モデルが提供する可能性のあるレスポンスを入力します。これらは、ポリシーが実際のユーザーインタラクションを検証する方法をテストする QnA ペアを形成します。
1. テストで予期される結果 (**有効**や**無効**など) を選択します。
1. (オプション) ロジック検証の最小信頼レベルである信頼度**しきい値**を選択します。自動推論チェックでは、複数の LLMsを結果に変換します。LLM 翻訳のかなりの割合でサポートされている結果のみを返します。信頼度しきい値は、変換が有効な結果のある検出結果になるために必要なサポートの最小パーセンテージを定義します。しきい値を下回る検出結果は として表示されます`TRANSLATION_AMBIGUOUS`。
1. **[保存]** を選択してテストを作成します。
## API を使用して QnA テストを作成する
`CreateAutomatedReasoningPolicyTestCase` API を使用して、プログラムでテストを作成します。
`policyArn` (必須)
自動推論ポリシーの ARN。
`queryContent` (オプション)
ユーザーの質問など、コンテンツを生成した入力クエリまたはプロンプト。これにより、検証のコンテキストが提供されます。
`guardContent` (必須)
検証する出力コンテンツ — 精度をチェックする基盤モデルのレスポンス。
`expectedAggregatedFindingsResult` (オプション)
予想される検証結果 (例: `VALID`または `INVALID`)。実際の結果は、結果を重要度順にソートし、最悪の結果を選択することによって決まります。重要度の最悪順は、`TRANSLATION_AMBIGUOUS`、、`IMPOSSIBLE`、`SATISFIABLE`、`INVALID`、 です`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"
}
```
## テストを実行する
### コンソールでテストを実行する
1. 検証する自動推論ポリシー (**MyHrPolicy** など) に移動します。
1. **[テスト項目を表示]** を選択します。
1. 次のいずれかを行います。
+ すべてのテストを実行するには、**すべてのテストの検証**を選択します。
+ 1 つのテストを実行するには、テストの横にある**アクション**ボタンを選択し、**検証**を選択します。
### 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 を使用します。
## テスト結果を理解する
テストが完了すると、一連の*検出*結果を受け取ります。各検出結果は、検証結果、使用される変数割り当て、結論をサポートするポリシールールとともに、テスト入力から抽出された事実クレームを表します。検出結果構造とすべての検証結果タイプの詳細な説明については、「」を参照してください[結果と検証結果](automated-reasoning-checks-concepts.md#ar-concept-findings)。
### テスト結果の構造
各テスト結果には以下が含まれます。
+ **期待される結果** — テストの作成時に設定した結果。
+ **実際の結果** — テストの実行から集計された結果。これは、結果を重要度順にソートし、最悪の結果を選択することによって決まります。重要度の最悪順は、`TRANSLATION_AMBIGUOUS`、、`IMPOSSIBLE`、`SATISFIABLE`、`INVALID`、 です`VALID`。たとえば、2 つの`VALID`検出結果と 1 つの`IMPOSSIBLE`検出結果を含むテストは、 の集計結果を持ちます`IMPOSSIBLE`。
+ **実行結果** — テストが成功したか (予想される結果と実際の結果が一致）、失敗したか。
+ **結果** — 個々の検証結果。各検出結果には、翻訳された施設とクレーム、信頼スコア、変数の割り当て、結論をサポートするポリシールールが含まれます。
### 結果の実用的な解釈
次の表は、各検証結果の実際の意味と、テストで確認したときに実行するアクションをまとめたものです。検出結果フィールドと詳細な説明を含む完全なリファレンスについては、「」を参照してください[検証結果リファレンス](automated-reasoning-checks-concepts.md#ar-concept-validation-results)。
| 結果 | 意味 | 対応方法 |
| --- | --- | --- |
| VALID | レスポンスのクレームは、オンプレミスとポリシールールを考慮して、数学的に正しいことが証明されています。検出結果には、クレームsupportingRulesを証明する と、クレームがどのように当てはまるかclaimsTrueScenarioを示す が含まれます。 | これが期待される結果である場合、テストは合格です。検証されなかった入力の一部untranslatedClaimsについて untranslatedPremisesと を確認します。VALID結果は翻訳されたクレームのみを対象とします。 |
| INVALID | クレームはポリシールールと矛盾します。検出結果には、違反したルールcontradictingRulesが示されています。 | これが期待される結果である場合、テストは合格です。予期しない場合は、ルールが正しいかどうか、または翻訳が間違った変数を割り当てたかどうかを確認します。結果の原因となったルールについてはcontradictingRules、「」を参照してください。 |
| SATISFIABLE | クレームはポリシーと一致していますが、関連するすべてのルールに対処しているわけではありません。レスポンスは一部の条件では正しいですが、すべてではありません。検出結果には、クレームが true claimsTrueScenarioと false の条件claimsFalseScenarioを示す と の両方が含まれます。 | 2 つのシナリオを比較して、欠落している条件を特定します。これは通常、レスポンスが不完全であることを意味します。これは間違っているわけではありませんが、すべての要件に言及しているわけではありません。テストで想定すべきかどうかSATISFIABLE、またはレスポンスがより完全であるべきかどうかを検討します。 |
| IMPOSSIBLE | 自動推論チェックでは、オンプレミスが矛盾しているか、ポリシー自体に競合するルールが含まれているため、クレームを評価できません。 | テスト入力に矛盾するステートメント (「フルタイムとパートタイム」など) が含まれているかどうかを確認します。入力が有効な場合、ポリシーに矛盾がある可能性があります。ルールの競合について品質レポートを確認してください。「[自動推論ポリシーのトラブルシューティングと絞り込み](address-failed-automated-reasoning-tests.md)」を参照してください。 |
| TRANSLATION\_AMBIGUOUS | 自然言語から正式なロジックへの翻訳はあいまいでした。翻訳に使用される複数の LLMs は、入力の解釈方法に異論がありました。結果には、不一致を理解するのに役立つ代替解釈が含まれています。 | これは通常、可変の説明の問題です。代替解釈を確認して意見の相違点を理解し、関連する変数の説明を改善します。一般的な原因: 変数の重複、あいまいな説明、またはあいまいな入力テキスト。「[自動推論ポリシーのトラブルシューティングと絞り込み](address-failed-automated-reasoning-tests.md)」を参照してください。 |
| TOO\_COMPLEX | 入力に含まれる情報が多すぎるため、自動推論チェックはレイテンシー制限内で処理できません。 | テスト入力を簡素化します。問題が解決しない場合は、ポリシーが複雑すぎる可能性があります。複数のフォーカスポリシーに分割するか、非線形算術を含むルールを簡素化することを検討してください。 |
| NO\_TRANSLATIONS | 入力を正式なロジックに変換できませんでした。これは通常、入力がポリシーのドメインに関連しないか、ポリシーに入力の概念をモデル化する変数がないことを意味します。 | 入力がポリシーに関連している場合は、欠落している変数を追加してルールを更新します。入力が本当にトピックから外れている場合、この結果は予想されます。アプリケーションはトピックから外れたコンテンツを個別に処理する必要があります (トピックポリシーを使用するなど）。 |
### 失敗したテストのデバッグのヒント
テストが失敗した場合 (実際の結果が期待される結果と一致しない場合）、次の方法を使用して問題を診断します。
1. **最初に翻訳を確認します。**検出結果の施設とクレームを確認します。適切な変数が割り当てられていますか? 値は正しいですか? 翻訳が間違っている場合、問題はルールではなく変数の説明にあります。たとえば、「2 年」が `tenureMonths = 2`の代わりに に変換された場合`tenureMonths = 24`、変数の説明で単位変換を指定する必要があります。
1. **ルールを確認します。**翻訳が正しいと思われる場合、問題はポリシールールにあります。結果`contradictingRules`の `supportingRules`または を参照して、関係するルールを特定します。ソースドキュメントと比較します。
1. **翻訳されていないコンテンツがないか確認します。**`untranslatedPremises` と を確認します`untranslatedClaims`。入力の重要な部分が翻訳されていない場合は、それらの概念をキャプチャするために変数を追加する必要がある場合があります。
1. **信頼スコアを確認します。**信頼スコアが低い場合は、翻訳モデルに同意していないことを示します。これは、このタイプの入力では変数の説明があいまいであることを示唆しています。
トラブルシューティングの詳細なガイダンスについては、「」を参照してください[自動推論ポリシーのトラブルシューティングと絞り込み](address-failed-automated-reasoning-tests.md)。