3. Reasoning Goal Trees and Rule-Based Expert Systems Video Lecture - Artificial

PROFESSOR PATRICK WINSTON:
Ladies and gentlemen, the
engineers drinking song.
Back in the day, I've drunk
quite a lot to that song.
And as drinking songs
go, it's not bad.
I caution you, however, before
playing this song in the
presence of small children,
audition it first.
Some of the verses are
sufficiently gross as to make
a sailor go beyond blushing.
It's an interesting song because
there are an infinite
number of verses.
Here's the mathematical proof.
Suppose there were a finite
number of verses.
Then there would be
a last verse.
And if there were a last verse,
then some drunk alumni
would compose a new one.
Therefore, there is no last
verse, the size is not finite,
and there are an infinite
number of verses.
I play it for you today because
I'm an engineer.
I like to build stuff.
I build stuff out of wood.
I build stuff out of metal.
I build stuff out of rocks.
And I especially like
to write programs.
I don't know, sometimes people
come to me and say, I'm
majoring in computer science,
but I don't
like to write programs.
I've always been mystified
by that.
I mean, if you want to show how
tough you are, you can go
bungee jumping or drive a nail
through your hand or something
like that instead.
But I've written quite a few
programs for demonstrating
stuff in this subject.
They're all written in Java,
principally because I can
therefore make them available to
you and to the rest of the
world by way of Web Start.
A few weeks ago, I was mucking
around with the system and
broke the version on the server,
and within 15 minutes,
I got an email from somebody
in the depths of Anatolia
complaining about it and asking
me to bring it back up.
This particular program
is patterned
after an early AI classic.
And it was the business end of
a program written by Terry
Winograd, who became, and is,
a professor of computer
science at Stanford
University--
which is on the west coast
for those of you--
on the strength of his work on
the natural language front end
of this program.
But the natural language part
is not what makes it of
interest for us today.
It's more the other
kinds of stuff.
Let's pile these things up.
Now, I'm going to ask to
do something, maybe put
B2 on top of B7.
Not bad.
How about B6 on B3?
This program's kind of clever.
Let me do one more.
Let's put B7 on B2.
OK, now let's see.
Maybe B5 on B2?
B4 on B3 first, maybe?
Oh, I must have clicked
the wrong button.
Oh, there it goes.
OK.
Let's put B4 on B1.
Agh, my mouse keeps getting
out of control.
Now, let's put B1 on B2.
This is an example I'm
actually going to
work out on the board.
Oh, I see.
My touch pad accidentally
got activated.
B1 on B2.
Now, let's ask a question.
OK.
Well.
SPEAKER 2: [SINGING]
PROFESSOR PATRICK
WINSTON: Stop.
SPEAKER 3: [LAUGHTER]
PROFESSOR PATRICK WINSTON:
Had enough of that.
Let's see.
Why did you put--
why did you want to
get rid of B4?
OK, one--
SPEAKER 2: [SINGING]
PROFESSOR PATRICK WINSTON: Maybe
they think, that's what
happens when you use software
you write yourself.
Why did you want to clear
the top of B2?
Did I do that?
Why did you clear
the top of B1?
OK.
SPEAKER 2: [SINGING]
SPEAKER 3: [LAUGHTER]
PROFESSOR PATRICK WINSTON:
Oh, it's haunting me.
Yeah.
So the drinking song is easily
offended, I guess.
But I won't develop that
scenario again.
What I want to show you is that
this program looks like
it's kind of smart, and it
somehow can answer questions
about its own behavior.
Have you ever written a program
that's answered
questions about its
own behavior?
Probably not.
Would you like to learn
how to do that?
OK.
So by the end of the hour,
you'll be able to write this
program and many more like it
that know how to answer
questions about their
own behavior.
There have been tens of
thousands of such programs
written, but only by people who
know the stuff I'm going
to tell you about
right now, OK?
So what I want to do is I want
to start by taking this
program apart on the board and
talking to you about the
modules, the subroutines
that it contains.
So here it is.
The first thing we need
to think about,
here are some blocks.
What has to happen if I'm going
to put the bottom block
on the larger block?
Well, first of all, I have
to find space for it.
Then I have to grasp
the lower block.
And I have to move it and
I have to ungrasp it.
So those are four things I need
to do in order to achieve
what I want to do.
So therefore, I know that the
put-on method has four pieces.
It has to find space on
the target block.
It has to grasp the block that
it's been commanded to move.
Then it has to move, and
then it has to ungrasp.
But taking hints from some of
the questions that it did
answer before I got haunted by
the music, taking our cue from
that, we know that in order to
grasp something, in this
particular world, you can't have
anything on top of it.
So grasp, therefore, may call
clear top in order to get
stuff off from the
target object.
And that may happen in an
iterative loop because there
may be several things on top.
And how do you get
rid of stuff?
Well, by calling get rid of.
And that may go around
a loop several times.
And then, the way you get rid of
stuff is by calling put-on.
So that gives us recursion, and
it's from the recursion
that we get a lot of the
apparent complexity of the
program's behavior when
it solves a problem.
Now, in order to find space,
you also have to
call get rid of.
So that's where I meant to
put this other iterative
loop, not down here.
Cleat top has got the iterative
loop inside of it.
So that's the structure
of the program.
It's extremely simple.
And you might say to me, well,
how can you get such
apparently complex-looking
behavior out of
such a simple program?
A legitimate question.
But before we tackle that one
head on, I'd like to do a
simulation of this program
with a very
simple blocks problem.
And it's the one I almost
showed you, but
it goes like this.
Here's B1.
We'll call this BX because
I forgot its name.
Here's BY.
And here's B2.
And the task is to
put B1 on B2.
And according to our system
diagram, that results in four
calls to subroutines.
We have to find space.
We have to grasp B1.
We have to move, and
then we ungrasp.
Now, the way we grasp something
is the first thing
we have to do is clear
off its top.
So grasp calls clear top.
And clear top in turn
calls get rid of.
And let me see.
Let me keep track of these.
This is clearing the top
of B1, and this is
getting rid of BX.
And the way we get rid of BX is
by putting BX on the table.
And then that in turn causes
calls to another find space,
another grasp, another move,
and another ungrasp.
So that's a little trace of
the program as it works on
this simple problem.
So how does it go about
answering the questions that I
demonstrated to you
a moment ago?
Let's do that by using
this trace.
So how, for example, does it
answer the question, why did
you get rid of BX?
[INAUDIBLE], what
do you think?
How can it answer
that question?
SPEAKER 4: [INAUDIBLE]
PROFESSOR PATRICK WINSTON: So
it goes up one level and
reports what it sees.
So it says, and said in the
demonstration, I got rid of BX
because I was trying to
clear the top of B1.
So if I were to say why did you
clear the top of B1, it
would say because I was
trying to grasp it.
If I were to say, why did you
grasp B1, it would say because
I was putting B1 on B2.
If I say, why did you put
B1 on B2, it would say,
slavishly, because
you told me to.
OK, so that's how it deals
with why questions.
How about how questions?
Timothy, what do you think
about that one?
How would it go about answering
a question about how
you did something?
Do you have a thought?
TIMOTHY: Um, yeah, it would
think about what I was trying
to accomplish.
PROFESSOR PATRICK WINSTON:
Yeah, but
how would it do that?
How would the program do that?
We know that answering
a why question makes
it go up one level.
How does it answer
a how question?
Sebastian?
SEBASTIAN: It goes
down one level.
PROFESSOR PATRICK WINSTON:
You go down one level.
So you start off all the way
up here with a put-on.
You will say, oh, well I
did these four things.
You say, why did you grasp B1?
It will say because I was
trying to clear its top.
Why did you clear its top?
Because I was trying
to get rid of it.
Why were you trying
to get rid of it?
Because I was trying to
put it on the table.
So that's how it answers how
questions, by going down in
this tree and this trace of the
program of action so as to
see how things are
put together.
What are these things that
are being put together?
What's the word I've been
avoiding so as to bring this
to a crescendo?
What are these objectives, these
things it wants to do?
They're goals.
So this thing is leaving a
trace, which is a goal tree.
Does that sound familiar?
Three days ago, we talked about
goal trees in connection
with integration.
So this thing is building a goal
tree, also known as an
and-or tree.
So this must be an and tree.
And if this is an and tree,
are there any and nodes?
Sure, there's one right there.
So do you think then that you
can answer questions about
your own behavior as long as
you build an and-or tree?
Sure.
Does this mean that the
integration program could
answer questions about
its own behavior?
Sure.
Because they both build goal
trees, and wherever you got a
goal tree, you can answer
certain kinds of questions
about your own behavior.
So let me see if in fact it
really does build itself a
goal tree as it solves
problems.
So this time, we'll put
B6 on B3 this time.
But watch it develop
its goal tree.
So in contrast to the simple
example I was working on the
board, this gets to be a pretty
complicated goal tree.
But I could still answers
questions about behavior.
For example, I could say, why
did you put B6 on B3?
Because you told me to.
All right, so the complexity of
the behavior is largely a
consequence not of the
complexity of the program in
this particular case, but the
building of this giant goal
tree as a consequence of the
complexity of the problem.
This brings us to one of
our previous matters--
early on to one of the gold
star ideas of today.
And this gold star idea goes
back to a lecture given in the
late '60s by Herb Simon, who was
the first Nobel Laureate
in the pseudo Nobel Prize
for economics.
Is that right, Bob?
Was he the first?
All right, he was the first
winner of the Nobel Prize,
pseudo Nobel Prize
in economics.
And in this lecture, which was
titled "The Sciences of the
Artificial," he said imagine
that you're looking on a beach
at the path of a ant.
And he said, well, you know,
the path of the ant looks
extremely complicated.
And you're tempted to think the
ant is some kind of genius
or monster brain ant.
But in fact, when you take a
closer look, what you discover
is that there are a bunch of
pebbles on the beach, and all
the ant is doing is avoiding
those pebbles on his way home.
So the complexity of the
behavior, said Simon, is a
consequence of the complexity
of the environment, not the
complexity of the program.
So that's the metaphoric
Simon's ant.
And what it says is that the
complexity of the behavior is
the max of the complexity of the
program and the complexity
of the environment.
So that's something we'll see
many times during the rest of
the semester.
Complex behavior,
simple program.
You think it's going
to be complicated.
It turns out to be simple
because the problem has the
complexity, not the program.
So that brings us to check box
three in today's talk, and
there's a little bit of a scene
here because now I want
to stop talking about
goal-centered programming and
start talking about rule-based
expert systems.
The rule-based expert systems
were developed in a burst of
enthusiasm about the prospects
for commercial applications of
artificial intelligence
in the mid-1980s.
At that time, it was supposed
lengthy articles are written,
but you could account for
useful aspects of human
intelligence by writing all the
knowledge in the form of
simple rules.
So if this is true,
then that's true.
If you want to achieve
this, then do that.
But all the knowledge had to be
encapsulated in the form of
simple rules.
So what might you want
to do with this?
All sorts of things.
Thousands of these systems
were written,
as I indicated before.
But here's an example.
I'm going to work out an example
having to do with
identification.
And this example is patterned
off of a classic program,
strangely also written at
Stanford, called MYCIN.
It was developed to
diagnose bacterial
infections in the blood.
So you come in.
You got some horrible disease,
and the doctor gets curious
about what antibiotic would be
perfect for your disease.
He starts asking a
lot of questions.
So I'm not going to deal with
that because that world has
all kinds of unpronounceable
terms like bacterioides and
anaerobic and stuff like that.
So it's completely analogous
to talk about identifying
animals in a little zoo, sort
of a small town type of zoo.
So I'm going to suggest that
we write down on a piece of
paper all the things we can
observe about an animal, and
then we'll try to figure
out what the animal is.
So I don't know, what
can we start with?
Has hair.
Then there are some
characteristics of the
following form.
Has claws.
Sharp teeth.
And forward-pointing eyes.
And these are all
characteristics of carnivores.
We happen to have
forward-pointing eyes too, but
that's more because we used to
swing around the trees a lot,
and we needed the
stereo vision.
And we don't have the claws
and the sharp teeth
that go with it.
But anyhow, those are typically
characteristics of
carnivores, as is eating meat.
And this particular little
animal we're looking at has
also got spots, and
it's very fast.
What is it?
Well, everybody says
it's a cheetah.
Let's see how our program
would figure that out.
Well, program might say, let's
see if it has hair, then rule
one says that that means
it must be a mammal.
We can imagine another rule that
says if you have sharp
claws, sharp teeth, and
forward-pointing eyes, then
you're a carnivore.
And I'm using sort of hardware
notation here.
That's an and gate, right?
So that means we have to have
all of these characteristics
before we will conclude that
the animal is a carnivore.
Now, this animal has been also
observed to eat meat.
So that means we've got extra
evidence that the animal is
carnivorous.
And now, because the animal is
a mammal and a carnivore and
has spots, and it's very fast,
then the animal is a cheetah.
And I hope all of our African
students agree that
it must be a cheetah.
It's a small zoo--
I mean, a big zoo.
Who knows what it is?
It's probably got some
unpronouncable name--
there's possibilities.
But for our small zoo,
that will do.
So we have group now written
down in the form
of these and gates.
Several rules, R1, R2--
and there needs to
be an and gate here--
that's R3 and an R4.
All of which indicate that
this animal is a cheetah.
So we built ourself a little
rule-based expert system that
can recognize exactly one
animal, but you could imagine
filling out this system with
other rules so that you could
recognize giraffes and penguins
and all the other
sorts of things you find
in a small zoo.
So when you have a system like
this that works as I've
indicated, then what we're
going to call that, we're
going to give that a special
name, and we're going to call
that a forward-chaining
rule-based--
because it uses rules--
expert system.
And we're going to put expert
in parentheses because when
these things were developed,
for marketing reasons, they
called them expert systems
instead of novice systems.
But are they really experts
in a human sense?
Not really, because they have
these knee-jerk rules.
They're not equipped with
anything you might want to
call common sense.
They don't have an ability to
deal with previous cases, like
we do when we go to
medical school.
So they really ought to be
called rule-based novice
systems because they reason
like novices on
the basis of rules.
But the tradition
is to call them
rule-based expert systems.
And this one works forward from
the facts we give it to
the conclusion off
on the right.
That's why it's a
forward-chaining system.
Can this system answer
questions
about its own behavior?
[INAUDIBLE], what
do you think?
SPEAKER 5: [INAUDIBLE].
PROFESSOR PATRICK
WINSTON: Why?
SPEAKER 5: [INAUDIBLE].
PROFESSOR PATRICK WINSTON:
Because it
looks like a goal tree.
Right.
This is, in fact, building a
goal tree because each of
these rules that require several
things to be true is
creating an and node.
And each of these situations
here where you have multiple
reasons for believing that the
thing is a carnivore, that's
creating an or node.
And we already know that you
can answer questions about
your own behavior if you leave
behind a trace of a goal tree.
So look at this.
If I say to it, why were
you interested in
the animal's claws?
Because I was trying to see
if it was a carnivore.
How did you know that the
animal is a mammal?
Because it has hair.
Why did you think it
was a cheetah?
Because it's a mammal,
a carnivore, has
spots, and very fast.
So by working forward and
backward in this goal tree,
this too can answer questions
about its own behavior.
So now you know how, going
forward, you can write
programs that answer questions
about their behavior.
Either you write the subroutines
so that each one
is wrapped around a goal, so
you've got goal-centered
programming, or you build a
so-called expert system using
rules, in which case it's easy
to make it leave behind a
trace of a goal tree, which
makes it possible to answer
questions about its own
behavior, just as this
[INAUDIBLE]
program did.
But now, a little
more vocabulary.
I'm going to save time by
erasing all of these things
that I previously drew by
way of connections.
And I'm going to approach this
zoo in a little different way.
I'm going to not ask any
questions about the animal.
Instead, I'm going to say,
mommy, is this thing I'm
looking at a cheetah?
And how would mommy go about
figuring it out.
In her head, she would say,
well, I don't know.
If it's going to be a cheetah,
then it must be the case that
it's a carnivore, and it must be
the case that it has spots.
And it must be the case
that it's very fast.
So so far, what we've
established is that if it's
going to be a cheetah, it
has to have the four
characteristics that
mommy finds behind
this rule are four.
So instead of working forward
from facts, what I'm going to
do is work backward
from a hypothesis.
So here the hypothesis is
this thing is a cheetah.
How do I go about showing
whether that's true or not?
Well, I haven't done anything so
far because all I know is a
cheetah if all these things are
true, but are they true?
Well, to find out if it's a
mammal, I can use rule one.
And if I know or can determine
that the animal has hair, then
that part of it is
taken care of.
And I can similarly work my way
back through carnivore.
I say, well, it's a carnivore if
it has claws, sharp teeth,
and forward-pointing eyes.
And then as much as the
animal in question
does, then I'm through.
I know it's a carnivore.
I don't have to go through and
show that it's a carnivore
another way.
So I never actually ask
questions about
whether it eats meat.
Finally, the final two
conditions are met by just an
inspection of the animal.
That's to say, it's
in the database.
I don't have to use any rules
to determine that the animal
has spots and is very fast.
So now, I've got everything in
place to say that it's a
cheetah, because it's a
carnivore, because it has
claws, sharp teeth, and
forward-pointing eyes, and all
the rest of this stuff is
similarly determined by going
backwards, backwards from the
hypothesis toward the facts,
instead of from the facts
forward to the conclusions.
So building a system that works
like that, I have a
backward-chaining rule-based
expert system.
But there's a very important
characteristic of this system
in both backward and forward
mode, and that is that this
thing is a deduction system.
That's because it's
working with facts
to produce new facts.
When you have a deduction
system, you can never take
anything away.
But these rule-based systems are
also used in another mode,
where it's possible to
take something away.
See, in fact world, in deduction
world, you're
talking about proving things.
And once you prove something
is true, it can't be false.
If it is, you've got a
contradiction in your system.
But if you think of this as a
programming language, if you
think of using rules as a
programming language, then you
can think of arranging it so
these rules add or subtract
from the database.
Let me show you an example
of a couple of systems.
First of all, since I've talked
about the MYCIN system,
let me show you an example
of a MYCIN dialogue.
That's a MYCIN dialogue.
And you can see the appearance
of words you have to go to
medical school to learn.
And here's a typical MYCIN rule,
just like the rules for
doing zoo analysis, only a
more complicated domain.
But here's another example of a
system that was written, not
in the '80s, but just a couple
of years ago by a student in
the architecture department,
Ph.D. thesis.
He was interested in the
architecture of a Portuguese
architect named Siza.
And Siza's done a lot of
mass housing stuff.
And Siza has the idea that you
ought to be able to design
your own house.
And so Jose Duarte, a Portuguese
student, a Ph.D.
student in architecture, wrote
a rule-based system that was
capable of designing Siza-like
houses in response to the
requirements and recommendations
and desires of
the people who are going
to occupy the houses.
So the most compelling part of
this thing, of this exercise,
was that Duarte took some of
the designs of the program,
mixed them up with some of the
designs of Siza, and put them
in front of Siza, and said,
which ones did you do?
And Siza couldn't tell.
So somehow, the rule-based
system that was built using
this kind of technology was
sufficient to confuse even the
expert that they were
patterned after.
But this program is a
little complicated.
It, too, has its own
specialized lingo.
So I'm not going to talk about
it in detail, but rather talk
instead about an analogous
problem.
And that is a problem that
everyone has faced at one
point or another, and that
is the problem of putting
groceries in a bag at
a grocery store.
It's the same thing, right?
Instead of putting rooms in
a house, you're putting
groceries in a bag.
And there must be some rules
about how to do that.
In fact, maybe some of you have
been professional grocery
store baggers?
[INAUDIBLE] a grocery store
professional bagger.
You're a--
which one?
LISA: [INAUDIBLE]
PROFESSOR PATRICK WINSTON:
Yeah, what is your name?
LISA: Lisa.
PROFESSOR PATRICK
WINSTON: Lisa.
OK, well we got two
professional
grocery store baggers.
And I'm going to be now
simulating a highly paid
knowledge engineer desirous of
building a program that knows
how to bag groceries.
So I'm going to visit your site,
Market Basket, and I'm
going to ask Lisa, now fearful
of losing her job, if she
would tell me about how
she bags groceries.
So could you suggest a rule?
LISA: Sure.
Large items in the bottom.
PROFESSOR PATRICK WINSTON: Large
items in the bottom.
You see, that's why I'm a
highly paid knowledge
engineer, because I translate
what she said
into an if-then rule.
So if large, then bottom.
So now I--
SPEAKER 3: [LAUGHTER]
PROFESSOR PATRICK WINSTON: So
how about you, [INAUDIBLE]?
Have you got a suggestion?
About how to bag groceries?
SPEAKER 6: The small
things on top.
PROFESSOR PATRICK WINSTON:
If small, then on top.
Lisa, have you got anything
else you could tell me?
LISA: Don't put too many heavy
things in the same bag.
PROFESSOR PATRICK WINSTON:
Don't put too many heavy
things in the same bag.
So if heavy greater than
three, then new bag, or
something like that.
Is that all we're going to be
able to-- does anybody else
want to volunteer?
[INAUDIBLE], have you bagged
groceries in Turkey?
LISA: So they don't
have grocery
baggers, so we have to--
PROFESSOR PATRICK WINSTON: So
everybody's a professional
bagger in Turkey.
Yeah.
It's outsourced to
the customers.
SPEAKER 7: So no squishies
on the bottom.
So if you have--
PROFESSOR PATRICK WINSTON: No
squishies on the bottom.
SPEAKER 7: If you
have tomatoes--
PROFESSOR PATRICK WINSTON:
That's good.
Tomatoes.
SPEAKER 7: You don't want
them to get squished.
PROFESSOR PATRICK WINSTON: Now,
there's a very different
thing about squishies and
tomatoes because tomato is
specific, and squishy isn't.
Now, one tendency of MIT
students, of course, is that
we all tend to generalize.
I once knew a professor
in the Sloan School
who seemed real smart.
And--
SPEAKER 3: [LAUGHTER]
PROFESSOR PATRICK
WINSTON: Then I
figured out what he did.
If I were to say, I'm thinking
about a red apple.
They'd sit back and say, oh,
I see you're contemplating
colored fruit today.
They're just taking it up one
level of abstraction.
Not a genius.
He also was able to talk for
an hour after he drew a
triangle on the board.
Amazing people.
Anyhow, where were we?
Oh, yes, bagging groceries.
So we're making some progress,
but not as
much as I would like.
And so in order to really make
progress on tasks like this,
you have to exercise--
you know about some principles
of knowledge engineering.
So principle number one, which
I've listed over here as part
of a gold star idea, is deal
with specific cases.
So while you're at the site, if
all you do is talk to the
experts like Lisa and
[INAUDIBLE], all you're going
to get is vague generalities
because they won't think of
everything.
So what you do is you
say, well, let me
watch you on the line.
And then you'll see that they
have to have some way of
dealing with the milk.
And then you'll see that they
have to have some way of
dealing with the potato chips.
Nobody mentioned potato chips,
except insofar as they might
be squishy.
We don't have a definition
for squishy.
Nobody talked about
the macaroni.
And no one talked about
the motor oil.
This is a convenience store.
I don't want that in the
same bag with the meat.
And then no one talked
about canned stuff.
Here's a can of olives.
So by looking at specific cases,
you elicit from people
knowledge they otherwise would
not have thought to give you.
That's knowledge engineering
rule number one.
And within a very few minutes,
you'll have all three
knowledge engineering rules and
be prepared to be a highly
paid knowledge engineer.
Heuristic, let's call
these heuristics.
Heuristic number one,
specific cases.
Heuristic number two is ask
questions about things that
appear to be the same, but are
actually handled differently.
So there's some Birds Eye
frozen peas, and here--
ugh, some fresh cut
sweet peas.
And to me, the person who's
never touched a grocery bag in
my life-- maybe I'm
from Mars--
I can't tell the difference.
They're both peas.
But I observe that the experts
are handling these objects
differently.
So I say, why did you handle
those peas differently from
those peas, and what
do they say?
One's canned, and
one's frozen.
So what happens?
Bingo, I've got some new
words in my vocabulary.
And those new vocabulary words
are going to give me power
over the domain because
I can now use
those words in my rules.
And I can write rules like if
frozen, then put them all
together in a little
plastic bag.
Actually, that's too
complicated, but that's what
we end up doing, right?
Why do we put them
all together in a
little plastic bag?
SPEAKER 8: [INAUDIBLE]
PROFESSOR PATRICK WINSTON:
What's that?
SPEAKER 8: [INAUDIBLE]
PROFESSOR PATRICK WINSTON:
Well, there are two
explanations.
There's the MIT explanation.
We know that temperature flow
is equal to the fourth power
of the temperature difference
and the surface area and all
that kind of stuff.
We want to get them all together
in a ball, sphere.
The normal explanation is that
they're going to melt anyway,
so they might as well not
get everything else wet.
All right.
SPEAKER 3: [LAUGHTER]
PROFESSOR PATRICK WINSTON: So
that's heuristic number two.
And actually, there's heuristic
number three, that I
just want to relate to you for
the first time because I have
been dealing with it a lot
over this past summer.
Heuristic number three is you
build a system, and you see
when it cracks.
And when it cracks is when you
don't have one of the rules
you need in order to execute--
in order to get the program
to execute as
you want it to execute.
So if I were to write a grocery
store bagging program
and have it bag some groceries,
again, eventually
it would either make a mistake
or come to a grinding halt,
and bingo, I know that there's
a missing rule.
Isn't that what happens when you
do a problem set, and you
hit an impasse?
You're performing an experiment
on yourself, and
you're discovering that you
don't have the whole program.
In fact, I've listed this as a
gold star idea having to do
with engineering yourself
because all of these things
that you can do for knowledge
engineering are things you can
do when you learn a new
subject yourself.
Because essentially, you're
making yourself into an expert
system when you're learning
circuit theory or
electromagnetism or something
of that sort.
You're saying to yourself,
well, let's look at some
specific cases.
Well, what are the vocabulary
items here that tell me why
this problem is different
from that problem?
Oh, this is a cylinder
instead of a sphere.
Or you're working with a problem
set, and you discover
you can't work with the problem,
and you need to get
another chunk of knowledge
that makes it possible
for you to do it.
So this sort of thing, which
you think of primarily as a
mechanism, heuristics for doing
knowledge engineering,
are also mechanisms for making
yourself smarter.
So that concludes what I want to
talk with you about today.
But the bottom line is, that
if you build a rule-based
expert system, it can
answer questions
about its own behavior.
If you build a program that's
centered on goals, it can
answer questions about
its own behavior.
If you build an integration
program, it can answer
questions about its
own behavior.
And if you want to build one of
these systems, and you need
to extract knowledge from an
expert, you need to approach
it with these kinds of
heuristics because the expert
won't think what to tell you
unless you elicit that
information by specific cases,
by asking questions about
differences, and by ultimately
doing some experiments to see
where your program is correct.
So that really concludes what I
had to say, except I want to
ask the question, is this all
we need to know about human
intelligence?
Can these things be--
are these things really smart?
And the traditional answer is
no, they're not really smart
because their intelligence is
this sort of thin veneer.
And when you try to get
underneath it, as written,
they tend to crack.
For example, we talk about a
rule, we could talk about a
rule that knows that you should
put the potato chips on
the top of the bag.
But a program that knows that
would have no idea why you
would want to put the potato
chips on top of the bag.
They wouldn't know that if you
put them on the bottom of the
bag, they'll get crushed.
And it wouldn't know that if
they get crushed, the customer
will get angry, because people
don't like to eat crushed
potato chips.
So that's what I mean when I
say the knowledge of these
things tends to be a veneer.
So the MYCIN program, during
debugging, once prescribed a
barrel of penicillin to be
administered to a patient for
its disease.
They don't know, they don't
have any common sense.
So the question then becomes,
well, I don't know.
Does rule-based--
do rules have anything to
do with common sense?
And I'm becoming a little bit
agnostic on that subject.
Because there are certain
indications, there are certain
situations, in which rules could
be said to play a role
in our ordinary understanding
of things.
Would you like to see
a demonstration?
What I'm going to show you,
when the clip speaks up--
well, before I make any
promises, let me see if I'm
actually connected to the web.
MIT, good.
MIT.
Guest.
Yeah, that's me.
Sounds good.
OK, I just tested the system,
and I've seen it is actually
connected to the web.
And I'm going to adjust some
systems options here.
I'll get rid of the text box.
And we'll get rid of those
changes scale a little bit.
What I'm going to do is I'm
going to read a little
synopsis of the Macbeth plot.
You're MIT students.
I'm sure you're all classically
educated and very
familiar with Shakespearean
plots.
So I'm going to read one.
I'm going to read a version
of a Macbeth plot.
And it's going to go
along like this.
It's basically reading
a rule base so far.
And pretty soon, it's going to
get beyond the rule base and
start reading the
Macbeth story.
And there it is.
It's read the Macbeth story.
Let me show you what the Macbeth
story looks like as
it's actually retained
by the system.
That's it.
Read that.
OK, you ran out of
time because the
machine's already finished.
It takes about five seconds
to read this story.
Now, as you look at this little
synopsis of Macbeth,
there are a couple
things to note.
For one thing, it says that
Duncan is murdered.
Duncan, I hope this doesn't
bother you.
Duncan is murdered by Macbeth.
But at no time does it say
that Duncan is dead.
But you know Duncan's dead
because he was murdered.
If murdered, then dead.
SPEAKER 3: [LAUGHTER].
PROFESSOR PATRICK WINSTON: So
if you look a little further
down, what you see is that
Macduff kills Macbeth.
Fourth line up from
the bottom.
Why did Macduff kill Macbeth?
Doesn't say why in this story,
but you have no trouble
figuring out that it's
because he got angry.
And when you get angry, you
don't necessarily kill
somebody, but it's possible.
SPEAKER 3: [LAUGHTER].
PROFESSOR PATRICK WINSTON: So
now that you see what's in the
story, let me take you
back to this display.
It's what we call an
elaboration graph.
And when I blow it up, you can
see that there's some familiar
looking things in there.
For example, up here in the
left-hand corner, Macbeth
murders Duncan, right
over there.
And over here, Macduff
kills Macbeth.
And if you look at what is a
consequence of that, it looks
like there must be a rule that
says if you murder somebody,
you harm them.
And if you murder somebody,
then they're dead.
And one reason why you might
kill somebody is because they
angered you.
And if you go the other way,
one consequence of killing
somebody is that you harm them,
and that they die too.
And if you harm somebody, they
get angry, and their state
goes negative.
So that suggests that there are
some things that we have
on our hands that are very
compiled and very, strangely
enough, very rule-like
in their character.
Now, to close, I'm just
going to read Hamlet.
The Hamlet demonstration is
much like the Macbeth one.
In fact, Hamlet and Macbeth are
very alike in their plot.
But there's one thing that's
well-illustrated by our
particular capturing
of Hamlet here.
And that is that you'll note
that the ratio of gray stuff
to white stuff is
considerable.
The gray stuff is stuff that
has been deduced by rules.
And the reason there's so much
gray stuff in this Hamlet
story is because everybody's
related to everybody else.
So when you kill anybody, you
irritate everybody else.
So look at that.
A few white things, those are
the things that are explicit
in the story, and lots
of gray stuff.
So what this is suggesting is
that when we tell a story,
it's mostly a matter of
controlled hallucination.
I know what rules are in your
head, so I could take
advantage of that in telling the
story and not have to tell
you anything I'm sure you're
going to know.
And so that's why, we've
discovered, that storytelling
is largely a matter of just
controlling how you're going
along, a kind of controlled
hallucination.