What type of automation does a data scientist need?
The last thing most data scientists want is a machine that replaces them! The idea that we can build a machine to conduct sophisticated analyses from start to finish has been around for some time now and new attempts surface every few years. The fully automated data scientist is going to be attractive to some organizations with no analytics experience whatsoever but for more sophisticated organizations the promise of such automation is bound to be met with skepticism and worry. Can you imagine visiting a machine learning driven medical service, accepting a diagnosis and prescriptions, and even undergoing surgery with no human oversight involved? Today, even though the pilots say that the airplanes can be 100% computer flown, few of us are ready to take a pilotless airplane ride even though the driverless car appears to be making impressive headway.
In our opinion, automation in predictive analytics is not just a luxury or a future hope. It is an essential component of our everyday modeling practice. The automation we develop for ourselves works its way into every release of our Salford Predictive Modeler. We look at this automation as a way to assist the human data scientist by doing what automation has always done best: relieving the data scientist of tedious repetitive and fairly simple tasks, such as rerunning a cross-validation many times using different random seeds and summarizing the results so that the learning from the experiment is immediately visible to the analyst. Today, some of our automated pipelines do indeed begin from a rather early stage in data exploration and drive all the way through to the delivery of a candidate deployable predictive model encompassing on the order of 15 stages of data processing, remodeling, and automated decision making. We view this as a way to quickly assemble a collection of results that an experienced data scientist can review, critique, modify, and rerun, on the way to arriving at a predictive model (or models) that is vetted by humans and can be trusted.
To a large extent the running of even a single Random Forests model can be viewed as predictive modeling automation. The user has no need to concern themselves with the issues that plague legacy statisticians such as missing values, transformations of predictors, possible interaction effects, outliers in the predictors, or multicollinearity. However, without some human oversight there is going to be genuine risk of what one of my most experienced colleagues refers to as “blunders” that can cause enormous pain if not caught before deployment or before critical decisions are taken. Data science veterans know well of predictive models that went bad due to a mismatch of training data and the data to which the models were to be applied. Just today I discussed this issue with a client confronting such a mismatch; the medical training data was gathered in different regions of the world than the regions in which the model is hoped to be used. We know that even how the data will be collected in different parts of the world will differ, and data errors will not be rare or innocuous. The point of the exercise is to save lives and we cannot accomplish our mission with just routine modeling. In developing an automated system to predict sales of products promoted in a network of large grocery stores we found products that appear to violate the “law of demand” (higher prices cause lower units sold, everything else being equal). Clearly, our system did not recommend increasing the prices during special promotions. If such problems were rare exceptions we could argue that full-on automation of predictive modeling could be largely safe and effective and a few simple rules might help us catch the odd problem cases. In our experience of over more than two decades of predictive modeling, unexpected problems in some part of the process leading from data acquisition to the final deployed model is the rule and not the exception.
By no means am I arguing against a warm embrace of automation in data science and predictive modeling. We have been promoting such automation since we first released a commercial version of the CART decision tree in collaboration with Leo Breiman and his coauthors. (This was before many of today’s data scientists were even born.) We have been building progressively more automation into our SPM product and into the systems we have built for our clients over the years and we will continue to do so. One of our systems retrained itself on new data every six hours, spit out millions of predictions per day, and operated with no downtime for three years before it was retired in favor of more modern technology. The automation we are trying to build is a set of tools that allow data scientists to spend more time thinking about the problems they are trying to solve, to recognize possible problems that can impede their progress or damage the generalization power of their models, and to arrive at the needed results far faster than was ever possible, even a few years ago. However, at least for the present, we see the data scientist as a mandatory participant in the process and our job is to assist them.