← Back to concept explainers

Concept Fable

Model version management

Conclusion first:Model version management tracks different combinations of models, data, parameters, and code to ensure deployment, rollback, and auditing are reproducible. It's not just giving models version numbers; it also records training data, features, hyperparameters, evaluation results, approval status, deployment environment, and scope of use. For an Agent platform, models, prompts, retrievers, rerankers, and tool policies should all be linkable to a reproducible release.

Model Versioning · MLOps / governance

Read the story first. There is no rush to give a definition here; let the question grow on its own first.

Fable

Three recipes all called spring salve

The South Street pharmacy had a spring ointment. The first version stopped itching quickly, the second version had a faint scent, and the third version did not melt easily. For convenience, the shopkeeper labeled all the bottles "Spring Ointment."

At first no one thought there was a problem. Clerks took medicine from the shelves, and customers repurchased by name. It was not until one group of customers said the new ointment had no effect, while another group said the taste had improved, that the pharmacy discovered everyone was not buying the same version.

The shopkeeper's patch was to have the clerks remember: blue cap means new version, white cap means old version. A few weeks later, the supplier changed the bottle caps, and the night-shift clerk mixed the two batches together again.

More seriously, when a physician wanted to look up an allergy complaint, they could not find which day that jar of ointment was brewed, which batch of herbs, which formula, or who approved it for the shelf. The pharmacy had to pull all spring ointments.

After the old pharmacist took over, he first assigned numbers to every formula, medicinal batch, brewing record, and shelving decision. The ointment could no longer be identified by name alone; it had to be traceable to its complete origin.

From then on, before a new formula entered the counter, its version, change description, applicable population, test records and rollback method had to be registered. Old versions could continue to be sold, but had to be clearly marked and were not allowed to be mixed with new versions.

When customers reported problems, the apothecary could look up the specific version and compare the effects of the same symptom across different versions. When a rollback was needed, the clerks knew which version to return to, rather than reverting to a vague old name. The apothecary also tied customer feedback to specific batches. If someone said it stung, they could trace which version, which pot, and which herb; if someone praised it, they could also know whether the change truly brought improvement, rather than accidentally suiting the right person. The old pharmacist also banned "quiet improvements." Even leaving out a single spice had to be registered as a minor version, because allergies, effects, and shelf life could all change with it. The numbering was not decoration for the bookkeeper; it let every change return to a specific responsibility. The shopkeeper also stopped fearing keeping old versions. As long as they were clearly labeled and traceable, old versions could serve the right customers, and new versions could be tried with confidence.

The pharmacist discovered that version numbering did not make the pharmacy slower; instead, it made experiments bolder. Because every change could be tracked, failures would not contaminate the whole shelf. The manager finally understood that the real risk was not formula changes, but that after a change no one could clearly say which one was currently being sold.

Reveal

This story is about: model version management

Model version management tracks different combinations of models, data, parameters, and code to ensure deployment, rollback, and auditing are reproducible. It's not just giving models version numbers; it also records training data, features, hyperparameters, evaluation results, approval status, deployment environment, and scope of use. For an Agent platform, models, prompts, retrievers, rerankers, and tool policies should all be linkable to a reproducible release.

What matters is that it is not just a term, but a structural problem that repeatedly appears in real AI / Agent systems. Understanding it lets you judge when to add a model, when to change a process, and when to add governance.

Metaphor mapping

  • Three formulas all called spring salve: multiple model versions sharing a vague name
  • Bottle cap color: a fragile artificial marker
  • Allergy complaint cannot be traced to its source: missing lineage and audit records
  • Recipe and herb codes: model artifact, data version, code version, and parameter records
  • Release decision: deployment approval and promotion
  • Which version to roll back to: rollback to a specific version
  • Compare the effects of different versions: A/B test, evals and production monitoring
  • Final insight: model version management makes model changes reproducible, auditable, and rollback-capable

Andy Ren Xu's judgment

The practical value of this concept is that it helps you break "AI features that look smart" into deliverable, verifiable, and governable units of work.

Model registryexperiment trackingartifact versioningrollbacklineage
京ICP备2026014272号