CPE CSC 481 Knowledge-Based Systems Dr Franz J Kurfess

Course Overview ◆ CLIPS ◆ Introduction ◆ Knowledge ◆ Semantic Nets, Frames, Logic ◆ Reasoning ◆ with Uncertainty Probability, Bayesian Decision Making ◆ Expert ◆ and Inference Predicate Logic, Inference Methods, Resolution ◆ Reasoning ◆ Representation System Design ◆ Overview Concepts, Notation, Usage ◆ Pattern ◆ Matching Variables, Functions, Expressions, Constraints ◆ Expert System Implementation ◆ Salience, Rete Algorithm ◆ Expert System Examples ◆ Conclusions and Outlook ES Life Cycle © 2002 -2010 Franz J. Kurfess Expert System Design

Overview Implementation of Rule-Based Systems ◆ Motivation ◆ Rete ◆ Objectives ◆ ◆ Chapter ◆ ◆ Important Concepts Performance Aspects ◆ Pattern ◆ ◆ ◆ Introduction Matching Basic Idea Unification Pattern Matching in Rule. Based Systems © 2002 -2010 Franz J. Kurfess ◆ ◆ Overview Rete Network Assert and Retract Optimizations Improvements ◆ Rule ◆ ◆ ◆ Algorithm Formulation General vs. Specific Rules Simple vs. Complex Rules Loading and Saving Facts ◆ Important Concepts and Terms ◆ Chapter Summary Expert System Design

Motivation ◆ pattern matching and unification are powerful operations to determine the similarity and consistency of complex structures ◆ they are at the core of many rule-based and predicate logic mechanisms ◆ their application goes beyond rule-based systems ◆ study concepts and methods that are critical for the functionality and performance of rule-based systems ◆ pattern matching and the Rete algorithm ◆ use and formulation of rules © 2002 -2010 Franz J. Kurfess Expert System Design

Objectives ◆ comprehend systems ◆ ◆ the mechanics of pattern matching in rule-based basic concepts and techniques Rete algorithm ◆ understand the effects of matching and rule formulation on the performance of rule-based systems ◆ learn to write rule-based programs and implement systems in an efficient way ◆ analyze and evaluate the performance of rule-based programs and systems ◆ ◆ identify bottlenecks formulate and implement strategies for performance improvements © 2002 -2010 Franz J. Kurfess Expert System Design

Overview Implementation of Rule-Based Systems ◆ due to their more declarative nature, it can be difficult to evaluate and predict the performance of rule-based systems ◆ time to complete a task ◆ memory usage ◆ disk space usage ◆ pattern matching can be used to eliminate unsuitable rules and facts ◆ but it can also introduce substantial overhead © 2002 -2010 Franz J. Kurfess Expert System Design

Chapter Introduction ◆ Important ◆ entities Concepts with internal structure data structures, objects, components ◆ terms, sentences, graphs ◆ diagrams, images ◆ concepts, hierarchies ◆ ◆ Performance ◆ somewhat Aspects different from conventional programs less control over the runtime behavior ◆ pattern matching can do a lot of the work ◆ © 2002 -2010 Franz J. Kurfess Expert System Design

Pattern Matching ◆ determines if two or more complex entities (patterns) are compatible with each other ◆ patterns can be (almost) anything that has a structure pictures: mugshot vs. person ◆ drawings: diagrams of systems ◆ expressions: words, sentences of a language, strings ◆ ◆ graphs are often used as the underlying representation the structure of the graphs must be compatible ◆ usually either identical, or one is a sub-graph of the other ◆ the individual parts must be compatible ◆ nodes must have identical or compatible values ◆ ◆ variables are very valuable ◆ links must indicate compatible relationships ◆ compatibility may be dependent on the domain or task © 2002 -2010 Franz J. Kurfess [Giarratano & Riley 1998, Friedmann-Hill 2003, Gonzalez & Dankel, 2004] Expert System Design

Pattern Matching Example ◆ images ◆ Do both images refer to the same individual? ◆ Do they have other commonalities? ❖ test ? ? ? Bucky and Satchel likes Bucky likes to take advantage of Satchel Bucky likes fish © 2002 -2010 Franz J. Kurfess Bucky likes fish Expert System Design

