We want an identifier for a model such that: identical inputs → identical ID, and any change → new ID. This is exactly the property of a content hash.
Why this step? We separate the machine identity (hash, immutable, exact) from the human label (v3, Production, mutable, meaningful). This is the same split Git uses: commit SHA (immutable) vs. branch name (mutable pointer).
A version-controlled store mapping a model name to an ordered list of immutable versions, each with metadata, metrics, artifacts, and a mutable stage label.
Which 4-tuple makes a model reproducible?
(code hash, data hash, hyperparameters, random seed) — with a deterministic pipeline they reproduce byte-identical weights.
Why can't plain Git version models well?
Weights are large binaries with meaningless diffs, and identical code can give different weights due to stochastic training.
What is content-addressable versioning?
Using a cryptographic hash of the artifact bytes as its ID; identical bytes → same ID, any change → new ID.
Why is registry rollback near-instant?
Old versions are immutable and still stored; rollback just flips an alias/stage pointer instead of moving artifacts.
What do MAJOR/MINOR/PATCH mean for a model?
MAJOR = breaking interface change; MINOR = retrained same interface; PATCH = serving/wrapper fix, weights unchanged.
Why must metrics be tied to an eval-data hash?
A metric is only comparable across versions if measured on the same frozen eval set; otherwise it's apples vs oranges.
What is model lineage?
A backward-pointing DAG linking a version to its data version, code commit, and experiment run for reproduction/audit.
Immutable version vs mutable stage — difference?
The version (weights+metadata) never changes; the stage/alias (Staging/Production/champion) is a movable pointer.
Recall Feynman: explain to a 12-year-old
Imagine you bake many cookies (models). Each cookie gets a numbered box you never re-open or change (immutable version). On the box you write the recipe, exact ingredients, and oven settings (code, data, seed) so you could bake the exact same cookie again. You keep a big shelf (registry) of all boxes. A sticky note that says "SERVE THIS ONE" (the Production alias) sits on the current best box. If the served cookie turns out bad, you just move the sticky note back to yesterday's box — you don't have to re-bake. That's rollback.
Dekho, ek trained ML model sirf ek .pkl file nahi hota — woh actually code + data + hyperparameters + weights + environment ka combination hai. Agar tum sirf pickle file save karoge, toh kabhi reliably nahi bata paoge ki "production me kaunsa model chal raha hai aur usko dobara kaise banau?" Isiliye model registry use karte hain — yeh ek version-controlled database hai jahan har model ek immutable (kabhi na badalne wala) version ki tarah store hota hai, uske saath metrics aur lineage bhi.
Sabse important concept: reproducibility 4-tuple — code hash, data hash, params, aur random seed. Agar yeh chaaro pin kar do aur pipeline deterministic ho, toh dobara run karne par bilkul same weights milenge. Version ki identity ke liye hum artifact ke bytes ka content hash (SHA-256) lete hain — same bytes toh same ID, thoda bhi change toh naya ID. Upar se human-friendly v1, v2, v3 label laga dete hain.
Rollback ki asli beauty yeh hai: purane versions immutable hote hain aur stored rehte hain, toh production kharab hua toh sirf alias/pointer ko purane version pe move karo — seconds me ho jata hai, koi artifact copy nahi karna padta. Yaad rakho "VIP-SAL": Versions Immutable, Pointers (Stages/Aliases) hi move hote hain, aur Lineage se rebuild kar sakte ho.
Ek badi galti jo sab karte hain: v5 ka 0.93 aur v4 ka 0.91 dekh ke keh dena "v5 better hai". Yeh tabhi valid hai jab same frozen eval dataset pe measure kiya ho — warna apples vs oranges. Isiliye registry metric ke saath eval-data ka hash bhi store karta hai. MLOps interviews aur real production dono me yeh concept bahut kaam aata hai.
