<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>7-days-of-mlops on @milinddethe15</title><link>https://milinddethe15.tech/tags/7-days-of-mlops/</link><description>Recent content in 7-days-of-mlops on @milinddethe15</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 19 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://milinddethe15.tech/tags/7-days-of-mlops/index.xml" rel="self" type="application/rss+xml"/><item><title>Day 7: Deployment Is Not The End</title><link>https://milinddethe15.tech/posts/mlops/day7/</link><pubDate>Fri, 19 Jun 2026 00:00:00 +0000</pubDate><guid>https://milinddethe15.tech/posts/mlops/day7/</guid><description>Yesterday I learned why feature stores exist.
Models don&amp;rsquo;t learn from raw data.
They learn from features.
And if training and production use different features, model quality can quietly degrade.
That raised one final question.
What happens after a model is deployed?
Today I learned that deployment is actually the beginning of the lifecycle.
A Model Is Only Valuable In Production Link to heading A model sitting in a notebook creates no value.</description></item><item><title>Day 6: Why Do Models Fail Even When Training Accuracy Looks Great?</title><link>https://milinddethe15.tech/posts/mlops/day6/</link><pubDate>Thu, 18 Jun 2026 00:00:00 +0000</pubDate><guid>https://milinddethe15.tech/posts/mlops/day6/</guid><description>Yesterday I learned how machine learning workflows evolve from scripts into pipelines.
Pipelines help orchestrate:
Validate Data ↓ Transform Features ↓ Train Model ↓ Evaluate Model That raised another question.
Why do models sometimes fail in production even when they performed well during training?
The Model Is Usually Not The Problem Link to heading Imagine a model achieves:
Accuracy = 95% during training.
Everyone is happy.
The model gets deployed.</description></item><item><title>Day 5: When Does a Training Script Become a Pipeline?</title><link>https://milinddethe15.tech/posts/mlops/day5/</link><pubDate>Wed, 17 Jun 2026 00:00:00 +0000</pubDate><guid>https://milinddethe15.tech/posts/mlops/day5/</guid><description>Yesterday I learned how machine learning teams improve models through hyperparameter tuning, AutoML, and large-scale experimentation.
That raised another question.
What happens when training is no longer a single Python script?
The Script Starts Small Link to heading Most machine learning projects begin with something simple.
data = load_data() model = train(data) evaluate(model) Everything fits in one file.
Life is good.
Then the project grows.
Reality Looks Different Link to heading A production training workflow rarely consists of three steps.</description></item><item><title>Day 4: Training One Model Is Easy. Finding The Best One Is Hard.</title><link>https://milinddethe15.tech/posts/mlops/day4/</link><pubDate>Tue, 16 Jun 2026 00:00:00 +0000</pubDate><guid>https://milinddethe15.tech/posts/mlops/day4/</guid><description>Yesterday I learned how machine learning teams version datasets and track experiments.
That means we can finally answer questions like:
Which dataset trained this model? Which parameters produced this result? Which experiment was deployed? That raised another question.
How do ML teams systematically find better models?
Training One Model Is Easy Link to heading Most machine learning tutorials look like this:
Dataset ↓ Train Model ↓ Accuracy = 85% Done.</description></item><item><title>Day 3: If Git Versions Code, What Versions Data?</title><link>https://milinddethe15.tech/posts/mlops/day3/</link><pubDate>Mon, 15 Jun 2026 00:00:00 +0000</pubDate><guid>https://milinddethe15.tech/posts/mlops/day3/</guid><description>Yesterday I learned that reproducibility is one of the foundations of MLOps.
A notebook can help discover a good model.
A reproducible workflow helps others trust it.
That raised another question.
If Git versions code, what versions data?
Git Solved One Problem Link to heading Software engineering has a remarkable advantage.
Code is the source of truth.
If a bug appears, we can inspect commits.
If a deployment breaks, we can roll back.</description></item><item><title>Day 2: From Notebook to Reproducible Training</title><link>https://milinddethe15.tech/posts/mlops/day2/</link><pubDate>Sun, 14 Jun 2026 00:00:00 +0000</pubDate><guid>https://milinddethe15.tech/posts/mlops/day2/</guid><description>Yesterday I learned why DevOps alone is not enough for machine learning.
Software systems change when code changes.
ML systems can change when the data changes.
That raised another question.
How do ML engineers actually build models in the first place?
The Notebook Is Where Most ML Projects Begin Link to heading Most machine learning projects start with a Jupyter notebook.
You load a dataset.
Train a model.
Generate a metric.</description></item><item><title>Day 1: Why DevOps Is Not Enough for Machine Learning</title><link>https://milinddethe15.tech/posts/mlops/day1/</link><pubDate>Sat, 13 Jun 2026 00:00:00 +0000</pubDate><guid>https://milinddethe15.tech/posts/mlops/day1/</guid><description>Over the last 7 days, I explored AI Platform Engineering.
I learned how GPUs are scheduled, how models are served, and what a production AI platform looks like.
But there is still one important question left unanswered:
How does a model actually get from a notebook to production?
That&amp;rsquo;s where MLOps comes in.
Before learning tools like MLflow, Kubeflow Pipelines, or KServe, let&amp;rsquo;s understand the problem MLOps is trying to solve.</description></item></channel></rss>