1. CIS 488/588 Bruce R. Maxim UM-Dearborn
Rule-Based Systems
CIS 488/588
Bruce R. Maxim
UM-Dearborn
11/18/2018

2. Rule-Based Systems
Also known as “production systems” or “expert systems”
Rule-based systems are one of the most successful AI paradigms
Used for synthesis (construction) type systems
Also used for analysis (diagnostic or classification) type systems
11/18/2018

3. Rule Format Label Rn if condition1 condition2 … then action1 action2
11/18/2018

4. Weaknesses of Expert Systems
Require a lot of detailed knowledge
Restrict knowledge domain
Not all domain knowledge fits rule format
Expert consensus must exist
Knowledge acquisition is time consuming
Truth maintenance is hard to maintain
Forgetting bad facts is hard
11/18/2018

5. Generic System Components
Global Database
content of working memory (WM)
Production Rules
knowledge-base for the system
Inference Engine
rule interpreter and control subsystem
11/18/2018

6. Simple Rule-Based System
11/18/2018

7. Expert System Architecture
11/18/2018

8. Inference Engine Rulebase new rule Conflict Execute Match Resolution
new fact
Factbase
11/18/2018

9. Data Structure
A major concern for the rulebase is the data structure used for internal storage
If the rules are stored separately from the system in a declarative fashion they must be loaded at run-time and placed in some searchable data structure
For data driven programs efficient searching is essential and this is a function of the date structure used (lists, trees, hash tables, etc.)
11/18/2018

10. Table vs Graph
11/18/2018

11. Forward Chaining Procedure
Do until problem is solved or no antecedents match
Collect the rules whose antecedents are found in WM.
If more than one rule matches
use conflict resolution strategy to eliminate all but one
Do actions indicated in by rule “fired”
11/18/2018

12. Forward Chaining
11/18/2018

13. Synthesis Systems Used to build things Tend to use forward chaining
Often data driven
Often make use of breadth first search
Tend looks at all facts before proceeding
11/18/2018

14. Backward Chaining Given goal g as input
find the set of rules S that determine g
if a set of rules does not equal empty set then
loop
choose rule R
make R’s antecedent the new goal (ng)
if new goal is unknown then
backchain (ng)
else
apply rule R
until g is solved or S is equal to empty set
consult user
11/18/2018

15. Backward Chaining
11/18/2018

16. Analysis System
Commonly used for diagnostic problems or classification problems
Tend to use backward chaining
Often goal driven
Often depth-first search
Tend to focus on one hypothesis (path) at a time (easier for humans)
11/18/2018

17. Conflict Resolution Strategies
Physically order the rules
hard to add rules to these systems
Data ordering
arrange problem elements in priority queue
use rule dealing with highest priority elements
Specificity or Maximum Specificity
based on number of antecedents matching
choose the one with the most matches
11/18/2018

18. Conflict Resolution Strategies
Recency Ordering
Data (based on order facts added to WM)
Rules (based on rule firings)
Context Limiting
partition rulebase into disjoint subsets
doing this we can have subsets and we may also have preconditions
Randomly Selection
Fire All Application Rules
11/18/2018

19. Deductive Systems Defintion
the rules in an expert system can be matched using forward or backward chaining
Sometimes it is desirable to alternate the forward and backward chaining strategies in the same system
11/18/2018

20. Hybred Inference Strategy
repeat
let user enter facts into factbase (WM)
select a a goal G based on current problem state
call bchain(G) to establish G
Until problem is solved
11/18/2018

21. Inference Net R4 R2 R5 R1 R3 6 mon up MM risk lower discount Fed
expans R5
stock
6 mon
down R1
decreas
reserve
short
term R3
11/18/2018

22. Answering Questions
Most expert systems users insist on being able to request an explanation of how the ES reached its results
This is often accomplished using traces of the rule matching and firing order
The rules themselves can be mapped to an “and/or” type decision tree
11/18/2018

23. And/Or Tree Goal: Acquire TV Steal TV Buy TV and Earn Money Get Job
11/18/2018

24. Explanations
To answer a “how” question identify the immediate sub-goals for the goal in question and report them
To answer a “why” question identify the super goals for a given goal and report them
11/18/2018

25. Disadvantages Basic rule-based systems do not: Learn
Use multi-level reasoning
Use constraint exposing models
Look at problems from multiple perspectives
Know when to break their own rules
Make use of efficient matching strategies
11/18/2018

