翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

自動推論ポリシーのトラブルシューティングと絞り込み

自動推論ポリシーテストが失敗した場合 - 実際の結果が予想される結果と一致しない場合 - 問題は、翻訳 (自然言語が間違った変数または値にマッピングされた) またはルール (ポリシーロジックがドメインと一致しません) にあります。このページでは、両方のタイプの問題を診断および修正するための体系的なアプローチを提供します。

トラブルシューティングを開始する前に、「」で説明されている 2 ステップの検証プロセス (翻訳、検証) を理解していることを確認してください翻訳: 自然言語から形式ロジックへ。この区別は、効率的なデバッグの鍵です。

デバッグワークフロー

テストが失敗したら、実際の結果を使用して問題のタイプを特定し、関連するセクションにジャンプします。

翻訳の問題を修正

翻訳の問題は、自動推論チェックが自然言語をポリシーの変数に確実にマッピングできない場合に発生します。最も目に見える症状はTRANSLATION_AMBIGUOUS結果ですが、間違った変数や値が割り当てられていると、翻訳の問題によって VALID、INVALID、または SATISFIABLEの結果が正しくない可能性もあります。

TRANSLATION_AMBIGUOUS 結果を診断する

TRANSLATION_AMBIGUOUS 検出結果には、不一致を理解するのに役立つ 2 つの主要なフィールドが含まれています。

これらのフィールドを調べて特定のあいまいさの原因を特定し、次のリストから適切な修正を適用します。

変数定義の重複

複数の変数が同じ概念を合理的に表すことができる場合、変換モデルはどの変数を使用するかに反対します。

症状: TRANSLATION_AMBIGUOUS検出結果optionsの は、異なる変数に割り当てられたのと同じ概念を示しています。たとえば、1 つのオプションは「2 年間のサービス」を に割り当てtenureMonths = 24、もう 1 つのオプションはそれを に割り当てますmonthsOfService = 24。

修正: 重複する変数を包括的な説明を含む 1 つの変数にマージします。削除された変数を参照するすべてのルールを更新して、残りの変数を使用します。

例:

不完全な変数の説明

ユーザーが日常的な言語で概念を参照する方法の詳細がない変数の説明は、入力を正しい変数にマッピングすることが困難になります。

症状: は正しい変数optionsを表示しますが、値が異なるか、翻訳によってユーザーの発言と一致しない値が割り当てられます。たとえば、「2 年」は tenureMonths = 2ではなく に変換されますtenureMonths = 24。

修正: 変数の説明を更新して、単位変換ルール、シノニム、代替フレーズを含めます。詳細なガイダンス包括的な変数の説明を記述するについては、「」を参照してください。

例:

値の書式に一貫性がない

変換のあいまいさは、システムが数値、日付、パーセンテージなどの値をフォーマットする方法がわからない場合に発生する可能性があります。

症状: は同じ変数optionsを表示しますが、値形式は異なります。たとえば、1 つのオプションは「5%」を に変換interestRate = 5し、もう 1 つのオプションはそれを に変換しますinterestRate = 0.05。

修正: 変数の説明を更新して、予想される形式を指定し、変換ルールを含めます。「変数の説明で単位と形式を指定する」を参照してください。

あいまいな入力テキスト

入力自体が真にあいまいである場合があります。あいまいな代名詞、不明瞭な参照、または複数の方法で解釈できるステートメントが含まれます。

症状: は、同じテキストの根本的に異なる解釈optionsを示しています。たとえば、「休暇を取ることはできますか？」と入力します。は、任意の従業員タイプを参照できます。

修正: これがテストの場合は、より具体的に入力を書き換えます。実行時に、アプリケーションはTRANSLATION_AMBIGUOUS結果を受け取ったときにユーザーに明確化を求める必要があります。統合パターンについては、「」を参照してください自動推論チェックをアプリケーションに統合する。

信頼度しきい値を調整する

境界線があいまいな入力TRANSLATION_AMBIGUOUSの結果が表示された場合は、信頼度しきい値を調整できます。しきい値を下げると、モデル契約が少ない翻訳が検証に進むことができ、TRANSLATION_AMBIGUOUS結果が減少しますが、翻訳が不正確になるリスクが高まります。

