Lisp HUG Maillist Archive

KnowledgeWorks: limits on size of rule base?

Greetings. We're building an expert system that is composed in large part of
classification-type "rules". These "rules" (quoted here because the
implementation is in question) are generally simple, and lend themselves to
auto-generation. However, in our production system there will realistically
be hundreds of thousands, if not more than a million, such "rules".

We must choose between two implementations. One approach is to store the
classification "rule" data in hash tables that reside in a saved image;
other rules using this data would employ predicates as part of pattern
matching. The other approach is to auto-generate the classification rules
from our database.

I'm looking for advice. Are there limitations within the KW implementation
that would make the table approach preferable to the rule approach, or
vice-versa? If not, from an engineering perspective is one implementation
preferable?

Thanks very much.

David E. Young
Bloodhound Software, Inc.
http://bloodhoundinc.com

"For wisdom is more precious than rubies,
and nothing you desire can compare with her."
  -- Prov. 8:11

"But all the world understands my language."
  -- Franz Joseph Haydn (1732-1809)


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

Re: KnowledgeWorks: limits on size of rule base?

>>>>> On Wed, 30 Jul 2003 10:21:02 -0400, "Young, David" <dyoung@bloodhoundinc.com> said:

    David> Greetings. We're building an expert system that is composed in large part of
    David> classification-type "rules". These "rules" (quoted here because the
    David> implementation is in question) are generally simple, and lend themselves to
    David> auto-generation. However, in our production system there will realistically
    David> be hundreds of thousands, if not more than a million, such "rules".

    David> We must choose between two implementations. One approach is to store the
    David> classification "rule" data in hash tables that reside in a saved image;
    David> other rules using this data would employ predicates as part of pattern
    David> matching. The other approach is to auto-generate the classification rules
    David> from our database.

    David> I'm looking for advice. Are there limitations within the KW implementation
    David> that would make the table approach preferable to the rule approach, or
    David> vice-versa? If not, from an engineering perspective is one implementation
    David> preferable?

Hi,

I presume that you are talking about forward chaining rules? KW
compiles the left-hand sides of these rules into a network of nodes
(called a RETE network). As each KW object is created or modified it
immediately creates objects that represent partial matches to the
rules. These matches are combined with other matches and flow through
the network. When the inference engine is run the eligible rules are
therefore already known and fire immediately. Each time the right-hand
side of a rule modifies the state another wave of incremental change
propagates through the network and so the eligible rule-set is
efficiently known at each cycle.

So KW goes to some trouble to make matching efficient. However, I
don't really know whether you will find creating rules or testing
properties more efficient. It depends on the complexity of the tests,
the number of objects, the amount of change, etc.

__Jason
Updated at: 2020-12-10 08:59 UTC