第 6 章:专家系统:把专家装进机器
本章问题:专家知识能不能被封装成系统?
6.1 那个用 500 条规则媲美医生的程序
1976 年,斯坦福大学,一个叫爱德华·肖特利夫的博士生提交了他的学位论文。
论文的题目是《MYCIN:一个基于规则的计算机咨询系统》。MYCIN 做的事情听起来很不可思议:它诊断细菌感染,并推荐抗生素治疗方案。
这不是一个"小世界"的玩具程序。它的领域是真正的医学问题——血液感染、脑膜炎——处理不当的后果是严重的。肖特利夫不是医生,他是一个计算机科学家。MYCIN 的知识来自和斯坦福医生的长期访谈。他花了几年时间,把感染病专家的专业知识,一条一条地转换成了大约 500 条"如果……那么……"规则。
1979 年,一项发表在《美国医学会杂志》上的研究比较了 MYCIN 的治疗建议和真人医生的方案。由 8 位独立专家进行盲审评审。结果——MYCIN 的建议在 65% 的病例中被评为"可接受"或更优,和真人医生的方案质量相当。
这是人工智能史上一个标志性的时刻。在此之前,人工智能主要在棋盘和积木世界里展示能力。而 MYCIN 把它带进了真实世界——一个涉及人命、专业判断和大量不确定性的领域。
它第一次证明了一件事:专家知识确实可以被封装成程序。
6.2 什么叫"把专家装进机器"?
专家系统的基本逻辑很直接:
- 找一个领域——比如疾病诊断、设备配置、法律咨询、矿藏勘探;
- 找到一个或多个人类专家;
- 和他们反复对话,把他们的判断逻辑拆解成规则;
- 把这些规则写进一个程序;
- 这个程序就成了一个"电子专家"——输入相关的事实,它就按规则推理,给出结论。
乍看之下,这没有什么神奇的地方。无非是把人脑中储存的决策经验变成了计算机里的"如果……那么……"语句。
但这件事的意义在于:知识第一次被当作一种可以独立于人的存储物。
专家的知识在专家的脑子里时,是稀缺的——一个好的感染病专家需要十年以上的训练和经验。但一旦这个知识被转换成了规则文件,它就可以被复制一千份、一万份,可以放到任何有计算机的地方运行,不会退休、不会生病、不会因为心情不好而误诊。
这就是专家系统的商业诱惑力:把稀缺的"知道如何做"变成可复制的软件产品。
6.3 知识工程师登场
在专家系统的范式里,诞生了一个全新的职业:知识工程师。
知识工程师既不是纯粹的程序员,也不是领域专家。他们是一种"翻译"。他们坐在医生、工程师、地质学家、律师旁边,听专家描述他们如何做判断,然后把这种描述形式化成机器可执行的规则。
这个过程听起来像是采访,但实际上非常困难。
专家往往"知道怎么做",但说不清自己是怎么做的。一位资深医生看到化验单,几乎本能地知道病人可能是什么感染——但如果问他"你是怎么判断的",他可能会说"我觉得"或者"经验"。
知识工程师的工作就是把这个"我觉得"拆开——你看了哪些数据?哪些值让你起了疑心?你排除了什么可能性?哪些因素对你最重要?你在哪一步改变了想法?
这需要极大的耐心和很好的沟通能力。好知识工程师往往必须同时学习两个领域——计算机科学和医学、或计算机科学和工程、或计算机科学和法律。他们就像两个部落之间的使者。
知识工程师的出现,也让一类新的问题进入了人工智能研究的视野:知识本身是有结构的,表达知识的方式会决定系统的能力。同样的医学知识,用不同的规则结构来组织,可能导致完全不同的诊断效果。写规则不只是"写清楚",而是"写对结构"。
6.4 XCON:专家系统的第一桶金
如果说 MYCIN 是实验室里的成功,那 XCON 就是市场的证明。
1978 年,数字设备公司(DEC)遇到了一个大问题。DEC 生产 VAX 系列小型计算机——这些是当时最成功的企业级计算机之一。每台 VAX 的配置都不一样:不同的 CPU、内存、硬盘、控制器、机箱、电源、电缆。客户下单时,需要有人确定这些部件是否彼此兼容,确保完整、正确、不会装不上。
这个"配置"工作以前是由经验丰富的技术人员完成的。但随着 VAX 产品线越来越复杂——数百种组件,每种都有兼容性约束——人工配置开始频繁出错。配错了导致延迟交货、客户投诉、退货重装的成本高昂。
DEC 找到了卡内基·梅隆大学的约翰·麦克德莫特团队。团队用专家系统的思路,把 DEC 熟练配置工程师的知识转换成了规则。1980 年,系统 XCON(最初叫 R1)开始在 DEC 位于新罕布什尔的工厂里运行。
到 1980 年代中期,XCON 处理了超过 80,000 份订单,准确率达到 95%-98%。DEC 称它每年为公司节省数千万美元。
这是人工智能第一个真正的商业成功案例。它告诉世界:AI 不只是学术好奇心——它能省下真金白银。
6.5 黄金时代:每个人都想要一个专家系统
XCON 的成功开启了一个热潮——后来被称为"专家系统黄金时代"。
在 1980 年代早期到中期,几乎每一家大公司都在问同一个问题:"我们需要一个专家系统吗?"银行想要信贷审批专家系统,保险公司想要理赔评估专家系统,矿业公司想要矿藏勘探专家系统,法律事务所想要合同分析专家系统。
一个新的产业形成了:AI 创业公司开发专家系统"壳"——一种通用推理引擎,你只需要往里填规则,就能得到一个特定领域的专家系统,不用从零写代码。风险投资涌入。会议爆满。媒体再次开始报道"会思考的机器"。
这个场景和 1958 年感知机引发的那波狂热有类似之处——只是这次的焦点不是"机器学习",而是"知识工程"。媒体的叙事从"机器在学"变成了"人在教",而"人在教"看起来更可控、更有商业确定性。
日本的"第五代计算机"计划把这种狂热推向了巅峰。1982 年,日本通产省宣布投资约 3.2 亿美元,研发"能像人类一样推理"的下一代计算机,核心技术就是专家系统和逻辑编程。这个计划让美国和欧洲政府极度紧张,纷纷推出自己的 AI 对等投资计划。
一时间,做 AI 的预算似乎是花不完的。
6.6 裂缝出现
但狂热之下,裂缝已经开始扩大。
第一个问题:规则不像想象中那么容易写。XCON 在运行中不断被添加新规则来处理特殊情况,最终膨胀到了近万条。新规则不断被添加来处理特殊情况,但老规则从来不被删除——因为没人敢确定删除某条规则会不会引发连锁反应。调试几千条互相作用的规则,比调试任何传统程序都要难。
第二个问题:维护变成了噩梦。计算机产品在不断更新,每出一个新的组件,就需要更新规则。这些更新不是自动的——需要知识工程师重新和专家沟通,重新形式化,重新测试。XCON 的规则维护团队后来成了 DEC 内部的难题。
第三个问题,也是最根本的问题:**专家系统的知识是脆弱的。**一旦输入超出了规则的覆盖范围,系统就会崩溃——不是优雅地承认"我不确定",而是给出一个看起来很确定但完全错误的答案。它不像人类专家那样有"常识"来兜底。
想象一下:一个贷款审批专家系统可能会因为客户地址里有一个拼写错误就拒绝贷款——因为规则里没有"如果拼写有误,先尝试纠正"这一条。人类会本能地知道该怎么做。机器不会。
6.7 为什么"装进去"比想象中难
回头看,专家系统的核心难题可以归结成一个词:隐性知识。
人类专家的知识有两种。
一种是显性知识——可以写成规则、流程、检查清单。比如"如果白细胞计数超过 X 且病人有发烧,考虑感染"。这种知识很适合装进专家系统。
另一种是隐性知识——专家"知道"但说不出来的东西。比如一位经验丰富的医生走进病房,看了一眼病人,"感觉不对",立刻要求做某项特殊检查。这个"感觉不对"涉及大量的身体信号、经验记忆、模式识别和情境判断。专家自己也无法把它拆成规则。
专家系统能封装的是第一种知识。但真正让专家值钱的往往是第二种。
这就是为什么知识工程师和专家的访谈过程如此艰难。他们试图把一种本来不以规则形式存储的知识,强行转换成规则。这有点像请一位音乐家把他即兴独奏的每一个音符解释成乐理公式——也许可以,但过程漫长,结果不完全。
更麻烦的是,在很多领域,专家的知识会过时。医学知识每年都在更新。法律条文在变化。产品线在更新。如果一个专家系统的规则是静态的——写进去就不变了——那它就有一个内置的折旧率。而这个折旧率比任何人预想的都快。
6.8 本章小实验:做五分钟知识工程师
找一个你非常熟悉的日常活动——比如骑自行车、切洋葱、打包行李箱,或者判断一碗汤好不好喝。
现在,假装你是一个知识工程师,你要把你的"决策规则"写下来,让一个从来没有做过这件事的人(或机器人)能按规则执行。
规则必须明确到不含任何"自然的""很正常的""随便弄一下"这类模糊表述。每一步都必须是可以被程序执行的。
你很快会发现:
- 骑自行车的规则写起来异常困难——"保持平衡"怎么分解成规则?
- 切洋葱涉及很多"看着办"——"切成合适的大小",什么叫合适?
- 判断一碗汤好不好喝——试一口,你立刻知道,但写成规则几乎不可能。
这个一分钟的实验,暴露的就是专家系统的核心困境:我们会做很多事情,但我们说不清自己是怎么做的。
而如果连你自己都说不清,你怎么教机器?
6.9 本章地图
6.10 本章结语:规则的边界
专家系统是符号主义人工智能在商业上最成功的形态。它验证了一个假设——人类的部分专业知识是可以用计算机规则来复现的——但也暴露了这个假设的边界。
知识工程比预想的更贵、更慢、更难维护。
隐性知识无法被规则化。
规则系统在边界之外毫无防御能力。
这些局限并不说明专家系统"失败了"。XCON 数千万美元的成本节省是真实的。MYCIN 的诊断准确率也是真实的。但它们说明了一件事:只靠"装规则"的方式,走不到通用智能。
下一章,我们会看到当这条路的极限被撞上时会发生什么。AI 寒冬来了——不是因为机器不够聪明,而是因为承诺太大、商业期望太高、维护成本太高,而替代的想象还看不到地平线。
Discussion
留言区 · GitHub-powered comments via Giscus