Submitted to the Sixth National Conference on Artificial Intelligence
The Role of Deterministic and Non-Deterministic Rule Scheduling in Expert Systems
Arthur B. Baskin Departmenl of ;\'ledicaJ Information Science University of TlIinois at L'rbana-Champaign 1408 W. University Avenue t;rbana. IL 61801 Telephone: (217) 333-8007 Arpanet: [email protected]
Robert E. Stepp Artificial Intelligence Research Group Coordinaled Science Laboratory University of Illinois at Crbana-Champaign 1101 Wesl Springfield Avenue L'rbana.IL 61801 Telephone: (217) 333-6071 Arpanet: [email protected]
Topic Area: Automated Reasoning Subtopic Area: RUle-based Reasoning Science Track
Keywords: Control Scheme; Rule Scheduling: Expert Systems
ABSTRACT Expert system problem solving ability depend!; on knowledge comprising both inferential relations between concepts and a strategy for their application. Existing expert sy..tcms U!ie a fe"" generic conll"ol strategies such as for""ard anu back.v.'ard chaining to reduce the amount of procedural knovdedge that is supplied by a domain expert. Systems generally do not accept much meta-kno""ledge about 110"" to manage the rules in the kno""ledge ba!;e and in so doing. they cannot follo"" rule scheduling strategi"" based on explicit problem r;oh"ing expertise coming from the domain expert. This is most usually noticed a!; inadequacies in expressing heuristics for problem decomposition and the solicitation of input data. A knov.·ledge engineer may try to overcome the inadfquaci"" by using sp«ially engineered rul"" that have scheduling side elf«t~ but at the cost of time. under'ltanc:lability. and maintainability.
The mis~ing element in present expert ..ystem~ is a formalir;m that can provide explicit kno'4'led¥e engineer cont 1"01 o,'er rule c;equendng as ~'ell at the customary ..cheduling ..chemes. Explicit conll"ol adds a l)rocE'dural m«hanism that can hi' used in an organized '4'ay to de'termini~tically inlJuence the <;<:hedulin¥ of "y<;tem acth·ities. The idea of a n.le group a~ a control <;cheme annotated knowledge block is introduced for calHuring and manipulating both procedural and declarative kno\J.-Iedge in a well structul"E'd object·orientcd way.
Major ~upport for thi:. research is provided by the Olftce of Nanl Research under grant NOOOI4-X2-K·OllSb and hy the Ndtional Science Foundation 'lnder grant NSF 1ST ~S-ll1iO; additional support is pro\"lded hy the IA-panment of Delense Adnnced Research Projects Agency under ~rant NOOO14-I5S·K-0078 and by iI contract for the study 01 ':llmplett'ness and conSIStency checking in rule hases from Compagnie Go:neral Electric European Support Ccnter. 1. Introduction
The now common paradigm of expert systems evolved from the inadequacies of purely procedural approaches to building problem solving systems. Human expertise expressed as procedures (e.g .. as conventional computer programs) was sufficient when available in complete detail [Bleich. 1972]. but such problem solving knowledge is very difficult to acquire. critique. refine. and interpret. The modularized structure provided by production rules. their improved ease of interpretation and critiquing. and their non-procedural deductive evaluation made them much more effident than procedural languages for building large problem solving systems.
The very concise non-deterministic statement of rule scheduling that makes non-procedural knowledge bases easier to build leads to problems when domain specific procedural knowledge needs to be taken into account. The difficulty presently experienced is the unpredictability of rule firing order as it affects problem decomposition. the acquisition of data. and search effort.
Knowledge engineers presently need to handcraft clever r.ules that affect rule precedence (order of use) as side effects of the way they fit in the inference chains. Such rules require great skill to write and they are very difficult to interpret because they do not contain domain expertise but engineering tricks to make the non-procedural approach have a procedural effect. The indirect encoding of this procedural information effectively obscures it in much the same way that encoding knowledge directly in program code obscured it in the past.
The above observations are important because experience with expert systems has shown that
the bottleneck is the acqUisition and refinement of knowledge [Ginsberg. Weiss. and Politakis.
1985]. Knowledge acquisition aids have grown in importance. including the development of
intelligent knowledge engineering tools to search and edit large complex knowledge bases and the
application of inductive inference techniques to the knowledge acquisition task. The hurden of
maintaining massive knowledge bases has also led to new design ideas for further structuring the
knowledge. Even with these aids. the acquiSition and management of expertise still demands a
formalism that makes plain those parts of the knowledge that encode domain expertise and those
2 that manage and direct system behavior and consultation session dynamics. A casual mixture of the two confounds system maintenance and limits knowledge base size simply because of knowledge engineer confusion.
In this paper. the role of procedural knowledge that is processed in a deterministic way
(sequenced a priori). and the role of inferential knowledge that is processed in a non-deterministic way (sequenced in the context of a particular problem) are explored. The view taken is that both types of knowledge are required to varying degrees and that th~y are to be woven together to best carture expertise. rather than to rigidly force a particular knowledge structure.
2. Structuring large numbers of rules
In complex expert systems. rules are profitably organized into rule sets called rule groups.
The immediate advantage to such an organization stems from the connectedness of the rules: certain subsets of rules perform chunks of inference that solve subproblems and are best organized into a functionality hierarchy built of rule groups. The rule group thus possesses a perceived goal. and that plus their modest size makes knowledge engineering over rule groups easier than manipulating individual rules in the universe of the entire knowledge base.
Rule groups also provide a way to carefully fit the rule dynamics to the subproblem they address. For example. inference over some sets of rules works much better in a forward-chained environment. While for other sets of rules. the better strategy may be backwards-chaining. As knowledge bases grow. it is less and less acceptable to pick just one single rule scheduling scheme for all the rules.
The choice of forward versus backwards chaining scheme is but one of a number of rule retrieval/evaluation/application control parameters that may need to vary from one part of the knowledge base to another. A currt'ntly missing dimension to controlling rule use goes back to the first historical perspective mentioned above: the need to facilitate both declarative inferential knowledge an.d procedural knowledge for solving problems. In many domains. there is important heuristic ~xrertise embodied as wise procedure-driven (sequence structured) inferences.
3 3. Scheduling large numbers of rules
Rules can be viewed as declared implicative statements and as IF ... THEl\ programming
constructs. depending on the way they are used to capture expertise. The system must be capable
of handling rules in a variety of ways. with the knowledge engineer able to specify the appropriate
view. A rule group is defined as the the smallest unit of rules with a common knowledge engineer
defined control mechanism. Thus. a rule group is composed of zero or more rules. each having a
condicion part and an actu.m part. The condition part can be any logical combination of predicates.
The action part ~an he a conjunction of assertions (variable value as.. of other rule groups. The rule processing mechanism in an expert system needs to perform three fundamental proce~..ses: • Rule retrieval: the selection of one or more relevant candidate rules from th~ rule group to be explored in more detail. • Rule evaluation: the evaluation of one or more of the condition parts of candidate rules to determine a set of satisfied rules. • Rule application: the selection of one or more of the satisfied rules and the performance of the rule's action part. Thus. the rule interpreter operates by asserting a precedence relation over rules for retrieval. condition evaluation. and. action performance. A particular rule scheduling strategy defines the precedence relations in a particular problem-oriented way. 3.1. Deterministic rule scheduling Deterministic rule scheduling makes an explicit procedural statement about rule precedence. This may be a linear sequence of rules to consider. or it may he a graph precedence using any of the conditional and iterative How control mechanisms in modern programming languages. A sample deterministic rule group is shown in Figure 1. Statements of the form IF Whereas a subroutine is a deterministic procedural form. the rule group may be either like a deterministic subroutine or a non-deterministic inference subprocess that plays a particular role in the decomposition of the problem. 3.2. Non-Deterministic rule scheduling ;\ion-deterministic rule scheduling makes a declarative statement about rule precedence. The order of rule selection is implicitly defined by the non-deterministic strategy and ultimately determined by the state of the system during problem solving in conjunction with the capabilities of competing rules. Typical strategies give precedence LO the rules with the greatest utility. or the rules that can most likely progress from currently available information. or the rules that can most likely infer currently needed information. A sample non-deterministic rule group is shown in Figure 2. DEGI~-R L'LE-GROL'P .. rg-one" A::\:l\i OTA TI01\:: use-deterministic-sc heduling IF Each Fig. 1: A sample deterministic rule group. BEGIX-RLLE-GROUP "rg-two" A:\:\OTATIO:\: use-forward-chaining IF < cond 1 > THE\; < action 1 > IF E:\O All rules are under consideration by the forward-chaining control scheme at all times. The actual order of rule use cannot be determined until inference is actually attempted in the context esta blished by presenting a particular problem. The precedence relation over a particular rule is influenced by its contribution to the current state of the inference process in the presence of other competing rules. Fig. 2: A sample non-deterministic rule group. 3.3. Deterministic versus non-deterministic scheduling Figure 3 illustrates the relationships between the degree of scheduling imprecision (i.e.. degree of non-determinism) versus a host of other rule group aspects. At the left-hand extreme are the purely non-deterministic scheduling mechanisms normally found in expert systems. The purely non-deterministic mode provides for concise statements of expert knowledge in which rule scheduling is in the hands of the selected control scheme and no explicit statements of rule precedence are given. This type of rule group is well suited to capturing shallow knowledge often found in the inference network of a typical knowledge base. :\on-deterministic scheduling is particularly ill suited to the task of specifying system behavior during inference. For example. many a knowledge engineer has tried to write rules to influence the order of solicitation of input data or evaluation of certain rules. In conventional systems that only practice non-deterministic rule scheduling. this is an alien goal and such attempts to introduce explicit precedence relations ihvariably lead to brittle systems with expert knowledge and system behavior directives inextricably woven together. The result is confusion and hardship in maintaining and understanding the two as separate facets of the system-one often 6 needs to adjust system behavior without compromising the expert knowledge. and vice-a-versa. The non-deterministic end of the scheduling envelope in Figure 3 is the widest to account for scheduling freedoms in the choices of • forward-chaining versus backward-chaining. • backtracking through rule interpretation choice points versus the hill-climbing approach. • one-shot rule firing versus repeated rule firing. The right-hand side of Figure 3 corresponds to purely deterministic rule scheduling. Here the knowledge engineer provides an explicit statement of rule precedence for retrieval. evaluation. and application. This statement is verbose and possibly difficult to write. Because there are explicit rule scheduling instructions. rule groups with purely deterministic scheduling are best for Envelope of rule scheduling flexibility Iterative and Other dimensions recur~ive control or scheduling control Degree 0" :'\on-deterministic Deterministic implicit rule precedence explicit rule precedence more concise more control shallow know ledge deep knowledge Fig. 3: .l.. portrait of some relationships on rule scheduling. 7 capturing deep. procedure based domain knowledge. The enclosing envelope is narrowist at the right because rule order is totally constrained by the explicit control of the knowledge engineer. :\'Ioving a little left of the deterministic extreme. one finds the introduction of structured deterministic control. such as iteration and recursion over rules and rule groups. Moving right to left the verboseness changes gradually into conciseness and explicit precedence over rules changes into implicit precedence. The middle region between the pure deterministic and non-deterministic extremes is an area that corresponds to systems with mixed control strategies. i.e.. with some rule groups that handle a non-deterministic part of the solution calling on and called from rule groups that handle a deterministic part. For example. a mostly non-deterministic approach (near the left end of the drawing) would have traditional inference behavior (non-deterministically scheduled rules) with system behavior control vested in deterministic rule groups. 4. Inter-rule scheduling to meet the demands of problem domains The knowledge base for a large. complex expert ..system requires the structure here described as the rule group. Each rule group is captured by the knowledge engineer and checked for completeness and consistency (tasks that are simplified via the rule group approach). The knowledge engineer may dial any desired degree of scheduling impreciSion as We decides what level of scheduling control versus conciseness is appropriate. Deterministic rule scheduling is most likely to be used for the rule group or groups near the root (beginning subproblems) in the tree of all rule groups. This corresponds to the presence of real world knowledge that dictates the gross decomposition of the problem and choice of strategy. Important procedural information might be captured to determine the appropriate order of subproblem investigation. or the choice of the best solution strategy from among several alternative inference chains. This type of knowledge can be clearly and concisely stated in a deterministicly scheduled rule group containing rules processed in a knowledge engineer specified order to activate other rule groups according to problem specific conditions. 8 This can ~ illustrated by considering the stereotypical problem of bin packing. With complete knowledge of the packing rules (packing constraints) but without procedural expertise. extensive searches must be conducted to find a solution. A non-deterministic control strategy by itself lacks the domain specific knowledge to equip it with an expert provided sequence of relevant subproblems that can reach a solution with much less searching. Heuristic knowledge for grocery packing such as "separate items into hard and soft categories: then pack hard objects: then pack soft objects" is a piece of top level problem decomposition expertise that is most easily captured by a deterministic formalism. The other place where deterministic scheduling is of great importance is the solicitation of input data. To achieve a satisfying user dialogue. data requests need to be ordered in a domain sensitive way by the knowledge engineer. Ordering of requests to please the user should not affect the inferential knowledge content of the system but only its order of rule application. Rules pertaining to related concepts should be scheduled together so that input requests they spawn are intellectually satisfying. Deterministicly scheduled rule groups make the job easy and well managed whereas an imposed non-deterministic strategy forces the knowledge engineer to corrupt the inference structure with special effect rules that break easily and have no problem relevance other than to to perturb rule order. S. Intra-rule scheduling to meet the demands of problem domains Individual rules possess their own deterministic versus non-deterministic control possibilities. In rule right hand sides. a conjunctive form is normally a non-deterministic structure. i.e .. its semantics say nothing about the order of evaluation of the conjuncts. There may be times when evaluation order may need to be explicitly stated for the well structured management of evaluation side effects attached to external real world data (such as managing the user dialogue) . .-\t other times it may be best for the order to be determined dynamically by the system to minimize the demand for data for which alternative sources exist. Again. no one scheme covers all cases. 9 It may be that certain conjuncts carry more weight that others. so that a system with limited resources may wish to evaluate some variables used in the left hand side of a rule while assuming default values for others. according to a preplanned way to get an approximate evaluation that is as good as possible under the imposed time/computation constraints. This within rule control strategy could practice a form of variable precision logic [Collins and \1ichalski. 1986]. Knowledge engineers are becoming increasingly aware that merely constructing a knowledge base that will support certain inferences is not enough. The knowledge base must be maintainable (i.e.. able to be automatically checked for consistency and completenes.-;) and understandable. In both regards. the structure of the knowledge becomes as important as its ability to sustain inference. Structure in a knowledge base includes grouping related knowledge tog~ther and proposing a precedence relation on it for optimized use. 6. Combined scheduling schemes The idea of this paper is that an important part of the knowledge base is the expression of the precedence relation on rules for retrieval. evaluation. and application. The precedence relation is part of the meta-knowledge of the system. The knowledge engineer should be able to specify the precedence himself (deterministic scheduling) or have the system do it through an established strategy (non-determinist scheduling). The approach taken in theory and in practice is the decomposition of the knowledge base into rule groups that have annotations giving control scheme information. This approach is being taken in the latest versions of the ADVISE tool for building expert systems [:\-lichalski and Baskin. 19~3]. The annotated rule group provides the basic control over rule scheduling. As illustrated in Figs. 1 and 2. the rules in a rule group are subjected to either a non-deterministic scheme or a deterministic one. Presently twelve non-deterministic schemes are known to the ADVISE system. These are built from strategies that combine the four dimensions forward-chaining/backward chaining, depth-firstibreadth-first· rule. activation. backtracking/hill-climbing. and single shot/multi-shot rule firings. For deterministic rule scheduling. the rules are taken in the order 10 presented in the rule group. as modified by iteration constructs. A series of initialization actions. such as the acquisition of labdata values that are always required. is performed by a deterministly scheduled rule group containing imperative. statements of the form IF TRL'E THE:\! For data acquisition the action may be a system primitive that triggers prompting and input from the user. For data initiali?.8tion. the action can be an assertion of the form [variablename,.. value]. 6.1. Rule groups as objects It is profitable to view rule groups as instances in an object-oriented world such as the Flavors system [Weinreb. 1980]. A rule group thus consists of values to instance variables along with method procedures defining computations over rule groups. Both instance variable and method definitions may be inherited from a hierarchy of superclasses. The rules in a rule group are assigned as a list to the rg::CONT AI~ED-RCLES instance variable. where rg is the name of the rule group and the double colon sets off an internal symbol within the rg structure. The control scheme is embodied in the method rg:oo where rg is again the name of the rule group and the single colon sets off an external symbol within the rg structure. The :00 method may be inherited or it may be unique to a particular rule group. By o.bject-oriented design. a rule is also cast as an object. but of a different type. A rule (simplified to our purposes here) is an object with three basic parts: a condition. an action. and strength-of-inference parameters. The condition part is an object having among other things a method cond:EVALL"ATE for evaluating the degree of satisfaction of the condition. The action part is an object having a method act:oo for performing conjunctive actions (by invoking :DO for each conjunct object). In this way rules containing rule group names in their left hand side fit well the standard rule semantics and implementation: when application of a rule group is needed. its :DO method is invoked. 11 A rule group's :00 method contains its control scheme-either a non-deterministic one or a deterministic one. Thus the activation of the :00 method causes rules to be processed under some precedence relation. In a deterministic :00. the rule (objects) are processed in list order. as written. Iterative constructs lead to the recursive application of :00 to the internal parts of the construct (i.e.. to invoke the rules in the body of the iteration). Invoking the :00 method for a non-deterministicly scheduled rule group works in the same way except that the method is the control procedure that dynamically determines rule precedence and takes rules in· that order rather than definition order. Thus. the :00 method serves two purposes: 1. it makes operational in an object-driven way the system interpretation of the various knowledge forms comprising the knowledge base (Le .• it provides the appropriate processing semantics to each form). 2. it provides a place to store explicit meta-knowledge for each rule group that is separate from the knowledge itself. The one mechanism provides the full range of possibilities depicted in Fig. 3. :'\jow let us consider the encoding of the :00 method itself. While the practiced LISP programmer would immediately think if it as just a LISP function or an attached procedure. another interesting possibility exists: .the :00 method could be a rule group. When thinking of the :00 method as a rule group. it would seem obvious that circularity of methods should be avoided. since execution of a rule group requires another :00 method to schedule the rules. Assume that purely deterministic rule groups have a system defined :[)() method that is not another rule group. Such rule groups can then be used (in a procedural way) to define :00 methods for other rule groups. Thus non-deterministic control schemes may be written within the language of the knowledge system as deterministic rule groups. When control schemes are written as rule groups. inference over control logic becomes possible for better understanding the control meta knowledge and for its optimization. revision. and consistency and completeness checking. 12 Whether to code :00 methods as LISP procedures or as rule groups in the knowledge base depends on the perceived balance of processing speed against knowledge engineer control and understanding. It would seem likely that some special kinds of expertise would sometimes require adapting the control scheme in a problem dependent way. The mechanism of method based rule group control schemes has this flexibility. 7. Conclusion The rule group construct provides a knowledge block for structuring rules in large. complex knowledge bases. The rule group focuses the' knowledge engineer on knowledge subsets that solve application subproblems. Annotation of the rule group by the object-oriented scheme of inherited methods provides a powerful way to use both implicit non-deterministic control strategies with explicit deterministic control strategies. The latter form has all the power of contemporary programming languages and can even be used to procedurally describe the inference control scheme applied to non-deterministic rule groups. In an object-oriented approach. the various control strategies are alternative bodies for a rule group's :fX) method. The benefits of this approach to rule precedence control are • separation of knowledge and control (meta) knowledge: consistency and completeness checking is made easier: interpretation of the rule is not confused by myriad special side effects otherwise needed to control rule firing order. • more flexible control strategies: each rule group in the knowledge base may have its own most appropriate control strategy applied to the rules within it. • built-in and knowledge engineer defined control schemes: the knowledge engineer may use either a built-in (underlying languaged coded) control scheme for a common strategy. or he may use a specially defined (rule language coded) control scheme for special effect. The object-oriented approach to separate but yet linked knowledge and control can be applied to expert systems in many ways. The:OO method from the previous section was said to operate both 13 with rule group objects and with rule objects. This gives rise to further flexibility: evaluation and application schemes for rules that can be system or knowledge engineer defined. Current research on the ADVISE tool for building expert systems involves developing this approach. Precedence control (obtained via explicit or implicit control schemes) serves to increase the efficiency of the human user of the system and of the system itself. By specifying intelligent precedences over data acquisition. the dialogue between the machine and the user better serves the user. By specifying intelligent precedences over high level rule groups. the basic subproblem solution strategy is better captured. making the system focus more keenly on the user's type of problem. By specifying appropriate precedences over rules within each rule group. the system applies the scheme that is most efficient for that set of rules. as determined by the knowledge engineer for a particular problem. By specifying appropriate precedences over elements within the left- and right-hand sides of rules. the system can more efficiently process the rule without compromising any problem implied rule semantics or side effects. In a nutshell. knowledge is power and power requires control. The techniques outlined here provide flexible new approaches for managing large. complex expert systems. 8. References Bleich. H.L.. "Computer-based consultation." ,tmerican Journal of Medicine. Vol. 53. Pp. 285-291. 1972. Collins. A .. and Michalski. R.S.• "The logic of plausible reasoning: A core theory," Cogniti.ve Science. Vol. 11. 1987 Ginsberg. A .. Weiss. S.• and Politakis. P.. "SEEK2: A generalized approach to automatic knowledge base refinement:' Proc. of the Ninth l1Uem. Jvint Con/. on. Arliftci.o1 l1Uelligen.ce. Los Angeles. CA. Pp. 367-374. 1985. Gordon. J .. and Shortliffe. E.. "A Method for ylanaging Evidential Reasoning in a Hierarchical Hypothesis Space." Artiftciallntelligence. Vol. 26. Pp. 323-3.57. 1985. Ylkhalski. R.S.. and Baskin. A.B .. "1ntegrating Multiple Knowledge Representations and Learning Capabilities in an Expert System." Proceedings of Intern. Joiru Conf. on Arriftcial Intelligence. Pp. 256-258. 1983. 14 Srackman. K.• "A Program for Machine Learning of Counting Criteria:' Computer Methods and Programs in. Biomedicine. Vol. 21. Pp. 221-226. 1985. Sridharan.~ .. "Evolving Systems of Knowledge:' AI Maga=ine. Pp. IOS-120. Fall. 1985. Weinreb. D.. and :\'Ioon. D.. "Flavors: :\Ies."iage Passing in the Lisp Machine:' :\lemo 602. MIT AI Lab. Cambridge. :\1A. ~ovember. 1980, IS