Data and Model Versioning

Track which code, data, features, experiment, and model artifact produced every production release so you can debug, compare, and roll back safely.

🧒 Simple Explanation (ELI5)

If a cake turns out great, you need the exact recipe, ingredients, and oven settings to make it again. MLOps versioning records the equivalent for machine learning.

🔧 Why Do We Need It?

• Rollbacks need certainty: teams must know exactly which model was live before an incident.
• Audit requires lineage: regulated teams need evidence of how a model was produced.
• Retraining needs comparison: new models must be compared against known baselines.
• Data changes silently: mutable datasets destroy reproducibility.

🌍 Real-world Analogy

An aircraft manufacturer tracks every serialized part in every plane. If one part fails, they know exactly which aircraft are affected. MLOps needs that same discipline for data and models.

⚙️ Technical Explanation

Versioning in MLOps spans multiple layers: Git for code, versioned data assets for training inputs, experiment tracking for run metadata, feature pipeline versions for transformations, model registries for approved artifacts, and deployment metadata for what is actually live. Without this chain, incident response becomes guesswork.

📊 Visual Representation

⌨️ Commands / Syntax

az ml data create --name churn-train --version 17 --path ./data/train.parquet --type uri_file
az ml model create --name churn-model --version 42 --path ./outputs/model.pkl

git tag model-churn-v42
git push origin model-churn-v42

import mlflow

with mlflow.start_run(run_name="churn-v42"):
    mlflow.set_tag("git_commit", "8d4f2c1")
    mlflow.set_tag("dataset_version", "churn-train:17")
    mlflow.log_param("feature_view", "customer_features_v5")
    mlflow.log_metric("auc", 0.862)
    mlflow.log_artifact("outputs/model.pkl")

💼 Example (Real-world Use Case)

A claims-triage model regresses after release. Because the team versions data and models correctly, they discover that training used dataset version 18, which contained a changed label mapping from an upstream partner. They roll back model version 42 to version 41 and quarantine dataset version 18 for investigation.

🧪 Hands-on

1. Create a lineage table with columns for model version, dataset version, Git commit, experiment run, and deployment date.
2. Check how many of those columns your current models can actually fill.
3. Tag one Git commit and one model artifact with the same release identifier.
4. Write a rollback note for one model: if version 42 fails, what exact version do you restore?

🎮 Try It Yourself

🐛 Debugging Scenario

Problem: business accuracy drops, but nobody can tell whether the cause is new data or a code change.

• Root cause: dataset versions were overwritten in place and the model artifact was named manually.
• Troubleshooting steps: recover the deployed registry version, map it to its experiment run, verify the dataset snapshot, and diff the release commit against the previous stable version.
• Fix: use immutable dataset versions, registry-backed model versions, and deployment metadata that links both to the release.
• Verification: reproduce the previous version with the same dataset and code, then compare outputs side by side.

🎯 Interview Questions

🌐 Real-world Usage

Finance, healthcare, and insurance teams depend on lineage for audit and rollback. Consumer platforms rely on it to compare candidates and recover from regressions quickly.

📝 Summary

If you cannot trace a production model back to exact data and code, you do not really control it. Versioning is the backbone of reliable MLOps.