Expert System

Human expert level performanceLimited application areaLarge component of task specific knowledgeKnowledge based system

Task specific knowledge is separate, identifiable part of the program

Access to knowledgeSeparate, 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 explanationDebuggingProgram maintenance

ModificationExtension

Main issuesRepresenting 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 PDISBasic operation

Look for interesting situations which take the form of patterns in input or memoryRespond by activating appropriate pieces of code to

Modify memoryCause external action

Activate a deviceOutput information

Components of a PDIS

Knowledge baseSet of structures called pattern-directed modules (PDMs)

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

InterpreterExecutive program which controls the selection and activation of PDMs

Chunks of Knowledge

PDMs are structurally independentEach module has some intrinsic meaning to the domain expert, i.e., is a “chunk” of knowledgePDMs are activated by patterns of data in working memoryWhy chunk knowledge

Facilitate incremental expansion of the knowledge basePermit system to trace and explain its behavior in a simple and effective wayFacilitate 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 invokedWhat 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 system’s 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 necessaryE.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 featuresFinding the relevant features and combinations of features of a problem is the hard part

Rule Based Systems

Each PDM is an antecedent-consequent pair called a ruleDistinguishing 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 baseAdd new rules to the knowledge base

DebuggingFind the rule where the error occurredDetermine whether error occurred because

A rule fired when not supposed to Modify the antecedent

Action taken was inappropriateModify the consequent

Rule Based System

Adding New RulesDefine conditions for taking action

Define the antecedentDefine the action to be taken

Define the consequent

Data examinationComparing the patterns in the antecedent with the elements in working memoryAntecedent patterns can be

Simple strings, complex graphsArbitrary pieces of code which can inspect WMEs

Working memory might be implemented asSimple 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 cycleRepresents the overall control scheme of system and is managed by the interpreter

Recognize Act Cycle

Cycle consists of four stepsSelection

Process of deciding what subset of rules and data elements should be considered during the next cycle

MatchingSearching selected rules and comparing their antecedent patterns against selected data

Very time consumingCareful selection can improve overall efficiency and knowledge base organization

Recognize Act Cycle

SchedulingDecide 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 dataIncomplete or erroneous rule antecedentsUse of redundant methods

Scheduling mechanism may beImplicitExplicitly implemented by programmer as a set of meta-rules or procedures

ExecutionFire 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 constantsIf <string1> in wm then <string2> is added to wmExample

If “barometric pressure is falling”Then “it is going to rain today”

SelectionAll rules and data elements applicable at all times

Example Rule Based System

SchedulingRules are in ordered listPatterns 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 firedAfter rule is fired, go back to top of list and start againContinue until no more rules with satisfied antecedents

Display contents of wm and then halt

Example Rule Based System

Sample knowledge baseIF ”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 interpreterThe 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 againAntecedent 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 formHOW <string>

The command HOW ”you should take a rain coat to work” might result in:

I was told that barometric pressure is fallingI used rule #1, if barometric pressure is falling then it is going to rain today, to conclude that it is going to rain todayI 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 stringPremise 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 wmAn 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 returnCheck to see if there are any rules in KB whose action would add premise to wm

Place rule pointer at next positionIf just beginning, place pointer at the first ruleOtherwise, 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 returnElse, ask the user:

If the user answers true, then add element to wmIf the user answers false, don’tReturn

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 appearanceIf all premises have been determined to be true

Fire the ruleIf the element added to wm as a result of the rule firing is the original premise, then inform the user that the premise is provenReturn

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

Sample Run

Start with an empty wmGive the premise ”you should take a rain coat to work” to the interpreter to be provedRecursion Level 0:Interpreter checks to see if the element is already in wm and notices that it is notPlaces the rule pointer at Rule #1Starting 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 thereInterpreter 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 notPlaces pointer at Rule #1Starting 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 thereInterpreter called recursively with the premise ”barometric pressure is falling”Recursion Level 2Interpreter checks to see if element ”barometric pressure is falling” is already in wm and notices that it is notPlaces pointer at Rule #1Starting with Rule #1 checks to see which rule can conclude the given premise

Sample Run …

Discovers that no rule can conclude the given premiseSince 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 trueThe premise ”barometric pressure is falling” is added to wmReturn to Recursion Level 1Since ”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 0Since ”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 itStructured 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 formThe 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 systemIf 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 itIf A implies B and A is true, then assume B is true