Dipendenze del modello di log

Questo articolo contiene informazioni su come registrare un modello e le relative dipendenze come artefatti del modello, in modo che siano disponibili nell'ambiente per attività di produzione come la gestione del modello.

Registrare le dipendenze del modello di pacchetto Python

MLflow include il supporto nativo per alcune librerie di Python ML, in cui MLflow può registrare in modo affidabile le dipendenze per i modelli che utilizzano queste librerie. Vedere le versioni predefinite del modello.

Ad esempio, MLflow supporta scikit-learn nel modulo mlflow.sklearn e il comando mlflow.sklearn.log_model registra la versione sklearn. Lo stesso vale per la registrazione automatica con tali librerie di ML. Per altri esempi, vedere il repository github per MLflow.

Nota

Per abilitare la registrazione di traccia per carichi di lavoro generativi di intelligenza artificiale, MLflow supporta l'assegnazione automatica OpenAI.

Per le librerie di ML che possono essere installate con pip install PACKAGE_NAME==VERSION, ma non dispongono di versioni predefinite del modello MLflow, è possibile registrare tali pacchetti con il metodo mlflow.pyfunc.log_model. Assicurarsi di registrare i requisiti con la versione esatta della libreria, ad esempio f"nltk=={nltk.__version__}" anziché solo nltk.

mlflow.pyfunc.log_model supporta la registrazione per:

• Librerie pubbliche e personalizzate incluse in pacchetto come file Python egg o Python wheel.
• Pacchetti pubblici in PyPI e pacchetti ospitati privatamente nel proprio server PyPI.

Con mlflow.pyfunc.log_model, MLflow tenta di dedurre automaticamente le dipendenze. MLflow deduce le dipendenze usando mlflow.models.infer_pip_requirements e le registra in un file requirements.txt come artefatto del modello.

Nelle versioni precedenti, MLflow a volte non identifica automaticamente tutti i requisiti python, soprattutto se la libreria non è un modello predefinito. In questi casi, è possibile specificare dipendenze aggiuntive con il parametro extra_pip_requirements nel comando log_model. Vedere un esempio di utilizzo del parametro extra_pip_requirements.

Importante

È anche possibile sovrascrivere l'intera serie di requisiti con i parametri conda_env e pip_requirements, ma in genere questa operazione è sconsigliata perché sovrascrive le dipendenze che MLflow preleva automaticamente. Vedere un esempio di come usare il parametro pip_requirements per sovrascrivere i requisiti.

Registrazione dei modelli personalizzata

Per gli scenari in cui è necessaria una registrazione dei modelli più personalizzata, è possibile:

• Scrivere un modello Python personalizzato. In questo modo è possibile creare sottoclassi mlflow.pyfunc.PythonModel per personalizzare l'inizializzazione e la previsione. Questo approccio è ideale per la personalizzazione dei modelli unicamente Python.
  • Per un esempio semplice, vedere l'esempio di aggiunta di un modello N.
  • Per un esempio più complesso, vedere l'esempio di modello XGBoost personalizzato.
• Scrivere una versione personalizzata. In questo scenario, è possibile personalizzare la registrazione al di là della versione generica pyfunc, ma in tal caso è necessario implementare più operazioni.

Codice Python personalizzato

È possibile che si disponga di dipendenze del codice Python che non possono essere installate usando il comando %pip install, ad esempio uno o più file .py.

Quando si registra un modello, è possibile indicare a MLflow che il modello può individuare tali dipendenze in un percorso specificato usando il parametro code_path in mlflow.pyfunc.log_model. MLflow archivia tutti i file o le directory passate usando code_path come artefatti insieme al modello in una directory di codice. Quando si carica il modello, MLflow aggiunge questi file o directory al percorso Python. Questo percorso funziona anche con file Python wheel personalizzati, che possono essere inclusi nel modello usando code_path, proprio come i file .py.

mlflow.pyfunc.log_model( artifact_path=artifact_path,
                         code_path=[filename.py],
                         data_path=data_path,
                         conda_env=conda_env,
                       )

Registrare le dipendenze dei modelli di pacchetti non Python

MLflow non rileva automaticamente le dipendenze non Python, ad esempio pacchetti Java, pacchetti R e pacchetti nativi, come i pacchetti Linux. Per questi pacchetti, è necessario registrare dati aggiuntivi.

• Elenco delle dipendenze: Databricks consiglia di registrare un artefatto con il modello che specifica queste dipendenze non Python. Potrebbe trattarsi di un semplice file .txt o .json. mlflow.pyfunc.log_model consente di specificare questo artefatto aggiuntivo usando l'argomento artifacts.
• Pacchetti personalizzati: proprio come per le dipendenze Python personalizzate citate prima, è necessario assicurarsi che i pacchetti siano disponibili nell'ambiente di distribuzione. Per i pacchetti in una posizione centrale, ad esempio Maven Central o il proprio repository, assicurarsi che la posizione sia disponibile in fase di assegnazione dei punteggi o di servizio. Per i pacchetti privati non ospitati altrove, è possibile registrare i pacchetti insieme al modello come artefatti.

Implementare modelli con dipendenze

