50、基于知识的系统：用户视角的全面解析

基于知识的系统：用户视角的全面解析

1. 基于知识的系统的特性

基于知识的专家系统最初旨在构建一种软件，使其在特定应用领域中能以专家水平与人类竞争解决问题。“专家系统”通常被定义为一种智能计算机程序，它运用知识和逻辑推理来解决那些需要大量人类专业知识的问题。这类软件系统不仅要将应用领域的信息形式化，还要对决策过程中的非形式化和基于经验的特质进行推理。成功的关键在于能够在计算机系统中表示和运用来自应用领域的各种知识。

一般来说，基于知识的系统具有以下特点：
- 为特定应用领域提供专家级的问题解决或决策支持。
- 系统内明确表示领域知识，并且可以根据领域知识对实现的功能进行更改。
- 存储的知识可通过多种方式推断事实和解决问题。
- 能够提供解释和依据，以阐明系统的推理过程并证明其结果的合理性。
- 开发过程和支持工具有助于更好地理解特定领域的问题解决方法和所涉及的知识本质。

基于知识的系统的典型应用包括监控、解释、诊断、设计、规划等任务。在许多情况下，待解决的问题会被重新表述为分类问题或配置问题。目前，这些系统可用于表示小型但复杂领域的专业知识，是向经验不足的用户传达专业知识的有效手段。常见的应用示例包括技术设备故障排除、数据库智能前端、财务顾问、医疗诊断和治疗选择、设计辅助以及各种决策支持系统。

大多数系统采用规则作为重要的知识表示机制。规则是一种条件结构，可用于定义逻辑必然性、因果关系、情境 - 动作对以及替换模式的产生规则。系统中存在一个明确的机制，用于根据规则和事实进行推理，通过识别和评估知识库中的相关规则来得出各种结论。然而，纯基于规则的方法并不总是能直接控制推理过程。特别是在系统需要呈现自然对话行为时，可能需要额外的手段来控制咨询过程中的流程。因此，目前大多数用于构建专家系统的工具和外壳都支持混合知识表示机制，例如将规则与面向对象的方法相结合。

除了规则，基于案例的推理（Case-Based Reasoning）也是一种重要的范式，它允许用户通过类比推理将决策问题与先前的案例联系起来，并为用户交互提供框架。其他流行的技术，如神经网络和遗传算法，在当今的系统中也发挥着重要作用，但它们通常被视为黑盒实现，对基于知识的系统的人机因素方面影响不大。

从技术角度来看，基于知识的系统应与仅基于超媒体、数据库管理、信息检索、面向对象和过程处理等技术的系统区分开来。尽管这些技术可以在基于知识的系统中使用，但明确表示知识对于本章讨论的系统类别至关重要。从用户的角度来看，底层技术并不总是可见的。在通信方面，基于知识的系统可以通过多种方式与用户交互，从标准图形用户界面（GUI）到准自然语言。此外，对话控制的底层流程以及用户和系统之间的主动性分配也特别值得关注。

2. “智能”过程的简史

2.1 人工智能

“人工智能”这一术语可以追溯到1956年，当时一群研究人员在达特茅斯夏季会议上讨论了受新兴计算技术启发的机械化智能的科学研究前景。当时已经有一些“智能”系统，例如赫伯特·西蒙（Herbert Simon）和艾伦·纽厄尔（Allan Newell）实现的处理逻辑证明的“逻辑理论家”（The Logic Theorist）。该系统基于产生式系统的形式主义，并融入了一些解决智力任务的思想，在执行逻辑证明的明确任务方面非常成功，但在模拟人类思维和与人类交互方面与人类智能有很大差距。

2.2 模拟人类推理

后来，赫伯特·西蒙、艾伦·纽厄尔以及马文·明斯基（Marvin Minsky）和罗杰·尚克（Roger Schank）等人开始致力于模拟人类推理、问题解决和文本处理等需要人类智能的领域。“智能”程序取得了一定的成功，赫伯特·西蒙和艾伦·纽厄尔使用产生式系统模型模拟了详细的人类推理过程。然而，很快人们发现需要更精细的人类知识表示模型。马文·明斯基提出了“框架”（frames）的概念，罗杰·尚克及其合作者则形式化了“脚本”（script）的概念，用于模拟人类的理解。这些概念旨在模拟通用的人类知识，但这些系统的主要弱点是基于包含很少领域知识的应用，在处理需要大量人类知识的问题时表现不佳。

