Do you prefer Stages or Labels to promote model versions in Model Registry?

Question

I have a question about applying best practices for model lifecycle management in Model Registry.

AFAIK, there are two mechanics to implement promotion of model versions to Dev/Staging/Prod:

1. Stages (like in MLflow). A single version has a one Stage only. So it's either "my_model v2 is in Prod" or "my_model v2 is in Staging".
2. Labels. A single version can have multiple labels. So it could be both: "my_model v2 is in (Prod, Staging)"

The Stages approach makes sense if you treat them like buckets, and intend to give a Kanban-style workflow.

The Labels approach is much more flexible and less opinionated (and can represent actual environments, because a single version can be deployed on multiple envs/setups), but on the other hand it might be "too flexible" and not pointing ML practitioners at any productive practices around using this feature. Specifically, in case of Model Registry you probably want to split your decisions and actual state of the deployments. In this case Labels should be a declaration of your decisions regarding specific version, not a reflection of what is currently happening on your deployment infrastructure with those versions => they should represent decisions about deployments to actual environments, but not the state of those deployments.

Which one of Stages/Labels you find more suitable for Model Registry and why?

Answer 1

Significant pros and cons are there for both the methodologies. To justify the requirement, Stages can be considered as upvoted methodology with some additional features in implementation.

Labeled:

1. The labeled data is more flexible as mentioned in several relatable documentations, but the point to be considered is it is unpredictable.
2. We cannot automatically tell whether an algorithm output is correct or not. It is not like in ML where you have labeled data to compute accuracy or recall on your evaluation set.

Stages:

1. It can help to give updates on different levels like API integration, CI/CD pipelines.
2. It helps to implement configuration modifications whenever it is required.

The supportive documentation

Stages is suggestable according to the requirement. And this can be modified according to the size of data and also the type of requirement.