Knowledge Base Systems

production rule representation.

Production Systems
Introduction These are a form of knowledge representation which have found widespread application in AI particularly in the area of Expert Systems.

Production systems consist of three parts: a) A rule base consisting of a set of production rules. b) the data c) an interpreter which controls the systems activity.

Production Rules
A production rule can be thought of as a condition action pair. They take the form IF condition holds THEN do action e.g. IF traffic light is red THEN stop car.

Firing Production Rules

A production rule whose conditions are satisfied can fire, i.e. the associated actions can be performed. Conditions are satisfied or not according to what data is currently available. Existing data may be modified as production rules are fired. Changes in data can lead to new conditions being satisfied. New production rules may then be fired.

 The decision which production rule to fire next is taken by a program known as the interpreter. The interpreter therefore controls the systems decisions and actions and must know how to do this.

Production Systems
Production systems were first proposed in 1943 by Post. Present day systems however bear little resemblance to those earlier ones. Newell and Simon in 1972 used the idea of production systems for their models of human cognition and AI in general has found widespread use for them.

Suitable Domains
Davis and King (1977) proposed the following criteria for problem domains where productions rules are suitable. 1: Domains in which knowledge is diffuse, consisting of many different strands of knowledge rather than some domain which is based on a unified theory like Physics. 2: Domains in which processes cane be represented as a set of independent actions as opposed to domains with dependent subprocesses. 3: Domains in which knowledge can be easily separated from the manner in which it is to be used as opposed to cases where representation and control are merged.

Knowledge Base Systems

Knowledge Base systems are intended to perform tasks which require some specialized knowledge and reasoning. Medical diagnosis, geological analysis, and chemical compound identification are examples of tasks to which Knowledge Base systems have been applied.

Expert Systems
Knowledge Base systems are often called expert systems because the problems in their application domain are usually solved by human experts. For example medical diagnosis is usually performed by a doctor.

Parts of a Knowledge Base System

Knowledge Base systems consist of Four major parts; The Knowledge Base, The Inference Engine The User Interface and The Explainer Knowledge Acquisition Module

Inference Engine Knowledge Base (rules)

Agenda

Working Memory (facts)

Explanation Facility

Knowledge Acquisition Facility

User Interface

 The knowledge to which the Knowledge Base system has access, is stored in the Knowledge Base, (hence the name). The Inference Engine is the part of a Knowledge Base system which is responsible for using its knowledge in a productive way. The Knowledge Base system's reasoning mechanisms are built into the Inference Engine. Most Knowledge Base systems employ deductive reasoning mechanisms.

 The Knowledge Base system communicates with the user through the User Interface. In many applications the Knowledge Base system is required to explain its reasoning to the user. This is particularly true in situations such as the identification of chemical structures where new results must be verified. The Explainer is that part of the Expert System which provides explanation and verification

 Knowledge Acquisition Modules These help with acquiring the systems knowledge. They do a variety of tasks for example in some systems they provide system analysis facilities similar to those of database development tools Mostly they help encode the knowledge from a high level format into a computer usable representation.

System Architecture

Inference Engine Knowledge Base (rules)

Agenda

Working Memory (facts)

Explanation Facility

Knowledge Acquisition Facility

