Acquiring expert rules with the aid of decision tables

E L S E V I E R European Journal of Operational Research 84 (1995) 150-162

EUROPEAN JOURNAL

OF OPERATIONAL RESEARCH

Acquiring expert rules with the aid of decision tables

J o h n P. S e a g l e *, P e t e r D u c h e s s i

School of Business, State University of New York at Albany, Albany, NY 12222, USA

Abstract

This paper describes a computer-assisted approach to help knowledge engineers elicit rules from a domain expert. The approach uses the decision table as a knowledge engineering tool, and incorporates a decision table analyzer that displays rule conditions which can be used to query the expert. The decision table analyzer also reports redundant rules and provides assistance for developing rules that use as few variables as possible. This has the benefit of limiting the number of questions to be asked of the expert. The approach is especially suited for heuristic classification problems where evaluative judgments are based on many combinations of values of the same facts.

Keywords: Expert systems; Knowledge acquisition; Heuristics; Software engineering

I. Introduct ion

Expert systems that use rules to model human expertise are commonly called rule-based expert systems. The rules are condition-action pairs: IF condition THEN action.

The rule condition contains one or more facts and logical operators, and the action may be either a directive or conclusion. Generally, a fact takes the form of a variable with a value. When a problem's data satisfies the condition, the action is performed. The rules constitute a knowledge base and are responsible for the expert system's problem solving ability. A knowledge engineer is the individual responsible for eliciting the rules

This research was conducted during two expert system development projects supported by the General Electric Cor- poration.

" Corresponding author.

from a domain expert and encoding them into the knowledge base.

The bottleneck in the development of expert systems is the acquisition of the domain expert's rules [1,2,9]. In many situations, the knowledge engineer queries the expert for the variables, rules and strategies normally used to solve domain problems. Interviews are often combined with other elicitation methods, including ques- tionnaires, observation of task performance and protocol analysis [18]. Generally, the knowledge engineer is confronted with the issue of how to pursue an effective line of questioning [10]. Miss- ing knowledge details serve as a basis to formulate questions, but they can be extremely difficult to identify.

We have developed a semiautomatic approach to knowledge acquisition that is especially well suited to heuristic classification problems where experts use combinations of many facts to make

0377-2217/95/$09.50 © 1995 Elsevier Science B.V. All rights reserved SSDI 0377-2217(94)00323-8

J. P. Seagle, P. Duchessi / European Journal of Operational Research 84 (1995) 150-162 151

judgments. A review of the extant literature reveals no comparable approach for this type of problem structure. We have successfully used it to develop two expert systems. The first is the Commercial Loan Analysis Support System (CLASS), a rule-based expert system that evaluates a company's financial position, recommends commercial covenants and makes loan decisions [5]. The second is Control Unit Expert (CUE), a rule-based expert system that diagnoses problems with the control unit of a steam turbine.

This paper has two objectives. The first is to show how decision tables can be used to facilitate knowledge acquisition, and how they relate to other methods. The second objective is to present the methodology behind our decision table analyzer, which reduces the number of questions that must be asked of the expert to complete a knowledge base. In the next section we describe how the approach relates to other methods of knowledge acquisition and the class of problems it fits best. We describe how to represent rules with a decision table, present the decision table analyzer (the heart of our approach) and demonstrate how to use it. We also discuss advantages and disad- vantages that were drawn from our experiences applying it to the CLASS and CUE expert systems. Finally, we conclude with a summary that incorporates the research contributions of our work.

2. Knowledge acquisition approaches

A classification scheme for knowledge acquisition methods for expert system development is available in [21]. For our purpose, these methods can be broadly classified as either manual or computer-based. Manual methods are based upon interviews and analysis of problem-solving proto- cols. These methods are time consuming and expensive. To alleviate these problems, computer-based approaches automate the process as much as possible, and are either semiautomatic or fully automatic. Semiautomatic methods that expedite rule acquisition include knowledge base editors and interfaces, explanation facilities and knowledge base revision systems that detect in- consistent rules and evaluate alternative rule revi- sions [2]. These methods may increase the knowledge engineer's productivity and require much less time from either or both the knowledge engineer and expert. Fully automatic methods at- tempt to minimize the roles of both parties. The most prominent automatic systems are rule in- duction systems [8,16]. They require attributes, or factors, that are considered by the expert along with a large set of cases for the system's algorithm to interpret into rules.

A series of papers describes other automated- knowledge acquisition methods that exploit the roles played by rules in solving problems of vari-

FP = Financial Position CO = Co l la te ra l CR = Cred i t CA = Capital CP = Capacity T = Trends P = Profitability L = L i q u i d i t y

E = Efficiency IT = Inventory Turnover RT = Receivables Turnover ok FA = F ixed Asse t Turnover T A = To ta l Asse t Turnover ET = E f f i c iency T r e n d s

Fig. 1. Structure of commercial lending.