Quando si distribuisce un modello dal server di rilevamento MLflow o dal Registro di sistema dei modelli, occorre assicurarsi che nell'ambiente di distribuzione siano installate le dipendenze corrette. Il percorso più semplice può dipendere dalla modalità di distribuzione: batch/streaming o servizio online e dai tipi di dipendenze.

Per tutte le modalità di distribuzione, Databricks consiglia di eseguire l'inferenza nella stessa versione run-time usata durante il training, poiché il Databricks Runtime in cui è stato creato il modello include diverse librerie già installate. MLflow in Databricks salva automaticamente tale versione run-time nel file di metadati MLmodel in un campo databricks_runtime, ad esempio databricks_runtime: 10.2.x-cpu-ml-scala2.12.

Servizio online: Mosaic AI Model Serving

Databricks offre Model Serving, in cui i modelli di Machine Learning di MLflow vengono esposti come endpoint dell'API REST scalabili.

Per le dipendenze Python nel file requirements.txt, Databricks e MLflow gestiscono tutto per le dipendenze PyPI pubbliche. Analogamente, se sono stati specificati .py file o file Python wheel durante la registrazione del modello usando l'argomento code_path, MLflow carica automaticamente tali dipendenze.

Per questi scenari di gestione dei modelli, vedere quanto segue:

• Usare librerie Python personalizzate con Model Serving
• Creare un pacchetto di artefatti personalizzati e file per la gestione dei modelli

Per le dipendenze Python nel file requirements.txt, Databricks e MLflow gestiscono tutto per le dipendenze PyPI pubbliche. Analogamente, se sono stati specificati .py file o file Python wheel durante la registrazione del modello usando l'argomento code_path, MLflow carica automaticamente tali dipendenze.

Servizio online: sistemi di terzi o contenitori Docker

Se lo scenario richiede la gestione di soluzioni di terzi o la propria soluzione basata su Docker, è possibile esportare il modello come contenitore Docker.

Databricks consiglia quanto segue per la gestione di terzi che gestisce automaticamente le dipendenze Python. Tuttavia, per le dipendenze non Python, il contenitore deve essere modificato per includerle.

• Integrazione docker di MLflow per la soluzione di gestione basata su Docker: modelli MLflow build-docker

• Integrazione MLflow di Azure Machine Learning:

  • Distribuire in un'istanza di Azure Container
  • Distribuire nel servizio Azure Kubernetes

Processi batch e di streaming

L'assegnazione dei punteggi batch e di streaming deve essere eseguita sotto forma di processi di Databricks. Un processo notebook è spesso sufficiente e il modo più semplice per preparare il codice consiste nell'usare il Registro modelli di Databricks per generare un notebook di assegnazione dei punteggi.

Di seguito vengono descritti il processo e i passaggi da seguire per assicurarsi che le dipendenze vengano installate e applicate di conseguenza:

1. Avviare il cluster di assegnazione dei punteggi con la stessa versione di Databricks Runtime usata durante il training. Leggere il campo databricks_runtime dal file di metadati MLmodel e avviare un cluster con tale versione run-time.

   • Questa operazione può essere eseguita manualmente nella configurazione del cluster o automatizzata con logica personalizzata. Per l'automazione, il formato della versione run-time letto dal file di metadati nell'API per processi e nell'API cluster.

2. Installare quindi eventuali dipendenze non Python. Per assicurarsi che le dipendenze non Python siano accessibili all'ambiente di distribuzione, è possibile:

   • Installare manualmente le dipendenze non Python del modello nel cluster Databricks nell'ambito della configurazione del cluster prima di eseguire l'inferenza.
   • In alternativa, è possibile scrivere logica personalizzata nella distribuzione del processo di assegnazione dei punteggi per automatizzare l'installazione delle dipendenze nel cluster. Supponendo di aver salvato le dipendenze non Python come artefatti, come descritto in Registrare le dipendenze del modello di pacchetti non Python, questa automazione può installare librerie usando l'API per librerie. In alternativa, è possibile scrivere codice specifico per generare uno script di inizializzazione con ambito cluster per installare le dipendenze.

3. Il processo di assegnazione dei punteggi installa le dipendenze Python nell'ambiente di esecuzione del processo. In Databricks, il Registro modelli consente di generare un notebook per l'inferenza che esegue questa operazione automaticamente.

   • Quando si usa il Registro modelli di Databricks per generare un notebook di assegnazione dei punteggi, il notebook contiene codice per installare le dipendenze Python nel file requirements.txt del modello. Per il processo del notebook per l'assegnazione dei punteggi batch o di streaming, questo codice inizializza l'ambiente notebook, affinché le dipendenze del modello siano installate e pronte per il modello.

4. MLflow gestisce qualsiasi codice Python personalizzato incluso nel parametro code_path in log_model. Questo codice viene aggiunto al percorso Python quando viene chiamato il metodo predict() del modello. È anche possibile eseguire questa operazione manualmente in uno dei due modi seguenti:

   • Chiamata di mlflow.pyfunc.spark_udf con l'argomento env_manager=['virtualenv'/'conda'].
   • Estrazione dei requisiti tramite mlflow.pyfunc.get_model_dependencies e relativa installazione tramite %pip install.

   Nota

   Se sono stati specificati .py file o file Python wheel durante la registrazione del modello usando l'argomento code_path, MLflow carica automaticamente tali dipendenze.