Mycin - medical decisions, EMYCIN
In the early 1970’s, an MD/PhD student at Stanford Medical School, Edward Shortliffe, developed a computer program, MYCIN, to diagnose blood infections, such as bacteremia and meningitis, and to recommend antibiotics. Its name is a reference to the common suffix for antibiotics, such as arithromycin. The program was not some massive, unified decision system, but rather relied on a granular set of roughly 600 individual rules. Rules generally had an IF-THEN structure, such as
Rule in LISP:
PREMISE: ($ AND (SAME CNTXT GRAM GRAMNEG)
(SAME CNTXT MORPH ROD)
(SAME CNTXT AIR ANAEROBIC))
ACTION: (CONCLUDE CNTXT IDENTITY BACTEROIDES TALLY .6)
1 the gram stain of the organism is gramneg, and
2 the morphology of the organism is rod, and
3 the aerobicity of the organism is anaerobic
There is suggestive evidence (.6) that the identity of the organism is bacteroides
Observations about MYCIN:
some facts and some conclusions of the rules (as above) are not absolutely certain
MYCIN uses numerical certainty factors; range between -1 and 1
(reasonably involved) rules for combining certainty factors of premises, with the number in the rule (as 0.6 above) into a certainty factor for the conclusions
later it turned out that MYCIN’s recommendations would have been the same if it used only 4 values for certainty factors
MYCIN was never used in practice (ethical and legal issues)
when tested on real cases, did as well or better than the members of the Stanford medical school
Peter Norvig has implemented MYCIN in common LISP, along with a sample set of rules.
Though not feasible as an autonomous medical decision system, MYCIN was nevertheless considered a success as a model of decision making. The MYCIN architecture separated the inference engine from the knowledge base (rules).
In fact, the Stanford researchers did precisely that to produce EMYCIN (“empty MYCIN”) which used MYCIN’s inference engine, but let the user put in new rules in a new domain. These expert system shells were quite popular. The process of compiling the set of rules for an expert system came to be called “knowledge engineering.” The idea was that a computer scientist would sit down with a human expert (doctor, geologist, real engineer), and conduct interviews to arrive at a suitable rule base. These rules would be coded up into an expert system which would then be given problems to solve. If the computer made a mistake, the knowledge engineer could debug an existing rule, add a new rule, or change the order in which rules were tested.
The 1970’s and 1980’s saw a number of rule-based expert systems, as well as critics of production systems. John McCarthy, the inventor of LISP and Stanford colleague of many of the expert system proponents, argued that expert systems need common sense.
Slade, Automated Decision Systems