26. Extensions Rule-Based systems often interface with external systems
Standard declarative rules support sensors (inputs) as symbols and output (effectors) as function calls
Rules are tested against working memory using assertions (pre-conditions) to determine when they are eligible to fire (requires post processing)
11/18/2018

27. Combining Declarative and Procedural Approaches
11/18/2018

28. VP Expert Rules !RULES BLOCK RULE 1 IF Married = Yes AND Savings = Ok
AND Insurance = Yes
THEN Advice = Invest
BECAUSE "Rule 1 determines if married should invest";
RULE 3
IF Savings <> Ok
OR Insurance = No
THEN Advice = Do_Not_Invest CNF 80
BECAUSE "Rule 3 determines automatic 'not invest'";
11/18/2018

29. VP Expert Control Block
! ACTIONS BLOCK
ACTIONS
DISPLAY "Welcome to the Investment Advisor !!“
FIND Advice
DISPLAY "The best advice we have for you is to {#Advice}.“
FIND Type
SORT Type
DISPLAY "Your top two choices are:“
FOR X = 1 to 2
POP Type, One_type
DISPLAY “Investment strategy to consider is {#One_type}.“
END;
11/18/2018

30. VP Expert Statements ! STATEMENTS BLOCK
ASK Married: "Are you married ?";
CHOICES Married: Yes, No;
ASK Bank: "What is the size of your emergency fund ?";
ASK Investment: "Enter your confidence in at least two investments:";
CHOICES Investment: Stocks, Bonds, Money_Market, Futures;
PLURAL : Investment, Type;
! Declares Investment and Type as plural variables
11/18/2018

31. Knowledge Acquisition
RBS require extremely detailed domain-specific knowledge
Much of the rulebase content consists of “rules of thumb” used by human experts to solve specific problems
This takes a long time and skillful listening on the part of the knowledge engineer (knowledge acquisition bottleneck)
11/18/2018

32. Expert Systems First generation Second generation
Domain experts encoded knowledge as if..then rules in some programming language
Very brittle and hard to maintain
Second generation
Rulebase separated from program code and written in declarative form
More robust and a little easier to maintain
11/18/2018

33. RBS Advantages Simplicity Modularity Flexibility Applicability
Rule syntax is based on human reasoning
Modularity
Easy to add and subtract rules
Flexibility
Easy to add and process symbols in WM
Applicability
Many problems can be formulated as rules
11/18/2018

34. RBS Disadvantages Expressiveness Power Efficiency Suitability
Hard to predict RBS behavior from rules alone
Power
Rule behavior often restricted to syntax representation
Efficiency
Matching can be time consuming
Suitability
Rules don’t work for every problem domain
11/18/2018

35. RBS Game Development – 1
Usually one person is the programmer, knowledge engineer, and domain expert (better to be 3 separate people)
The knowledge-based system is implemented first and the rules come later in the game development cycle
Dividing the task in two (code writing and rule offering) makes it easier for one person to handle
11/18/2018

36. RBS Game Development – 2
Dividing the task provides demonstrates some of the advantages of second generation expert systems
Reusability (RBS module can be used in other programs)
Debugging (when errors occur WM contents can be captures and the offending rule easily identified and modified)
11/18/2018

37. RBS Efficiency
Hard-coding and compiling may be faster than interpretation for processing linear lists of rules
Declarative rules do not need to be organized in linear lists, but are limited to simple actions (e.g. setting symbol values)
Can hardcode problem independent facts in a small database and augment this by dynamic data structures as needed
11/18/2018

38. Suitable Problems
Make sure you have access to sufficient expert knowledge to capture in the rules
If your code has long strings of if statements, they could be encoded as declarative rules
RBS work bests when there a several (flexible) rule sequences can be used to reach a goal state
RBS work well to implement control strategies in deterministic, reactive environments
11/18/2018

39. Brutus First generation procedural expert system
Each action is expressed as a C++ if statement
Using steering behaviors to follow players or stop at their feet
11/18/2018

40. Wall Following Behavior
If no wall is present and not already following another wall then move forward
If wall in front then turn away from it
If wall on the side and not in front then move forward to follow the wall
If no wall is present and a wall was previously being followed then turn toward the side where the last wall was
11/18/2018

41. Note: context variable “following wall” used to distinguish between case 1 and 4.
11/18/2018

42. RBS Considerations
It will take longer to implement than approach used for Brutus or Marvin
The RBS approach has the potential for reuse in other parts of the game (e.g. motion)
Forward chaining approach will be used
Good for behavioral simulation in reactive systems
Rule action can be procedural does not need to be declarative (like in backward chaining)
Declarative conditions can be loaded from a file
11/18/2018

43. Rule Simplifications Keep number of rules used to a minimum
Assume rules listed in priority order
Later rules assume that earlier rule conditions are already true
Allow for multiple rule actions on a match rather than repeating matches for each action on at a time
11/18/2018

44. Working Memory XML is used to initialize FEAR modules Working memory
<Symbol name="sideWall” />
<Symbol name="following" value="false" ground="true" />  
</memory>
11/18/2018

45. Symbols There are two types of symbols
Native symbols refer to sensors or effectors outside the RBS (e.g. “sideWall” )
Internal symbols are used inside the RBS only (e.g. “following” )
This allows functional extensions to be handled indirectly
Native symbols are set automatically before interpreter cycle starts
11/18/2018

46. Rulebase -<rulebase> -<Rule> -<conditions>
<Symbol name="following" value="false" />
<Symbol name="frontWall" value="false" />
<Symbol name="sideWall" value="false" />
</conditions>
-<actions>
</actions>
</Rule>
<rulebase>
11/18/2018

47. Interface Must allow data to be passed to module at run-time
This mainly tells the systems the location of the native symbols and how to execute native actions
Run-time data is synchronized with static declarations
11/18/2018

48. Synchronization
Variables can be registered with the module by passing pointers (first parameter) along with their names (second parameter)
SetSensor(&SensorSidewall, “sideWall”);
Procedural actions are implemented as functors (classes that store functions as a means of implementing callback functions without virtual calls)
11/18/2018

49. Accessor Methods For Boolean values Adding Rules on the Fly
void Set(const string& symbol, const bool value);
bool Get(const string& symbol) const;
Adding Rules on the Fly
void AddCondittion(const string& symbol,
const bool value);
void SetAction(const string& action);
11/18/2018

50. Implementation
Reuses containers from the C++ standard template library to store the RB and WM
Rules are easily edited in the XML file
Interpreter processes the rules using their positional priorities
The C++ RBS module is available at
11/18/2018

51. Data Structures
Symbols are implemented as integers rather than strings
A map (similar to hash function) is used to do the translation
WM can be a simple array with integer symbols used as WM indices
Effectors and sensors can be stored in two containers associating integer symbols with native functions passed by the interface
11/18/2018

52. Interpreter - 1 CheckSensorsI( ) ApplyRules( )
Calls native functions to get symbols
Done before matching means each function only called once
ApplyRules( )
Rule antecedents are checked in order listed using short-circuited evaluation
Default values are overwritten when rule matches
Default values set if no rules match
11/18/2018

53. Interpreter - 2 CheckEffectors( ) Scans effector symbols in WM
Calls native functions for any true effector symbols
For control situations it is more efficient to check every effector symbol each iteration rather than on those for rule fires
11/18/2018

54. Working Memory
Assuming wall appears on one side only reduces number of symbols required
Symbol
Default
Initial
sideWall
(sensor)
frontWall
following
true
false
moveForwards
turnAway
turnTowards
11/18/2018

55. Rulebase Written in XML format mean
IF NOT following AND NOT frontWall AND NOT sideWAll
THEN following = false
IF frontWall
THEN turnAway = true AND moveForwards = false
IF NOT sideWall
THEN turnTowards = true AND moveForwards = false
Rule order says “look for wall” first so the 2nd and 3rd rules can assume the wall is found
Use of default values eliminate need for 4th rule
11/18/2018

56. Sensors and Effectors
Coded as member functions in Brain class and passed to RBS as function pointers along with a pointer back to the class
Sensors placed a 0 degrees and 45 degrees (true value returned it obstacle detected)
Moving average is computed from values returned to reduce jerkiness resulting from calling Move( ) and Turn( ) directly
11/18/2018

57. Evaluation Animat slows down near corners to avoid getting lost
Increasing length of whiskers (sensors) helps animat detect walls – but takes more time
If animat loses wall, it may go into an endless spin trying to find the wall (use of spin counter to trigger forward motion would help)
Has problems at the bottom of stairs
11/18/2018

58. Stalker
Uses a combination of simple rules driven by a RBS interpreter to follow walls
Capable of finding walls when lost to prevent aimless spinning motion
11/18/2018