Recently, I had lunch with a friend who is one of the best and most successful (as a leader and in terms of exits) technical execs you could meet. We were discussing some of our recent professional discussions, and it will not surprise that they have been dominated by artificial intelligence (AI) and machine learning (ML). A theme we've both experienced is an obsession with trying to define the ontology of AI, ML and Deep Learning (DL). Below are just a couple of examples of things we’d heard during recent discussions:
"If I hear a company use AI and ML interchangeably I cross them off the list right away"
"We're only interested in real AI solutions. Not just ML."
We were both perplexed. These kinds of comments come from smart people we respect. Neither of us felt we could draw a clean bright line between ML and AI in a way that everyone would support. More to the point, neither of us could fathom the point of doing so. For one group, ML morphs into AI when unsupervised learning comes into the equation. For another, unsupervised learning is just a subset of ML, which is a subset of AI. This article claims a radical difference between DL and ML. Those three groups can't both be right. And that doesn't matter. The field is advancing so rapidly, both in terms of the richness of the insights it yields and the relative ease with which it can be deployed. We are better to focus on the content of the book rather than the ordering of the table of contents. As Benedict Evans observed in his excellent article here:
[T]he term 'artificial intelligence' [...] tends to end any conversation as soon as it's begun. As soon as we say 'AI', it's as though the black monolith from the beginning of 2001 has appeared, and we all become apes screaming at it and shaking our fists.
Earlier in my career, working on virtual agents and chat bots, similar levels of energy were dashed on the shores of the debate over what really constituted Natural Language Understanding. So long as we were aware of the state of the art addressing the problem, the definitions game made no difference to the quality of our product and never helped someone make a more informed buying decision. But it became an obsession in the industry.
My view is this: if we have a notion that a data set can be best exploited using data-driven techniques, let's use the techniques that best answer our questions, whether simple or complex. If a good answer is yielded by a simple technique, it renders neither the answer, the data, nor the technique any less useful. For example, I recently posted a job advertisement for an Engineering role. One of the platforms I used was ZipRecruiter. During the workflow to set up the job posting, this graphic popped up:
This is an old-fashioned probability distribution. And it is really useful. ZipRecruiter has compensation data over a large population and it's being presented in a clear, simple, and useful way at a helpful time in the user flow. (BTW - if you know good full stack developers, 🤙 call me 🤙)
We shouldn't eschew Good Clean Stats because they're not AI enough. Nor should we - beyond academic endeavor perhaps - spill much more ink on trying to delineate AI, ML and Deep Learning (DL). Firstly, because articles like the one I just linked to address the topic in interesting and useful ways, and secondly because they are being re-written ad infinitum with diminishing returns
Instead, we should focus on the problems we're trying to solve. We're in a privileged position. Tool kits to execute the full spectrum of machine learning - from simple regressions to DNN's - are abstracted to Python (and other popular) libraries, meaning it's never been easier to deploy a broad range of data-driven techniques. But as our technology board advisor shared with me a couple of weeks ago, one problem with this is that some highly skilled developers who have little background in data science and statistics are throwing pretty heavy DL techniques at problems that may not be suitable, with understandably mixed results. Or, maybe the problem is suitable, but the data hasn't been adequately treated and prepared; validation and test sets don't exist; parameters haven't been fully understood.
So my call is to cut to the core of the opportunity. At Plannuh, we're committed to exploiting the full set of data-driven techniques available, and determined to follow where our data and our questions take us. First and foremost, be clear-eyed about your data, the quality and characteristics, and the questions you want to ask of it/answer with it. That insight should drive your technical and algorithmic choices.
When we do that, we achieve our best, most insightful results. On the other hand, if we determine to use convolutional neural nets before we've visualized, understood and prepared our data set, and before we truly understand the questions we're interested in, frustration lies just over the horizon.