Pattern Matching Example ◆ shapes ? ? ? ? ? © 2002 -2010 Franz

Pattern Matching Examples ◆ constants and variables “Hans” “Josef” “Franz” ? first_name last_name ©

Pattern Matching Examples ◆ terms ◆ composed of constants, variables, functions father(X) ? “Joseph” father(Y) father(X)) © 2002 -2010 Franz J. Kurfess mother(X) ? ? grandfather(X) Expert System Design

Applications of Pattern Matching ◆ search and retrieval ◆ precise ❖ matching strings, images, documents, objects ◆ similarity-based matching imprecise ❖ requires specification of a similarity measure ❖ often domain/application/task-specific ❖ © 2002 -2010 Franz J. Kurfess Expert System Design

Search and Retrieval ◆ strings, images, documents, objects ◆ precise matching ◆ the query and the result have to match perfectly the two can be identical ❖ all requirements specified in the query have to be met by the result ❖ ◆ similarity-based matching ◆ imprecise ❖ some aspects of the result are different from the query specification ❖ but not too different ◆ partial ❖ match not all requirements specified in the query are met ◆ requires ❖ specification of a similarity measure often domain/application/task-specific © 2002 -2010 Franz J. Kurfess Expert System Design

Face Recognition and Matching ◆ some cameras and photo management applications have “face recognition” capabilities ◆ identify areas in a photo that are likely to be a person’s face ❖ matching of an image area with a “face” prototype ◆ compare ❖ face candidates against a set of known faces matching of an image area against another image area to determine if they show the face of the same person © 2002 -2010 Franz J. Kurfess Expert System Design

Genetic Analysis ◆ comparison © 2002 -2010 Franz J. Kurfess of gene sequences Expert

Analysis of Chemical Compounds ◆ candidates are compared agains compounds with known properties ◆

Dating ◆ Web sites like Match. com use (more or less) sophisticated matching methods to identify potential mates ◆ some ❖ approaches are based on scientific research although it is not clear how much better they are than others © 2002 -2010 Franz J. Kurfess Expert System Design

Unification ◆ formal specification for finding substitutions that make logical expressions identical ◆ the unification algorithm takes two sentences and returns a unifier for them (if one exists) Unify(p, q) = θ if Subst(θ , p) = Subst(θ , q) ◆ if there is more than one such substitution, the most general unifier is returned ◆ used in logic programming, automated theorem proving ◆ possibly complex operation ◆ quadratic in the size of the expressions ◆ “occur check” sometimes omitted ❖ determines if a variable is contained in the term against which it is unified © 2002 -2010 Franz J. Kurfess Expert System Design

Informal Unification ◆ assume that there are two or more entities with an internal structure and properties ◆ all or some of them are willing to make adjustments to their structure or properties some of the properties may be unspecified (“don’t care”) ❖ structure may not be modifiable ❖ ◆ example: ◆ partners personal relationships involved are willing to change their properties behavior, appearance, values, beliefs, . . . ❖ some aspects are difficult to change ❖ © 2002 -2010 Franz J. Kurfess Expert System Design

Pattern Matching in Rule-Based Systems ◆ used to match rules with appropriate facts in working memory ◆ rules for which facts can be found are satisfied ◆ the combination of a rule with the facts that satisfy it is used to form activation records ❖ one of the activation records is selected for execution ❖ the respective rule “fires” © 2002 -2010 Franz J. Kurfess Expert System Design

Simplistic Rule-Based Pattern Matching ◆ go through the list of rules, and check the antecedent (LHS) of each rule against the facts in working memory ◆ create an activation record for each rule with a matching set of facts ◆ repeat after each rule firing ◆ very inefficient ◆ roughly (number of rules) * (number of facts)(number of patterns) ◆ the actual performance depends on the formulation of the rules and the contents of the working memory © 2002 -2010 Franz J. Kurfess Expert System Design

Rete Algorithm ◆ in most cases, the set of rules in a rule-based system is relatively constant ◆ the facts (contents of working memory) change frequently ◆ most of the contents of working memory, however, don’t change every time ◆ optimization ◆ ◆ of the matching algorithm remember previous results change only those matches that rely on facts that have changed ◆ the Rete algorithm performs an improved matching of rules and facts ◆ ◆ invented by Charles Forgy in the early 80 s basis for many rule-based expert system shells © 2002 -2010 Franz J. Kurfess [ Friedmann-Hill 2003, Giarratano & Riley 1998, Gonzalez & Dankel, 2004] Expert System Design

