320 likes | 665 Views
Famous Expert Systems. Before expert systems ("in the beginning...") • Detailed Operation Procedures (DOP's): used by aeronautics industry and NASA, they are expert knowledge codified in written form. - Not implemented on a computer. However, using a DOP is like manually
E N D
Famous Expert Systems Before expert systems ("in the beginning...") • Detailed Operation Procedures (DOP's): used by aeronautics industry and NASA, they are expert knowledge codified in written form. - Not implemented on a computer. However, using a DOP is like manually following an algorithm by hand (ignizio p.49) • Heuristic programming: use heuristics to solve large, complex computational problems (early 1960's) - Controversy whether expert systems are just examples of heuristic programming
1. DENDRAL • First expert system • Project began at Stanford in mid 1960's, and is still being used. • Domain: Organic chemistry - mass spectrometry • Task: identify molecular structure of unknown compounds from mass spectra data • Input: Histogram giving mass number/intensity pairs • Output: Description of structure of the compound • Architecture: plan-generate-test with constrained heuristic search • Tools: production rules implemented in Lisp • Results: "Discovery" of knowledge engineering. Many published results.
DENDRAL Winston
DENDRAL Winston
DENDRAL Winston p. 200
DENDRAL Procedure: 1. Spectra data given as input 2. Preliminary analysis determines - necessary compounds -- spectra data - forbidden compounds -- spectra data, expert knowledge 3. Generate and test: a) structure enumerator: can generate all possible compounds - Takes necessary and forbidden lists, and creates a new possible compound - output is formula b) spectra synthesizer: generates spectra data for this compound c) matcher - matches synthesized spectra with actual one - compound with best fit is the one • Note: all compounds checked. Complexity reduced because of the pruning done in step 2
DENDRAL • Example rule for analyzer: Winston 201 • Matcher is involved: needs expert knowledge in knowing when some peaks are more important than others
2. MACSYMA • Developed at MIT since 1968 onwards • Domain: high-performance symbolic math (algebra, calculus, differential equations,...) • Task: carry out complex mathematical derivations • Input: formulae and commands (interactive) • Output: Solutions to tough problems • Method: Brute force (expert techniques are encoded as algorithm) • Architecture: programmed in Lisp (300,000 lines of code) • Results: Widely used, powerful system. • Newest version: Maxima - Free! Open source. - works on Windows, linux, MacOS - maxima.sourceforge.net
MACSYMA p.136-7 Harmon
3. Hearsay I and II • Developed at Carnegie-Mellon in late 1960's • Domain: speech understanding for simple database query • Task: Using specific vocabulary and grammar criteria, generate correct speech recognition • Input: Speech wave • Output: Ordered list of hypotheses of what was said, plus database query based on best guess • Architecture: Opportunistic, agenda-based reasoning, using "blackboard" to record hypotheses from multiple independent knowledge sources • (Definition: Blackboard: common working memory for independent systems) • Tools: Programmed in SAIL
HEARSAY • Results: - proved feasibility of automated speech recognition - pioneering effort in system architecture techniques - blackboard for multiple knowledge sources - power of symbolic computation over purely statistical ones - Spawned other expert system projects.
HEARSAY Harmon 138
HEARSAY Harmon 139
4. INTERNIST/CADUCEUS • Developed at U of Pittsburgh in early 1970's thru mid 80’s • Domain: diagnostic aid for all of internal medicine • Task: medical diagnosis given interactive input • Input: Answers to interactive queries • Output: ordered set of diagnoses • Architecture: forward chaining with "scores" for diseases • Tools: programmed in Lisp • Results: ambitious project; inspired other systems
INTERNIST p.141-144 Harmon
5. MYCIN • Stanford U in mid 70's • Domain: Medical diagnosis for bacterial and meningitis infections • Task: interview physician, make diagnosis and therapy recommendations • Input: Answers to queries • Output: Ordered set of diagnoses and therapies • Architecture: rule-based exhaustive backward chaining with uncertainty • Tools: programmed in LISP (shell called EMYCIN -- empty MYCIN) • Results: not in general use, but was ground-breaking work in diagnostic consultation systems • Made acceptable diagnoses at a rate of 69% (better than human experts!)
MYCIN p.16-20 Harmon
6. Prospector • Developed at SRI international in late 1970's • Domain: exploratory geology • Task: evaluate geological sites • Input: geological survey data • Output: maps and site evaluations • Architecture: rule-like semantic net with uncertainty • Tools: programmed in LISP, and is a descendant of MYCIN • Results: In one blind test, the program identified a previously undiscovered site, thus showing commercial viability of expert systems.
PROSPECTOR p. 146 Harmon
PROSPECTOR p. 145 Harmon
7. PUFF • Developed at Stanford in 1979 • Domain: Diagnosis of obstructive airway diseases using MYCIN's inference engine and a new knowledge base • Task: Take data from instruments and dialog, and diagnose type and severity of disease • Input: instruments, queries • Output: Written report for physician to review and annotate • Architecture: rule-based, exhaustive backward chaining with uncertainty • Tools: EMYCIN (Empty MYCIN) • Results: Reports correct 86% of the time. A 55-rule system is in daily use, running in Basic!
PUFF p.150 Harmon
PUFF p. 151 Harmon
8. XCON (R1) • Originally called R1, developed at Carnegie Mellon and DEC in late 70's • Domain: configure computer hardware • Task: configure VAX systems by projecting the need for subassemblies given a high-level description of the system • Input: Vax system description • Output: list of parts, accessories, and a plan for assembly • Architecture: forward-chained, rule-based, with almost no backtracking • Tools: OPS5, a production system tool • Results: Used by DEC and performed better than previous experts (since fired) - by 1986, processed total of 80,000 orders with 95-98% accuracy - saved DEC $25 million a year
XCON p. 156 Harmon
XCON • as of 1991, XCON has 8000 (!) production rules • a serious problem has developed: maintenance • has been said that XCON replaced 75 experts with 150 XCON maintainers • shows the need for developing better maintenance systems for large expert systems (and other large software systems)
Some other famous systems • DELTA/CATS: - diagnose and repair diesel locomotives - developed in LISP, but ported to FORTRAN (a common phenomenon) • DRILLING ADVISOR: - diagnose oil drilling problems - rule-based, exhaustive backward chaining with uncertainty, frames • GENESIS: - designs molecular genetics experiments and procedures - was used by over 500 research scientists • GATES: - airline gate assignment and tracking system - used by TWA at JFK airport - implemented in Prolog on microcomputers - access database for 100 daily flights, and creates gate assignment in 30 seconds (experts took between 10 and 15 hours, with 1 hour per modification) ( possible extension: lost luggage!)
Conclusion p. 170 Harmon
A typical industrial system • (Byte, Oct 1994) Picker International • Problem domain: • Picker produce sophisticated medical diagnostic machines • needed a system for use by their service technicians • tasks: • intelligent service expert system: full explanation, graphical UI, hypertext user manual • onsite access to main service DB of user site data • capture site data: feedback for knowledge base improvements • use site data to improve products, service effectiveness in future
System • Built with Carnegie Group’s TestBuilder system • shell system geared towards diagnostic systems • systems are typically: hierarchical, rule-based, object-oriented (frames) • multi-level explanation important • rule-level: how, why • deeper level: hypertext manuals (interactive, graphical) • TestBuilder is interactive KB editor and tester • Final system is compiled into DOS executable form • TestView is run-time system • Compared with general-purpose shells, this system is specialized • inference focusses on problem right away, via menu’s or natural language input • completeness sacrificed for efficient focus on possible problem
Conclusions from Pickers system • Incremental design of system • get prototype running on initial problems • build onto it • Can help if Knowledge engineer has domain knowledge • caveat: here, KE is already “computer-oriented” • caveat: problem domain well-adapted to Testbuilder paradigm • On-site capture of new data permits continual update of system for “free” • empirical data capture and DB useful for KB, as well as products themselves • integrated standalone systems (eg. laptops) very handy! • CD ROM’s also can prevent need to download data