1
Curious builder0 XP earned · 300 to level 2
0 daysFinish a lesson to begin
Badge collection0 of 6 unlocked
50 small wins to finish your pathNext lesson →
Why models stall in notebooks
A model that runs only in a notebook is not a product. It has no address anyone can call, no record of how it was produced, no way to be rebuilt from scratch, and no one watching it when the data underneath it moves.
Last updated: 19 Oct, 2026 · MLOps
The MLOps overview named the parts of this course. This lesson says why they exist. The gap is familiar: a notebook that scores well, a stakeholder who wants to use it, and weeks of work that nobody planned for. The MLOps roadmap video puts a number on that work, calling deployment about a fifth of a project's time, and the reason it is a fifth is that none of the following comes for free.
What a notebook quietly leaves undone
- No reproducible path. Cells run in whatever order you pressed them, and the state in memory is part of the result. Restart the kernel a month later and the numbers can move, with nothing to say why.
- No record of the run. The model file on disk is the only artefact, and it does not carry the parameters, the metric or the data that produced it. Two model files in a folder are two mysteries.
- Data on one laptop. The CSV sits in a Downloads folder. Git refuses to hold it at any size worth training on, so nobody else can rebuild the same model from the same rows.
- No way for anyone to call it. A prediction needs the notebook open and the person who wrote it present. A product needs an address, a request shape and an answer.
- No automated build. Shipping a change means a person remembering the steps in order. The step they forget is the one that breaks production.
- Nobody watching. Once predictions reach users, the data drifts away from the training set and accuracy slides. A notebook has no way to notice.
The questions production asks that a notebook cannot answer
- Which run produced this model? Answered by experiment tracking, which stores the parameters, the metrics and the model together.
- Can I rebuild it from the same data? Answered by data and pipeline versioning, which pins the rows as well as the code.
- How does anyone else use it? Answered by a served API in a container, which runs the same way on any machine.
- How does a change reach production? Answered by a CI/CD pipeline, which tests, builds and deploys from a commit.
- Is it still any good? Answered by monitoring and a retraining strategy, which compare live data against the data the model learned from.
A notebook run against an operated service
| A notebook | An operated service | |
|---|---|---|
| How it runs | Cells, in the order you pressed them | A pipeline, start to finish, in one command |
| Who can use it | You, with the kernel open | Any caller, over HTTP |
| Record of a run | The output still on screen | Params, metrics and the model, stored |
| The data | A file on your machine | Versioned, with a hash anyone can fetch |
| Shipping a change | A person repeating steps | A commit that builds and deploys |
| When accuracy slides | You find out from a user | A drift report and a retrain |
Where the gap shows up first
- Handing a model to another team, where the first question is which data and which parameters, and the notebook has no answer.
- The second model. Everything done by hand for the first one has to be done again, and the shortcuts taken the first time are now the schedule.
- Three months after launch, when the predictions are worse and nothing in the project can say whether the data moved or the code changed.
Watch out. The gap is not a research problem, which is why it is easy to postpone. Every item above is ordinary engineering: a folder layout, a config file, a log line, a container. Postponing it does not make it smaller, it moves it to the week the model is supposed to go live.
Related
- Previous: MLOps overview
- Next: MLOps vs DevOps
- Reference: MLOps: continuous delivery and automation pipelines in machine learning
Try it yourself
- Take a notebook you have and write down what a colleague would need to reproduce its model exactly.
- Open the folder where your last model file landed and see whether anything there records the metric it scored.
- For one model you trained, name who would notice first if its accuracy dropped by a tenth.
Little by little, you're building something great.