Most ML models fail in production for a reason that has nothing to do with the model. They fail because everything around the model, the part that actually keeps it running once real users show up, was never built. That is the production gap, and it is what this track exists to close.
Picture it in the concrete. A data scientist spends three weeks building a churn prediction model. It hits 94 percent accuracy on the test set. The demo goes perfectly. Everyone in the room is impressed. Six months later, that model has never made a single prediction for a real customer. It is sitting in a notebook on a laptop, exactly where it was born.
This is the most common story in machine learning, and it is not rare. Industry surveys have repeatedly put the share of models that never reach production somewhere between half and the vast majority. Gartner has estimated that only about half of models make it from prototype to production even at mature organizations. The exact number is argued about, but the direction is not. Most models never ship.
The natural reaction is to blame the model, or the data, or the algorithm. That reaction is wrong, and correcting it is the entire point of this track.
The hard part of machine learning in production was never the model. It is everything around the model.
Building the model is the part that gets taught in courses and the part that feels like the real work. But a trained model is only the engine. It cannot move anyone anywhere on its own. The discipline of building everything around that engine so it runs reliably, every day, at scale, is called ML platform engineering. That is what this track is about.
Picture a beautifully built engine sitting on a workbench in a garage. It is precision engineered. It revs perfectly. It is also completely useless for getting you to work, because an engine on a bench does not move anyone anywhere.
To turn that engine into a car you can actually drive, you need a lot more:
A trained model is the engine. The car is everything else. The data scientist builds the engine and cares about how well it runs on the bench, which we measure as accuracy. The ML platform engineer builds the car and cares about whether it keeps running on a real road, next week, under load, without a mechanic riding along.
Hold onto this picture. Every topic in this track is another part of the car.
Here is the gap made concrete. Everything that works quietly in a notebook becomes a real engineering problem the moment real users show up.
| In the notebook | In production you now need |
|---|---|
| Runs on your machine, your Python, your library versions | It must run identically on a server you will never see, which means containerization |
You call model.predict(x) in a cell | Ten thousand users call it per second over , which means a serving API |
| You trained it once, by hand, on a CSV | The data changes every week, so it must retrain itself, which means pipelines |
| Features computed inline in the notebook | The same feature logic must run at training time and at request time, or predictions go wrong, which means a feature store |
One file named model_final_v2_really.pkl | Dozens of versions, and you must know which one is live and roll back in seconds, which means a model registry |
| Accuracy checked once, on the test set | The world shifts and accuracy silently rots, which means monitoring and drift detection |
A normal web application is a straight line. You deploy it, and it keeps doing the same correct thing until you change the code. A machine learning model is different. It starts decaying the moment the real world drifts away from the data it learned from. Fraud patterns change. Customer taste changes. Prices change. The model does not know any of this happened.
So production machine learning is not a one-time deploy. It is a loop that has to run forever:
The platform's job is to run this loop with as little human effort as possible. Serve predictions. Watch how the model behaves on live data. Catch the moment it starts to decay. Retrain on fresh data. Redeploy the new version safely. A human steps in for decisions, not for plumbing. When people say a company has a mature ML platform, they mean this loop turns on its own.
To see why the loop is not optional, watch what happens to a model that ships and is then left alone. The accuracy falls while nothing looks broken, which is exactly what makes it dangerous.
Catching that decline is only half the job. The platform also has to decide when a retrain is actually worth it, because retraining on thin or bad data can ship a worse model than the one you have.
People often assume MLOps is DevOps with a model dropped in. The difference is exactly one thing, and that one thing is what makes it hard.
In traditional DevOps, two things change over time: your code and your configuration. Both are things you control directly. When something breaks, it broke because a human changed code or config, and you can find that change.
In MLOps, a third thing changes on its own: the data.
Code you control. Data drifts whether you touch it or not. And when the data changes, the model's behavior changes without a single line of code changing.
This is why an ML platform needs machinery that a normal backend never needs. You have to version data, not just code. You have to version models and track exactly which data trained each one. You have to monitor the statistical shape of live traffic, not just error rates and . You have to be able to retrain and redeploy automatically. It is DevOps standing on a floor that is quietly moving under your feet.
Put the pieces together and you get the map for this entire track. Here is the whole platform on one canvas. Follow the numbered path to see how a model travels from a notebook experiment to a monitored production service, and hover any box to see what it does.
Each component solves one specific failure of the notebook world, and each has a real industry-standard tool behind it.
| Component | The problem it solves | The tool you will learn |
|---|---|---|
| Packaging and containerization | The model must run the same everywhere | , BentoML |
| Serving and inference APIs | Turn a model file into a service under load | BentoML |
| Training pipelines and orchestration | Retrain automatically instead of by hand | Kubeflow |
| Feature stores | Kill train and serve skew, reuse features | Feast |
| Model registry and versioning | Know what is live, roll back fast | MLflow |
| Monitoring and drift detection |
None of this is theoretical. Every company running machine learning at scale eventually built exactly this kind of platform, usually after feeling the pain of deploying models by hand.
Uber built Michelangelo, an internal ML platform that standardized the whole lifecycle from feature engineering to training to serving. It let hundreds of teams ship models without each one reinventing the plumbing, and it powered everything from arrival-time estimates to fraud detection.
Netflix built Metaflow, a framework for building and running data science workflows, which they later open sourced. It let scientists write normal Python while the platform handled scaling, scheduling, and moving work to the cloud.
Meta built FBLearner Flow, which ran millions of modeling experiments and served predictions across the company. At its peak it was training and serving a huge share of Meta's production models through one platform.
Airbnb built Bighead, and Spotify built its own ML platform on top of Kubeflow, both for the same reason. The model was never the bottleneck. The path from a good model to a reliable production service was the bottleneck, and a platform is what removes it.
The lesson from all of them is the same. If you want machine learning to be a repeatable capability rather than a series of one-off heroics, you build the platform. That is what you are going to learn to do here.
3 questions - Score 80% to pass
According to this lesson, what is the main reason most ML models never reach production?
What single factor makes MLOps fundamentally harder than traditional DevOps?
Why is production machine learning described as a loop rather than a line?
Look at the right-hand column. Every row names a different piece of machinery. That is not a coincidence. An ML platform is precisely the system that closes every one of these gaps. Each becomes its own lesson in this track. The first two, getting a model to run identically everywhere and answer over HTTP, are covered in model packaging and containerization and model serving and inference.
| Catch silent model decay |
| Evidently |
| Scaling and GPU infrastructure | Serve heavy models without burning money |
| Production RAG and LLM systems | Run retrieval plus a model reliably | LLM serving stack |
Build these once as reusable infrastructure and the payoff is enormous. The next model your team ships does not rebuild any of this. It plugs into a platform that already exists, and it goes from notebook to production in days instead of quarters. That multiplier is the real reason companies invest in platforms rather than deploying each model by hand.
The last row, production RAG and LLM systems, is where this same platform meets generative AI, and the choices there start with fine-tuning versus RAG versus prompting.
It also helps to see the same platform as a stack rather than a flow. Users only ever touch the top layer. Every layer beneath it exists so that top layer keeps answering correctly next month.