2.3 早期专家系统

20世纪70年代，专家系统从实验室走向现实世界。爱德华·费根鲍姆（Edward Feigenbaum）提出可以将人类拥有的知识表示在计算机程序中，这是将一个人的知识在计算机中表示以供他人使用的第一步。这些系统被称为“专家系统”，因为它们被认为包含了“专家”的知识。其意义在于，在专家稀缺或无法提供服务的情况下，可以通过计算机提供专业知识。知识库也被视为保存可能丢失的知识的一种方式，例如蒸汽机故障排除的知识。到1988年，商业领域已经有139个专家系统在农业、计算机、建筑、公用事业、金融、制造、采矿、地质、医学、科学和运输等各个领域得到应用。

3. 当前基于知识的系统

基于知识的系统在人类与系统之间的任务分配以及人机通信类型方面存在差异。自动化程度可分为高、中、低三个级别：
- 高级自动化：系统几乎完全接管任务，人类用户为系统提供信息，并负责检查和解释系统提供的结果。
- 中级自动化：人类和计算机系统共同解决问题。计算机系统可被视为智能代理，能够独立解决部分任务，并为人类的问题解决工作提供建议或批评。
- 低级自动化：系统应用户请求作为工具使用，可作为智能帮助或智能信息搜索器。

基于知识的系统的典型任务是提供咨询建议，类似于专家通过电话提供的建议。传统上，这类系统通常实现为目标驱动、基于规则的系统，在收集足够信息以从知识库中的相关规则得出结论的过程中与最终用户进行对话。在这种方法中，系统掌握主动权，需要时会要求用户提供额外信息。

然而，在许多情况下，让用户扮演被动角色并不理想，而且让系统提出决策建议而让用户承担责任也不是一个好的解决方案。用户可能会轻易接受系统的建议，而不考虑专家建议的可靠性，这可能导致决策错误，因为系统和用户都难以跟踪系统知识的限制和适用性。

近年来的发展更倾向于支持用户自己的决策，而不是直接给出建议。专家批判系统就是这种趋势的体现，用户首先提出决策或行动方案，系统然后审查该建议，并就建议的合理性、必要的先决条件、合理的替代方案及其优点等方面提供评论。

提供咨询建议的合作计算机系统有三种不同的范式：
|范式|特点|
| ---- | ---- |
|事务系统|代表经典的数据处理方法，特定任务对应系统中的特定事务。每个事务与一组固定的输入数据相关联，用户需按规定格式输入数据，在事务处理过程中无法与应用程序或后台数据库进行交互。这种系统较为僵化，但配备良好直接操作界面的事务系统可让用户掌握主动权并感觉能控制整个系统。|
|专家咨询系统|通常采用基于规则的系统，系统试图从知识库中推理解决任务。需要额外信息时会询问用户，最终结果通常会附带对建议决策的论证，包括结果如何从输入数据得出以及使用了哪些知识。解释通常是预先编写和存储的，或者从系统执行的计算轨迹中生成。虽然比传统事务系统更灵活、强大，但问题解决和对话过程的主动权基本由系统掌握，这有时会让用户感到沮丧。|
|专家批判系统|用户向系统提交一个或多个替代解决方案，以便系统进行评论。这样，用户可以控制在决策过程中何时寻求计算机的建议，问题解决的整体方法主要由用户在提出的决策中表达的偏好控制。|

这三种范式在计算过程和实现所需的知识表示方面的复杂程度逐渐增加。本章的讨论将主要集中在传统的提供建议的专家咨询系统的经验上，这是文献中使用最广泛且记录最详细的方法。然而，总体趋势是朝着联合认知系统发展，即人类和计算机在问题解决和决策过程中进行合作。

