I. Conflict resolution
If you're silly enough to construct your rule-based system to
be so specific that for every conceivable state of the data
base there is only one rule that applies, you're going to run
into some trouble. First, for big problems, you'll have a
very big rule base, and big rule bases make for slow
programs. Second, this program is not going to be very
adaptable to new situations. And third, it's a good
indication that you're doing it wrong.
For example, a rule in your tic-tac-toe system should most
definitely not be this specific (although if this is what
you have to do to get your Oska program working, so be it):
IF the data base is
[[e,e,e],[e,e,e],[e,e,e]]
THEN change the data base to
[[e,e,e],[e,x,e],[e,e,e]]
So, in more general systems, there are going to be lots of
times when two or more rules apply, but only one can be
executed (at least on a serial computer). That's where
"conflict resolution" comes into play. There are any number
of conflict resolution strategies; here are just a few ways
to select one rule when many rules have had their left-hand-
sides satisfied:
1. Use the first rule whose left-hand-side was satisfied.
Thus, ordering of rules is important. This can get ugly
in big systems with lots of rules, especially as you add,
delete, or change rules (e.g., where does that rule go
now?).
2. Assign priorities to rules, and use the rule with the
highest priority. But then how do you determine the
priorities?
3. Use the most specific rule---the one with the most
details or constraints in the left-hand-side.
4. Use the most recently used (or least recently used)
rule.
5. Use the rule which matches the most recently added piece
of knowledge in the data base.
6. Choose a rule arbitrarily---flip a computational coin.
7. Construct multiple copies of the data base and use all
rules in parallel, with each rule affecting only one copy
of the data base. This could, of course, get ugly over
time.
II. Advantages and disadvantages of rule-based systems
As with anything we've seen in this class so far, there are
advantages and disadvantages to representing procedural
knowledge as rules. Here are some advantages:
1. The knowledge is all represented in the same homogeneous
format, which makes it all easier to understand.
2. The rules are modular or independent; thus, adding or
changing knowledge should be easy to do without goofing
up everything else.
3. If-then rules are an "intuitive" or "natural" way to
represent knowledge; they're easy for us to work with.
However, there are some disadvantages:
1. Rule-based systems are highly inefficient. In order to
use just one rule, the system must examine all the rules.
2. Despite our best intentions, hidden dependencies between
rules may exist. This makes it hard to predict the
effects of adding or deleting a rule.
3. It's hard to see the flow of control in a rule-based
system, so they're difficult to design and difficult
to debug.
III. Expert systems
As the documentary pointed out, in the 1980s some of the AI
folks started extracting narrow, domain-specific knowledge
from human experts and encoding that knowledge as rules in
rule-based systems. These systems performed so well that
they were often called "expert systems". In class we talked
about expert systems, and spent some time going into more
depth about two classic expert systems, MYCIN and DENDRAL.
The accompanying slides should be sufficient to tell you
what you want to know about expert systems.
IV. Logic as a rule-based system
Using logic to prove theorems, which is what CILOG and
Prolog are doing, is another form of a rule-based system in
action. That's really the message of Chapter 6 in your
textbook, which explains how to write a meta-interpreter
for one language (called a metalanguage) on top of the
interpreter for another language (called the base language).
Careful perusal of this chapter should give you some insight
as to how CILOG was implemented on top of Prolog.
Last revised: December 7, 2004