Gestion des modèles avec Snowflake Model Registry¶

Le Snowflake Model Registry simplifie le processus de transfert d’un modèle de machine learning du développement à la production. Un registre de modèles bien organisé sert de plaque tournante centrale et de source unique pour tous les modèles, leurs métriques et leurs métadonnées. L’enregistrement de votre modèle dans le registre est la première et la plus importante étape de votre parcours Snowflake ML Ops, qui place vos opérations de machine learning sous le contrôle, la sécurité et la gouvernance pour lesquels Snowflake est connu.

Le Snowflake Model Registry est suffisamment flexible pour répondre à une large gamme de cas d’utilisation et scénarios de gestion de modèles ML. Cette rubrique fournit des conseils sur la meilleure façon d’utiliser le registre pour gérer de manière transparente les modèles du développement à la production, notamment :

Comment contrôler l’accès aux modèles afin que le bon groupe d’utilisateurs ou de rôles puisse effectuer diverses opérations.
Comment interroger les métriques et autres métadonnées de tous vos modèles.
Comment gérer le cycle de vie d’un modèle du développement à la production.
Comment déployer une nouvelle version d’un modèle sans aucune modification du code de production.

Gouvernance¶

Parce que les modèles de machine learning sont des objets de première classe dans Snowflake, vous pouvez utiliser toutes les fonctionnalités de gouvernance standard de Snowflake avec eux, y compris le contrôle d’accès basé sur les rôles et Information Schema.

Contrôle d’accès basé sur les rôles¶

Les objets de modèle ont deux privilèges : OWNERSHIP et USAGE.

Privilège	Description
OWNERSHIP	Contrôle total du modèle, y compris la gestion des versions du modèle, l’accès aux artefacts et la mise à jour des métadonnées du modèle. Un seul rôle peut posséder le modèle, mais vous pouvez accorder ce rôle à plusieurs utilisateurs ou à d’autres rôles.
USAGE	Accès en lecture seule au modèle, permettant l’inférence (prédiction) et l’utilisation des commandes SHOW MODELS et SHOW VERSIONS IN MODEL. Les rôles avec seulement USAGE ne peuvent pas accéder au code du modèle, aux poids ni à d’autres artefacts.

Le propriétaire d’un modèle peut accorder l’accès à n’importe quel rôle comme suit :

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Requêtes Information Schema¶

Comme tous les objets Snowflake, les modèles sont représentés dans une vue dans Schéma d’information de Snowflake. La vue des modèles et de leurs versions est INFORMATION_SCHEMA.MODEL_VERSIONS. Les informations sur la version du modèle sont un sur-ensemble des informations relatives aux modèles. Il n’existe donc pas de vue de MODEL séparée.

Grâce à cette vue, vous pouvez interroger le registre lui-même. Par exemple, supposons que vous mainteniez une métrique de précision, en l’ajoutant à chaque version de modèle à l’aide de SQL comme ce qui suit.

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

Copy

Note

Vous pouvez également définir des métriques avec l’API Python du registre.

mv = reg.get_model("my_model").version("v1").set_metric("accuracy", 0.769)

Copy

Après avoir ajouté cette métrique à toutes les versions de vos modèles, vous pouvez utiliser une requête comme celle-ci pour récupérer des informations sur tous les objets du modèle et les répertorier par ordre de précision, de la plus élevée à la plus faible.

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;

Copy

Vous pouvez créer des requêtes plus complexes qui se joignent à d’autres vues Information Schema ou à d’autres tables pour une analyse plus détaillée.

Gestion du cycle de vie du modèle¶

Pour répondre aux divers besoins des petites et grandes entreprises, le Snowflake Model Registry fournit quatre schémas simples, mais puissants, pour gérer le cycle de vie d’un modèle, du développement à la production. Choisissez celui qui vous convient le mieux en fonction de la structure de gouvernance que vous préférez.

Utilisation de la version par défaut
Utilisation d’alias
Utilisation des balises
Utilisation de plusieurs schémas

Utilisation de la version par défaut¶

Les modèles sont versionnés et une version est désignée comme version par défaut. Vous pouvez traiter la version par défaut d’un modèle comme la version de production par convention ; le code de production n’appelle que la version par défaut du modèle.

