BY YUE KANG AND A. TERRY BAHILL

a TOOL forEXPERT-SYSTEM

Test casescan findrun-time

errorsin the

systemevery

time arule is

added ormodified

46

he most difficult part of expert-system design is testing. Brute-force enumeration of all inputs isimpossible for most systems, so

the traditional testing method has a humanexpert run many test cases on the expertsystem. This method is time-consuming andfa l l ib le . Furthermore, the knowledge engi-neer never knows when enough test caseshave been run. Our run-time tool helps theknowledge engineer know exactly when toquit.

More mistakes could be corrected if manyexperts tested the system. It is often possibleto find an expert who will devote lots oftime for interviewing, debugging the knowl-edge base, and running test cases. It is muchharder to find other experts with the timeto test the final product: their time is expen-sive; there are few of them in any geo-graphical area; and they don't have the per-sonal commitment to the project. Becauseexperts have so many time constraints,there should be tools to help make judicioususe of it.

Evaluating an expert system by using testcases is certainly not original. P.G. Politakis1

has shown how statistics gathered while run-ning test cases can be used by the developerto modify the rules and improve the expertsystem.

The technique described here comes intoplay at run-time. Each rule-firing is record-ed. Rules that never succeed and rules thatsucceed for all test cases are probably mis-takes, and the human expert is notified."Succeed" means all the premises are trueand the expression in the conclusion is as-signed the appropriate value.

RUNNING TEST CASESIt appears we are back to square one be-cause we need to bring in the expert to runtest cases. However, only one test case isnecessary; the expert does not have toreanswer 100 questions every time theknowledge engineer corrects a spelling er-ror. To create test cases, start the systemand ask the expert to pull the file or visual-ize a particular patient. The expert shouldrun a consultation and answer all the ques-tions. At the end of the consultation, afterthe expert system gives its advice (but be-fore you exit or restart), save the intermedi-

AI EXPERT • FEBRUARY 1990

DETECTINGERRORS

