本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

自动推理策略最佳实践

本页汇总了创建和维护自动推理策略的最佳实践。在创建您的第一个策略之前，请先阅读此内容，并在调试问题时参考该策略。有关这些做法背后的概念基础，请参阅自动推理检查概念。有关 step-by-step创建说明，请参阅创建自动推理策略。

从简单开始，然后进行迭代

创建自动推理策略时最常见的错误是尝试一次性捕获整个复杂文档。取而代之的是，从规则的重点子集开始，然后逐步构建。

这种方法有两个优点：它使问题更易于隔离（你知道哪个部分引入了问题），并且它可以在开发过程中使策略保持可管理性。包含 10 条经过充分测试的规则的策略比包含 100 条未经测试的规则的策略更有用。

使用法学硕士学位预处理文档

对于篇幅较长、包含叙事散文或将规则与非规则内容混为一谈的文档（例如法律免责声明或组织背景），请在将文档上传到自动推理检查之前通过法学硕士学位。要求法学硕士按照明确的 if-then 规则提取内容。此预处理步骤显著提高了提取策略的质量，因为自动推理检查最适合处理清晰的声明性语句而不是非结构化文本。

在编写预处理提示时，请包括以下有关 LLM 的说明：

有关详细的提示模板和 step-by-step预处理工作流程，请参阅（可选）使用 LLM 将文档重写为逻辑规则。

使用含义 (=>) 来构造规则

if-then 格式（使用=>隐含运算符）是最重要的规则编写模式。每条表达条件关系的规则都应使用这种格式。

裸露的断言（没有 if-then 结构的规则）会产生公理——这些陈述始终是正确的。该断言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结果的首要原因。

一个好的变量描述应该可以回答四个问题：

示例：之前和之后

对非排他性状态使用布尔值

对可以共存的状态进行建模时，请使用单独的布尔变量而不是单个枚举。一个人既可以是资深人士，也可以是老师。使用枚举会customerType = {VETERAN, TEACHER}强制在它们之间做出选择，当两者都适用时，就会产生逻辑上的矛盾。

为真正相互排斥的类别保留枚举，其中一次只能应用一个值，例如leaveType = {PARENTAL, MEDICAL, BEREAVEMENT}（员工一次只能申请一种休假）。有关自定义类型的更多信息，请参阅自定义类型（枚举）。

在变量描述中指定单位和格式

单位含糊不清是翻译错误的常见来源。如果用户说 “我在这里工作了 2 年”，而你的变量是tenureMonths，那么翻译需要知道将年转换为月。如果您的变量描述未指定单位，则翻译可能会tenureMonths = 2改为赋值tenureMonths = 24。

请务必指定：

示例：

验证数值的范围

对于数值变量，添加限制有效范围的边界规则。这可以防止逻辑上不可能出现的情况，并有助于自动推理检查产生更有意义的结果。

;; 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 格式的规则）适用的情况之一。

使用中间变量进行抽象

当多个规则共享一个共同条件时，将该条件提取到中间布尔变量中。这简化了您的规则，使策略更易于维护。

示例：会员等级

与其在每条福利规则中重复会员资格条件，不如说：

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

这种模式使以后更新成员资格标准变得更加容易，您只需要更改一条规则，而不是三条规则。

使用枚举进行分类

当变量表示具有一组固定的互斥值的类别时，请使用自定义类型（枚举），而不是多个布尔值或字符串。枚举限制了可能的值并使规则更清晰。

保持逻辑是声明性的，而不是程序性的

自动推理策略描述的是真实情况，而不是如何计算。避免编写看起来像带有顺序步骤或优先级逻辑的代码的规则。

同样，避免在规则之间编码优先级或优先级。在形式逻辑中，所有规则同时适用。如果您需要表示一个条件优先于另一个条件，请在规则条件中对其进行显式编码：

;; 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。清晰的名字对人工审稿人和翻译过程都有帮助。

常见的反模式

以下模式经常导致自动推理策略出现问题。如果您遇到意想不到的测试结果，请检查您的策略是否包含任何这些反模式。

用公理代替暗示

如中所述使用含义 (=>) 来构造规则，裸露的断言会产生始终正确的公理。这是最常见的反模式，也是最具破坏性的——它会使所有类别的输入都返回IMPOSSIBLE。

症状：应返回VALID或INVALID返回的IMPOSSIBLE测试。

修复：在规则中找到裸露的断言并将其重写为含义，或者如果它们不代表边界条件，则将其删除。

重叠变量

如果有两个变量代表相同或相似的概念（例如tenureMonths和monthsOfService），则会混淆翻译过程。自动推理检查无法确定给定概念使用哪个变量，从而导致翻译和TRANSLATION_AMBIGUOUS结果不一致。

症状：TRANSLATION_AMBIGUOUS即使输入文本清晰明了，测试也会返回。

修复：将重叠的变量合并为具有全面描述的单个变量。更新所有引用已删除变量的规则。

策略过于复杂

具有太多变量、深度嵌套条件或非线性算术的策略可能会超过处理限制并返回TOO_COMPLEX结果。

症状：测试返回TOO_COMPLEX或超时。

修复：简化政策。移除未使用的变量，使用中间变量将复杂的规则分解为更简单的规则，并避免使用非线性算术（指数、无理数）。如果您的域名确实很复杂，可以考虑将其拆分为多个重点政策。

相互矛盾的规则

相互矛盾的规则使自动推理检查无法得出结论。例如，一条规定全职员工有资格休假，而另一条规定第一年的员工没有资格休假，但没有具体说明全职员工在第一年的情况。

症状：IMPOSSIBLE对于涉及冲突规则的输入，则返回测试结果。

修复：检查质量报告是否存在冲突规则。通过将规则合并为具有明确条件的单个规则，或者删除其中一个冲突规则，来解决冲突。有关更多信息，请参阅 查看提取的政策。

未使用的变量

未被任何规则引用的变量会给翻译过程带来干扰。当未使用的变量与类似的活动变量竞争时，转换可能会给未使用的变量赋值，从而浪费处理能力，并可能导致TRANSLATION_AMBIGUOUS结果。

症状：意外TRANSLATION_AMBIGUOUS结果，或者为不影响任何规则的变量赋值的转换。

修复：删除未使用的变量。在控制台中，查找变量旁边的警告指示器。通过 API，查看来自GetAutomatedReasoningPolicyBuildWorkflowResultAssets的质量报告--asset-type QUALITY_REPORT。

缺少枚举值

如果你的枚举没有包含用户可能提及的每个可能类别的值，那么当输入与任何定义的值都不匹配时，翻译可能会失败或产生意想不到的结果。

症状：测试返回，TRANSLATION_AMBIGUOUS或者NO_TRANSLATIONS当输入提及不在枚举中的类别时。

修复：在枚举中添加OTHER或NONE值以处理与定义的类别不匹配的输入。更新枚举值描述以明确每个值何时适用。