What Exactly Is IBM Doing Differently With Machine Learning?
What Exactly Is IBM Doing Differently With Machine Learning?
IBM is one of the biggest platform companies out there for machine learning and artificial intelligence. But how do they do it?
Join the DZone community and get the full member experience.Join For Free
Machine learning itself is not new. The concepts have been around for decades, and many companies have been building ML models and doing predictive analytics for a while. So what exactly is IBM doing in this space?
I would like to say, "IBM takes an enterprise approach to ML," but that sounds too vague. This post details IBM's commitment to machine learning and how our approach goes beyond hype and hand-waving to offer the platforms, tools, and processes our enterprise customers need.
I would like to focus on three things:
- Democratizing machine learning.
- Operationalizing machine learning.
- Hybrid machine learning with fit-for-purpose deployment options.
Let's look at each one.
One aspect of "democratizing" is expanding the access to machine learning with open-source code, open languages, and open frameworks. Languages like Python, Scala, and R; frameworks like Spark and TensorFlow; tools like Apache Zeppelin™, Jupyter, and RStudio. What about organizations that have been using proprietary ML tools? With support for importing PMML, SPSS and other proprietary environments, we can work with existing models — proprietary or open source — in this environment. Providing that diversity is our way of meeting users where they are, with the skills they already have. Machine learning is moving too fast to force teams to burn time ramping up on something unfamiliar.
The second aspect of "democratizing" is lowering the barrier for people who don't have the deep math or statistics background that's been necessary in the past. I want to be careful about this. I don't want to suggest that the tools take away the need to understand what is going on (far from it!), but visual, guided interfaces for building and testing models bring a level of productivity — assuming that you have some fundamental grasp of the principles and domain. An example is the Auto Data Preparation option (see Figure 1), which does a basic level of feature engineering automatically. As another example, the Cognitive Assistance for Data Science (CADS) function selects the ideal algorithm for you based on the data set and class of algorithms you want to analyze.
Figure 1: Auto data preparation for feature engineering
A third aspect of "democratizing" is the ability to collaborate. Data science is a team sport, involving data engineers, data scientists, business analysts, application developers, and other personas in the enterprise. These personas can interact and collaborate, giving your entire team a collaborative workbench to understand data sources, share data exploration in notebooks, data sets, and models — from both visual and programmatic model-building tools — with access control and governance in place.
As the phrase suggests, this is about taking machine learning from the laptops of the data science team and weaving it into the actual operations of the enterprise. How do you implement version control? How can you deploy models quickly? How can application developers invoke models easily? How do you make sure the models stay current as time goes by? Most organizations currently doing ML have faced this challenge. A new model that has just been trained and evaluated performs fantastic on day one; however, the predictions are not that great after a few weeks, and the model has become completely useless in a few months. Data patterns have changed, and the model performance has degraded. How do you alert stakeholders when the model doesn't work that well anymore? How do you manage the task of refreshing models with new training data?
Those are the questions that compelled us to create a framework for managing the full data science lifecycle: ingest, prepare, build, deploy, monitor, and continuously improve. Integration with GitHub and GitHub Enterprise provides the ability to merge and manage code versions. An integrated self-service catalog provides a "shop for data" experience. The ability to deploy models with a few clicks, allowing application developers the ease of consuming with a REST call, etc. are also examples of this lifecycle. Of particular relevance is a feedback loop that ensures the predictive performance of your models stays strong — without the typical time-sink of babysitting them.
Figure 2: Specifying performance metrics for a classification model
More and more, we were seeing data science teams pulled away from their real work of brainstorming, feature engineering, and model design — and instead forced to manage routine tasks that could be automated. So we automated them.
Hybrid ML With Fit-for-Purpose Deployment Options
We realize that for most enterprises the future is multi-cloud. A majority of our customers are now managing data and workloads in multiple environments — on multiple public clouds, behind the firewall in a private cloud, on mainframes, on specialized hardware and appliances, or spanning these. It is important to conform to the principles of data gravity (bring analytics to the data; try to avoid moving data around) and meeting performance or security SLAs that certain platforms provide.
It may make sense to train on one platform and deploy on another. For example, you may need to train and build an ML model on an x86 cluster on-premises using sensitive data, and deploy the trained model to an off-premises cloud. (See Figures 3 and 4.)
Figure 3: Build and train a model on-premises, but publish to cloud
Figure 4: ML model built on trained on-premises becomes available in the cloud
In a similar way, suppose you are working on a complex model for fraud detection. It would make sense to dramatically accelerate training on Power machines leveraging GPUs and the high-speed NVLink connections (see here), but then you might want to deploy the model right into a CICS in-transaction call on the mainframe for sub-millisecond scoring of a credit card transaction. These use cases need maximum interoperability and a unified user experience across diverse environments.
Fit-for-purpose ML is a tall order, but certain core principles apply, including bringing machine learning capabilities native to a variety of platforms and systems. You can deploy your machine learning models where it makes the most sense, whether that's in the public cloud, behind the firewall, in the optimized IBM Integrated Analytics System, or on the mainframe, just to name a few. Further, our Kubernetes based ML environment can be stood up on infrastructure from a variety of popular Cloud vendors, giving you the ability to deploy to IBM and non-IBM cloud environments and enabling a multi-cloud strategy.
This keeps customers from working against data gravity: We let them bring the tools, intelligence, and analytics to the data rather than forcing them to drag data slowly — and insecurely — from place to place.
An Enterprise Platform for ML
We brought all these capabilities together into Data Science Experience (DSX), IBM's enterprise platform for ML.
Perhaps it goes without saying, but the strategies and capabilities described above don't stand alone. Working with IBM means the ability to integrate with the broader IBM portfolio, which ranges from master data management to governance to decision optimization to Watson Explorer to Watson Cognitive APIs to PowerAI and more. Combining these sets of capabilities doesn't just create incidental efficiencies; together they can truly transform your organization. As an example use case, Watson Image Recognition produces a set of features that feed into downstream custom Machine Learning models in DSX that predict building energy efficiency. In a second use case, integration between Decision Optimization with CPLEX and DSX brings advanced store staff scheduling, going beyond linear programming to quadratic functions. In a third use case, Watson Speech-to-Text and advanced NLP capabilities in Watson Explorer (WEX) integrate with DSX to combine unsupervised and supervised techniques for understanding deep intent in customer calls into the call center.
We have integration not just with the IBM portfolio but also with a rich ecosystem of partners like H2O, HortonWorks etc. For example, integration with the HortonWorks Data Platform allows you to leverage native capabilities including browsing for data in the Hadoop cluster and authentication using Apache Knox.
Another strength is a steady stream of innovation coming in from IBM Research, ranging from automatic feature engineering to cognitive databases to distributed deep learning for scaling acceleration and more.
But in the midst of all the features and tools that IBM is providing to drive data science for the enterprise, it can be easy to forget the deeper reason our customers look to IBM in the first place. They look to IBM because they know that our decades of real-world experience across every imaginable industry means we bring an unmatched depth of knowledge about how organizations run and what makes them thrive.
As powerful as machine learning is, it's a myth to think that organizations can throw data into a black box and get back actionable results. Doing feature engineering and building models and infusing them into the applications and processes of a business needs an intimate knowledge of the business and its dynamics — both at the high level of the industry sector and at the low level of transaction flow, regulation, and so on. That's what differentiates IBM. Our industry-leading approach to machine learning is just the latest manifestation of a long tradition of helping customers find the future.
Published at DZone with permission of John Thomas , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.