4. 经典专家咨询系统

许多专家系统具有高度自动化和与用户沟通有限的特点。早期的一个例子是RI/XCON，它用于配置数字设备公司的计算机系统。该系统并非主要旨在模拟人类推理，也不依赖与人类的交互，但它是商业专家系统中最成功的例子之一。其基于知识的方法展示了如何有效管理任务的巨大复杂性，以及如何修改知识库以适应不断变化的需求。从XCON的长期发展历程中可以观察到，不仅要关注技术问题，还要关注系统所服务的个人的特定态度，如他们对工作、计算机辅助、过程明确性等方面的态度。这表明工作场所分析研究的重要性。

更典型的基于知识的专家系统会与用户进行对话，并支持用户的决策。20世纪70年代专家系统的突破部分归功于MYCIN等系统的成功演示，这些系统能够提供高质量的建议，并附带有用的理由和解释。例如，MYCIN仅使用500条规则就能够捕捉到重要且困难的应用领域中的重要专业知识，同时通过基于规则的方法轻松提供结果和建议的解释和理由。

在基于规则的专家系统中，与用户的对话是根据规则前提部分的信息需求生成的。当需要系统中未知或无法从现有事实推导的信息时，会向用户提出问题。系统的推理从给定目标（寻求的解决方案）向后追溯，直到可以输入用户已知的事实。这种询问用户的方式不需要复杂的自然语言输入处理机制，输出可以使用简单模板和预制文本以自然语言表述。

这种方法的主要弱点是无法处理不能简单表述为事实的复杂输入，以及用户缺乏主动性，需要等待系统询问信息。虽然可以设计更复杂且由程序员控制的用户对话，但这会失去基于规则方法的简单性和优雅性。

MYCIN的一个重要成果是EMYCIN外壳，许多商业产品都紧密遵循MYCIN/EMYCIN的解决方案。这些工具或外壳已成功用于为许多应用构建有效的专家咨询系统。

Prospector系统也采用了基于规则的方法，但其对话管理更为复杂。用户可以用自然语言输入观察结果，这不仅要求系统能够解析和分析英语输入，还需要语义网络和概念分类法来将通用规则与特定实例联系起来。例如，当用户输入“我发现了一个流纹岩岩栓”时，系统必须能够判断提及火山岩的规则是否适用。Prospector系统成功展示了在复杂的地质勘探领域中对专家知识进行建模和推理的能力，但未能构建出易于使用的外壳来在其他领域构建类似系统，因此其更高级的对话管理风格没有得到广泛效仿。

除了纯基于规则的系统提供的自动解释和知识透明度潜力外，Clancey还证明了这类基于知识的系统可以转变为智能辅导系统。然而，这种解释和辅导方式存在严重局限性，需要添加额外的解释信息和特定知识才能改善情况。

在知识系统中，管理用户界面是一个特殊的挑战，因为系统和用户都会产生通信行为。专家系统架构通常更注重解决领域问题所需的推理，而忽视对话结构。一种解决方案是使用用户界面管理系统（UIMS），它可以管理对话并在推理和对话过程之间进行协调。

例如，专家系统UIMS Ignatius结合了负责用户界面交互技术的表面交互管理器和处理对话结构的基于计划的会话对话管理器。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(用户):::process -->|输入信息|B(基于知识的系统):::process
    B -->|输出结果和建议|A
    B -->|内部推理|C(知识库):::process
    C -->|提供知识|B
    B -->|对话管理|D(UIMS Ignatius):::process
    D -->|协调对话|B

5. 专家批判系统

专家批判系统为用户的决策提案提供反馈。用户先提出决策或行动方案，系统在已知情况下审查该建议，评估方案，提供改进建议，指出可能风险，列出替代方案并评估其优点等。以下是不同领域中专家批判系统的发展情况：
- 医疗领域 ：Miller在医疗应用中引入了专家批判的概念。相关研究还包括在MYCIN传统中解决用户与建议程序之间冲突的需求，以及HELP系统对医疗治疗决策的审查和警示生成。Van der Lei的研究表明，仅基于医疗记录就可以生成有用的批判。
- 工程设计领域 ：早期在工程设计领域也有类似研究，如CRITTER系统对数字电路设计的评估和评论。Fischer及其同事在设计批判方面做出了重要贡献，从LISP批评开始，发展到人机协作设计支持的研究。
- 通用批判系统 ：Silverman基于专家错误和批判理论开发了COPE系统，可视为通用的批判外壳。同时，也有关于专家批判可用性方面的讨论。

