Episode Details

Back to Episodes

ML in production: why models die after the notebook

Episode 88 Published 1 month, 1 week ago
Description

Why do most machine learning projects never leave the lab? The position here is blunt: the model is about ten percent of the work and the other ninety percent is pipelines, monitoring and ownership. The episode walks through the three failure points at the notebook to production handoff, data drift, unowned pipelines after launch, and systems never designed for retraining, and why a drifting model costs money quietly instead of paging you at midnight.

You come away able to name the roles that fix this, the ML engineer and the data engineer, read vendor claims from DBT Labs against O'Reilly Radar and MIT Sloan Management Review, apply data as a product, and ask the accountability question before funding an AI project.

Key takeaways

  • Before approving any model, ask who by name is on the hook to keep it running six months after launch.
  • Budget for an ML engineer who sits between the data scientist and the software team, not just modellers.
  • Treat each dataset as a product with an owner, a quality standard, documentation and a promise it will not silently change.
  • Monitor for data drift, because a degrading model keeps returning confident answers instead of crashing.
  • Discount vendor productivity claims such as DBT Labs surveys and cross check them against O'Reilly Radar or MIT Sloan research.

Chapters
0:00 Why ML projects die after the notebook
1:10 Three places the handoff snaps
2:02 The ML engineer nobody budgets for
2:25 Data as a product, not byproduct
3:25 Why buying a platform does not help
4:07 The one question to ask before greenlighting

Go deeper, free lessons

Sources

The article: https://www.mba-training.com/en/blog/ml-pilots-production-field-guide

MBA Training, mba-training.com

Listen Now

Love PodBriefly?

If you like Podbriefly.com, please consider donating to support the ongoing development.

Support Us