152 J.P. Seagle, P. Duchessi / European Journal of Operational Research 84 (1995) 150-162

ous types [15]. Each method is based upon a particular set of assumptions about the underly- ing problem structure (e.g., differentiating knowledge for diagnosis) and makes use of a particular model for solving those problems. The approaches use the models to generate questions for the expert and develop rules from the an- swers. For an extensive discussion of models of problem solving for rule-based expert systems, see [12]. For an overview of knowledge acquisition methods, including their strengths and weaknesses, see [21] and [13]. A general overview of knowledge acquisition and transfer is given by Gaines [7].

Our decision table-based approach can be grouped with the semiautomatic knowledge acquisition approaches. It partially automates the process of acquiring rules by generating unspecified rule conditions from an initial set supplied by the expert, and it requires the expert to provide conclusions, or make judgments, about those conditions. The approach uses decision tables and a automated decision table analyzer that identifies unspecified rule conditions, reports redundant rules, and provides assistance for developing rules that use as few facts as possible.

The approach is appropriate for problems that use a rule-based representation scheme, are solved in stages and use many combinations of facts to make conclusions or judgments. Fig. 1 describes a part of the overall knowledge base for commercial lending as used in CLASS. The expert modeled evaluates Inventory Turnover, Re- ceivables Turnover, Fixed Asset Turnover, Total Asset Turnover and Efficiency Trends. The expert then combines these evaluations to make a judgment about Efficiency. That judgment is combined with judgments about Profitability and Liquidity to make a judgment about a company's Credit position. Commercial lending is a heuristic classification problem as described by Clancey [3]. The expert analyzes data about a company and makes a heuristic judgment about Efficiency, Profitability, or some other financial factor. In evaluating credit, the expert simultaneously con- siders judgments previously made about Prof- itability, Efficiency, and Liquidity. Negative evaluations in this domain tend to result from the

presence of major weaknesses, or many minor weaknesses, or certain combinations of comple- mentary weaknesses. Positive evaluations represent the lack of such weaknesses.

This type of problem differs from diagnostic problems, which are also heuristic classification. In diagnostic problems, each symptom is assumed to have a cause, and the expert's role is to identify that cause or hypothesis. Mole, a knowledge acquisition tool based upon this assumption, asks for "explanations of a symptom rather than the conditions for accepting a hypothesis" [6, p.49]. Only if a symptom has several possible causes does Mole ask for additional information to dif- ferentiate among causes.

3. Representing expert rules with a decision table

Rules are not restricted to expert systems. Many traditional computer applications, especially in transaction processing, use rules for making decisions. The decision table is a common system design tool for such applications, but it is also applicable for representing and designing expert system rules. Table 1 is an example of a decision table that contains several rules. It lists rule variables, or conditions in conventional decision table terminology, as column headings under Conditions. Possible values of the variables appear in columns below the list of variables. Ac- tions appear in the lower left quadrant, or action stub as it is known in conventional decision table usage. The rows containing sets of variable values continue across, and actions are on the right. Each row represents a rule. The decision table is a compact representation when several rules re- fer to the same variables. Just as fourth genera- tion languages produce code from a design, code can be generated automatically from a decision table [11]. One expert system development tool, GEN-X, uses decision tables to communicate rules automatically into the knowledge base, eliminating the human coding step [4].

Table 1 is a decision table that summarizes an interview with an expert. It is a simplified version of a table from the CLASS project. To develop

J.P. Seagle, P. Duchessi / European Journal of Operational Research 84 (1995) 150-162

Table 1 Expert rules in a decision table

153

Rules Conditions

Credit ok Collateral ok Capital ok Capacity ok Trends

Actions

Financial pos

1 F . . . . P

2 T T T T I S 3 T T T T S S 4 T F F - I M 5 T T F T S M 6 T F T F S M

this table, the knowledge engineer quizzed a financial expert in order to develop rules for classi- fying the financial position of a loan applicant. In the top part of the table, labeled 'Conditions', one relevant variable is 'Credit ok'. The expert assigns one of two values to the variable: T for True, or F for False. The next three variables 'Collateral ok', 'Capital ok' and 'Capacity ok' also have T and F values. The expert assigns to the last variable, 'Trends ' , one of three values: I for improving, S for stable, or D for deteriorating. These variables complete the conditions part of the table. Values for these variables appear in each row, and the collection of all the values in a row represents a rule condition. In the right or action part of the table, labeled 'Actions' , each of the expert 's distinct conclusions about financial position appear. The expert assigns one of three values to the financial position variable, 'Finan- cial pos'. S represents a strong financial position, M moderate, and P poor. A rule condition and the associated conclusion represents a rule in the table. For example, the last row of Table 1 displays the rule: If 'Credit o k ' = T and 'Collateral ok' = F and 'Capital ok' = T and 'Capacity ok' = F and 'Trends ' = S then 'Financial pos' = M.

