Rule-Based Expert Systems (1984)
people.dbmi.columbia.edu
people.dbmi.columbia.edu
The approach had various problems at the time:
* what to do with a chain of reasoning if a previously asserted fact was retracted (i.e. when being questioned by the system, you realise that a previous answer was wrong)
* very brittle knowledge that doesn't transfer well outside a specific domain (the 'joke' example was a medical expert system that would diagnose rust-patches on a car as measles)
* The problem that as rule sets grew in size, domain knowledge needed to be supplemented by software engineering skills
We found it telling that none of the contributing companies continued to use the rule-based approach for very long when the EU funding dried up, and that none of them successfully commercialised it for a third party company. However, as an experienced programmer rather than an AI researcher, in at least one case, I found that the rule-based approach was a good way of getting domain experts to articulate the heuristics they used, and then embed these in a conventional application. The GUI we developed for the frame-based component was also repurposed for a very successful in-house modelling too, so the codebase wasn't a complete loss.
Mixing up the concepts of "forgetting" (a monotonic operation that maintains a systems consistency at the cost of completeness), and "retraction"/"deleting" (a non-monotonic operation that requires truth maintenance and chooses completeness potentially at the cost of corectness (of the whole system)), is the billion dollar NULL mistake of the knowledge representation and database world.
Retraction is largely solved. Rules engines such as Drools and Clara use the RETE algorithm, hashtable/b-tree indexes, can match against millions of rules. These work particularly well for "complex event processing" where you could could gather up events (say from a rocket starting up or a financial trade) into compound events you code against.
People who use this kind of tool
would say their tools are much better and that the "logic" of production rules is a pale shadow of what SAT solvers, theorem provers, etc. can do.
For ordinary "Business Rules", production rules engines compete against implementing the rules in ordinary code.
http://inform7.com/book/WI_1_1.html
is a toolkit for writing text adventure games in what looks like English. Just blasting through rules in order it uses defaults as a primary mechanism of control.
Production Rules and logic compete with databases in the sense that a more expressive system won't scale as well (you want to fit in the L3 cache if not the RAM) RDFS and OWL implement limited-but-useful subsets that scale better than others.
I've used production rules in data transformation one record at a time, they work well for this, but today I implement the same organizational principles in a set of Python functions that act on dicts. The production rules do
https://en.wikipedia.org/wiki/Transitive_closure
idiomatically but in the limited cases where you need that you can look it up in an algorithm book.
Production rules also are great for highly interactive systems.
I have used production rules in the control plane for a distributed data processing system where the system compiled a description of a job into a set of rules.
They are great for "internet-of-things" both because "IF-THIS-THEN-THAT" feels natural and the compound event capability.
It seems that they'd even be an answer to the asynchronous communication problem in Javascript.
Interesting how it's almost opposite of what the field is now.
That's exactly what makes this stuff interesting. People sometime seem to be struck by something you might call "path dependence blindness" where they see the path taken as the only path that might have been taken, and assume that anything which is off that precise path is useless. However, it it sometimes useful to look back and ponder those forks in the path which were not chosen, or which were abandoned (perhaps prematurely).
Can you take an old idea from something like MYCIN and apply it in a new way, combined with other, newer ideas? Or maybe find something that was a good idea in principle, but was "ahead of its time" in regards to computing power or some other constraint? Maybe, maybe not. But it's exploring those kinds of things that always leads me back to stuff like this.
Especially in sectors that are heavily regulated, such as medicine, legal professions, and also the public sector, automated rule-based reasoning can be very useful and helpful.
It is particularly interesting that the system can produce explanations for why something was done or recommended. For example, chapter 19 discusses explanations for dosage selection:
https://people.dbmi.columbia.edu/~ehs7001/Buchanan-Shortliff...
It is also interesting that the same inference mechanism can be applied also in different contexts. Quoting from page 296:
"The flexibility needed by MYCIN to extend or modify its knowledgebase was exploited in EMYCIN. Neither the syntax of rules nor the basic ideas underlying the context tree and inference mechanism were changed."
Sample interaction, using custom rules for reasoning in business-related contexts, shown on page 300:
20-Oct-79 14:16:48
-------- COMPANY-1 --------
1) What company is having a problem?
** IBM
2) Is the problem with payroll or inventory?
** PAYROLL
3) What is the number of employees of ibm?
** 10000000
Conclusions: the tools to use in solving the problem are as follows: a large computer.
That is the killer edge that rule-based systems can offer. You can question them about how they reached their conclusions; armed with the response, you can evaluate their reasoning and critique their conclusions.
Explanations aren't beyond the reach of ML systems in principle, AFAIAA, but I've yet to hear of any proposal about how one might construct a self-explaining ML system.
[Edit] I guess not being able to explain your reasoning might be considered an advantage, in some circumstances; if you can't show that a certain system is using defective reasoning (because it won't show you its reasoning), you can't show the system is defective, so it becomes harder to sue the manufacturer or relying party.
This is something that, as you state, you simply cannot do with a deep learning approach. Regulators don't love black boxes, especially when it comes to human lives.
Is it highly specific and non-transferable? Yes. Did it take a decade of work to refine? Yes. But does it get the best results, even better than classical MPC/PID approaches? So far, yes. In medicine, it's results that matter, not reusability of the tech employed. Human trials are just around the corner, and we can find out with certainty if our approach gives the results we think it will.
Research conducted at the Stanford Medical School found MYCIN received an acceptability rating of 65% on treatment plan from a panel of eight independent specialists, which was comparable to the 42.5% to 62.5% rating of five faculty members.[5]
Maybe an evaluation of first line treatments for hypertension and diabetes would have been better.
de Dombal, E T., Leaper, D. J., Horrocks, J. C., Staniland, J. R., and McCann, A. E 1974. Human and computer aided diagnosis of abdominal pain: Further report with emphasis on the performance of clinicians. British Medical Journal 1: 376-380.
I'll read the paper and revise my knowledge- thanks again!