Expert Systems: Types, Architecture & Fuzzy Logic

TAKEAWAYS:

• Expert systems emulate human expertise using knowledge bases and inference engines to solve complex problems in domains like medicine, finance, or engineering.
• The architecture of an ES includes a user interface, knowledge base, inference engine, and explanation subsystem, each playing a critical role in decision-making.
• Fuzzy logic enables ES to handle uncertainty by representing truth values as degrees (0–1) rather than binary (true/false), making it ideal for real-world ambiguity.
• Types of ES (rule-based, case-based, model-based) differ in how they store and retrieve knowledge, with rule-based systems being the most common.
• Errors in ES development stem from knowledge acquisition bottlenecks, incomplete rules, or overfitting to specific scenarios.
• Real-world applications like eSewa’s fraud detection (rule-based) or Khalti’s credit scoring (fuzzy logic) demonstrate how ES improve efficiency and accuracy.

What is an Expert System?

An expert system (ES) is a computer program designed to mimic the decision-making ability of a human expert in a specific domain. Unlike general AI, ES focuses on narrow, well-defined tasks (e.g., diagnosing diseases, approving loans, or configuring hardware). The core idea is to encode human expertise into a machine-readable format, allowing non-experts to access high-quality decisions.

How Does an ES Work?

An ES operates by:

1. Acquiring knowledge from domain experts (e.g., doctors, engineers).
2. Storing knowledge in a structured format (rules, cases, or models).
3. Applying reasoning to solve problems using an inference engine.
4. Explaining decisions to users (e.g., "Why was this loan rejected?").

Architecture of an Expert System

The architecture of an ES consists of four key components, visualized below:

graph TD
    A["User Interface"] -->|"Inputs/Outputs"| B["Knowledge Base"]
    B -->|"Rules/Cases"| C["Inference Engine"]
    C -->|"Reasoning"| D["Explanation Subsystem"]
    D -->|"Justifications"| A

1. User Interface:

   • Acts as the bridge between the user and the ES.
   • Example: A doctor inputs patient symptoms via a GUI.
   • Real-world tie: eSewa’s chatbot uses a UI to guide users through service requests (e.g., "Your bill amount is Rs. X; confirm?").

2. Knowledge Base:

   • Stores domain-specific knowledge in one of three forms:
     • Rules (IF-THEN statements, e.g., "IF fever > 101°F THEN suspect malaria").
     • Cases (past examples, used in case-based reasoning).
     • Models (mathematical or simulation-based, e.g., financial risk models).
   • Visual: A rule-based knowledge base looks like this:

3. Inference Engine:

   • The "brain" of the ES that applies reasoning techniques (forward/backward chaining) to derive conclusions.
   • Example: If the rule base says "IF symptom X AND symptom Y THEN disease Z," the engine checks for X and Y in the input.
   • Worked Example: Problem: A bank approves loans based on rules like:
     • IF credit_score > 700 AND income > 50000 THEN approve_loan.
     • IF loan_amount > 1000000 THEN require_collateral. Input: A customer has credit_score = 720, income = 60000, and loan_amount = 800000. Inference:
     1. Engine matches credit_score and inference → approve_loan (forward chaining).
     2. loan_amount does not trigger collateral rule → final decision: approve.

4. Explanation Subsystem:

   • Provides transparency by explaining how conclusions were reached.
   • Example: "Loan approved because your credit score (720) and income (Rs. 60,000) meet our criteria."
   • Why it matters: Regulators (e.g., Nepal Rastra Bank) require explainability in automated lending systems.

Types of Expert Systems

ES are classified based on their knowledge representation and reasoning approach. Below is a comparison table:

Fuzzy Logic in Expert Systems

Fuzzy logic extends classical logic (true/false) to handle partial truths using degrees of membership (0–1). This is critical for real-world systems where data is noisy or ambiguous.

How Fuzzy Logic Works

1. Fuzzification: Convert crisp inputs into fuzzy sets (e.g., "temperature = 38°C" → "fuzzy hot = 0.8").
2. Rule Evaluation: Apply fuzzy rules (e.g., "IF temperature is hot THEN risk is high").
3. Aggregation: Combine results from multiple rules.
4. Defuzzification: Convert fuzzy output back to a crisp value (e.g., "risk = 75%").

Visual: The membership function for "hot temperature" might look like this:

Worked Example: Traffic Light Control (Nepal’s Kathmandu Traffic)

Problem: Adjust traffic light timings based on fuzzy inputs like "vehicle count" and "pedestrian density." Fuzzy Rules:

• IF vehicle_count is high AND pedestrian_count is low THEN green_light_duration is long.
• IF vehicle_count is low AND pedestrian_count is high THEN green_light_duration is short.

Input:

• vehicle_count = 45 (fuzzy "high" = 0.7), pedestrian_count = 5 (fuzzy "low" = 0.9). Inference:

1. Apply rule 1: min(0.7, 0.9) = 0.7 → "long duration" contribution = 0.7.
2. Rule 2 is irrelevant here.
3. Defuzzify: Output = green_light_duration = 70% of default (e.g., 40 seconds instead of 30).

Real-world tie: Pathao’s dynamic pricing uses fuzzy logic to adjust fares based on fuzzy inputs like "demand," "driver availability," and "time of day."

Sources of Errors in Expert System Development

Errors in ES development typically arise from three bottlenecks:

1. Knowledge Acquisition Bottleneck:

   • Cause: Experts may struggle to articulate their knowledge clearly.
   • Example: A cardiologist knows how to diagnose heart disease but may not be able to list all rules explicitly.
   • Solution: Use interview techniques or protocol analysis to extract rules.

2. Incomplete or Inconsistent Knowledge Base:

   • Cause: Missing rules or contradictory rules (e.g., "IF X THEN Y" and "IF X THEN NOT Y").
   • Example: A loan approval system might approve a loan for a high-risk applicant due to conflicting rules.
   • Visual:

3. Overfitting:
   • Cause: The ES performs well on training data but fails on new data.
   • Example: A medical ES trained only on Kathmandu patients may misdiagnose a patient from Pokhara due to regional differences.
   • Solution: Use cross-validation and diverse training data.

Development Life Cycle of an Expert System

The life cycle follows these six phases, akin to software development but with a focus on knowledge engineering:

1. Problem Identification:

   • Define the scope (e.g., "Build an ES to diagnose dengue fever").
   • Key question: Can the problem be solved with current knowledge?

2. Knowledge Acquisition:

   • Gather rules from experts via interviews, documents, or observation.
   • Tool: ROMC approach (Repertory Grid, Observation, Modeling, Case Studies).

3. Knowledge Representation:

   • Choose a format (rules, cases, or models) and structure the knowledge base.
   • Example: Representing "dengue symptoms" as:

     IF fever > 38°C AND headache AND joint_pain THEN dengue_likelihood = high
     

4. System Design:

   • Design the architecture (UI, inference engine, etc.).
   • Tip: Use modular design for easier updates.

5. Implementation:

   • Build the system using tools like CLIPS (rule-based) or WEKA (case-based).

6. Testing & Maintenance:

   • Validate with experts and real-world data.
   • Example: Test the dengue ES on 100 patient cases before deployment.

In the Real World

1. eSewa’s Fraud Detection:

   • Idea Used: Rule-based expert system.
   • How: eSewa’s backend uses rules like "IF transaction_amount > Rs. 50,000 AND user_location ≠ billing_location THEN flag_for_review" to detect fraud. The system integrates with Nepal Police’s database for verification.
   • Visual:

2. Khalti’s Credit Scoring:

   • Idea Used: Fuzzy logic + rule-based hybrid system.
   • How: Khalti evaluates loan applications using fuzzy rules for ambiguous inputs (e.g., "income stability" is a fuzzy set). For example:
     • IF income_stability is low (0.6) AND credit_history is poor (0.7) THEN loan_approval is low (0.5).
   • Impact: Reduces default rates by 30% compared to traditional scoring.

3. NTC’s Network Fault Diagnosis:

   • Idea Used: Case-based reasoning (CBR).
   • How: When a fiber-optic cable fails in Nepal, NTC’s ES retrieves similar past cases (e.g., "cable cut by construction near Chyasal") and suggests solutions (e.g., "dispatch team to Chyasal").
   • Worked Example:
     • New Case: "No signal in Dhulikhel."
     • Retrieved Case: "2022 outage in Dhulikhel caused by tree branch."
     • Adaptation: "Check for tree branches near Dhulikhel tower."
     • Solution: "Send crew to trim branches."

4. Nepal Rastra Bank’s Loan Approval:

   • Idea Used: Model-based ES.
   • How: NRB uses simulation models to predict loan defaults based on macroeconomic factors (e.g., inflation rate, GDP growth). Fuzzy logic handles subjective factors like "bank reputation."

Exam Tip

This unit is conceptual but heavily visual—expect questions that ask you to:

1. Draw and label the architecture of an ES (prioritize the 4 components).
2. Compare types of ES (rule-based vs. case-based vs. fuzzy) in a table with pros/cons.
3. Explain fuzzy reasoning with a step-by-step worked example (like the traffic light or loan approval above).
4. Discuss errors in ES development—always link to knowledge acquisition bottlenecks.
5. Relate to Nepal: Use eSewa, Khalti, or NTC as examples for rule-based/fuzzy systems.

Common Pitfalls:

• Forgetting the explanation subsystem in the architecture (it’s often overlooked but critical for exams).
• Confusing forward chaining (data-driven) with backward chaining (goal-driven) in inference engines.
• Ignoring fuzzification/defuzzification steps in fuzzy logic questions.

High-Score Strategy:

• For short notes (e.g., "ROMC approach"), list the four techniques and give a one-sentence example for each.
• For long answers, start with a definition, then visualize (draw a diagram), and end with a real-world tie (e.g., "Like Khalti’s credit scoring...").