Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!nike!ucbcad!ucbvax!HT.AI.MIT.EDU!hamscher From: hamscher@HT.AI.MIT.EDU (Walter Hamscher) Newsgroups: mod.ai Subject: queries about expert systems Message-ID: <8609250525.AA05454@ucbvax.Berkeley.EDU> Date: Sat, 20-Sep-86 15:44:00 EDT Article-I.D.: ucbvax.8609250525.AA05454 Posted: Sat Sep 20 15:44:00 1986 Date-Received: Thu, 25-Sep-86 05:06:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 107 Approved: ailist@sri-stripe.arpa Date: Thu, 18 Sep 1986 17:10 EDT From: LIN@XX.LCS.MIT.EDU 1. Production systems are the implementation of many expert systems. In what other forms are "expert systems" implemented? [I use the term "expert system" to describe the codification of any process that people use to reason, plan, or make decisions as a set of computer rules, involving a detailed description of the precise thought processes used. If you have a better description, please share it.] ``Expert System'' denotes a level of performance, not a technology. The particularly important aspirations are generality and robustness. Every program strives for some degree of generality and robustness, of course, but calling a program an expert system means it's supposed to be able to do the right thing even in situations that haven't been explicitly anticipated, where ``the right thing'' might just be to gracefully say ``I dunno'' when, indeed, the program doesn't have the knowledge needed to solve the problem posed. Production systems, or, more accurately, programs that work by running a simple interpreter over a body of knowledge represented as IF-THEN rules, ease the construction of simple expert systems because it's possible to encode the knowledge without having to commit to a particular order or context of using that knowledge. The interpreter determines what rule to apply next at runtime, and so long as you don't include contradictory rules or assume a particular order of application, such systems are easy to construct and work pretty well, i.e. can be general (solve a wide variety of problem instances) and robust (degrade gracefully by saying ``i dunno'' (no rules, or only very general rules apply) in unusual situations, rather than trapping out with an error). That may not have seemed like an answer to question #1, so let me return to it explicitly. Production systems are not the only technology for building expert systems, but pattern-directed invocation is a theme common to all expert systems, whatever technology is used. Let me explain. Another popular technology for expert systems (in the medical domain, especially) might be called Frames and Demons. Facts are organized in a specialization hierarchy, and attached to each fact may be a bunch of procedures (demons) that are run when the fact is asserted, or denied, when the program needs to figure out whether the fact is true or not, etc. Running a demon may trigger other demons, or add new facts, or new demons, and so the system grinds away. The underlying principle is the same as in production systems: there is a large body of domain specific knowledge, plus a simple interpreter that makes no initial commitment to the order or context in which the facts are going to be used. The name of the game is pattern-directed invocation: the next action to take is selected from among the ``rules'' or ``methods'' or ``demons'' that are relevant to the current situation. This characteristic is not unique to expert systems, but (I think) every program that has ever been called an expert system has this characteristic in common, and moreover that it was central to its behavior. 2. A production system is in essence a set of rules that state that "IF X occurs, THEN take action Y." System designers must anticipate the set of "X" that can occur. What if something happens that is not anticipated in the specified set of "X"? I assert that the most common result in such cases is that nothing happens. Am I right, wrong, or off the map? In most implementations of production systems, if the current situation is such that no rules match it, nothing happens (maybe the program prints out the atom 'DONE :-). If the system is working in a goal-directed fashion (e.g. it's trying to find out under what circumstances it can take action Y (action Y might be "conclude that Z has occurred")) and there aren't any rules that tell it anything about Y, again, nothing happens: it can't conclude Z. In practice, there are always very general rules that apply when nothing else does. Being general, they're probably not very helpful: "IF () THEN SAY Take-Two-Aspirin-And-Call-Me-In-The-Morning." The same applies to any brand of pattern-directed invocation. However, it's getting on the hairy edge of matters to say "System designers must anticipate the set of X that can occur." The reason is that productions (methods, demons) are supposed to be modular; independent of other productions; typically written to trigger on only a handful of the possibly thousands of features of the current situation. So in fact I don't need to anticipate all the situations that occur, but rather ``just'' figure out all the relevant features of the space of situations, and then write rules that deal with certain combinations of those features. It's like a grammar: I don't have to anticipate every valid sentence, except in the sense that I need to figure out what all the word categories are and what local combinations of words are legal. Now, to hone your observation a bit, I suggest focusing on the notion of ``figuring out all the relevant features of the space of situations.'' That's what's difficult. Experts (including carbon-based ones) make mistakes when they ignore (or are unaware of) features of the situation that modify or overrule the conclusions made from other features. The fundamental problem in building an expert system that deals with the real world is not entirely in cramming enough of the right rules into it (although that's hard), it's encoding all the exceptions, or, more to the point, remembering to include in the program's model of the world all the features that might be relevant to producing exceptions. End of overly long flame. Walter Hamscher P.S. I am not an AI guru, rather, a mere neophyte disciple of the bona fide gurus on my thesis committee.