Knowledge Base Systems

almondpitterpatterIA et Robotique

23 févr. 2014 (il y a 3 années et 5 mois)

80 vue(s)

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



Agenda

Knowledge Base


(rules)

Explanation

Facility

User Interface

Knowledge

Acquisition

Facility

Working Memory


(facts)


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



Agenda

Knowledge Base


(rules)

Explanation

Facility

User Interface

Knowledge

Acquisition

Facility

Working Memory


(facts)


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

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