Generally, tables contain both goals and subgoals of an expert system. A subgoal is a fact that appears in a rule condition of one table and as an action or conclusion of other tables. For example, in Table 1, financial positions of strong, moderate and poor are goals. The facts that appear in the second rule condition, 'Credit ok' = T, 'Collateral ok' = T, 'Capital ok' = T, 'Capacity ok' = T, and ' T r e n d s ' = I, are subgoals; they appear as conclusions in other tables that are analyzed separately.

The tables facilitate rule development, but do not make inferences. The inference process is under the control of the expert system's inference en- gine, which connects rules through forward or backward chaining during system execution.

In the example shown in Table 1, the knowledge elicited from the expert takes the form of six rules, and each rule is represented by a row of the table. The F in Row 1 indicates that the variable 'Credit ok' must have the value False for Rule 1 to hold; the dashed entries in the remain- der of Rule 1 show that the rule holds for all values of those variables. That is, an expert system would execute Rule 1 whenever the first variable, 'Credit ok', is False, regardless of the values of the other variables. Whenever Rule 1 executes, the conclusion P (poor financial position) is reached. Rules 2 and 3 show two alternative ways that the conclusion S (strong financial position) may be reached.

Although the intentions of the expert and knowledge engineer in the knowledge acquisition process are to make explicit the expert 's knowledge, many needed rules go unrecognized until the system, or a prototype, has undergone extensive testing. These missing rules are observable conditions for which the expert system would be unable to reach a conclusion. Our experience suggests that an expert can easily articulate several initial rules during an interview. The real challenge is to expand these initial rules into a larger set of rules that cover most of the conditions that are encountered in practice. The decision table-based approach allows missing rule conditions to be identified as they are being acquired during interviews.


4 . I d e n t i f y i n g m i s s i n g r u l e s

T h e k n o w l e d g e e n g i n e e r c a n o b t a i n m i s s i n g

r u l e s by u s i n g a d e c i s i o n t a b l e to c o n s t r u c t al l

p o s s i b l e r u l e c o n d i t i o n s n o t e x p l o r e d by t h e ex-

p e r t a n d k n o w l e d g e e n g i n e e r , a n d t h e n a s k i n g

t h e e x p e r t fo r a p p r o p r i a t e c o n c l u s i o n s for t h o s e

c o n d i t i o n s . A p p l y i n g t h i s a p p r o a c h to T a b l e 1

w o u l d l e a d to a t a b l e w i t h 48 s i m p l e ru les , w h i c h

a r e r u l e s t h a t c o n t a i n n o d a s h e s , as s h o w n in

T a b l e 2. T h e t o t a l n u m b e r o f r u l e s is t h e p r o d u c t

o f t h e n u m b e r o f v a l u e s t h a t e a c h v a r i a b l e c a n

a s s u m e , in th i s c a se 2 x 2 x 2 x 2 x 3, o r 48.

T a b l e 2 s h o w s 30 ru les , r e f e r r e d to as c o v e r e d

ru les , fo r w h i c h t h e e x p e r t ' s six r u l e s h a v e p r o -

v i d e d c o n c l u s i o n s . A l t h o u g h o n l y six r u l e s w e r e

Table 2 Complete decision table with simple rules

Rules Conditions

Credit ok Collateral ok Capital ok Capacity ok

Actions

Trends Financial pos

1 T T T T I 2 T T T T S 3 T T T T D 4 T T T F I 5 T T T F S 6 T T T F D 7 T T F T I 8 T T F T S 9 T T F T D

10 T T F F I 11 T T F F S 12 T T F F D 13 T F T T I 14 T F T T S 15 T F T T D 16 T F T F I 17 T F T F S 18 T F T F D 19 T F F T I 20 T F F T S 21 T F F T D 22 T F F F I 23 T F F F S 24 T F F F D 25 F T T T I 26 F T T T S 27 F T T T D 28 F T T F I 29 F T T F S 30 F T T F D 31 F T F T I 32 F T F T S 33 F T F T D 34 F T F F I 35 F T F F S 36 F T F F D

i i i i i ! 45 F F F T D 46 F F F F I 47 F F F F S 48 F F F F D

S S ? 9

? 9

?

M

9

9

9

9

9

9

9

M 9

M ? ?

M ? ?

P P P P P P P P P P P P

P P P P

J.P. Seagle, P. Duchessi / European Journal of Operational Research 84 (1995) 150-162 155

initially given by the expert, expert Rule 1 of Table 1 covers the last 24 rules of Table 2, all cases in which the first variable is false. Four of the expert's other rules correspond directly to rules of Table 2, while the expert's fourth rule covers two rules (19 and 22) of Table 2. This leaves 18 possible rule conditions that the expert and knowledge engineer have failed to address during the interview. In Table 2, these conditions are marked with question marks as conclusions. Using Table 2, the knowledge engineer can formulate questions on these 18 rule conditions to ascertain the appropriate conclusions. For example, based upon Rule 3, the first uncovered simple rule, the knowledge engineer can ask the question: If the company's current credit, collateral, capital and capacity positions are favorable, but financial trends are deteriorating, how would you rate the company's overall financial position? Although asking such questions would eventually complete the table, the number of uncovered simple rules can easily become quite large. If the expert's rules were to involve five variables with three possible values each (e.g., High, Medium, and Low), then a table analogous to Table 2 would contain 243 simple rules. This brute force approach could result in the expert being asked too many questions.

