I divide decision support software into three categories for the purpose of my explanation.
It should be noted that expert systems or related techniques are potentially applicable in many areas which are not directly concerned with decision making. Indeed there are few areas which may not be affected by these techniques. In particular, for example, 'Application Productivity' could be a major benficiary. I wi1l confine -my attention to the applications more relevant to decision support.
4.1 Development of existing decision support packages
There is a great deal of scope for development to packages intended to provide support for decisions by more or less traditional (by comparison with AI methods) data processing techniques. To provide a comprehensive range of such packages and integrate them into the office automation system is not a trivial venture. This area is well covered by Dr. Cooper in his paper on Decision Support Systems, and I am not competent to improve on his analysis.
These packages could (and should) as Dr. Cooper suggests be improved by more user-friendly interfaces, and comprehensive user guidance facilities. A great deal could be done along these lines without encroaching upon controversial and ill understood AI techniques, and the results might then be marketed as a species of 'expert system'.
Within this category fall the existing relational database Management systems and query languages. This is not to say that they are not sophisticated products, but rather that they do not, I believe, currently make use of knowledge base techniques or make any non- trivial inferences on behalf of the user. Further developments to relational database facilities should take into account the needs of expert systems as well as offering direct use of the more convenient and powerful database and knowledge base access facilities obtainable by the new techniques, Relational databases could be the stepping stone from which the database/knowledge base management - facilities required by software of categories 'b' and 'c' is developed.
4.2 Ready built expert systems
Expert systems using knowledge engineering techniques over different problem domains have more in common with each other than they have in common with more traditional packages in similar problem areas. To attempt to extend existing packages by adding knowledge engineering techniques would be unlikely to produce satisfactory results. It would fail to produce satisfactory expert systems and would place an intolerable overhead on the user who does not require the 'expert' capabilities. Nevertheless, it is desirable that expert systems should be able to exploit directly the capabilities of existing packages. To this end it is desirable that means be provided in all ICL operating systems, whereby any facility which may be invoked by a user from a terminal, may also be invoked by an expert system on his behalf, without modification to the software (or hardware) supplying that service.
The development of tailored expert systems needs to be undertaken both because decision support requires such systems to assist in (or constitute) the application of ICL software to the decision making process, and because the knowledge engineering support systems which the customer needs to build his own expert systems cannot be evaluated other than by being practically applied. The development of concrete expert systems therefore proceeds hand in hand with the development of knowledge engineering support tools (which ultimately will in any case themselves be expert system (in expert systems)).
ICL should be supplying its customers with expert systems covering the domains in which ICL is itself expert, i.e. its products. This not only enhances the usability of the systems we market, but is also a potentially invaluable sales productivity aid. If the customer can discover all he needs to know about his existing system and all the other options and upgrades available from ICL, including price quotations and expert sizing, then our products will truly be selling themselves.
This would require a coordinated company wide effort which might be best supplied by IPC. Documentation development procedures could be automated in such a way that online access to documentation becomes a free by-product. This would straightforwardly effect a level of documentation equivalent to widely expanded 'HELP' facilities. Progressive developments to the tools used by IPC in this process would be a natural way to convert by stealth the 'authors' into 'knowledge engineers', and the 'HELP' facilities into expert systems. These sane facilities could also be used internally for PSDs and other documents, and could be offered to customers for use either in systematic documentation or in knowledge engineering. Knowledge engineering is however, by repute, extremely labour intensive and it is therefore important that the tools on which such a system is based be sufficiently flexible to allow whatever degree of sophistication is appropriate on the spectrum between the 'HELP' and the 'expert'.
A broad based advance of this sort, though likely to give a good all round improvement in system usability, would progress too slowly to enable ICL to take a leading position in expert systems. It is essential to compliment it with much rare intensive work in a small number of selected fields. The principle criterion for the selection of these fields should be the value of advances in the proposed fields to our actual or prospective customers. Thus decision support experts assisting in corporate decisions vital to profitability are prime contenders, subject to their being susceptible to solution by these techniques (the qualification is important; notwithstanding undoubted advances, it is still essential to chose the problem domain carefully if good results are to be obtained). If ICL is to suceed in this difficult area then it must take a realistic view of its own capabilities. ICL does not have people with the right skills now, and it is likely that this field will continue to be lead by academics who are disinclined to enter industry. It is important therefore in this as in many other areas, to buy in what we cannot supply ourselves, We would be well alvised to pay for the best advice and to enter into collaborative developments wherever this is possible. The negotiability of suitable collaborations should be a factor in determining which areas to develop first.
An important function of the first expert systems developments will be to identify in what ways the existing infrastructure and superstructure should be modified in order to accomodate more widespread application of Expert Systems.
4.3 Knowledge Engineering Support Systems
For the purpose of explaining the requirements for knowledge engineering support systems, I need first of all to draw certain distinctions which bear directly upon the nat@-ire of knowledge e@ngineering suploort. I-laving made tlriese distinctions I will then proceed to describe the sorts of support required for knowledge engineering.
4.3.1 Expert Systems and knowledge bases
To some extent the techniques used in expert systems are independent of the domain in which they are applied. This independence has lead to and is witnessed by the development of programming languages for use in producing expert systems (PLANNER, PROLOG), and of packages for developing expert systems (SAGE, ICLX). This independence is important to the widespread application of expert systems, but does need to be treated cautiously. In fact, it is characteristic of the work in artifinial intelligence which has lead to impressive expert systerns, that the distinction between the theorem-proving/problem solving logic and the knowledge base on which it operates has became less clear. Earlier work on Artificial Intelligence was largely dominated by resolution based theorem provers which were more domain independent. Experience with these showed that they functioned well only on simple problems, and when applied to more complex problems combinatorial explosion resulted in an unacceptable amount of mill being required to find a solution. The development of expert system has relied upon much greater use of domain dependent knowledge in guiding the search for a proof/solution. Languages for developing expert systems have either totally neglected to make special provision for any disjunction between the inference process and the knowledge base (as in the use of LISP to encode procedurally the domain knowledge) or they have made the logical distinction at the cost of efficiency (e.g. PLANNER, which seems now to be obsolete), or finally they have adopted some compromise, (CONNIVER provides a framework, but requires that the user encodes with his domain dependent information the search strategy required to obtain a solution. PROLOG provides an inference engine built into the language, but relies for efficiency upon the user providing control information to limit the amount of backtracking). In any case such distinction as is made is a purely logical distinction, intended to to permit the 'knowledge engineer' to concentrate upon encoding his knowledge of the domain without at every step needing to understand the processes whereby this knowledge will be applied in problem solving. The final product, the expert system, is a program with both the inference mechanisms and the domain knowledge built into it, and the knowledge base as an independent physical entity does not exist.
Nevertheless the arguments in favour of knowledge bases as distinct physical entities are persuasive. This is a clear aim of the Japanese fifth generation project, in which knowledge bases are to be managed by dedicated knowledge base management processors optimised for the sorts of operations which are found in relational database systems. Whether or not the relational database model is adequate, it is probable that special CAFS-like developments for handling knowledge bases will prove necessary in the long run.
The arguments in favour of independent knowledge bases are particularly pertinent in the application of expert systems to decision support. In this field it is important to aim 'upmarket'. The introduction of expert systems for decision support brings higher management into a much more intitmte relationship with the computer than has hitherto been the case. It will enable the managing director to obtain the information he needs directly from his 'executive workstation' instead of using computer experts as intermediaries. It is this single man within an organisation who will have the largest influence over the purchasing of computing facilities, and, though the computing resource which he himself uses may be a negligible fraction of the total use of his organisation, the ease with which he can obtain the information he needs from the system will be an important factor in influencing spending on the, corporate ccmputer network.
His requirements dictate that his terminal be capable of interpreting requests in natural language (preferably spoken) for information, and should bring to bear upon these requests expert knowledge from any or all of a wide range of problem domains with which the company is concerned, as well as any of the information held in the organisation's distributed datrabase. There is no possibility of the entire knowledge base being compiled into a single expert program, and if it were instead distribute among a number of experts covering subdomains, this would represent too rigid a compartmentalisation to give reasonable performnce in problems which require knowledge more than one of these subdomains. Furthermore, such an organisation would make much more difficult the sort of continuous extension to a corporate expert knowledge base which will inevitably become the rule.
In order to make knowledge bases as independent entities practicable it is important to address the reasons for their not being so at present. These are:
It is therefore desirable that the following are provided for:
4.3.2 Expert systems and traditional program.
Many of the problems to which a computer naive user requires a solution will not in themselves require expert systems techniques for their solution, and even those which do need a genuine expert capability may involve subproblems for which effective procedures are not only known but are already programmed.
In areas where solutions are obtainable by stricty algorithmic metbods, it would be grossly inefficient to solve them by any other means. This applies even in new problem areas peculiar to expert systems where algoritbmic solutions are obtainable.
The areas in which the new techniques are indispensible are those in which a solution is only obtainable by a process of search, which search needs to be guided by domain dependent heuristics if the search time is to be kept within reasonable bounds.
The distinction here drawn is that between the things which are inalienably a part of the expert system and various other functions which are amenable to more traditional methods. The distinction can also be made in respect of the data upon which the systems operate. Certain sorts of information will need to be kept in knowledge bases, but large amounts of regularly structured data such as is found in corporate databases will continue to be best held in traditional databases, so long as this data can be made comprehensible to the expert systems.
In general, where data, subroutines, or utilities, are required by an expert system for the solution of a problem, it is undesirable for these things to be incorporated into a knowledge base if they are readily available elsewhere in the system. In order to eliminate the necessity for this sort of duplicated information, special provision needs to be made to enable an expert system to access and use these sorts of information in the process of its problem solving.
If we suppose, as I have suggested above, that the expert capability is provided under the control of a knowledge base query system, then this 'knowledge base query system needs to be able, on discovering appropriate cues in the knowledge base to do any of the following:
To meet the needs of the computer naive user all of these facilities must be accessible without prior notification by the user, indeed the user should not need to know that this process is taking place at all. The only constraints upon the user's access should be those imposed by security or budgetary considerations, and within these constraints the expert system should be able to invoke without any action of the user whatever system resources are necessary to the solution of the problem which the user has presented. Feedback is desirable to the user on how much of his budget a particular query is consuming or is likely to consume before completion, since this may not be obvious from the problem statement.
4.3.3 The Knowledge Base Management System
The previous two sections have suggested that the knowledge base and its management is of central importance to the support of expert systems, and may have given some clues about my view of the role of the knowledge base manager in expert systems. In this section I hope to expand upon and clarify my views in this area.
The role of the knowleige base mnager is best exolained with the aid of a diagram:
\0/ | user / \ | | __________________ | user | | Interface | | manager | |__________________| | | __________________ | Central | | Intelligence | | Unit | |__________________| | | _______________________________________________ | Knowledge Base Manager | | ______________________________________________| OMF ___________ Data Lib |Knowledge | Base OMF | Base | Data Lib ____________ Base Knowlege Knowledge Base Base The Expert System
In this diagram solid lines between boxes represent data flows, dotted lines represent references (pointers).
4.3.3.1 The User Interface Manager
This part of the system is responsible for translating the users input to the expert system into the internal knowledge representation language, and for constructing optimally user-intelligible output from the internal representations. The user interface manager may itself be domain specific, or it my be a general interfacing package which operates with information from the knowledge base determining the vocabulary and grammer to be used in the dialogue.
The data flow between the User Interface Manager and the knowledge Base Manager represents the following sorts of information.
4.3.3.2 Central Intelligence Unit
This is the principle problem solving unit. It consists wholly of data structures or executable code retrieved from or through the principle or subsidiary knowledge bases. Its nature may dynamically vary during a single session according to the problem domain under consideration. Its main function is theorem-proving/problem solving. From a simplified viewpoint the central intelligence unit takes a problem formulated by the user in interactive dialogue with the User Interface Manager, and applies a heuristic search process to find a solution to that problem from data presented by the user and facts, inference rules and heuristics taken from the knowledge base. The processor time and possibly store space used in this search orocess is likely to be a limiting factor on the capability of the expert system for takling large problem domains, or difficult problems in smaller domains, and it is therefore highly desirable that wherever possible the knowledge base contains explicit solution methods which can be directly applied. These, solution methods may be specified in the knowledge base algoritlnically, and may involve the use of standard library procedures or programs which are brought into the virtual machine as required by the knowledge Base Manager. From the less simplified viewpoint it will in some cases be impossible to disentangle so clearly the user interfacing from the problem solving. In practise it often proves necessary to apply domain knowledge and problem solving capability to resolve amibiguities, either of form or of reference, in the input from the user, and so a dialogue becomes necessary not only between the user interface manager and the user but even in parsing a single sentence, between the User Interface Manaqer and the Central Intelligence Unit.
4.3.3.3 The Knowledge Base Manager
The functions of the Knowledge Base manager are therefore:
When the expert system is invoked this is done by loading the Knowledge Base manager with reference to a specified primary knowledge base. This knowledge base is tailored to the requirements of the user, or more often to a class of users with similar requirements. The primary knowledge base will contain those constituents of expertise which are likely to be most frequently required by the user, and will contain a sufficiency of references to other knowledge bases to enable less frequently used expertise to be retrieved when required. Along with other domain specific information the primary knowledge base contains references to the other system components which need to be set up for query processing. These will include the procedures of the User Interface Manager and as much of the Central Intelligence Unit as is necessary to support the User Interface Manager. These ,could probably be retrieved from OMF libraries. Once the minimal set of components has been loaded Control is passed to the Central Intelligence Unit and thence to the User Interface Manager. Thereafter the actions of the system revolve around requiremnts arising from the user dialogue.
Having passed control to the Central Intelligence Unit the primary function of the Knowledge Base Manager is to provide for the Central Intelligence Unit the right bits of information as rapidly as possible. In order to perform this function the Knowledge Base Manager has responsibility for both primary and secondary store. Using information derived from a continuous dialogue with the Central Intelligence Unit it attempts to ensure that the right parts of the knowledge base are in primary store for solving the problem at hand, Its success in this in cases where the knowledge base cannot be held entirely in primary store will depend upon our ability to satisfactorily structure knowledge bases into relatively independent subdomains. This 'normal function' includes the retrieval of OMF modules such as are likely to be required for problems in the current subdomain and arranging for these to be removed when they are no longer likely to be of use.
Access to secondary Knowledge Bases may be achieved in several different ways, all of which should be sunported by the Knowledge Base Manager. They vary according to whether the access is automatic or explicitly user invoked, according to whether the access is or is not visible to the user, and according to whether the secondary knowledge base is local or remote.
An automatic access occurs when the primary Knowledge Base contains enough knowledge of the relevant domain to be able to identify a problem explicitly stated by the user or a subproblem arising in the solution of a user problem as requiring expertise from a secondary knowledge base. An explicitly user invoked access occurs when, though the primary Knowledge Base may be incapable of identifying a suitable secondary knowledge base, the user is himself able to do so.
In the case of a secondary Knowledge Base being invoked automatically in the solution of a subproblem the access should normally be invisible to the user. In some cases however, where the dialogue with the user has shifted to an alien problem domain, then the invocation of the secondary knowledge base may become visible by the use of different interfacing techniques. This is achieved by action on the part of the Knowledge Base Manager, which on being advised by the Central Intelligence Unit or the User Interface Manager of the change in the domain of the user dialogue will cause the appropriate interface management code from the secondary knowledge base to be loaded and to take over management of the user interface. In this case the primary Knowledge Base has almost fallen into the background but will still need to be accessed since it contains the users local information and it will need to be returned to when dialogue in the alien domain is completed. The user may require to access further secondary knowledge bases located through arbitrary chains of references and in the absence of security or budgetary constraints tnis should be supported.
The context of the discussion so far has been that of local access to a secondary knowledge base, i.e. access to knowledge bases on secondary media directly accessible from the node on which the expert system is runnning. In highly networked systems there will be a requirement also for access to knowledge bases accessible only through the network. There are (at least) two distinct ways of achieving remote Knowledge Base access across a network, each of which has its own advantages.
The first method is to retrieve data from the alien knowledge base and use that data in problem solving processes in the local node in much the same way as it is used when obtained by local secondary Knowledge Base access. The second is to establish a second expert system in the remote node and to have the local expert log into and consult the remote expert in the same way as would a human user connected directly to that remote node. In the first case this requires that the Knowledge Base Manager be capable of retrieving data across a comunications link as well as from local secondary store.
The second option requires that the User Interface Manager be able to manage a dialogue in which the expert system of which it is a part is consulting rather than being consulted. This would be particularly advantageous if the remte expert were running on alien hardware, in which case there might be no lower level of interface understood by both system, It might also result in some cases in considerably less traffic across the communications network than would be occasioned by the first method. The penalty paid for these advantages is the resource used in translating to and from natural language (or whatever is used in dialogue with users) in each node.
If this was implemented in a way which effectively made the expert system indifferent to whether, at the communications protocol level, it was acting as a primary or a secondary, then it would provide a facility enabling the expert system to consult a human expert where it found a problem beyond its capabilities. Such an expert system might then act as a buffer between customers and ICL consultants, effectively filtering out all problems which can be solved without human assistance, and in other cases assisting in the careful formulation of the problem and the collection of all plausibly relevant information before consulting a human expert. Though this might be considered a remote objective, it is actually more important in the short term, because of the severe limitations we are likely to find in the range of problems which we can efficiently solve with fourth generation hardware and current 'state of the art' software tednniques.
It is virtually inconcievable that expert systems can form effective decision support tools without their having good database access facilities. Databases differ frcm Knowledge Bases in the following ways (at least):
In the short to medium term, setting up and updating knowledge bases is likely to be a specialised job, comparable to writing or enhancing programs. In the long term knowledge base update may become a continuous and a partly automatic process. Clearly the knowledge base manager must provide facilities for updating knowledge bases and it would be preferable, but not in the short term essential, if this operation vnre ffore akin to updating a database than to recompilation of a program. Update of the knowledge base is discussed further belcw.
4.3.4 The management of the user interface
A picture of the User Interface Manager has already largely emerged from my description of the Knowledge Base Manager. This is an important part of the system about which I have little to say. A range of different interfacing techniques are available, and in general it would seem best to use the ones appropriate to the problem domain; hence my previous suggestion that the Knowledge Base should contain references to determine the Interface Manager which is to be loaded.
Menu driven or form filling interfaces may be adequate in many domains for the users input to the system. These are relatively unproblematic. In some problem domains however, it is likely that user input of a less rigidly constrained form will be necessary and in these cases natural language input may prove the only solution.
For the display of information to the user a graphics capability is highly desirable, though in the short term at least it will be necessary to provide acceptable output vhthout such a capability.
4.3.5 Maintaining the Knowledge Base
The three prime requirements for kowledge base mantenance are:
Without doubt the most convenient way of maintaining a Knowledge Base would be by interactive use of an Expert System, rather than by using an edit/recompile approach. In the long term complete recompilation of knowledge bases is likely to be too cumbersome an approach, though it may be satisfactory in the short term. Ideally an interactive develooment capability would be provided allowing the Knowledge Engineer to add delete or modify rules at will and then to observe the effects immediately.
Two levels of tracing facility are likely to be required. A basic facility, enabling an expert system, to give an account to a user in full of the reasons for its conclusions, and rare complex diagnostics to assist in debugging knowledge bases. The basic facility is required during normal use of the system. When used in an advisory capacity to human experts, or as a tutor, the expert or student may need to know the reasons behind the diagnosis. If a doctor disagrees with the diagnosis of an expert system, then he will need to examine the reasons for that diagnosis, in order to decide whether the expert system is correct in its conclusions. We cannot afford to risk a patient's health or the possibility of a fault in the knowledge base.
More sophisticated tracing facilities are likely to be necessary for the Knowlege Engineer while developing the system. For example, the effectiveness of domain dependent heuristics cannot be evaluated by examining the conclusions of the expert or the 'reasons' which it gives for them. This is because the heuristic may only effect the speed with which answer is obtained rather than the corectness of the solution once found.
Knowledge bases may be expected to have bugs in them, normally. Human experts are not infallible and nor will be Expert Systems. In the normal course of events an expert system may be expected to be incorrect in a certain proportion of its diagnoses. Even if this proportion is very low by human standards it may still represent too many errors to be handled by manually processed fault reports. It is nevertheless highly desirable that information should be collected on faulty diagnoses, and this should therefore be done by the expert system itself. If a diagnosis is found to be faulty, the expert system should collect from the user all relevant information, so that it may be used to improve (or debug) the Knowledge Base.
This brings out a point of some importance which I have not yet discussed. I have hitherto assumed that all knowledge bases are static. i.e. that they are set up with the domain knowledge in them and then they are only written to in exceptional circumstances, and only on explicit instructions from a Knowledge Engineer. This more or less implies that these expert systems are not capable of learning, The closest they might come is in being able to be taught by a knowledge engineer. Ultimately we may expect expert systems which are capable of learning from their mistakes, and are capable of acquiring knowledge from people who are skilled only in the relevant domain. We do not know how to make systems 'learn' in any but the most simple sense. For some problems a certain amount of optimisation is possible, and learning behaviour has been demonstrated in specially selected narrow domains, but these techniques are unlikely to mature for some time yet. There are many areas which are potential beneficiaries of expert systems with essentially static knowledge bases, and it is these we should concentrate on for the time being.