I often come across data science teams that are fascinated by deep learning, compressive classification, and self-driving cars, and that are eager to employ the algorithm du jour. For instance, I was recently working with a large financial institution on increasing its cybersecurity and, before we even got started with basic monitoring, a data scientist on my team was talking about k-means clustering and neural networks.
We must always remember to understand the problem and opportunity first, and then apply the right system or algorithm. Sometimes self-learning neural networks may be the best alternative; however, sometimes you’ll have to go with a classic: the expert system.
An expert system is a rule-based engine based on the collective wisdom of experts. It’s one of the oldest innovations in artificial intelligence (AI), with its practical use dating back to the 1970s.
Expert systems are often joked about in data science circles as obsolete dinosaurs that are interesting but impractical for modern-day use. I strongly disagree—there’s nothing in the advancements of AI that fully replace the functionality and utility of expert systems. Furthermore, since expert systems have been around for quite some time, there’s a lot of history that you can leverage for best practices. Here are six of my best practices for using expert systems to get you started.
1: Gather requirements
One of the hardest parts about building an expert system is getting time with the actual experts. It’s difficult enough to get time with any end users, but the experts you’ll need for your project are very special end users that everybody wants to talk to. Before collecting requirements, engage management to confirm your time with the experts.
For instance, when I was working with a global transaction processing company, there were only a half-dozen or so people in the entire company that knew the guts of the transaction network. If you didn’t get management to commit the experts’ time, you aren’t going to be talking to them for more than 15 minutes.
2: Perform analysis
Spend very little time on analysis. Resist the urge to perform qualitative analysis on expert interviews—it’s not necessary.
An expert system is designed to perform its own analysis. The hard work isn’t so much in the analysis, but rather the setup and fine-tuning of your framework. In that respect, it’s similar to a neural network. Your job is to tell the system how to think, and then let the system do the thinking for itself.
3: Design the framework
Design verbosity into your expert system framework. An expert system is comprised of two basic components: a knowledge base and an inference engine. The knowledge base stores facts about your domain under design, and the inference engine applies the AI equivalent of inductive (forward chaining) and deductive (backward chaining) reasoning to the facts in the knowledge base.
Both systems must be instrumented very well, allowing you to understand what the expert system is thinking. You need a very detailed view into what your expert system knows and how it’s drawing its conclusions. Advanced systems employ more of a natural language interface—a best practice I support.
4: Develop the system
Development should be fast. Like analysis, if you’re spending a lot of time here, you’re doing something wrong. The only thing you should be developing is a framework (knowledge base and inference engine). Stay away from writing procedural code for now.
However, think ahead. Build interfaces where procedural code could take the place of framework inference. Although supplanting procedural code for framework-based inference is contrary to popular wisdom, it’s a practical extension of your expert system once its rules have been thoroughly vetted. Procedural code affords you the opportunity of much faster execution, which is more practical for many applications (e.g., embedded systems).
SEE: Quick glossary: Business intelligence and analytics (Tech Pro Research)
5: Train the system
Don’t underestimate the time, effort, and expert involvement required to properly train an expert system. I use the term train loosely—an expert system is not technically a learning system. But, what makes or breaks an expert system is its domain knowledge and how it makes inferences. Experts must be part of this process because they’ll need to fine-tune the engine once it’s seeded with the information collected during the requirements phase.
Here’s where things get interesting. It’s hard enough to get one expert to explain their process, let alone a group of experts to agree on the right process. It’s worth it in the end, but diligence and patience will serve you well during this phase.
6: Improve the system
Retain your expert council for future reviews. Once your expert system has been deployed, it will be difficult to hold onto your experts for very long; they would need to periodically review real-world conclusions to ensure your system is still upholding its responsibilities as an expert. Get this commitment from them upfront. Use management like you did in the requirements phase—it’s safe to say you’ll need their eyeballs about once per quarter for at least a year while the expert system stabilizes. Make sure everyone’s on board with this idea before you get started.
Even with all the newfangled systems and algorithms that are flooding the data science world, there’s nothing wrong with using a tried-and-true solution that’s been around for decades: the expert system. Don’t let the simplicity of design fool you into thinking it’s outmoded or ineffective, as the contrary is true.
As long as you secure the right experts, you can stand up an expert system in no time; meanwhile, other data scientists are still trying to wrap their brains around compressive classification. With the tips I’ve given you here and your own lessons learned, you’ll be an expert systems pro before you know it.