MLOps — 3 Practices to make AI enterprise-ready

Please note, this article focuses on best practices regarding Machine Learning Operations (MLOps), the set of practices responsible for enabling the scalability of AI/ML solutions. If you wish to learn more about what MLOps is and why it’s critical to a successful and scalable AI strategy, we suggest you read this article first.

Now that you’re all across the what and why of MLOps, let’s set the scene.

You have completed all the hard work pre-processing the data and trained and tested a model which is performing at an acceptable standard. The exciting and challenging R&D phase of the project is ending. Now is time for the model to make an impact and begin creating business value. This requires embracing practices that enable the model lifecycle to be automated.

By nature, a model is not a steady piece of machinery but a continuously changing resource that is constantly adapting, both in response to evolving business objectives and the data your business collects. MLOps is the set of practices that enable AI and machine learning models to adapt and meet evolving business needs. MLOps is not only data science, but marks a shift in objective towards automation of the model training, deployment and retirement lifecycle, as well as integration with an organisations existing tech ecosystem. In short, MLOps is kind of a big deal: it’s responsible for making AI/ML tools work reliably, consistently and in a scalable fashion and operates effectively within your business.

In this article, we will describe 3 best practices that allow an ML model to be utilised effectively in production.

ML Project Lifecycle

The image above represents the ML project lifecycle. What you should immediately notice is that the MLOps journey doesn’t begin with AI, technology or even data.

Rather, the first priority is to clearly define the business objectives, including ideal outcomes, evaluation metrics and latency requirements. These are the guiding criteria and benchmarks for building and evaluating a prototype or ‘proof of concept’ (PoC), which is intended to validate performance against the defined metric(s) and inform decisions as to whether the model is fit-for-purpose and justifies investment in scaling, or whether it must be refined, or to employ a different approach.

This stage forms its own miniature cycle, and its aim is to conduct small scale testing before investing significant time and resources in scaling something that will not create value. For example, a model designed to predict customer churn can be tested against historical data of customers who actually churned to assess whether it is able to produce reliable predictions. If the model is unable to make reliable predictions, the data used to train the model can be adjusted, training parameters tweaked or a new algorithm used. However, should several test scenarios fail to yield satisfactory results, a no-go decision can be made.

Once small-scale testing and validation are completed, the model is connected to a data pipeline that allows it to integrate with the existing data storage and software infrastructure involved in the enterprises’ processes and operations. The criteria and metrics are used to evaluate the impact of the model on the business processes it is intended to augment, and the model is monitored to ensure it satisfies those metrics and performance meets expectations.

This is a key step in validating the business value of an ML project as it allows data science and operations teams to have a quantitative representation of how an ML model is performing relative to metrics, such as cutting costs or boosting productivity. Diminishing model performance relative to these metrics can trigger the modification and retraining (or retiring) of a model to ensure consistent high-quality predictions are generated.

Finally, gathering insights on how the ML solution is impacting the business metrics can be useful to generate ideas and inform a business case for how the technology can be adapted and expanded to increase the scale of its impact and the value created to your business. In other words, the intellectual property (IP) that has been created to address a particular use-case can be adapted to solve a related but different problem in some other business process.

The MLOps lifecycle is an iterative process that runs continuously. Therefore the importance of being able to automate this process to make changes quickly and seamlessly without being reliant on humans is critical to continuously optimizing an ML solution and consistently creating business value.

CI/CD Pipeline Automation

A Continous Integration/Continous Delivery (CI/CD) pipeline is a series of steps that must be performed to deliver a new version of the software. CI/CD pipelines allow for the implementation of new features without compromising core functionality, allowing for the fast yet secure exploration and testing of new ideas.

An automated CI/CD pipeline complements MLOps by enabling the fast and easy deployment of new updates and features to the existing continuous ML Pipeline without compromising current performance effectiveness. The CI/CD pipeline automation enables a data science team to easily experiment with updates, making a model more effective with changes that can create even more business value to an ML project. The risk of not having a CI/CD pipeline consists of slow update times that hinder the ever-changing nature of an ML model, threatening the efficacy and value created by the ML project in the long term. In other words, the lack of a CI/CD pipeline limits agility in terms of being able to quickly test, validate and implement improvements without disrupting the existing process, imposing barriers to a culture of continual experimentation and improvement.

For example, if ML is being used to automate a back-office process and is currently delivering value, an automated CI/CD pipeline allows developers to easily test new model features that automate other processes without the risk of a decrease in accuracy for the tasks it is currently performing. In fact, without a CI/CD pipeline, developers are highly likely to encounter compatibility and update implementation issues which will impede the precision of models currently deployed in use.

The image below depicts the role of a CI/CD pipeline in a machine learning project.

Containerization

Containerisation technology enables software component to be encapsulated into discrete containers and has become a key aspect of MLOps. The original containerisation use case for data science focuses on environment management, a set of practices to create a ‘protected space’ to run experiments without affecting other parts of a system. Setting up software environments is a constant challenge, particularly when working with open-source software which is the domain in which most data scientists work. The reality is software environments are brittle and involve consistent trial and error to update and make changes, which may break dependencies such as those between software packages, or between drivers and applications.

Containers enable different environments to be isolated from each other and allow analysts and developers to experiment and freeze golden-state environments, significantly reducing the risk of making changes as poor performing updates can be quickly reversed, additions can be made far more easily and allowing code to work consistently on different infrastructures.

Whilst managing software environments is the original containerisation use-case, it offers significant benefits in the context of machine learning:

• Remove central IT bottlenecks (e.g., compatibility or missed dependencies) in the MLOps life cycle.
• Ensure better collaboration between engineers when sharing code and research.
• Making it possible for old projects to be instantly reproduced and rerun.
• Reducing the brittleness of software development, encouraging agility and a culture of continuous improvement of an ML project

Given the number of different software architectures present in an enterprise environment, containerization allows for the flexibility that modern organizations need. As containers initially offered flexibility and freedom to enable data scientists to configure environments, they can also provide organizations flexibility and freedom in working across platforms and architectures, representing a keystone in the continuous development and growing success of Artificial Intelligence projects.

Final thoughts

There you have it, the top 3 concepts and best practices that are fundamental to the successful implementation of MLOps into impactful and scalable AI projects. The key takeaway? Building an ML model is a key stage but a small part of integrating machine learning into a successful AI enterprise project.