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

自動推論ポリシーのベストプラクティス

このページには、自動推論ポリシーを作成および維持するためのベストプラクティスがまとめられています。最初のポリシーを作成する前にこれを読み、問題をデバッグするときに参照してください。これらのプラクティスの概念的な基盤については、「」を参照してください自動推論チェックの概念。step-by-stepの作成手順については、「」を参照してください自動推論ポリシーを作成する。

シンプルに開始して反復する

自動推論ポリシーを作成する際の最も一般的な間違いは、複雑なドキュメント全体を 1 回のパスでキャプチャしようとすることです。代わりに、ルールの焦点を絞ったサブセットから始めて、段階的に構築します。

このアプローチには 2 つの利点があります。問題を簡単に分離し (どのセクションで問題が発生したかがわかります）、開発中にポリシーを管理できるようにします。適切にテストされたルールが 10 個あるポリシーは、テストされていないルールが 100 個あるポリシーよりも便利です。

LLM を使用してドキュメントを前処理する

長いドキュメント、説明文を含むドキュメント、またはルール以外のコンテンツ (法的免責事項や組織の背景など) を含むルールを混在させるドキュメントの場合、ドキュメントを LLM で実行してから自動推論チェックにアップロードします。明示的な if-then ルールとしてコンテンツを抽出するように LLM に依頼します。この前処理ステップにより、自動推論チェックは非構造化テキストではなく明確で宣言的なステートメントで最適に機能するため、抽出されたポリシーの品質が大幅に向上します。

前処理プロンプトを書き込むときは、LLM に次の手順を含めます。

詳細なプロンプトテンプレートとstep-by-stepの前処理ワークフローについては、「」を参照してください(オプション) LLM を使用してドキュメントを論理ルールとして書き換える。

影響 (=>) を使用してルールを構築する

if-then 形式 ( インプリケーション演算子を使用) => は、最も重要な 1 つのルール書き込みパターンです。条件付き関係を表すすべてのルールは、この形式を使用する必要があります。

ベアアサーション (if-then 構造のないルール) は、常に true であるアキシオムを作成します。アサーションは、条件に関係なく、親の休暇資格が常に true であることを自動推論チェックにeligibleForParentalLeave指示します。ユーザーが適格でないという入力は、このアキシオムと矛盾IMPOSSIBLEするため、 を返します。

ベアアサーションは、次のような常に保持する必要がある境界条件にのみ適しています。

;; Account balance can never be negative
(>= accountBalance 0)

;; Interest rate is always between 0 and 1
(and (>= interestRate 0) (<= interestRate 1))

抽出されたポリシーにベアアサーションが見つかった場合は、条件付きとして書き換えるか、削除します。抽出されたポリシーの確認の詳細については、「」を参照してください抽出されたポリシーを確認する。

包括的な変数の説明を記述する

変数の説明は、翻訳精度の主要な要素です。自動推論チェックは、自然言語を正式なロジックに変換する場合、変数の説明を使用して、テキストで説明されている概念に対応する変数を決定します。曖昧な説明や不完全な説明は、TRANSLATION_AMBIGUOUS結果の最大の原因です。

適切な変数の説明は、次の 4 つの質問に答える必要があります。

例: 前後

非排他的状態のブール値を使用する

が共存できる状態をモデリングする場合は、単一の列挙型の代わりに個別のブール変数を使用します。退役軍人でも教師でもかまいません。列挙型を使用すると、選択肢が強制customerType = {VETERAN, TEACHER}的に選択され、両方が適用されると論理的な矛盾が生じます。

例えば、一度に 1 つの値しか適用できない、真に相互に排他的なカテゴリ用に列挙型を予約します leaveType = {PARENTAL, MEDICAL, BEREAVEMENT} (従業員は一度に 1 つのタイプの休暇のみをリクエストできます）。カスタムタイプの詳細については、「」を参照してくださいカスタムタイプ (列挙型)。

変数の説明で単位と形式を指定する

単位に関するあいまいさは、翻訳エラーの一般的な原因です。ユーザーが「ここで働いたのは 2 年です」と言っていて、変数が の場合tenureMonths、翻訳は年を月に変換するために を知る必要があります。変数の説明で単位が指定されていない場合、翻訳は tenureMonths = 2の代わりに を割り当てますtenureMonths = 24。

常に以下を指定します。

例:

数値の範囲を検証する

数値変数には、有効な範囲を制限する境界ルールを追加します。これにより、論理的に不可能なシナリオを防ぎ、Automated Reasoning チェックがより意味のある結果を生成するのに役立ちます。

;; Account balance cannot be negative
(>= accountBalance 0)

;; Interest rate must be between 0 and 1 (0% to 100%)
(and (>= interestRate 0) (<= interestRate 1))

;; Credit score ranges from 300 to 850
(and (>= creditScore 300) (<= creditScore 850))

;; Tenure in months cannot be negative
(>= tenureMonths 0)

これらの境界ルールがないと、Automated Reasoning チェックでは、マイナスのアカウント残高またはクレジットスコアが 1000 を超えるシナリオが考慮される場合があります。これはドメインでは意味がありません。境界ルールは、ベアアサーション (if-then 形式ではないルール) が適切である数少ないケースの 1 つです。

抽象化に中間変数を使用する

複数のルールが共通の条件を共有する場合は、その条件を中間ブール変数に抽出します。これにより、ルールが簡素化され、ポリシーの管理が容易になります。

例: メンバーシップ階層

すべての特典ルールでメンバーシップ条件を繰り返す代わりに、次の操作を行います。

;; Without intermediate variable (repetitive)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForFreeShipping)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForPrioritySupport)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForEarlyAccess)