Rete Network ◆ the ◆ name comes from the latin word rete stands for net ◆ consists ◆ each node represents one or more tests on the LHS of a rule ◆ ◆ of a network of interconnected nodes input nodes are at the top, output nodes at the bottom pattern nodes have one input, and check the names of facts join nodes have two inputs, and combine facts terminal node at the bottom of the network represent individual rules ◆a rule is satisfied if there is a combination of facts that passes all the test nodes from the top to the output node at the bottom that represents the rule ◆ the Rete network effectively is the working memory for a rulebased system © 2002 -2010 Franz J. Kurfess Expert System Design

Rete Network Example 1 (deftemplate x (slot a)) (deftemplate y (slot b)) ? = x ? = ? v 1 (defrule example-1 (x (a ? v 1)) (y (b ? v 1)) ==> ) y ? v 1 Left. 0. a ? = Right. b ? v 1 = ? v 1 example-1 © 2002 -2010 Franz J. Kurfess Expert System Design

Rete Left and Right Memories ◆ left (alpha) memory ◆ ◆ right (beta) memory ◆ ◆ contains the left input of a join node contains the right input of a join node notation: Left. p. q ? = Right. r ◆ compare the contents of slot q in fact p from the left memory with slot r in the fact from the right memory ? = x ? = ? v 1 y ? v 1 Left. 0. a ? = Right. b ? v 1 = ? v 1 (deftemplate x (slot a)) (deftemplate y (slot b)) (defrule example-1 (x (a ? v 1)) (y (b ? v 1)) ==> ) © 2002 -2010 Franz J. Kurfess example-1 Expert System Design

Running the Network ◆ ◆ only facts x and y are considered all facts where x. a == y. b pass the join network ◆ ◆ all {x, y} tuples are fowarded to the next node compare the contents of slot q in fact p from the left memory with slot r in the fact from the right memory ? = x ? = ? v 1 y ? v 1 Left. 0. a ? = Right. b ? v 1 = ? v 1 (deftemplate x (slot a)) (deftemplate y (slot b)) (defrule example-1 (x (a ? v 1)) (y (b ? v 1)) ==> ) © 2002 -2010 Franz J. Kurfess example-1 Expert System Design

Rete Network Example 2 ◆ shares some facts with Example 1 (deftemplate x (slot a)) (deftemplate y (slot b)) (deftemplate z (slot c)) ? = x ? = ? v 2 y ? = z ? v 2 Left. 0. a ? = Right. b ? v 2 = ? v 2 (defrule example-2 (x (a ? v 2)) (y (b ? v 2)) (z) ==> ) © 2002 -2010 Franz J. Kurfess example-2 Expert System Design

