What is an Expert System?
Artificial Intelligence and Expert Systems
Before I get into the categories of expert systems, let me clear up what they are. First off, expert systems are a category of programs that are artificially intelligent. Of course, nobody can quite agree on exactly what artificial intelligence is, but for our purposes, artificially intelligent programs attempt to emulate or extend certain specific human behaviors. The common types of artificial intelligence that are actively being explored include pattern recognition, voice recognition, machine learning, simulations, diagnostics, and forecasting.
Expert systems narrow this field to models that represent a real-world problem and attempt to provide insight. They can provide a diagnosis, extract crucial information, forecast a trend, or define a course of action in an uncertain environment.
The biggest difference between expert systems and traditional programming (arguably) is that traditional programs are procedural, proceeding step-by-step through a specified sequence, while expert systems are non-sequential, and can take any information in any format at any time and come up with a result. Traditional programs are limited to being able to handle only the specific cases they've been programmed to handle, while expert systems theoretically can handle unknown, previously unanticipated cases.
In practice, however, many expert systems are only extensions of procedural programming, and even the better ones can't come up with information that wasn't programmed into it in the first place.
What types of expert systems are there?
That's a good question. So far, I've encountered the following:
- Bayesian Belief Networks
- State Machines
- Backward- and forward-chaining inference engines
- Case-Based Rules
- Fuzzy Logic algorithms
- Neural Networks
Who uses expert systems?
The list is long and varied. NASA, HP, various power, pulp, oil and manufacturing companies, Lockheed, Price Waterhouse, Bellcore, Boeing, DaimlerChrysler AG, Australian Dept. of Defense, the University of Victoria, Microsoft, OSHA, NOAA, USPS... the list goes on.
What is a knowledge engineer?
A knowledge engineer is someone who works with a "domain" expert to create rules or models for an expert system.
What is your background?
I spent two years as a knowledge engineer modeling, writing, and editing troubleshooters for various Microsoft products. During that time, I learned the ins and outs of working with complex Bayesian belief networks, provided training to new Knowledge Engineers, managed the development of over 90 individual models, and coordinated technical improvements between the expert system shell authoring, production, and runtime components.
I have six years' professional writing experience, writing for consumer magazines, software end users, developers, system administrators, and managers. As a freelancer, I have gained familiarity with state machines in telecommunications management software and a backward-inferencing engine for patient management software.
Currently I'm doing research for a book about expert systems, and offering my knowledge engineering services on a consulting basis.
Expert systems seem to fall into several broad categories. On this page I'll attempt to broadly describe the major categories. I welcome your feedback—if you disagree with my comments, or if I've left something major out, please feel free to let me know.
Expert System Shells
Since expert systems run on computers, and computers are only capable of procedural step-by-step processing, we need some sort of program to run our expert system. These programs are called shells. Expert system shells provide a layer of abstraction between the computer itself and the expert system. I've found about 30 of them on the web, and they range from being programming languages (such as LISP and Prolog) to hybrid environments that mix C++, Java, and COBOL modules with expert system code (such as CLIPS, JESS, Arden, and Flex) to full-fledged GUI authoring environments that let you draw nodes and arcs and specify relationships directly.
The programming languages like LISP and Prolog provide maximum flexibility and form the basis of many of the other shells. The more sophisticated shells provide a framework for modeling your problem, making knowledge engineering a matter of creating your rules, conditions, and outcomes, instead of necessitating programming from scratch.
So now let's discuss the different types of expert systems. Note that some of these are only available in certain shells.
- Tree-based logic
- State machines
- Case-based reasoning
- Bayesian belief networks
- Neural networks
- Fuzzy logic
- Object-oriented design
Okay. So this isn't really an expert system, so much as the easiest way to program and develop a diagnostic system. You don't need any expert system shell to develop a tree-based system—you just create a flowchart with all the necessary branches and start coding. You can easily do it with hyperlinks on a web page.
You start with the symptom of the problem to solve, ask the user questions that narrow down the realm of possible causes, until you reach the question that definitively identifies the actual cause. You build the model from symptom to cause.
So why should you use it? Because, in spite of all the hoopla and excitement surrounding expert systems, just coding a procedural branching diagnostic program is fast, easy, and can be done by anyone familiar with whatever platform you choose. It's easy to update, cheap to implement, and requires no new investments.
So why use anything else? Mainly because you have to do everything by hand. You have to manually update all of the links when your business model changes. If you miss one, you could have a broken link or a broken program. And if your problem gets complex, using a lot of variables that may change at unknown times, or your user chooses a wrong answer (different than you programmed it), or can't skip the question, the model breaks down.
Tree-based logic is chopped down by uncertainty.
Still, you need to have a pretty compelling case to make it worth the extra time and expense to develop anything else.
Another stalwart from traditional programming, state machines have some expert system-like capabilities. They can handle data in different ways at different times. They model existing systems. They execute in a circular, rather than linear fashion.
A state machine is basically an object that can be in a variety of states. How the object behaves (what it inputs and outputs) depend on what state it's currently in. Some inputs may change the object to a new state.
Forward chaining is quite similar to tree-based logic in that you start from the symptoms. Once you identify the symptoms, the expert system calculates forwards to find a result.
The difference is mainly in how you program it. Instead of having to program the flow of the diagnosis, identifying step after step, you simply define a set of rules that could all run in parallel. "If A, then B." "If B, then Z." "If not B, then X." The shell runs all the rules in an unspecified sequence, setting variables as appropriate and finally arriving at a result.
Forward chaining is useful for forecasting trends.
The opposite of forward chaining, obviously, is forward freeing. No? Oh, sorry. Wrong context. Backward freeing?
Backward chaining is the scientific method. First, you state a hypothesis. Then, you compare evidence. If the evidence doesn't match, you have to start over with a new hypothesis. If the evidence matches, you've made the correct hypothesis.
The semantics of creating a backward-chaining expert system can be very similar to the forward-chaining systems. It's the engine that handles the systems differently. Some engines do both forward and backward chaining with the same expert system.
The benefit of a backward-chaining inference engine is that it doesn't have to evaluate all of the evidence to arrive at a conclusion. If your expert system contains a huge number of possible hypothesis, it may perform substantially better using backward chaining, than having to evaluate all of the evidence sequentially, essentially having to process all of the cases.
Case-Based Reasoning (CBR)
Now here we're getting to the part that I always thought defined intelligence: learning from your mistakes.
A CBR system compares the problem with previous cases, and then suggests the most successful course of action. Instead of requiring a thoughtful domain expert and knowledge engineer to determine rules in advance, CBR systems rely on databases of past results to train itself. This is the realm of data mining.
Bayesian Belief Networks
This is probably the most difficult expert system to create, and the least common. But that depends on how accurately you define it. I think... but I'm not sure.
Belief networks are the champions of uncertainty, because they rely on probability rather than definite rules. The expert system doesn't blink if a user can't answer a question—it just goes to the next most likely recommendation without missing a beat.
The knowledge engineers must have a sense for how often given causes occur, and then separately decide how likely they are to know whether or not they occurred.
For a sense of what it takes to design a Bayesian belief network, see the tutorial I wrote for Microsoft elsewhere on this site.
Okay. Now we're getting into cutting-edge stuff here. Neural networks have to do with distributed computing. Instead of having a single processor doing all the work in sequence, you have a bunch of processors doing the work at the same time, and then share the results with the other processors.
Neural networks attempt to mimic the behavior of the brain, processors acting as neurons firing information through synapses.
Most of the work of neural networks is going into pattern recognition, Japanese toy robots, and simulations. Like CBR, neural networks are trained rather than programmed, and potentially will have the most adaptability of any expert system. But like humans and HAL 9000, they can make mistakes...
Fuzzy logic isn't an expert system per se, but rather a meta-meta-meta- set of definitions to define tolerances in manufacturing or pattern recognition. It's more of a component than a system, but it can be integrally related to the other expert systems.
Object Oriented Design
Wait a minute. What's that doing here? Isn't that just the current buzz in programming?
Well, sure it is. But it comes from the same sources as the other expert systems—university research departments.
Most people today acknowledge the wisdom of designing software in terms of objects. An object has a defined input, and a define output. How the object works behind that interface is irrelevant, as long as it does what it's supposed to.
All expert systems are essentially models. Hopefully, they represent real-world systems and problems. Object orientation is a very powerful tool for developing these models, and in many cases, extending them. Most of the expert system shells described above are being expanded to allow for discrete, interdependent objects. Object-oriented design may well prove to be essential to making expert systems effective.