目前许多应用都采用了专家批判方法，该方法具有以下特点和优势：
- 知识基础灵活 ：可以基于启发式领域专业知识或形式决策理论。实践经验表明，启发式方法为开发工作系统提供了更方便的基础，批判范式适合应对决策过程中缺乏形式理论的情况。
- 实现方式多样 ：可以是基于知识的，也可以是算法的，如拼写检查器。
- 批判方法可选 ：可以采用分析方法或差异方法进行批判。分析方法评估和评论用户决策建议的各个方面，差异方法则将建议解决方案与“正确”或标准解决方案进行比较，具体选择取决于应用场景。
- 注重论证讨论 ：不仅关注对用户首选解决方案的批判，还关注对系统自身建议的论证。可以将专家批判系统概念化为能够与用户进行论证性讨论的系统。
- 文本生成方式 ：可以采用临时方法或语言方法进行文本生成。批判的内容、底层结构以及用于论述的修辞手段都很重要。

不过，专家批判系统也存在一些需要考虑的因素：
|因素|具体情况|
| ---- | ---- |
|构建复杂性|构建专家批判系统通常比传统系统更复杂，因为它既需要有推导首选解决方案的知识，又要有批判各种替代方法的能力。|
|应用范围|批判方法的应用范围更广，即使系统自身无法生成完整解决方案，也可以对用户提出的各种建议提供有用的评论。|
|用户控制感|在用户希望控制决策过程的情况下，批判系统可能更受青睐。用户提出第一个解决方案建议后会更投入，从而提高用户满意度。|
|处理冲突知识|批判系统可以方便地处理领域中的冲突专业知识，它不需要产生一个特定的推荐解决方案，而是可以维护一个包含处理给定问题的替代方法的知识库。如果采用分析批判方法，用户建议可以轻松与不同的解决方案进行比较。|
|部分知识可用性|在只有部分领域知识的情况下，批判系统也很有用。当系统只能处理问题的某些方面或对给定情况的知识不够深入时，它可以告知用户生成的评论和批判的质量和可靠性。|
|过渡支持|专家批判方法可以为从具有有限知识库的批判系统发展为成熟的专家系统提供过渡支持。在知识库合理完整和验证之前，传统专家系统无法实际使用，而批判方法可以让用户在系统构建早期使用部分知识库获得实践经验。

专家批判还可以分为以下几种类型：
- 推理和问题解决机制 ：用于组织处理问题所需的知识和推理。知识库通常组织为一组在不同情况下应用的批评，可用于生成 - 测试的问题解决方法，如对软件规范的批判。
- 非侵入式建议 ：主要目的是确保用户控制决策过程。系统仅对用户的建议进行评论，即使它可以提出替代解决方案。主要关注监控系统与用户之间的交互。
- 可理解的论证和解释 ：主要关注批判的语义、范围、组成部分和修辞结构。文本生成的研究与此方面的批判相关。

6. 专家系统的讨论

6.1 对“智能”系统的批判

对“智能”系统的批判主要来自哲学家。人类知识具有意向性，推理既有意义又有目的，而机械系统无论多么复杂，都无法对自身知识进行推理或反思。这种批判主要针对早期的人工智能运动，如纽厄尔和西蒙提出的启发式问题解决者，旨在模拟人类推理，但对算法或数学模型没有影响。

大多数基于知识的系统需要明确表述专家知识，这也受到了批评。Winograd和Flores认为，知识在出现问题之前不会被反思，因此知识不能被明确表示，而应被视为一种从符号下过程中涌现的属性。Lucy Suchman则认为，人们不会严格遵循预先制定的计划，而是根据当前情况制定计划。例如，复印机的帮助系统基于简单的顺序模型，当出现问题时，人们会放弃原计划，系统反而变得混乱而无助。这些观点表明，人类知识是在社会环境中实现的，而不是“存储”在头脑中。

