Explanation

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 --gt 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,... lt-- step in inference
tree(0,0) (1,_),
(2,_),... lt-- inference tree record
level(0) lt--
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
2. Bowen toy system
(ch.8)
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
--gt 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.