5. Acquiring knowledge with the help of the decision table analyzer

If the set of rules under investigation is nearly complete, a knowledge engineer can use the decision table analyzer to identify conditions not covered by the expert's rules, as described in the first subsection below. In cases where the set is far from complete, the knowledge engineer can use the decision table analyzer to identify potential rules that will enable the set to be completed with the fewest possible questions, as described in the second subsection. The decision table analyzer does more than apply simple combinatorial analysis to identify uncovered simple rules; it summarizes them in a compact fashion by using dashes to abbreviate, reducing the number of questions to be asked of the expert. The analyzer

can also handle variables with any number of values (currently 10), making it applicable to problems characterized by multivalued variables.

5.1. Completing a set o f rules

One purpose of the decision table analyzer is to identify all possible rule conditions which have not been addressed by the expert. Instead of displaying all 18 uncovered simple rules as in Table 2, the analyzer summarizes the rules as shown in Table 3.

The expert's six rules appear on the top part of the table. The analyzer summarizes the 18 uncovered simple rules from Table 2 by the seven system generated rules shown at the bottom. Five of the seven generated rules are abbreviated (sometimes called composite or complex) rules, in which the value of one or more variables is shown by a dash. The dash indicates that the rule ap- plies for all possible values of the dashed variable. By contrast, Table 2 contains only simple rules. The set of generated rules shown in Table 3 is a mutually exclusive and collectively exhaus- tive set, implying that each simple rule that is not covered by any of the six expert's rules is covered by exactly one of the seven generated rules.

Whenever the value of a variable in a generated rule is dashed, the knowledge engineer knows that the expert has not specified a conclusion for any rule in the group of rules formed by replacing each dash with each possible value of the corresponding variable. For example, the first generated rule in Table 3 has three dashes for variables having two values each, and thus represents eight uncovered simple rules. In general, an abbreviated rule can cover a number of uncovered simple rules, the number being the product of the number of possible values of each dashed variable. The knowledge engineer asks the expert for a conclusion for each of the generated rules in Table 3. For example, using the first generated rule in Table 3, the knowledge engineer may ask the following question: If the company's credit position is favorable and financial trends are deteriorating, what is the company's financial position? If the expert cannot answer this question, then the rule may be expanded into a set of

156 J.P. Seagle, P. Duchessi /European Journal of Operational Research 84 (1995) 150-162

simpler rules by replacing one or more dashes with values of the corresponding variables. Lines of questioning are based upon the generated rules, the expert's responses and the knowledge engineer's abilities. In our experience, the domain expert has little difficulty in determining conclusions for rule conditions. After all, the generated rules represent the 'Else' case for the original set of rules obtained from the expert during the initial interview, and often represent impossible conditions.

5.2. Deueloping efficient questions for the expert

When the set of uncovered simple rules is large, the approach described above may not yield many, or any, abbreviated rules for which conclusions can be reached. This would mean that many questions would have to be asked of the expert, and the knowledge engineer would be little better off than by using Table 2.

One way to make the knowledge acquisition process efficient is to generate highly abbreviated rules for which the expert can provide conclusions. For example, in Table 3, Generated Rule 1 is powerful in that it covers eight simple rules and requires values for only two variables. But this power is realized only if the expert can assign a conclusion to the generated rule. If the expert

cannot assign a conclusion to that particular rule, the analyzer has the capability to generate all rules with the same power, or any other level of power. Thus, if a usable powerful rule exists, the analyzer will identify it.

This capability is possible because the seven generated rules shown in Table 3 are not the only set of mutually exclusive and collectively exhaus- tive rule conditions that cover the simple rules remaining after those covered by the expert's rules have been removed. A change in the ordering of the rows or columns of the expert rules causes the analyzer to generate different rule conditions. Any of the possible generated rules may contain highly abbreviated rule conditions for which the expert has a conclusion. By select- ing this second type of analysis, a knowledge engineer can get the analyzer to identify all possible abbreviated rules with any minimum number of dashes, say two or more, as shown in Table 4. The bodies of Tables 3 and 4 are based on computer outputs from the analyzer, given the same six expert rules.

The generated rules in Table 4 are not mutually exclusive; for example, Generated Rules 1 and 2 overlap in that the simple rule with the values T,T,T,F,D is covered by both. However, none of the generated rules overlap the expert rules. Thus, each is a potential candidate for the

Table 3 Expert rules followed by a complete set of generated rules

Rules Conditions

