Why Models Behave Differently in Prod

An unwelcome surprise I often see teams encounter is a disparity between a model’s performance post-training and its actual results in production. Besides the immediate effect this can have on your hairstyle (because of the many head-scratching moments!), the unexpected mismatch in performance can lead to an erosion of trust from your end-users. Not sure which one is worse.

The best way to safeguard both your hair and your customers’ trust is to understand the most common root causes of this problem and take steps to minimize the risk of it happening. Let’s explore how to do just that.

Input Data Deviation

A dip in performance most often occurs because a data source was used for training that is different from what the model will actually see in production. A model trained only on sensor data from a controlled environment or lab setting, for instance, will likely not perform as expected when exposed during production to data from sensors in varied real-world environments.

The only foolproof solution in this case is to extract your batch of training data directly from the same raw data stream where the model will later be integrated. If that’s not possible (or if the data stream doesn’t yet exist), you might consider building a system for data collection first. Such a system will need to collect all the same types of data that humans would draw upon as input to make the relevant decisions. Needless to say, make sure to also collect the human decisions (labels) themselves as part of that system. Often, implementing such a system translates to digitizing a traditionally manual and time-intensive process within the company.

Data Cleaning

Another common reason for a post-training/production performance mismatch is that Data Scientists sometimes over-clean their datasets, resulting in a training data distribution that looks different from what the model sees in production. Supplying the model with data that is “too clean” is like asking it to learn from a simplified version of reality and then expecting it to perform the same way once it’s interacting with a much noisier, less complete, or skewed environment.

One way around this problem—at least for classification tasks—is to assign a label called “unclassified” or “mud” to data points you might otherwise filter out. By highlighting the presence of the problem data in this way (instead of “washing” such data out), the model has the chance to learn what it looks like, and you’ll be able to see how much of this “mud” ends up in your business-critical classes as part of your pre-prod model evaluations. An alternative way to address the problem is to apply the same cleaning steps in prod as you did during your local experimentation. However, before taking this route, you’ll want to consider how much this will impact your overall automation rate.

Prod Environment Discrepancies

Unexpected performance at the production stage can often stem from discrepancies between the training and deployment environments. This could be due to differences in Python or package versions, model iterations, order of input features, and configurations. The most reliable solution for these sorts of mismatches are End-to-End (E2E) tests. These tests validate the entire system's workflow, from start to finish, in its real-world environment. They ensure that different components of an application interact seamlessly and produce the expected outputs, helping to identify integration issues and potential bottlenecks.

Monitoring and Alarms

As mentioned before, with any productive system, you should always have detailed logs, monitoring dashboards, and alarms in place to keep track of key metrics, including your model’s confidence level. Having a guarantee that you’ll get notified if something unexpected happens in prod can greatly improve your chances of keeping both your hair and your peace of mind.