Unit 3: Expert systems

I. Orientation

Expert systems are a major application of artificial intelligence designed to reproduce the problem-solving behaviour of a human specialist within a limited domain. They became prominent in the 1970s and 1980s through systems such as MYCIN, which assisted with bacterial infection diagnosis, and DENDRAL, which interpreted chemical mass spectra. Their governing principle is to separate specialist knowledge from the reasoning mechanism so that knowledge can be represented, applied, inspected, and updated systematically.

• Domain-specific intelligence: An expert system normally addresses a restricted field, such as medical diagnosis, mineral exploration, banking, or equipment maintenance.
• Symbolic knowledge representation: Knowledge is stored through rules, facts, frames, cases, or other explicit structures rather than only through numerical model parameters.
• Inference under uncertainty: Conclusions may depend on incomplete or uncertain evidence, represented through certainty factors, probabilities, or fuzzy values.
• Separation of knowledge and control: The knowledge base stores domain information, while the inference engine determines how that information is used.
• Human-oriented interaction: A user interface allows non-specialists to enter evidence, receive conclusions, and sometimes inspect the system’s reasoning.
• Explanation as a design goal: Many expert systems can answer “Why?” or “How?” questions by tracing the rules used to reach a conclusion.
• Limited autonomy: An expert system supports or imitates specialist decision-making; it does not possess general human understanding or consciousness.

II. Definition and purpose

A. Definition of expert systems

An expert system is a computer program that uses explicitly represented specialist knowledge and an inference process to solve problems that normally require human expertise.

• Formal meaning: The system maps observed facts or user-provided evidence to conclusions, recommendations, classifications, or actions within a defined domain.
• Knowledge requirement: A system for diagnosing faults in a pump might contain facts such as “the motor is running” and rules such as:

  IF motor_is_running AND water_flow_is_low
  THEN inspect_intake_filter

Here, IF identifies conditions and THEN identifies the recommended conclusion or action.

• Expert behaviour rather than human identity: The system reproduces selected reasoning patterns, not the expert’s personality, emotions, intuition in its full human sense, or broad common sense.
• Problem-solving scope: MYCIN, for example, was designed around bacterial infections and antibiotic recommendations rather than general medical practice.
• Output types: An expert system may produce a diagnosis, rank possible causes, recommend a treatment, flag a risk, or request additional information.
• Difference from ordinary software: Conventional programs often follow a fixed algorithm for predictable inputs; an expert system applies a changing body of rules to interpret evidence and may explain its conclusion.

III. Architecture of an expert system

A. Architecture of an expert system

The architecture of an expert system consists of cooperating components that store knowledge, reason with it, communicate with users, and maintain a record of the consultation.

• Knowledge base: This contains domain-specific facts, rules, relationships, heuristics, and sometimes cases.
  • A rule-based medical system may store IF fever AND rash THEN consider_measles.
  • A fact may be patient_has_fever = true.
• Inference engine: This matches known facts against rules, selects applicable rules, and derives new facts or conclusions.
• Working memory: Also called the fact base or blackboard, this holds information about the current problem, such as symptoms entered during one consultation.
• User interface: This collects user observations and presents questions, recommendations, warnings, and explanations.
• Explanation facility: This records reasoning steps so the system can state which rules supported a conclusion or why particular evidence was requested.
• Knowledge-acquisition component: This helps a knowledge engineer capture information from specialists, documents, databases, or previous cases.
• External interfaces: Sensors, hospital records, laboratory databases, or industrial controllers may supply real-time evidence.
• Typical information flow: The user supplies facts; working memory stores them; the inference engine activates relevant knowledge-base rules; the system returns a conclusion through the interface.
• Architecture distinction: The knowledge base is domain content, whereas the inference engine is the general reasoning mechanism. The same engine can potentially operate with a different knowledge base.

IV. Knowledge representation and reasoning

A. Knowledge bases and inference engines

Knowledge bases and inference engines are the central reasoning partnership: the knowledge base states what is known, and the inference engine determines what follows from it.

• Declarative knowledge: Facts describe objects or conditions, such as temperature = 95°C, engine_will_not_start, or patient_has_cough.
• Procedural or heuristic knowledge: Rules express practical specialist guidance rather than guaranteed laws:

  IF battery_voltage < 11.5 V
  THEN battery_is_probably_weak

battery_voltage is an observed variable measured in volts; < is a comparison operator.

• Production rules: A rule usually has an antecedent, introduced by IF, and a consequent, introduced by THEN. Several conditions may be joined by AND or OR.
• Forward chaining: Reasoning begins with available facts and moves toward conclusions.
  1. Fact: smoke_detected.
  2. Rule: IF smoke_detected THEN possible_fire.
  3. New fact: possible_fire.
