0% found this document useful (0 votes)
61 views29 pages

Lecture 9

This document describes an expert system and knowledge-based systems. It discusses how knowledge-based systems encode task-specific knowledge separately, allowing direct access to that knowledge. This separate encoding enables automatic generation of explanations, debugging, program maintenance, and modification of the system. The main issues are representing knowledge and structuring knowledge to make problems easier to solve. Pattern-directed inference systems are introduced as a class of rule-based systems. The components, knowledge representation as chunks, and recognize-act cycle of such systems are described.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
61 views29 pages

Lecture 9

This document describes an expert system and knowledge-based systems. It discusses how knowledge-based systems encode task-specific knowledge separately, allowing direct access to that knowledge. This separate encoding enables automatic generation of explanations, debugging, program maintenance, and modification of the system. The main issues are representing knowledge and structuring knowledge to make problems easier to solve. Pattern-directed inference systems are introduced as a class of rule-based systems. The components, knowledge representation as chunks, and recognize-act cycle of such systems are described.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 29

Expert System

Human expert level performance


Limited application area
Large component of task specific
knowledge
Knowledge based system
Task specific knowledge is separate, identifiable
part of the program

Access to knowledge
Separate, identifiable task specific knowledge
allows direct access to that knowledge

Themes in Knowledge Based


Systems
Direct access to encoded knowledge useful
for
Automatic generation of explanation
Debugging
Program maintenance
Modification
Extension

Main issues
Representing knowledge
Structuring knowledge to make problems easier to solve

Using knowledge explicitly in a computer program

Pattern Directed Inference


Systems (PDIS)
Rule based systems belong to more
general class of PDIS
Basic operation
Look for interesting situations which take the
form of patterns in input or memory
Respond by activating appropriate pieces of
code to
Modify memory
Cause external action
Activate a device
Output information

Components of a PDIS
Knowledge base
Set of structures called pattern-directed
modules (PDMs)

Working memory
One or more data structures in which
PDIS dynamic memory is stored

Interpreter
Executive program which controls the
selection and activation of PDMs

Chunks of Knowledge
PDMs are structurally independent
Each module has some intrinsic meaning to
the domain expert, i.e., is a chunk of
knowledge
PDMs are activated by patterns of data in
working memory
Why chunk knowledge
Facilitate incremental expansion of the knowledge
base
Permit system to trace and explain its behavior in
a simple and effective way
Facilitate isolation of effective problem solving
knowledge

Chunks of Knowledge
Having knowledge modules helps the
programmer understand what the system knows
Knowledge can be added in small meaningful chunks

Trace information can be provided by keeping a


history of
Which modules have been invoked
What specific elements of working memory caused
their invocation

Explanation can be produced dynamically by


telling user what PDM is currently invoked

Chunks of Knowledge
To find the source of a systems problem solving
power
Perform experiments in which various PDMs are
Modified, deleted, traced

PDMs have to know relevant features and


combinations of features of all possible situations
that might occur
Every detail of every possibility not necessary
E.g., a grammar does not have to specify all possible sentences

Human experts make mistakes when they do not take


account of or are unaware of relevant features of a situation
Could invalidate conclusions reached using other features

Finding the relevant features and combinations of features


of a problem is the hard part

Rule Based Systems


Each PDM is an antecedentconsequent pair called a rule
Distinguishing feature of rules is that
there is a clear separation of
Data examination
Searching for significant patterns in the data
(antecedent)

Data modification (consequent)

Rule Based Systems


Separation of examination and
modification of data makes it easier to
Debug rules already in the knowledge base
Add new rules to the knowledge base

Debugging
Find the rule where the error occurred
Determine whether error occurred because
A rule fired when not supposed to
Modify the antecedent

Action taken was inappropriate


Modify the consequent

Rule Based System


Adding New Rules
Define conditions for taking action
Define the antecedent

Define the action to be taken


Define the consequent

Data examination
Comparing the patterns in the antecedent with the
elements in working memory
Antecedent patterns can be
Simple strings, complex graphs
Arbitrary pieces of code which can inspect WMEs

Working memory might be implemented as


Simple lists, trees, etc.

Recognize Act Cycle


Overall activity of a rule based
system can be thought of as a series
of repetitions of the recognize-act
cycle
Represents the overall control
scheme of system and is managed
by the interpreter

Recognize Act Cycle


Cycle consists of four steps
Selection
Process of deciding what subset of rules and
data elements should be considered during the
next cycle

Matching
Searching selected rules and comparing their
antecedent patterns against selected data
Very time consuming
Careful selection can improve overall efficiency and
knowledge base organization

Recognize Act Cycle


Scheduling
Decide which of rules whose antecedents have been
matched should be fired on current cycle
Several rules might have satisfied antecedents
simultaneously because of
Ambiguity or error in data
Incomplete or erroneous rule antecedents
Use of redundant methods

Scheduling mechanism may be


Implicit
Explicitly implemented by programmer as a set of metarules or procedures

Execution
Fire the rule chosen by the scheduler
Execute the action specified in the consequent

Example Rule Based System


Data are strings
it is going to rain today

Rules have the form


if <string1> then <string>
Patterns are string constants
If <string1> in wm then <string2> is added to wm
Example
If barometric pressure is falling
Then it is going to rain today

Selection
All rules and data elements applicable at all times

Example Rule Based System


Scheduling
Rules are in ordered list
Patterns checked against wm in order
NOTE: A pattern in the antecedent of a rule can be
satisfied only once by a given data element
Otherwise system would never halt

