Introduction to MLOps & Model Versioning: Give Every Model a Memory

You trained a model last month. It worked well. Then you retrained it last week. Now you can’t remember what changed, and you can’t get last month’s version back. Sound familiar? This is the exact problem EP101 of Intelevo solves, and this article is your companion guide to that episode.

By the end, you’ll understand MLOps in plain language. You’ll also understand model versioning, and you’ll see a working MLflow example you can copy today. Let’s get started.

The Problem: A Model With No Memory

In EP100, you packaged a trained model into a FastAPI app. Then you deployed it inside a Docker container. That container runs anywhere, which is great progress. But there’s a catch.

Every time you retrain that model, you overwrite the old one. The new version replaces the old file. So the version your team trusted last month simply disappears. There’s no history. There’s no rollback. There’s no way to compare today’s results against yesterday’s.

This is where MLOps comes in. And more specifically, this is where model versioning comes in. Together, they give your model a memory.

What Is MLOps, Really?

MLOps stands for Machine Learning Operations. That name sounds technical, but the idea behind it is simple. MLOps is just a set of habits and tools. These habits keep your model’s history organized, from the moment you first train it, through every retrain, all the way to the version currently serving real users.

Here’s an analogy that makes this click instantly.

Think of a Chef’s Recipe Notebook

Picture a professional chef. A good chef never trusts memory alone. Instead, every time a recipe changes, the chef writes it down. A pinch more salt here. A lower oven temperature there. Each change gets a date and a number.

So if a new version disappoints the table, the chef simply flips back. The chef serves what worked before. Nothing is ever truly lost, because everything sits inside that notebook.

That’s exactly what we want for a machine learning model. Every training run deserves its own entry. Every entry deserves a date and a version number. And when a new model underperforms, you should be able to flip back just as easily.

That recipe notebook, translated into code, is what we call model versioning.

The MLOps Lifecycle in Five Steps

MLOps generally moves through five steps: Build, Track, Version, Deploy, and Monitor. You build the model first. Then you track how it performs. Next, you version it, so every attempt is saved. After that, you deploy it, similar to what you did in EP100. Finally, you monitor it in production.

This article, and the video that goes with it, focuses on step three: Version. In EP102, we shift focus to step five: Monitor, where we cover data drift.

Why Model Versioning Actually Matters

Let’s compare two worlds, side by side. This comparison makes the value obvious.

Without model versioning:

• Nobody knows for certain which model is currently live. Whoever ran the script last might remember, or might not.
• A bad retrain has no way back. The old, working model is gone.
• Comparing results relies on guesswork, memory, or scattered notes.
• A new teammate needs a full walkthrough, because nothing is written down.

With model versioning:

• One clear, current version exists, and everyone can see it.
• You can roll back to the last good version in seconds.
• Every version’s metrics sit side by side, ready to compare.
• History is documented. A new teammate reads it and catches up fast.

Notice the pattern here. Model versioning doesn’t just protect your best model. It also protects your team’s time, and it protects your confidence when something breaks.

What Should Every Version Capture?

A useful version needs more than just a saved file. In fact, four pieces matter most.

1. The code. This is the exact training script that produced the model. Without it, you can’t recreate anything.
2. The data. This means the dataset, or the specific snapshot of it, that trained the model. Data changes over time, so this detail matters.
3. The settings. These are your hyperparameters: learning rate, tree depth, number of epochs, and so on.
4. The model file itself. This is the trained artifact, saved and clearly named.

Capture all four together, and you can recreate exactly what worked, even months later. Skip even one, and you’ll eventually hit a wall you can’t explain.

From Training Run to Tracked Version, in Five Steps

Here’s how the full flow looks in practice:

1. Train your model, just as you normally would.
2. Log the parameters and metrics as the run happens.
3. Save the model artifact somewhere safe.
4. Register that artifact with a version number.
5. Compare runs against each other, then promote the best one.

Notice what didn’t change here: your model-building code stays exactly the same. You’re not rewriting your machine learning logic. You’re simply wrapping it with a few extra lines. That’s the whole trick, and it’s why this habit is so easy to adopt.

Hands-On: Track Your First Model With MLflow

Now let’s make this concrete. MLflow is a free, open-source tool, and it does exactly what our recipe notebook analogy describes. It logs every run automatically, so you don’t have to remember anything manually.

Step 1: Install It

First, install MLflow alongside scikit-learn.

pip install mlflow scikit-learn

Step 2: Import What You Need

Next, bring in MLflow and your usual model class.

import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier

Step 3: Name Your Experiment

Give your experiment a name once. As a result, every future run groups together sensibly, instead of scattering across unrelated logs.

mlflow.set_experiment("churn-prediction")

Step 4: Wrap Your Training Code

This next part is the key move. You wrap your training code inside a with mlflow.start_run(): block. Everything inside that block, MLflow watches and records automatically.

with mlflow.start_run():
    model = RandomForestClassifier(n_estimators=200)
    model.fit(X_train, y_train)

Step 5: Log the Metrics and the Model

Still inside that same block, score your model. Then log what actually matters: the parameter you chose, the accuracy you achieved, and the trained model itself.

    acc = model.score(X_test, y_test)

    mlflow.log_param("n_estimators", 200)
    mlflow.log_metric("accuracy", acc)
    mlflow.sklearn.log_model(model, "model")

That’s the entire change. Four extra lines, wrapped around code you already had.