然而，简单地否定基于知识的系统是不合理的，就像不能一概否定代数方法一样。重要的是研究在各种情况下如何开发、使用和交流基于知识的启发式方法。

6.2 专家系统的实际问题

尽管存在哲学和理论上的批判，基于知识的系统仍在不断被使用，但在实际应用中仍存在一些问题，主要包括责任归属、人类知识的“萎缩”和用户接受度：
- 责任归属 ：当系统提出误导性或错误的决策或建议时，责任归属不明确。从法律上讲，用户通常对最终行动负责，但用户咨询系统可能是因为缺乏解决问题的全部知识。专家和知识工程师也可能不应该完全承担责任，因为系统使用中的无意识情境假设属于专家的“隐性知识”，知识工程师并不了解。为了帮助用户决定是否依赖专家建议，系统应明确其适用和不适用的上下文。
- 人类知识的“萎缩” ：引入新工具可能导致人类知识的变化，人们担心随着基于知识的系统的发展和使用，专家知识可能会“萎缩”。例如，使用专家系统可能不会鼓励进一步的技能培训或知识发展，就像使用计算器使心算变得不必要，使用文字处理器在一定程度上使手写变得过时。然而，也有一种观点认为，人类知识是不断发展的，新工具的出现会改变知识和环境，知识体现在工具及其使用中，情况无法回到没有该工具的状态。例如，在飞机自动化中，如果用户忘记与系统合作，可能会高估自己的技能，导致事故发生。解决方案是培训用户在有系统和没有系统的情况下都能工作。
- 用户接受度 ：专家系统可能会遭到抵制，原因包括：专家担心被系统取代；早期专家系统让用户扮演被动角色，工作变得乏味，而批判系统可以让用户更积极地参与；用户对计算机建议的信任与对系统的熟悉程度有关，人们对计算机建议的判断也受到建议形式的影响，更人性化（冗长）的形式可能不如更机械的形式受信任。此外，新手在领域中往往比专家更容易相信建议，人们倾向于先相信所理解的信息，拒绝建议需要更多的知识。因此，专家系统的接受度和可用性可能取决于用户判断其可靠性的能力，以及检查系统建议是否适用于当前问题的机会。

7. 专家系统的实证研究

7.1 案例研究

大多数实证研究是案例研究，因为很难对不同系统、领域和用户进行概括。以下是一些典型的案例研究：
- XCON系统 ：XCON用于配置计算机系统，取得了巨大成功。但类似的营销系统XCEL在美国成功，在欧洲却失败了，因为欧洲销售经理希望由专家使用该系统，而专家认为没有必要，导致系统被闲置。这表明组织文化对系统的使用有重要影响。
- 投资建议和飞机故障诊断系统 ：在投资建议过程中引入专家系统，以及在飞机发动机故障诊断中使用专家系统的研究，都显示了系统的优缺点。优点包括提高效率，以及利用知识库进行教育和文档记录；缺点包括对用户能力的要求，以及社交接触的减少。在投资建议案例中，用户的关注点从判断投资风险和收益转移到与客户沟通，系统在处理复杂问题时效果更好。在这两个案例中，知识工程师在系统设计和更新中都起着核心作用，同时也需要计算机专家解决软件相关问题。

7.2 实验研究

为了理解影响基于知识系统使用的因素，可以通过实验改变一些变量，如覆盖的领域、使用的知识模型和与用户的交互类型。但目前对这些变量的影响了解不足，难以进行预测测试。而且，在现实世界中设置涉及忙碌用户的实验很困难，难以得出广泛的结论。

