A Framework for Model-Based Adaptive Training

Scheduling System - Augmenting the Existing KBS

Several researchers [Anderson et al. 1990, Clancey 1986] have pointed out that the granularity of modelling domain knowledge for the purpose of instruction needs to be smaller than would be necessary in typical expert system applications. A tutoring system needs to be able to:

  1. generate adequate explanations; and
  2. at any point be able to recognise all possible steps that a trainee might produce.

This contrasts with many expert system applications which often provide limited explanations, and for which finding a single next step in problem solving is sufficient. Typical expert systems with rule representations frequently represent compiled expertise in such a way that implicit problem solving methods are embedded in the rules. The existing order scheduling system is no exception. The GUIDON system [Clancey 1986] was designed as a domain-independent system to teach expertise embedded in the EMYCIN expert system. However, Clancey discovered that the existing EMYCIN knowledge base was not suitable for developing intelligent tutors. GUIDON showed that it is necessary to:

  1. split the domain knowledge and tutoring knowledge; and
  2. represent the domain knowledge explicitly for the purpose of using it for instruction and generating adequate explanations.

In MOBAT the training knowledge and subject knowledge is also split into separate modules (i.e., a trainer agent and expert agent). The EMYCIN knowledge base was re-designed for GUIDON’s tutoring system. As presented in this chapter, the existing order scheduling knowledge base is augmented rather than re-designed.

Figure 5-2 shows how the existing scheduling knowledge base is implemented in problem-spaces. Each of the problem spaces has possible problem solving methods (control methods) and associated task structures (i.e., subject specific tasks mapped to generic task primitives). Scheduling knowledge is represented in a total of 206 rules. The existing scheduling rule representation provides an indication of the amount of knowledge each rule contains. The average conditional part of a scheduling rule has 4 elements (the smallest rule has 1 and the largest rule has 12). Each condition element is a pattern that on average has 6 attributes plus values, variables or expressions. The average action part of a rule has 3 elements (the smallest rule has 1 and the largest rule has 8). Each action element on average makes 3 changes to the scheduling working memory (i.e., changes to the problem solving state). The typical rule has a conditional pattern of 24 items (4 elements * 6 attribute-value pairs) and an action pattern of 9 items (3 elements * 3 attribute-value pairs). This rule representation is relatively complex and would be easier to explain in smaller sections.

Figure 5-1 Scheduling-MOBAT Framework Overview

Figure 5-4 Mapping Task Decomposition & Scheduling Knowledge

Refinements for the existing scheduling knowledge base are specified with detailed task decomposition and detailed expertise classification. The MOBAT trainer agent can only provide in-depth training if the model properties it needs are explicitly recognised in the knowledge base. The breakdown of rules into the generic task elements provides the first extension to the existing scheduling knowledge base. Existing rules are broken into smaller ones (which are linked to generic tasks) using an expert system explanation facility. This gives the training system the ability to provide detailed trainee support. The second extension is the selection of generic problem solving methods. For the scheduling rules the existing specific problem solving methods are used. These specific problem solving methods are control structures directing a sequence of scheduling tasks. The specified requirement of a skill-based trainee expertise level suggest the possible use of a propose & apply problem solving method for the generic tasks. Alternative methods are also possible, which can provide further detail in step-by-step problem solving (e.g., propose, reject, evaluate & apply method). The propose step exists in all Scheduling-MOBAT problem solving methods. This provides the training system with the ability to recognise, at any point, all possible steps that might be taken in different problem solving situations. As shown in RIME, by representing reject knowledge separately, possible incorrect decisions and their conditions can be explained. By representing evaluation knowledge explicitly, the system can explain why certain steps are taken in preference of others. For examples of RIME knowledge roles, see Section 2.5.2 Role Limiting Methods.

Figure 5-5 A Scheduling Rule Implementation

Figure 5-5 A Scheduling Rule Implementation

The generic tasks and available expertise will be analysed further with a slightly more complex rule for the task to-validate-date. Figure 5-4 shows the mapping for just one of the twelve rules for the task to-validate-date. A condition element in the scheduling knowledge base is taken as a plausible level to consider for an interpretation task. A more detailed level would be to break up each condition element into its attribute-value pairs; however, this fine granularity could lead to complex software structures. The example rule has 4 scheduling condition elements (C1-C4). Although these conditions can be related by variables, each condition element can be viewed by MOBAT as one interpretation step. A decision needs to be taken if the rule should be considered for execution (D1). There are 12 rules for the task “to-validate-date” which suggests that for this task there are 12 possible decisions to be determined in MOBAT. An action element in a rule is taken as a plausible level to consider for an execution task. The example rule has 4 action elements (A1-A4). Each action element can be examined by MOBAT as separate execution steps.

Figure 5-5 shows the implementation of just one scheduling rule. The existing rules are fairly complex. It is the augmentation to one lower level of detail that provides the means of using the rules for instruction purposes. The expertise is represented both as the existing single rule and into detailed problem solving rules. The task ‘to-validate-date’ in problem space ‘order-scheduling’ is implemented at a lower level of detail in its own problem space. The sub problem space ‘to-validate-date’ is realised with a general propose & apply problem solving method. As in Proto-MOBAT, the expert system defines the possible problem solving method(s) for a task in a training unit slot. The trainer is in control of the overall training process. The trainer selects and controls the expert’s problem solving and can move states from one to another . In the sample implementation rule the control element is called the Goal-Context (GC). The trainer can move the expert from (a) a fixed method, (b) situation dependent methods in a specific problem space and (c) to a sub-problem space for problem solving at a low level of detail using very generic methods.

Figure 5-6 Rule Augmentation

Figure 5-6 Rule Augmentation

To implement the complete sample rule (with C1-C4, D1 and A1-A4) would require a detailed implementation of 18 rules. An example of implementing a single element (C1) is shown in Figure 5-6. There are 12 rules for the task ‘to-validate-date’. To implement all elements in these rules at the lower level of detail, with the propose & apply method, requires fewer detailed rules than the total number of elements in the existing scheduling rules. This is due to duplicate condition and action elements. For example, C2, C4, A1 and A2 are all duplicated in 8 of the 12 rules. These elements only need to be implemented once in the lower level representation. C2 is also re-used in 29 rules for other scheduling tasks. By specifying the training units a trainee is expected to learn with task decomposition and expertise classification methods the need for lower level representation can be kept to a minimum. Augmenting the existing knowledge base is only needed if the specified training units demand it.

So far knowledge representation has been discussed without making a clear distinction between the different levels. In the MOBAT framework, the specification of knowledge at the same, ‘above’ or ‘below’ the level of expected trainee behaviour provides rote, deductive and inductive learning modes. This is based on the surmise that people have these different learning preferences in different situations. The chosen learning mode depends on trainee preferences and training strategy. The actual learning mode at run time is adjusted by:

  1. what has been most effective in past training situations and
  2. the available knowledge representations.

Industrial expertise takes many forms and alternative representations can be used to accomplish a task. In the following sections three distinct levels of knowledge representation are discussed. Section 5.6.1 presents procedural knowledge, Section 5.6.2 presents associative knowledge and Section 5.6.3 presents principled knowledge. Finally, Section 5.6.4 presents the SOAR transfer of learning methods which are used together with the three distinct model types.

Flower Show
© | | Sitemap