Please enable JavaScript.
Coggle requires JavaScript to display documents.
Knowledge Acquisition and System Implementation (Knowledge Acquisition…
Knowledge Acquisition and System Implementation
Incremental Development
Employing incremental development is the task of developing and expanding a system and knowledge base.
A key process in the incremental development phase is the acquisition of knowledge.
Knowledge Acquisition
Knowledge Acquisition is composed of:-
a) Knowledge elicitation of the knowledge from the sources. b) Representation of this knowledge within the tool.
Main method for knowledge elicitation is face-toface discussion between the expert who possess the domain knowledge and the knowledge engineer.
These discussion are often done rigorously and is known to be very tedious.
Other techniques include observation of (1) expert at work and (2) intuition.
Knowledge acquisition is presents a significant portion of the development of a knowledge based system
In general the knowledge engineer has a greater stake in the success of the project then the expert.
The burden of success, which requires establishing a good working relationship with the expert, falls largely on the knowledge engineer
Basic Unstructured 1-on-1 Interview
In most knowledge based system, knowledge elicitation is performed one-on-one.
consists of a series of interview sessions, each having slightly different objectives such as
Kickoff Interview
The main objective is to create a good rapport with the expert. The knowledge engineer should attempt to make a good first impression
However extensive familiarization is not required.
A typical agenda for the initial interview consists of:
◦ An introduction and light conversation.
◦ An explanation of what knowledge-based system are their relation to this project.
◦ A discussion of the importance of the project.(if applicable).
◦ A discussion of what reading materials the expert recommends for the knowledge engineer to review to familiarize himself with the domain
◦ A discussion of what is expected of the expert as well as what the expert would expect from the knowledge engineer
◦ The scheduling of the next meeting.
The knowledge engineer should also query the domain expert the documentation that he or she would recommend.
The ground rules for system development should also be discussed in this phase.
A major requirement for building rapport is the early identification of both the expectation of the expert and knowledge engineer
Early identification of expectation must be established early in the process.
The length of the kickoff interview must also be kept short.
Included during the kickoff interview discussion on description of interview process, explanation of incremental development can be included.
Approximately around 1 hour
Knowledge Elicitation Sessions
After a few minutes of introduction in which the knowledge engineer and expert get to know each other the conversation should shift to a discussion of the project.
In this phase the knowledge engineer should explain what a knowledge based system is and how this technology should relate to the expert domain.
Knowledge elicitation session is where we begin the actual knowledge elicitation process.
Knowledge elicitation session can be categorized into two types:-
General knowledge-gathering sessions
Knowledge obtain here is to learn general principle about the domain from the expert
The knowledge gather here will probably not be explicitly coded within the knowledge base
The objective of the knowledge engineer at this point is to :-
1) Understand the problem domain better
2) Understand the expert’s opinions and viewpoints on the domain
3) Continue building rapport with the expert
At this stage the knowledge engineer should have a vocabulary and basic understanding of the domain to converse with the expert.
The task mention above also facilitates the next task in this phase which is the knowledge gathering through an interview consisting of open-ended questions.
Open-ended questions are similar to essay questions on an examination.
Open ended questions require discussions.
Expert generally enjoy an opportunity to share their knowledge. A knowledge engineer can benefit through this by able to see how an expert operates.
This would in turn verify and strengthen her understanding of the domain.
However the exists dangers in general knowledgegathering sessions
The expert may take uncontrolled walks which could result in a waste time which can cause a knowledge engineer to be frustrated
Open ended questions should continue for enough sessions till objectives of obtaining better understanding the problem domain are fulfil and will also serve as a continuous process of building rapport with the domain expert.
During this phase the knowledge engineer also attempts to digest and understand the knowledge presented with the objective of understanding other sub problem appropriate for further examination.
Specific problem-solving knowledge-gathering sessions.
In this phase the knowledge engineer attempts to understand and gather the specific problem-solving knowledge used by the expert.
The knowledge described above will be used to represent the knowledge in the knowledge base.
The process of incremental development can be started by selecting a sub-area that will serve as the first chunk of knowledge to be extracted from the expert and represented within the system.
The objective of these interviews is to explore how the expert solves specific problems. Many of the questions are close-ended questions: answer yes/no or numeric
This sub-area should involve problems:
1) Well understood by the expert
2) Fairly well understood by the knowledge engineer
3) Of sufficient breadth and depth to truly represent the difficulties of problems within this domain
4) Small enough to require only two or three months of development effort without trivializing the scope of this domain’s problems
Care to keep the expert focused on the problem at hand
These interviews are highly directed, emphasizing depth instead of breadth of coverage.
Relate interviews to each other
Summarize and verify the knowledge gained during the previous interview.
Knowledge Organization
A very well known technique for knowledge organization is the
Output-input-middle method:
Identify the answer(s) or solution(s) to the problem being discussed: the system’s outputs.
Identify the sources of information that the expert uses to deduce the solutions: the system’s inputs.
Determine the links between the inputs and the outputs: the middle.
These connections represent the core of the expert’s knowledge. Additionally, intermediate goals or hypotheses may be required to complete the connections
Another technique to consider in structuring an interview is to determine whether there is a standard script that describes the process that the expert typically performs.
If a standard does not exist, it may be useful to create one
Knowledge Documentation
Documentation knowledge is important in the implementation stage, since the knowledge must be presented before it can be implemented.
Documentation also serves as a permanent “paper record” of the knowledge.
Types of knowledge documentation is rule based knowledge diagram, decision trees,semantic nets, relation of frames.
Other Knowledge Elicitation Technique
The unstructured interview is most commonly used.
In some domains significant quantities of expertise are documented in instruction manuals or books.
Some experts cannot verbalize (part of) their expertise Two different methods:
a) Observational
b) Intuitive
Iterative: gathering knowledge - implementing - verifying
Observational Technique
Observational technique means looking over the shoulders of an expert he does his job.
Quiet on-site observation
Some of the characteristic of quiet on-site observation :- 1) No questions by the knowledge engineer 2) Expert thinking aloud 3) This technique should be used only when there is a need to get a feel for the total magnitude of the problem-solving process or to verify a hypothesized approach.
On-site observation with discussion
No gag order on the knowledge engineer thus it permits the knowledge engineer to better probe the process that she observes.
Hopefully, the difference between the real process and this interrupted process is not very significant.
If the observed task is routine for the expert, the expert will be free to give a detailed explanation of his approach and the knowledge engineer can acquire significant knowledge.
If the problem is difficult, then the expert may have difficulty to reach a solution. Symptoms: uneasiness, hesitation, refusing to make a solution. With a cooperative expert such situations can provide a wealth of information.
Once observation is done it is important that a question and answer session is done so that the knowledge engineer can clarify questions on doubts which he has during the exercises
Exercising the expert
In pure observation method the disadvantage is that real problems needs to be used which can be scarce.
Another alternative is to prepare cases of varying difficulties from historical data
These cases are presented to the expert in an “off-line manner” environment to observe the expert’s behaviour.
Experts may already familiar with most of these cases and the expert may have the feeling of being “tested”.
One way to solve this is through applying the Hoffman method that enforces
Limited Information Task:- the expert is not provided certain information that is typically available
Constrained processing tasks:-A routine task is performed, but the expert must execute under some constraint, for example, within a limited amount of time.
These techniques examine the expert’s abilities to provide additional information about his problem solving talents
Problem description and analysis
This category consist of problems best characterized as ones typically discussed and analysed by instructors in a classroom situation
They illustrate important or significant relationships within the domain
Normally, these are selected by the expert, but occasionally they are selected by the knowledge engineer.
Intuitive Technique
Knowledge engineer attempts to become a pseudo-expert and implements his/her pseudo-knowledge regarding the problem domain.
The knowledge engineer has a significant understanding of the problem-solving process and wishes to verify its correctness
Role playing: role reversal, the knowledge engineer acts as the expert and vice versa.
This process can clarify and modify approaches that were thought to be appropriate and can provide significant new problem-solving information not previously uncovered by knowledge engineer.