Knowledge Engineering Tools at the Architecture Level

I. Introduction

This paper is about tools for knowledge engineering at the architecture level. A knowledge system architecture spe­ cializes common AI problem-solving techniques to a par­ ticular class of tasks. An architecture provides descriptions of a particular kind of problem solving (e.g., diagnosis or configuration) at a conceptual level that is above the im­ plementation, thus making clear which aspects of a class of problems are intrinsic to the· problem and which are ar­ tifacts of the implementation. An architectures is a partial design of a knowledge system in which some decisions are made in advance to support particular task characteristics. For example, many medical diagnosis systems first inter­ pret data bottom-up to find "triggered" disease hypothe­ ses, then set top-down goals of acquiring evidence pro and con the triggered hypotheses. This "trigger/ acquire ev­ idence" cycle is an intrinsic part of any architecture for the class of medical diagnosis tasks, though it might be implemented in a wide variety of ways.

Architecture-level tools for knowledge engineers can improve the productivity of system development and knowledge acquisition because:

• By supporting the abstraction of representational and computational primitives at the architecture level they permit the knowledge engineer and expert to c~ operatively develop systems using a shared language of architecture constructs, rather than in terms of the underlying implementation.
• They can incorporate knowledge about the architec­ ture to facilitate system development and knowledge acquisition (e.g., by enforcing constraints on the types and values of elements in the knowledge base).

Jar class of tasks. Architectures have been developed for simple classification (e.g., decision trees), heuristic classi­ fication (e.g., HERACLES [Clancey, 1986]; CSRL [Bylander and Mittal, 1986]), constructing configurations (e.g., SALT [Marcus, 1987]; COAST [Bennett, 1986]), and routine de­ sign (e.g., DSPL [Brown and Chandrasakeran, 1985]; DO­ MINIC [Howe et al., 1986]}.

The second perspective is structural: an architecture is a partial design that includes specifications of knowledge representation formalisms, inference mechanisms, and con­ trol strategies. Many of the structural components, such as frame and rule systeins, are provided by commercially available AI programming environments. Architectures, however, are not arbitrary combinations of these compo­ nents, but artifacts designed by the knowledge engineer for particular tasks.

A third view of an architecture is that it defines a virtual machine. Just as Lisp provides primitives for sym­ bol manipulation that the programmer can use without thinking about how they are realized in hardware, a knowl­ edge system architecture presents representational primi­ tives above the level of their implementation. The archi­ tecture provides a language that describes the behavior of a system in terms natural for the knowledge engineer and expert. For example, most medical diagnosis systems provide some kind of support for triggering- making par­ ticular hypotheses "active" when certain events occur, typ­ ically input data. To the expert, triggering might corre­ spond to "bringing a diagnosis to mind." A programmer can produce the effect of triggering using implementation­ level primitives (e.g., giving triggered diseases high cer­ tainty factors or agenda priorities). But terms such as triggering - not their implementation - are the medium of knowledge engineering. Such tCI8k-level terms promote explanation [Swartout, 1983] and knowledge acquisition [Gruber and Cohen, 1987]. Knowledge engineers, experts, and users can all understand triggering without thinking about how it is implemented. A virtual m!Khine that exe­ cutes triggering as a primitive is easier to program.

In summary, the functional view of an architecture emphasizes the behavior of programs that instantiate it. The structural view emphasizes knowledge representa­ tions, inference methods, and other components of the ar­ chitecture. A virtual machine integrates these views: it is an abstract device designed to meet the functional needs of a class of problem solving tasks. The next section discusses how the interactions of these views result in an organiza­ tion of knowledge engineering tools.

III. Tools for the MU Architecture

In this section we describe an architecture for systems that actively manage uncertainty, called MU [Cohen et al., 1987b], with the aim of illustrating how the three views of architectures influence the design of knowledge engineering tools. MU grew out of experience with MUM (Managing Un­ certainty in Medicine), a system for planning a series of di­ agnostic questions, tests, and treatments for diseases man­ ifesting chest and abdominal pain [Cohen et al., 1987a].

The primary aim of MUM is to decide how to act when data are insufficient for diagnosis and treatment. Like a physician, MUM reasons about tradeoff's between the costs of evidence, the marginal utility of potential data given what is already known, the effects of treatments and the evidence they provide, and so on. MU is an architecture for building systems like MUM that reason about uncertain situations in deciding how to act.

Viewed from a functional perspective, MU's task is managing uncertainty by taking appropriate actions. The task requires knowledge about the effects of actions on multiple goals, such as providing evidence for and against hypotheses, minimizing cost, and treating the condition. Structurally, MU has a large inference network of hypothe­ ses, supporting evidence and intermediate conclusions, and actions that produce evidence and provide treatment; a working memory of developing hypotheses; inference mech­ anisms for propagating the effects of evidence in working memory; and support for strategies that choose among ac­ tions. Viewed as a virtual machine, MU supports knowl­ edge engineering in terms that make sense for diagnostic tasks, such as hypothesis and potential-evidence. These terms are specialized for specific domains by terms such as distJCI8e, and further instantiated as specific diseases such as angina.

The interactions of these views of the MU architecture are apparent in the design of knowledge engineering tools. Figure 1 shows a hierarchy of tools that supports develop­ ment of systems in MU. The foundation is a commercially­ available AI programming environment that includes im­ plementation primitives such as rules and frames, and ba­ sic AI programming techniques such as pattern-matching rule interpreters and message-passing. The bottom layer in Figure 1 is a structural description of the implementa­ tion of MU. It is not a design for an architecture, because no functional description has been given or is implied by this collection of implementation primitives, which could be instantiated to provide a wide range of behaviors.