Dans ce scénario, vous passez une version de modèle à la production simplement en la définissant comme modèle par défaut, peut-être après qu’elle réponde à vos exigences de workflow de notation de modèle ou d’évaluation des performances. C’est le moyen le plus simple de contrôler quelle version d’un modèle est utilisée en production.

Utilisez cette méthode lorsque :

Le propriétaire du modèle a le pouvoir de décider quelle version utiliser en production.
Vous n’avez pas besoin de suivre les étapes du cycle de vie en dehors du développement/de la production.

Configuration initiale¶

Le propriétaire du modèle accorde l’utilisation du modèle à un rôle de production.

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Lorsque le modèle est initialement enregistré, sa seule version est la version par défaut et cette version est prête à être utilisée.

Important

Un modèle doit toujours avoir une version par défaut. Dans ce cadre, vous ne pouvez donc pas désigner un modèle comme n’ayant pas encore de version de production. Si vous devez empêcher l’utilisation de modèles avant qu’ils ne soient prêts, vous pouvez enregistrer une version initiale qui génère immédiatement une erreur. Cette version restera la version par défaut jusqu’à ce qu’une autre version soit prête.

Passer un modèle en production¶

Lorsqu’une nouvelle version, appelée new_version dans le SQL ci-dessous, a effacé la barre de qualité, désignez-la comme valeur par défaut pour la marquer comme version de production.

ALTER MODEL my_model SET DEFAULT_VERSION = new_version;

Copy

Utilisation du modèle en production¶

En production, appelez directement le modèle pour utiliser la version par défaut.

SELECT my_model!predict(...) ... ;

Copy

Développement et tests¶

Pour utiliser une version préliminaire, appelez la version du modèle souhaité par son nom :

WITH my_version AS MODEL my_model VERSION new_version
    SELECT my_version!predict(...) ...;

Copy

Utilisation d’alias¶

De nombreuses organisations gèrent les cycles de vie des modèles à l’aide de plusieurs zones de préparation, telles que le développement, la mise en zone de préparation, la production et l’obsolescence. Les versions de modèles peuvent avoir des alias, des étiquettes ou des balises définies par l’utilisateur que vous pouvez attacher exclusivement à l’une des versions d’un modèle. Vous pouvez utiliser des alias pour représenter les étapes du cycle de vie utilisées par votre organisation.

Utilisez cette méthode lorsque :

Le propriétaire du modèle a le pouvoir de prendre des décisions concernant les étapes du cycle de vie du modèle.
Vous souhaitez suivre plusieurs étapes du cycle de vie, pas seulement le développement/la production.

L’exemple ci-dessous utilise deux étapes de préproduction (alpha et beta) et une étape de production (production).

Configuration initiale¶

Le propriétaire du modèle accorde l’utilisation du modèle à un rôle de production.

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Passage de la version initiale du modèle¶

Lorsque vous enregistrez le modèle, définissez l’alias production pour pointer vers la première version, ici nommée v1.

ALTER MODEL my_model VERSION v1 SET ALIAS = production;

Copy

Gestion des versions de pré-production¶

Au départ, le modèle n’a pas de version désignée alpha ou beta. Lorsque vous ajoutez une nouvelle version, désignez-la initialement alpha.

ALTER MODEL my_model VERSION v2 SET ALIAS = alpha;

Copy

Plus tard, pour passer la nouvelle version à beta :

ALTER MODEL my_model VERSION v2 UNSET ALIAS;
ALTER MODEL my_model VERSION v2 SET ALIAS = beta;

Copy

Promouvoir les versions ultérieures du modèle¶

Lorsqu’une nouvelle version d’un modèle a passé le test, supprimez l’alias production de la version de production actuelle, ici v1, et appliquez-la à la nouvelle version, ici v2.

ALTER MODEL my_model VERSION v1 UNSET ALIAS;
ALTER MODEL my_model VERSION v2 UNSET ALIAS;
ALTER MODEL my_model VERSION v2 SET ALIAS = production;

Copy

Utilisation du modèle en production¶

Appelez la version de production du modèle via l’alias production.

