What stages does the pipeline cover?

Preprocessing, training, evaluation, experiment tracking, and CI/CD-driven deployment — the full lifecycle around a model, not just the training step.

Why does preprocessing need to be a pipeline step instead of a notebook cell?

Because informal, copy-pasted preprocessing at training time tends to drift from what inference code actually does in production — defining it as a versioned, reusable step keeps the two in sync.

What does the evaluation stage actually check?

More than a single accuracy number — performance breakdowns across data slices, weak classes, and edge cases, since a headline metric alone hides how a model behaves in the situations that matter.

Why does experiment tracking matter?

Without it, you can't confidently answer which model version is in production or what data and hyperparameters produced it after a few iterations — tracking makes that provenance answerable later, not just in the moment.

What an End-to-End MLOps Pipeline Actually Needs (Beyond Just Training a Model)

Training a model that hits good accuracy on a validation set is, relatively speaking, the easy part of machine learning in production. The genuinely hard part — the part most ML tutorials skip entirely — is everything that has to happen around that model before it's actually deployable: reliable preprocessing, honest evaluation, experiment tracking, and a CI/CD pipeline that doesn't require someone manually SSHing in to push a new model version.

This project is about that "everything around it," built as an actual end-to-end MLOps pipeline rather than a single training script.

Preprocessing that isn't a one-off notebook cell

A model in production needs preprocessing that runs identically at training time and inference time — the classic failure mode is a notebook where preprocessing happens once, informally, and then the deployed inference code quietly does something slightly different. The pipeline here defines preprocessing as a versioned, reusable step, not a notebook cell that gets copy-pasted and drifts.

Evaluation beyond a single accuracy number

A single validation-accuracy number tells you almost nothing about how a model will behave on the specific slices of data that matter in production — which classes it's weak on, whether performance holds up on edge cases, how it degrades under data drift. The evaluation stage here is built to surface that breakdown, not just a headline metric.

Tracking: knowing which model is actually running

Without experiment tracking, "which version of the model is in production, and what data/hyperparameters produced it" becomes a question nobody can answer confidently after a few iterations. Tracking each run's data version, hyperparameters, and resulting metrics is what makes a model's provenance answerable months later, not just at the moment it was trained.

CI/CD: deployment as a pipeline step, not a manual process

The last stage automates what would otherwise be a manual, error-prone deploy: on a passing evaluation, the pipeline can push a new model version through CI/CD rather than someone manually copying a model file to a server and hoping nothing else changed in the meantime.

Why this is the actual MLOps skill

Anyone can train a model that scores well in a notebook. The skill this project is actually about — the one that's genuinely scarce — is building the infrastructure that makes a model's entire lifecycle (train, evaluate, track, deploy, and re-deploy when it drifts) repeatable and automated, instead of a one-time manual effort that nobody can reproduce six months later.