I need to program an expert system that, according to a series of complex possibilities, returns a well defined result, together with some kind of diagnostic of what that results means.

What is the general process to define the behavior of an expert system, from the initial assessment of the conditions to the actual code ?

  • What specific problem is the expert system intended to solve? Apr 15 '13 at 15:22

I have no experience of serious expert system development, but I've played with some related algorithms.

Bayes theorem is interesting for when your information contains the wrong probabilities - the probability of x given y when you need the probability of y given x, basically.

ID3 is an easy-to-understand way of deciding which question to ask first, so you can turn a huge table of facts into a decision tree. Strictly, I don't think ID3 can cope with an exclusive-or kind of decision, but it's not that hard to adapt.

Basically, it uses "entropy" calculations - the weighted average of the amount of information you would gain if you received a particular answer, given the probability of that answer (both for the information calculation and the weight). In an either-or choice, a very unlikely answer gives you a lot of information - if you get that answer. Once you weight the answers, the questions that give the most information on average tend to have balanced answer probabilities. One issue is that a question with a lot of (well balanced) answers has more entropy than one with a few possible answers. That actually works well for my multiple dispatch thing, but might mean that a real expert system would tend to ask awkward questions first rather than simple ones.

I use a variation on the theme for a multiple-dispatch handling code generator utility. Yes, it's overkill, but I had that code already written out of interest, so it made sense to use it.

The thing about multiple dispatch functions, though, is that there's only a few "what run-time type is that parameter?" questions to consider. In real life, ID3 is supposed to be a bit slow, so there's loads of alternatives. One classic is I think called CN4.5. I never spent the time to understand it, though.

ID3 and similar decision-tree building algorithms are often called "rule induction" algorithms. I think I first saw ID3 in an ancient issue of PC World, where the example was identifying a coin by its properties (round or polygon, silver or bronze etc).

Of course algorithms and snippets of probability theory, in themselves, don't add up to much. Even if you know the basic algorithms, that seems to be only the first small step to understanding how to apply them. For example, my multiple dispatch thing is very neat - the table of questions (parameters), answers (run-time types) and conclusions (which implementation) is fully defined by the rules of the tool. I don't have to worry about things like asking too many questions, and therefore parroting specific training examples rather than learning principles. And I'm very glad I don't have that subjective issue to worry about.


It's been a long time since I've done any expert system work. The basic process is conceptually straightforward, but the devil as they say is in the details. At that time we used the Java Expert System Shell (JESS). Essentially there are two important facets of expert systems:

  • Facts (the information you are sorting)
  • Rules (how to apply meaning to the facts)

An optional, but useful third concept is:

  • Relationship weights (how strong are two facts related)

Rules can alter facts, and the relationship/weighting between facts. The trick is to come up with a set of rules that make sense, don't contradict one another, and embody the meaning of what the experts believe. That is quite a non-trivial task.

I wish I had the bibliographic information for the reference book we used, but I suspect it might be out of print now. However, for further reading you may want to check out the resources on this page: http://www.aaai.org/AITopics/pmwiki/pmwiki.php/AITopics/ExpertSystemsTechnologyIntroductoryReadings


A google search brings up the following, which seems to contain a nice overview:


Are you planning to write the entire expert-system from scratch, or will you be using a builder tool/library for the work?

  • 2
    from scratch, and I am going crazy already Jan 31 '11 at 13:57
  • Worth finding a library to help you out, no question.
    – glenatron
    Jan 31 '11 at 15:25

The question is fairly general, but here's some suggestions. (Note: Different fields of expertise are suited by different approaches.)

  1. First step is to get an idea of how your knowledge representation is going to work. You're starting from scratch so I'd recommend tackling a small but similar problem and creating code to handle it. (In my experience it's not hard to do that. You can use a variety of languages, what suits you. It doesn't have to be Lisp, F# or Haskell. I've done this using OO languages, Javascript can do a good job...)
  2. I would normally then check out the problem area, work out what we hope to gain, establish a way to measure success, make sure I have enough past data to compare against. (If you don't know where you're going it's very easy to get there!)
  3. I'd look at the available experts, talk to them, figure out the best one to start with, and then work hard to get that best guy. That's typically hard to do, he's in demand. Failing that, well, don't burn your bridges with the other experts, you'll probably need them later if not at the beginning.
  4. Talk to the expert, establish what you're going to implement. There'll often be quite a lot to choose from. Work out the best chunk to tackle first.
  5. Talk through the first goal (/ section) with the expert. He often can't explain it well, he just does it, that's can be a sign of real expertise. This may take a while, be persistent, make notes.
  6. When you have enough down code it up so that it can run with some available UI. Web, desktop program whatever. Fairly quickly discuss it with the expert. Keep the momentum going. Run through it with him. Discuss it as it runs, refine, correct...
  7. Run through 5. and 6 repeatedly. Until you've done enough chunks.
  8. Ideally run it with other experts. That typically goes much quicker, and it improves the work. Seeing an example means you don't need to explain it from basics so much the second time around.
  9. Polish it up, deploy it etc.

Sometimes I see this sort of thing being done without an expert. If that's your case I would try to emulate an expert in some way.

The coding tends to be easy, even where the knowledge representation takes continuous variables (as inputs) and results in conclusions which are more than boolean.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.