Shipping and monitoring models

A notebook is a sketch. To ship, move your code into plain Python files: one to prepare data, one to train, one to predict. Save the trained model to a file, along with the exact preprocessing steps. A scikit-learn Pipeline keeps both together, so training and serving cannot drift apart.

Then put it behind an API. FastAPI is a popular choice: a few lines turn a predict function into a web endpoint that takes JSON and returns a prediction. Not everything needs to be live. A nightly batch job that writes scores to a table is often simpler and enough.

Docker puts your code, the model file and the exact library versions into a container. If it runs on your laptop, it runs the same on a cloud server. Pin your versions; a silent library update can change predictions.

MLOps is the name for the habits that make this repeatable: code and data in version control, automated tests, a pipeline that retrains and checks a model before it replaces the old one, and a record of which model version is live.

The world changes after you train. Prices rise, users behave differently, a new product launches. When the input data shifts, that is data drift. When the link between inputs and the right answer changes, that is concept drift. Both make a good model slowly go wrong, with no error message.

So watch three things: the system (speed, errors, cost), the inputs (do they still look like the training data?) and the outcomes (once true answers arrive, is accuracy holding?). Set alerts, and plan how and when you retrain.

Do not swap models all at once. Run the new one in shadow mode, where it predicts but nobody sees the result, or send it a small share of traffic first. Keep the old version ready so you can roll back in minutes.