CLIPS: A Tool for Building Expert Systems

Why is it inherently better to use a bakeards chaining system under all circumstances?

Caveat first off: it's 7+ years since I looked at this, so take "modern" in that context. I used SWI Prolog specifically [1].

At that point, CLIPS and Prolog occupied similar spaces - but not the same. Prolog is backward chaining. So it's really good at answering questions that can be derived from a base set of facts. For example. Let's say:

There's a road from City A to City B, and a road from City B to City C.

It's then very easy in Prolog to say "there's a route from "Start" to "Finish" if either:

1. there's a road from Start to Finish, or

2. There's a road from Start to City X, and a route from X to Finish.

The beauty of prolog is that you don't need to explicitly code iteration over all the available roads; that's what the backward chaining algorithm does for you.

In arriving at the answer, it'll exhaustively test all permutations. Importantly though, it won't add to the list of facts you started with (unless you specifically tell it to). Once the question is answered, the intermediate results are discarded. In that sense, Prolog - at least in purest form - is somewhat stateless. Assert some facts, then ask questions about inferences that can be drawn from them.

CLIPS is different. It's a forward chaining engine, from a class of related products known as Production Systems. It's designed to be used where new facts are being asserted; when that happens, it figures out the consequences as they ripple through. As new facts are asserted - and their consequences computed - the underlying state evolves. So intermediate results are retained (in fact, that's key to operation).

CLIPS (and Production Systems in general) were used, for example, in medical diagnosis applications. As new symptoms were asserted, the rules rippled through, suggesting the most likely diagnosis.

The key to making this efficient is the forward chaining algorithm, known as Rete [2] (pronounced "Rait").

Again: these are examples, and the reality is likely much more nuanced now. But at least in their purest original form, CLIPS and Prolog are more complementary than overlapping.

[1] http://www.swi-prolog.org/ [2] https://en.wikipedia.org/wiki/Rete_algorithm

EDIT: minor grammar changes + clarified naming in Prolog example.

It looks like they were able to make expert systems useful.

Our work on KnowledgeTool might be equally useful!

After all, it appears that their work was stuck with C, and our work on KnowledgeTool was based on, was a pre-processor to -- sorry to mention this -- PL/I. But, gee, they based on C, so mentioning PL/I should not be so bad!

Our use of KnowledgeTool was to monitor server farms and networks. There in particular we were trying to do problem detection. So, in expert systems,

     When I see A and B and 
     5 or more cases of C 
     without a D, then it 
     looks really bad -- 
     raise an alarm.

And this statement of a symptom, test, for something wrong, was supposed to come from operator experience. So, broadly the idea of KnowledgeTool for that work was not to find better ways to monitor but just to encode what operators had already learned, mostly just from experience.

Hmm .... In such monitoring, we have two ways to be wrong, (1) a false alarm where we say that the system is sick when it is well and (2) a missed detection where we say that a system is well when it is sick.

So, we want the false alarm rate, to be called the probability of Type I error, and the missed detection rate, to be called the probability of Type II error.

Quite broadly there is a trade-off between these two rates: If we accept a higher false alarm rate, then we stand to get a lower missed detection rate.

Not all means of detection are equivalent: Some poor detectors have really high rates for both false alarms and missed detections, and some good detectors have really low rates on both of the errors.

A problem with expert systems was that we had no idea what rates we were getting or if our detectors were poor or good.

Commonly at least in principle we can adjust the rate of false alarms. That is good because (1) a false alarm sends the bridge staff on wild goose chasing and (2) false alarm rate too high is a standard complaint.

Looking at the problem in a little more detail, we easily had wide, deep rapidly flowing oceans of data. So, we could easily have data on 1000 variables with the data for each variable arriving at 100 times a second. So, write some expert system rules? No thanks!

So, I dreamed up a solution, basically, right, as guess from Type I/II, a statistical hypothesis test but one that is both distribution free and multi-dimensional, maybe the first such. False alarm rate can be set in advance of collecting data, and is in a useful sense for each selected false alarm rate has the detection rate the highest possible (for that false alarm rate).

I did this work to improve on expert systems for monitoring. Yes, I published the work, in Information Sciences.

Ah, beating expert systems! What's in the paper is some applied math based on some advanced pure math prerequisites, especially an idea from ergodic theory. What's in the paper really SHOULD be deployed. I suspect that more could be done.

Well, the OP starts with

> Developed at NASA’s Johnson Space Center from 1985 to 1996, the C Language Integrated Production System (CLIPS) is a rule-based programming language useful for creating expert systems and other programs where a heuristic solution is easier to implement and maintain than an algorithmic solution.

Gee, I thought that my "algorithmeic", really original mathematical statistics, was easier than doing as well with heuristics.