Day12-02｜3.5.2 专家系统的特点：知识密集型系统如何建立可信推理

本文对应《系统架构设计师教程（第2版）》第3章“信息系统基础知识”3.5.2“专家系统的特点”。本节要掌握的不是零散形容词，而是这些特点对系统架构、数据治理、知识维护、交互设计和安全审计提出的具体要求。

一、学习目标

完成本节后，应能够：

1. 说明专家系统与普通业务系统、MIS、DSS的主要差异；
2. 解释知识密集、领域专用、推理驱动和人机协同等特点；
3. 分析专家系统为什么需要解释、处理不确定性并保留人工复核；
4. 结合案例说明知识获取困难、规则冲突和知识更新滞后的架构风险；
5. 在论文中把“专家经验沉淀”写成可维护、可验证、可追溯的工程方案。

二、专家系统的主要特点总览

三、知识密集性：系统的核心资产是知识

普通业务系统的主要价值可能体现在流程自动化和数据处理，而专家系统的核心竞争力是知识。知识包括领域概念、对象关系、诊断模式、处理规则、专家经验、案例和约束条件。若知识库为空，即使系统具有先进的推理引擎，也不能解决实际问题。

知识密集性带来三个工程要求。第一，要有知识表示方式。简单规则可以使用条件—结论表示，复杂对象可以使用概念层次、属性、关系或图结构表示，历史经验可以使用案例表示。第二，要有知识获取机制。知识工程师需要从专家访谈、历史工单、制度文件和数据中提取知识。第三，要有知识质量控制。每条知识都要有来源、责任人、适用范围、生效时间和验证样例。

知识与数据也存在区别。数据记录“某设备温度为90度”，知识可能表示“高温与振动同时出现时，轴承故障概率明显增加”。数据是事实，知识是对事实的概念化、关系化和规则化表达。专家系统需要把二者连接起来，避免规则脱离实际数据。

四、领域专用性：能力深而不一定广

专家系统通常针对一个特定领域，例如医疗诊断、设备维护、金融审核、地质勘探、法律咨询和网络故障定位。领域专用性使系统可以使用专业术语、领域模型和高质量规则，在限定范围内达到较强能力；但也意味着系统不能轻易推广到没有验证过的领域。

架构设计时要明确系统边界。应说明支持哪些对象、问题类型、数据来源、业务流程和风险等级；还要说明哪些情况超出知识库，需要转人工或调用其他系统。边界提示是专家系统可信性的组成部分。系统不能因为匹配到一条相似规则，就对完全不同的问题给出确定结论。

领域专用性还要求领域模型稳定。设备诊断系统需要理解设备、部件、指标、故障和处置动作之间的关系；授信系统需要理解客户、账户、还款、担保和风险事件；医疗系统需要理解症状、疾病、检查和治疗。领域模型是规则、数据和界面之间的共同语义。

五、推理驱动：从事实到结论的过程可计算

专家系统不是把专家意见直接打印出来，而是根据事实和知识进行推理。推理过程包括事实匹配、规则选择、推理方向、冲突消解和结果排序。正向推理适合从监控事实触发告警和诊断，反向推理适合从候选结论寻找证据，混合推理则结合两者。

推理驱动对架构的影响是：规则不能散落在页面代码中；推理服务应有明确接口；推理运行要有上下文和超时控制；推理路径要可记录；规则冲突要有确定策略；循环规则和重复触发要能检测。对长链路推理，还需要保存中间结论和证据，以便用户理解系统为何走到当前结果。

推理驱动并不代表系统一定采用复杂人工智能算法。基于规则的推理、案例推理、概率推理和模型推理都可以成为专家系统的一部分。选择何种方式，要看知识形式、数据条件、解释要求和风险等级。

六、启发式：把专家经验用于不完全问题

启发式知识是专家长期实践形成的经验规则，例如“当某类告警与某类日志同时出现时，优先检查网络链路”“在旺季前应提高安全库存”“同一供应商连续出现质量异常时需要升级审核”。这些经验不一定是严格的数学定理，却能在信息不完整时缩小搜索范围、提高问题处理效率。

启发式规则有优势，也有风险。优势是能够利用经验快速处理复杂问题，减少从头分析的成本；风险是规则可能依赖特定环境、存在主观偏差或已经过时。因此，系统应保存规则来源、适用边界和验证结果，不能把“专家说过”当作永久正确。

启发式还可以表现为优先级、搜索策略和候选方案排序。例如在故障诊断中优先检查高频、影响大且容易验证的故障；在供应商选择中先排除不合规对象，再比较成本和交付能力。架构师应说明启发式用于“缩小范围和提供建议”，最终结论仍要结合证据和人工判断。

七、不确定性：结论必须带条件和可信度

现实世界的数据可能缺失、延迟、冲突或不准确。规则也可能只有近似适用范围。专家系统如果只输出绝对结论，就会给用户造成错误安全感。因此，应对事实、规则和结论管理不确定性。

不确定性可以通过可信度、概率、模糊等级、证据强度或风险等级表示。例如“轴承故障可能性为高”“当前证据不足，建议补充振动频谱”“模型结果仅适用于近三个月数据”。系统还应区分未知、否定和未采集，不能把“没有数据”误判为“没有问题”。

不确定性处理需要配合人工复核和升级策略。当多个证据冲突、结果置信度低或风险超过阈值时，系统应转人工处理；当数据质量不达标时，应阻止自动生成确定结论；当知识库没有覆盖当前问题时，应提示系统能力边界。

八、解释性：输出结论也输出理由

