Partager via


Prise en main de MLflow 3 pour les modèles

Note

Cet article se concentre sur les fonctionnalités MLflow 3 pour les modèles Machine Learning et Deep Learning traditionnels. MLflow 3 offre également des fonctionnalités complètes pour le développement d’applications GenAI, notamment le suivi, l’évaluation et la collecte de commentaires humains. Pour plus d’informations, consultez MLflow 3 pour GenAI .

Cet article vous permet de commencer à utiliser MLflow 3 pour développer des modèles Machine Learning. Il décrit comment installer MLflow 3 pour les modèles et inclut plusieurs notebooks de démonstration pour commencer. Il inclut également des liens vers des pages qui couvrent les nouvelles fonctionnalités de MLflow 3 pour les modèles plus en détail.

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

MLflow 3 pour les modèles sur Azure Databricks fournit un suivi des expériences de pointe, une évaluation des performances et une gestion de production pour les modèles Machine Learning. MLflow 3 introduit de nouvelles fonctionnalités significatives tout en préservant les concepts de suivi de base, ce qui rend la migration à partir 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 améliorations pour le développement d’applications Agent et GenAI. Pour obtenir une vue d’ensemble complète, consultez MLflow 3 pour GenAI.

Les principales fonctionnalités de MLflow 3 pour GenAI sont les suivantes :

  • Suivi et observabilité - Visibilité de bout en bout pour les applications GenAI avec une instrumentation automatique pour plus de 20 cadres, notamment OpenAI, LangChain, LlamaIndex, et Anthropic.
  • Évaluation et surveillance : capacités d’évaluation GenAI complètes pour mesurer et améliorer la qualité du développement à la production. Inclut les juges LLM intégrés, les juges personnalisables, la gestion des jeux de données d’évaluation et la surveillance en temps réel.
  • Collecte de commentaires humains - Interface utilisateur de révision personnalisable pour collecter des commentaires d’experts du domaine et tester de manière interactive des agents, avec des sessions d’étiquetage structurées pour organiser et suivre la progression de l’examen
  • Registre de demandes : centralisation du contrôle de version des demandes, de la gestion et des tests A/B avec intégration du catalogue Unity
  • Gestion des versions des applications et des agents GenAI, y compris le suivi des révisions de code, des paramètres, des évaluations de qualité, des métriques de performances et des traces associées à l’application ou à l’agent.

Comment MLflow 3 est-il différent de MLflow 2 concernant les modèles ?

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

  • Suivez et analysez centralement les performances de vos modèles dans tous les environnements, à partir de requêtes interactives dans un notebook de développement via des batches de production ou des déploiements de service en temps réel.

Interface utilisateur de suivi des modèles.

  • Affichez et accédez aux métriques et paramètres du modèle à partir de la page de version du modèle dans le catalogue Unity et à partir de l’API REST, dans tous les espaces de travail et expériences.

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

  • Orchestrez les flux de travail d’évaluation et de déploiement à l’aide du catalogue Unity et accédez aux journaux d’état complets pour chaque version de votre modèle.

Tâche de déploiement complexe qui inclut le déploiement intermédiaire et la collecte de métriques.

Ces fonctionnalités simplifient et rationalisent le développement, l'évaluation et le déploiement en production des modèles d'apprentissage automatique.

Modèles journalisés

La plupart des nouvelles fonctionnalités de MLflow 3 dérivent du nouveau concept d’un LoggedModel. Pour les modèles d’apprentissage profond et de Machine Learning traditionnels, LoggedModels élève le concept d’un modèle produit par une exécution d’entraînement, en l’établissant en tant qu’objet dédié pour suivre le cycle de vie du modèle dans différentes exécutions d’entraînement et d’évaluation.

LoggedModels capturer des métriques, des paramètres et des traces entre les phases de développement (formation et évaluation) et entre les environnements (développement, préproduction et production). Lorsqu'une LoggedModel est promue dans le catalogue Unity en tant que version de modèle, toutes les données de performance de l’original LoggedModel deviennent visibles sur la page de la Version du modèle UC. Cela offre une visibilité à travers tous les espaces de travail et expériences. Pour plus d’informations, consultez Suivre et comparer des modèles à l’aide de modèles journalisés MLflow.

Travaux de déploiement

MLflow 3 introduit également le concept d’un travail de déploiement. Les travaux de déploiement utilisent Lakeflow Jobs pour gérer le cycle de vie du modèle, notamment les étapes telles que l’évaluation, l’approbation et le déploiement. Ces flux de travail de modèle sont régis par le catalogue Unity, et tous les événements sont enregistrés dans un journal d’activité disponible dans la page de version du modèle dans le catalogue Unity.

