Machine learning services can return successful HTTP responses while producing empty, generic, or badly filtered results.
2
A quality metric tied to the service's purpose can detect failures that latency, errors, traffic, and saturation miss.
3
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.
Machine learning can fail while the software looks healthy
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
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
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
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
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
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
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.
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
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.
"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."Lina Weichbrodt07:47
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.