解释性是专家系统最重要的特点之一。用户需要知道系统使用了哪些事实、匹配了哪些规则、排除了哪些方案以及还缺少什么信息。解释不是附加装饰，而是用户信任、错误定位、知识维护和责任审计的基础。

解释可以采用规则路径、证据列表、因果关系、相似案例和敏感因素等形式。对于诊断系统，可以展示“症状—证据—规则—故障—建议”的链路；对于风险审核，可以展示“指标变化—触发规则—风险等级—处理建议”；对于运维系统，可以展示告警关联、拓扑依赖和处置步骤。

解释必须与历史版本绑定。若一条规则在今天被修改，昨天的结论仍应能够按照昨天的事实、参数和规则版本解释。对于人工覆盖结果，也要记录原始建议、覆盖后的结论、操作人员和理由。

九、交互性：通过问答逐步完善问题

很多专家问题无法一次性获得全部信息。专家系统需要通过对话或交互逐步补充事实。提问顺序应优先选择区分度高、成本低、用户容易回答的问题，避免让用户填写大量无关字段。

交互系统需要维护会话状态，包括已确认事实、待确认问题、候选结论、推理路径和用户修正。用户回答“未知”时，系统应正确处理；用户修改之前的事实时，应重新计算受影响的结论；用户中断会话后，需要支持恢复或审计。

交互性还要和安全结合。不同角色能看到的问题、数据和建议可能不同；敏感字段应脱敏；人工补充的证据必须记录来源；系统不能通过连续提问诱导用户输入不必要的隐私信息。

十、知识维护：专家系统不是一次性交付

知识会随着政策、产品、设备和业务环境变化。知识维护包括新增、修改、废止、合并、冲突检测、回放测试和效果评估。没有维护流程的专家系统，初期可能有效，运行一段时间后就会产生误诊、漏诊和错误建议。

一个基本的知识发布流程是：知识工程师提交变更；领域专家审核；用历史案例和测试样例回放；在测试或灰度环境验证；审批后发布；监控线上效果；必要时回滚。规则库应支持版本化，模型和规则的变化应能够区分，知识变更还要关联制度或业务来源。

十一、人机协同与责任边界

专家系统的“专家”是系统提供的知识能力，不能直接等同于现实中的责任主体。高风险场景应明确系统建议、人工复核、最终批准和执行动作的边界。系统可以自动分流低风险问题，把复杂和高风险问题升级给专家；可以自动推荐处置步骤，但危险操作要人工确认。

人机协同需要设计覆盖机制。用户覆盖建议时，系统保存原建议和新结论；用户拒绝补充证据时，系统标记结论可信度；专家新增规则时，系统要求说明来源；执行结果异常时，系统触发复盘。这样才能把人的经验吸收到知识库，同时保留审计轨迹。

十二、案例分析：医院用药审核专家系统

某医院计划建设用药审核专家系统，系统根据患者基本信息、过敏史、诊断、检验结果和处方内容提示用药风险。项目负责人提出：“只要规则库覆盖常见禁忌，就可以完全自动拦截处方。”请分析该方案的问题并提出改进。

参考答案：第一，医疗知识具有领域性和时效性，规则必须关联指南版本、生效时间和审核专家；第二，患者数据可能缺失或延迟，系统要区分未知与否定，并对证据不足提示人工核验；第三，同一处方可能触发多条规则，应按严重程度、证据强度和适用条件冲突消解；第四，系统应输出触发规则、患者证据和建议，而不是只有“禁用”结论；第五，低风险提示可以自动展示，高风险处方应由药师复核，紧急情况需要明确人工覆盖流程；第六，处方审核结果、人工意见和实际用药反应应形成反馈，用于知识更新；第七，患者隐私要实施最小权限、脱敏、加密和访问审计。

该答案体现了专家系统的特点：知识密集、领域专用、推理驱动、存在不确定性、强调解释并依赖人机协同。

十三、综合知识练习

选择题1

下列哪项最能体现专家系统的知识密集性（ ）。

A. 保存大量用户头像 B. 通过领域规则和案例进行故障诊断 C. 提高网络带宽 D. 增加打印机数量

答案：B。解析：领域规则和案例是专家知识的具体表达，直接决定系统的专业能力。

选择题2

当系统证据不足、规则冲突且风险较高时，最合理的处理是（ ）。

A. 强制输出确定结论 B. 删除冲突规则 C. 提示不确定性并转人工复核 D. 随机选择一条规则

答案：C。解析：高风险和证据不足场景必须保留不确定性提示与人工升级机制。

简答题

请说明专家系统为什么需要知识版本管理。

参考答案：领域知识、制度和规则会变化，版本管理能够明确每条知识的来源、责任人、生效和失效时间；能够在发布前进行测试和审批；能够复现历史结论、分析规则变化影响；出现问题时可以回滚到稳定版本；还便于审计、责任追踪和知识持续维护。

十四、论文素材与今日复盘

论文中可以写：“考虑到专家知识具有领域性、启发性和时效性，我没有把规则固化在业务代码中，而是建立独立的知识管理和推理服务。每条规则均登记来源、适用范围、生效时间、责任人和验证样例，经过专家审核、历史回放和灰度验证后发布。系统对证据不足、规则冲突和高风险结果提供不确定性提示和人工升级，并通过解释链、版本快照和审计日志保证结论可追溯。”

今日复盘：专家系统的特点最终都要落到架构机制；知识密集意味着知识治理比页面开发更重要；不确定性、解释性和人机协同决定了系统能否在真实场景中可信运行。下一篇进入 3.5.3 专家系统的组成。