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 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 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 antecedent-consequent 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 meta-rules 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 then ” Patterns are string constants If in wm then 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 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, don’t 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