Source: artificial intelligence
An available, competent and cooperative domain expert is a vital element in the success of a project. In addition to possessing the appropriate knowledge, the domain expert should be accepted as a qualified expert, particularly by the intended user. It is helpful, but not necessary, for the domain expert to have the communication skills to explain his or her knowledge to a knowledge engineer who may know little or nothing about the domain initially. Unfortunately, there may be many demands upon the time of the domain expert, thereby making that individual inaccessible to the AI project.
It is likely that even after the system has been fielded, there will be occasional further need for the expert. When an unanticipated condition occurs for which the knowledge base is incomplete, it might be necessary to call upon the expert for advice. The expert may not be familiar with the particular problem, but still be able to effectively reason out a solution.
If the Al project cannot be promised a sufficient allocation of the expert’s time, it will be possible to start the project using a less experienced expert. The top expert can then be called in later to verify the knowledge that has been elicited. Another approach is to use an expert who is in or near retirement. Some of these individuals may be more readily available and even welcome the opportunity to “immortalize” their expertise.
In addition to having access to experts, it is necessary to keep them interested and enthusiastic during the development phase. They must be motivated to contribute even though some of the process appears repetitious or boring. They must be tolerant of the limitations of the system developers and the technology they use. The expert may not have an extensive theoretical background, and therefore suspicious of “schoolbook” or technologic approaches. Such experts must be continuously reassured of the value of their knowledge for the design of the system and the importance of their contribution to the organization.
There are many instances where the best source of detailed knowledge for an AI system is not at the upper levels of the technical or managerial organization chart. It is likely that the most useful knowledge will exist at or near the same level as that of the user. The senior manager may have a view of the overall objectives of the system that is not known at the operating level, but this is where the detailed procedural knowledge is most likely to be found. There may be a real difference in the way a particular job is perceived by senior management and the way that job is actually carried out. The wise knowledge engineer will recognize that more than one view of a task can exist, and in a sense, all views are correct. The real art in system design is to accommodate all views in the design so that the system does not, by its existence, force those involved to resolve their inconsistent approaches before they can accept the use of the system.
Vital and realistic background knowledge may be provided by long-time semiprofessional employees who truly understand the organization’s procedures and its rules (some of which may actually be in conflict with each other). Gaining access to these employees may be complicated not only by the employee’s attitude but also by managerial reluctance to provide such access. Nevertheless, these employees may be in the best position to explain how the job really is accomplished. These experts, as well as the more technically oriented professionals, may make frequent use of inexact knowledge. They will have difficulty in expressing just how they do their job. Their explanations could include such non-quantifiable terms as high and low, good and bad, hard and easy. They may also use conditionals such as, “If the boss really looks angry then I do this other job first.” This is useful information although it may be difficult to represent in a computer system. Techniques such as fuzzy logic, described in a previous series of posts, may be utilized.
Domain experts have reported an interesting result from their participation in the knowledge-elicitation process. Some have said that the elicitation process helped them improve their own understanding. It improved their way of looking at a problem and generating the solution. Some experts have also stated that as a result of participating in the process, they have improved their job performance and their ability to explain the procedures they are using.
Using multiple experts can be helpful in eliciting knowledge or knowledge verification. But they can also introduce problems and complications (Mittal, 19851. Additional domain experts may help to clarify problems, improve the design of the user interface and increase user interest in the system. A second domain expert may be able to fill in gaps in the knowledge base or point out errors of interpretation. Complications can arise when experts do not agree with each other. On occasion, experts with differing opinions may each be right because each uses different approaches to solving a problem. Dealing with such differences poses a sensitive human relations issue for the project leader. As a result, many project leaders have concluded that it is better to attempt to utilize only one expert until the initial prototype has been completed. At this point, a second expert can be called in to verify systems operation and to fill in gaps in the knowledge. Experience shows that a skillful knowledge engineer can benefit from multiple sources of knowledge throughout much of the knowledge-elicitation and system-building process.