WITH my_version AS MODEL my_model VERSION production
    SELECT my_version!predict(...) ...;

Copy

Développement et tests¶

Pour utiliser les versions préliminaires, appelez le modèle via l’alias alpha ou beta à la place. Par exemple, pour tester la version alpha :

WITH my_version AS MODEL my_model VERSION alpha
    SELECT my_version!predict(...) ...;

Copy

Utilisation des balises¶

Les schémas de gestion du cycle de vie de la version par défaut et de l’alias supposent que le propriétaire du modèle puisse gérer les cycles de vie du modèle. Cependant, dans de nombreuses organisations, cette responsabilité incombe à un rôle d’ingénierie de production distinct, et les scientifiques des données n’ont pas l’autorité nécessaire pour passer les versions de modèles en production. Étant donné que les modèles sont des objets Snowflake de première classe, vous pouvez leur appliquer des balises à cet effet. Les balises sont sécurisables par un contrôle d’accès basé sur les rôles et conviennent à cette séparation des responsabilités.

Utilisez cette méthode lorsque :

Un rôle autre que le propriétaire du modèle détermine quand promouvoir une version de modèle d’une étape du cycle de vie à l’autre.

Configuration initiale¶

Le propriétaire du modèle accorde l’utilisation du modèle à un rôle de production.

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Le rôle de production nécessite également la capacité de voir les balises sur un modèle et de lire les valeurs des balises. Ici, le premier est atteint en accordant le privilège APPLY TAG ON ACCOUNT plus large du rôle. Ce dernier est obtenu en accordant USAGE sur le schéma.

USE ROLE ACCOUNTADMIN;
GRANT APPLY TAG ON ACCOUNT ON MODEL my_model TO ROLE prod_role;
GRANT USAGE ON SCHEMA model_database.model_schema TO ROLE prod_role;

Copy

Pour créer des balises, un rôle a besoin du privilège CREATE TAG ON SCHEMA.

Créez une balise nommée live_version dans un schéma appartenant à prod_role pour contenir le nom de la version de production actuelle du modèle.

USE ROLE prod_role;
USE SCHEMA prod_db.prod_schema;

CREATE TAG live_version;

Copy

Note

Ici, la balise est créée dans le schéma de production, car elle est gérée par le rôle de production. Lorsque vous l’utilisez dans d’autres schémas, utilisez son nom complet.

Passage de la version initiale du modèle¶

Pour rendre un modèle disponible en production, appliquez la balise live_version au modèle, en spécifiant la version de production initiale comme valeur de la balise.

USE ROLE prod_role;
USE SCHEMA prod_db.prod_schema;

ALTER MODEL model_database.model_schema.my_model
    SET TAG live_version = 'V1';

Copy

Promouvoir les versions ultérieures du modèle¶

Lorsqu’une nouvelle version du modèle est prête, mettez à jour la balise live_version avec le nom de cette version.

USE ROLE prod_role;

ALTER MODEL model_database.model_schema.my_model
    SET TAG prod_db.prod_schema.live_version = 'V2';

Copy

Utilisation du modèle en production¶

Appelez la version de production du modèle en récupérant la valeur de la balise live_version du modèle en utilisant SYSTEM$GET_TAG, puis en appelant la version du modèle qui porte ce nom. Le SQL suivant montre ce processus en deux étapes.

Note

Le domaine SQL des modèles, à utiliser avec SYSTEM$GET_TAG, est MODULE.

-- get production model version from live_version tag
SET live_version = (SELECT
    SYSTEM$GET_TAG('prod_db.prod_schema.live_version', 'my_model', 'MODULE'));

-- call that version
WITH my_version AS MODEL my_model VERSION IDENTIFIER($live_version)
    SELECT my_version!predict(...) ... ;

Copy

Développement et tests¶

Pour les versions préliminaires, vous pouvez utiliser la même méthode avec des balises supplémentaires (telles que alpha_version et beta_version). Dans de nombreuses organisations, cependant, seule la promotion vers la production est gérée par l’ingénierie, et il est raisonnable de gérer les étapes de pré-lancement en utilisant la méthode d”alias plus simple.

Utilisation de plusieurs schémas¶