Credit ok Collateral ok Capital ok Capacity ok

Actions

Trends Financial pos

Expert rules: 1 F - - P

2 T T T T I S 3 T T T T S S 4 T F F I M 5 T T F T S M 6 T F T F S M Generated rules: 1 T - - D *

2 T - T F I ? 3 T T - F S 9 4 T T F - I ? 5 T F T T I ? 6 T F T S 9 7 T F F F S ?

J.P. Seagle, P. Duchessi / European Journal of Operational Research 84 (1995) 150-162

Table 4 Decision table with non-exclusive, abbreviated rules

157

Rules Conditions

Credit ok Collateral ok Capital ok Capacity ok Trends

Actions

Financial pos

Expert rules: 1 F 2 T 3 T 4 T 5 T 6 T Generated rules: 1 T

2 T 3 T 4 T

. . . . p

T T T I S T T T S S F F - I M T F T S M F T F S M

- - - D ?

- - F D ?

- F - D ?

F - - D ?

next expert rule. If the expert can attach a conclusion to any of the four generated rules, that rule is added to the set of expert rules and the number of uncovered simple rules is reduced. The analyzer can be set to generate all possible abbreviated rules with any lower bound on the number of dashes. With this analysis, the knowledge engineer can examine every possible rule condition that the expert may use to make a decision with a limited number of facts. In this way, the knowledge engineer can identify efficient heuristics, or powerful rules that consider only a few facts.

Once the expert assigns a conclusion to a generated rule, it is appended to the expert rules and the analyzer run again. Because the generated rules are not mutually exclusive, only one rule should be appended at a time. If more than one rule were to be included with the expert rules, the set of expert rules could contain conflicts or redundancies. The process continues until the possibilities for abbreviated rules are ex- hausted. The table is then tested for completeness, and conclusions are obtained from the expert for all remaining rules.

6. How the decision table analyzer works

The algorithm used by the decision table analyzer to generate and abbreviate rules is de-

scribed with reference to Table 2, in which all possible simple rules for the variables in the table are organized in a pattern. This pattern starts with a collection of variables arranged in an arbitrary order, and another arbitrary ordering of the values of each variable. Then each variable takes on its first value in Rule 1. In Rule 2, the last variable takes on its second value. This pattern, called a fully expanded decision table [14], repeats for all variables and all possible values of each variable. The current algorithm works implicitly with this pattern.

The algorithm starts with several rules given by an expert, and then generates the condition parts of a set of rules that, coupled with the expert's rules, cover all values of all variables. It generates rules by analyzing uncovered rules in the fully expanded table, starting with the topmost uncovered rule. This is similar to one of the approaches used by Maes to convert a decision grid chart into a decision table [14]. Given the sequence in Table 2, the first uncovered rule is Rule 3; it forms the basis for the first generated rule. However, the analyzer's real power is its ability to generate abbreviated rules. It attempts to abbreviate Rule 3 by examining the first variable, 'Credit ok', to determine if a necessary condition for abbreviation exists: the variable takes on its first value, T. If this necessary condition does not hold, the variable cannot be dashed because the prospec- tive dashed rule would be redundant to one of

158 J.P. Seagle, P. Duchessi / European Journal o f Operational Research 84 (1995) 150-162

the expert rules. Suppose a variable in the first uncovered rule does not have its first value. This implies that some rule above in the order must differ only in the value of the first variable, and all rules above are covered because the algorithm started with the top most uncovered rule.

If the necessary condition is met, the algorithm then checks for sufficient conditions for abbreviation: that the expert rules do not cover any higher numbered rules that differ only in the value of the first variable. Because of the pattern in Table 2, each value of the first variable repeats 24 times, and a rule with a number 24 greater than the current rule will differ only in the value of the first variable. Rule 27 differs from Rule 3 only in the value of the first variable. However, Rule 27 is already covered by an expert's rule, leading to the action P. Thus, the algorithm cannot dash the first variable in the rule being generated from Rule 3 of Table 2.

Next, the algorithm checks the second variable of Rule 3, 'Collateral ok', in a similar manner. Because its values repeat 12 times, the rule that differs from Rule 3 only in the value of the second variable is the rule with a number 12 greater, or Rule 15. This rule is not covered by an expert's rule, as shown by the ? action, so the algorithm places a dash for this variable in the rule being generated.

Continuing with the third variable, 'Capital ok', in Rule 3, the algorithm recognizes that the necessary condition of a first value is again met. Because its values repeat six times, the rule that differs only in the value of the third variable is

Rule 9. It is not covered by an expert's rule. However, sufficient conditions are more extensive than before because the rule being generated already has a dash.

Table 3 shows that the algorithm eventually dashes the fourth variable, 'Capacity ok', yielding the first system generated rule in Table 3. This is a highly abbreviated rule with three dashes, and covers eight simple rules from Table 2. After the algorithm has completed its analysis of Rule 3, it moves on to the next rule that is not covered by either an expert rule or a previously generated rule. From this point on, coverage by a previously generated rule is treated as if the coverage were by an expert rule.

