4.25 Expert systems: architecture, knowledge engineering and rule-based inference

What this is and why it exists

An expert system separates what is known from the program that reasons over it, and that separation is the entire idea. A conventional program has its knowledge spread through its code, so changing what it knows means rewriting it. An expert system holds the knowledge in data — rules, mostly — and a fixed program reasons over whatever rules it is given. A different problem in the same domain then needs new rules and not a new program. This is also the approach whose collapse produced the second AI winter, so an honest treatment covers how one is built, what it is made of, and the specific things it cannot do. The most famous of them outperformed the average clinician and was never used on a patient, which is the whole story in one sentence.

The vocabulary

• Domain expert — the person whose knowledge is being captured.
• Knowledge engineer — the person capturing it and building the system.
• Knowledge base — the rules and facts the system holds.
• Static knowledge — rules and facts that do not change during a consultation.
• Working memory — the facts gathered during this consultation.
• Inference engine — the program that searches the knowledge base.
• Production rule — an if-then rule; the usual form of knowledge here.
• Forward chaining — from the known facts towards what they imply.
• Backward chaining — from a hypothesis towards the facts supporting it.
• Explanation module — the part answering how and why.

The mental model

The difference from a conventional program is where the knowledge lives. In an ordinary program, expertise is spread through the code and the data structures together, so a change in what is known means a change to the program. Here all of it is in data structures and none of it is in the program. Change the rules and the same program solves a different problem in the same domain. There is a second difference worth stating plainly: a conventional program is written to produce correct answers, whereas an expert system is written to behave like a human expert, and human experts are sometimes wrong. That is a design intention, not a defect, and it explains why explanation facilities matter so much here.

Building one has five phases and the failures are not where people look for them. Identification settles what the problem is, its scope, what resources it needs, and what the system is for, with the domain expert in the room. Conceptualisation decides the concepts, the relations between them, the control the reasoning needs, and how fine-grained the knowledge has to be. Formalisation expresses those in a framework the tools support — data structures, inference rules, control strategy. Implementation turns that into a working prototype. Testing has the expert evaluate it and the engineer revise. Most projects fail in the first two phases and the failure is discovered in the last, which is worth knowing before starting one.

The architecture has parts and each has a job. The knowledge base holds static knowledge — rules and facts compiled in, unchanged by a consultation — and dynamic knowledge, which is the working memory: it starts empty, fills with what the user tells the system as the consultation proceeds, and is discarded at the end. The inference engine is the reasoning mechanism plus a control strategy deciding the order rules are applied in. The user interface asks the questions, checks that answers are of the right kind and among the permitted ones, and passes them on. The explanation module answers two questions — how did you reach that, and why are you asking me this — and it is the part that makes the system usable by someone who has to decide whether to believe it. A knowledge acquisition module lets an expert add and revise rules without a programmer, and a case history keeps past consultations for reuse.

Knowledge is written as production rules and read in one of two directions. A rule has an if part, holding conditions in some logical combination, and a then part that may be concluded when they hold. Rules are independent of one another: adding or removing one changes the conclusions reachable and does not require editing the others. Forward chaining starts from the known facts and applies rules towards whatever they imply, until a goal appears or nothing new does. Backward chaining starts from a hypothesis and looks for the facts that would support it, asking the user for what it cannot derive. The direction should follow the problem. Where data arrives first and the question comes later — monitoring, configuration — chain forwards. Where you begin with a hypothesis and want to know what would confirm it, chain backwards, which is why the medical systems of the period worked that way and why a consultation with one feels like being interviewed.

Knowledge acquisition is where the projects actually died. The engineer starts by reading enough to hold a conversation, then interviews the expert systematically, extracts general rules, has the expert check them, translates them into the system's form, and repeats. The problem is that experts are best at doing the thing and worst at saying how they do it. What comes out of an interview is a rationalisation; what makes the expert good is often a judgement they cannot state. On top of that the knowledge goes out of date, so the acquisition never finishes. Every part of that bottleneck is human and none of it got faster with better hardware.

The limits are specific and they are what ended the period. The system cannot respond usefully to a situation its rules do not cover, where a human expert would improvise. It has no common sense, so it will pursue a line that any person in the room can see is absurd. It cannot adapt: it changes only when a person edits the knowledge base. And a mistake in the rules produces a confident wrong answer with a plausible explanation attached. The systems worked in demonstrations and were unmaintainable in service, and that, together with the collapse of the specialised hardware built to run them, is the second winter described in the history topic at the start of this module.

So the last question is whether a problem suits this approach at all, and it should be asked first. Specialised knowledge that a few people have and others need. A payoff high enough to be worth the effort. Experts who are available and willing to cooperate at length. A cost the result can justify. A problem of the right kind — one where expertise is the bottleneck rather than data or computation. Asking this first is the check the field skipped when the approach was fashionable, and it is the transferable lesson: the same question is worth asking of every technology arriving with that much confidence attached.

What you should now be able to explain or do

Say what an expert system is and give both differences from a conventional program. List the five phases of building one and say where the failures happen. Describe the architecture part by part and say what each part is for, including the two kinds of knowledge. Write production rules and run both chaining directions over them, choosing the direction from the problem. Describe the knowledge acquisition process and explain why it is the bottleneck. State the four limits and connect them to the second AI winter. Judge whether a given problem suits an expert system.

Check yourself