Best practices for adopting an “MLOps” mindset
Taking an AI project from ideation to completion is a vicious loop, and there’s only one way to solve it – don’t let the loop begin! This is true because the data deserves expert treatment at all levels. Starting by extracting it from different sources to cleanse, analyze, and populate it, machine learning systems are prone to latencies if the underlying architecture lacks an operational approach to ML – known as by MLOps.
Most AI projects fail to go into production due to a gap that seems very basic but has a huge impact: poor communication between data scientists and the business. This IDC survey emphasizes the importance of ongoing engagements between the two verticals. This has forced organizations to seek out immediately available solutions, and this is where MLOps comes in.
MLOps best practices focus on:
- Provide end-to-end visibility into data mining, modeling, deployment and monitoring for faster processing.
- Faster auditing and replication of production models by storing all associated artifacts such as version data and metadata.
- Effortless recycling of a model depending on the environment and varying requirements
- Faster, safer and more accurate testing of ML systems.
However, the development, implementation or training of ML models has never been the main bottleneck. Building an integrated AI system for continuous operations in the production environment, without any major disconnections, is the real challenge. For example, organizations that need to deploy on-demand ML solutions have no choice but to iteratively rewrite the experimental code. The approach is ambiguous and may or may not end in success.
This is exactly what MLOps is trying to solve.
Simply put, DataOps for ML models is MLOps. It is the process of operationalizing ML models through working with data scientists to achieve speed and robustness. A company called Neuromation has a full service model wrapped around the MLOps strategy. ML Service Provider emphasizes bringing data scientists and engineers together to achieve robust ML lifecycle management.
Along with data scientists, the collaboration includes engineers, cloud architects, and ongoing feedback from all stakeholders. Along the way, he focuses on implementing better ML models in the production environment and creating a data-driven DevOps practice.
What more ? Read along.
Improved automation of the CI / CD pipeline
Continuous Integration (CI) and Continuous Development (CD) automate the creation, testing and deployment of ML pipelines. They deploy a new continuous ML pipeline with newly designed model architecture, features and hyper-parameters. This deployed pipeline is then run on new datasets. When it receives new data, the Continuous Automation pipeline implements a new prediction service. At this point, the output is source code for the new components. These are then pushed to a new source repository on the intended environment.
The new source code triggers the CI / CD pipeline to create the new components, followed by continuous unit testing and integration. Once all the tests are successful, the new pipeline is deployed in the targeted environment. The pipeline is automatically executed in the production environment according to a predefined schedule and training data.
Building lakes for practical data evaluation
ML perfects huge volumes of data. That is why the feasibility of the data is necessary to ensure an appropriate volume and efficiency before considering it for instant forecasting. For example, the QSR (Quick Service Restaurant) system which processes the data of millions of customers should be supported by ML. Here, not only does the data keep growing, it also changes agility. This is also the case with e-commerce landscapes which have many systems linked together, such as last mile delivery, CRM, and internal ERP.
To get started, set up a data lake environment with transparent access to all data sources. Like a centralized warehouse, data lakes should be the epicenter of data assessment. This is the repository for filtering and qualifying data for MLOps processing and further into the data analysis landscape. To ensure that the data has sufficient value to build qualitative analyzes and the necessary business changes, it becomes necessary to adapt to continuous experimentation. You do this by using a scalable computing environment that processes the available datasets in a rapid manner.
At the same time, the lakes deserve an interactive dashboard for advanced visualization. Consider using tools like AWS Quick Sight, Plotly Dash, and Power BI as examples of data visualization dashboards. These dashboards are easily customizable to meet different business needs.
At the end of the data evaluation, all data sets are filtered and structured for future use. This is also the inclusion phase of cataloging. Data catalogs are needed to discover and visualize metadata structures and lineage from source to consumer microservices.
Monitor predictive service and performance
In addition to training, data, and model type, there are other metrics to determine how well the deployed model is performing against business goals. To clock the optimal output of machine learning models, consider the following metrics:
- Latency: Evaluate a transparent UX. Measure latency in milliseconds
- Scalability: The ability to handle service traffic for a particular latency. This is measured in requests per second (RPS).
- Service update: ensure minimum service downtime when updating.
Using the data factory
A data fabric is a framework for collecting data from a multitude of sources and making it operational for analytical staff. MLOps initiatives work closely with data fabrics in a wide variety of cloud and on-premises operational use cases. Because fabrics create a centralized coordination flow, they mitigate risk and reduce the overall costs of big data management. Interestingly, organizations have used the fabric as a base to expand their DataOps initiatives.
K2View, for example, provides a data preparation hub based on its Fabric technology. A data preparation hub captures data from different sources, filters, enriches and hides it according to redefined patterns and rules. Here, a digital entity whose data is stored in an exclusive Micro-DB represents each customer. Such a business entity data pipeline approach ensures integrity, providing uninterrupted access to teams.
Bonus tip: Choosing the right cloud architecture
Your data landscape is likely tied to a cloud application in some way. Given the increasing integration of cloud models in our companies, it is necessary to check the basics: is the cloud platform compliant with MLOps?
While most cloud platforms provide built-in data science capabilities, check if they support resilient, high-performance end-to-end ML pipeline processing (storage, ingestion, modeling, visualization, monitoring, etc. .).
Here, infrastructure as code automates the provisioning of ML environments that are scalable and repeatable. Just like on-premises, cloud platforms depend on CI / CD for accurate training and testing of the ML model. Examples of out-of-the-box cloud environments that support MLOps are AWS SageMaker, Google Cloud AI Pipelines, and Databricks.
Conclusion
This article has reviewed the key metrics to consider for an MLOps strategy. Since automation is a common service, the next challenge for organizations will be to upgrade their âXOpsâ skills. With MLOps, not only will they improve their engagement in the DataOps process, but they will also meet the expectations of the impatient customer.
Copyright © 2021 IDG Communications, Inc.