1 / 10

Explanation

Explanation. • An important feature of expert systems is their ability to explain : - why questions are being asked - how certain conclusions were reached - why other conclusions were not reached - trace the inference engine for debugging purposes

Download Presentation

Explanation

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. Explanation • An important feature of expert systems is their ability to explain : - why questions are being asked - how certain conclusions were reached - why other conclusions were not reached - trace the inference engine for debugging purposes - give "human level" explanation of rules • Implementing explanation involves keeping a record of the inference steps that resulted in a computation: - the rules that were executed: (i) rule #’s, (ii) symbolic images of rules - the order in which rules were executed --> ie. keep a record of the computation tree • explanation utilities merely access this computation tree record, and print out text accordlingly

  2. Explanation (cont) • There are various methods for recording the computation tree: a) assert and retract facts recording level, step, and rule numbers - this adds complexity to knowledge base: rule numbers, "enter_rule" goal,... - KB becomes less declarative b) new arguments record explanation in KB rules; rules keep tabs on this arg - still makes KB less declarative c) Meta-interpreters: - because KB should be declarative, we write a simple meta-interpreter to execute it - this meta-interpreter will keep track of the computation tree via an added argument - advantage: KB remains declarative and simple to maintain - also, one can encode fairly sophisticated explanation facility

  3. Explanation • explain line of reasoning: why - why query is being asked how - how a conclusion was reached why_not - why another conclusion wasn't reached trace - computation trace dump - dump one or all rules in a readable format • Requires keeping track of computation tree - identify rules: rule numbers, or symbolically - keep track of computation tree i) assert step/rule info in active database ii) an extra argument to a meta-interpreter • Type of explanation generated: 1. print the rule - dump Prolog clause - print a rule number - print "attribute : value" - print a "english"-style version of rule

  4. Explanation (cont) 2. print special text incorporated into the rule eg. defect(12, 'the heater blower', is, defective) :- cause(13, 'the blower', is, stuck), cause(14, 'the motor', is, 'out of whack'). eg. meta-interpreter bird(barn_swallow, 'the name of the bird') :- family(swallow, _ ), tail(square, _). tail(square, X) :- X = 'the shape of the tail', ask(tail, square, X). then: (1) ask will use this 3rd argument when querying the user (2) meta-interpreter's "prove" predicate will include this text in its history argument, which is then available for any explanation required

  5. Explanation (cont) 3. Associate some canned text with each rule eg. rule numbers: bird(26,barn_swallow) :- family(_,swallow), tail(_,square). elsewhere... big_explanation(26) :- write('Barn swallows have the following unique characteristics..."). • The shell utility will match this explanation with the rule for which a big explanation is sought. • Could also have a text file for the rule: bird('barnswallow.txt', barn_swallow) :- .....

  6. 1. MTA • working data base: step(0) [1,2,3,...] <-- step in inference tree(0,0) [ (1,_), (2,_),...] <-- inference tree record level(0) <-- keeps track of which level in tree is currently being explained • advantages: - high-level explanation of rules disadvantages: - rules themselves are not printed (useful for debugging) - KB has more control info * - step, tree, level predicates work as side-effects: a very nasty way to do logic programming!

  7. (ch.8) 2. Bowen toy system run :- write ('Name='), read(Person), should_take(Person, Drug, Reason), write_list(['Recommend taking ', Drug, nl]), write('Explanation:'), nl, write_nl_list(Reason). should_take(Person, Drug, Reason) :- complains_of(Person, Symptom, ComplainsReason), suppresses(Drug, Symptom, SuppressesReason), not unsuitable_for(Person, Drug, UnsuitReason), append(SuppressesReason, UnsuitReason, InterReason), append(ComplainsReason, InterReason, Reason). suppresses(Drug, Symptom, [relieves(Drug, Symptom)]) :- relieves(Drug, Symptom). etc - 3rd arguments are lists of reasons why goals succeed - need to append them together: ruins declarativity of KB

  8. 3. Bird ID • meta-interpreter keeps a list of the successfully solved goals • this list is printed as part of explanation • Note that prov(G, [G | H ]) same as append([G], H, H2), prov(G, H2) • to add "why" to our toy system: - add a history argument to "prov" to keep a growing list of successful goals (represents the branch of computation tree) - modify "ask" to recognize "why" from user (already reads "yes" and "no"); will also take history argument, and print it out when "why" is seen • advantage: - KB is kept simple & declarative disadvantage: - the explanation written is terse --> solutions: (i) add phrase arguments, pretty printing (ii) add canned text predicates for why

  9. Comparing these styles - MTA KB is more difficult to maintain ; meta-interp'ed KB is more declarative - MTA shell code is side-effect driven , while Meta-interp is more straight-forward eg. compare MTA's write_explanation with bird's process_ans - each repeated "why" in MTA will retract/assert new level clause, which is a side effect - process_ans can be made to print elements in history list for each why given by user • Bowen's ch. 8 method is better, but it still complicates the KB - when Kb rules have "append", something is amiss •  meta-interpreter: ideal method, because we can in essence design our own KB language, whose explanation, I/O, inference scheme, etc, is tailored to our needs - can keep KB as pure as possible

  10. User interface • user interface should provide a variety of user commands - standard explanation ones: why, how, why_not, trace, ... - query input: yes, no, ( values - white, long, etc...) menus - choices, numeric input, windows, ... unsure - not certain how to determine query answer unknown - a definite answer is not possible • when recording input: assert(fact(Attribute, Value, X)) , where X is one of yes, no, unknown • unknown can mean that some rules are possible eligible • if user types "unsure", can give guidance as to how to proceed . This is called "test" advice in text.

More Related