专家系统

专家系统是符号 AI 在工程实践上最成功的应用形态。它的核心思路是将人类专家的领域知识编码为计算机可以处理的规则和事实，通过推理引擎自动完成诊断、分析、决策等任务。在 20 世纪 80 年代，专家系统曾经是 AI 商业化最成功的故事。

系统架构

典型专家系统由知识库、推理引擎和用户界面三个核心组件构成。知识库存储领域相关的规则和事实，是系统的知识基础；推理引擎负责在知识库上进行逻辑推理，得出新结论；用户界面接受用户的输入（如症状描述、问题参数），展示推理结果和推理过程。 知识库是整个系统的核心资产。一个设计良好的知识库需要做到规则之间无矛盾、覆盖领域内主要的决策场景、易于更新和扩展。知识库的构建通常需要领域专家和知识工程师紧密合作：领域专家提供专业知识，知识工程师负责将知识转化为规则和逻辑形式。这个过程被称为知识工程（Knowledge Engineering）。 推理引擎的两种策略在前文已有详细介绍。大多数专家系统支持前向链和后向链两种推理模式，用户可以根据问题特点选择合适的模式。推理引擎还需要处理规则冲突、不确定性和推理过程记录等问题。 解释机制是专家系统区别于其他决策工具的重要特征。当系统给出一个结论时，它可以展示完整的推理链：哪些规则被触发、每个中间结论是如何得出的、哪些用户输入是关键证据。这种可解释性在医疗诊断、法律推理等高风险场景中至关重要——决策者需要理解系统建议的依据，才能做出最终判断。

MYCIN：医疗诊断

MYCIN 是斯坦福大学在 1970 年代开发的细菌感染诊断系统，也是研究最深入的专家系统之一。系统包含约 600 条产生式规则，能够根据患者的症状、实验室检测结果和病史，识别导致感染的细菌种类并推荐抗生素方案。 MYCIN 的推理过程使用后向链策略。系统从可能的诊断结论出发，反向查找需要的证据，通过交互式问答向医生询问患者的具体情况。每个诊断结论关联一个确定性因子（CF 值），多条规则对同一诊断的贡献通过 CF 组合函数合并，最终给出按置信度排序的诊断列表。 MYCIN 的评估结果表明，其诊断准确率约为 65%，与当时斯坦福医学院的传染病专家水平相当。但 MYCIN 从未在临床实际使用，原因是多方面的：法律责任问题（谁为错误诊断负责？）、医生对计算机建议的不信任、系统维护的困难（新的抗生素和耐药性数据需要持续更新）。这些非技术因素导致的失败，对今天的 AI 工程实践仍然有警示意义。 MYCIN 对 AI 领域的贡献远超其实际应用。它验证了基于规则的推理在复杂领域中的可行性，开创了可解释 AI 的先河，催生了 EMYCIN（Empty MYCIN）这个通用专家系统框架——将 MYCIN 的医疗知识库替换为其他领域的知识库，就能快速构建新的专家系统。

DENDRAL：科学发现

DENDRAL 是更早期的系统，开发于 1960 年代斯坦福大学，任务是分析有机化合物的分子结构。给定质谱仪数据，系统通过符号推理和约束满足推断出可能的分子结构。DENDRAL 是 AI 在科学领域的首次成功应用，它的一些分析结果甚至被化学家收录到了化学文献中。 DENDRAL 的关键技术是"计划-生成-测试"架构。计划阶段根据输入数据确定搜索空间的大致范围，生成阶段枚举该范围内所有可能满足约束的分子结构，测试阶段用已知的化学规则逐一验证每个候选结构。这种分阶段处理复杂问题的方法后来被广泛借鉴。 DENDRAL 项目还发展出了一个重要的副产品——Meta-DENDRAL，一个能够自动从化学数据中学习新规则的程序。Meta-DENDRAL 可以看作早期机器学习系统的代表，它从已知分子的质谱数据中归纳出"碎片规则"，用于指导后续新分子的结构分析。这种"自动发现知识"的能力是后来数据驱动方法的前身。

XCON：商业成功

XCON（eXpert CONfigurer，又称 R1）是卡内基梅隆大学为 DEC 公司开发的计算机配置系统。DEC 的 VAX 计算机系统有数千种可选组件，每个客户订单需要根据需求和技术约束进行正确的配置组合。XCON 用产生式规则编码了配置专家的知识，自动生成满足需求的组件清单和连接方案。 XCON 在商业上取得了巨大成功。系统包含数千条规则，处理了 DEC 每年数万份订单中的大部分，准确率超过 95%，每年为公司节省数千万美元。XCON 证明了 AI 技术可以在工业界产生实际的商业价值，直接推动了 1980 年代专家系统产业的繁荣。 XCON 也揭示了专家系统的维护挑战。规则库从最初的几百条增长到上万条，规则之间的交互变得越来越复杂。一个看似无害的规则修改可能引发意想不到的配置错误。知识工程师团队需要持续维护和测试规则库，维护成本随着系统规模增长而加速上升。

知识工程

知识获取是构建专家系统的最大瓶颈。领域专家的很多知识是隐性的——他们凭经验做出判断，但很难清晰表达推理过程。知识工程师需要通过深度访谈、案例分析和观察，逐步将专家的隐性知识转化为显式规则。这个过程耗时且昂贵，一个中等规模的专家系统可能需要数人年的知识工程工作。 知识工程师的角色类似于现代数据工程师与产品经理的结合。他们既需要理解领域知识，又需要掌握知识表示和推理的技术，充当领域专家和计算机系统之间的桥梁。这个角色在现代 AI 开发中演变成了数据标注、提示词工程和领域适配等岗位。 快速原型法是知识工程的最佳实践。先构建一个覆盖核心场景的原型系统，让领域专家试用并提供反馈，根据反馈迭代扩展知识库。这种增量式开发方式比试图一次构建完整系统的瀑布方法要有效得多。现代的机器学习项目也遵循类似的迭代模式：先训练基线模型，评估效果，再逐步改进。

兴衰与启示

1980 年代中期是专家系统的黄金时代。大量企业投资构建专家系统，AI 研究获得了充足的经费支持。但到 1980 年代末，专家系统的局限性变得明显：知识获取瓶颈无法突破，维护成本持续上升，系统的脆弱性在复杂应用场景中暴露无遗。1990 年代初，专家系统产业大幅萎缩，AI 研究进入第二个寒冬。 专家系统的兴衰给 AI 工程留下了深刻的教训。技术本身并非失败——MYCIN、XCON 等系统的能力是真实的。失败在于过高估计了符号方法可以解决问题的范围，忽视了知识获取、系统维护和实际部署中的工程挑战。这些问题在今天的 AI 工程中以不同的形式重新出现：大模型同样面临领域适配困难、输出不可控、维护成本高等挑战。 专家系统的技术遗产至今仍在发挥作用。业务规则引擎（如 Drools、IBM ODM）是产生式系统的直接后裔，在金融、保险、电商等领域广泛用于业务逻辑管理。规则引擎与机器学习模型的组合成为现代智能系统的常见架构——模型负责概率性判断，规则引擎负责确定性约束和合规检查。