Artificial Intelligence

Knowledge Reasoning And Planning

Expert Systems & Rule-Based AI

An expert system is an AI program that emulates the decision-making of a human expert within a narrow, well-defined domain, using a base of explicitly encoded r

JrCodex·8 min read

Jr Codex AI Notes

Level: Intermediate Prerequisites: Chapter 5 Time to complete: ~25 minutes


Table of Contents

  1. What is an Expert System?
  2. The Architecture of an Expert System
  3. Building a Small Expert System
  4. Certainty Factors — Handling Imperfect Confidence
  5. Famous Historical Expert Systems
  6. Why Expert Systems Fell Out of Favor
  7. Where Rule-Based AI Still Matters Today
  8. Summary & Next Steps

1. What is an Expert System?

An expert system is an AI program that emulates the decision-making of a human expert within a narrow, well-defined domain, using a base of explicitly encoded rules — a direct, practical application of everything built across this module: knowledge representation (Chapter 1), logic (Chapters 2-3), and inference (Chapter 4).

The Core Idea
─────────────────────────────────────────
  Capture an EXPERT's knowledge as a set of IF-THEN rules,
  then let the system apply INFERENCE (Chapter 4) to answer
  questions or make recommendations — without the human
  expert needing to be personally consulted each time.
─────────────────────────────────────────

Module 1, Chapter 2's history covered expert systems' 1980s commercial boom (and subsequent bust) — this chapter shows exactly how they work mechanically.


2. The Architecture of an Expert System

Three Core Components
─────────────────────────────────────────
  Knowledge Base:     the collection of IF-THEN rules,
                        encoded by "knowledge engineers"
                        working with domain experts
                        (directly built on Ch.1's representation
                        techniques)

  Inference Engine:      the reasoning mechanism that APPLIES
                            those rules to specific facts —
                            typically forward or backward
                            chaining (Chapter 4)

  User Interface:           how a user provides facts/answers
                              questions, and receives the
                              system's conclusion/explanation
─────────────────────────────────────────
Expert System Architecture Diagram
─────────────────────────────────────────
  User ──── facts/answers ────►  [Inference Engine]
                                        │      ▲
                                        ▼      │
                                  [Knowledge Base]
                                   (IF-THEN rules)
                                        │
                                        ▼
  User ◄──── conclusion + explanation ────
─────────────────────────────────────────

The "explanation" capability is a defining, valuable feature of classical expert systems — because reasoning proceeds through explicit, human-readable rules, the system can show exactly which rules fired to reach its conclusion, a transparency property that Module 6's discussion of explainable AI (XAI) revisits for modern, less transparent ML/DL systems.


3. Building a Small Expert System

A simplified medical-diagnosis-style expert system, directly using Chapter 4's backward chaining:

class ExpertSystem:
    def __init__(self):
        self.rules = []      # list of (conditions, conclusion, confidence)
        self.known_facts = {}
 
    def add_rule(self, conditions, conclusion, confidence=1.0):
        self.rules.append((conditions, conclusion, confidence))
 
    def ask_user(self, fact):
        """In a real system, this would prompt the user; simulated here."""
        return self.known_facts.get(fact)
 
    def prove(self, goal, depth=0):
        indent = "  " * depth
        if goal in self.known_facts:
            return self.known_facts[goal]
 
        # Try to find a rule concluding this goal
        for conditions, conclusion, confidence in self.rules:
            if conclusion == goal:
                print(f"{indent}Checking rule: {conditions}{conclusion}")
                if all(self.prove(c, depth + 1) for c in conditions):
                    print(f"{indent}{goal} confirmed via rule (confidence={confidence})")
                    self.known_facts[goal] = True
                    return True
 
        # No rule fired — ask directly (a "leaf" fact)
        answer = self.ask_user(goal)
        return answer if answer is not None else False
 
 
expert = ExpertSystem()
expert.add_rule(["fever", "cough"], "flu_suspected", confidence=0.8)
expert.add_rule(["flu_suspected", "body_aches"], "recommend_rest_and_fluids", confidence=0.9)
 
# Simulate user-provided facts
expert.known_facts = {"fever": True, "cough": True, "body_aches": True}
 
result = expert.prove("recommend_rest_and_fluids")
print(f"\nFinal recommendation issued: {result}")

This is directly built from Chapter 4's backward chaining pattern, with confidence scores added — Section 4 covers exactly why raw true/false confidence isn't enough for realistic domains like medicine.


4. Certainty Factors — Handling Imperfect Confidence

Real expert knowledge is rarely perfectly certain ("fever and cough usually suggests flu, but isn't a guarantee") — classical expert systems (notably MYCIN, Section 5) introduced certainty factors to represent this.

def combine_certainty_factors(cf1, cf2):
    """
    Combines two independent certainty factors (each in [-1, 1],
    where 1 = certainly true, -1 = certainly false, 0 = unknown).
    This is MYCIN's classic combination formula.
    """
    if cf1 >= 0 and cf2 >= 0:
        return cf1 + cf2 * (1 - cf1)
    elif cf1 < 0 and cf2 < 0:
        return cf1 + cf2 * (1 + cf1)
    else:
        return (cf1 + cf2) / (1 - min(abs(cf1), abs(cf2)))
 