The algorithm would be difficult to implement as just described, because explicitly storing the complete table of simple rules would require a matrix with as many rows as the product of the number of values of each variable. Thus, a problem with 14 true or false variables would require a matrix with 16 384 rows. However, the pattern started in Table 2 allows each simple rule to be fully specified by its rule number, and created whenever needed. As a consequence, the only information that the analyzer stores for a simple rule is which expert or system generated rule covers it. The analyzer uses a single vector of 16384 integers which holds all the information required. The analyzer uses a positive integer to show which expert's rule covers a simple rule, and a negative integer to identify the generated rule that covers a simple rule not covered by an expert's rule. We have run the analyzer on a

Table 5 Genera l i zed decision table in s t anda rd form

Rules Var iable

1 2 3 r n - 2 m - 1 m

1 t'(1, 1) t'(2, 1) t(3, 1) 2 v(l , 1) v(2, 1) v(3, 1)

~c(m) ~(1, 1) i~(2, 1) ~'(3, 1)

n t,(1, k(1)) v(2, k(2)) v(3, k(3))

v (m - 2, 1) t ,(m - 1, 1) v (m, 1) v (m - 2, 1) I ( m - 1, 1) v(m, 2)

i ' (m - 2, 1) ~:(m - 1, 1) ~:(m, k(m)) c(m - 2, 1) t:(m - 1, 2) t (m , 1)

t,(m - 2, k (m - 2)) ~.'(rn - 1, k ( m - l ) ) t~(m, k(m))


personal computer for problems with up to 14 binary variables. Should problems exceed the capacity of the algorithm used here, other approaches are mentioned in [14], particularly Shwayder's application of the Quine-McCluskey method [19].

The process of storing which expert rule covers a simple rule also reveals inconsistencies in which more than one expert rule covers the same simple rule. In this respect, the expert's rules are similar to a decision grid chart. Conversion of such charts into decision tables has been covered by Strunz [20] and Maes [14]. A small change in the algorithm allows the analyzer to generate highly abbreviated rules that are not mutually exclusive. This change is simply to ignore coverage by another generated rule. Whenever an uncovered simple rule cannot be abbreviated, then that simple rule is used as a generated rule. Experience shows that substantial abbreviation occurs.

A generalized algebraic representation of Table 2 is given as Table 5. In Table 5, rules are numbered from 1 to n along the left of the table. Variables (conditions) are represen ted by columns, numbered at the top from 1 to m. Let i be a typical variable, with k( i ) different values. In Table 2, the first four variables have just two values, T or F, so k( i ) = 2 for i from 1 to 4, and 3 for i = 5. Values in Table 5 are represented by v(i, j) , where i refers to the variable number and j refers to the specific value. In Table 5 the second subscript of v is an index showing which of the k( i ) possible values v has taken on, not a rule or column number. The fact that v(1, 1) is the leftmost entry in both Rules 1 and 2 implies that both rules start with the same value of the first variable. The rightmost column shows that Variable m cycles through all its values without repetition. The entire cycle repeats as many times as necessary to go through all the rules. The first value of variable m - 1, v(rn - 1, 1), repeats for the first cycle of values for Variable m. Variable m - 1 then takes on its second value for the second cycle of Variable m. The process continues analogously to the left of the table.

The pattern of value repetition described above allows each simple rule to be implicitly associated with a unique number. Procedures based on this

pattern can rapidly determine the number of any given rule, generate the row of values that constitute any numbered rule, and identify the rules that differ only in the value of a single variable. Consequently, the analyzer does not need to store explicitly the complete set of simple rules nor perform pattern matching. A single coverage vector, c(r), r = 1 . . . . . n, records the expert or system generated rule that covers each simple rule.

The analyzer first determines the simple rules covered by expert rules. It then examines the remaining simple rules, those that have not been articulated by the expert, and generates abbreviated representations of these uncovered rules. During the first step, the analyzer examines each expert rule and calculates all the simple rules that it covers. The number of the expert rule is stored in the coverage vector: if Expert Rule e covers Simple Rule r, the number e is stored in c(r). A conflict is identified and reported whenever the analyzer attempts to record a rule number in a coverage vector component that already contains a rule number.

In the second and final step, the analyzer begins by examining the coverage vector to find the number of the first simple rule that has not been covered by an expert rule. This number is used to create the simple rule's components in memory. An algorithm then attempts to generate an abbreviated or dashed rule that describes not only the first uncovered simple rule, but as many other uncovered simple rules as possible. Starting with the simple rule's first variable, the algorithm verifies the presence of a necessary condition for dashing its value: the variable has its first value (i.e., j = 1 in v(i, j)). Otherwise, because of the pattern specified in Table 5, some rule that differs only in the i-th variable has already been covered by an expert rule. If this necessary condition is met, the algorithm posits that the value may be replaced by a dash. It examines the coverage vector to find all simple rules that differ only in the value of the Variable i, and, if the sufficient condition holds that all these simple rules are uncovered, Variable i is dashed and the generated rule number is entered into the corresponding coverage vector components. The algorithm does not mark the coverage vector when it


