Expert Systems: What They Were and Why Rules Fell Short

Expert systems were programs that copied how a human expert decides things, using a store of facts and if-then rules. Wikipedia's article on expert systems says they were among the first truly successful forms of AI software. In short, they worked well inside a narrow field, got hard to build and maintain as the rules piled up, and gave way to systems that learn from data.

If you would rather think about where AI goes next through a story, Contain ASI is a story strategy game for 1 to 4 players that runs in your browser. You try to keep four fictional AI labs from crossing into recursive self-improvement before 2027.

What an expert system is

An expert system is a computer system that emulates the decision-making ability of a human expert. Instead of ordinary procedural code, it reasons through a body of knowledge written mainly as if-then rules. For example: if the patient has a fever and the test shows a certain result, then suspect a certain infection.

The article says expert systems were created in the 1970s and spread in the 1980s. At the time they were widely regarded as the future of AI, before artificial neural networks became successful. They belong to the older, rule-based tradition that the post on symbolic AI covers more broadly.

The two parts: knowledge base and inference engine

Every expert system has two main parts. The knowledge base holds facts and rules. The inference engine applies the rules to the known facts to deduce new facts. The engine can also explain itself and help with debugging.

Fuller designs add an explanation facility, a way to acquire knowledge, and a user interface. In later systems built with commercial tools, the knowledge base gained more structure, with classes, subclasses and instances borrowed from object-oriented programming.

A worked example: forward and backward chaining

The article uses a classic example. Take the rule: if X is a man, then X is mortal. Now follow both modes of the inference engine.

1. Forward chaining starts from facts. You tell the system that Socrates is a man. The engine matches the rule and adds a new fact: Socrates is mortal.
2. Backward chaining starts from a possible conclusion. The system wants to know whether Socrates is mortal, finds the rule, and checks whether Socrates is a man. If it does not know, it can ask the user, which made backward chaining powerful when paired with a user interface.
3. Explanation comes almost free. Ask why Socrates is mortal, and the system traces back over the rules that fired: because all men are mortal and Socrates is a man.

One rule, two ways to run it: from facts forward, or from a goal backward.

That last step matters. Because the knowledge sat in readable rules, a person could see the chain of reasoning. Later engines added more: truth maintenance, which revokes conclusions when a fact changes, hypothetical reasoning across several possible worlds, and uncertainty, where a rule carries a probability.

Where they started: Dendral and Mycin

The article says expert systems were formally introduced around 1965 by the Stanford Heuristic Programming Project, led by Edward Feigenbaum, who is sometimes called the father of expert systems. Bruce Buchanan and Randall Davis were other key contributors.

The team looked for areas where expertise was highly valued and complex. Two became famous: diagnosing infectious diseases (Mycin) and identifying unknown organic molecules (Dendral). Medicine was a favorite target, and other early medical systems included Internist-I and, later, CADUCEUS.

The 1980s boom

In the 1980s, expert systems spread fast. Universities offered courses, and the article says two-thirds of the Fortune 500 companies used the technology in daily business. Interest was international, including Japan's Fifth Generation Computer Systems project and more research funding in Europe.

One striking case was a design program from 1982 written in Lisp. Fed with rules from several expert logic designers, it generated 93% of the logic gates of a large processor. The article notes the combined rules gave a design that in many cases beat what the experts alone had done.

Ready-made tools called expert system shells let teams enter a few rules and have a prototype in days rather than months. Applications ranged from medical diagnosis to dam monitoring in Italy, which began in 1992. The article groups uses into ten kinds, including diagnosis, design, planning, monitoring, instruction and control.

Why rules fell short

The same article lists the problems, and they explain why the boom ended.

• Knowledge acquisition. The experts were valuable and always busy, so getting their knowledge into rules was slow and hard.
• Scale. As the knowledge base grew, so did the processing cost, and checking that thousands of rules did not contradict each other became difficult.
• Maintenance. The claim that shells would remove the need for programmers was seldom true. A misplaced comma could cause havoc, as in any other language.
• Narrowness. The knowledge was superficial and lived in a closed world. The system had no deep grasp of concepts until an expert supplied them.
• Perception. Tasks like speech recognition and sonar analysis suited neural networks better than rules.

The article concludes that new approaches were needed instead of rule-based technology, built on machine learning and feedback. For the funding side of that story, see the post on AI winters, and for the wider timeline, the short history of AI.

Did expert systems fail?

The article gives two readings. In one, expert systems failed: they did not deliver on their hype, and by the 1990s the idea of a standalone AI system mostly dropped out of the IT vocabulary. In the other, they were victims of their success: rule engines became one of many standard tools, so the label faded while the technique stayed.

There is some support for the second view. In the 2000s the technology had a resurrection under the name rule-based systems, and the article says expert systems have moved into business rules and business rules management. Both readings can hold at once.

What this means for AI safety

The trade-off here comes up again in safety debates. An expert system's reasons could be read and traced, but it could not do much outside its field. Systems that learn can do far more, but their reasons are harder to inspect. The posts on explainable AI follow that thread. This is an observation about a trade-off, not a claim about any real system.

Frequently asked questions

What is an expert system in simple terms?

It is a program that stores a human expert's knowledge as if-then rules and uses them to reach conclusions in one narrow field, such as diagnosing a disease.

What are the two main parts of an expert system?

A knowledge base of facts and rules, and an inference engine that applies the rules to known facts to deduce new ones.

What is the difference between forward and backward chaining?

Forward chaining starts from known facts and fires rules to reach new facts. Backward chaining starts from a possible conclusion and works back to check whether it can be shown true.

Why did expert systems fall out of favor?

Getting knowledge from experts was slow, big rule sets were hard to check and update, and the systems stayed narrow. Machine learning handled many of these tasks better.

Do expert systems still exist?

The article says the idea lives on as rule-based systems and business rules management, though the standalone expert system label has mostly disappeared.

Get started

You now have the arc: knowledge in rules, a fast boom, the limits of hand-built knowledge, and the turn to learning. To carry those questions into a story about AI labs in a race, play Contain ASI. Its labs, people and events are all fictional, and it is a story, not a forecast.