Modèles de déploiement de modèles
Cet article décrit deux schémas courants pour déplacer les artefacts ML par les étapes de staging et en production. La nature asynchrone des modifications apportées aux modèles et au code signifie qu'il existe plusieurs modèles possibles qu'un processus de développement ML pourrait suivre.
Les modèles sont créés par le code, mais les artefacts de modèle résultants et le code qui les a créés peuvent fonctionner de manière asynchrone. C’est-à-dire que les nouvelles versions de modèle et les modifications de code pourraient ne pas se produire simultanément. Par exemple, considérez les scénarios suivants :
- Pour détecter les transactions frauduleuses, vous développez un pipeline de ML qui réentraîne un modèle chaque semaine. Le code peut ne pas changer très souvent, mais le modèle peut être réentraîné chaque semaine pour intégrer de nouvelles données.
- Vous pourriez créer un grand réseau de neurones profonds pour classifier des documents. Dans ce cas, l'entraînement du modèle consomme beaucoup de ressources de calcul et prend beaucoup de temps, et son réentraînement n'aura probablement lieu qu'occasionnellement. Cependant, le code qui déploie, sert et surveille ce modèle peut être mis à jour sans réentraîner le modèle.
Les deux modèles diffèrent selon que l' artefact de modèle ou le code d'entraînement qui produit l'artefact de modèle est promu en production.
Déployer le code (recommandé)
Dans la plupart des situations, Databricks recommande l'approche « deploy code ». Cette approche est intégrée au workflow MLOps recommandé.
Dans ce modèle, le code d'entraînement des modèles est développé dans l'environnement de développement. Le même code passe en pré-production, puis en production. Le modèle est entraîné dans chaque environnement : initialement dans l'environnement de développement dans le cadre du développement du modèle, en pré-production (sur un sous-ensemble limité de données) dans le cadre des tests d'intégration, et dans l'environnement de production (sur l'ensemble des données de production) pour produire le modèle final.
Avantages :
- Dans les organisations où l'accès aux données de production est restreint, ce modèle permet d'entraîner le modèle sur des données de production dans l'environnement de production.
- Le réentraînement automatisé des modèles est plus sûr, car le code d’entraînement est examiné, testé et approuvé pour la production.
- Le code de support suit le même modèle que le code d'entraînement de modèle. Les deux passent par des tests d'intégration en préproduction.
Inconvénients :
- La courbe d'apprentissage pour les data scientists, afin de transférer du code à des collaborateurs, peut être abrupte. Les Template de projet prédéfinis et les workflows sont utiles.
De même, les data scientists doivent pouvoir examiner les résultats d’entraînement de l’environnement de production, car ils possèdent les connaissances nécessaires pour identifier et corriger les problèmes spécifiques au ML.
Si votre situation exige que le modèle soit entraîné en pré-production sur l'ensemble du dataset de production, vous pouvez utiliser une approche hybride en déployant du code en pré-production, en entraînant le modèle, puis en le déployant en production. Cette approche permet d'économiser les coûts de formation en production, mais ajoute un coût d'opération supplémentaire en pré-production.
Déployer des modèles
Dans ce modèle, l'artefact du modèle est généré par un code d'entraînement dans l'environnement de développement. L'artefact est ensuite testé dans l'environnement de staging avant d'être déployé en production.
Considérez cette option lorsque une ou plusieurs des conditions suivantes s'appliquent :
- Le Model Training est très coûteux ou difficile à reproduire.
- Tout le travail est effectué dans un seul Workspace Databricks.
- Vous ne travaillez pas avec des dépôts externes ou un processus CI/CD.
Avantages :
- Un transfert plus simple pour les data scientists
- Lorsque l’entraînement des modèles est coûteux, il ne nécessite qu’un seul entraînement du modèle.
Inconvénients :
- Si les données de production ne sont pas accessibles depuis l'environnement de développement (ce qui peut être vrai pour des raisons de sécurité), cette architecture peut ne pas être viable.
- Le réentraînement automatisé des modèles est délicat dans ce schéma. Vous pourriez automatiser le réentraînement dans l'environnement de développement, mais l'équipe responsable du déploiement du modèle en production pourrait ne pas accepter le modèle résultant comme étant prêt pour la production.
- Le code de support, tel que les pipelines utilisés pour l'ingénierie des fonctionnalités, l'inférence et le monitoring, doit être déployé en production séparément.
Généralement, un environnement (de développement, de pré-production ou de production) correspond à un catalogue dans Unity Catalog. Pour plus de détails sur la façon de mettre en œuvre ce modèle, consultez le guide de mise à niveau.
Le diagramme ci-dessous compare le cycle de vie du code pour les modèles de déploiement ci-dessus dans les différents environnements d'exécution.
L'environnement affiché dans le diagramme est l'environnement final dans lequel une étape est exécutée. Par exemple, dans le modèle de déploiement de modèles, les tests unitaires et d'intégration finaux sont effectués dans l'environnement de développement. Dans le modèle de déploiement de code, les tests unitaires et les tests d'intégration sont exécutés dans les environnements de développement, et les tests unitaires et d'intégration finaux sont effectués dans l'environnement de staging.