Step 6: Open the Dashboard

Finally, open a terminal and run one command.

mlflow ui

This opens a local dashboard at localhost:5000. There, you’ll see every run listed, complete with its parameters, its accuracy, and its saved model, all side by side. One line earlier, you had none of that visibility. Now you have all of it.

Choosing a Versioning Strategy That Fits Your Team

You don’t need every available tool on day one. Instead, start simple, and only upgrade once the simple approach starts to hurt.

If you’re solo, or on a small team, MLflow alone works beautifully. It’s free, it runs locally, and it requires only a tiny code change. This makes it perfect for getting started quickly.

If you’re managing large datasets, or need cloud pipelines and team approvals, that’s when you graduate to full platforms. Tools like DVC, SageMaker, or Vertex AI handle versioning at a larger scale. They also plug into broader cloud workflows.

Either way, the underlying principle stays the same. Version everything, so nothing gets lost.

MLflow vs. Full Platforms: A Quick Comparison

Still unsure which option fits you? Here’s a simple way to decide.

Choose MLflow if you work alone, or with a very small team. Choose it if your datasets fit comfortably on your laptop. Choose it if you want to start today, without setting up any cloud infrastructure first.

Choose a full platform like DVC, SageMaker, or Vertex AI if your datasets are large and shared across a team. Choose one if you need approval workflows before a model reaches production. Choose one if your pipeline already lives in the cloud, and you want versioning to plug directly into it.

Notice that neither option is “better” in an absolute sense. Instead, each one fits a different stage of growth. Many teams actually start with MLflow, then add a full platform later, once their needs get bigger. So don’t feel pressure to pick the “advanced” option immediately. Start where you are, and upgrade when it makes sense.

Three Habits That Keep Your Models Safe

Beyond the tooling, a few habits make an enormous difference.

First, tag every run. Even a “just testing” run deserves a name and a short note. Your future self will thank you for this small effort.

Second, never overwrite production in place. Instead, promote a new version. Always give it a new number. This one habit alone prevents most versioning disasters.

Third, record the why, not just the what. Metrics show what changed numerically. But a short note explains why you made that change. That single sentence often saves your next debugging session.

Three Mistakes First-Timers Make

Now, let’s cover the traps that catch most beginners.

Tracking too late. If you bolt on versioning after months of ad-hoc training, your early history is already gone. So the earlier you start, the more you preserve.

Trusting “latest” blindly. The newest run isn’t automatically the best one. Always check the logged metric instead of the timestamp. Otherwise, you might promote a weaker model by accident.

Skipping the notes. Numbers alone don’t explain a decision. A missing note becomes a mystery for your future self, and mysteries cost time.

Avoid these three traps, and you’ll skip the painful lessons most people learn the hard way.

Why This Habit Pays Off

Once versioning becomes a habit, it stops feeling like extra work. Instead, it becomes simply how you train models. And the payoff shows up in three places at once.

Reproducibility comes first. You can recreate any past result exactly, even months later, because every detail sits recorded.

Team speed follows right behind it. New teammates read the history instead of repeatedly asking what happened. So onboarding gets faster, and confusion drops.

Confident deploys round out the list. You promote the version with proof it performs better, rather than a guess based on gut feeling. That confidence changes how your whole team operates.

Quick Recap

Let’s tie everything together. MLOps is simply the habit of keeping your model’s recipe notebook current. Model versioning means you never overwrite a model. Instead, every run gets its own dated, numbered record.

A useful version captures four things: code, data, settings, and the model file. MLflow logs all of this automatically, using just a few extra lines wrapped around code you already have. Finally, tag your runs, protect production, and always write down the why.

What’s Next: EP102

Your model is now versioned, and it’s live in production. But shipping a model isn’t the finish line. In EP102, we shift attention to what happens after deployment.

Specifically, we’ll cover monitoring models in production, along with data drift. Over time, the real world quietly drifts away from the data your model originally trained on. So we’ll show you how to catch that shift early, before your users ever notice a problem.

Frequently Asked Questions

Does model versioning require a cloud account? No, it doesn’t. MLflow runs entirely on your own laptop. You only need a cloud account once your team grows, or once your datasets outgrow local storage.

Is model versioning only useful for big teams? Not at all. Even a solo learner benefits, because six months from now, you won’t remember every detail of today’s training run. Your notes and logs will remember for you.

How is model versioning different from regular code versioning? Code versioning, through tools like Git, tracks your scripts. Model versioning goes further. It also tracks your data snapshot, your hyperparameters, and the trained model file itself. So it captures the full picture, not just the code.

Do I need to learn MLOps before I learn model versioning? No, you can learn them together, and honestly, that’s the easiest path. Model versioning is simply one practical piece inside the broader MLOps habit. This episode teaches both at once, using one hands-on example.

What happens if I skip versioning for now? Nothing breaks immediately. But eventually, you’ll retrain a model, lose the old one, and wish you had a way back. Starting early costs almost nothing. Starting late costs real time and real frustration.

Watch the Full Walkthrough

This article covers the core ideas, but the video walks through every step live, including the full MLflow demo on screen. If you’d like to see it in action, watch EP101 on the Intelevo YouTube channel. Then, once you’ve watched it, try running the MLflow example yourself on any small project you already have.

If this article helped you, please like the video, subscribe for EP102, and leave a comment with your questions. I read every single one. See you in the next episode.