本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 自動化推理政策最佳實務
<a name="automated-reasoning-policy-best-practices"></a>

此頁面會合併建立和維護自動化理由政策的最佳實務。在建立第一個政策之前，請先閱讀此內容，並在偵錯問題時回頭參考。如需這些實務背後的概念基礎，請參閱 [自動化理由檢查概念](automated-reasoning-checks-concepts.md)。如需step-by-step建立說明，請參閱 [建立自動推理政策](create-automated-reasoning-policy.md)。

## 開始簡單並反覆執行
<a name="bp-start-simple"></a>

建立自動推理政策時最常見的錯誤是嘗試以單一傳遞擷取整個複雜的文件。反之，請從規則的重點子集開始，並逐步建置。

1. 選擇來源文件的單一、定義明確的區段 （例如，人力資源手冊中的親職休假資格）。

1. 從該區段建立政策，並檢閱擷取的規則和變數。

1. 撰寫涵蓋該區段關鍵案例的測試。

1. 在新增更多內容之前修正任何問題。

1. 使用反覆政策建置一次合併一個額外的區段。如需詳細資訊，請參閱[反覆政策建置](create-automated-reasoning-policy.md#iterative-policy-building)。

這種方法有兩個優點：它可以更輕鬆地隔離問題 （您知道哪個區段引入了問題），並在開發期間保持可管理政策。具有 10 個經過良好測試規則的政策比具有 100 個未經測試規則的政策更有用。

## 使用 LLM 預先處理文件
<a name="bp-preprocess-with-llm"></a>

對於冗長、包含敘述性內容的文件，或將規則與非規則內容 （例如法律免責聲明或組織背景） 混合，請在將文件上傳至自動化理由檢查之前，透過 LLM 執行文件。要求 LLM 依明確的 if-then 規則擷取內容。此預先處理步驟可大幅改善擷取政策的品質，因為自動化原因檢查最適合使用清晰的宣告式陳述式，而非非結構化文字。

撰寫您的預先處理提示時，請包含 LLM 的下列指示：
+ 以 if-then 格式擷取規則，並具有明確的條件和後果。
+ 保留所有條件、邏輯運算子 (AND、OR、 NOT)、量化器 (「至少」、「最多」) 和例外子句 (「除非」、「例外」)。
+ 新增常識限制的健全度規則，例如「帳戶餘額不能為負數」或「信用分數必須介於 300 到 850」，這會轉換為政策中的界限規則 （請參閱 [驗證數值的範圍](#bp-validate-ranges))。

**重要**  
使用 LLM 做為來源文字之前，請務必針對原始文件檢閱 LLM 的輸出。LLMs可能會幻覺來源中不存在的規則、錯誤解譯條件或捨棄重要的例外狀況。預先處理步驟是起點，不能取代人工檢閱。

如需詳細的提示範本和step-by-step預先處理工作流程，請參閱 [（選用） 使用 LLM 將文件重寫為邏輯規則](create-automated-reasoning-policy.md#preprocess-with-llm)。

## 使用影響 (=>) 來建構規則
<a name="bp-use-implications"></a>

if-then 格式 `=>` （使用隱含運算子） 是最重要的單一規則撰寫模式。每個表達條件關係的規則都應使用此格式。


| 良好：隱含 | 錯誤：裸露聲明 | 
| --- | --- | 
| (=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave) | eligibleForParentalLeave | 
| (=> (> loanAmount 500000) requiresCosigner) | requiresCosigner | 

裸露聲明 （沒有 if-then 結構的規則） 會建立軸線 — 一律為 true 的陳述式。宣告`eligibleForParentalLeave`會告知自動理由檢查，無論任何條件為何，父系休假資格一律為 true。任何指出使用者*不符合*條件的輸入都會傳回，`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)。

## 撰寫完整的變數描述
<a name="bp-variable-descriptions"></a>

變數描述是轉譯準確度的主要因素。自動化推理檢查將自然語言轉換為正式邏輯時，會使用變數描述來判斷哪些變數對應至文字中提到的概念。模糊或不完整的描述是`TRANSLATION_AMBIGUOUS`結果的頭號原因。

良好的變數描述應回答四個問題：

1. **此變數代表什麼？** 以純語言說明概念。

1. **它使用哪個單位或格式？** 指定單位 （月、美元、百分比作為小數） 和任何轉換規則。

1. **使用者如何參考此概念？** 包含同義詞、替代措辭，以及使用者以日常語言表達此概念的常見方式。

1. **什麼是邊界條件？** 描述邊緣案例、預設值，以及變數在設定為特定值時的意義。

**範例：前後**


| 模糊 （導致翻譯失敗） | 詳細 （可靠翻譯） | 
| --- | --- | 
| tenureMonths：「員工已工作多久。」 | tenureMonths：「持續雇用員工的完整月份數。當使用者提到服務年限時，請轉換為月數 （例如 2 年 = 24 個月）。對於尚未完成第一個月的新員工，請將 設為 0。」 | 
| isFullTime：「全職狀態」。 | isFullTime：「員工是全職 (true) 還是兼職 (false) 工作。當使用者提到 'full-time'、工作 'full hours' 或每週工作超過 40 小時時，設為 true。當使用者提到「兼職」、工作「減少時數」或每週工作少於 40 小時時，設定為 false。」 | 
| interestRate：「利率」。 | interestRate：「年利率以十進位值表示，其中 0.05 表示 5%，0.15 表示 15%。當使用者提到「5%」之類的百分比時，請轉換為小數形式 (0.05)。」 | 

## 針對非專屬狀態使用布林值
<a name="bp-booleans-non-exclusive"></a>

建立可共存的狀態模型時，請使用不同的布林值變數，而非單一列舉。一個人可以是資深人員和老師。使用列舉會在兩者之間`customerType = {VETERAN, TEACHER}`強制選擇，並在兩者套用時建立邏輯衝突。


| 良好：個別布林值 | 錯誤：非專屬狀態的列舉 | 
| --- | --- | 
|  `isVeteran` （布爾）：「客戶是否為兵役退役軍人」。 `isTeacher` (bool)：「客戶是否為老師」。  |  `customerType` （列舉：VETERAN、TEACHER、STUDENT)：「客戶類型」。 問題：無法代表同時是資深和老師的客戶。  | 

預留列舉給真正互斥的類別，其中一次只能套用一個值，例如 `leaveType = {PARENTAL, MEDICAL, BEREAVEMENT}`（員工一次只能請求一種休假）。如需自訂類型的詳細資訊，請參閱 [自訂類型 （列舉）](automated-reasoning-checks-concepts.md#ar-concept-custom-types)。

## 在變數描述中指定單位和格式
<a name="bp-units-formats"></a>

單位的模棱兩可性是翻譯錯誤的常見來源。如果使用者說「我在這裡工作了 2 年」且您的變數是 `tenureMonths`，則翻譯需要知道 才能將年轉換為月。如果您的變數描述未指定單位，則翻譯可能會指派 `tenureMonths = 2`而非 `tenureMonths = 24`。

一律指定：
+ 測量單位 （月、日、美元、百分比）。
+ 格式 （小數與百分比、日期格式、貨幣）。
+ 常見替代表達式的轉換規則 （例如，「2 年 = 24 個月」)。

**範例**：
+ `loanAmount`：「貸款金額總計，以美元為單位。當使用者提到以千為單位的金額時 （例如 '500K')，請轉換為完整數字 (500000)。」
+ `submissionDate`：「提交到期日之後的天數。值為 0 表示提交準時。正值表示延遲提交。」

## 驗證數值的範圍
<a name="bp-validate-ranges"></a>

對於數值變數，新增限制有效範圍的邊界規則。這可防止邏輯上不可能的情況，並協助自動化合理性檢查產生更有意義的結果。

```
;; 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)
```

如果沒有這些界限規則，自動推理檢查可能會考慮帳戶餘額或點數超過 1000 的負面案例，這在您的網域中沒有意義。邊界規則是裸露聲明 （規則不是 if-then 格式） 適用的少數案例之一。

## 使用中繼變數進行抽象化
<a name="bp-intermediate-variables"></a>

當多個規則共用共同條件時，請將該條件擷取至中繼布林值變數。這可簡化您的規則，並使政策更容易維護。

**範例：成員資格方案**

而不是在每個利益規則中重複成員資格條件：

```
;; 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)
```

此模式可讓您稍後更輕鬆地更新成員資格條件，您只需變更一個規則，而不需要變更三個規則。

## 使用列舉進行分類
<a name="bp-enums-categorization"></a>

當變數代表具有一組固定互斥值的類別時，請使用自訂類型 （列舉），而不是多個布林值或字串。列舉會限制可能的值，並讓規則更清楚。


| 良好：列舉 | 避免：專屬狀態的多個布林值 | 
| --- | --- | 
|  類型：`LeaveType = {PARENTAL, MEDICAL, BEREAVEMENT, PERSONAL}` 變數：`leaveType`(LeaveType) 規則： `(=> (= leaveType PARENTAL) (>= leaveDays 60))`  |  `isParentalLeave` (bool) `isMedicalLeave` (bool) `isBereavementLeave` (bool) 問題：沒有什麼可以防止多個布林值同時成為 true。  | 

**提示**  
如果輸入可能不符合任何定義的類別，請在列舉中包含 `OTHER`或 `NONE`值。這可防止輸入不適合其中一個定義值時的轉譯問題。

## 保持邏輯宣告，而非程序性
<a name="bp-declarative-logic"></a>

自動化推理政策說明*什麼是 true*，而不是*如何運算它*。避免編寫類似具有循序步驟或優先順序邏輯之程式碼的規則。


| 良好：宣告式 | 避免：程序性思考 | 
| --- | --- | 
|  「如果員工是全職員工，並且有超過 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.
```

## 命名慣例
<a name="bp-naming-conventions"></a>

一致的命名可讓政策更易於讀取、維護和偵錯。請遵循下列慣例：
+ **布林值變數：**使用 `is`或 `has`字首。例如 `isFullTime`、`hasDirectDeposit`、`isEligibleForLeave`。
+ **數值變數：**在名稱中包含單位。例如 `tenureMonths`、`loanAmountUSD`、`creditScore`。
+ **列舉類型：**類型名稱使用 PascalCase，值使用 UPPER\$1SNAKE\$1CASE。例如：`LeaveType = {PARENTAL, MEDICAL, BEREAVEMENT}`。
+ **變數：**使用 camelCase。例如 `tenureMonths`、`isFullTime`、`leaveType`。

避免可能模棱兩可的縮寫。使用 `tenureMonths`而非 `tenMo`，以及 `isFullTime` 而非 `ft`。清除名稱有助於人工檢閱者和翻譯程序。

## 常見的反模式
<a name="bp-anti-patterns"></a>

下列模式經常導致自動化合理化政策中的問題。如果您遇到非預期的測試結果，請檢查您的政策是否包含任何這些反模式。

### 軸線而非含意
<a name="bp-anti-axioms"></a>

如 中所述[使用影響 (=>) 來建構規則](#bp-use-implications)，裸露聲明會建立一律為 true 的軸線。這是最常見的反模式和最具破壞性 — 它讓整個類別的輸入傳回 `IMPOSSIBLE`。

**徵狀：**應`IMPOSSIBLE`改為傳回`VALID`或`INVALID`傳回的測試。

**修正：**在您的規則中尋找裸露聲明，並將其重寫為含意，如果它們不代表界限條件，則將其刪除。

### 重疊變數
<a name="bp-anti-overlapping-variables"></a>

有兩個代表相同或類似概念的變數 （例如 `tenureMonths`和 `monthsOfService`) 會混淆轉譯程序。自動化理由檢查無法判斷用於指定概念的變數，導致不一致的轉譯和`TRANSLATION_AMBIGUOUS`結果。

**徵狀：**`TRANSLATION_AMBIGUOUS`即使輸入文字清晰不明確，測試也會傳回。

**修正：**將重疊變數合併為具有完整描述的單一變數。更新參考已刪除變數的所有規則。

### 過於複雜的政策
<a name="bp-anti-overly-complex"></a>

具有太多變數、深度巢狀條件或非線性算術的政策可能會超過處理限制並傳回`TOO_COMPLEX`結果。

**徵狀：**測試傳回`TOO_COMPLEX`或逾時。

**修正：**簡化政策。移除未使用的變數，使用中繼變數將複雜的規則分解為較簡單的變數，並避免非線性算術 （指數、不合理數字）。如果您的網域真的複雜，請考慮將其分割成多個聚焦政策。

### 矛盾的規則
<a name="bp-anti-contradictory-rules"></a>

相互矛盾的規則使得自動推理檢查無法得出結論。例如，一個規則表示全職員工符合休假資格，另一個規則則表示第一年的員工不符合資格，而不指定第一年全職員工會發生什麼情況。

**徵狀：**測試`IMPOSSIBLE`傳回涉及衝突規則的輸入。

**修正：**檢查品質報告是否有衝突的規則。將規則合併為具有明確條件的單一規則，或刪除其中一個衝突規則，以解決衝突。如需詳細資訊，請參閱[檢閱解壓縮的政策](create-automated-reasoning-policy.md#review-extracted-policy)。

### 未使用的變數
<a name="bp-anti-unused-variables"></a>

任何規則未參考的變數都會將雜訊新增至轉譯程序。轉換可能會將值指派給未使用的變數，浪費處理容量，並可能在未使用的變數與類似的作用中變數競爭時產生`TRANSLATION_AMBIGUOUS`結果。

**徵狀：**非預期`TRANSLATION_AMBIGUOUS`的結果，或將值指派給不影響任何規則之變數的轉譯。

**修正：**刪除未使用的變數。在 主控台中，尋找變數旁的警告指標。透過 API，`GetAutomatedReasoningPolicyBuildWorkflowResultAssets`使用 從 檢查品質報告`--asset-type QUALITY_REPORT`。

### 缺少列舉值
<a name="bp-anti-missing-enum-values"></a>

如果您的列舉未包含使用者可能提及的每個可能類別的值，則當輸入不符合任何定義的值時，轉譯可能會失敗或產生非預期的結果。

**徵狀：**測試傳回`TRANSLATION_AMBIGUOUS`或輸入提及不在列舉中的類別`NO_TRANSLATIONS`時。

**修正：**將 `OTHER`或 `NONE`值新增至列舉，以處理不符合已定義類別的輸入。更新列舉值描述，以釐清何時套用每個值。