Complementing Data Versioning, model versioning is the systematic tracking of every distinct trained model over time — its lineage, its config, and its relationship to other versions.
What Defines a Model "Version"
A new model version typically results from any meaningful change: different training data, different hyperparameters, a different architecture, or even the same configuration retrained from a different random seed. Not every version needs to be kept forever, but each should be traceable back to exactly what produced it while it's relevant — a direct extension of the model registry's version-tracking capability from Model Registry.
A Practical Model Versioning Scheme
# Semantic-versioning-inspired scheme, adapted for models
# MAJOR.MINOR.PATCH, e.g. "2.3.1"
#
# MAJOR: architecture change, or a fundamentally different training approach
# MINOR: retrained on significantly new/updated data, or a meaningful hyperparameter change
# PATCH: retrained on the same config, e.g. a scheduled periodic retrain with only minor data updates
model_metadata = {
"version": "2.3.1",
"architecture": "resnet50",
"training_data_version": "dataset_v14",
"training_run_id": "mlflow_run_abc123",
"parent_version": "2.3.0", # tracks lineage -- what this version was derived from
"created_date": "2026-08-01",
}Why Lineage Tracking Matters
Recording a model version's "parent" (what it was derived from — fine-tuned from, or retrained with a small change relative to) builds a traceable history, valuable for understanding how a model has evolved, debugging when a regression is introduced between two versions, and supporting rollback decisions with full context about what changed and why.
Connecting to Model Drift Monitoring
Model versioning becomes especially important once Model Drift monitoring triggers a retrain — the new version needs to be clearly distinguished from, and comparable against, the previous one, with both the reason for retraining and the resulting performance change recorded as part of its metadata.
Common Mistakes
- Versioning models inconsistently or informally (e.g. ad hoc filename suffixes) rather than through a systematic scheme integrated with the model registry — this makes it hard to answer "what exactly changed between version A and version B" later.
- Not recording a new version's lineage (what it was derived from and why) — this loses valuable context for understanding a model's evolution and debugging regressions between versions.
Interview Relevance
Q: "Why is tracking a model version's 'lineage' — what it was derived from and why — valuable, beyond just having a version number?" A bare version number tells you a model changed, but not what changed or why — lineage metadata (parent version, training data version, the specific reason for retraining) provides the context needed to understand a model's evolution over time, debug a performance regression by comparing exactly what differs between two versions, and make an informed rollback decision with full understanding of what's being reverted and why.
Practice Question
Why might a model versioning scheme distinguish between a "major" version bump (architecture change) and a "patch" version bump (routine scheduled retrain)?
