Time based split was a wake up call
Our forecast error got honestly worse after fixing the split, which is exactly what we needed to know.
Browse
Take a model from notebook to a monitored service: reproducible training, MLflow tracking, packaging, CI, deployment and drift checks
Created by Kwame Mensah
A model in a notebook is an experiment. A model that makes predictions for real users, keeps working as data changes and can be retrained safely is a product. The gap between the two is where many machine learning projects stall. MLOps is the set of practices that closes that gap.
This course takes a single, realistic model, a demand forecast for a chain of bakeries, and walks it through the whole lifecycle. We keep the tooling deliberately modest and widely used, so the habits transfer to any platform your team adopts later.
Most production problems are not exotic. They are a column that changed type upstream, a feature computed differently in training and serving, or a model nobody noticed had degraded. We focus on simple, robust checks that catch those problems early. Tools are introduced only when a problem calls for them.
You should be comfortable with Python, pandas and scikit-learn, and know the basics of Git and the command line. Docker experience helps but is introduced from the start.
Statistician and ML engineer teaching statistics and how to ship models responsibly
I trained as a statistician and now work on machine learning systems, from experiment design to keeping models healthy after deployment. I spend a lot of time explaining uncertainty to people who would prefer a single number.
My courses focus on intuition first. We simulate things in Python before we use a formula, so the formula has something to stand on. Then we look at the tools teams actually use, such as scikit-learn, MLflow and FastAPI.
I want my students to be the person on the team who asks how big the sample was and how the model will be monitored.
Our forecast error got honestly worse after fixing the split, which is exactly what we needed to know.
I could train models but never shipped one reliably. The bakery case study mirrors my job almost exactly.
pandera checks now run at the start of every pipeline we own. Two upstream changes caught already.
I appreciated not being pushed into a big platform. More on orchestrators would have been nice.
We now shadow every new model for two weeks. It has prevented one bad release already.
The registry alias approach simplified our deployments a lot. Monitoring section is strong too.
Docker is introduced, but if you have never used it the serving section moves quickly.