The Role of Deterministic and Non-Deterministic Rule Scheduling in Expert Systems

The Role of Deterministic and Non-Deterministic Rule Scheduling in Expert Systems

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..<i;ignment..<;:;) and/or invocations 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 <condition> THE:\ < rule-group> act in this setting like subroutines in a conventional programming environment. 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

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    15 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us