Migration à partir de MLflow 2.x

Bien qu’il existe de nombreuses nouvelles fonctionnalités dans MLflow 3, les concepts fondamentaux des expériences et des exécutions, ainsi que leurs métadonnées telles que les paramètres, les balises et les métriques, restent les mêmes. La migration de MLflow 2.x vers la version 3.0 est très simple et doit nécessiter des modifications de code minimales dans la plupart des cas. Cette section met en évidence certaines différences clés de MLflow 2.x et de ce que vous devez connaître pour une transition transparente.

Modèles de journalisation

Lors de la journalisation des modèles dans la version 2.x, le artifact_path paramètre est utilisé.

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

Dans MLflow 3, utilisez name plutôt, ce qui permet au modèle d’être recherché ultérieurement par nom. Le artifact_path paramètre est toujours pris en charge, mais a été déconseillé. De plus, MLflow n’a plus besoin d’une exécution active lors de la journalisation d’un modèle, car les modèles sont devenus des citoyens de première classe dans MLflow 3. Vous pouvez enregistrer directement un modèle sans commencer une exécution.

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 de la session sous le chemin d'accès de cette dernière. Dans MLflow 3, les artefacts de modèle sont désormais stockés dans un emplacement différent, sous le chemin d'accès des artefacts 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 des modèles avec mlflow.<model-flavor>.load_model en utilisant l'URI de modèle retourné par mlflow.<model-flavor>.log_model pour éviter tout problème. Cet URI de modèle est au format models:/<model_id> (plutôt que runs:/<run_id>/<artifact_path> dans MLflow 2.x) et peut également être construit manuellement si seul l’ID de modèle est disponible.

Registre de modèles

Dans MLflow 3, l’URI de Registre par défaut est maintenant databricks-uc, ce qui signifie que le registre de modèles MLflow dans le catalogue Unity sera utilisé (consultez Gérer le cycle de vie du modèle dans le catalogue Unity pour plus d’informations). Les noms des modèles inscrits dans le catalogue Unity sont de la forme <catalog>.<schema>.<model>. Lors de l’appel d’API qui nécessitent un nom de modèle inscrit, par exemple, mlflow.register_model, ce nom complet de trois niveaux est utilisé.

Pour les espaces de travail sur lesquels Unity Catalog est activé et dont le catalogue par défaut se trouve dans le catalogue Unity, vous pouvez également utiliser <model> comme nom et le catalogue et le schéma par défaut seront déduits (aucune modification du comportement de MLflow 2.x). Si le catalogue Unity est activé pour votre espace de travail, mais que son catalogue par défaut n’est pas configuré pour être dans le catalogue Unity, vous devez spécifier le nom complet de trois niveaux.

Databricks recommande d’utiliser le registre de modèles MLflow dans le catalogue Unity pour gérer le cycle de vie de vos modèles.

Si vous souhaitez continuer à utiliser le Registre de modèles d’espace de travail (hérité), utilisez l’une des méthodes suivantes pour définir l’URI databricksdu Registre sur :

Autres modifications importantes

  • Les clients MLflow 3 peuvent charger toutes les exécutions, modèles et traces journalisés avec les clients MLflow 2.x. Toutefois, l’inverse n’est pas nécessairement vrai, de sorte que les modèles et les traces journalisés avec les clients MLflow 3 ne peuvent pas être chargés avec les versions antérieures du client 2.x.
  • L’API mlflow.evaluate a été déconseillée. Pour les modèles ML ou Deep Learning traditionnels, utilisez-les mlflow.models.evaluate pour assurer une compatibilité totale avec l’API d’origine mlflow.evaluate . Pour les applications LLMs ou GenAI, utilisez plutôt l’API mlflow.genai.evaluate .
  • L’attribut run_uuid a été supprimé de l’objet RunInfo . Utilisez run_id plutôt 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é :

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

Exemples de notebooks

Les pages suivantes illustrent le flux de travail de suivi de modèle MLflow 3 pour le ml traditionnel et le deep learning. Chaque page inclut un exemple de bloc-notes.

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 LoggedModel concept. Les modèles enregistrés à l’aide de la journalisation des modèles Spark continuent d’utiliser les exécutions MLflow 2.x et les artefacts d’exécution.

Étapes suivantes

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