Model Monitoring

Model monitoring is the continuous measurement of a deployed machine learning model's inputs, outputs, performance, and service health, with alerts when any of them moves outside an expected range. Model failures are usually silent: a detector keeps returning boxes with plausible confidence after a camera is moved, a lens gets dirty, or a product is redesigned, and only its accuracy changes. Monitoring compares live behavior with a reference, usually the validation data the model was approved on, so teams learn about data drift and degraded accuracy from dashboards instead of from users. It closes the machine learning operations (MLOps) loop after model deployment and decides when a model needs retraining.

What to Monitor#

Production monitoring usually covers four layers:

• Inference latency and service health: Request rate, error rate, p95 and p99 latency, and GPU memory and utilization, often collected with Prometheus and charted in Grafana.
• Input data: Schema violations, missing values, and shifts in feature or image statistics such as brightness, resolution, or object size.
• Prediction confidence and output mix: The class distribution, detections per image, and confidence scores. A shift here, called prediction drift, is an early warning before labels exist.
• Model performance: Accuracy, precision, recall, or mAP, computed once ground truth arrives. Fraud labels may arrive weeks later as chargebacks, and vision teams label a sample of production images by hand.

Ultralytics Platform builds the prediction layer into its dedicated endpoints: the Monitoring tab charts a deployed YOLO model's confidence distribution, mean confidence over time, top classes, and predictions per image, and recent images can be saved with their predictions to a dataset for review and retraining. The model monitoring and maintenance guide and the Ultralytics Academy lesson Observability and Drift walk through drift checks for YOLO deployments.

Two kinds of change cause most decay. Data drift, also called covariate shift, changes the inputs, as when an inspection camera on a manufacturing line is moved or the lighting changes. Concept drift changes the relationship between inputs and correct answers, as when fraudsters change tactics and once-normal transactions become fraudulent. Input statistics reveal data drift directly, and concept drift appears only in performance metrics once labels arrive. Both are among the most common reasons computer vision models fail in production.

Detecting Drift#

A common drift check compares the distribution of a live statistic with the reference using a two-sample Kolmogorov-Smirnov test, which measures the largest gap between two cumulative distributions. This script applies it to simulated detection confidences: a reference sample from validation, a production week that matches it, and a week shifted lower:

import numpy as np
from scipy.stats import ks_2samp

rng = np.random.default_rng(0)

# Detection confidences logged at validation time form the reference distribution
reference = rng.beta(8, 2, size=2000)

# Two simulated production windows: one like the reference, one shifted lower
windows = {"week 1": rng.beta(8, 2, size=500), "week 2": rng.beta(5, 3, size=500)}

for name, live in windows.items():
    # Two-sample Kolmogorov-Smirnov test: do both samples come from one distribution?
    result = ks_2samp(reference, live)
    drift = result.pvalue < 0.01
    print(f"{name}: mean {live.mean():.2f}, KS {result.statistic:.3f}, p {result.pvalue:.1e}, drift {drift}")

Week 1 passes with a KS statistic of 0.037 and p = 0.64. In week 2, mean confidence falls to 0.63 from week 1's 0.80, and a KS statistic of 0.456 with p = 1.2e-75 flags drift. With many thousands of samples, even harmless shifts become statistically significant, so production checks often alert when the KS statistic or the population stability index (PSI) crosses a fixed threshold. Open-source libraries such as Evidently and NannyML package these tests into drift reports, and NannyML also estimates a classifier's accuracy without labels from its calibrated confidence scores. Amazon SageMaker Model Monitor and Vertex AI Model Monitoring offer the same checks as managed services. An alert then starts an investigation:

Monitoring vs. Observability and Evaluation#

• Observability: The logs, traces, and stored inputs that explain why an alert fired. Monitoring runs predefined checks, and many vendors sell the two together as ML observability.
• Model evaluation: Scores a model on a held-out test set before release. Monitoring repeats that measurement on live traffic for as long as the model serves.
• Experiment tracking: Records training runs during development, before any production data exists.