Aller au contenu principal
Dernière mise à jour le

Démarrez avec MLflow 3 pour les modèles

remarque

Cet article se concentre sur les fonctionnalités de MLflow 3 pour les modèles de machine learning traditionnel et de deep learning. MLflow 3 offre également des fonctionnalités complètes pour le développement d'applications GenAI, y compris le traçage, l'évaluation et la collecte de retours humains. Consultez la documentation MLflow 3 pour GenAI pour plus de détails.

Cet article vous initie à MLflow 3 pour développer des Modèles de machine learning. Il décrit comment installer MLflow 3 pour les modèles et comprend plusieurs Notebooks de démonstration pour start. Il comprend également des liens vers des pages qui couvrent plus en détail les nouvelles fonctionnalités de MLflow 3 pour les modèles.

Qu'est-ce que MLflow 3 pour les modèles ?​

MLflow 3 pour les modèles sur Databricks offre un suivi de pointe des expérimentations, l'évaluation des performances et la gestion de la production pour les modèles de machine learning. MLflow 3 introduit de nouvelles fonctionnalités importantes tout en préservant les concepts de suivi de base, rendant la migration de MLflow 2.x rapide et simple.

Qu'est-ce que MLflow 3 pour GenAI ?​

Au-delà de MLflow 3 pour les modèles, MLflow 3 pour GenAI introduit une grande variété de nouvelles fonctionnalités et d'améliorations pour le développement d'applications d'agents et de GenAI. Pour un aperçu complet, consultez MLflow 3 pour GenAI.

Les fonctionnalités principales de MLflow 3 pour GenAI incluent :

  • Traçage et observabilité — Observabilité de bout en bout pour les applications GenAI avec instrumentation automatique pour plus de 20 frameworks, y compris OpenAI, LangChain, LlamaIndex et Anthropic
  • Évaluation et monitoring - Capacités complètes d’évaluation GenAI pour mesurer et améliorer la qualité du développement à la production. Comprend des juges LLM intégrés, des juges personnalisables, la gestion des datasets d'évaluation et le monitoring en temps réel.
  • Collecte de feedback humain – Interface utilisateur de révision personnalisable pour la collecte de feedback d'experts du domaine et le test interactif d'agents, avec des sessions d'étiquetage structurées pour l'organisation et le suivi de la progression de la révision
  • ** Prompt Registry ** — Versioning, gestion et tests A/B centralisés des prompts avec l'intégration Unity Catalog

En quoi MLflow 3 pour les modèles est-il différent de MLflow 2​

MLflow 3 pour les modèles sur Databricks vous permet de :

  • Suivez et analysez de manière centralisée les performances de vos modèles dans tous les environnements, des query interactives dans un Notebook de développement aux déploiements de service par batch ou en temps réel en production.

Interface utilisateur de suivi de modèles.

  • Affichez et accédez aux métriques et paramètres du modèle depuis la page de version du modèle dans Unity Catalog et depuis l'API REST, à travers tous les workspaces et expérimentations.

Page de version du modèle dans Unity Catalog affichant les métriques de plusieurs exécutions.

  • Orchestrez les workflows d'évaluation et de déploiement à l'aide d'Unity Catalog et accédez à des logs d'état complets pour chaque version de votre modèle.

Un Job de déploiement complexe qui inclut un déploiement par étapes et la collecte de métriques.

Ces capacités simplifient et rationalisent le développement, l’évaluation et le déploiement en production des modèles de machine learning.

Modèles enregistrés​

Une grande partie de la nouvelle fonctionnalité de MLflow 3 découle du nouveau concept d'un LoggedModel. Pour les modèles d'apprentissage profond et de modèle de machine learning traditionnels, LoggedModels élève le concept de modèle produit par une exécution d'entraînement, l'établissant comme un objet dédié pour suivre le cycle de vie du modèle à travers différentes exécutions d'entraînement et d'évaluation.

LoggedModels capturer les métriques, les paramètres et les traces à travers les phases de développement (formation et évaluation) et les environnements (développement, test et production). Lorsqu'un LoggedModel est promu dans Unity Catalog en tant que version de modèle, toutes les données de performance du LoggedModel original deviennent visibles sur la page de la version de modèle UC, offrant une visibilité sur tous les workspaces et expérimentations. Pour plus de détails, consultez Suivre et comparer les modèles à l'aide des modèles enregistrés MLflow.

Jobs de déploiement​

MLflow 3 introduit également le concept d'un Job de déploiement. Les jobs de déploiement utilisent les Lakeflow Jobs pour gérer le cycle de vie du modèle, y compris des étapes telles que l'évaluation, l'approbation et le déploiement. Ces workflows de modèle sont régis par Unity Catalog, et tous les événements sont enregistrés dans un journal d'activité qui est disponible sur la page de version du modèle dans Unity Catalog.

Migration depuis MLflow 2.x​

Bien qu'il existe de nombreuses nouvelles fonctionnalités dans MLflow 3, les concepts fondamentaux des expérimentations et des runs, ainsi que leurs métadonnées telles que les paramètres, les tags et les métriques, restent les mêmes. La migration de MLflow 2.x vers 3.0 est très simple et ne devrait nécessiter que des modifications de code minimes dans la plupart des cas. Cette section met en évidence certaines différences clés de MLflow 2.x et ce dont vous devez être conscient pour une transition transparente.