# Two independent pieces of evidence, each moderately supporting "flu"
cf_from_fever = 0.6
cf_from_cough = 0.5
combined = combine_certainty_factors(cf_from_fever, cf_from_cough)
print(f"Combined certainty: {combined:.2f}")      # higher than either alone — CORROBORATING evidence
Certainty Factors vs Probability (Module 4 Preview)
─────────────────────────────────────────
  Certainty factors were a PRAGMATIC, heuristic approach —
  computationally simple, and reasonably intuitive for domain
  experts to assign by hand.

  They are NOT the same as formal PROBABILITY theory, and can
  produce inconsistent results in some edge cases. Module 4's
  Bayesian networks provide a more mathematically rigorous
  alternative for reasoning under uncertainty — a direct
  successor to this chapter's certainty-factor approach.
─────────────────────────────────────────

5. Famous Historical Expert Systems

MYCIN (1970s, Stanford)
─────────────────────────────────────────
  Domain:      diagnosing bacterial infections, recommending
                 antibiotics
  Approach:      backward chaining (Chapter 4) + certainty
                   factors (Section 4)
  Outcome:         reportedly outperformed some human doctors
                    on its narrow diagnostic task in controlled
                    tests — but was NEVER deployed clinically,
                    partly due to liability/trust concerns and
                    integration difficulty
─────────────────────────────────────────

XCON/R1 (1980s, Digital Equipment Corporation)
─────────────────────────────────────────
  Domain:      configuring custom computer system orders
                 (choosing compatible components)
  Approach:      forward chaining (Chapter 4) over thousands
                   of hand-coded rules
  Outcome:         a genuine major commercial success — saved
                    DEC an estimated tens of millions of dollars
                    annually, one of the clearest ROI stories
                    in AI's history at the time (Module 1, Ch.2)
─────────────────────────────────────────

Both systems demonstrate this module's techniques applied at real scale — MYCIN leaned on backward chaining and confidence handling for diagnosis; XCON leaned on forward chaining for exhaustive, correctness-critical configuration.


6. Why Expert Systems Fell Out of Favor

Directly following up on Module 1, Chapter 2's history of the second AI winter:

The Core Problems
─────────────────────────────────────────
  Knowledge Acquisition Bottleneck:   extracting an expert's
                                        knowledge into precise
                                        IF-THEN rules is SLOW,
                                        expensive, and requires
                                        specialized "knowledge
                                        engineers"

  Brittleness:                          a rule-based system fails
                                          BADLY outside its narrow,
                                          explicitly coded domain —
                                          no graceful degradation,
                                          no generalization

  Maintenance Burden:                      as rule count grows into
                                            the thousands (like XCON),
                                            rules can CONFLICT or
                                            interact in ways nobody
                                            fully understands anymore

  Couldn't LEARN or ADAPT:                   every new scenario
                                              required a human to
                                              manually write a NEW
                                              rule — no ability to
                                              improve from experience
                                              (exactly the gap machine
                                              learning was built to fill)
─────────────────────────────────────────

This is the concrete mechanism behind Module 1, Chapter 3's symbolic-AI trade-off — expert systems are transparent and precise (Section 2's explanation capability) but brittle and expensive to build/maintain, which is precisely what motivated the field's shift toward learning-based methods (the ML/DL notes).


7. Where Rule-Based AI Still Matters Today

Expert systems as a dedicated commercial category faded, but the underlying rule-based technique never disappeared — it persists wherever transparency and precision matter more than learned flexibility:

Modern Rule-Based Systems
─────────────────────────────────────────
  Business rule engines:    automating loan approval,
                              insurance underwriting rules
                              (often legally required to be
                              EXPLAINABLE — directly connecting
                              to Module 6's XAI chapter)
  Compliance/validation systems: enforcing regulatory rules
                                    that must be followed exactly,
                                    with a clear audit trail
  Hybrid AI systems:                combining a learned ML model's
                                       prediction with a rule-based
                                       "safety layer" that overrides
                                       clearly wrong outputs
  Configuration systems:               modern descendants of XCON,
                                          still used for complex
                                          product configuration
─────────────────────────────────────────

The lesson for a modern AI practitioner: rule-based/symbolic techniques and learning-based techniques aren't in competition — knowing when explicit, auditable rules are the right tool (versus when a learned model's flexibility is worth its opacity) is itself a valuable, practical skill.


8. Summary & Next Steps

Key Takeaways

  • An expert system encodes a human expert's domain knowledge as IF-THEN rules, then uses an inference engine (forward/backward chaining, Chapter 4) to answer questions with a transparent, explainable reasoning trail.
  • Certainty factors were expert systems' pragmatic way of handling imperfect confidence — a precursor to the more rigorous probabilistic methods in Module 4.
  • MYCIN (diagnosis) and XCON (configuration) demonstrate expert systems' real capability — XCON in particular was a genuine, large-scale commercial success.
  • Expert systems fell out of favor due to the knowledge-acquisition bottleneck, brittleness outside their narrow domain, and inability to learn or adapt — directly motivating the field's shift toward machine learning.
  • Rule-based AI persists today wherever transparency and auditability matter more than learned flexibility — business rules, compliance systems, and hybrid AI safety layers.

Module 3 Complete — Next Module

You now have the full classical reasoning toolkit: knowledge representation, propositional and first-order logic, inference (forward/backward chaining, resolution), automated planning, and rule-based expert systems. Module 4 extends this into reasoning under uncertainty — where classical logic's strict true/false gives way to probability.

Concept Check

  1. What are the three core architectural components of an expert system?
  2. Why was XCON considered a genuine commercial success while MYCIN, despite strong diagnostic performance, was never clinically deployed?
  3. What specific limitation of expert systems directly motivated the rise of machine learning?

Next Chapter

Module 4: Reasoning Under Uncertainty


Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index