Previous: The Nature of Problem Solving Up: Issues in Knowledge Level Modelling Next: Roles of Knowledge Level Modelling

Next Generation Architectures

Second generation expert systems [34] were developed in the early 80s to overcome a number of problems of the first generation, rule based systems. These problems were, in a nutshell brittleness, poor explanation capabilities and maintainability. The basic idea at that time was to 'deepen' the analysis of the knowledge that these systems embody. This has been interpreted sometimes as deepening of the knowledge, for example by making explicit first principles of a domain. However, second generation expert systems do not necessarily embody deep knowledge in this narrow sense. More generally, the idea is that the knowledge which they embody is analysed and represented up to its constituent role-specific pieces [10][38][16][15]. In retrospect we now view much of the work on second generation expert systems as contributions to a knowledge level theory of specialised intelligence.

Second generation expert systems reflect in their structure the use-specific structure within which specialised knowledge leads to adequate behaviour for a limited number of problem situations.

This structure is what we have called the KL-model. The Generic Task approach was the first to illustrate the idea of linking re-usable models to re-usable pieces of code [7]. Ever since methodological approaches to second generation expert systems almost invariably rely on mapping the structure of a KL-model to the architecture of the application [43][37][24]. This KL-model or parts of it are used to ``stuff in'' the specialized knowledge [27].

It is remarkable that architectures are focused on making control decisions explicit, either in method or in task specific ways. Task specific shells, for example, hard-wire the structure of knowledge and the control of using it, and are therefore limited in scope. Method specific shells are slightly broader since they use a method specific rather than a task specific terminology [22][24]. They therefore require an additional mapping from task to method. In a more sophisticated approach the methods are configured from smaller building blocks [30] or re-usable chunks of models and executables can be put together, inspected and modified at all levels of descriptions [36]. These approaches acknowledge the fact that similar tasks can be solved in different and sometimes highly specific ways but, once instantiated, the task-method-knowledge combination remains fixed.

Architectures like this exhibit a form of brittleness that arises not from a lack of knowledge, but from a lack of flexibility in using the knowledge. They make more explicit what the boundaries of their competence are, they certainly do not account for a graceful degradation of performance. Steps have been taken toward greater flexibility. A first one is to provide for dynamic method selection [31]. Based on problem characteristics, a system will choose the most adequate problem solving method. A complementary approach is to enable preferred problem solving methods by sustained learning of the knowledge that they require [1][40].

But from a fundamental perspective all these are ad hoc solutions. Problem solving methods are still a "what" perspective and thus occupy a strange position at the knowledge level which is concerned with "why". In the problem solving as modelling view, however, the control follows from the need to evolve the case model into a certain state. For example a heuristic classification problem solver will use its knowledge to minimise the size of the differential. Actions will be executed that can lead to new knowledge that enables this minimisation. So, control is genuinely a result of the present state of knowledge about the problem, reflected in the case model [42]. Such architectures have not been extensively explored but they would reflect much more the real nature of problem solving from a knowledge level perspective.

Next generation expert systems support the process of problem solving as modelling by making explicit the case models that they are creating, grounding all interaction in the need to evolve this case model into a state with specified characteristics.

The idea of problem solving as modelling also provides for a powerful framework to model interaction. A knowledge system is useful to the extend that it contributes to the construction of a useful case model, as the result of an interaction between the agents, the systems and the world. Problem solving is realised by a process that involves agents and systems that work toward an understanding of the problem, i.e., the case model. This case model should be the primary vehicle of communication among the different agents. Clancey pointed out that the metaphor of blackboard systems is useful for this: all systems involved in the problem solving process work on and communicate through a common blackboard which at all times reflect the state of understanding of the problem [12]. Again we are far from the view that problem solvers are input-output devices. They are triggers of interaction that leads to the construction of a case model that is acceptable to all the agents involved in the process.

walter@arti