As far as predictive modeling is concerned, you can do too much or too little.
Believe it or not, most people try to do too much! Kathleen L. D. Maley, vice president of analytics production with Experian, argues in favor of a modified “the perfect is the enemy of the good” mindset.
She says organizations can realize more value, over a longer period of time, with good-enough models.
“If I develop a B+ model in six months, instead of an A- model in 18 [months], I’m actually going to deliver a whole lot more value for the business with that B+ model iteratively,” she told host Eric Kavanagh, in a recent episode of DM Radio, a weekly radio program devoted to data management.
Maley’s insight was not that organizations should rush models into production. And it wasn’t that organizations shouldn’t focus on engineering highly accurate, reliable and useful predictive models.
Her insight, instead, had to do with when, or how they should focus on engineering better models.
In this respect, Maley argued, an iterative approach to building machine learning (ML) models can pay all kinds of dividends, some of them unexpected. It gives data science or ML engineering teams an upfront win, for one thing. If models are engineered, delivered and maintained as part of an MLOps- or DataOps-type methodology, this becomes a long-term win, too. The team can iteratively enhance them, not only by improving their predictive power, but by enriching the “world” they’re supposed to represent.
To take an iterative approach to model engineering is to make a feature out of a couple of bugs: one, the phenomenon whereby the accuracy of a predictive model declines over time (“model drift); two, the tendency for problems and, especially, edge cases to emerge. Problems such as poor data quality and bias are relatively well known; tools exist for identifying and correcting them during model engineering and testing, prior to pushing models into production. (My colleague Stephen Swoyer does an adequate job describing some of these in a separate article.) But data and ML engineers, QA testers and other experts are also going to miss some problems. Besides, no expert is able to foresee an edge case.
This resistance to foresight is what makes an edge case an edge case!
“But you know, when we start applying these algorithms to real world problems, there’s a whole new set of challenges that have to be addressed [for us] to be able to use them effectively,” she said.
Just because you Ops, doesn’t mean you iterate effectively!
So iterating is good. Got it.
No problem, you say: this is why we have MLOps, DataOps, AIOps and other every other kind of Ops!
The thing is, Maley puts her finger on the pulse of an implicit problem: Each of these practices comprises its own world with its own priorities and responsibilities; how are these practices effectively to collaborate with one another? Share knowledge of their distinct priorities, ground-truth assumptions and so forth? How, if at all, are these practices to influence, act on and change one another?
The danger of having so many specialized practices is that of a new kind of silo-ing: not just of data, but of knowledge, of expertise, that is specific to each practice. How, then, do you avoid ending up with siloed groups, each of which has its own parochial taxonomy of knowledge, priorities, values and so forth? (The term “parochial taxonomy” is Stephen Gould’s. I use it here because I think it le mot juste.)
The ideal would be that each of these practices is able to grow and develop as, so to speak, distinct ecosystems living in, rooted in, the same world. They have the same, shared world as their terra firma.
How do you achieve this? How do you avoid parochial silo-ing among specialized Ops groups?
“Most don’t avoid it and end up with exactly this problem,” says Phil Harvey, an AI solutions architect with a prominent software and services vendor and co-author of the book Data: A Guide to Humans.
“One solution for avoiding it would be interdisciplinary teams of generalists who do many things ‘well enough.’ This [approach] has one catch: no one is allowed to be an expert specialist,” Harvey suggests.
“You are then only allowed communities of [specialized] practice as secondary overlays to encourage ‘good enough practices’ and to avoid the dangers of codifying best practices in ‘simple’ environments.”
Harvey’s point that organizations should promote interdisciplinary collaboration among Ops teams and discourage team members from specialization, in their day-to-day jobs, at least, is worth considering.
He adds that his perspective “comes straight out of Dave Snowden’s Cynefin framework.”
The bias, the damned endemic bias, of human experience
Elsewhere, Experian’s Maley really got cooking on the subject of ML models and bias.
She argued that ML models in and of themselves cannot be biased. They can and do incorporate bias, as well as perpetuate and exacerbate its real-world effects, but this is something quite different.
“Algorithms do not create bias…. They can only do exactly what we tell them. It’s all about how we are putting these things into production, the decisions we’re choosing to make, how we’re using and creating the data that feeds into them, it’s hugely complex,” she said. “[The model] reveals a lot about how we’re developing these things and [it is] magnifying some of these issues that exist elsewhere.”
The challenge is to engineer and use ML (especially ML-powered AI technologies) without perpetuating and compounding the harm of human bias. One way to do this, Maley told Kavanagh, is by bringing ML to bear on ML. “We can use [ML models] to eliminate bias. It’s not easy. It takes real thinking and intelligence and intention. But the algorithms can remove bias as well,” she argued.
This involves “watching it [the model] once it’s in place, monitoring it: what is actually happening? What is it actually doing and adjusting on the fly? I think that’s the other reason why I’m a huge fan of experimentation,” Haley explained, citing a personal example from what she called “the very early days of facial recognition:” a strong bias in the form of correctly recognizing white male facial features – and only white male facial features. “It worked brilliantly, as long as you were a white male, because of course, that was the data that was used to design these algorithms and on which these algorithms were trained,” she said. “Taking that concept a step further, I can actually design my training data sets to address problems that … I already know I’m likely to encounter, and then monitoring what is happening once it’s live for all of those questions I didn’t even think to ask at the beginning.”
AutoML to the Rescue?
On the other hand, Maley told Kavanagh, new types of quasi-automated, self-service or user-assisted ML technologies, such as AutoML, have the potential to exacerbate bias and other endemic problems.
She sees automated ML as a double-edged weapon of sorts: on the one hand, it empirically accelerates ML development and makes it possible for ML engineering teams to radically shrink their development cycles. Also, it has the potential to automate the identification and correction of bias, poor data quality, and other endemic problems. On the other hand, it puts ML technologies (and, in some cases, ML engineering capabilities) at the hands of non-expert users who do not understand them.
“In the old days … I literally could not run optimization problems, because I didn’t have the compute power to run that many different scenarios, right? So, if I wanted to optimize a decision, I maybe could do that once a month, and that is no longer the case. We can process huge amounts of data very, very quickly,” she explained, adding that, for better and worse, “this introduces a new set of challenges: How do I make sure that that is a controlled system? It can no longer be human-dependent, I have to almost have an automated mechanism with control points that allow me to review what is happening.”
This is just to scratch the surface of a fascinating discussion about ML, AI, and analytics. Host Eric Kavanagh was also joined by David Sweenor, senior director of product marketing with Alteryx, and Tim Wyatt, a senior scientist with Lookout, which provides endpoint security software and services.
Tune in to listen to a replay of this DM Radio episode here!
About Vitaly Chernobyl
Vitaly Chernobyl is a technologist with more than 40 years of experience. Born in Moscow in 1969 to Ukrainian academics, Chernobyl solved his first differential equation when he was 7. By the early-1990s, Chernobyl, then 20, along with his oldest brother, Semyon, had settled in New Rochelle, NY. During this period, he authored a series of now-classic Usenet threads that explored the design of Intel’s then-new i860 RISC microprocessor. In addition to dozens of technical papers, he is the co-author, with Pavel Chichikov, of Eleven Ecstatic Discourses: On Programming Intel’s Revolutionary i860.