ate knowledge. (For M.I the command issavecache.) Eliminate the values derived bythe inference engine with a text editor, leav-ing only the human answers to questions.(M.I tags these "because you said so." Un-fortunately, this tag doesn't work if the ex-pert answers "unknown" to a question; theknowledge engineer sti l l has some work todo.)

To create a second test case, ask your ex-pert to concentrate on another patient (ormalfunctioning circuit, for example) andproduce another set of answers. Save this setunder a different name. Convenient namesmay be easel, case2, case3, and so on. In thismanner the expert can produce many testcases that can be used for subsequent testingduring the project's lifecycle. Every time arule is added or modified these test casescan be automatically played through the sys-tem to look for run-time errors. If you didnot add new questions to the knowledgebase, the advice should be produced imme-diately. If you added new questions, theywill be asked, and you'll get your advice andcan save the new test case. If the modifica-tions require more knowledge from the ex-

pert, it may be possible to glean this infor-mation from a telephone call. The test casescould be readily updated without demand-ing a lot of the experts time and you couldtest the system at your leisure.

Using real test cases provided by the ex-pert is only one method of exercising aknowledge base. Test cases may also be in-vented by the knowledge engineer and pro-vided by the user; those created by theknowledge engineer are often more effi-cient, because more rules can be exercisedby fewer test cases. The expert, the knowl-edge engineer, and the user are like threeblind men describing an elephant: each un-derstands a different aspect of the system,so their test cases will exercise different por-tions of the knowledge base. It may be wiseto use test cases from all three sources.

Rules never succeed if either of twoclasses of mistakes are made: failure due tofalse premises and failure due to single-val-ue cutoff. The problems and techniques dis-cussed are universal and should apply to anyrule-based expert system (we've tried themon M.I , VP-Expert and Personal ConsultantPlus systems). 47

AI EXPERT • FEBRUARY 1990

Validator

48

Validator is a program that interactively verifies and vali-dates rule-based expert-system knowledge bases. It checksthe syntax and semantics for potential errors and bringsthem to the attention of the knowledge engineer. Validatordoes not attempt to fix errors; that task is left to the knowl-edge engineer. The system has six modules: a preprocessor,syntax analyzer, syntactic error checker, debugger, chainingthread tracer, and knowledge-base completeness module.

Validator was tested on 67 expert systems selected fromMA projects, potential commercial systems, class projectsfor graduate courses in knowledge engineering, and com-mercial demonstration systems. The potential mistakesflagged by Validator fell into nine categories: illegal use ofreserved words; rules that could never fire (both backwardand forward rules); unused facts; unused questions; unusedlegal values; repeated questions; multiple methods (includ-ing expressions that appear in questions and facts, questionsand conclusions, and facts and conclusions); rules using il-legal values (including mismatches between any of the sets oflegal values, utilized values, concluded values, and assignedvalues); and incorrect instantiations. Validator was writtenand is maintained by Musa Jafar and Terry Bahill, at BICS,1622 W. Montenegro, Tucson, Ariz. 85704.

FAILURE DUE TO FALSE PREMISESConsider this type of if-then production rule:if premise = \es then conclusion = yes. If thepremise cannot be satisfied in any consulta-tion, then the rule will fail. For example, inif a> 1 then c = 0, if the designer thoughtthat a would sometimes be larger than one(but in the real world a was always less thanone), then the premise could never be satis-fied and the rule would never succeed.

If a premise has many conditions, theymay contradict each other, so the premise isalways false (such as if humidity = 37c andheavy-rain = yes then conclusion.) The contra-dictory conditions could even be indirectand spread out in other rules. For example:

goal = c.rule-1: if heavy-rain = yes and b = yes then c = yes.rule-2: if humidity = 3% then b = yes.

rule-1 cannot succeed. We can generalizethis idea to:

rule-1: if heavy-rain = yes and b1 = yes then c = yes.rule-2: if ... b2 = yes and ... then b1 = yes.

rule-k: if ... bk = yes and ... then bk-1 = yes.

rule-k+1: if humidity = 3% then bk = yes.

Since hi depends on bk, rule-1 can't succeed.If a rule has one premise that will be false

for all valid combinations of values, the rulewill never succeed and is probably a mis-take. Notice that this type of error-checkingdepends on knowledge and therefore can beused only at run-time.

FAILURE DUE TO CUTOFFWhen seeking a value for a single-valued ex-pression, most backward-chaining expertsystems stop after finding a value with com-plete certainty. If a system always stops be-fore a certain rule, that rule will never suc-ceed. Consider this knowledge base:

goal = c.rule-1: if a1 = yes then c = 1 cf 100.

rule-k: if ak = yes then c = k cf 100.rule-k+1: if b = yes then c = k+1 cf X.

Assume r is single-valued. If one of al, a2, ...ak is always 100% yes, then the system willalways stop seeking a value for c before rule-k+1 can succeed. Therefore, rule-k+1 willnever succeed. Consider this set of rules:

rule-1: if a = yes then c = 1 cf 100.rule-2: if a = no then c = 2 cf 100.rule-3: if b = yes then c = 3 cf X.

rule-3 will never succeed. After the infer-ence engine has found a value with 100%certainty, it won't seek further values. (Thisexample presumes the user is not allowed toanswer "unknown" when a value for a isqueried.) These errors cannot be found bysyntax checking because they are semantic;they can be found only during run-time in-vestigations. Validator (see sidebar) scansthe knowledge base by flagging single-valued terms with different values attribut-ed to them in different rules as potentialerrors.

In addition to these types of errors, ourrun-time tool detected rules that could nev-er succeed due to other types of errors. Va-lidator had already detected many of thesemistakes, but it produces some false posi-tives, so knowledge engineers sometimes ig-nore the warnings.

Rules that succeed for every test case areprobably mistakes. If a rule is always truethen it might be simpler to replace it with afact. Of course, some control rules alwayssucceed, and some rules will be designed forrare situations not exercised by the testcases at hand. Again, this technique is onlyadvisory; the expert must make the final de-cision about the rule's correctness.

AI EXPERT • FEBRUARY 1990

To detect which rules succeed at run-time, we add additional terms to the knowl-edge base. For example, this original knowl-edge base:

rule-1: if prenise-1 = yes then conclusion-1.

rule-k: if premise-k = yes then conclusion-k.

must be edited to become this transformedknowledge base:

rule-1: if premise-1 = yesthen conclusion-1 and r-1 = yes.

rule-k: if premise-k = yesthen conclusion-k and r-k = yes.

We use the terms r-i to record which rulessucceeded (i is an index that goes from oneto k, where k is the number of rules in theknowledge base). When the system invokesa rule, if the premises are true (meaning therule succeeded), r-i is assigned a value of yes.If rule i has succeeded during the consulta-tion, the value of r-i will be yes. If rule i hasnot succeeded during the consultation, thevalue of r-i will not be yes.

This technique works for both forward-and backward-chaining shells, but it does re-quire the shell to allow multiple terms inthe rule conclusions. Personal ConsultantPlus from Texas Instruments, VP-Expertfrom Paperback Software, and many othershells allow this technique. However, tomake the technique work for M. I , an addi-tional clause must be added as the last prem-ises of each rule, as shown in this modifiedknowledge base:

rule-1: if premise-1 = yes and do(set r-1 = yes)then conclusion-1.

rule-k: if premise-k =then conclusion-k.

yes and do set(r-k = yes)

This example is written as if there were onlyone premise, but the technique will workwith multiple premises as long as the do set(r-k = yes) is the last one. When rule-i fires, ifthe original premises are true (meaning therule will succeed), then r-i will be set to yes.If the premises arc false, then the rule willfail and r-i will not be set to yes.

None of these additions influences thefunction of the rules, but they do allow de-tection of which rules succeeded. The nextstep is storing the values of the r-i, which re-flect the status of a rule in only one consul-

tation. Since our goal is to determine whichrules have succeeded after many consulta-tions, we must accumulate the values of r-ifrom the first to the last consultation. Fromthe results of this accumulation we can findthe rules that never succeeded and that suc-ceeded for every test case.

RECORDING SUCCESSFUL RULESWe wrote a C program to modify the knowl-edge bases automatically. It added and doset(r-i = yes) into rules kb-1 to kb-k and ap-pended kb-k+1 to kb-k+ 3 to the originalknowledge base to record which rules suc-ceeded. Examine this modified M.I knowl-edge base:

goal = goal-1.kb-1: if premise-1 = yes and do set(r-1

then conclusion-1.yes)

kb-k: if premise-k = yes and do set(r-k = yes)then conclusion-k.

kb-k+1: goal = goal-2.kb-k+2: if do(log filenamel) and do(show r-X) and

do(log off) and external(cprogram1,[]) = [] andprintrule = yes and do(log filename2) anddo(uses do(set r-X=yes)) and do(log off) andexternal(cprogram2,[]) = [] then goal-2=true.

kb-k+3: question(printrule) = 'Would you like tocreate a file showing the rules and the number oftimes they succeeded?'

To use our program we ran a consultationwith the modified knowledge base. Wesaved test cases, loaded one with the load-cache command, and restarted. The originalgoal, goal-1, drove a normal consultation,

TABLE 1.Summary of run-time tool testingresults.

SIZE KB UNSUCCESSFUL TESTNAME (KB) ENTRIES RULES RULES CASES

TV-FILM

BACKUP

AUTOMECH

MACEXPERT

SOFTWARE

ADVISOR

HELPER

DIET

WIREBOND

DRUGDEAL

VOLCANIC

DRUG

CHROMIE

VET

DELL

CARPET

32

8

8

11

7

84

63

14

19

26

18

40

114

33

54

56

290

50

56

85

68

307

204

118

113

206

141

120

681

235

453

390

25

20

24

16

32

64

57

33

39

81

65

82

231

105

148

106

0

1

0

1

1

2

3

11

22

34

36

36

41

67

70

70

6

8

12

15

26

30

40

8

6

7

8

13

20

6

6

20

49

AI EXPERT • FEBRUARY 1990

Example 1.goal=intro.rule-1: if a_banner_displayed is sought

and output is soughtand class_assignment is soughtand do(reset done)then intro.

rule-2: if not(class)then intro.

/*Because intro was single-valued and rule-1 always succeeded, rule-2 neverfired. Earlier we called this failure due to single valued cutoff.*/

Example 2.goal = complete-commands.rule-1: if help-with-commands=yes

and commands is soughtthen complete-commands.

rule-2: if help-with-commands=nothen commands.

/*This is a special case of failure due to false premises. It could besimplified to goal=c.Vrule-1a: if a=yes

and b is soughtthen c=yes.

rule-2a: if a=nothen b=yes.

/*Since a cannot be yes and no at same time, rule-2a can never succeed.*/

Example 3 (simplified).goal=c.rule-1: if a is unknown

and b=yesthen c=yes.

rule-2: if b=Wand d=Vand computer(N,V)=Xthen a=X.

fact-1: computer(yes,V)="something"./*If b=no rule-1 fails. If b=yes, then a=something and is therefore known.Therefore, rule-1 can never succeed. This is another example of failure dueto false premises.*/

Example 4 (simplified).goal=c.rule-1: if a=1

then c=yes.rule-2: if not(b=1)

and b=Xthen a=X.

rule-3: if b=1and d=Xthen a=X.

legalvals(d)=[2,3]./*Neither rule-2 nor rule-3 could make a=1, so rule-1 will never succeed. Usingvariables makes it harder to see the contradiction.*/

LISTING 1.Examples.

50

and goal-2 caused M.I to invoke rule kb-k + 2, which created a results file called file-name 1. This file contained the cache entriesfor all successful rules. For example, if rule-5succeeded then r-5 = yes because... would bein cache and put into filename 1.

Next, we ran a another consultation(loaded another test cache) and our pro-gram added the new statistics to the file.The external function cprograml consolidat-ed the new data with the data from previousconsultations. When we finished running all

the test cases, we answered "yes" to thequestion "Would you like to create a fileshowing the rules and the number of timesthey succeeded?" Rule kb-k + 2 then causedM.I to create a file cMed filename 2. The ex-ternal function cprogram2 modified that file,producing the final output file containingthe rules, the knowledge-base number ofeach rule, and the number of times eachrule succeeded. (In a consultation, the newknowledge base works the same as the oldone. The user sees no differences.)

We tested this run-time tool on 16 expertsystems. Table 1 lists their names, sizes,number of knowledge-base entries, rules,rules that never succeeded during our tests,and test cases we used to exercise the expertsystems. We identified each rule that neversucceeded and determined why not. Manyrules failed because they contained mis-takes. The four examples shown in Listing 1summarize these mistakes.

Our most powerful verification and vali-dation tool, Validator,23 could not detectthese mistakes because they depend on theuser's answers and can be detected only atrun-time.

The first seven expert systems listed inTable 1 had fewer mistakes, and we coulddetermine the cause of failure for every rulethat never succeeded. These seven expertsystems had an average of 34 rules, ran anaverage of 20 test cases for each system, andhad an average of one unsuccessful rule persystem.

For the next nine systems listed in Table1, we could not find the cause of failure forevery unsuccessful rule. These nine systemshad an average of 99 rules, they were givenan average of 10 test cases and had an aver-age of 43 unsuccessful rules. So for the sys-tems we tested, as the number of test casesapproached one-half the number of rules,the number of unsuccessful rules diminished.

The best way to test an expert system is tolet the domain expert run consultations,first creating a test case for every 10 rules(10 test cases for a 100-rule system) and ob-serving which rules never succeed. Next theexpert should provide test cases that mightmake these rules succeed. This procedurecould be repeated until most of the ruleshave succeeded. Then the knowledge engi-neer could try to find the reason for the re-maining rules not succeeding.

LIMITATIONSThis technique is limited in one way be-cause a rule that never succeeds is not neces-sarily wrong; it is possible that the test casesjust did not exercise that rule. For example,for Chromie (Table 1) the expert providedmany test cases, yet 41 rules never succeed-ed. When this statistic was revealed to theexpert, she said, "Of course. That part of

AI EXPERT • FEBRUARY 1990

the knowledge base is so simple, I neverbothered to give you a test case that wouldexercise it."

Even if a rule succeeds we cannot be surethat it contributes to the final result:

rule-1: if a = yes then c = 1 cf 70.rule-2: it b1 = yes then c = 2 cf 100.

rule-k: if bk = yes then c = k cf 100.

Assume c is single valued. If one of bl to bkis always yes, even if rule-l succeeded, c = 1cf 70 would be replaced by a result from an-other rule. So rule-1 is useless.

TECHNIQUE BENEFITSTesting expert systems is difficult, time con-suming, and unfulfilling. We have devel-oped a technique to make this task easierand to give the designer more confidence inthe final product. This technique is intend-ed to be run after all static errors have beenremoved from the knowledge base. For ex-ample, spelling errors, use of reservedwords, and rules that do not link to the restof the knowledge base can be detected in acareful reading of the knowledge base orwith an interactive tool such as Validator.After this detection is complete, our run-time tool can reveal more potential errorsusing knowledge stored from consultationswith the expert. (It detects rules that neversucceed and rules that succeed for every testcase.) Such rules are probably mistakes andshould be brought to the attention of theknowledge engineer.

We have shown two classes of mistakesthat would cause a rule never to succeed:the premises could always be false, or single-valued cutoff might cause the inference en-gine to stop seeking a value for a term be-fore a certain rule is ever encountered. QQ

REFERENCES1. Politakis, P.G. Empirical Analysis for Expert Systems.

Boston, Mass.: Pitman Advanced Publishing Program,1985.

2. Jafar, M.J., and A.T. Bahill. "Validator, a tool forverifying and validating personal computer based ex-pert systems." In Brown, D.E., and C.C. White (eds.)Operations Research and Artificial Intelligence: The Integra-tion of Problem Solving Strategies. Boston, Mass.: KluwerAcademic Publishers, 1990.

3. Jafar, M J. "Tool for Interactive Verification andValidation of Rule Based Expert Systems." Ph.D. dis-sertation, Dept. of Systems and Industrial Engineering,University of Arizona, Tucson, 1989.

Yue Kang is a graduate student systems andindustrial engineering at the University of Arizona,Tucson, and was previously a computer engineer inBeijing. A. Terry Bahill is a professor of systemsengineering at the University of Arizona and is anAssociate Editor of IEEE Expert.

GATECHExpertSystemsShort Coursesleading to aCERTIFICATE INKNOWLEDGEENGINEERINGLet Georgia Tech knowledge engineersshow you how to lead your companyto the forefront by employing expertsystems on personal computers.

This complete series is offered inspring 1990:

1. K.E. I - Manager's Vieiv ofExpert SystemsMarch 19

2. Knowledge AcquisitionMarch 20-21

3. Lisp-at-Work: Essential Syntaxand UseMarch 22

4. K.E. II - Rapid PrototypingPracticumMarch 23-24

5. Object-Oriented ProgrammingSystemsMarch 28-29

6. K.E. Ill — Project ManagementMarch 30

For more information and courseregistration call:

Education Extension-MGeorgia Institute of Technology

Atlanta, Georgia 30332-03851-800-325-5007

51CIRCLE 19 ON READER SERVICE CARD

AI EXPERT • FEBRUARY 1990