concept

ML Platform

The infrastructure that makes machine learning repeatable — data, features, training, deployment, monitoring — where the model is the small part.

ml-platformmlopsfeaturesreproducibilitydrift

Definition

An ML platform provides the shared capability that model development requires: data access, feature computation, experiment tracking, training infrastructure, model registry, deployment, and monitoring.

The model itself is a small fraction of a production system. Everything around it is the platform.

The components that matter most

Feature computation, with training-serving consistency. The single most consequential piece. A feature computed one way in training and differently at serving produces a model that performs well in evaluation and badly in production — and the failure is silent. A feature store, or at minimum shared computation code, exists to prevent this specific class of bug.

Reproducibility. Given a model, you must be able to identify the code, the data, the parameters and the environment that produced it. Without this, a model behaving oddly cannot be investigated, and a regulator's question cannot be answered.

A model registry with versions, lineage, evaluation results and deployment status.

Deployment with the same rigour as any service — canary, rollback, shadow evaluation against the current model.

Monitoring for drift, which is the failure mode specific to ML: input distributions change, the world changes, and the model degrades without erroring. Monitor input distributions, prediction distributions and — where feedback is available — actual outcome quality.

The architectural decisions

Batch, streaming or real-time inference. Batch is far simpler and adequate for many use cases — scoring overnight and serving precomputed results gives sub-millisecond reads with no inference infrastructure. Real-time is required only when the input is not known in advance.

Where feature computation happens. Offline for training, online for serving, and the two must agree.

Latency budget. Model inference within a request path consumes budget that may not exist, which frequently pushes the decision toward precomputation.

Failure scenarios

  • Training-serving skew from divergent feature computation. The most common and most damaging.
  • No reproducibility, so a production model cannot be explained or rebuilt.
  • No drift monitoring, so degradation is discovered through business metrics months later.
  • Real-time inference where batch would have been indistinguishable to users and far cheaper.
  • Every team building its own pipeline, which is the signal to create the platform.

Interview question

"A model performs well in evaluation and poorly in production. What are the likely causes?"