Rete Network Example 2 with Assert ◆ additional fact asserted ? = (deftemplate x (slot a)) x ? = ? v 2 y ? = ? v 2 z 17 (deftemplate y (slot b)) (deftemplate z (slot c)) Left. 0. a ? = Right. b ? v 2 = ? v 2 (defrule example-2 (x (a ? v 2)) ? v 2 = 17 (y (b ? v 2)) (z) ==> ) example-2 (assert (z (c 17)) © 2002 -2010 Franz J. Kurfess Expert System Design

Assert and Retract with Rete ◆ ◆ ◆ asserting additional facts imposes some more constraints on the network retracting facts indicates that some previously computed activation records are not valid anymore, and should be discarded in addition to the actual facts, tags are sent through the networks ◆ ADD to add facts (i. e. for assert) ◆ REMOVE to remove facts (i. e. for retract) ◆ CLEAR to flush the network memories (i. e. for reset) ◆ UPDATE to populate the join nodes of newly added rules ❖ already existing join nodes can neglect these tokens © 2002 -2010 Franz J. Kurfess Expert System Design

Rete Network Optimization ◆ networks with shared facts can be combined ? = x ? = y ? = z (deftemplate x (slot a)) (deftemplate y (slot b)) (deftemplate z (slot c)) Left. 0. a ? = Right. b (defrule example-1 (x (a ? v 1)) (y (b ? v 1)) ==> ) (defrule example-2 (x (a ? v 2)) (y (b ? v 2)) (z) ==> ) © 2002 -2010 Franz J. Kurfess example-1 example-2 Expert System Design

Further Optimizations ◆ sophisticated data structures to optimize the network ◆ hash table to presort the tokens before running the join node tests ◆ fine-tuning ◆ frequently via parameters trade-off between memory usage and time © 2002 -2010 Franz J. Kurfess Expert System Design

Special Cases for Pattern Matching ◆ additional enhancements of the Rete network can be used to implement specific methods ◆ backward ❖ chaining requires a signal indicating to the network that a particular fact is needed ◆ not conditional element indicates the absence of a fact ❖ requires special join nodes and special fields in the tokens passing through the network ❖ ◆ test conditional element uses a special join node that ignores its right input ❖ the result of the function is passed on ❖ © 2002 -2010 Franz J. Kurfess Expert System Design

Exploring the Rete Network in Jess ◆ (watch ◆ diagnostic output when rules are compiled example-1: +1+1+1+2+t ❖ ❖ ❖ +1 one-input (pattern) node added to the Rete network +2 two-input (pattern) node added +t terminal node added ◆ (view) ◆ compilations) function graphical viewer of the Rete network in Jess ◆ (matches ◆ ◆ <rule-name>) function displays the contents of the left and right memories of the join nodes for a rule useful for examining unexpected rule behavior © 2002 -2010 Franz J. Kurfess Expert System Design

Rete Visualization © 2002 -2010 Franz J. Kurfess http: //upload. wikimedia. org/wikipedia/commons/9/92/Rete. JPG Expert

Rule Formulation ◆ Pattern Order ◆ General vs. Specific Rules ◆ Simple vs. Complex

Pattern Order ◆ since Rete saves information about rules and facts, it can be critical to order patterns in the right way ◆ otherwise a potentially huge number of partial matches can be generated © 2002 -2010 Franz J. Kurfess Expert System Design

Example Pattern Order (deffacts information (find-match a c e g) (item a) f 2 (item b) f 3 (item c) f 4 (item d) f 5 (item e) f 6 (item f) f 7 (item g)) f 8 (defrule match-1 (find-match ? x ? y ? z ? w) (item ? x) P 2 © 2002 -2010 Franz J. Kurfess f 1 (deffacts information (find-match a c e g) (item a) (item b) (item c) (item d) (item e) (item f) (item g)) (defrule match-2 (item ? x) (item ? y) (item ? z) (item ? w) (find-match ? x ? y ? z ? w) ==> (assert (found-match ? x ? y ? z ? w)) P 1 [Giarratano & Riley 1998] Expert System Design

Pattern Matches ◆ full matches P 1: f 1 P 2: f 2, f 3, f 4, f 5, f 6, f 7, f 8 P 3: f 2, f 3, f 4, f 5, f 6, f 7, f 8 P 4: f 2, f 3, f 4, f 5, f 6, f 7, f 8 P 5: f 2, f 3, f 4, f 5, f 6, f 7, f 8 ◆ partial matches P 1: [f 1] P 1 -2: [f 1, f 2] P 1 -3: [f 1, f 2, f 4] P 1 -4: [f 1, f 2, f 4, f 6] P 1 -5: [f 1, f 2, f 4, f 6, f 8] Total: 29 full, 5 partial matches © 2002 -2010 Franz J. Kurfess ◆ full matches P 1: f 2, f 3, f 4, f 5, f 6, f 7, f 8 P 2: f 2, f 3, f 4, f 5, f 6, f 7, f 8 P 3: f 2, f 3, f 4, f 5, f 6, f 7, f 8 P 4: f 2, f 3, f 4, f 5, f 6, f 7, f 8 P 5: f 1 ◆ partial matches P 1: [f 2, f 3, f 4, f 5, f 6, f 7, f 8] P 1 -2: [f 2, f 2], [f 2, f 3], [f 2, f 4], [f 2, f 5], [f 2, f 6], [f 2, f 7], [f 2, f 8], [f 3, f 2], [f 3, f 3], [f 3, f 4], [f 3, f 5], [f 3, f 6], [f 3, f 7], [f 3, f 8], . . . P 1 -3, P 1 -4: . . . P 1 -5: [f 2, f 4, f 6, f 8, f 1] Total: 29 full, 2801 partial matches Expert System Design

Adding another Fact ◆ what is the effect on the two cases if another fact (item h) is added? ◆ no significant changes for match-1 ◆ in particular, no additional partial matches ◆ major changes for match-2 ◆ another 1880 partial matches © 2002 -2010 Franz J. Kurfess Expert System Design

Guidelines for Pattern Matches ◆ try to formulate your rule such that the number of matches is low ◆ full ◆ try and partial matches to limit the number of old partial matches ◆ removing those also is time-consuming ◆ in general, the state of the system should be reasonably stable ◆ matches ◆ assertion, retraction, modification of facts © 2002 -2010 Franz J. Kurfess Expert System Design

Guidelines for Pattern Ordering ◆ most specific patterns first ◆ smallest number of matching facts ◆ largest number of variable bindings to constrain other facts ◆ patterns matching volatile facts go last ◆ facts that are changing frequently should be used by patterns late in the LHS ◆ smallest number of changes in partial matches ◆ may cause a dilemma with the above guideline ◆ patterns matching the fewest facts first ◆ reduces the number of partial matches © 2002 -2010 Franz J. Kurfess Expert System Design

Multifield Variables ◆ multifield wildcards and multifield variables are very powerful, but possible very inefficient ◆ should only be used when needed ◆ limit their number in a single slot of a pattern © 2002 -2010 Franz J. Kurfess Expert System Design

Test Conditional Element ◆ the test conditional element should be placed as close to the top of the rule as possible ◆ reduces the number of partial matches ◆ evaluation of expressions during pattern matching is usually more efficient © 2002 -2010 Franz J. Kurfess Expert System Design

Built-In Pattern Matching Constraints ◆ the built-in constraints are always more efficient than the equivalent expression ◆ not so good: (defrule primary-color ? x&: (or (eq ? x red) (eq ? x green) (eq ? x blue) ==> (assert (primary-color ? x))) ◆ better: (defrule primary-color ? x&red|green|blue) ==> (assert (primary-color ? x))) © 2002 -2010 Franz J. Kurfess Expert System Design

General vs. Specific Rules ◆ some knowledge can be expressed through many specific, or a few general rules ◆ specific rules generate a top-heavy Rete network with many pattern nodes and fewer join nodes ◆ general rules offer better opportunities for sharing pattern and join nodes ◆ it usually is easier to write an inefficient general rule than an inefficient specific rule © 2002 -2010 Franz J. Kurfess Expert System Design

Simple vs. Complex Rules ◆ simple rules are sometimes elegant, but not necessarily efficient ◆ storing ❖ temporary facts can be very helpful especially in recursive or repetitive programs © 2002 -2010 Franz J. Kurfess Expert System Design

Loading and Saving Facts ◆ facts can be kept in a file, and loaded into memory when needed ◆ (load-facts) and (save-facts) functions ◆ may lead to visibility or scoping problems if the respective deftemplates are not contained in the current module © 2002 -2010 Franz J. Kurfess Expert System Design

Important Concepts and Terms ◆ ◆ ◆ ◆ agenda assert backward chaining constant fact expert system (ES) expert system shell forward chaining join node knowledge base knowledge-based system left (alpha) memory matches matching © 2002 -2010 Franz J. Kurfess ◆ ◆ ◆ ◆ pattern matching pattern node RETE algorithm retract right (beta) memory rule substitution term test conditional element unification variable view working memory Expert System Design

Summary ES Implementation ◆ for rule-based systems, an efficient method for pattern matching between the rule antecedents and suitable facts is very critical ◆ matching every rule against all possible facts repeatedly is very inefficient ◆ the ◆ ◆ Rete algorithm is used in many expert system shells it constructs a network from the facts and rules in the knowledge base since certain aspects of the knowledge base are quite static, repeated matching operations can be avoided ◆a few strategies can be used by programmers to achieve better performance ◆ ◆ most specific patterns first, patterns with volatile facts last careful use of multifield variables, general rules use of the test conditional element, built-in pattern constraints loading and saving of facts © 2002 -2010 Franz J. Kurfess Expert System Design