Evaluating Machine Learning Systems in Production

Imagine you have built a recommendation model and it performs well on a test set that you collected before deployment. That result is encouraging, but it answers only part of the question. A model that scores well on past data may still change what real people do once it is placed in front of them. This article looks at the next step in evaluation, the one that happens after offline checks are done, and at one of the most common tools used to carry it out.

Follow one prediction from the moment the model makes it to the moment a real user responds. The path it takes is what separates offline evaluation from online testing, and it is the thread that runs through the rest of this article.

Offline evaluation measures predictions that are fixed in advance. The model is run on a previously collected test set, its outputs are scored, and the scores are the result. Nothing the model shows is seen by a person, so nothing a person does can feed back into the measurement.

In production, the same prediction does not stop at the score. It is shown to a user, the user responds, and that response is recorded as a metric. The diagram below traces this path. The offline branch ends at a fixed score, while the online branch loops through a person and returns real behavior to the team.

Offline evaluation has real advantages. It is cheap to repeat, it does not expose real users to an unfinished system, and it lets you compare candidate models on identical inputs. Those advantages are why it is the necessary starting point. The limitation is that the predictions it measures are fixed in advance, while the behavior of the system in production depends on how people respond to what they are shown.

This matters because changing the recommendations or search results a website shows can drastically change user behavior. A change that looks like a clear improvement on a test set can lead to unexpected consequences once people start reacting to it. For systems that users see directly, online testing is therefore the usual next step after offline evaluation.

A/B testing is the most widely used form of online testing described in this material. Its procedure has three stages. First, users are divided into two groups, and each group receives one algorithm. Second, relevant success metrics are recorded for both groups over a set period of time. Third, the metrics of algorithm A and algorithm B are compared, and a choice between the two approaches is made according to those metrics.

A common arrangement is for algorithm A to be a new model and algorithm B to be the established system that is already running. The new model is tested against the current one on live traffic, so the decision to adopt it rests on how users actually behave rather than on offline scores alone. Follow a single user through the flow below: they enter the system, get assigned to one group, and their data is recorded under that group.

The main benefit of A/B testing is that it lets you evaluate algorithms in the wild. Because users interact with the model in its real setting, the test can surface effects that no offline measurement would have predicted. Most user-facing services rely on this protection: a small portion of traffic absorbs the risk of a surprising change before it reaches everyone.

Once the metrics have been recorded, the comparison can be as simple as computing a rate for each group. The example below is a hypothetical one with invented counts, using a metric that is the fraction of visitors who clicked on a recommended item. Each group has its own count of visitors and clicks, and the click rate for each group is the number of clicks divided by the number of visitors.

The comparison step is where most errors happen. The mistakes below all come from treating a number as more settled than the test allows.

A/B testing is not the only way to run online tests. There are more elaborate mechanisms for online testing that go beyond A/B testing, and bandit algorithms are one example. A/B testing is a well-established starting approach within a larger set of options. You do not need to master bandit algorithms to understand the core idea of live evaluation, but it is useful to know they exist when a simple two-group comparison is not the right fit.

The loop below shows what distinguishes the bandit approach. Each user's response feeds back into the algorithm's next decision, so the traffic it sends to each option can change over successive rounds. In a fixed two-group split, the groups stay the same for the duration of the comparison. In the bandit loop, the allocation of traffic is revised as responses arrive.