Expert Systems, and MYCIN as the Comparison

And it was never deployed in clinical use. The reasons usually given are not about its performance: the integration into practice, the legal position, and the computing available at the time.

What this book does not claim about it. Any specific figure for its accuracy, or a comparison with human specialists. Such figures are quoted in the literature and this book has not read the primary reports, so it does not repeat them.

Certainty factors, and why they were a problem

What they are. A number attached to a rule or a fact, expressing how strongly it is believed. Combining rules combines the numbers.

Why they seemed necessary. Expertise is full of "usually" and "this suggests", and a system that can only say yes or no cannot represent it.

Why they caused trouble. Three reasons and all three are worth naming.

The combination rules were ad hoc. How to combine two pieces of evidence for the same conclusion was decided by what behaved reasonably, not derived from anything.

They are not probabilities. They do not obey the laws probability obeys, so intuitions carried over from probability give wrong answers.

And they made the knowledge harder to acquire. An expert asked for a rule can give one. An expert asked for a rule and a number expressing how strongly they believe it gives a number they have no way of calibrating.

The eventual response was probabilistic graphical models, which have a principled account of combination, and which lose much of the transparency that made the expert system attractive. That trade is still live, which is why this material is on a syllabus.

The knowledge acquisition bottleneck

The problem, stated plainly. Getting what an expert knows out of them and into rules is slow, and it is the dominant cost of building an expert system.

Why it is hard. Experts are fluent and not articulate: they can do the task and cannot always say how. What they say when asked is often a reconstruction rather than a description of what they did.

Why it does not improve with practice. Each new domain needs a new extraction. The knowledge is the system, so there is nothing to reuse.

And this is the reason the programme stalled, more than any technical limitation. A technology whose cost is dominated by expert interview time does not scale, and saying so is the honest historical verdict.

What survived, and what returned

What survived. Rule engines are in wide use in business systems, where the rules are policies rather than expertise and the experts who state them are the people who wrote the policies. The acquisition problem does not arise because the knowledge was already explicit.

What returned. The requirement for explanation. Systems built by learning from data cannot explain themselves, and the argument for interpretable models is the argument the expert system architecture made forty years earlier.

And the honest summary for an answer. The architecture was sound and the bottleneck was human. Where the knowledge is already written down, the architecture works and is used; where it has to be extracted from a specialist, it did not scale.

The comparison with the classical material

The row that repays attention is the last. The classical scheme solved the acquisition problem by writing the knowledge down and then maintaining an apparatus for transmitting it: the four layers of [Śāstra: What Makes a Body of Knowledge Formal]. That is a real answer to the bottleneck, and it takes centuries.

Quick revision

• Five components: knowledge base, working memory, inference engine, explanation facility, knowledge acquisition.
• Two explanations owed: why are you asking, and how did you conclude that. Both are free in a rule architecture.
• MYCIN: rule-based, backward-chaining, with an explanation facility and certainty factors, and never deployed clinically.
• Certainty factors: ad hoc combination rules, not probabilities, and they made acquisition harder.
• The knowledge acquisition bottleneck is the historical reason the programme stalled: experts are fluent and not articulate, and nothing transfers between domains.
• What survived: rule engines where the rules are already-written policies. What returned: the demand for explanation.

Test yourself

1. Name the five components of an expert system and say which distinguishes it from a program with rules in it.

Knowledge base, working memory, inference engine, explanation facility, knowledge acquisition. The explanation facility is what distinguishes it: a system replacing a specialist must be able to defend its conclusions as the specialist would.

2. Give the two questions an expert system should be able to answer, and when each is asked.

"Why are you asking?", asked during the consultation and answered by naming the goal the current question serves. "How did you conclude that?", asked afterwards and answered by the chain of rules that fired.

3. State three problems with certainty factors.

The rules for combining them were chosen for reasonable behaviour rather than derived; they are not probabilities and do not obey probability's laws, so transferred intuitions mislead; and asking an expert for a number they cannot calibrate makes knowledge acquisition harder.

4. What was the main historical reason the expert system programme stalled, and where does the architecture still work?

The knowledge acquisition bottleneck: extracting rules from a specialist is slow, does not transfer between domains, and dominated the cost. The architecture still works where the knowledge is already explicit, as in business rule engines encoding written policies.