Enregistrement des modèles​

Lors de l’enregistrement des modèles en 2.x, le parameter artifact_path est utilisé.

with mlflow.start_run():
    mlflow.pyfunc.log_model(
        artifact_path="model",
        python_model=python_model,
        ...
    )

Dans MLflow 3, utilisez name à la place, ce qui permet au modèle d'être recherché ultérieurement par son nom. Le paramètre artifact_path est toujours pris en charge mais a été déprécié. De plus, MLflow n'exige plus qu'une exécution soit active lors de l'enregistrement d'un modèle, car les modèles sont devenus des citoyens de première classe dans MLflow 3. Vous pouvez directement enregistrer un modèle sans démarrer une exécution au préalable.

mlflow.pyfunc.log_model(
    name="model",
    python_model=python_model,
    ...
)

Artefacts de modèle​

Dans MLflow 2.x, les artefacts de modèle sont stockés en tant qu’artefacts d’exécution sous le chemin d’artefact de l’exécution. Dans MLflow 3, les artefacts de modèle sont maintenant stockés à un emplacement différent, sous le chemin d'artefact du modèle.

# MLflow 2.x
experiments/
  └── <experiment_id>/
    └── <run_id>/
      └── artifacts/
        └── ... # model artifacts are stored here
# MLflow 3
experiments/
  └── <experiment_id>/
    └── models/
      └── <model_id>/
        └── artifacts/
          └── ... # model artifacts are stored here

Il est recommandé de charger les modèles avec mlflow.<model-flavor>.load_model en utilisant l'URI du modèle renvoyé par mlflow.<model-flavor>.log_model pour éviter tout problème. Cet URI de modèle est au format models:/<model_id> (plutôt qu’au format runs:/<run_id>/<artifact_path> comme dans MLflow 2.x) et peut également être construit manuellement si seul l’ID de modèle est disponible.

Registre des modèles​

Dans MLflow 3, l'URI de registre par default est désormais databricks-uc, ce qui signifie que le MLflow Model Registry dans Unity Catalog sera utilisé (voir Gérer le cycle de vie des modèles dans Unity Catalog pour plus de détails). Les noms des modèles enregistrés dans Unity Catalog sont de la forme <catalog>.<schema>.<model>. Lors de l'appel d'APIs qui nécessitent un nom de modèle enregistré, tel que mlflow.register_model, ce nom complet à trois niveaux est utilisé.

Pour les Workspaces ayant Unity Catalog activé et dont le default catalogue se trouve dans Unity Catalog, vous pouvez également utiliser <model> comme nom et le catalogue et le schéma par défaut seront déduits (aucun changement de comportement par rapport à MLflow 2.x). Si votre Workspace a Unity Catalog activé mais que son catalogue par default n'est pas configuré pour être dans Unity Catalog, vous devrez spécifier le nom complet à trois niveaux.

Databricks recommande d'utiliser le MLflow Model Registry dans Unity Catalog pour gérer le cycle de vie de vos modèles.

Si vous souhaitez continuer à utiliser le Workspace Model Registry (hérité), utilisez l'une des méthodes suivantes pour définir l'URI du registre sur databricks:

Autres modifications importantes​

  • Les clients MLflow 3 peuvent charger toutes les exécutions, tous les modèles et toutes les traces Logs avec les clients MLflow 2.x. Toutefois, l’inverse n’est pas nécessairement vrai, de sorte que les modèles et les traces Logs avec les clients MLflow 3 peuvent ne pas pouvoir être chargés avec des versions clientes 2.x plus anciennes.
  • L'API mlflow.evaluate a été dépréciée. Pour les modèles de ML traditionnels ou de deep learning, utilisez mlflow.models.evaluate qui maintient une compatibilité totale avec l'API mlflow.evaluate d'origine. Pour les LLM ou les applications GenAI, utilisez plutôt l'API mlflow.genai.evaluate.
  • L'attribut run_uuid a été supprimé de l'objet RunInfo. Utilisez run_id à la place dans votre code.

Installer MLflow 3​

Pour utiliser MLflow 3, vous devez mettre à jour le package pour utiliser la version correcte (>= 3.0). Les lignes de code suivantes doivent être exécutées chaque fois qu'un Notebook est exécuté :

Python
%pip install mlflow>=3.0 --upgrade
dbutils.library.restartPython()

Exemples de Notebooks​

Les pages suivantes illustrent le workflow de suivi des modèles MLflow 3 pour le ML traditionnel et l'apprentissage profond. Chaque page comprend un exemple de notebook.

Limitation​

Bien que la journalisation des modèles Spark (mlflow.spark.log_model) continue de fonctionner dans MLflow 3, elle n'utilise pas le nouveau concept LoggedModel. Les modèles enregistrés à l'aide de la journalisation des modèles Spark continuent d'utiliser les exécutions et les artefacts d'exécution MLflow 2.x.

Ressources supplémentaires​

Pour en savoir plus sur les nouvelles fonctionnalités de MLflow 3, consultez les articles suivants :

Sur cette page