Knowledge Base Maintenance and Ripple-Down Rules

Knowledge acquisition for an expert system is often a continuing process because new knowledhe may come to light or some things that used to be true are no longer true. This means that an expert system's rule set must be modified to reflect the new knowledge. A major problem in updating a rule set is to ensure that any modifications leave the rule set consistent. That is, we don't want changes to break already working rules.

Ripple-Down Rules

Ripple-down rules were devised by Paul Compton to make it easier to maintain a knowledge base and keep all the rules consistent. We will use the following formulation of a ripple-down rule: For example: This is interpreted as "if a and b are true then we conclude c unless d is true. In that case we conclude e. Here are the outputs of the RDR under different conditions: Notice that an RDR can always be rewritten as an ordinary if-then-else statement. The rule above would be: We use the exception conditions instead of the normal if-then-else form because this will make it easier for us to update rules.

Building RDR's

Ripple-down rules are built interactively. Initially an RDR consists of a default rule, such as: This simply says that no matter what, the expert system will always draw the conclusion normal.If this were a problem in medical diagnosis, this rule would work most of the time because most people are normal!

Now suppose that a person comes to the doctor with symptoms a and b and the doctor concludes that the patient has disease c. The RDR would conclude that this person is normal. To correct this, we add an exception rule:

This rule now works for this patient since the RDR would conclude that the person is normal except when the symptoms a and b are present.

Now suppose another patient with disease h comes along. He as symptoms f and g. Because there is no rule to cover these conditions, we still get a diagnosis of normal. This is because true is always true, so in the absence of any other rules, normal is the conclusion. How do we fix this? We add a new else part:

This RDR now works for the new patient. Now suppose another patient comes to the doctor. This patient has symptoms a, b and d. The doctor concludes that the patient has disease e, but the RDR concludes c because of a and b. To fix this problem, we add another exception rule: This process is repeated for each case that is seen.

How do we know where to add a new rule? Here is the algorithm:

Using Case Differences to Build Conditions

How do we decide which conditions to add to a new rule? We would like to chose the conditions so that the new rule is as general as possible so that new cases can be diagnosed correctly. The interactive RDR methodology requires an expert to tell the system what conditions to use. However, the expert can get some help from the system.

An RDR system keeps track of which cases caused a rule to be created. Here is rule 2 above, rewritten with the associated cases:

Now let's see what happens when we get case [a, b, d]. Initially it is classified as d, which is incorrect. Now what is the difference between the original case [a, b] and [a, b, d]? The new case has the additional condition d. So if we want to distinguish the two cases, we just look to see if d is present. Thus the new rule is: Suppose that instead of the case [f, g] we had [a, f, g]. The RDR above would still produce the correct diagnosis, but the cases would be a little different. According to this rule, the case [f, g] would be diagnosed as h. Suppose it should be diagnosed as i. What is the difference between the cases? The original case has an additional a. Thus the new rule could be: Thus, we can make a difference list of conditions from the old and new case like this: These differences can then be presented to the expert to select the best ones.

Note: when attributes are numeric, we may have to do something else. For example, if case 1 has age 20 and case 2 has age 40, we might pick the mid point and build a condition age > 30.


RDR Example

Click here to see a full example of buiding an RDR