First rule to have conditions satisfied (i.e., patterns


matched) will be fired
After rule is fired, go back to top of list and start
again
Continue until no more rules with satisfied
antecedents
Display contents of wm and then halt

Example Rule Based System


Sample knowledge base
IF
barometric pressure is falling
THEN it is going to raid today
IF
it is going to rain today
THEN you should take a rain coat to
work

Sample Run
Add the data element barometric pressure is
falling to wm from some external source and start
the interpreter
The interpreter notices that the condition of Rule
#1 is satisfied
barometric pressure is falling is present in wm

Action specified by Rule #1 is taken


it is going to rain today is added to wm

Cycle begins again


Antecedent of Rule #1 is checked and no match is
found
barometric pressure is falling is present in wm but was
already used once to satisfy this rule

Sample Run
Interpreter notices that condition of Rule #2
is satisfied
it is going to rain today is in wm

Action taken by Rule #2 is taken


you should take a rain coat to work is added to
wm

Interpreter realizes that no more rules have


their conditions satisfied so
Displays contents of wm to user and halts

This simple interpreter is an example of a


forward chaining OR data driven interpreter.

Automatically Generated
Explanation
Suppose we allow commands of the form
HOW <string>

The command HOW you should take a rain coat to


work might result in:
I was told that barometric pressure is falling
I used rule #1, if barometric pressure is falling then it is
going to rain today, to conclude that it is going to rain today
I used rule #2, if it is going to rain today then you should
take a rain coat to work, to conclude that you should take a
rain coat to work

The fact that the rules are modular, meaningful


chunks of knowledge helps make it possible to
generate this type of understandable explanation
automatically

A Modified Interpreter
Basic mode of operation is to prove a
given premise
Premise is represented by some string
Premise is true if element is in wm

Proving a premise is equivalent to


determining whether there is some way
that element can be placed in wm
An element can be placed in wm
From some external source (e.g., user input)
As the result of the action of a rule

A Modified Interpreter
Given some initial premise to prove, the
interpreter will perform the following actions:
Check to see if premise is already in wm
If so, say premise is true and return

Check to see if there are any rules in KB


whose action would add premise to wm
Place rule pointer at next position
If just beginning, place pointer at the first rule
Otherwise, advance pointer to the next rule in the list

Take the first rule, starting with the rule being


pointed to by the rule pointer, satisfying this
requirement and move the rule pointer to it

A Modified Interpreter
If no rules satisfy requirement then:
If the premise is the original premise, then tell the user that
the premise is false and return
Else, ask the user:
If the user answers true, then add element to wm
If the user answers false, dont
Return

Else, for the rule being pointed to, call the interpreter
recursively on each pattern in the antecedent
Each pattern in the antecedent is passed to the interpreter as
a premise to be proved in order of appearance
If all premises have been determined to be true
Fire the rule
If the element added to wm as a result of the rule firing is the
original premise, then inform the user that the premise is proven
Return

Else, try to find the next relevant rule and repeat the process

Sample Run
Start with an empty wm
Give the premise you should take a rain
coat to work to the interpreter to be proved
Recursion Level 0:
Interpreter checks to see if the element is
already in wm and notices that it is not
Places the rule pointer at Rule #1
Starting with Rule #1 it checks to see which
rule can conclude the given premise

Sample Run
Discovers that Rule #2 can conclude the
given premise and moves the poniter there
Interpreter called recursively with the
premise it is going to rain today
Recursion Level 1:
Interpreter checks to see if element it is
going to rain today is already in wm and
notices that it is not
Places pointer at Rule #1
Starting with Rule #1 checks to see which
rule can conclude the given premise

Sample Run
Discovers that Rule #1 can conclude the
given premise and leaves the pointer there
Interpreter called recursively with the
premise barometric pressure is falling
Recursion Level 2
Interpreter checks to see if element
barometric pressure is falling is already
in wm and notices that it is not
Places pointer at Rule #1
Starting with Rule #1 checks to see which
rule can conclude the given premise

Sample Run
Discovers that no rule can conclude the given premise
Since premise is not original (i.e., recursion level is not
0), interpreter asks the user:
Is it true that barometric pressure is falling?

The user answers true


The premise barometric pressure is falling is added
to wm
Return to Recursion Level 1
Since barometric pressure is falling has been found
to be true, fires Rule #1
Adds it is going to rain today to wm

Return to Recursion Level 0

Sample Run
Recursion Level 0
Since it is going to rain is found to be true,
fires Rule #2
you should take a rain coat to work is added to
wm

Since element just added to wm represents


original premise, the interpreter prints:
It is true that you should take a rain coat to work

This simple interpreter is an example of a


backward chaining interpreter

Rule Based Programming


Knowledge in a static KB is represented at a fairly
high level
High enough so that a non-programmer can understand it
Structured enough so that a machine can understand it

The same knowledge is used in two different ways


by two different interpreters
Different interpreters can result in qualitatively different
behaviors during program execution

The programmer did not tell the interpreter how to


apply the knowledge provided
Knowledge is provided by the programmer in a
declarative form
The interpreter takes care of the rest

Rule Based Programming


The same form of rules can be used to:
Write a program to perform a specific task
Given A it performs B

Model a system
If the system is observed to do B when A occurs,
this is modeled by the rule if A then B

Represent judgemental knowledge and apply it


If A implies B and A is true, then assume B is true

You might also like