1 / 32

Famous Expert Systems

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

wright
Download Presentation

Famous Expert Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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.

  3. DENDRAL Winston

  4. DENDRAL Winston

  5. DENDRAL Winston p. 200

  6. 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

  7. DENDRAL • Example rule for analyzer: Winston 201 • Matcher is involved: needs expert knowledge in knowing when some peaks are more important than others

  8. 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.

  9. MACSYMA p.136-7 Harmon

  10. 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

  11. 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.

  12. HEARSAY Harmon 138

  13. HEARSAY Harmon 139

  14. 4. INTERNIST/CADUCEUS • Developed at U of Pittsburgh in early 1970's, and used ever since • 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 with "scores" for diseases • Tools: programmed in Lisp • Results: widely used, still being developed.

  15. INTERNIST p.141-144 Harmon

  16. INTERNIST

  17. 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 •

  18. MYCIN p.16-20 Harmon

  19. 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.

  20. PROSPECTOR p. 146 Harmon

  21. PROSPECTOR p. 145 Harmon

  22. 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!

  23. PUFF p.150 Harmon

  24. PUFF p. 151 Harmon

  25. 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: In use by DEC and performs better than previous experts (since fired)

  26. XCON p. 156 Harmon

  27. 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)

  28. Some other famous systems • DELTA/CATS: - diagnose and repair diesel locomotives - developed in LISP, but ported to FORTRAN (a common phenomena) • DRILLING ADVISOR: - diagnose oil drilling problems - rule-based, exhaustive backward chaining with uncertainty, frames • GENESIS: - designs molecular genetics experiments and procedures - 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!)

  29. Conclusion p. 170 Harmon

  30. 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

  31. 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

  32. 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

More Related