• Backward chaining: Reasoning begins with a possible goal and works backward to identify facts needed to prove it. A diagnostic system may begin with possible_fuel_failure and ask whether fuel pressure is low.
• Conflict resolution: If several rules are applicable, the engine may prefer the rule with greater specificity, higher priority, more recent evidence, or greater certainty.
• Uncertainty handling: Certainty factors, Bayesian probabilities, or fuzzy membership values can express that a conclusion is plausible rather than certain. A rule might assign 0.7 confidence to a suspected fault, although the meaning of that number depends on the system’s formal scheme.
• Inference cycle: A simplified cycle is:

  repeat
      match rules against working memory
      select one applicable rule
      execute its conclusion or action
      update working memory
  until a goal is reached or no rule applies

match, select, and execute describe the three major stages; the cycle stops when reasoning can no longer progress.

• Worked example: Given engine_will_not_start and battery_voltage = 10.8 V, a rule requiring voltage below 11.5 V can infer battery_is_weak. A second rule can then recommend charging or replacing the battery.

V. Human interaction and explanation

A. The relevance of a user interface

The user interface is essential because an expert system’s usefulness depends not only on its internal reasoning but also on how accurately users provide information and understand the result.

• Evidence collection: The interface asks targeted questions, such as “Is the warning light flashing?” or accepts values such as pressure, temperature, or age.
• Usability: Clear labels, sensible defaults, validation, and appropriate units reduce input errors. A temperature field should distinguish °C from °F.
• Dialogue management: The system should ask only relevant questions. If a user reports that a device has no power, questions about software configuration may be postponed.
• Results presentation: The interface should distinguish a diagnosis, supporting evidence, confidence level, and recommended action rather than displaying an unexplained final label.
• Explanation facility: A “Why?” function may show that a recommendation followed from low_fuel_pressure and engine_cranking; a “How?” function may list the rule chain used.
• User roles: A technician may need detailed sensor readings, whereas a manager may need only risk level and recommended intervention.
• Trust and accountability: Explanations help users identify incorrect assumptions and decide whether to accept or override a recommendation.
• Error handling: The interface should identify missing, contradictory, or impossible data, such as a negative engine temperature where the sensor cannot produce one.
• Human responsibility: In high-risk contexts, such as medicine or aviation, the interface should support professional judgment rather than imply that the computer’s recommendation is automatically correct.

VI. Evaluation of expert systems

A. The advantages and disadvantages of expert systems

The advantages and disadvantages of expert systems arise from their ability to preserve and apply specialist knowledge consistently while remaining dependent on the quality and scope of that knowledge.

• Advantages—consistent decisions: The same rules are applied to comparable cases, reducing variation caused by fatigue, memory failure, or mood.
• Advantages—availability: A system can operate continuously and provide assistance when a human specialist is unavailable, such as an overnight equipment-diagnosis service.
• Advantages—knowledge preservation: Expertise can be captured before an experienced employee retires or leaves an organisation.
• Advantages—speed and scalability: Once facts are entered, thousands of rules can be examined rapidly, making the system useful for fault diagnosis and large-scale screening.
• Advantages—training support: Explanations and hypothetical cases can help less experienced staff learn how experts connect evidence with conclusions.
• Advantages—danger reduction: An expert system can make preliminary assessments in hazardous environments, such as chemical plants or radioactive sites, without immediately exposing a person to danger.
• Disadvantages—knowledge-acquisition bottleneck: Extracting tacit expertise from specialists is difficult because experts may act intuitively and struggle to articulate every decision rule.
• Disadvantages—narrow scope: A system trained for aircraft engine faults may fail when presented with an unrelated electrical or environmental problem.
• Disadvantages—brittleness: Rule-based reasoning can break when evidence is unusual, incomplete, contradictory, or outside the assumptions built into the knowledge base.
• Disadvantages—maintenance cost: Regulations, equipment, diseases, and best practices change; obsolete rules can produce unsafe recommendations unless specialists regularly validate updates.
• Disadvantages—limited common sense: The system may correctly apply a rule while failing to understand ordinary context, social consequences, or an exception obvious to a human.
• Disadvantages—bias and poor data: If the knowledge source contains discriminatory assumptions or inaccurate rules, the system can reproduce those defects consistently.
• Disadvantages—false confidence: A precise-looking output does not guarantee a correct conclusion, especially when the evidence is weak or the confidence model is poorly calibrated.
• Disadvantages—implementation expense: Interviews, knowledge engineering, testing, interface design, integration, security, and maintenance may cost more than initially expected.
• Balanced use: Expert systems are strongest as decision-support tools in stable, well-defined domains with explainable rules and access to qualified human oversight.