Lecture 25 Case Study Designing Rulebased Expert Systems

Lecture 25

Case Study: Designing Rule-based Expert Systems Automobile Diagnosis Expert System

Introduction • Consider a small problem in automobile diagnosis. • Review the step involved in this task as an example of typical course taken when developing forward chaining rule based systems.

Steps • • Define the problem Define the input data Define the structure (data driven) Write initial code Test Design the interface Expand the system Evaluate the system

Automobile Diagnosis • Attractive area – Useful – Rules readily available • Typically diagnostic systems are based on backward chaining. • Since there can be a number of problems leading to a large set of facts hence it may be advisable to use FWD chaining • Inherently data driven approach to solving automobile diagnosis problem, therefore more natural to use forward chaining.

Task 1: Define the Problem • Learn about automobile diagnostics. Possible sources of information – A good car mechanic – A trouble-shooting manual • Auto-repair manuals – – – Series of tests to identify problem. Decision trees Checklist type tests Sections grouped by principal problems Narrowing down problems: subsystems • Problem to diagnose is hard starting

Subsystems • • Cranking System Ignition System Fuel System Engine Compression System

Decision tree Durkin Fig 10. 1 Engine does not start Test Cranking system good Cranking system bad Test Ignition system good Ignition system bad Test Fuel system good Test Compression system Fuel system bad

1 - Problem Specifications • Scope – ‘Engine does not start’ problems – Address only cranking problems

2 - Define Input Data • Start-up Rule (auto fire on start up) Rule 1: Start IF Task is Start THEN Ask what is the problem?

3 - Define Structure • Data driven structure • Incorporate flow control into the premises of rules, e. g. IF Task is test engine --- Type of test AND Lights are dim --- Result THEN test battery --- Proceed to

4 - Write initial code • Subset of rules that capture the general structure. • Purpose: To verify that we have effectively captured the problems knowledge in our rule structure. • A good structure is one that not only provides correct results but also a template to follow for the development of other rules

Knowledge Base Rule 1: IF Task is start THEN Ask problem Working Memory Task is start What is the problem? Rule 2: IF problem is car does not -car does not start -car gives problem at start at high speeds THEN Task is to test cranking system Rule 3: IF problem is car gives problem at high speeds THEN Task is test fuel system

Knowledge Base Rule 1: IF Task is start THEN Ask problem Rule 2: IF problem is car does not start THEN Task is to test cranking system Rule 3: IF problem is car gives problem at high speeds THEN Task is test fuel system Working Memory Task is start Problem is car does not start

Knowledge Base Rule 1: IF Task is start THEN Ask problem Working Memory Problem is car does not start Task is to test Rule 2: IF problem is car does not cranking system start THEN Task is to test cranking system Rule 3: IF problem is car gives problem at high speeds THEN Task is test fuel system

Knowledge Base Rule 4: IF Task is to test cranking system THEN Ask how engine turns Rule 5: IF Task is to test cranking system AND engine turns slowly/doesn’t turn THEN Cranking system is not working AND Task is to test battery connection Rule 6: IF Task is to test cranking system AND Engine turns normally THEN Cranking system is working AND Task is to test ignition system Working Memory Problem is car does not start Task is to test cranking system How does the engine turn upon ignition? -slowly/doesn't turn -normally

Knowledge Base Working Memory Rule 4: IF Task is to test cranking Problem is car does system not start THEN Ask how engine turns Task is to test Rule 5: IF Task is to test cranking system AND engine turns slowly/doesn’t Engine turns slowly/doesn’t turn THEN Cranking system is not working AND Task is to test battery connection Rule 6: IF Task is to test cranking system AND Engine turns normally THEN Cranking system is working AND Task is to test ignition system

Knowledge Base Working Memory Rule 7: IF Task is to test battery connection THEN Ask about Screwdriver test Problem is car does not start Engine turns slowly/doesn’t turn Rule 8: IF Task is to test battery connection AND Screwdriver test shows that lights brighten OR Screwdriver test shows that lights do not turn on THEN Problem is a bad battery connection Rule 9: IF Task is to test battery connection AND Screwdriver test shows that lights don’t brighten THEN Battery connection is good AND Task is test battery • Cranking system is not working • Task is to test battery connection Do screwdriver test. What happens to the lights? -brighten -not on -don’t brighten

Knowledge Base Working Memory Rule 7: IF Task is to test battery connection THEN Ask about Screwdriver test Problem is car does not start Engine turns slowly/doesn’t turn Rule 8: IF Task is to test battery connection AND Screwdriver test shows that lights brighten OR Screwdriver test shows that lights do not turn on THEN Problem is a bad battery connection Rule 9: IF Task is to test battery connection AND Screwdriver test shows that lights don’t brighten THEN Battery connection is good AND Task is test battery • Cranking system is not working • Task is to test battery connection • Screwdriver test shows that lights brighten

Knowledge Base Working Memory Rule 7: IF Task is to test battery connection THEN Ask about Screwdriver test Problem is car does not start Engine turns slowly/doesn’t turn Rule 8: IF Task is to test battery connection AND Screwdriver test shows that lights brighten OR Screwdriver test shows that lights do not turn on THEN Problem is a bad battery connection Rule 9: IF Task is to test battery connection AND Screwdriver test shows that lights don’t brighten THEN Battery connection is good AND Task is test battery • Cranking system is not working • Task is to test battery connection • Screwdriver test shows that lights brighten • Problem is a bad battery connection

