# Monitoring the Machine Learning Stack

Lina Weichbrodt, DKB | MLOps Meetup | Episode 23 | 55:32
Hosted by Demetrios Brinkmann

Source: https://www.youtube.com/watch?v=Un30yb1WlpU
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/monitoring-the-machine-learning-stack
Published: 2020-07-08
Tags: data-quality, monitoring, recommender-systems

## TL;DR
- Machine learning services can return successful HTTP responses while producing empty, generic, or badly filtered results.
- A quality metric tied to the service's purpose can detect failures that latency, errors, traffic, and saturation miss.
- Monitoring should cover training data, serving behavior, model output, infrastructure, and the data used to measure success.

## Summary
Lina Weichbrodt explains why standard software monitoring misses serious machine learning failures. A request can be fast and error-free while returning empty recommendations, the wrong model, generic top sellers, or results damaged by a client filter. At Zalando, one copy-and-paste error left cross-recommendations 60% empty for five months. Lina's approach was to define a simple quality metric close to the response boundary, such as the share of requests returning at least five articles from the best configured algorithm. The metric runs as an ordinary application counter and feeds existing monitoring and alerting systems. She also compares the metric across old and new stacks during deployments. The talk covers gaps between training, serving, and evaluation data, along with input validation and data drift checks. Lina is honest that alerts need tuning and can require investigation, but she considers the cost acceptable because these failures can persist without visible system errors.