generates non-exclusive rules which contain a limited number of facts as determined by the knowledge engineer. In this case, the coverage vector shows only coverage by expert rules. The process continues for all variables in the first uncovered simple rule, and for all remaining uncovered simple rules.

A difficulty arises when the analyzer attempts to generate more than one dash. This difficulty has been noted by Whitten et al. [22, p.377] who state that one cannot "consolidate rules based on conditions that have already been identified as indifferent". The analyzer overcomes this difficulty by examining the coverage vector to find all simple rules that are already covered by the current rule being generated. For each such simple rule, the analyzer finds all other simple rules that differ only in the value of the current variable. Only if all such rules have not been covered may the current variable be dashed in the current rule

being generated. This is a more complex set of sufficient conditions than for the case of a single dash.

7. Using decision tables and the analyzer to develop a complete knowledge base

Fig. 2 displays a partial inference tree for the commercial lending problem. Decision Table 1 contains rules that make conclusions about financial position. It shows only the first rule, which is Rule 1 of Table 2, of the many rules actually involved. It also shows part of another rule which has 'Credit OK' = F as one fact in its rule condition. The figure's remaining decision tables contain rules that apply to other parts of the inference tree, although only one rule for each table is displayed. Decision Table 2 contains the rules that make conclusions about Credit: 'Credit

Table t

Ru le 1

c,--T II cP=T i Table 2 I C f

Rule 1 ~

=T i

Rule 1

Fig. 2. Inference tree.

I CR=F t

FP = Financial pos CO = Collateral ok CR = Credit ok CA = Capital ok CP = Capacity ok T = Trends P = Profitabil ity ok L = Liquidity ok E = Efficiency ok


OK'= T and 'Credit OK'= F. The conclusions, or subgoals, appear as facts in the rule conditions of Decision Table 1.

A knowledge engineer uses the decision tables and the analyzer to develop a complete knowledge base by repeatedly applying the analyzer to examine and complete each decision table. For example, the knowledge engineer, armed with several seed rules, uses the analyzer to acquire the rules that reach conclusions about Efficiency and they would be contained in a third decision table. The rules are only a portion of the entire inference tree or knowledge base. The knowledge engineer uses another decision table and reap- plies the analyzer to acquire the rules for Liquid- ity. Another iteration yields the rules for Prof- itability: When a decision table is complete and has no inconsistencies, the knowledge engineer adds the rules to the knowledge base; the knowledge base grows each time the rules of a decision table are added to it.

At a higher level in the inference tree, the knowledge engineer uses decision tables and the analyzer to examine and complete decision tables whose rule conditions contain facts that are conclusions in lower level decision tables. For example, the conclusion, 'Efficiency OK = T', of the single rule appearing at the bottom of Fig. 1 is a fact in the rule condition of the single rule shown in Table 2. Similarly, the conclusions of Decision Table 2 appear as facts in the rule conditions of Decision Table 1. By repeatedly using the decision tables and analyzer to complete each of those tables, the knowledge engineer builds the entire knowledge base.

In the CLASS project, we first specified the overall structure of the knowledge (see Fig. 1), and then began at the bottom of inference tree and moved upward. We completed decision tables for detailed factors, such as Profitability, Efficiency and Liquidity; before moving upward to Credit, Collateral, Capacity, Capital and Trend Analysis. In the CUE project, without the benefit of a predefined structure, we began at the top of the inference tree and moved downward from major components of the control unit to sub components which were discovered during the knowledge acquisition process. CUE deals with a

diagnostic problem for which other approaches exist, but the table approach was useful for components in which several observed variables had to be analyzed together.

Generally, the inference tree for real projects is prohibitively large. Decision tables provide a convenient way to represent large portions of the tree and analyze them. Collectively, the decision tables represent the entire inference tree, or knowledge base, and address the relationship be- tween the conclusions and facts: a conclusion or subgoal in one table appears as a fact in the rule condition of another table.

8. Conclusions

This paper reports an adaptation of a system development approach, the decision table, to knowledge acquisition. To make this application practical, we developed a decision table analyzer that extends the traditional uses of the decision table to the acquisition of expert system rules. The analyzer identifies incompleteness, redun- dancy and conflict before rules are incorporated into an expert system. By making the knowledge engineer aware of these potential problems, sub- sequent prototyping and field testing efforts can focus on validating the correctness of the rules, rather than finding errors of incompleteness and conflict. The major contribution of the analyzer is in providing the knowledge engineer with powerful potential rules that reduce the number of questions to be asked of the expert, without sacri- ficing completeness. Using the abbreviated tables produced by the analyzer, the knowledge engineer can formulate a line of questioning for acquiring missing rules and identifying heuristic rules. Newly acquired rules are entered into the expert rule portion of the decision table and reanalyzed. Each repetition moves the knowledge engineer to a more complete realization of the expert's knowledge.