中間変数を定義し、それを参照します。

;; With intermediate variable (cleaner)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) isPremiumMember)
(=> isPremiumMember eligibleForFreeShipping)
(=> isPremiumMember eligibleForPrioritySupport)
(=> isPremiumMember eligibleForEarlyAccess)

このパターンにより、後でメンバーシップ条件を簡単に更新できます。3 つのルールではなく 1 つのルールを変更するだけで済みます。

分類に列挙型を使用する

変数が相互に排他的な値の固定セットを持つカテゴリを表す場合は、複数のブール値または文字列の代わりにカスタムタイプ (列挙型) を使用します。列挙型は可能な値を制約し、ルールをより明確にします。

手続き型ではなく宣言型のままにする

自動推論ポリシーは、その計算方法ではなく、正しいことを記述します。シーケンシャルステップや優先順位ロジックを使用して、コードのようなルールを記述することは避けてください。

同様に、ルール間のエンコードの優先順位や優先度は避けてください。正式なロジックでは、すべてのルールが同時に適用されます。ある条件が別の条件を上書きすることを表現する必要がある場合は、ルール条件で明示的にエンコードします。

;; GOOD: Explicit exception handling
;; General rule: full-time employees with 12+ months get parental leave
(=> (and isFullTime (> tenureMonths 12) (not isOnProbation))
    eligibleForParentalLeave)

;; BAD: Trying to encode precedence
;; "Rule 1 takes priority over Rule 2" — this concept doesn't exist
;; in formal logic. Instead, combine the conditions into a single rule.

命名規則

一貫した命名により、ポリシーの読み取り、保守、デバッグが容易になります。以下の規則に従います。

あいまいな略語は避けてください。tenureMonths の代わりに を使用しtenMo、 isFullTime の代わりに を使用しますft。明確な名前は、人間によるレビュー担当者と翻訳プロセスの両方に役立ちます。

一般的なアンチパターン

次のパターンは、Automated Reasoning ポリシーで頻繁に問題を引き起こします。予期しないテスト結果が発生した場合は、ポリシーにこれらのアンチパターンが含まれているかどうかを確認します。

意味ではなくアクシオム

で説明されているように影響 (=>) を使用してルールを構築する、ベアアサーションは常に true のアキシオムを作成します。これは最も一般的なアンチパターンであり、最もダメージを与えます。入力のカテゴリ全体が を返しますIMPOSSIBLE。

症状: IMPOSSIBLEが代わりに返VALIDすかINVALID返すテスト。

修正: ルールでベアアサーションを見つけて影響として書き換えるか、境界条件を表していない場合は削除します。

重複する変数

同じ概念または類似の概念 ( tenureMonthsや などmonthsOfService) を表す 2 つの変数があると、翻訳プロセスが混乱します。自動推論チェックでは、特定の概念に使用する変数を判断できないため、翻訳やTRANSLATION_AMBIGUOUS結果に一貫性がありません。

症状: 明確であいまいな入力テキストTRANSLATION_AMBIGUOUSでもテストは返ります。

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

過度に複雑なポリシー

変数が多すぎるポリシー、深くネストされた条件、または非線形算術は、処理制限を超え、TOO_COMPLEX結果を返す可能性があります。

症状: テストが戻りTOO_COMPLEXまたはタイムアウトします。

修正: ポリシーを簡素化します。未使用の変数を削除し、中間変数を使用して複雑なルールをより単純なものに分割し、非線形算術 (指数、不合理な数値) を回避します。ドメインが本当に複雑な場合は、複数のフォーカスポリシーに分割することを検討してください。

矛盾するルール

相互に矛盾するルールにより、自動推論チェックが結論に到達できなくなります。例えば、あるルールでは、正社員には休暇の資格があり、別のルールでは、初年度の正社員には何が起こるかを指定せずに、初年度の正社員には資格がないと言います。

症状: 競合するルールを含む入力IMPOSSIBLEをテストします。

修正: ルールの競合について品質レポートを確認します。ルールを明示的な条件を持つ単一のルールにマージするか、競合するルールのいずれかを削除して、競合を解決します。詳細については、「抽出されたポリシーを確認する」を参照してください。

未使用の変数

どのルールでも参照されない変数は、変換プロセスにノイズを追加します。変換では、未使用の変数に値が割り当てられ、処理容量が浪費され、未使用の変数が同様のアクティブな変数と競合すると、TRANSLATION_AMBIGUOUS結果が発生する可能性があります。

症状: 予期しないTRANSLATION_AMBIGUOUS結果、またはルールに影響を与えない変数に値を割り当てる変換。

修正: 未使用の変数を削除します。コンソールで、変数の横にある警告インジケータを探します。API を使用して、 の品質レポートを GetAutomatedReasoningPolicyBuildWorkflowResultAssetsで確認します--asset-type QUALITY_REPORT。

列挙値の欠落

列挙型に、ユーザーが言及する可能性のあるすべてのカテゴリの値が含まれていない場合、入力が定義された値と一致しない場合、変換が失敗したり、予期しない結果を生成したりすることがあります。

症状: 入力が列挙型にないカテゴリに言及NO_TRANSLATIONSすると、テストは TRANSLATION_AMBIGUOUSまたは を返します。

修正: 列挙型に OTHERまたは NONE値を追加して、定義されたカテゴリと一致しない入力を処理します。列挙値の説明を更新して、各値がいつ適用されるかを明確にします。