Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ihuxv!arrgh
From: arrgh@ihuxv.UUCP
Newsgroups: comp.ai
Subject: Explanations in expert systems
Message-ID: <1800@ihuxv.ATT.COM>
Date: Thu, 5-Mar-87 10:08:41 EST
Article-I.D.: ihuxv.1800
Posted: Thu Mar  5 10:08:41 1987
Date-Received: Fri, 6-Mar-87 23:56:26 EST
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 51
Keywords: expert systems, ai, natural language

I have to put in my $0.02 into the expert systems discussion.

In real life, an expert system probably will not be used unless it possesses
a sound explanation facility.  For most users, this does not mean merely 
dumping rules or whatever, e.g., "the system is trying to satisfy rule-518", but
rather being able to turn the knowledge encoded in each unit of representation
into meaningful natural language.

An example may make this requirement clearer.  One of the systems I have
built is the Michael Reese-IIT Stroke Consultant.  This program is a large
neurology expert system designed to assist house physicians with the
diagnosis and treatment of stroke. 

One of the treatments this system recommends is to prep the patient for surgery,
take him into the OR, remove the back of his head, and proceed to dig around
in the cerebellum for a hematoma.  

Naturally enough, any reasonable physician will want to ask the machine "WHY?"
it recommends such a radical treatment, and expect an answer in a form that
a physician (not a computer scientist) can understand.  The explanation system
will furnish: an English statement of the problem, e.g., "diagnosis is
hemorrhage into the cerebellum", and justifications for the treatment, e.g.,
"Evacuation of cerebellar hematoma is recommended because it greatly reduces
mortality when the following signs are present... Refer to the following
references [references to the neurology literature are cited]."

Lets take a more common case.  Last spring, I built an expert system that
is designed to diagnose problems in candy wrapping machinery.  In fact, if
you eat candy bars, you have almost certainly eaten candy wrapped on one of
these machines.  The operators of these machines needed additional help
in diagnosing and troubleshooting problems in this new equipment, and we
built an expert system for this specific task.

Machine operators, unlike many of you, have absolutely no understanding of
production rules, and moreover, they are not interested.  This system had to be
able to furnish the following explanations on line at all times: (1) how to
use system itself, (2) how the candy wrapping equipment was supposed to
operate (an on line tutorial on the machine), (3) how to answer the questions
the system was asking, e.g., where was IC 9 pin 7 on the Micro controller "A"
board, and (4) an explanation of the reasoning the system was using at that
time.

The moral of this rather long posting is that if you want to build expert
systems that will actually be used by real people you will need a good
explanation facility.  While this is necessary, it is of course, not
sufficient.  The knowledge engineer will need good debugging facilities
(something not provided on most tools today).

Hope this clears up some confusion.
-- 
Howard Hill, Ph.D.