Lecture 3: Reasoning: Goal Trees and Rule-Based Expert Systems

Related Resources

Duarte, José Pinto. "Customizing Mass Housing: A Discursive Grammar for Siza's Malagueira Houses." PhD thesis, MIT, 2001.

• Download this transcript - PDF (English - US)

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.

Free Downloads

Video

• iTunes U (MP4 - 175MB)
• Internet Archive (MP4 - 175MB)

Subtitle

• English - US (SRT)