MLOps for Vision

MLOps for vision keeps cameras, datasets, and models versioned together, so a model that worked in the lab keeps working on the street.

Ten thousand daily images flow through versioned data and model stores into canary serving with a monitor that fires when accuracy falls to 0.86

Why Does This Exist?

A vision model that scores well on a frozen test set meets a harsher world on release: seasons change lighting, cameras get replaced, new packaging appears on shelves. Accuracy slides silently because nobody labels the live stream. Teams discover the drop from complaints, weeks late.

MLOps for vision closes that loop. Data snapshots, model versions, and serving configs move as one bundle, while monitors watch input and output statistics for drift. Model serving covers the rollout mechanics, edge deployment covers cameras with weak links, and data-centric practice covers fixing the dataset instead of the net.

Think of It Like This

A bus depot with inspection bays

Buses leave the depot on schedule, but every return passes an inspection bay: tires, lights, brakes. A bus that fails goes to the shop, and the depot log ties each repair to a mileage snapshot.

Images are the buses, the model is the route, and the monitor is the bay. Versioned data plus model versions form the log. The analogy stops at automation: buses do not retrain themselves, while a vision pipeline can trigger labeling and training from the inspection result.

How It Actually Works

Three stores move together: a data snapshot with hashes of every image, a model registry entry with weights plus metrics, and a serving config with thresholds and hardware targets. Live traffic first hits a canary on a small share, and monitors compare live input stats plus prediction mix against the training snapshot. A breach pages the team and freezes promotion.

Worked example

A shelf-monitoring model serves $10{,}000$ images a day at $0.92$ accuracy. After a packaging refresh, the monitor sees accuracy on a $500$ -image audit set fall to $0.86$ , a $0.06$ drop, while the share of unknown-SKU predictions triples from $0.04$ to $0.12$ . The rule fires: halt full rollout at $10$ percent canary, label $1{,}000$ fresh images, retrain, and promote only when the audit set clears $0.90$ again. One number plus one mix shift made the call.

Code

The firing rule, checked nightly on the audit sample.

1def needs_retraining(base_acc: float, audit_acc: float, drop_tol: float = 0.03) -> bool:2    """Fire when audit accuracy falls more than tolerance below baseline."""3    return (base_acc - audit_acc) > drop_tol  # absolute drop, not relative4
5
6print(needs_retraining(0.92, 0.86))  # -> True7print(needs_retraining(0.92, 0.905))  # -> False

Watch Out For

Versioning weights without the images

Storing model files while letting the training folder drift means a rollback restores weights nobody can rebuild or audit. The symptom is a retrain that never reproduces the promoted score.

Hash the dataset snapshot into the registry entry. No hash, no promotion.

Monitoring predictions but not inputs

Watching only the label mix misses slow camera decay: predictions look stable while blur grows. Then a lens cleaning flips the mix overnight and the team blames the model.

Track input stats like brightness and sharpness beside outputs. Input drift warns weeks earlier.

The Quick Version

Vision MLOps versions data, model, and serving config as one bundle.
Canary rollouts plus input and output monitors catch drift early.
Worked numbers: $10{,}000$ daily images, $0.92$ to $0.86$ triggers action at $0.06$ drop.
Unknown-SKU share tripling from $0.04$ to $0.12$ confirms the shift.
Hash datasets into the registry and monitor inputs, not just predictions.