기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 자동 추론 정책 모범 사례
<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. 소스 문서의 잘 정의된 단일 섹션(예: HR 핸드북의 육아 휴가 자격)을 선택합니다.

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\$1850이어야 합니다"와 같은 상식적 제약 조건에 대한 안전 규칙을 추가하여 정책의 경계 규칙으로 변환합니다( 참조[숫자 값의 범위 검증](#bp-validate-ranges)).

**중요**  
원본 문서로 사용하기 전에 항상 원본 문서와 비교하여 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인 문인 axiom을 생성합니다. 어설션은 조건과 관계없이 육아 휴가 자격이 항상 참임을 자동 추론 검사에 `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).

## 포괄적인 변수 설명 작성
<a name="bp-variable-descriptions"></a>

변수 설명은 번역 정확도의 기본 요소입니다. 자동 추론 검사는 자연어를 공식 로직으로 변환할 때 변수 설명을 사용하여 텍스트에 언급된 개념에 해당하는 변수를 결정합니다. 모호하거나 불완전한 설명은 `TRANSLATION_AMBIGUOUS` 결과의 가장 큰 원인입니다.

좋은 변수 설명은 네 가지 질문에 답해야 합니다.

1. **이 변수는 무엇을 의미합니까?** 개념을 일반 언어로 설명합니다.

1. **어떤 단위 또는 형식을 사용하나요?** 단위(월, 달러, 백분율을 십진수로) 및 변환 규칙을 지정합니다.

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)으로 변환합니다." | 

## 비독점 상태에 부울 사용
<a name="bp-booleans-non-exclusive"></a>

공존할 수 있는 상태를 모델링하는 경우 단일 열거형 대신 별도의 부울 변수를 사용합니다. 사람은 재향 군인이자 교사일 수 있습니다. 열거형을 사용하면 두 열거형 간에 선택이 `customerType = {VETERAN, TEACHER}` 강제로 적용되므로 둘 다 적용될 때 논리적 모순이 발생합니다.


| 좋음: 별도의 부울 | 잘못된: 비독점 상태의 열거형 | 
| --- | --- | 
|  `isVeteran` (bool): "고객이 군인인지 여부" `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`.

항상 다음을 지정합니다.
+ 측정 단위(월, 일, 달러, 백분율).
+ 형식(10진수 대 백분율, 날짜 형식, 통화).
+ 일반적인 대체 표현식에 대한 변환 규칙(예: "2년 = 24개월").

**예**:
+ `loanAmount`: "미국 달러 단위의 총 대출 금액. 사용자가 수천 단위로 금액을 언급하면(예: '500K') 전체 숫자(500,000)로 변환합니다."
+ `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)
```

이 패턴을 사용하면 나중에 멤버십 기준을 더 쉽게 업데이트할 수 있습니다. 규칙을 3개가 아닌 1개만 변경하면 됩니다.

## 범주화에 열거형 사용
<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>

자동 추론 정책은 *계산 방법이* 아니라 *사실에 대해* 설명합니다. 순차적 단계 또는 우선 순위 로직이 있는 코드처럼 보이는 규칙을 작성하지 마세요.


| 좋음: 선언적 | 회피: 절차적 사고 | 
| --- | --- | 
|  “직원이 정규직이고 재직 기간이 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를** 사용합니다. camelCase 예, `tenureMonths`, `isFullTime`, `leaveType`.

모호할 수 있는 약어는 사용하지 마세요. `tenureMonths` 대신 `tenMo`를 사용하고 `isFullTime` 대신를 사용합니다`ft`. 명확한 이름은 인적 검토자와 번역 프로세스 모두에 도움이 됩니다.

## 일반적인 안티 패턴
<a name="bp-anti-patterns"></a>

다음 패턴은 자동 추론 정책에서 문제를 자주 일으킵니다. 예기치 않은 테스트 결과가 발생하는 경우 정책에 이러한 안티 패턴이 포함되어 있는지 확인합니다.

### 영향 대신 Axiom
<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>

열거형에 사용자가 언급할 수 있는 가능한 모든 범주에 대한 값이 포함되지 않은 경우 입력이 정의된 값과 일치하지 않으면 번역이 실패하거나 예기치 않은 결과가 발생할 수 있습니다.

**증상:** 테스트는 입력이 열거형에 없는 범주를 언급할 `NO_TRANSLATIONS` 때 `TRANSLATION_AMBIGUOUS` 또는를 반환합니다.

**수정:** 열거형에 `OTHER` 또는 `NONE` 값을 추가하여 정의된 범주와 일치하지 않는 입력을 처리합니다. 열거형 값 설명을 업데이트하여 각 값이 적용되는 시기를 명확히 합니다.