Theory and Knowledge

This section looks at the theory behind RBSs generally, instead of focusing on the algorithmic details. The key concept is the underlying knowledge representation. We'll look at how expertise is acquired, and how RBSs fit in with existing representation languages.

This will give us additional understanding beyond the mechanical processing of the system. On one hand, we'll get an idea of the potential of such systems, along with their possible applications, but on the other hand, their problems will also be revealed.

Knowledge Elicitation

Despite being extremely powerful and flexible in theory, RBSs need to be provided with problem-specific expertise. (For instance, the RBS needs rules to be able to avoid obstacles.) The main question is how should this knowledge be acquired? Unfortunately, this is a problem with AI solutions in general, but it is particularly serious with knowledge-based systems. This process is known in lingo as knowledge elicitation (that is, acquisition) to those in the field.

RBSs rely on human-like rules-of-thumb, which makes it slightly easier to convert expert knowledge into production rules. However, this task is surprisingly complex, and has become a problem known as the knowledge acquisition bottleneck. Researchers in the field have attempted to improve this phase by developing tools and methodologies for creating expert systems, but the bottleneck still remains.

The first kind of KBS (pre-1980s) relied on domain experts encoding their knowledge procedurally within the system—as programmers would. Especially obvious in large-scale systems, this development lacked structure, exposing brittleness and many maintenance difficulties. This led to an initiative in 1983 to separate the system from the knowledge by encoding it in a declarative form. This emphasized the distinction between the knowledge and its application (see Figure 11.7). Such systems fall under the category of second-generation expert systems.

Nowadays, it is the job of the knowledge engineer to act as an intermediate between the human experts and the computer system. Such is the complexity of the task that it often requires a dedicated person, assisted by a set of tools. The job of the knowledge engineer can be summarized as follows:

• Read literature about the targeted domain to understand the fundamental concepts and the terminology.

• Schedule interviews with experts in the field to "extract" their knowledge of the problem.

• Summarize the information collected, organize the facts, and enter them into a computer system after an appropriate format has been chosen. Common decisions that have to be made at this stage are discussed in the next few sections.

This combination of expert and knowledge engineer is the most widespread method for providing the system with knowledge, and has proven itself extremely successful in numerous domains. Game AI development can also benefit from this approach.

Further Information There are automated knowledge-discovery techniques that can be used to extract rules from data. In this book, we'll cover two other techniques suitable for learning such rules. One approach is decision tree induction covered in Chapter 26, and the other technique is known as classifier systems, as explained in Chapter 33, "Learning Classifier Systems." In many cases, learning approaches are not as high quality as expert solutions, but they can simplify the development significantly.

Knowledge Representation

Production rules are fundamentally part of a knowledge representation language: RBSs themselves. However, they can be enhanced with other KR formalisms. Because RBSs are defined as a set of "if...then" statements, they are extremely flexible. The formats of both the head and the body can be chosen to match the problem at hand.

Symbols are the most widely used KR paradigm, but they require as many symbols as concepts. The object/attribute/value paradigm can be used to structure the information in a more convenient fashion (for instance, member variables). Frames are useful for describing relationships between objects (for instance, pointers), and semantic networks express higher-level concepts (for instance, inheritance)—reducing the number of rules needed for complex problems. All these KR formalisms are common in everyday object-oriented programming; the difference here is that they need to be made explicit for the RBS to understand them (that is, allowing introspection).

Further Information RBSs can also be extended to deal with uncertainty, using concepts such as confidence or certainty factors. When the facts are associated with a degree of truth, the RBS becomes a fuzzy expert system. The theory and practice behind this technique is discussed extensively in Chapter 30, "Fuzzy Logic."