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.
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.
Figure 11.7. Knowledge elicitation in RBSs. Comparison of procedural and declarative approaches, and the people involved.
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:
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.
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).