So far we have talked alot about how we can represent knowledge, but not so much about how we can use it to solve real practical problems. This section will therefore look at how some of the techniques discussed so far are used in expert systems - systems which provide expert quality advice, diagnoses and recommendations given real world problems.
The notes here are an abridged form of those in chapter 8 in the book by Luger and Stubblefield (Artificial Intelligence). However, both Rich &Knight and Bratko have short sections on expert systems which cover much of the material introduced here.
Anyway, expert systems are meant to solve real problems which normally would require a specialised human expert (such as a doctor or a minerologist). Building an expert system therefore first involves extracting the relevant knowledge from the human expert. Such knowledge is often heuristic in nature, based on useful ``rules of thumb'' rather than absolute certainties. Extracting it from the expert in a way that can be used by a computer is generally a difficult task, requiring its own expertise. A knowledge engineer has the job of extracting this knowledge and building the expert system knowledge base.
A first attempt at building an expert system is unlikely to be very successful. This is partly because the expert generally finds it very difficult to express exactly what knowledge and rules they use to solve a problem. Much of it is almost subconscious, or appears so obvious they don't even bother mentioning it. Knowledge acquisition for expert systems is a big area of research, with a wide variety of techniques developed. However, generally it is important to develop an initial prototype based on information extracted by interviewing the expert, then iteratively refine it based on feedback both from the expert and from potential users of the expert system.
In order to do such iterative development from a prototype it is important that the expert system is written in a way that it can easily be inspected and modified. The system should be able to explain its reasoning (to expert, user and knowledge engineer) and answer questions about the solution process. Updating the system shouldn't involve rewriting a whole lot of code - just adding or deleting localised chunks of knowledge.
The most widely used knowledge representation scheme for expert systems is rules (sometimes in combination with frame systems). Typically, the rules won't have certain conclusions - there will just be some degree of certainty that the conclusion will hold if the conditions hold. Statistical techniques are used to determine these certainties. Rule-bsed systems, with or without certainties, are generally easily modifiable and make it easy to provide reasonably helpful traces of the system's reasoning. These traces can be used in providing explanations of what it is doing.
Expert systems have been used to solve a wide range of problems in domains such as medicine, mathematics, engineering, geology, computer science, business, law, defence and education. Within each domain, they have been used to solve problems of different types. Types of problem involve diagnosis (e.g., of a system fault, disease or student error); design (of a computer systems, hotel etc); and interpretation (of, for example, geological data). The appropriate problem solving technique tends to depend more on the problem type than on the domain. Whole books have been written on how to choose your knowledge representation and reasoning methods given characteristics of your problem.