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) Working Memory (facts) Agenda Explanation Facility Knowledge Acquisition Facility User Interface 11

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) Working Memory (facts) Agenda Explanation Facility Knowledge Acquisition Facility User Interface 16

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 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 23

Architecture of Rule-Based XPS 1 Knowledge-Base / Rule-Base stores expert knowledge as “condition-action-rules” (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 24

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 26

Rule-Based Systems - Example ‘Grades’ - Rules to determine ‘grade’ If study then get good_grade If do not_study then get bad_grade If sun_shines THEN go_out If go_out then do not_study If stay_home then study If awful_weather then stay_home 27

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 real-world 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.