基于知识的专家系统：原理、推理与开发工具解析

# 基于知识的专家系统：原理、推理与开发工具解析 ## 1. 框架与恶魔机制 在知识表示中，框架是一种重要的结构。例如有框架A和框架B，在恶魔激活前后，它们的状态会发生变化。知识工程师会将恶魔附加到框架的槽上，当槽赋值事件发生时，恶魔会自动激活，这模拟了基于常识的推理。 ### 1.1 恶魔类型及作用 - **IF_NEEDED恶魔**：以框架B的son_of槽为例，若对该槽进行引用，IF_NEEDED恶魔会被调用，只有在引用槽时才会推断并添加值到槽中。 - **IF_DELETED恶魔**：当从框架中删除槽时，此类恶魔会被调用。在许多工程问题中，恶魔非常有用，可根据假设的修改或计算出的值更新上下文。 ## 2. 不精确推理 人类专家处理不精确、不完整和不确定信息的能力，在专家系统中难以完全复制。随着对实际问题的关注增加，领域和问题知识往往存在不确定性，而经典推理方法处理的是明确信息，因此需要研究如何利用不确定知识进行合理推理。 ### 2.1 不确定信息的来源 - **不可靠信息**：领域概念不明确或数据不准确，导致专家无法建立规则前提和结论之间的具体关联，影响知识库质量。 - **不精确的描述语言**：自然语言的模糊性和不精确性，使规则在转换为知识库时无法精确表达。 - **不完整信息的推理**：基于不完整信息进行推理，会导致建立错误事实和做出不可接受的决策。 - **不同专家知识的不良组合**：同一领域多个专家参与可能产生分歧，达成的共识可能带来更多困惑。 ### 2.2 处理不确定性的方法 |方法|描述|缺点| | ---- | ---- | ---- | |概率理论|最著名的表示不确定性的形式主义|应用于复杂不确定知识建模存在实际困难| |确定性因素或置信水平|启发式近似概率|可能与简化的不确定性传播机制结合，或与现实存在公理上的矛盾，部分属于直观类型，数学处理困难| |模糊集理论|处理语言不精确性|/| |非单调推理和默认推理|/|/| |Dempster - Shafer信念函数的区间表示|/|/| ### 2.3 谓词逻辑推理系统的局限性 谓词逻辑推理系统精确严谨，但属于单调推理系统，在实际应用中存在局限性。实际推理需要考虑以下事实： - 决策过程中，可用信息通常不完整。 - 条件会随时间变化。 - 推理陷入僵局时，需要进行有效但可能错误的猜测。 ## 3. 非单调推理 非单调推理系统包含一组不可变的前提和一组基于默认假设的临时信念。系统会为每个信念维护依赖记录，当新的知识或事实加入时，可能使之前的临时真理变为错误，通过依赖导向的回溯机制传播信念变化的影响。 ### 3.1 非单调推理的应用与挑战 规划和设计问题常使用基于不精确或部分信息的临时假设，非单调推理系统通过依赖导向的回溯机制，能有效解决此类问题，但实现需要大量内存存储依赖信息和大量处理时间来传播信念变化。 ### 3.2 Doyle的TMS Doyle提出的TMS是一种非单调推理系统的实现，它在新知识值生成时调用推理系统，维护知识库的一致性。TMS的作用是被动的，当发现信念不一致时，会调用依赖导向的回溯来恢复一致性。 ## 4. 基于确定性因素的推理 ### 4.1 确定性因素推理的原理 Shortliffe在20世纪70年代提出了第一个不确定性管理方案，在MYCIN开发过程中得到改进。在使用确定性因素的专家系统中，知识以“IF <证据> THEN <假设> CF”的规则形式存在，CF表示基于观察到的证据对假设的信念。 在进行证据组合前，需要计算两个中间函数MB[h,e]和MD[h,e]： \[ MB[h,e] = \begin{cases} 1, & \text{if } P(h) = 1 \\ \frac{\max\{P(h|e), P(h)\} - P(h)}{\max\{1, 0\} - P(h)}, & \text{otherwise} \end{cases} \] \[ MD[h,e] = \begin{cases} 1, & \text{if } P(h) = 0 \\ \frac{\min\{P(h|e), P(h)\} - P(h)}{\min\{1, 0\} - P(h)}, & \text{otherwise} \end{cases} \] 然后通过以下公式计算CF： \[ CF = \frac{MB - MD}{1 - \min\{MB, MD\}} \] CF值范围从 -1 到 +1，-1 表示假设否定的确认，+1 表示假设的确认。当多个规则影响同一假设时，需要组合各个规则的CF值。 ### 4.2 规则示例与推理过程 以下是几个简单规则示例及推理过程： ```plaintext RULE example 1 for CF IF A AND B THEN D AND E 假设A、B和C的置信度分别为90、80和85，由于所有合取项应视为等同，如同链条中最弱的环节决定整体强度，所以输入的整体置信度由B的置信度80决定，D和E的置信度也设为80。 RULE example 2 for CF IF A OR B THEN D AND E 析取A或B的真值置信度等于析取中单个置信度最高的前件的置信度，这里整体输入置信度取90和85中的最小值85，D和E的置信度设为85。 RULE example 3 for CF IF A OR B AND C THEN D CF90 AND E CF80 当条件满足时，D的置信度为整体输入置信度85乘以规则中的CF值90，即76.5；E的置信度为85乘以80，即68。 ``` ### 4.3 规则解释与推理引擎 推理引擎对规则的解释取决于置信模式的状态。在规则触发和冲突解决方面，当不精确推理禁用和启用时，链过程会有所不同。以一个包含五条规则的简单规则库为例： ```plaintext RULE R1 IF B THEN C CF80 AND F CF90 RULE R2 IF A THEN C CF90 AND F CF80 RULE R3 IF P THEN D RULE R4 IF Q AND R THEN D RULE R5 IF C AND D THEN E ``` 假设目标是E，A、B、P、Q和R的置信度为100。 - **不精确推理禁用时**：采用反向链过程，推理机制会选择规则R2来建立C，因为冲突解决策略会按规则中结果建立事实对应的CF值降序尝试建立事实。 - **不精确推理启用时**：所有尝试建立事实的规则都会被尝试，如果规则能以更高的置信度建立事实，则会触发该规则，否则忽略。 使用置信水平存在一个问题，即置信值在多级传播时会迅速减小，目前缺乏可靠的归一化机制。 ## 5. 专家系统开发工具 开发专家系统可使用专门语言或专家系统开发工具，开发工具更为方便，能提供知识表示和推理机制，使开发者更专注于知识获取和组织。 ### 5.1 开发工具评估标准 |标准|描述| | ---- | ---- | |知识表示|应具备足够的表达能力来表示工程概念，理想情况下结合规则和对象或框架来表示程序知识和声明性知识，并能在问题解决过程中相互交互| |推理机制|拥有不同的推理机制，如反向链、正向链和混合链，还应具备在框架环境中实现不同类型推理的机制| |开发者界面|提供知识库编辑器、知识调试环境、跟踪推理过程、检查上下文和修改值等工具| |用户界面|使用户能高效与专家系统交互，包括菜单系统、交互式图形和解释功能| |编程语言考虑|工具所使用的语言对专家系统的兼容性和可移植性至关重要，还应具备访问其他程序或数据库的接口| |硬件|工具支持的计算机主要取决于其编写的语言和操作系统，以及计算机的内存、处理和图形显示能力| |成本|工具成本会影响产品价格和市场| |其他标准|如处理复杂算术的能力、可扩展性和供应商支持程度| ### 5.2 部分开发工具介绍 |工具名称|类型|优点|缺点| | ---- | ---- |