ルールの問題を修正

ルールの問題は、翻訳が正しいが、ポリシーロジックがドメインと一致しない場合に発生します。適切な変数が適切な値で割り当てられていることを確認しましたが、検証結果はまだ間違っています。

INVALID が予想されたときに VALID を取得する

ポリシーには、クレームを禁止するルールはありません。レスポンスはドメインの知識と矛盾しますが、ポリシーで許可されます。

診断: 検出結果supportingRulesの を確認します。これらは、クレームが有効であることを証明するルールです。これらのルールが正しいかどうか、またはルールがないかどうかを確認します。

一般的な原因と修正:

VALID が想定されたときに INVALID を取得する

ポリシーには、クレームを誤って禁止するルールがあります。

診断: 検出結果contradictingRulesの を確認します。これらは、クレームを否定するルールです。これらのルールが正しいかどうかを確認します。

一般的な原因と修正:

VALID が予想されるときに SATISFIABLE を取得する

レスポンスは一部の条件では正しいですが、すべてではありません。ポリシーには、レスポンスが対処しない追加のルールがあります。

診断: 検出結果claimsFalseScenarioの claimsTrueScenarioと を比較します。これらの違いは、レスポンスが言及していない条件を示しています。

一般的な原因と修正:

不可能な結果を修正する

IMPOSSIBLE その結果、オンプレミスが矛盾しているか、ポリシー自体に競合するルールが含まれているため、Automated Reasoning チェックではクレームを評価できません。2 つの異なる原因があります。

入力の矛盾

テスト入力には、相互に矛盾するステートメントが含まれています。たとえば、「私は正社員であり、パートタイムでもあります」は isFullTime = trueと isFullTime = falseを同時に設定しますが、これは論理的には不可能です。

診断: 検出結果のtranslationオンプレミスを検査します。矛盾する値が割り当てられている変数を探します。

修正: これがテストの場合は、入力を書き換えて矛盾を削除します。実行時に、アプリケーションは入力を明確にするようユーザーに求めてIMPOSSIBLE結果を処理する必要があります。

ポリシーの競合

このポリシーには相互に矛盾するルールが含まれているため、自動推論チェックが競合するルールを含む入力の結論に達することは不可能です。

診断: 入力が有効な場合 (矛盾する施設がない場合）、問題はポリシーにあります。結果の contradictingRulesフィールドをチェックして、競合するルールを特定します。また、品質レポート (「」を参照品質レポートを使用する) も確認してください。競合するルールに自動的にフラグが付けられます。

一般的な原因と修正:

注釈を使用してポリシーを修復する

注釈は、テストが失敗したときにポリシーに適用するターゲットを絞った修正です。ルールと変数を手動で編集する代わりに、注釈を使用して必要な変更を記述し、自動推論チェックを適用できます。注釈は、コンソールと API の両方で使用できます。

コンソールで注釈を適用する

API を使用して注釈を適用する

で StartAutomatedReasoningPolicyBuildWorkflow API を使用してREFINE_POLICY、プログラムで注釈を適用します。現在のポリシー定義全体を注釈とともに渡します。

注釈タイプは次のとおりです。

例: 注釈を使用して欠落している変数とルールを追加する

aws bedrock start-automated-reasoning-policy-build-workflow \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-type REFINE_POLICY \
  --source-content "{
    \"policyDefinition\": EXISTING_POLICY_DEFINITION_JSON,
    \"workflowContent\": {
      \"policyRepairAssets\": {
        \"annotations\": [
          {
            \"addVariable\": {
              \"name\": \"tenureMonths\",
              \"type\": \"int\",
              \"description\": \"The number of complete months the employee has been continuously employed. When users mention years of service, convert to months (for example, 2 years = 24 months).\"
            }
          },
          {
            \"addRuleFromNaturalLanguage\": {
              \"naturalLanguage\": \"If an employee is full-time and has more than 12 months of tenure, then they are eligible for parental leave.\"
            }
          }
        ]
      }
    }
  }"

注釈の例

例 1: 欠落しているテニュア要件を修正する

問題: ポリシーはすべてのフルタイム従業員の親休暇を承認しますが、ソースドキュメントには 12 か月以上の在職期間が必要です。

