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.
