本章探讨了可能用来提高基于规则的专家系统解释能力的一些技术。我们考虑许多方法，通过创建更交互的图形用户界面不仅提高了系统透明性，而且提供更多系统灵活性。特别地，我们来看一下能担任用户界面主要成分的许多图：

•允许用户视觉跟踪知识库的推理过程，并带着用户一步一步看到推理过程的流程图（见图6-2和图6-3）。

•一个复杂知识库被分成有意义的以一种分层的方式组织起来的部分的图（见图6-4和图6-5）。

•图示了在一个规则轨迹中条件和行为间的内部关系的规则轨迹图（见图6-8）。

•用于解决问题的模型策略知识和方法图，以便用户具有专家系统如何得到结论的高级理解（见图6-13～图6-16）。

表6-2提供就透明性和灵活性而言的两种接口类型的不同。一方面传统的基于文本的用户界面缺乏解释能力，因为其没有理解系统如何和为什么得到相关建议的方法。并且，对话是一种严格的问题-答案会话，在该会话里输入以预定义的顺序输入，不必从头再来，因为不存在后退和检测假定的方法。在另一方面，图表的界面提供了一种高度的解释能力，因为它提供给用户一种系统如何得到结论的图形化模型。这个界面使用户能看到系统是如何工作的，因此提供系统内部机制的更深层理解。当鼓励用户探讨和对不同脚本和假定进行彻底检验时，系统是高度灵活的。

表6-2 传统界面和图形界面的一个并行比较(www.daowen.com)

尽管本章描述的图形化的表示是改善专家系统用户界面一种强有力的方法，但也存在弱点和运输模式专家系统的限制，我们应该注意。首先，传输模式是一种toy系统，只是阐述了一个很简单的问题。尽管它是基于从运输系统得到的真实的主要原理产生的，但它是一个虚拟系统，其目的是演示本章中描述的解释能力的原理。因此，要问的很自然的问题就是这些图形化的用户界面是否能扩大到更复杂的领域。例如，一个必须为更大更复杂应用创建系统的设计者必须考虑在一个单一屏幕上安装一个大的系统。一种选择就是创建为一个屏幕分层，并且有用户滚动条（上/下或左/右）以到达分层的相关部分。另一种选择是让用户放大/缩小（放大以得到更大的图形，缩小以聚焦在图的相关部分）。但是，滚动和缩放在提供易于使用的界面方面都有局限。你可以很容易地想象，从一个分层的页面上从头到尾滚动一次才能到达相关信息是多么令人沮丧。

另一种方法是将一个大的图形分成分离的屏幕信息。例如，你只能将一个大分层的顶部放在一个屏幕上，并且需要用户点击这些节点以获得更细节的内容。这种解决方案将考虑分层模型的深入描述和考虑细节间隔尺寸和多层的用户界面。当需要为更复杂应用创建图形时，这是我们极力提倡的方法。事实上，图6-14～图6-16给出的流程图的确表示了一个已经被分成三个独立部分的较大的单一流程图。离页引用的使用可以说明流程图如何继续到另一个流程图。

第二个问题就是不是所有解决问题情况都能用简单的分层或流程图描述。运输模式问题是一个表示起来相对简单的问题（的确是一个人工组成以便它能控制成一个树结构），因为它能被分解成子部分，子部分又被分解成子子部分，以便一个解决问题情况的多级结构被构建。但是，很多解决问题领域不适合简洁的分层描述。我们不能建议所有的知识库能以分层来表示。但是，很多复杂的知识库能够也应该分成有意义的部分。除了分层和树结构外，其他的图形化的表达，不管它们是语义网络、因果图、决策流程图或者其他别的知识结构，可能更合适将这些部分连接在一起。

第三个议题是用户与图形界面交互的自由形式（如和运输模式分层）意味着一个用户可以以任意顺序输入数据，或者选择在一些情况下根本不输入数据。这个能提高系统灵活性的同时，这个特点也是一把双刃剑可能导致一个损失，即在与图形交互时用户可能迷失或者可能不知道什么是需要输入的数据。相反，一个很结构化的问题-答案对象能控制输入数据的需求——会告诉用户应该输入什么和何时输入，这样消除了所需数据之外的臆测。但是有可以解决这个问题的图形选择。一个流程图可以用来说明一步一步需要输入什么数据并且何时输入，直到专家系统得到它的建议。图6-3是一个图形界面的简单例子，它给出了所采用的推理线路和需要输入的数据（同时图6-14～图6-16中表示运输模式策略知识的流程图）。

最后，基于规则的专家系统经常是它解决问题的方法不必是最精确的，它们也不需要以相同顺序的步骤发生。相反，一个常规的问题，如由一个常规编程语言C++或Java开发的问题，可以以一个很结构化的步骤进行。流程图和其他图形技术的使用表明一个专家系统正以一个更结构化的和安排好的逐步的方式——以一种算法的方式进行，因此会推动一些动态的和机会的特征。我们同意这一点。但是，没有结构和秩序，一个知识库就很容易变得难控制且很难管理和维护。如果没有一种顺序结构在里面，即使只包含52个规则的运输模式知识库也会很难修改和维持。我们提倡在所有情况下使用流程图去建立策略知识的模型，一些情况下结构的缺乏可以考虑专家决策制定的更紧急和动态的形式。但是，在大多数情况下，需要某种结构。应该进行知识库的某种分割和模块化去管理它的复杂性。否则，专家系统的用户将会很容易迷失，开发者在更新和维持一个无序知识库时也会很困难。