Conflict resolution strategy: What's the difference between size ordering/ data ordering/ least recently used rule?

Question

What's the difference between size ordering/ data ordering/ least recently used rule?

I did lots of researches already, and most of the books say:

Data ordering: Arrange all possible assertions in one long prioritized list. Use the triggered rule that has condition pattern that matches the highest priority assertion in the list.

Size Ordering: Use the triggered rule with the toughest requirements, where the toughest means the longest list of conditions.

Least recently used rule(Recency Ordering): Use the least recently used rule.

However, all of these explanations are too abstract for me, and I can't understand them well.

Can someone help me using the following cases to explain these three strategies? (Feel free to use own case)

1. A system to handle complaints quickly. This involves a library of generic excuses whenever a real answer is unavailable.
2. A system to detect current and prospective clients and forward their calls to appropriate managers.
3. A sympathizing system to handle complaints. The goal of this system is to have an automated voice have a conversation with the caller and appear knowledgeable and concerned about the complaint. The system wants the caller to end the conversation feeling satisfied that the complaint has been heard and that the company is acting appropriately on it. The system will have a varying amount of information depending on what the caller is willing to say to a machine. The system uses specific rules for when it gathers a lot of information and general rules when it does not.

Answer 1

To understand what conflicts resolution strategy is, let's simulate a condition in which we have a conflict between two rules. I will cover the first and second provided example and for the rules I will use the CLIPS language.

The first rule, answers to complaints with a quick response. It's ideal if we don't have any further information on how to handle the complaint.

The second rule activates if the customer which is complaining is assigned to a manager and forwards the complaint to the manager.

(defrule generic-excuse
  ; Provide a generic excuse to complaining customers
  ?complaint <- (complaint (customer ?customer))
  =>
  (respond-to-customer ?customer "We are sorry for the inconvenience.")
  (retract ?complaint))

(defrule forward-complaint-to-manager
  ; Forward a complaint to the assigned manager
  ?complaint <- (complaint (customer ?customer))
  ?manager <- (manager (assigned-customers $?customers))  ; managers have a list of assigned customers
  (test (member$ ?customer ?customers))                   ; test if the customer among the ones assigned to the manager
  =>
  (forward-to-manager ?manager ?complaint)
  (retract ?complaint))

These two rules seems to conveniently cover both cases. Both the rules remove (retract) the complaint from the engine's working memory once they fire as the complaint itself gets managed.

Nevertheless, they are conflicting with each other in case they both have all conditions met for firing. Ideally, if there's a manager assigned to a given customer the complain should be forwarded to him/her. Yet in this case the first rule might take over and the customer will receive a generic apology instead of being re-directed to a manager.

Usually, rule developers control the execution order of the rules via a salience mechanism. If rules appear to have the same salience, the conflict resolution takes over and decide in which order the rules will fire.

The first resolution strategy you mention (data ordering) suggests the prioritization will be made based on the order the facts are asserted in.

The second strategy (size ordering) in CLIPS is referred as complexity strategy. It prioritizes rules with more constraints. In the above example, this is the correct strategy to adopt as the manager rule is more specific and hence more complex. If you structure your rule base so that more specific rules should fire over generic ones than this is your strategy of choice.

Third strategy is pretty easy to understand. The rules which fired the least recently will be prioritized first.

To conclude, rule conflicts are extremely common in expert systems. Resolution strategies influence the way your rule base will grow and how its maintenance cost will increase. It is quite important to choose wisely at the beginning of your design as changing it later on might bring lots of unpleasant refactoring.

You can see a full copy of the example program in the following gist.