Friday, February 29, 2008

OpenRules Rule Compressor

The people over at OpenRules have developed some very cool technology with their Rule Compressor. Given any decision table the compressor looks for redundant rule combinations and removes them.

If I have two rows in the decision table that look like this:
if age > 50 then decrease price by 10%
if age > 65 then decrease price by 10%

We have redundancy there and it can be combined into a single rule:
if age > 50 then decrease price by 10%

This is obviously a very simple case and the Rule Compressor can do much more complex combinations. I've taken the liberty of taking a screen shot from a section showing an example from their Rule Compressor explanation page:

5 comments:

  1. There's limitation with approaches like that. It only works for very simple rules. Say I change the rule slight to this

    If age > 50 then decrease price by 10%
    If age > 65 then decrease price by 11%

    rule compression isn't going to work so well with this tiny change. Take it another step.

    If 50 > age > 65 then decrease price by 9%
    If age > 65 and retired then decrease price by 15%

    What rule compression doesn't do is teach the business user how to write better rules, or point out inefficiencies in their decision process. A big part of using rule technology is analyzing the business process to improve it. That means taking time to understand the problem and identifying the intent. I've seen this first hand dozens of times. Too many people want to just slap a rule engine in the application without taking time to analyze the business process and improve it.

    the technique described on the rule compression page is old stuff. optimization algorithms and static analysis algorithms have covered this domain in depth since the 80's, so it's nothing new.

    It's definitely beneficial to have a tool like rule compressor to start the analysis, but that should be the first step to producing clean manageable rules. If you ask any of the old rule guys, most have done this dozens of times using custom tools or sql queries.

    my bias 2 bits.

    ReplyDelete
  2. I agree with 'woolfel' (sorry don't know your full name) on numerous points. Writing rules is not always about being most concise and reducing the number of rules. The primary reasons rules have been more acceptable of all AI technologies is the ease of use and natural understanding. What good is a rule based system if the business users cannot easily modify and change the rules....hence I think its more important for rules to capture correct process and knowledge rather than be 'less in number'.

    Having said that....here is thought...lets not throw baby away with the bathwater (yet). Why not use the compressor for runtime generation of rules? I mean...let the rules a user views on BRMS or Excel file, remain the same. But right before rules are deployed, run them through the 'compressor', get a leaner meaner rule base and deploy to the engine.
    This way neither performance is sacrificed nor is usability.

    -V-

    ReplyDelete
  3. Vineet,

    What you describe sounds similar to ILOG's Fastpath algorithm...

    http://www.ilog.com/products/jrules/documentation/jrules66/rsoptimize/rs_opt_algorithms4.html

    Dan

    ReplyDelete
  4. Hi.. I have a doubt in decision tables in xls.. i am using excel and my rules has no format.. in first rule there may be three fields with and conditions and in second another two with different condition.. so i have created rule table for every rule.. is that risk..?
    please let me know..

    ReplyDelete
  5. For a small knockdown finish, there are a couple of good ways to apply the texture, in small areas, without a compressor.
    http://www.dynaselimpex.com/stock/non-ferrous-metal/compressor-sealed-units-scrap.html

    ReplyDelete