以下是一些实验研究的例子：
- 工程师使用专家系统 ：Will对工程师使用专家系统分析油井压力积累的研究表明，使用系统的用户对自己的解决方案更有信心，但决策质量与未使用系统时相似。专家比新手更不喜欢该系统。
- 计算机化导师与用户的交互 ：Nass等人的研究改变了计算机化导师与用户的交互类型，特别是导师自我表扬或自我批评的程度。结果发现，得到自我表扬的表现更受用户重视，提供批评的系统被认为更聪明。这表明导师对自己的信心会影响用户。

实验研究表明，系统建议的形式会影响用户对系统的信任，建议的内容与用户的领域知识相互作用。很难对领域中的“专业知识”进行令人满意的定义，因为提供知识的专家和知识系统用户都只掌握部分可用知识、特定的知识视角或解决问题的策略。因此，对“专家”和“新手”的研究需要相对解释，即具有“高”或“低”水平的知识。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(用户知识):::process -->|影响|B(用户信任):::process
    C(系统知识):::process -->|影响|B
    D(系统形式):::process -->|影响|B
    A -->|判断|C
    B -->|反馈|A

8. 智能干预策略

8.1 联合认知系统相关问题

问题解决、规划或决策任务对计算机系统设计师和处于任务情境中的人类来说都具有挑战性。设计师需要为可预测的情况进行设计，而用户需要应对可预测和不可预测的情况。引入计算机系统可能会带来新问题，因为用户需要解释和验证计算机的专业知识，这被称为“自动化的讽刺”。

要实现令人满意的联合认知系统解决方案，一种方法是让计算机做擅长的事情，人类做擅长的事情，但这种方法过于表面，没有考虑到环境要求、任务性质、计算机支持的能力和形式以及个体差异等因素。研究表明，这些因素对联合认知系统的性能效率有重要影响。例如，Layton对飞行员在航线重新规划任务中的研究发现，在更自动化的情况下，飞行员更有可能选择较差的计划，这表明用户在复杂情况下难以可靠地判断计划的质量。Dalai比较了认知任务要求与用户和计算机支持的“认知风格”，结果表明，根据情况，相似性和互补性都很重要，需要进一步分析辅助工具和任务才能得出一般结论。目前，关于联合认知系统的人类因素研究缺乏一个统一的理论来指导寻找相关因素，相似性、互补性、任务分配和任务协商等原则都不能作为通用原则，而应根据联合认知系统的运行环境来确定原则。任务的复杂性、时间压力、解决方案的收敛性或发散性、环境的不确定性、系统的不完整性以及任务的动态性质等因素都很重要，因此很难提出明确的指导方针。

8.2 深度知识与认知偏差

联合认知系统关注任务的执行以及计算机和用户如何协作完成任务，而另一种方法则关注处理任务所需的深度知识以及计算机系统需要克服的人类认知偏差。认知心理学研究发现，人类在认知推理中存在一些偏差，例如倾向于忽视负面信息，容易接受而不是拒绝假设，并且在制定假设时更倾向于接受而不是拒绝。这种推理方式可能会对评估计算机系统的建议产生不利影响。人类还倾向于忽视事件的基本概率，在基本概率较小时高估事件的可能性，在基本概率较大时低估事件的可能性。

基于知识的系统可以帮助用户避免这些偏差，使他们注意到通常会忽略的信息。Silverman开发了实验系统来预防或批判用户错误，他发现更复杂的问题可能需要预防性帮助或决策支持，即用户不仅要意识到可能的偏差，还需要有足够的手段来克服这些偏差，例如使用概率计算公式。

Silverman还研究了系统与用户的交互风格，发现领域新手更受益于直接、提供更多领域原则、主动控制并提供固定信息而非动态推理的系统，而领域专家则更喜欢微妙的提醒、浅层的原则、灵活的控制和动态信息。因此，批判应该根据不同用户进行定制，不仅要考虑领域知识和处理偏差的方式，还要考虑交互风格。

8.3 基于知识的系统中的解释

在联合认知系统中，各方需要就任务进行沟通，因此计算机解释非常重要，特别是对于批判系统、协作学习系统或其他类型的智能支持。早期仅提供系统推理轨迹的解释方式是不够的，因为推理轨迹不一定与系统最终用户相关，它可能包含不熟悉的点需要进一步解释，或者包含琐碎的推理步骤。

