Expert systems & AI applications (and their limits)

What an expert system is

An expert system solves problems in a *narrow, well-studied* domain by relying on the knowledge of a human domain expert — combining theoretical understanding with the heuristic rules experience has shown to work. It differs sharply from a general AI problem solver: a general program uses *domain-independent* methods, whereas an expert system trades generality for strong performance in one specialized area. DENDRAL, MYCIN, PROSPECTOR, and XCON (Lesson 0.2) are the canonical successes — and their shared lesson is that domain-specific knowledge beats general-purpose reasoning for hard real-world tasks.

They are built by knowledge engineering: a knowledge engineer and a domain expert iterate — the expert demonstrates and critiques, the engineer encodes the knowledge as rules, and the system is refined on sample problems until it performs well. The hardest part is the knowledge-acquisition bottleneck: much expertise is *tacit*, and experts struggle to state explicitly what they actually do.

Where AI has been applied

Beyond expert systems, the field's recurring application areas are worth a one-line each: game playing (well-defined rules, huge search spaces — the original testbed for heuristic search); automated theorem proving (logic is formal, hence automatable — one of AI's oldest branches); natural language understanding (hard precisely *because* it needs vast background knowledge, not just parsing); planning (state-space search over actions, e.g. robotics); and machine learning (the answer to the "no learning" gap below). Each maps back to the two pillars — representation of a domain, and search through its possibilities.

The five limitations of expert systems (exam-load-bearing)

This is the most testable content in the module — exam and assignment essays repeatedly ask for the limits of expert systems. Learn all five, each with its one-line reason:

Worked example — the five limitations, with MYCIN as the running illustration.

1. No deep / first-principles knowledge. They reason from surface heuristics, not underlying theory. *MYCIN could prescribe for an infection without any model of human physiology* — it knew *symptom → treatment* rules, not how the body works.
2. Brittleness — no robustness at the domain edge. They perform well inside their narrow domain but degrade abruptly (often confidently wrongly) on problems just outside it, with no graceful fallback.
3. Shallow explanation. Their “explanations” only recite the *steps/rules* used; they cannot justify *why* those rules are right from first principles.
4. No learning from experience. Solve the same problem twice and the system repeats the *identical* computation — it never gets faster or better. A human doctor improves with each case; an expert system does not, until a programmer manually updates it.
5. Narrow domain + hard to verify. Each system covers one small area, and proving such a rule base *correct* is genuinely difficult — a serious matter when the domain is medicine or air-traffic control.

The “no learning” limitation is the one most damaging to claims of intelligence, and it is precisely what motivated machine learning (Module 8) — the field's response to expert systems' static nature.

How this module sets up the course

You now have the frame the rest of COMP 456 fills in: knowledge representation (Modules 1, 6) and search (Modules 3–4) are the pillars; logic (Module 1) and Prolog (Module 2) are the tools for encoding and reasoning; production / expert systems (Modules 5–6) operationalize the knowledge engineer's rules; and machine learning (Module 8) is the field's answer to the “no learning” limitation you just learned. Every later module is one of these pillars, sharpened.