1 / 26

Notes for CS3310 Artificial Intelligence Part 6: Control structures and expert systems

Notes for CS3310 Artificial Intelligence Part 6: Control structures and expert systems. Prof. Neil C. Rowe Naval Postgraduate School Version of January 2009. Control structures for rule-based systems. = your policy about what to do next at any time; or

aleta
Download Presentation

Notes for CS3310 Artificial Intelligence Part 6: Control structures and expert systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Notes for CS3310 Artificial IntelligencePart 6: Control structures and expert systems • Prof. Neil C. Rowe Naval Postgraduate School Version of January 2009

  2. Control structures for rule-based systems • = your policy about what to do next at any time; or • = different procedural interpretations of the rules. • Prolog's usual control structure is "backward chaining" or "goal-directed reasoning", reasoning from query to data. • But there are other control structures. • Modus ponens: Given A is true and A implies B, conclude B is true. • Modus ponens can be used as the basis of a control structure, what is called "forward chaining" or "data-directed reasoning". • CLIPS, JESS, and SOAR are examples of forward-chaining systems. • There are also hybrids of backward and forward chaining.

  3. Rule-cycle hybrid chaining • Finds conclusions that follow by modus ponens from a set of facts. • Requires: a set of facts and a set of rules that could work in backward chaining if called with arguments all unbound. • 1. Apply subroutine "one-cycle" to the list of all rules without negations • 2. Apply "one-cycle" to the list of all rules. • Subroutine "one-cycle": • 1. Take the rules in order (one "cycle"): • (a) Find every way to get the rule to succeed by matching to the current set of facts (taking facts in order). Backtrack to ensure you try all possible bindings. Execute arithmetic and list-processing expressions as subroutine calls. • (b) Add each new fact you prove at the bottom of the set of facts. • 2. If no new facts were proved from any rule, stop. Else go to step 1.

  4. Example rule-based system without variables • m :- b, c, r. • u :- a, \+ e. • r :- s, b. • s :- c. • a. • b. • c.

  5. Example rule-based system with variables • c(X) :- f(X). • goal2(X) :- c(X), d(Y). • f(X,Y) :- h(X), d(Y), g(X). • b :- \+ e. • goal1 :- \+ c(X). • a(X) :- b, c(X). • c(X) :- g(X). • d(7). • g(3). • g(5).

  6. Problems with negations in forward and hybrid chaining • a :- \+ c. • c :- \+ d. • Assume no "d" facts. If you follow the forward or hybrid chaining algorithm with the above, you will prove "a", then "c". But: • c :- \+ d. • a :- \+ c. • will prove only "c". That is correct! • The problem: a negation can be evaluated incorrectly if: • (1) its argument is provable; and • (2) its argument is proved only after you evaluate the negation.

  7. 3 solutions to evaluating negations • 1. Don't use any negations in your program: Define certain predicates to be opposites of certain other predicates, and have facts for the new predicates. This can require many more facts, plus changes to rules. • 2. Evaluate the negations in some order, not necessarily the order in which they occur in rules, in which no negation is evaluated until all ways to prove its argument have been tried. This isn't always possible, as with recursive rules. • 3. Use negations, but never on something that appears on a left side. To ensure this, expand and rewrite negation expressions as necessary, using DeMorgan's Laws. But: this only can be done in Prolog when no local variables are created inside that negation. See next page for examples.

  8. Example 1: a :- b, \+ c. c :- d, e. Substitute "c" definition in first rule: a :- b, (\+ d; \+ e). Then rewrite as two equivalent rules: a :- b, \+ d. a :- b, \+ e. Keep the "c" rule too if needed elsewhere. Example 2: a :- b, \+ c. c :- d, \+ e. c :- f. e :- g, h. a :- b, \+ c. c :- d, \+ g. c :- d, \+ h. c :- f. a :- b, \+ (d, \+ g), \+ (d, \+ h), \+ f. a :- b, \+ d, \+ d, \+ f. a :- b, g, \+ d, \+ f. a :- b, \+ d, h, \+ f. a :- b, g, h, \+ f. Using DeMorgan's Laws to avoid negation problems

  9. Building of expert systems, "knowledge engineering” • Rule-based systems are often good for initial development of “expert systems”. • Expert systems try to duplicate human expertise. • Building them requires an expert or experts and a "knowledge engineer". • Later the rules can be “compiled” into a more efficient form. • It’s best to first define terms with the expert, then define rules. • The knowledge engineer should check for errors like missing definitions, inconsistent terminology, and inconsistent rule patterns. • Expect that development will require several cycles of writing rules, generating output, and showing output to the expert. • Automatic explanation facilities are very helpful (explaining why the system gives particular answers or not).

  10. Implementing rule-based expert systems • Use codes to represent questions. • Implement virtual facts by a user-input subroutine. • Cache user answers to questions (in Prolog, with asserta). • Identify appropriate top-level conclusions. • Use intermediate predicates to chunk knowledge. • Hash facts to find relevant rules quickly.

  11. Diagnosis of malfunctions of simple appliances • diagnosis('Fuse blown') :- power_problem, askif(lights_out). • diagnosis('Fuse blown') :- power_problem, askif(hear(pop)). • diagnosis('Break in cord') :- power_problem, askif(cord_frayed). • diagnosis('Short in cord') :- diagnosis('Fuse blown'), askif(cord_frayed). • diagnosis('Device not turned on') :- power_problem, klutz_user, askif(has('an on-off switch or control')), askifnot(device_on). • diagnosis('Cord not in socket properly') :- power_problem, klutz_user, askif(just_plugged), askifnot(in_socket). • diagnosis('Foreign matter caught on heating element') :- heating_element, not(power_problem), askif(smell_smoke). • diagnosis('Appliance wet--dry it out and try again') :- power_problem, klutz_user, askif(liquids). • diagnosis('Controls adjusted improperly') :- klutz_user, askif(has('knobs or switches')).

  12. Appliance program, page 2 • diagnosis('Kick it, then try it again') :- mechanical_problem. • diagnosis('Throw it out and get a new one'). • /* Definitions of intermediate predicates */ • power_problem :- askif(device_dead). • power_problem :- askif(has('knobs or switches')), askifnot(knobs_do_something). • power_problem :- askif(smell_smoke), \+ heating_element. • klutz_user :- askifnot(handyperson). • klutz_user :- askifnot(familiar_appliance). • mechanical_problem :- askif(hear('wierd noise')), askif(has('moving parts')). • heating_element :- askif(heats). • heating_element :- askif(powerful). • questioncode(device_dead, 'Does the device refuse to do anything'). • questioncode(knobs_do_something, 'Does changing the switch positions or turning the knobs change anything').

  13. Appliance diagnosis program, page 3 • questioncode(lights_out, 'Do all the lights in the house seem to be off'). • questioncode(cord_frayed, 'Does the outer covering of the cord appear to be coming apart'). • questioncode(handyperson,'Are you good at fixing things'). • questioncode(familiar_appliance, 'Are you familiar with how this appliance works'). • questioncode(device_on,'Is the ON/OFF switch set to ON'). • questioncode(just_plugged, 'Did you just plug the appliance in'). • questioncode(in_socket, 'Is the cord firmly plugged into the socket'). • questioncode(smell_smoke,'Do you smell smoke'). • questioncode(liquids,'Have any liquids spilled on the appliance just now'). • questioncode(heats,'Does the appliance heat things'). • questioncode(powerful,'Does the appliance require a lot of power'). • questioncode(has(X),X) :- write('Does the appliance have '). • questioncode(hear(X),X) :- write('Did you hear a ').

  14. The spectrum of inference methods flexible and uncompiled Mathematical modeling Predicate-calculus inference Rule-based systems logical Heuristic search numeric Decision graphs Neural networks Case-based reasoning Signatures rigid and compiled

  15. Standard algorithms: --Backward chaining: what Prolog does automatically --Forward chaining: reasoning by modus ponens --Rule-cycle hybrid: forward chaining on rules in a cycle, backtracking within rules Variations on the algorithms : --Virtual facts: prompt user for a fact only when needed --Caching of facts: add time-consuming conclusions as facts to the database (in Prolog, "asserta" does this), a form of learning from experience --Partitioning of rules: modularity of objects (in Prolog, "consult" loads files dynamically) "Compiled" algorithms (fast but inflexible): --Inference networks (and-or-not graphs): discrete neural nets --Decision graphs: asking yes/no questions in a hierarchy --Signatures: hash tables implementing decision trees --Parallelism: partition, AND, OR, and variable-matching --Meta-rules: generalized control Control structures for rule-based systems

  16. Inference networks ("and-or-not graphs") • Example rules: • a :- b, c. f :- b, \+ c. • c :- d. c :- \+ e. • You can represent these with "and" gates, "or" gates, and inverters, and create a combinatorial-logic integrated circuit that corresponds to the rules. • "and" gate: "or" gate: inverter: a b c d f e

  17. Decision graphs • Ask questions whose answers must be "yes" or "no” about the facts. Continue until you establish all applicable conclusions. • A graph can summarize the situations. Branches can converge after diverging, so in general it's a decision graph, not a tree. “b” true? no yes “d” true? “d” true? no yes no “e” true? yes yes conclude “c” conclude “a” and “c” no “e” true? no conclude “f” yes stop

  18. Decision graph example • Given these rules, construct a decision graph that asks first about “fever” and “coughing”. • virus :- cold, \+ severe. • bacterium :- cold, severe. • cold :- fever, coughing. • cold :- fever, sneezing. • cold :- coughing, sneezing, red_eyes.

  19. Rule-based systems versus compiled graphs • Advantages of rules: • 1. Very modular: you can add and remove rules without changing other rules. • 2. Easy to understand since rules are like how people think. • 3. Easy to debug since what program is doing can usually be explained declaratively. • Advantages of inference networks and decision graphs • 1. Often much faster than rule-based systems. • 2. Can be put in VLSI chips or very simple computers • 3. Good for partitioned rule-based systems. • Disadvantages of inference networks and decision graphs • 1. Variables are difficult to handle. • 2. Modification is difficult once built. • 3. Explaining what they're doing is hard. • 4. Optimal decision lattices require work to build.

  20. Signatures • A way to make decision trees even faster. Works best when most questions must be asked in any circumstance; important for fast-response systems like intrusion-detection systems and object recognition by robots. • 1. Make a list of all N possible questions and number them. • 2. For each leaf node of the decision tree: • a. Make a list of questions answered positively along the path here, and a list of the those answered negatively. • b. Hash (apply a complicated deterministic function to) this vector, store at that location the conclusions at the leaf node. • 3. When a new situation is encountered: • a. Make list of all question answers for this situation. • b. Find every hash entry corresponding to every subset of the question answers. (Shortcuts may eliminate some subsets.) • Signatures are a good explanation for human behavior in time-critical applications like firefighting (as per G. Klein).

  21. Possible parallelisms in rule-based systems • Assume you have several processors and a shared memory to hold all facts. You can do 4 kinds of parallel processing: • 1. Data parallelism: Make copies of rules, apply each set to different data. Good for "information filtering"; good for agent-based simulation where each copy is an agent. (Google does huge amounts of this.) • 2. Partition parallelism: Divide the rules into groups, execute each group simultaneously. Good for forward and hybrid chaining on some "partionable" rule-based systems. Often uses a “blackboard” or global set of inferred facts. • 3. Or-parallelism: For a set of rules with the same left side, execute each rule on a different processor. • 4. And-parallelism: For a rule right side of "and"ed expressions, execute each expression on a different processor. (This is harder to do than or-parallelism because of side effects of variable binding.)

  22. Example (automatic aircraft fuel management) • Consider a military aircraft that has redundant systems (extra fuel tanks, extra engines, extra control wiring). For survivability it must automatically choose which to use when damage occurs. • A processor can exploit sensors scattered throughout the aircraft. • Assume: hybrid chaining, several processors, shared memory. Where are some good opportunities for parallelism?

  23. Agents • "Agents" is a popular term in artificial intelligence these days. • It usually means a set of mostly-autonomous rule-based systems that communicate like a society. • The main applications: • "Distributed problems solvers" that work on problems simultaneously by each addressing different data or methods • "Simulation agents" that that model people in a game or simulation • "Knowledge brokers" that find information for you on the Internet

  24. Example multi-agent rule-based system • Agent type R rule 1: If no enemy fire, advance toward target. • Agent type R rule 2: If see enemy and either you are concealed or enemy is blocking your route, fire with small guns. • Agent type R rule 3: If enemy fires, return to staging area. • Agent type R rule 4: If major equipment malfunction, return to staging area. • Agent type S rule 1: If no enemy fire, advance straight toward target. • Agent type S rule 2: If enemy advancing, shoot at it. • Agent type S rule 3: If enemy retreating, block them. • Agent type S rule 4: If enemy fire is encountered, use big guns. • Create some terrain, staging areas, and targets for each agent. • Model effects of movement. • Let there be a probability of seeing something given that there is a line of sight. • For many agents of both types, simulate what happens. • Change probabilities to test situational effectiveness. • Change, delete, or add rules to test policy effectiveness.

  25. Issues for rule-based agents in a simulation • Each agent can have its own set of rules. E.g., a cautious agent will act differently to threats than an aggressive agent. Together these rules model an agent's "personality". • Each agent can have its own set of beliefs. It should reason about its own beliefs only. E.g., it may know the positions other units are supposed to take in a battle. • Agents can acquire new beliefs by exploring the world and observing. E.g., an agent sees another agent in the world and hence knows its location. But they won't notice everything. • Agents can also acquire new beliefs by being told them by other agents (but they need not believe everything they are told). E.g. an agent may be lied to in order to manipulate it. • Agents must follow "social protocols" to communicate to one another, and cannot just send facts to one another. They must initiate "speech acts" in the proper format and sequence. • Agents can search hypothetical worlds states.

  26. Meta-rules • = Rules that tell you what order in which to use other rules. They provide a higher-level kind of control structure. • Examples: • 1. Prefer the most recently used rule next. • 2. Prefer the shortest rule. • 3. Prefer the rule with the highest-priority conclusion. • 4. Prefer the rule with the highest-priority premises. • In general, a set of meta-rules is necessary to get a unique recommended rule.

More Related