为了满足心理需求，解释必须与接收者的知识相关，因此需要用户模型。为了实现学习的迁移，仅靠特定问题的规则是不够的，还需要一个领域相关关系的模型，这就引出了“深度解释”的问题。“深度模型”明确表示知识库规则中隐含的关系，可用于建模用户知识和确定用于解释的知识。

此外，还需要确定一种可靠的方法来处理通信需求，仅使用推理模型不足以实现预期的通信。一些研究关注了解释的交际方面，例如Rankin讨论了在批判情境中进行论证支持的文本生成，展示了如何使用论证理论作为批判和论证文本的框架，并引入语言游戏隐喻来扩展到对话情境。

解释可以分为描述、叙述、说明和论证等类别，每个类别还可以进一步细分，并且都需要额外的信息，其中大部分不能自动生成。获取解释所需的信息可以看作是一个新的知识征集事件，需要专家付出大量额外的努力。

不同类型的解释对新手和专家的作用不同，领域新手更喜欢包含朴素和专家知识、特定和一般原则的详细解释，而领域专家则更喜欢简短明了的解释。为了提供相关和有用的信息，需要考虑个体差异，“用户模型”可以包含从领域知识假设到任务相关问题再到表面结构问题等多种类型的信息。用户建模是一个重要问题，在设计建议、帮助、指导以及用户界面设计等方面都有涉及。

9. 讨论与结论

从用户的角度来看，基于知识的系统的设计面临许多与常规任务计算机系统不同的挑战。这些系统旨在用于复杂情况，没有算法可以解决问题。目前，关于可用性方面的文献较少，实证研究也尚无定论。新系统不断开发，实证研究难以跟上发展的步伐。因此，研究的贡献应该与基于知识的工作的理论发展以及促进此类支持系统开发的指导方针相关。

目前，可用于基于知识工作的理论研究较少，当前占主导地位的理论主要关注问题领域的有限方面，主要涉及个体决策或问题解决。工作环境需要考虑更多方面，“分布式认知”领域的最新发展可能相关，但该研究仍处于起步阶段。

最近才制定了开发专家系统的人类因素指导方针，包括：
- 确保用户合作 ：尽管以用户为中心的设计在系统开发中得到广泛认可，但这种实践尚未在基于知识的系统设计中普及。开发知识系统的方法应该与其他计算机支持系统的开发方法类似。
- 确保任务合适 ：基于知识的系统不能用于所有类型的任务，任务应具备以下条件：可以得到答案；可以在短时间内得到答案；答案不是基于常识；有容易获取的专家可以解释如何解决问题；深度比广度更重要；信息不会不断变化；系统必须能够通过结果证明其价值，如提高生产力或降低成本。
- 确保兼容性 ：基于知识的系统和其他计算机支持系统应与现有任务兼容。如果用户需要改变工作惯例，而新惯例与旧实践不兼容，他们会反感新系统，并难以学习新的工作流程。
- 确保视角多样性 ：目前大多数基于知识的系统依赖单一视角，但专家可能具有互补的知识和解决问题的策略，这些可能与用户的某些观点和知识不兼容。视角的多样性可以扩展用户和专家的知识。
- 为矛盾的准则找到妥协方案 ：需要在管理者对正式工作组织的想法和知识工作者实际执行的工作之间找到妥协。这意味着从管理角度和知识工作者角度看待任务的知识可能存在差异，知识工作者可能会“超越”他们认为不必要的规则或找到不符合规定程序的捷径，而管理者应该有坚持“不必要”程序的合理理由。

组织需要发展其“知识资本”，基于知识的系统是实现这一目标的一种技术。组织需要谨慎对待专家和系统用户，以防止知识“萎缩”或被滥用。应该通过实际联合系统的性能反馈来促进知识资本的发展，知识资本应被视为不断发展的，受到用户和专家的输入、使用经验以及先前领域知识的影响。最终的挑战是设计能够结合人类和计算机智能解决问题的系统，并根据具体情况找到正确的组合方式，这需要人类因素专家和技术专家的创造性合作。