翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 自動推論ポリシーのベストプラクティス このページには、自動推論ポリシーを作成および維持するためのベストプラクティスがまとめられています。最初のポリシーを作成する前にこれを読み、問題をデバッグするときに参照してください。これらのプラクティスの概念的な基盤については、「」を参照してください[自動推論チェックの概念](automated-reasoning-checks-concepts.md)。step-by-stepの作成手順については、「」を参照してください[自動推論ポリシーを作成する](create-automated-reasoning-policy.md)。 ## シンプルに開始して反復する 自動推論ポリシーを作成する際の最も一般的な間違いは、複雑なドキュメント全体を 1 回のパスでキャプチャしようとすることです。代わりに、ルールの焦点を絞ったサブセットから始めて、段階的に構築します。 1. ソースドキュメントの明確に定義されたセクションを 1 つ選択します (HR ハンドブックの親休暇資格など）。 1. そのセクションからポリシーを作成し、抽出されたルールと変数を確認します。 1. そのセクションの主要なシナリオをカバーするテストを記述します。 1. コンテンツを追加する前に問題を修正します。 1. 反復ポリシー構築を使用して、追加のセクションを一度に 1 つずつマージします。詳細については、「[反復ポリシーの構築](create-automated-reasoning-policy.md#iterative-policy-building)」を参照してください。 このアプローチには 2 つの利点があります。問題を簡単に分離し (どのセクションで問題が発生したかがわかります）、開発中にポリシーを管理できるようにします。適切にテストされたルールが 10 個あるポリシーは、テストされていないルールが 100 個あるポリシーよりも便利です。 ## LLM を使用してドキュメントを前処理する 長いドキュメント、説明文を含むドキュメント、またはルール以外のコンテンツ (法的免責事項や組織の背景など) を含むルールを混在させるドキュメントの場合、ドキュメントを LLM で実行してから自動推論チェックにアップロードします。明示的な if-then ルールとしてコンテンツを抽出するように LLM に依頼します。この前処理ステップは、自動推論チェックが非構造化テキストではなく明確で宣言的なステートメントで最適に機能するため、抽出されたポリシーの品質を大幅に向上させます。 前処理プロンプトを書き込むときは、LLM に次の手順を含めます。 + if-then 形式でルールを抽出し、明確な条件と結果を示します。 + すべての条件、論理演算子 (AND、OR、NOT)、定量化子 (「少なくとも」、「最大」）、および例外句 (「ない限り」、「ときを除く」) を保持します。 + 「アカウント残高を負にすることはできません」や「クレジットスコアは 300～850」など、一般的な制約のサニティルールを追加し、ポリシーの境界ルールに変換します (「」を参照[数値の範囲を検証する](#bp-validate-ranges))。 **重要** LLM の出力をソーステキストとして使用する前に、必ず元のドキュメントと照合して確認してください。LLMsソースに存在しないルールをハルシネーションしたり、条件を誤って解釈したり、重要な例外を削除したりする可能性があります。前処理ステップは開始点であり、人間によるレビューに代わるものではありません。 詳細なプロンプトテンプレートとstep-by-stepの前処理ワークフローについては、「」を参照してください[(オプション) LLM を使用してドキュメントを論理ルールとして書き換える](create-automated-reasoning-policy.md#preprocess-with-llm)。 ## 影響 (=>) を使用してルールを構築する if-then 形式 ( インプリケーション演算子を使用) `=>` は、最も重要な 1 つのルール書き込みパターンです。条件付き関係を表すすべてのルールは、この形式を使用する必要があります。 | 良い: インプリケーション | 不良: ベアアサーション | | --- | --- | | (=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave) | eligibleForParentalLeave | | (=> (> loanAmount 500000) requiresCosigner) | requiresCosigner | ベアアサーション (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)) ``` 抽出されたポリシーにベアアサーションが見つかった場合は、条件付きとして書き換えるか、削除します。抽出されたポリシーの確認の詳細については、「」を参照してください[抽出されたポリシーを確認する](create-automated-reasoning-policy.md#review-extracted-policy)。 ## 包括的な変数の説明を記述する 変数の説明は、翻訳精度の主要な要素です。自動推論チェックは自然言語を正式なロジックに変換する場合、変数の説明を使用して、テキストで説明されている概念に対応する変数を決定します。曖昧な説明や不完全な説明は、`TRANSLATION_AMBIGUOUS`結果の最大の原因です。 適切な変数の説明は、次の 4 つの質問に答える必要があります。 1. **この変数は何を表しますか?** 概念を平易な言語で説明します。 1. **どの単位または形式を使用していますか?** 単位 (月、ドル、10 進数としてのパーセンテージ) と変換ルールを指定します。 1. **ユーザーはこの概念をどのように参照しますか?** シノニム、代替フレーズ、およびユーザーがこの概念を日常的な言語で表現する一般的な方法を含めます。 1. **境界条件は何ですか?** エッジケース、デフォルト値、および特定の値に設定した場合の変数の意味について説明します。 **例: 前後** | 曖昧 (翻訳が失敗する) | 詳細 (確実に翻訳) | | --- | --- | | tenureMonths: 「従業員が勤務した期間」。 | tenureMonths: 「従業員が継続的に雇用された完全な月数。ユーザーが長年のサービスについて言及する場合は、 を月 (2 年 = 24 か月など) に変換します。最初の月をまだ完了していない新規採用者の場合、 を 0 に設定します。」 | | isFullTime: 「フルタイムステータス」 | isFullTime: 「従業員がフルタイム (true) かパートタイム (false) か。ユーザーが「フルタイム」、「フルタイム」、または週に 40 時間以上勤務していると言及する場合は true に設定します。ユーザーが「パートタイム」、「短時間勤務」、または週 40 時間未満の勤務について言及した場合は false に設定します。」 | | interestRate: 「利率」 | interestRate: 「年利は 10 進値で表されます。0.05 は 5%、0.15 は 15% を意味します。ユーザーが「5%」のようなパーセンテージに言及する場合は、10 進数形式 (0.05) に変換します。」 | ## 非排他的状態のブール値を使用する が共存できる状態をモデリングする場合は、単一の列挙型の代わりに個別のブール変数を使用します。退役軍人でも教師でもかまいません。列挙型を使用すると、選択肢が`customerType = {VETERAN, TEACHER}`強制的に選択され、両方が適用されると論理的な矛盾が生じます。 | 良い: ブール値を区切る | Bad: 非排他的状態の列挙型 | | --- | --- | | `isVeteran` (ブール): 「お客様が退役軍人かどうか」。
`isTeacher` (bool): 「顧客が教師かどうか」 | `customerType` (列挙: VETERAN、TEACHER、STUDENT): 「顧客のタイプ」。
問題: 退役軍人と教師の両方である顧客は表現できません。 | 列挙型は、一度に 1 つの値しか適用できない、真に相互に排他的なカテゴリ用に予約します `leaveType = {PARENTAL, MEDICAL, BEREAVEMENT}` (従業員は一度に 1 つのタイプの休暇のみをリクエストできます）。カスタムタイプの詳細については、「」を参照してください[カスタムタイプ (列挙型)](automated-reasoning-checks-concepts.md#ar-concept-custom-types)。 ## 変数の説明で単位と形式を指定する 単位に関するあいまいさは、翻訳エラーの一般的な原因です。ユーザーが「ここで働いたのは 2 年です」と言っていて、変数が である場合`tenureMonths`、翻訳は年を月に変換するために を知る必要があります。変数の説明で単位が指定されていない場合、翻訳は `tenureMonths = 2`の代わりに を割り当てます`tenureMonths = 24`。 常に以下を指定します。 + 測定単位 (月、日、ドル、パーセンテージ）。 + 形式 (10 進数とパーセンテージ、日付形式、通貨）。 + 一般的な代替式の変換ルール (例: "2 years = 24 months")。 **例:** + `loanAmount`: 「米ドルの合計ローン額。ユーザーが数千単位 (「500K」など) で言及する場合、 を整数 (500,000) に変換します。」 + `submissionDate`: 「送信が行われた期日からの日数。値 0 は、送信が時間どおりであったことを意味します。正の値は送信が遅れたことを示します。」 ## 数値の範囲を検証する 数値変数の場合は、有効な範囲を制限する境界ルールを追加します。これにより、論理的に不可能なシナリオを防ぎ、自動推論チェックがより意味のある結果を生成するのに役立ちます。 ``` ;; 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 つのルールを変更するだけで済みます。 ## 分類に列挙型を使用する 変数が相互に排他的な値の固定セットを持つカテゴリを表す場合は、複数のブール値または文字列の代わりにカスタムタイプ (列挙型) を使用します。列挙型は可能な値を制約し、ルールをより明確にします。 | 良い: 列挙型 | 回避: 排他的状態の複数のブール値 | | --- | --- | | 型: `LeaveType = {PARENTAL, MEDICAL, BEREAVEMENT, PERSONAL}`
変数: `leaveType` (LeaveType)
ルール: `(=> (= leaveType PARENTAL) (>= leaveDays 60))` | `isParentalLeave` (ブール)
`isMedicalLeave` (ブール)
`isBereavementLeave` (ブール)
問題: 複数のブール値が同時に発生するのを防ぐものはありません。 | **ヒント** 入力が定義されたカテゴリのいずれとも一致しない可能性がある場合は、列挙型に `OTHER`または `NONE`の値を含めます。これにより、入力が定義された値の 1 つに正しく収まらない場合の変換の問題を回避できます。 ## 手続き型ではなく宣言型のロジックを維持する 自動推論ポリシーは、その計算方法ではなく、*正しいものを*記述します。 **シーケンシャルステップや優先順位ロジックを使用して、コードのようなルールを記述することは避けてください。 | 良い: 宣言的 | 回避: 手続き型思考 | | --- | --- | | 「従業員がフルタイムで、12 か月を超える在職期間がある場合は、親休暇の対象となります。」
これは、条件と結果の関係に関する事実を示しています。 | 「従業員がフルタイムであるかどうかを最初に確認します。「はい」の場合は、テニュアを確認します。在職期間が 12 か月を超える場合は、資格を true に設定します。」
これは、論理的な関係ではなく、プロシージャを記述します。 | 同様に、ルール間のエンコードの優先順位や優先度は避けてください。正式なロジックでは、すべてのルールが同時に適用されます。ある条件が別の条件を上書きすることを表現する必要がある場合は、ルール条件で明示的にエンコードします。 ``` ;; 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. ``` ## 命名規則 一貫した命名により、ポリシーの読み取り、保守、デバッグが容易になります。以下の規則に従います。 + **ブール変数:** `is`または `has` プレフィックスを使用します。例えば、`isFullTime`、`hasDirectDeposit`、`isEligibleForLeave` などが挙げられます。 + **数値変数:** 名前に単位を含めます。例えば、`tenureMonths`、`loanAmountUSD`、`creditScore` などが挙げられます。 + **列挙型:** 型名には PascalCase を使用し、値には UPPER\_SNAKE\_CASE を使用します。例: `LeaveType = {PARENTAL, MEDICAL, BEREAVEMENT}`。 + **変数:** camelCase を使用します。例えば、`tenureMonths`、`isFullTime`、`leaveType` などが挙げられます。 あいまいな略語は避けてください。`tenureMonths` の代わりに を使用し`tenMo`、 `isFullTime` の代わりに を使用します`ft`。明確な名前は、人間によるレビュー担当者と翻訳プロセスの両方に役立ちます。 ## 一般的なアンチパターン 次のパターンは、Automated Reasoning ポリシーで頻繁に問題を引き起こします。予期しないテスト結果が発生した場合は、ポリシーにこれらのアンチパターンが含まれているかどうかを確認します。 ### 意味ではなくアクシオム で説明されているように[影響 (=>) を使用してルールを構築する](#bp-use-implications)、ベアアサーションは常に true のアキシオムを作成します。これは最も一般的なアンチパターンであり、最もダメージを与えます。入力のカテゴリ全体が を返します`IMPOSSIBLE`。 **症状:** `IMPOSSIBLE`が代わりに返`VALID`すか`INVALID`返すテスト。 **修正:** ルールでベアアサーションを見つけて影響として書き換えるか、境界条件を表していない場合は削除します。 ### 重複する変数 同じ概念または類似の概念 ( `tenureMonths`や など`monthsOfService`) を表す 2 つの変数があると、翻訳プロセスが混乱します。自動推論チェックでは、特定の概念に使用する変数を判断できず、翻訳と`TRANSLATION_AMBIGUOUS`結果に一貫性がありません。 **症状:** 明確であいまいな入力テキスト`TRANSLATION_AMBIGUOUS`でもテストは返ります。 **修正:** 重複する変数を包括的な説明を含む単一の変数にマージします。削除された変数を参照するすべてのルールを更新します。 ### 過度に複雑なポリシー 変数が多すぎる、深くネストされた条件、または非線形算術を持つポリシーは、処理制限を超え、`TOO_COMPLEX`結果を返す可能性があります。 **症状:** テストが戻り`TOO_COMPLEX`またはタイムアウトします。 **修正:** ポリシーを簡素化します。未使用の変数を削除し、中間変数を使用して複雑なルールをより単純なものに分割し、非線形算術 (指数、不合理な数値) を回避します。ドメインが本当に複雑な場合は、複数のフォーカスポリシーに分割することを検討してください。 ### 矛盾するルール 相互に矛盾するルールにより、自動推論チェックが結論に到達できなくなります。例えば、あるルールでは、正社員には休暇の資格があり、別のルールでは、初年度の正社員には何が起こるかを指定せずに、初年度の正社員には資格がないと言います。 **症状:** 競合するルールを含む入力`IMPOSSIBLE`をテストします。 **修正:** 競合するルールの品質レポートを確認します。ルールを明示的な条件を持つ 1 つのルールにマージするか、競合するルールのいずれかを削除して、競合を解決します。詳細については、「[抽出されたポリシーを確認する](create-automated-reasoning-policy.md#review-extracted-policy)」を参照してください。 ### 未使用の変数 どのルールでも参照されない変数は、変換プロセスにノイズを追加します。変換では、未使用の変数に値が割り当てられ、処理容量が浪費され、未使用の変数が同様のアクティブな変数と競合した場合に`TRANSLATION_AMBIGUOUS`結果が発生する可能性があります。 **症状:** 予期しない`TRANSLATION_AMBIGUOUS`結果、またはルールに影響を与えない変数に値を割り当てる変換。 **修正:** 未使用の変数を削除します。コンソールで、変数の横にある警告インジケータを探します。API を使用して、 の品質レポートを `GetAutomatedReasoningPolicyBuildWorkflowResultAssets`で確認します`--asset-type QUALITY_REPORT`。 ### 列挙値の欠落 列挙型に、ユーザーが言及する可能性のあるすべてのカテゴリの値が含まれていない場合、入力が定義された値と一致しない場合、変換が失敗するか、予期しない結果を生成する可能性があります。 **症状:** 入力が列挙型にないカテゴリに言及`NO_TRANSLATIONS`すると、テストは `TRANSLATION_AMBIGUOUS`または を返します。 **修正:** 列挙型に `OTHER`または `NONE`値を追加して、定義されたカテゴリと一致しない入力を処理します。列挙値の説明を更新して、各値がいつ適用されるかを明確にします。