On the other hand, the approach is not fully automatic. It requires an expert to supply the seed rules and provide conclusions for rule conditions posed by the knowledge engineer. It leaves the estimation of uncertainty measures to other

162 J.P. Seagle, P. Duchessi /European Journal of Operational Research 84 (1995) 150-162

analyses, as do other computer-based methods. For example, it can be used to develop a fuzzy system's rule table(s), but not the fuzzy functions which are determined by assessing relevant mem- bership values for an associated scale. The approach does not generate a search process; it assumes the availability of either backward or forward chaining inference engines. The approach can only be used for rule-based representation schemes; it is not applicable for developing frame or object-based applications. The approach does not simultaneously address conflicts among all decision tables and completeness of the total knowledge base because the knowledge engineer focuses on one decision table during each iteration.

Acknowledgments

The authors are grateful to the managers and staff of the General Electric Corporation who participated in the expert system development projects.

References

[1] Barr, A., and Feigenbaum, E. A., The Handbook of Artificial Intelligence, VoL H, Addison-Wesley, Reading, MA, 1982.

[2] Buchanan, B. G., Barstow, D., Bechtal, R., Bennett, J., Clancy, W., Kulikowski, C., Mitchell, T., and Waterman, D. A., "Constructing an Expert System", in: F. Hayes- Roth, D. A. Waterman and D. Lenet, (eds.), BuiMing Expert Systems, Addison-Wesley, Reading, MA, 1983, 127-168.

[3] Clancey, W. J., "Heuristic classification", Artificial Intel- ligence 27 (1985) 289-350.

[4] Dietz, P.W., "GEN-X: An environment for building rule-based Expert Systems", General Electric Corpora- tion, Technical Report No. 86CRD041, 1986.

[5] Duchessi, P., Shawky, H., and Seagle, J. P., "A knowledge-engineered system for commercial loan decisions",

Financial Management: Special Issue on Expert Systems 17/3 (1988) 57-65.

[6] Eshelman, L., Ehret, D., McDermott, J., and Tan, M., "Mole: A tenacious knowledge-acquisition tool", Inter- national Journal of Man-Machine Studies 26 (1987) 41- 54.

[7] Gaines, B. R., "An overview of knowledge acquisition and transfer", International Journal of Man-Machine Studies 26 (1987) 453-472.

[8] Gallagher, J. P., Knowledge Systems for Business: Integrat- ing Expert Systems and MIS, Prentice-Hall, Englewood Cliffs, NJ, 1988.

[9] Harmon, P., and King, D., Expert Systems: Artificial Intelligence in Business, Wiley, New York, 1985.

[10] Holsapple, C. W., and Whinston, A. B., Building Expert Systems, Irwin, Homewood, IL, 1987.

[11] Humby, E., Programs from Decision Tables, American Elsevier, New York, 1973.

[12] Karbach, W., Linster, M., and Voss, A., "Models of problem solving in knowledge based systems: Their focus on knowledge acquisition", in: Proceedings of the 5th Knowledge Acquisition for Knowledge-Based Systems Workshop, SRDG Publications, Department of Com- puter Science, University of Calgary, Calgary, Alta., Canada T2N 1N4.

[13] Kim, J., and Courtney, J.F., "A survey of knowledge acquisition techniques and their relevance to managerial problem domains", Decision Support Systems 4 (1988) 269-284.

[14] Maes, R., "An algorithm approach to the conversion of decision grid charts into compressed decision tables", Communications of the ACM 23/5 (1980) 286-293.

[15] Marcus, S., Automating Knowledge Acquisition for Expert Systems, Kluwer Academic Publishers, Dordrecht, 1988.

[16] Messier, W. F., and Hansen, J. V., "Inducing rules for Expert System development: An example using default and bankruptcy data", Management Science 34/12 (1988) 1403-1415.

[17] Montalbano, M., Decision Tables, Science Research As- sociates, Chicago, IL, 1974.

[18] Olson, J. R., and Rucker, H. H., "Extracting expertise from experts: Methods for knowledge acquisition", Ex- pert Systems 4/3 (1987) 152-168.

[19] Shwayder, K., "Combining decision rules in a decision table", Communications oftheACM 18/8 (1975) 476-480.

[20] Strunz, H., "The development of decision tables via parsing of complex decision situations", Communications of the ACM 16/6 (1973) 366-369.

[21] Turban, E., Experts Systems and Applied Artificial Intelli- gence, Macmillan, New York, 1992.

[22] Whitten, J.L., Bentley, L. D., and Barlow, V. M., Systems Analysis and Design Methods, 2nd ed., Irwin, Homewood, IL, 1989.

Documents

Acquiring expert rules with the aid of decision tables