In this article we will discuss about:- 1. Meaning of Knowledge Elicitation 2. Techniques for Knowledge Elicitation 3. Tool Support.
Meaning of Knowledge Elicitation:
Assuming, that we have considered our domain of interest carefully and defined the boundaries of the expert system, our first and most crucial stage is knowledge acquisition. Knowledge acquisition is the process of getting information out of the head of the expert or from the chosen source and representing it into the form required by the expert system.
We can, thus identify two phases of this process; knowledge elicitation, where the knowledge is extracted from the expert, and knowledge representation, where the knowledge is put into the expert system.
The knowledge engineer is probably not an expert in the domain of interest. The engineer’s first task is therefore to become familiar with the domain through talking to domain expert and reading relevant background material. Once the engineer has a basic level of understanding of domain he or she can begin knowledge extraction. There are a number of techniques used to facilitate this. It is the job of the knowledge engineer to spot gaps in the knowledge which is being offered and fill them.
ADVERTISEMENTS:
The problem of knowledge extraction is not a trivial one. To help us to understand the magnitude of the problem, think of a subject on which we would consider our solves expert. Imagine having to formalise all this information without error or omission.
Let us think about some behaviour improve in which we are skilled (a good example is driving a car)- can we formalise all the actions and knowledge required to perform the necessary actions? Alternatively, imagine questioning someone on a topic on which we are not expert. How do we know when information is missing? This is where concrete examples can be useful since it is easier to spot a conceptual leap in an explanation of a specific example than it is in more general explanation.
Knowledge required for the development of an expert system can be extracted from experts, books, magazines and journals on the domain. When the knowledge extraction is based on the interviews between the domain expert and the knowledge engineer or between the domain expert and the system itself then knowledge extraction is called Knowledge Elicitation.
Techniques for Knowledge Elicitation:
The interview can capture qualitative information, which is the crux of knowledge elicitation, and therefore provides the key mechanism for acquiring knowledge. There are a number of different types of interview, each of which can be useful for eliciting different types of information.
ADVERTISEMENTS:
We will consider a number of variations on the interview:
1. The unstructured interview;
2. The structured interview;
3. Focused discussion,
ADVERTISEMENTS:
4. Critiquing
5. Role reversal and
6. Think aloud.
1. Unstructured Interview:
ADVERTISEMENTS:
The unstructured interview is open and exploratory; no fixed questions are prepared and the interviewee is allowed to cover topics as he or she deems fit. It can be used to set the scene and gather contextual information at the start of the knowledge elicitation process. Probes, prompts and seed question can be used to encourage the interviewee to provide relevant information.
A probe encourages the expert to provide further information without indication what that information should be. Examples of such questions are “tell me more about that”, “and then?” and “yes?”. Prompts are more directed and can help return the interviewer to a relevant topic which is incomplete. Seed questions are helpful in starting unstructured interview.
A general seed question might be, you went into a book-store and saw a book, immediately you would desire to go through the contents to judge its suitability if it covers the prescribed course on the subject of AI.
2. Structured Interviews:
ADVERTISEMENTS:
In structured interviews a framework for the interview is determined in advance. They can involve the use of check-lists or questionnaires to ensure focus is maintained. Strictly structured interviews allow the elicitor to compare answers between experts whereas less strict, perhaps more accurately termed semi-structured interviews, combine a focus on detail with some freedom to explore areas of Interest.
Appropriate questions can be difficult to devise without some understanding of the domain. Unstructured interviews, are often used initially, followed by structured interviews and more focused techniques.
3. Focused Discussions:
A focused discussion is centered around a particular problem or scenario. This may be a case study, a critical incident or a specific solution. Case analysis considers a case study which might occur in the domain or one which has occurred. The expert explains how it would be or was solved, either verbally or by demonstration. Critical incident analysis is a variant of this which looks at unusual and probably serious incidents, such as error situations.
4. Critiquing:
The expert is asked to comment on someone else’s solution to a problem of design. He is further asked to review the design or problem solution and identify omissions or errors. This can be helpful as a way of cross- referencing the information provided by different experts, and also provides validation checks, since each solution or piece of information is reviewed by another expert.
5. Role Reversal:
Role reversal techniques place the elicitor in the expert’s role and vice versa. There are two main types: teach-back interviews and Twenty Question. In teach-back interview the elicitor teaches’ the expert on a subject.This checks the elicitor’s understanding and allows the expert to amend the knowledge if necessary.
In Twenty Questions, the elicitor chooses a topic from a predetermined set and the expert asks questions about the topic in order to determine which one has been selected. The elicitor can answer yes or no. The questions asked reflect the expert’s knowledge of the topic and therefore provide information about the domain.
6. Think-Aloud:
Think-aloud is used to elicit information about specific tasks. The expert is asked to think aloud while carrying out the task. In this method of interview the knowledge engineer asks the domain expert to think aloud that is whatever steps he is taking he should be speaking loudly. Using eye-movement equipment to track the pattern in which the DE searches for the data. He thus focuses attention at each stage for the problem — solving process and encouraging the K.E. to explicitly ask for each piece of information.
In the post-talk-walk method the DE briefs the K.E. after the task has been completed. Both techniques are better than simple observation, as they provide information on expert strategy as well as behaviour.
The process of interviewing a human expert to elicit knowledge present a number of difficulties regardless of whether the interview is conducted by a human or by computer. Experts are surprisingly inarticulate when it comes to solving the problem.
They do not have access to statistical information. Therefore, there is a great deal of interest in building systems which automatically induce their own rules by looking at sample problems and solutions. With inductive techniques, an expert needs only to provide the conceptual frame work for a problem and a set of useful examples.
Tool Support for Knowledge Elicitation:
After the initial system it built it must be iteratively refined until it approximates expert level performance. The process of extracting knowledge from expert(s) is expensive and time consuming, so it is worthwhile to look for automatic ways of constructing expert knowledge bases. While no totally automatic knowledge acquisition systems yet exist, there are some programs which interact with domain experts to extract knowledge efficiently, more will be under System-Building Aids.
For example, the expert system shell Mac SMART includes an example-based component which allows the domain expert to input information in terms of primary factors, question and advice (instead of rules), and the system generates a knowledge base from these.
This knowledge base can then be validated by the expert. Another system, Tiresias (after the Greek sage), was designed. The expert critiques the performance of the system of a small set of rules and some problems. This focuses the knowledge elicitation process on the specific problems.