The functional view of an architecture constrains how implementation-level primitives and techniques are spe­ cialized for a particular kind of problem-solving. The func­ tional requirements of MU are that it should represent in­ ferential relations among data, intermediate conclusions, and hypotheses. It should maintain measures of belief in all these objects, decide focus of attention (i.e., which objects to seek evidence for), and decide which evidence to seek. At the second level of Figure 1, the frames and slots of the first level are specialized as hypotheses and inferential relations. Inferential relations serve as pathways through the inference net. Rules are used to implement combining functions that specify how evidence supporting hypothe­ ses is combined when propagated from subordinate nodes. Some properties of hypotheses and data-gathering actions - a subset of their slot values - are used as control param­ eters, which help determine focus of attention. The value propagation mechanism is implemented with the demons ("active values") and message passing capabilities of the frame system. In summary, the structure of the architec­ ture is designed from implementation constructs to meet the functional requirements of a particular problem solv­ ing method, resulting in a virtual machine, or task-specific shell.

An architecture is designed not for a specific task like diagnosing chest pain, but for a class of tasks such as diagnostic reasoning. The knowledge engineer and expert instantiate architecture-level primitives for a par­ ticular application just as the architecture designer spe­ cializes implementation-level primitives. Figure 2 is a structural view of MUM - the chest pain specialist - engineered in the MU architecture. Hypotheses are in­ stantiated as diseases such as classic angina; inter­ mediate conclusions are instantiated as clusters such as exercise-induced pain; inferential relations are in­ stantiated by specific links between evidence and conclu­ sion, such as the potential evidence link between EKG results and classic angina.

Having instantiated architecture-level constructs such as hypotheses with domain-level terms such as diseases, the knowledge engineer can build a knowledge-acquisition in­ terface to help elicit knowledge in the terms of the domain. Knowledge about the architecture-level terms is provided by the knowledge engineer in the shell, and is inherited by the domain objects used in an application. Knowl­ edge acquisition utilities, on the top of the hierarchy, use meta-knowledge a.bout objects in the knowledge base to help the user build a syntactically valid and semantically consistent knowledge base. Currently MU supports form­ filling editors for all knowledge base objects, graphical in­ terfaces for acquiring combining functions, and rudimen­ tary consistency-checking abilities. Tools for interactively acquiring control knowledge are in progress.

IV. Conclusions

Architecture-level knowledge engineering tools have sev­ eral advantages:

• One can capitalize on the vertical integration of implementation-level tools at the architecture level. For example, a general-purpose frame editor and net­ work grapher provided at the implementation level (such as the KREME interface [Abrett and Burstein, 1987]) can be customized as a knowledge acquisi­ tion interface for editing architecture-level constructs such as hypotheses and their instantiations as dis­ eases. This is possible because the architecture-level objects are specializations of implementation-level ob­ jects (i.e., frames), and consequently share their struc­ ture.
• Declaratively representing architecture-level con­ structs - the primitive objects of the virtual machine - encourages a consistent design shared by a team of programmers. For example, once the trigger relation has been designed, one need not worry about several members of a software project trying to achieve the same functionality with different implementations.

• Declarative architecture-level constructs also facilitate knowledge acquisition because meta-knowledge can be attached to objects to check for consistency, provide help, generate explanations, and so on. For exam­ ple, a form-filling interface specialized for acquiring an instance of a disease can use a declarative descrip­ tion of the properties of diseases, such as the kinds of relations they have with data, to offer a menu of documented choices [Gruber and Cohen, 1987] .
• Building a virtual machine at the architecture level and then a knowledge acquisition interface on top of the virtual machine defines the roles of the knowl­ edge engineer and expert. The knowledge engineer de­ signs an architecture by specializing general-purpose implementation-level tools to operationalize the con­ structs suited for the problem solving task, whereas the expert instantiates architecture-level constructs for the application domain. Virtual machine tools [sic] assist the knowledge engineer in customizing an archi­ tect \Ire for a particular application, and knowledge ac­ quisition tools help the expert build, refine, and debug the knowledge base.

V. Discussion

The hierarchy of tools discussed here reflects a power/generality tradeoff. Constructs at the implemen­ tation level are general (e.g., production systems can be configured for many kinds of problem solving) but from the standpoint of knowledge engineering they are weak. To say an object is a disease hypothesis is to imply much more knowledge about it than to say it is a frame, even though the implementation of the disease hypothesis may be no more than a frame. This added knowledge constrains the internal structure of the disease frame (e.g., values and types of slots, or the kinds of messages it can han­ dle, etc.), constrains its relationships with other frames, and so on. Since these constraints facilitate knowledge engineering, architecture-level objects like disease frames are at the "power" end of the power/ generality spectrum. Implementation-level objects, lacking constraints, are more general but correspondingly less powerful from the stand­ point of knowledge engineering;.

Thus, when one builds an expert system for a task, the utility of an architecture level analysis depends entirely on how much one knows about the task. The knowledge system architecture embodies knowledge about a class of problem solving tasks - it is a virtual machine for that class - and as such facilitates system development and knowl­ edge acquisition for problem solvers of that class. The power/ generality tradeoff tells us that we can ameliorate the knowledge acquisition bottleneck for restricted classes of tasks by designing architectures and building integrated "power tools" at the architecture level.