## Key ideas
### Machine learning can fail while the software looks healthy
[03:05](https://www.youtube.com/watch?v=Un30yb1WlpU&t=185s)
Lina says machine learning monitoring has more moving parts because incoming data and the model are part of the product. Unlike a database write, where no exception can provide useful evidence of success, a machine learning response can be valid at the protocol level and still be bad. Latency, HTTP status, and the absence of exceptions do not show whether the result serves its purpose. At Zalando, users received no personalized features after a client changed a case-sensitive identifier to uppercase. Another filter intended for one recommendation box was applied to other boxes, making them much emptier without causing an error.

### Production bugs can damage recommendations for months
[11:47](https://www.youtube.com/watch?v=Un30yb1WlpU&t=707s)
Lina describes a copy-and-paste error that pointed a service at the wrong models. The service continued responding, but recommendations became strange or empty. The bug remained live for five months, and cross-recommendations were 60% empty before a stakeholder noticed. In another case, an integration consistently returned top sellers instead of the intended personalized recommendations. Configuration can also become harmful when business conditions change, such as sales seasons, even if the configuration was initially valid. These examples make the cost of relying on ordinary service health checks concrete.

### The monitored success condition should describe the service's purpose
[14:46](https://www.youtube.com/watch?v=Un30yb1WlpU&t=886s)
Lina proposes extending the usual definition of a successful request. For a personalized recommendation service, a request might need to return at least four or five articles from the personalized algorithm, in addition to being fast and error-free. This metric does not claim to measure the true quality of a recommendation. It is a practical signal that should fall when the service is degraded. The metric can be calculated for each business case in real time and placed alongside the existing service-level objectives. A simple share of non-empty or properly personalized responses can be easier for engineers, data scientists, and product staff to interpret.

### The response boundary gives faster and cleaner detection
[17:15](https://www.youtube.com/watch?v=Un30yb1WlpU&t=1035s)
Lina considered measuring user actions such as clicks, but found those signals noisy and difficult to integrate. A 10% drop at the point where the service returns its response is harder to identify from click-through behavior without running an A/B test for some time. Measuring immediately before the response gives a less fluctuating rate and allows direct comparison with backend deployment data. She still recommends other checks for other parts of the stack. Online response monitoring catches failures introduced by later configuration, filtering, or downstream service calls that model-focused tools may not see.

### Training, serving, and evaluation data can disagree
[24:25](https://www.youtube.com/watch?v=Un30yb1WlpU&t=1465s)
Lina separates the usual offline-to-online gap from a less discussed gap between serving data and evaluation data. At Zalando, training data came from one batch job, inference data from another system, and success measurements from Google Analytics. Tracking problems meant some payment options and Express Checkout events were missing. Around 20% of orders were absent from the tracking data in one example. That could make an otherwise good model look unsuccessful in an A/B test. Lina added monitoring that compared the learning and serving data with the data used to measure outcomes, so structural differences could be found before they distorted conclusions.

### The implementation uses ordinary application metrics
[27:43](https://www.youtube.com/watch?v=Un30yb1WlpU&t=1663s)
Lina's method does not require a machine learning monitoring product. The application evaluates the quality condition on each request and increments counters for good, poor, or clearly bad responses. A monitoring system such as Prometheus can poll those metrics, calculate the quality rate, and trigger alerts. Her example used a threshold based on observed behavior. A quality dashboard showed each business case over time, while deployment monitoring compared the same metric for two stacks. Because the method uses the infrastructure already used for software services, it can fit into an existing monitoring setup.

### Comparing stacks makes deployment failures visible
[28:59](https://www.youtube.com/watch?v=Un30yb1WlpU&t=1739s)
During a deployment, Lina calculated the quality metric for the existing and new stacks and plotted their difference. If both stacks behaved the same, the difference should remain around zero apart from statistical noise. A line that stayed below zero showed that the new stack was worse. This helped identify problems such as a bad model switch or a change to an external metadata service. The comparison provided a basis for rolling back and investigating the change. Lina says the metric can be used for many business cases, with a separate quality KPI where different stacks need different definitions.

### Ownership needs to include product quality
[37:17](https://www.youtube.com/watch?v=Un30yb1WlpU&t=2237s)
Lina worked in a team that owned the stack and its monitoring, including 24/7 responsibility. She argues that splitting monitoring away from the team with domain knowledge makes it harder to understand filters, business rules, and the meaning of a response. She also describes a recurring ownership problem: engineers may avoid data investigation while machine learning researchers may avoid operational tasks. Her view is that a team delivering a machine learning service must take responsibility for whether the response is useful, rather than treating any technically valid response as sufficient.

### Alerts need conservative thresholds and human investigation
[39:54](https://www.youtube.com/watch?v=Un30yb1WlpU&t=2394s)
Lina used one catch-all alert for severe degradation and more finely tuned alerts for individual use cases. She observed normal behavior first, then chose generous thresholds to reduce false positives. Some alerts still required substantial investigation because normal activity, such as a load test by another team, could look like a failure. She considered that acceptable because the alerts did not fire every day or week, while the failures they caught could harm the business for months. Finding the cause could take hours or longer because request metadata was often missing and teams had to investigate upstream changes and data.

## Notable quotes
- Lina Weichbrodt: "Just getting a response is usually not enough to tell you if that was a success." (04:18)
- Lina Weichbrodt: "We had this bug actually live for five months and our cross recommendation was 60% empty and I kid you not, we did not notice that a stakeholder had to call us and ask what happened." (07:47)
- Lina Weichbrodt: "You pick a quality metric that you just put on top of your typical SLO." (16:36)
- Lina Weichbrodt: "The good news is that this plugs right into anything you already have." (33:13)
- Lina Weichbrodt: "We should think of this as really not just replying some response, but replying a useful response." (38:47)

## Tools & references mentioned
- Zalando
- DKB
- Google
- Google Analytics
- Prometheus
- Grafana
- Great Expectations
- TensorFlow Data Validation
- Amazon

## Who should watch
- You operate recommendation, ranking, personalization, fraud, or another machine learning service where a valid response can still be useless.
- Your dashboards show latency and error rates, but you have little visibility into empty, generic, filtered, or degraded model results.
- You are comparing models or stacks in production and need to check that the data used to measure success matches the data being served.

## Editor's note

From the pack [Monitoring and drift](https://mlopstalks.com/packs/monitoring-and-drift):

Gar needs the training-data version that belongs to the deployed model, and Paka describes how missing model records made comparisons hard to trust. ZenML records pipeline steps, inputs, outputs and code versions for each run, giving investigations a record of how a model was produced. Live request capture, outcome joins and alert thresholds still need to be designed for the service being monitored.

Written by the MLOps Talks editors (the ZenML team), not by the speaker.

## Related talks

- [The Not So Talked About Reasons Model Monitoring Fails](https://mlopstalks.com/talks/the-not-so-talked-about-reasons-model-monitoring-fails) (Oren Razon, Superwise, 56:03)
- [ML Observability](https://mlopstalks.com/talks/ml-observability) (Aparna Dhinakaran, Arize AI, 55:04)
- [Model Monitoring in Practice: Top Trends](https://mlopstalks.com/talks/model-monitoring-in-practice-top-trends) (Krishnaram Kenthapadi, Fiddler AI, 51:34)
- [Model Monitoring: The Million Dollar Problem](https://mlopstalks.com/talks/model-monitoring-the-million-dollar-problem) (, 52:55)
- [Engineering MLOps](https://mlopstalks.com/talks/engineering-mlops) (Emmanuel Raj, TietoEvry, 51:55)