Vous pouvez utiliser plusieurs schémas pour gérer les étapes du cycle de vie. Avec cette approche, le code appelle exclusivement des modèles dans un schéma de production désigné, qui contient uniquement les modèles utilisés en production. Les modèles des autres étapes sont stockés ailleurs. Lorsqu’une version de modèle est prête pour la production, elle est copiée dans le schéma de production. Étant donné que les modèles de production sont des objets distincts dotés de leur propre contrôle d’accès, vous pouvez les protéger contre toute modification accidentelle tandis que les développeurs de modèles ont toute liberté pour gérer les modèles en phase de développement.

Utilisez cette méthode lorsque :

Un rôle autre que celui de propriétaire du modèle passe les modèles en production.
Vous souhaitez une séparation forte entre les environnements de développement et de production.

Configuration initiale¶

Créez un rôle (appelé, par exemple, ml_admin) qui a accès aux schémas de développement et de production. Dans cet exemple, l’accès à ces deux environnements est encapsulé dans des rôles existants nommés model_owner et prod_role, qui contiennent des privilèges tels que USAGE et CREATE MODEL sur les schémas de développement et de production, respectivement. Le nouveau rôle ml_admin obtient les privilèges dont il a besoin en se voyant accorder ces rôles.

USE ROLE ACCOUNTADMIN;
CREATE ROLE ml_admin;

USE ROLE model_owner;
GRANT ROLE model_owner TO ROLE ml_admin;

USE ROLE prod_role;
GRANT ROLE prod_role TO ROLE ml_admin;

Copy

Passage de la version initiale du modèle¶

Utilisez le rôle ml_admin pour copier les versions du modèle du schéma de développement vers le schéma de production, en effectuant la copie initiale à l’aide de CREATE MODEL … FROM MODEL pour copier uniquement la version souhaitée. Vous pouvez utiliser le même identificateur pour la version de production ou établir un schéma de numérotation différent pour la production. Ici, la version de développement V12 devient version de production V1.

USE ROLE ml_admin;

CREATE MODEL prod_db.prod_schema.prod_model WITH VERSION V1
    FROM MODEL dev_db.dev_sch.dev_model VERSION V12;

Copy

Après avoir créé la version de production initiale du modèle, accordez USAGE et tout autre privilège nécessaire aux rôles qui l’utiliseront en production.

USE ROLE ml_admin;

GRANT USAGE ON MODEL my_model TO ROLE prod_role;

Copy

Promouvoir les versions ultérieures du modèle¶

Lorsqu’une nouvelle version du modèle est prête pour la production, copiez uniquement la nouvelle version du modèle dans l’environnement de production. Ici, la version de développement V24 devient version de production V2. V2 est alors définie comme version par défaut.

USE ROLE ml_admin;

ALTER MODEL prod_db.prod_schema.prod_model ADD VERSION V2
    FROM MODEL dev_db.dev_schema.dev_model VERSION V24;

ALTER MODEL prod_db.prod_schema.prod_model
    SET DEFAULT_VERSION = V2;

Copy

Astuce

C’est une bonne idée de conserver les versions de production précédentes au cas où vous auriez besoin de revenir en arrière, ce que vous pouvez faire en définissant la version par défaut sur une version précédente, comme indiqué ci-dessous.

ALTER MODEL prod_db.prod_schema.prod_model SET DEFAULT_VERSION = V1;

Copy

Établissez une politique concernant le nombre d’anciennes versions à conserver et la durée de leur conservation.

Utilisation du modèle en production¶

En production, appelez la version par défaut du modèle.

SELECT prod_model!predict(...) ... ;

Copy

Développement et tests¶

Pour gérer les versions préliminaires, vous pouvez utiliser des schémas supplémentaires, en passant les versions d’une zone de préparation à l’autre en les copiant d’un schéma à l’autre. Si le propriétaire du modèle peut gérer les étapes de pré-production, vous pouvez utiliser une méthode plus simple telle que des alias pour gérer ces versions. L’utilisation de schémas supplémentaires peut toujours être utile pour séparer plusieurs environnements de pré-production, tels que le développement et les tests, lorsqu’une ou plusieurs de ces étapes sont gérées par un autre rôle.