Expert systems: rule order

Rules seemingly have the same format as IF.. THEN.. statements in any other conventional computer language. The major difference is that the latter statements are constructed to be executed sequentially and always in the same order, whereas expert system rules are meant as little independent pieces of knowledge. It is the task of the inference engine to recognize the applicable rules. This may be different in different situations. There is no preset order in which the rules must be executed. Clarity of the rule base is an essential characteristic because it must be possible to control and follow the system on reasoning errors. The structuring of rules into rule sets favours comprehensibility and allows a more efficient consultation of the system. Because of the natural resemblance to real expertise, rule-based expert systems are the most popular. Many of the earlier developed systems are pure rule-based systems. 

Explanation. A user may ask for explanation of the line of reasoning at any time during an expert system consultation. RuleMaster presents explanation as a list of premises and conclusions in English-like text. The explanation describes the execution path which led up to the current conclusion or question. Explanation is presented in proof ordering, which usually differs from the order in which the questions and conclusions were encountered. This is perceived as more relevant and understandable than the time-ordered presentation of fired rules, as is present in most expert system approaches. 

Expert systems differ from standard procedural or object-oriented programs in that there is no clear order in which code executes. Instead, the knowledge of the expert is captured in a set of rules, each of which encodes a small piece of the expert s knowledge. Each rule has a left-hand side and a right-hand side. 

In any expert system, explanations of the decisions made are important, both for instruction of the user and for maintenance of the system. Explanations in GSH take several forms. There are explanations for the development steps and their ordering provided by the designer of the knowledge base. Detailed explanations of the rules activated, formulae used, or individual scores of actions can be generated if required, and canned text and literature references are provided for general knowledge. 

Work on expert systems in the specific domain of tablet film coating was initiated in April 1990, using a rule induction tool in order to develop a system for the identification and solution of defects in film-coated tablets. Although not strictly a formulation expert system, the developed system did contain knowledge whereby a given formulation known to cause defects could be modified to provide a solution. The completed system described by Rowe and Upjohn. 

This chapter provides an overview of expert-system verification and validation (V V) techniques. Several methods are presented. First, many of the conventional software V V techniques such as requirements analysis and unit testing can be applied to expert-system development. Second, an expert-system developer can use automated tools to test rule consistency and structure. A more viable alternative, however, is for the developer to create his own set of consistency and completeness tests. Finally, a developer should rely on qualitative judgment to determine the validity of a knowledge base. This judgment could include expert opinion as well as specialized tests designed to determine knowledge-base certification. The chapter suggests that methods should be combined into an optimal mix in order to best undertake V V. 

Rule order may influence both the operation (and therefore the results) and the execution time of a rule base. Therefore it is necessary to test the expert system under a demanding variety of scenarios. 

To build a pharmaceutical formulation expert system, the formulation process has to be broken down into a number of discrete elements in order to provide distinct problem-solving tasks, each of which can be reasoned about and manipulated. However, as the formulation process is so complex, none of these tasks can be treated independently. A means of representing interactions and communicating information between tasks is therefore required. For example, one task may result in certain preferences that must be taken into account by subsequent tasks. To achieve this level of communication between tasks, the information in an expert system has to be highly structured and is therefore often represented as a series of production rules. An example of a production rule is as follows ... 

In order to convert an expert system to an intelligent tutoring system, the expert system must be able to explain its answers. This explanation facility has been added to the PIRExS program by means of amendments to the rules and by addition of disk files that contain all the rules expressed in natural language (English). 

At present the Expert System can only learn by being told, i.e. by having new or revised rules entered by an expert. In order to make it more robust other ways of learning need to be introduced. 

Expert systems, as defined by the encyclopaedia, are programmes made up of a set of rules that analyze information (usually supplied by the user of the system) about aspedfiic class of problems, as well as provide ai ysis of the problem(s), and, depending upon their design, recommend couise of actions in order to iniplement corrections. In layman s terms, Expert Systems are computer programnes that are built to perfonn at a human expert level in a narrow, specialised domain. 

---