Problems in production
Five reasons running models is hard, and how MLOps Central Platform responds
Five problems
| # | Problem | Typical symptom | How MLOps Central Platform responds |
|---|---|---|---|
| 1 | Training you cannot reproduce | Nobody knows which settings a past run used, and rerunning the same code gives different results | The training wizard stores the full configuration, and every run's parameters, metrics and artifacts are recorded automatically as MLflow experiments. Resubmit with the same settings reproduces it |
| 2 | Models of unknown origin | Nobody knows what data the production model file was trained on | Every model version is linked to its training run, dataset and metrics. Click a version in the registry to trace its origin |
| 3 | Deployment without review | Whoever likes a model pushes it straight to the field | Stages (Staging → Production) and approval. Promotion to Production always starts as an approval request and takes effect only when an approver approves it. Safety-critical models need two approvals |
| 4 | Scattered field devices | Devices run different model versions, and a dead device is noticed late | Edge Fleet collects heartbeats (the periodic signal a device sends to report that it is running), collected data and inference results, and sends commands, policies and models from the centre. A disconnected device raises an alert |
| 5 | Silent performance decay | Field data shifts and accuracy drops without anyone noticing | Drift monitoring measures how far the input distribution has shifted with the PSI and KS metrics, raises an alert, and the retraining wizard opens from the same screen |