Get in touch
Work location
B-810/811, World Trade Tower (WTT), Makarba, Sarkhej Gandhinagar Highway, Ahmedabad,
Gujarat, India, 380015
Social link
A model that works in a notebook is a finding, not a product. Getting from one to the other is the actual job: versioned data, tracked experiments, containerized serving, and monitoring that catches drift before a customer does.
MLPipe is the MLOps layer we built behind 16 production models across 7 deployments. It versions the data, tracks every experiment through MLflow, serves each trained model as a containerized API, and keeps watching accuracy and drift once it’s live, with 12,400 API requests logged this week. Every number is traceable to the run that produced it.
Models built in notebooks had no dataset versioning, no experiment history, and no visibility once deployed. When something looked off in production, there was no way to trace it back to a cause: the data, the code, or simply a shift in the world.
Every dataset and training run is now versioned and tracked, the trained model deploys as a container rather than a manual script, and production accuracy and drift are watched continuously, with alerts firing before degraded output reaches a user.
A model that only exists in a notebook has no answer to “which version of the training data produced this?” That question matters the first time an output looks wrong. MLPipe versions every dataset and logs every training run through MLflow, so a model deployed today traces cleanly back to the exact data and parameters that built it. Deployment means a Docker container exposing a FastAPI endpoint, not a script someone runs when they remember to, and once it’s live, accuracy is checked continuously instead of discovered to have slipped three weeks later.
Four layers keep a deployed model honest: data is versioned first, every experiment is logged, the model is served from a container, and monitoring watches it in production. Each layer feeds the next, so lineage is never lost between training and serving.
Every change to a training dataset is tracked, so a model’s lineage back to its training data is never a guess.
.svg)
MLflow logs every run’s parameters, metrics and resulting model version automatically.
The trained model deploys as a Docker container behind a FastAPI endpoint.
Accuracy and drift are tracked continuously against baseline, with alerts before users notice a problem.
Every candidate placed on impact and effort, so the conversation moves from “could we?” to “which one first?”
Every run’s parameters and metrics are captured without anyone writing them down in a spreadsheet.
Promoting a model to production is a pipeline step, not someone SSHing in to run a script.
Production accuracy is compared against baseline on an ongoing basis, not spot-checked occasionally.
Degradation is flagged before it shows up as a support ticket or a bad decision downstream.
Not a target. The actual current state of the fleet, checked continuously.
The aim was simple: any number in production should trace back to the run that produced it. Here is how the shipped pipeline differs from what came before it.
Found that deployment mostly meant a local script, run manually, with no record of what data trained the live model.
Before touching training or serving, made sure every dataset change was tracked. The rest of the pipeline is only as trustworthy as this layer.
Every run’s parameters and metrics started being logged automatically instead of living in someone’s notes.
Both steps moved into Docker, so “it works on my machine” stopped being a deployment strategy.
Waited until there was something real in production worth monitoring, rather than building dashboards for models that didn’t exist yet.
Early alerts fired on normal seasonal shifts. Collecting enough history to tell the two apart came before trusting alerts unsupervised.