Design the Interface • Begin design of interfaces in parallel with development of rules • Interfaces interactive • Graphical user interface • Display screens – Introduction screen – Intermediate findings screen – Conclusions • Question screens

Design of Expert Systems • Software Engineering methodology for developing practical ES • ESDLC • General Stages – Feasibility study – Rapid Prototyping – Alpha system (in-house verification) – Beta system (tested by users) – Maintenance and Evolution

Planning Phase • • Feasibility Assessment Resource Allocation (HR, time, financial) Task Phasing and Scheduling Determine high-level requirements

Knowledge Acquisition • Most important stage in the development of ES • During this stage the knowledge engineer works with the domain expert to acquire, organize and analyze the domain knowledge for the ES. • Knowledge acquisition bottleneck – – Acquisition from expert Define strategy (consider various options) Identify concrete knowledge elements Group and classify knowledge. Develop hierarchical representation where possible

Knowledge Acquisition (Cont. ) • Identify knowledge source. Expert in the domain – Identify potential sources (human expert, expert handbooks/manuals), e. g. car mechanic expert system’s knowledge engineer may chose a mix of interviewing an expert mechanic and using a mechanics trouble-shooting manual. – Tip: • Limit the number of knowledge sources (experts) for simple domains to avoid scheduling and view conflicts • However, a single expert approach may only be applicable to restricted small domains – – Rank by importance Rank by availability Select expert/panel of experts If more than one expert has to be consulted, consider a blackboard system. More than one knowledge source (kept partitioned), interact through interface called Blackboard

Knowledge Elicitation • Getting knowledge from the expert knowledg elicitation vs. broader term knowledge acquisition • Elicitation methods may be broadly divided into: – Direct Methods • Interviews – Very good at initial stages – Balance between structured (multiple choice, rating scale) and un-structured interviewing) – Record interviews (transcribe or tape) – Mix of open and close ended questions • Informal Discussions (gently control digression, but do not offend expert by frequent interruption) – Indirect Methods • Questionnaire

Problems with Elicitation • not be able to effectively articulate her knowledge • provide irrelevant information. • Provide incomplete knowledge • Provide inconsistent or incorrect knowledge

Knowledge Acquisition Techniques • Knowledge elicitation by interview • Brainstorming session with one or more experts – Introduce some structure • Define problem at hand • Prompt for ideas • Looks for converging lines of though – Electronic brainstorming • On-site observation • Documented organizational expertise, e. g. troubleshooting manuals

Knowledge Analysis • Analyze and structure the knowledge gained during the knowledge acquisition phase • Identify specific knowledge elements • From the notes taken during the interview sessions, extract specific – – – Strategies (as a list of points) Translate to rules Heuristics Identify concepts Represent concepts and their relationships using cognitive maps

Cognitive Map Example Age Patient Medical History Gets Tests Echo Cardiogram Blood Sugar Blood hematology Personal History

Knowledge Analysis (Cont. ) • Inference networks – Graphical representation of system’s rules Diagnosis is Anemia AND Blood test shows low hemoglobin level Symptoms indicate anemia OR Inner surface of eyes lids pale OR Consistent Low Blood Pressure Feeling Listless

Knowledge Analysis (Cont. ) • Flowchart – Sequence of steps – Depict the order of application of rule sets – e. g. Doctor begins by asking symptoms • If not indicative of some disease the doctor will not ask for specific tests. • If symptomatic of two or three potential diseases – The doctor decided disease to check for first – Rules out potential diagnoses in some heuristic sequence

Knowledge Design • At the end of this phase, we have – Knowledge definition – Detailed design • Decide how to represent knowledge – Rules and Logic – Frames • Decide a development tool. Consider whether it supports your planned strategy. • Internal fact structure • Mock interface

Code • • • Coding Prepare tests Comment code Develop User’s manual. Installation guide At the end of this phase the system is ready to be tested.

Linear Model for ES development Planning Work Plan Knowledge Acquisition and Analysis Knowledge Baseline Knowledge Design Code Knowledge Verification System Evaluation Formal in-house testing Product evaluation by users Encoding of knowledge Using a development tool Design Baseline

How to do it? A Practical Approach • Problem definition • Requirement engineering – Knowledge acquisition • Flow charting, knowledge elicitation • Design • Implementation & testing

Problem Definition • This system is to replace old experience judges of serious crime cases like murder, theft, burglary, kidnapping, and terrorism

Severity • Complex relationship between the decision factors. • Specific to each offense. 1 Severity 0 0 0 Variable

Severity Murder 1 1 Severity 0 0 0 100 Victim Age 0 1 Intention Minimum of both

Severity Terrorist Attack 1 Severity 0 5 100 loss

Severity Kidnap 1 1 Severity 0 0 0 90 Confinement 0. 5 100 Ransom Maximum of both

Severity Burglary 1 Severity 0 0. 01 150 Theft amount

Severity Concession 1 Severity (CONCESSION) 0 1 10 Plead guilty hearing number

Severity Penalty 1 Severity 0 1 25 Grade

Sentence Creation Logic • General Formula – Sentence = Min + Severity x (MAX – MIN) • E. g. for murder – Prison = 3 + severity x (33 -3) – Fine = 1 + severity x (100 -1) Same model applies for concession and penalty

Flow Chart Murder cases Terrorism cases start Case feed Kidnap case Murder sentences Penalties Concessions Burglary cases