No course on Expert systems is complete without a discussion of Mycin. As mentioned above, Mycin was one of the earliest expert systems, and its design has strongly influenced the design of commercial expert systems and expert system shells.
Mycin was an expert system developed at Stanford in the 1970s. Its job was to diagnose and recommend treatment for certain blood infections. To do the diagnosis ``properly'' involves growing cultures of the infecting organism. Unfortunately this takes around 48 hours, and if doctors waited until this was complete their patient might be dead! So, doctors have to come up with quick guesses about likely problems from the available data, and use these guesses to provide a ``covering'' treatment where drugs are given which should deal with any possible problem.
Mycin was developed partly in order to explore how human experts make these rough (but important) guesses based on partial information. However, the problem is also a potentially important one in practical terms - there are lots of junior or non-specialised doctors who sometimes have to make such a rough diagnosis, and if there is an expert tool available to help them then this might allow more effective treatment to be given. In fact, Mycin was never actually used in practice. This wasn't because of any weakness in its performance - in tests it outperformed members of the Stanford medical school. It was as much because of ethical and legal issues related to the use of computers in medicine - if it gives the wrong diagnosis, who do you sue?
Anyway Mycin represented its knowledge as a set of IF-THEN rules with certainty factors. The following is an English version of one of Mycin's rules:
IF the infection is pimary-bacteremia
AND the site of the culture is one of the sterile sites
AND the suspected portal of entry is the gastrointestinal tract
THEN there is suggestive evidence (0.7) that infection is bacteroid.
The 0.7 is roughly the certainty that the conclusion will be true given the evidence. If the evidence is uncertain the certainties of the bits of evidence will be combined with the certainty of the rule to give the certainty of the conclusion.
Mycin was written in Lisp, and its rules are formally represented as Lisp expressions. The action part of the rule could just be a conclusion about the problem being solved, or it could be an arbitary lisp expression. This allowed great flexibility, but removed some of the modularity and clarity of rule-based systems, so using the facility had to be used with care.
Anyway, Mycin is a (primarily) goal-directed system, using the basic backward chaining reasoning strategy that we described above. However, Mycin used various heuristics to control the search for a solution (or proof of some hypothesis). These were needed both to make the reasoning efficient and to prevent the user being asked too many unnecessary questions.
One strategy is to first ask the user a number of more or less preset questions that are always required and which allow the system to rule out totally unlikely diagnoses. Once these questions have been asked the system can then focus on particular, more specific possible blood disorders, and go into full backward chaining mode to try and prove each one. This rules out alot of unecessary search, and also follows the pattern of human patient-doctor interviews.
The other strategies relate to the way in which rules are invoked. The first one is simple: given a possible rule to use, Mycin first checks all the premises of the rule to see if any are known to be false. If so there's not much point using the rule. The other strategies relate more to the certainty factors. Mycin will first look at rules that have more certain conclusions, and will abandon a search once the certainties involved get below 0.2.
A dialogue with Mycin is somewhat like the mini dialogue we gave in section 5.3, but of course longer and somewhat more complex. There are three main stages to the dialogue. In the first stage, initial data about the case is gathered so the system can come up with a very broad diagnosis. In the second more directed questions are asked to test specific hypotheses. At the end of this section a diagnosis is proposed. In the third section questions are asked to determine an appropriate treatment, given the diagnosis and facts about the patient. This obviously concludes with a treatment recommendation. At any stage the user can ask why a question was asked or how a conclusion was reached, and when treatment is recommended the user can ask for alternative treatments if the first is not viewed as satisfactory.
Mycin, though pioneering much expert system research, also had a number of problems which were remedied in later, more sophisticated architectures. One of these was that the rules often mixed domain knowledge, problem solving knowledge and ``screening conditions'' (conditions to avoid asking the user silly or awkward questions - e.g., checking patient is not child before asking about alcoholism). A later version called NEOMYCIN attemped to deal with these by having an explicit disease taxonomy (represented as a frame system) to represent facts about different kinds of diseases. The basic problem solving strategy was to go down the disease tree, from general classes of diseases to very specific ones, gathering information to differentiate between two disease subclasses (ie, if disease1 has subtypes disease2 and disease3, and you know that the patient has the disease1, and subtype disease2 has symptom1 but not disease3, then ask about symptom1.)
There were many other developments from the MYCIN project. For example, EMYCIN was really the first expert shell developed from Mycin. A new expert system called PUFF was developed using EMYCIN in the new domain of heart disorders. And systom called NEOMYCIN was developed for training doctors, which would take them through various example cases, checking their conclusions and explaining where they went wrong.
We should make it clear at this point that not all expert systems are Mycin-like. Many use different approaches to both problem solving and knowledge representation. A full course on expert systems would consider the different approaches used, and when each is appropriate. Come to AI4 for more details!