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:
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.
There are so many applications areas where the inference rules are already known and need not be guessed from data. In such cases, where the challenge is to automate the existing known rules, I hope that similar formalisms can help us build better and more reliable software.
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.
We're a medical device startup using a KB/RBR system for glucose control, and our greatest feature from a traceability/regulatory perspective is the ability to produce a report for each and every decision made; why we made that decision based on what we know, and how that decision affects the output of the system. This can also be applied retroactively; so all we need to know is the version of the system employed and the sensor inputs given and we can fully replay the decision process.
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.
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:
There are so many applications areas where the inference rules are already known and need not be guessed from data. In such cases, where the challenge is to automate the existing known rules, I hope that similar formalisms can help us build better and more reliable software.