A model that works on the test set and a model that works in service are two different objects, and the difference is not accuracy. The classification error measured on a validation set describes how the model behaves on data collected in the past; the production system receives data from now, produced by a process that changes while the model stays fixed. Everything that separates the two regimes — serialisation, scoring latency, monitoring, retraining, traceability of decisions — is engineering and process work that shows up on no ROC curve.

Context

In recent years, building a model has become something anyone can do. scikit-learn, described by Pedregosa et al. in the paper that appeared in JMLR, puts supervised and unsupervised estimators behind a single fit/predict interface, on top of NumPy and SciPy, under a BSD licence. Apache Mahout brings clustering, classification and collaborative filtering to Hadoop, in batch MapReduce. Vowpal Wabbit, born at Yahoo! Research, trains online linear models on streams that do not fit in memory. The barrier to training has dropped; the barrier to operating has not.

Many organisations now have a trained model — inside an R session, a Python script, a Mahout job — and no defined path to move it into the system that makes the decisions. The model lives in the notebook of whoever wrote it. The problem is not rebuilding it a second time: it is turning it into a component someone answers for.

From notebook to service

The first obstacle is trivial and expensive: the model has to be serialised and reloaded elsewhere. In Python this usually means pickle, which saves the state of the estimator object. It works as long as the versions of scikit-learn, NumPy and the interpreter in production match those used for training; a pickle produced with one version and deserialised with another can break silently, returning an object that predicts without raising an error. The library version thus becomes part of the model’s definition, not an environment detail.

The language-independent alternative has existed for a while: PMML (Predictive Model Markup Language), the XML standard from the Data Mining Group, at version 4.0 since 2009. A decision tree or a regression model exported to PMML can be loaded into a scoring engine written in a different language from the one used for training. PMML covers a subset of the most common models, not all of them, and the fidelity of the export depends on the implementation; it remains the only way to decouple the model format from the runtime of whoever trained it.

The second obstacle is the difference between batch and online scoring. A model that recomputes recommendations once a day on Hadoop is a job that reads an input and writes an output: cron schedules it, and it is treated like any other ETL pipeline. A model that has to respond inside an HTTP request is a service with a latency budget, which loads its parameters into memory at start-up and keeps them warm. These are two different architectures, and the choice shapes the serialisation format, the sizing and the monitoring.

The data changes, the model does not

A trained classifier is a fixed function. The distribution of the data it works on is not. The phenomenon has a settled name — concept drift — and a literature to match: Widmer and Kubat describe it as early as 1996, Tsymbal gives a survey of it in 2004. The statistical relationship between the input variables and the outcome to be predicted shifts over time, for reasons external to the model: seasonality, a change in an upstream data source, a change in the behaviour of whoever generates the data, even the fact that the model acts and alters the process it observes.

The accuracy measured at validation says nothing about when all this will happen. It only says how the model behaved on past data. In production a model can degrade slowly for weeks without any error being raised: it keeps returning a class, a probability, a score, and those values are simply more and more wrong. Silent failure is the typical way a model in service stops working.

A precise operational consequence follows: a model in production must be monitored on the quality of its predictions, not only on service availability. Checking that the endpoint responds with a 200 under 50 ms says nothing about the correctness of what it responds. You need metrics on the input distribution — the comparison between the training distribution and the current one — and, where the real outcome is known after the fact, a continuous measure of field error. The latter often arrives late: in a churn model the true label is known weeks after the prediction, and until then you work only on indirect signals.

Governance implications

When a model makes or suggests decisions about people — a risk score, a priority, a classification — the question is no longer only whether it is accurate, but who answers for a wrong decision and on what data the model was trained. This requires traceability: for every version of the model in service, knowing which dataset it was trained on, with which parameters, by whom, and since when it has been active. It is versioning applied to an artefact that is neither code nor data, but depends on both.

Reproducibility is the technical prerequisite of this traceability. A model is reproducible if, given the same dataset, the same code and the same parameters — including the seed of the pseudo-random generators — it produces the same weights. Without fixing the seed, two training runs on the same input give different models, and it becomes impossible to tell whether a difference in production behaviour comes from a change in the data or from chance. Fixing the seeds and recording the library versions is the minimum for a model to be an object you can interrogate after the fact.

Limits

None of this depends on the algorithm. A decision tree and a support vector machine have the same serialisation problem, the same drift, the same need for monitoring. Incremental learning — Vowpal Wabbit’s online models, for one — lowers the cost of retraining because it updates the weights at each example, but it does not remove the need to measure whether the update is heading in the right direction: an online model chases noise as readily as it chases a signal.

And the limit of slow feedback remains. When the true outcome of a prediction is known only after some delay, any monitoring scheme that starts from real error is structurally behind the degradation. Indirect signals can be used — the drift of the input distribution — but they are an approximation, and a model can degrade even on stable inputs if what links input and outcome changes. On this point the concept drift literature has been clear for over a decade: the problem is known, the complete solutions are not.

For how these constraints play out when models move from experimentation into service, see the noze insight on the subject: https://www.noze.it/en/insights/machine-learning-production/.

Cover image: Overfitting diagram: two groups of colored dots separated by a highly jagged line that splits them perfectly, next to a smoother… — diagram by Chabacano, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Overfitting.svg