例 2: TRANSLATION_AMBIGUOUS の原因となる重複する変数を修正

問題: 2 つの変数 (tenureMonths と monthsOfService) が同じ概念を表しているため、翻訳に一貫性がありません。

注釈:

例 3: IMPOSSIBLE 結果を引き起こすベアアサーションを修正

問題: ルール(= eligibleForParentalLeave true)は、ユーザーが適格でないと入力が要求できないようにするベアアサーションです。

注釈:

品質レポートを使用する

品質レポートは、各ビルドワークフローの後に生成され、テストの失敗を引き起こす可能性のあるポリシー内の構造上の問題を特定します。コンソールでは、品質レポートの問題が 定義ページに警告として表示されます。API 経由で、 GetAutomatedReasoningPolicyBuildWorkflowResultAssetsで を使用します--asset-type QUALITY_REPORT。

品質レポートでは、次の問題にフラグが付けられます。

競合するルール

2 つ以上のルールが同じ条件セットに対して矛盾する結論に達します。ルールが競合すると、ポリシーは競合するルールを含むすべての検証リクエストIMPOSSIBLEに対して を返します。

例: ルール A は (=> isFullTime eligibleForLeave)を、ルール B は を記述します(=> (<= tenureMonths 6) (not eligibleForLeave))。在職期間が 3 か月のフルタイム従業員の場合、ルール A は適格と答え、ルール B は対象外と答えます。これは矛盾です。

修正: 明示的な条件でルールを 1 つのルールにマージします。 (=> (and isFullTime (> tenureMonths 6)) eligibleForLeave)または、競合するルールのいずれかが誤って抽出された場合は削除します。

未使用の変数

ルールによって参照されていない変数。未使用の変数は変換プロセスにノイズを追加し、同じ概念で同様のアクティブな変数と競合すると、TRANSLATION_AMBIGUOUS結果を引き起こす可能性があります。

修正: 将来の反復で参照するルールを追加する予定がない限り、未使用の変数を削除します。

未使用の型値

ルールによって参照されないカスタムタイプ (列挙型) の値。たとえば、LeaveType列挙値に PARENTAL、MEDICAL、BEREAVEMENT、PERSONAL の値があっても、ルールが PERSONAL を参照していない場合、未使用としてフラグが付けられます。

修正: 未使用の値を参照するルールを追加するか、列挙型から削除します。未使用の値は、入力が概念に言及しているが、それを処理するルールがない場合、翻訳の問題を引き起こす可能性があります。

Disjoint ルールセット

変数を共有しないルールのグループ。不結合ルールセットは必ずしも問題ではありません。ポリシーは、意図的に独立したトピック (休暇資格や経費の払い戻しなど) をカバーしている可能性があります。ただし、関連するルール間の接続が変数にないことを示すことができます。

アクションのタイミング: 分離ルールセットを関連付ける必要がある場合 (たとえば、両者は従業員の利益を処理しますが、同じ概念に異なる変数名を使用）、重複する変数をマージして接続します。ルールセットが本当に独立している場合、アクションは必要ありません。

ポリシーの絞り込みに Kiro CLI を使用する

Kiro CLI は、ポリシーの問題の診断と修正のためのインタラクティブなチャットインターフェイスを提供します。自然言語の会話を通じて、ポリシー定義と品質レポートをロードし、テストが失敗する理由を説明し、変更を提案し、注釈を適用できます。

Kiro CLI は、特に以下の場合に便利です。

ワークフローの例:

You: The test with ID test-12345 is not returning the expected result.
     Can you load the test definition and findings, look at the policy
     definition, and explain why this test is failing?

Kiro: [analyzes the test and policy] The test expects VALID but gets
      INVALID because rule R3 requires 24 months of tenure, while the
      test input specifies 18 months. The source document says 12 months.
      Rule R3 appears to have been misextracted.

You: Can you suggest changes to fix this?

Kiro: I suggest updating rule R3 to change the tenure threshold from 24
      to 12 months. Here's the updated rule: ...

You: Looks good. Can you use the annotation APIs to submit these changes?

Kiro: [applies annotations via the API]

自動推論ポリシーで Kiro CLI を設定して使用する詳細な手順については、「」を参照してください自動推論ポリシーで Kiro CLI を使用する。