Control 版 (精华区)

发信人: dagam (断情), 信区: Control
标  题: [转载]专家系统解释[1] 
发信站: 哈工大紫丁香 (2001年07月01日11:49:34 星期天), 站内信件


解释
专家系统的一个重要的功能就是要能够解释它自己的行为。这意味着用户可以在任何时

候询问系统为什么得出某个结论，或者为什么提出某个问题。
这对于用户来说是一项重要的功能，有时候用户只要求知道答案，可是有时候用户需要

知道解释，而通常的专家系统无法对它的行为做出有说服力的解释，而只能够告诉用户

它使用了哪些规则得出的结论，至于为什么这些规则能够得出这样的结论，系统是无法

解释的。例如下面这个例子：
汽车能够启动么？ 不行
引擎发动了么？ 是的
你问到汽油味道了么？是的
建议：等待5秒钟，然后再试。
为什么？
因为我使用了这样的规则：
如果不能够启动而且引擎发动了而且问到汽油味，那么就推荐的等待5秒再试。
很显然这个专家系统无法解释其选择某个规则的原因，而只能告诉用户它使用了某种规
则。
如果用户硬要刨根问底的话这个系统就无能为力了。
为了让系统具有真正的解释功能，我们需要比规则更多的知识。对每个规则进行注释是
一
个比较好的方法，这种方法将在以后的章节介绍。还有一种方法就是把更多的知识进行
编
码，推理引擎和解释引擎都同时使用这个知识库。
还有些专家系统的知识库是属于经验知识，在这种情况下系统的解释可以直接使用规则
。
像识别鸟类的分类系统就属于这种情况。鸟类识别系统就能够使用它的规则直接进行解
释，例如为什么某种鸟是野鸭，就是因为它具有野鸭的一些特性，而这些特性就是规则
所定义的。识别鸟类并不存在什么高深的理论，而只是根据某些特点进行分类的。
也许对于用户来说某些解释是多余的，不过对于开发人员来说这是十分重要的。这和通
常的语言中的跟踪调试有些类似。
当系统没有按照预期的效果执行的时候，开发人员可以根据解释研究错误的产生原因。
知识工程师也可以根据解释从而设计出更加贴近用户的知识库。
解释的种类
在一般的专家系统中常用的有4种解释。
报告当前的会话进程。
解释系统是如何得出某个结论的。
解释为怎么系统向用户询问某个问题。
解释为什么某个结论不成立。
在我们上一章介绍的Clam外壳程序中，推理引擎是自己编写的，所以这些解释特性并不
难
加入系统当中。在第一章的原始外壳中没有推理引擎，而是使用prolog的内部引擎，这
样
就无法加入新的解释特性，为了达到这个目的，我们需要编写自己的推理引擎，而这个
引
擎的运作方式和prolog相同，也就是说需要使用prolog编写一个prolog，好在这项工作
并
不难完成。
在Clam中使用解释
首先让我们看看在Clam中加入了解释的一个例子，这里沿用了上一章汽车诊断系统。 首
先
用户打开对话跟踪功能，跟踪的信息使用粗体字表示，跟踪信息显示了系统是如何调用
规
则的。注意系统正确的表示出了规则的嵌套调用。
报告当前的会话进程的解释：
consult, restart, load, list, trace, how, exit
:trace on
consult, restart, load, list, trace, how, exit
:consult
call rule 1
Does the engine turn over?
: no
call rule 2
Are the lights weak?
: yes
exit rule 2
call rule 3
Is the radio weak?
: yes
exit rule 3
exit rule 1
call rule 4
fail rule 4
call rule 5
fail rule 5
call rule 6
fail rule 6
problem-battery-cf-75
done with problem
下面来看看如何解释为什么要向系统提问。用户可以在任何时候向推理引擎询问why，请
看这个例子：
...
Is the radio weak?                     从不喜欢光光一个,可惜偏偏光光一个
: why
rule 3
If
radio_weak
Then
battery_bad 50
rule 1
If
not turn_over
battery_bad
Then
problem is battery 100
goal problem
...
这里可以看出来当用户向系统询问为什么问is the radio weak这个问题的时候，系统把
有关这个问题的几个规则列出来了。

--

--
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: heart.hit.edu.cn]