Snowflake Model Registry: Versions, Metrics and Metadata Tags

1.Logging a model creates a version

The Model Registry stores models as first-class, schema-level Snowflake objects. You don't need a special registry database. Any Snowflake schema can serve as a registry, although Snowflake recommends creating a dedicated schema such as ML.REGISTRY. In Python you open the registry with Registry(session=..., database_name=..., schema_name=...). It returns a handle for logging new models and getting references to existing ones. The main classes are Registry (manages models within a schema), Model (represents a model) and ModelVersion (represents one version of a model).

Adding a model to the registry is called *logging* it. log_model serializes the Python model object and creates the Snowflake model object, together with any metadata you pass in the same call. A model object only comes into existence when its first version is logged. To retrain and register a new version, you call log_model again with the same model_name and a new version_name. The pair must be unique in the schema, and the model name can't be changed after logging. The call below logs version v1 with a pip-free dependency list (conda_dependencies), a comment, an initial metric and sample input data.

from snowflake.ml.model import task, type_hints
mv = reg.log_model(clf,
                   model_name="my_model",
                   version_name="v1",
                   conda_dependencies=["scikit-learn"],
                   comment="My awesome ML model",
                   metrics={"score": 96},
                   sample_input_data=train_features,
                   task=task.Task.TABULAR_BINARY_CLASSIFICATION)

The registry has limits worth knowing. A model can hold at most 1,000 versions. Each version can have at most 10 methods and at most 100 KB of metadata, metrics included. For warehouse-deployed models, the total model size is capped at 15 GB. Built-in type support covers scikit-learn, XGBoost, LightGBM, Prophet, CatBoost, PyTorch, TensorFlow, Keras, Hugging Face pipelines, Sentence Transformer and MLflow pyfunc models. Models trained with Snowflake ML Functions such as FORECAST do not appear in the registry.

Sources1

2.Metadata: comments, tags and metrics

Once a model exists, the registry gives you three kinds of metadata, and they work differently. A comment (also available as description) is free text. Both models and model versions can have one, and you can set it from Python or with ALTER MODEL. Tags are standard Snowflake object tags applied to the model. They record purpose, algorithm, training data set, lifecycle stage or anything else you choose. Metrics are key-value pairs on a specific *version*. Their values can be any JSON-serializable Python object.

The big practical difference is up-front definition. A tag name has to exist as a schema-level object, created with CREATE TAG, before you can apply it. In Python you then use set_tag, get_tag, show_tags and unset_tag on the model. Metric names need no setup. You set them at log time through metrics= or later with set_metric, read them back with show_metrics, and remove them with delete_metric.

# scalar metric
mv.set_metric("test_accuracy", test_accuracy)

# hierarchical (dictionary) metric
mv.set_metric("evaluation_info", {"dataset_used": "my_dataset", "accuracy": test_accuracy, "f1_score": f1_score})

# multivalent (matrix) metric
mv.set_metric("confusion_matrix", test_confusion_matrix)

Because tags are ordinary Snowflake object tags, the general tagging controls apply to them. ALLOWED_VALUES limits a tag to a fixed list of strings, which suits a lifecycle-stage tag where only a few values make sense. Each tag value can be up to 256 characters long.

CREATE TAG cost_center ALLOWED_VALUES 'finance', 'engineering';

Sources12

3.Querying metadata and tracing versions to their data

Models are Snowflake objects, so they appear in the Information Schema. A single view, INFORMATION_SCHEMA.MODEL_VERSIONS, covers both models and versions. Version information is a superset of model information, so there is no separate MODEL view. Metrics are stored as version metadata, which means you can also write them in SQL with ALTER MODEL ... MODIFY VERSION ... SET METADATA.

ALTER MODEL my_model MODIFY VERSION v1
    SET  ?  = '{"metric": {"accuracy": 0.769}}';

Once every version carries the same metric, you can rank all versions of all models in a schema with a single query. That makes it a convenient way to compare a retrained candidate with the versions already registered.

SELECT
    catalog_name,
    schema_name,
    model_name,
    model_version_name,
    metadata:metric:accuracy AS accuracy,
    comment,
    owner,
    functions,
    created_on,
    last_altered_on
FROM my_database.INFORMATION_SCHEMA.MODEL_VERSIONS
ORDER BY accuracy DESC;

A metric records how well a version performed. It doesn't preserve the data the version was trained on. Snowflake Datasets do that. They are schema-level objects organized into versions, and each version is a materialized, immutable snapshot of the data. One of their documented uses is tracking the lineage used to create an ML model. If you train from a Dataset version and record its name on the model version, for example in a metric such as evaluation_info with a dataset_used key, the training data stays identifiable even after the source table keeps changing.

Sources34

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Tags are set per model version, like metrics, so each version can carry its own tag values.Why is that wrong?

   Tags are attributes of the model object, while metrics belong to individual versions. A tag that stores a version name, such as live_version, is set once on the model and updated as versions change.

   Covered in Metadata: comments, tags and metrics