User Interface

 Obviously the knowledge to which a Knowledge Base system has access is no good to it, if it cannot use it to solve the problems in the application domain. Therefore the systems knowledge must be represented in a form which can be manipulated by the reasoning mechanisms of the Inference Engine.

 While the Knowledge Base, the IE and the User Interface are essential components, in many Knowledge Base systems there are also facilities to help in the acquisition of new knowledge. Teiresias, [DAVIS '76], which is used in association with MYCIN, [Shortliffe '76, Davis '76] is an example of such a system. It elicits high level information from the user which it converts into structured knowledge for its Knowledge Base. It also performs consistency checks on the updated knowledge base. The ability to acquire new knowledge is important since the amount of knowledge to which a system has access determines the range of problems which it can solve.

Applications of Knowledge Base systems

Knowledge Base systems have been applied to many diverse problem domains, such as the following. Diagnostic Aids such as MYCIN, [Shortliffe '76, Davis '76], which diagnoses bacterial blood infections and PUFF, [Kunz et al '78], which diagnose pulmonary disorders. MYCIN was a joint venture between Dept. of Computer Science and the Medical School of Stanford University. Much of the work took place in the 1970's. Mycin was designed to solve the problem of diagnosing and recommending treatments for meningitis and bacteremia, (blood infections).

 Aids to Design and Manufacture such as R1, [McDermott '82], which configures computers. Teaching Aids such as SCHOLAR [Carbonell '70] which gives Geography Tutorials and SOPHIE, [Brown et al '82], which teaches how to detect breakdown in electrical circuits. Problem Solving

 Recognition of forms, e.g. DENDRAL, [Buchanan and Feigenbaum '78, Lindsay et al '80], which recognizes the structures of chemical compounds. Robotics e.g. SHDRLU, [Winograd '73], which manipulates polygons in a restricted environment. Game playing systems such as Waterman's Poker Player, [Waterman '70], and

 Automatic theorem Provers such as AM, [Lenat '82]. [Hayes-Roth et al '83, Handbook A.I. '82, Waterman '86], describe some more categories than those mentioned above. These include Planning systems such as NOAH, [Sacerdoti '75] and MOLGEN, [Friedland '75] and Prediction systems such as Political Forecasting Systems, [Schrodt '86] based on the Holland Classifier, [Holland '86].

Rule-Based Expert Systems

Work with a set of facts describing the current world state a set of rules describing the expert knowledge inference mechanisms for combining facts and rules in reasoning

Architecture of Rule-Based XPS 1

Knowledge-Base / Rule-Base
stores expert knowledge as condition-actionrules (or: if-then- or premise-consequence-rules) objects or frame structures are often used to represent concepts in the domain of expertise, e.g. club in the golf domain.

Working Memory
stores initial facts and generated facts derived by the inference engine additional parameters like the degree of trust in the truth of a fact or a rule ( certainty factors) or probabilistic measurements can be added

Knowledge Engineering
Knowledge engineering is a general term for the processes involved in building expert systems: planning, knowledge acquisition, system building,system installation, system maintenance. In the following notes "KE" stands for knowledge engineer, and "DE" stands for domain expert.

Architecture of Rule-Based Systems

Inference Engine matches condition-part of rules against facts stored in Working Memory (pattern matching); rules with satisfied condition are active rules and are placed on the agenda; among the active rules on the agenda, one is selected (see conflict resolution, priorities of rules) as next rule for execution (firing) consequence of rule can add new facts to Working Memory, modify facts, retract facts, and more

Rule-Based Systems
- Example Grades Rules to determine grade 1. If study then get good_grade 2. If do not_study then get bad_grade 3. If sun_shines THEN go_out 4. If go_out then do not_study 5. If stay_home then study 6. If awful_weather then stay_home

Questions
Ask the following questions of the expert System Q1: If the weather is awful, do you get a good or bad grade? Q2: When do you get a good grade?

 forward reasoning rule chain given fact: awful_weather 6,5,1 backward reasoning hypothesis/goal: good_grade 1,5,6 Answer Question 1 Good Grade Exercise Answer question 2 with forward and backward chaining

Explaining
Note we presented a rule chain when we solved this problem. If we asked How do you know we get a good grade in awful weather we can say that By rule 6 if the weather is awful stay at home By rule 5 If stay at home then you will study And finally By rule 1 if you study you get a good grade

In other words
In order to explain how we arrive at a solution we list the chain of rules that were fired on rout to this conclusion. This is the basis of expert system explainers

Knowledge Acquisition
Obtaining knowledge for use in the knowledge base of an expert system.

Sources of knowledge:
Documents: textbooks, journal articles, technical reports, case histories, etc. This will almost never be sufficient to provide the knowledge base for a realworld expert system. The range of problems which a textbook examines and solves is always smaller than the range of problems that a human expert is master of.

Knowledge Analysis
Simultaneously with the knowledge acquisition process, a knowledge analysis process takes place. The KE uses the data from the knowledge acquisition sessions to build a good model of the expertise that the DE is using to solve problems in the domain. This may or not rely heavily on building a prototype see below.

Knowledge Elicitation
The most important branch of knowledge acquisition is knowledge elicitation - obtaining knowledge from a human expert (or human experts) for use in an expert system. Knowledge elicitation is difficult. This is the principle reason why expert systems have not become more widespread - the knowledge elicitation bottleneck. It is necessary to find out what the expert(s) know, and how they use their knowledge..

Human experts
Expert knowledge includes: domain-related facts & principles; modes of reasoning; reasoning strategies; explanations and justifications.

Knowledge elicitation and experts

The knowledge elicitation (and analysis) task involves: Finding at least one expert in the domain who: is willing to provide his/her knowledge; has the time to provide his/her knowledge; is able to provide his/her knowledge. Repeated interviews with the expert(s), plus task analysis, concept sorting, etc, etc.. Knowledge structuring: converting the raw data (taken from the expert) into intermediate representations, prior to building a working system.

Knowledge Elicitation continued

Building a model of the knowledge derived from the expert, for the expert to criticise. From then on, the development proceeds by stepwise refinement. One major obstacle to knowledge elicitation: experts cannot easily describe all they know about their subject. They do not necessarily have much insight into the methods they use to solve problems. Their knowledge is "compiled" (c.f. a compiled computer program fast & efficient, but unreadable).

Techniques used in Knowledge Elicitation

Various different forms of interview: Unstructured. A general discussion of the domain, designed to provide a list of topics and concepts. Structured. Concerned with a particular concept within the domain. Problem-solving. The expert is provided with a real-life problem, of a kind that they deal with during their working life, and asked to solve it. As they do so, they are required to describe each step, and their reasons for doing what they do. The transcript of their verbal account is called a protocol.

Think-aloud. As above, but the expert merely imagines that they are solving the problem presented to them, rather than actually doing it. Once again, they describe the steps involved in solving the problem. Dialogue. The expert interacts with a client, in the way that they would normally do during their normal work routine.

Review.
It is standard practice to tape record KE sessions. However, KEs should be aware of the costs this involves, in time and money. The KE and DE examine the record of on of the sessions described above, together.

More Methods
Sample lecture preparation. The expert prepares a lecture, and the KE analyses its content. Concept sorting ("card sort"). Questionnaires. Especially useful when the knowledge is to be elicited from several different experts. Repertory grid (particularly the "laddered grid" technique).

Computerised knowledge elicitation.

The state of the art in AI (especially NLP) is not sufficiently advanced to permit fully-automated knowledge elicitation.
However, 'knowledge elicitation workbenches', or 'knowledge engineering environments', are commercially available (e.g KEE, KnAcqTools); their principle use is to simplify the task of converting a protocol into frames, rules, etc., and inserting these structures into an expert system shell as soon as they are formulated.