Configurare il training AutoML per i dati tabulari con l'interfaccia della riga di comando di Azure Machine Learning e Python SDK

  • Articolo

SI APPLICA A:Estensione ml dell'interfaccia della riga di comando di Azure v2 (corrente)Python SDK azure-ai-ml v2 (corrente)

Questa guida illustra come configurare un processo di machine learning automatizzato, AutoML e training con Python SDK v2 di Azure Machine Learning. Machine Learning automatizzato seleziona automaticamente un algoritmo e iperparametri, e genera un modello pronto per la distribuzione. Questa guida fornisce informazioni dettagliate sulle varie opzioni che è possibile usare per configurare esperimenti di Machine Learning automatizzati.

Se si preferisce un'esperienza senza codice, è anche possibile Configurare il training AutoML senza codice in studio di Azure Machine Learning.

Prerequisiti

Per usare le informazioni sull'SDK, installare SDK v2 per Python di Azure Machine Learning.

Per installare l'SDK, è possibile:

Configurare l'area di lavoro

Per connettersi a un'area di lavoro, è necessario specificare una sottoscrizione, un gruppo di risorse e un nome dell'area di lavoro.

I dettagli dell'area di lavoro vengono usati nel MLClient da azure.ai.ml per ottenere un punto di controllo per l'area di lavoro di Azure Machine Learning necessaria.

Nell'esempio seguente viene usata l'autenticazione di Azure predefinita insieme alla configurazione predefinita dell'area di lavoro o da qualsiasi file config.json copiato nella struttura delle cartelle. Se non viene trovato alcun config.json, è necessario introdurre manualmente il valore subscription_id, resource_group e l'area di lavoro durante la creazione di MLClient.

from azure.identity import DefaultAzureCredential
from azure.ai.ml import MLClient

credential = DefaultAzureCredential()
ml_client = None
try:
    ml_client = MLClient.from_config(credential)
except Exception as ex:
    print(ex)
    # Enter details of your Azure Machine Learning workspace
    subscription_id = "<SUBSCRIPTION_ID>"
    resource_group = "<RESOURCE_GROUP>"
    workspace = "<AZUREML_WORKSPACE_NAME>"
    ml_client = MLClient(credential, subscription_id, resource_group, workspace)

Origine dati e formato

Per fornire dati di training ad AutoML in SDK v2, è necessario caricarli nel cloud tramite un oggetto MLTable.

Requisiti per il caricamento dei dati in un oggetto MLTable:

  • I dati devono essere in formato tabulare.
  • Il valore da stimare, la colonna di destinazione, deve essere presente nei dati.

I dati di training devono essere accessibili dal calcolo remoto. ML automatizzato v2 (Python SDK e CLI/YAML) accetta asset di dati MLTable (v2), anche se per compatibilità con le versioni precedenti supporta anche set di dati tabulari v1 da v1 (un set di dati tabulari registrato) tramite le stesse proprietà del set di dati di input. Tuttavia, è consigliabile usare MLTable disponibile in v2. In questo esempio si presuppone che i dati vengano archiviati nel percorso locale, ./train_data/bank_marketing_train_data.csv

È possibile creare un oggetto MLTable usando mltable Python SDK, come illustrato nell'esempio seguente:

import mltable

paths = [
    {'file': './train_data/bank_marketing_train_data.csv'}
]

train_table = mltable.from_delimited_files(paths)
train_table.save('./train_data')

Questo codice crea un nuovo file, ./train_data/MLTable, che contiene il formato di file e le istruzioni di caricamento.

Ora la cartella ./train_data include il file di definizione MLTable più il file di dati, bank_marketing_train_data.csv.

Per altre informazioni sugli oggetti MLTable, vedere l'articolo sulla guida pratica per mltable

Training, convalida e test dei dati

È possibile specificare set di dati di training e di convalida separati, ma i dati di training devono essere forniti al parametro training_data nella funzione factory del processo di Machine Learning automatizzato.

Se non si specifica in modo esplicito un parametro validation_data o n_cross_validation, ML automatizzato applica tecniche predefinite per determinare come viene eseguita la convalida. Questa determinazione dipende dal numero di righe nel set di dati assegnato al parametro training_data.

Dimensioni dei dati di training Tecnica di convalida
Più di 20.000 righe Viene applicata la suddivisione dei dati di training/convalida. Per impostazione predefinita, come set di convalida viene considerato il 10% del set di dati di training iniziale. A sua volta, il set di convalida viene usato per il calcolo delle metriche.
Minore o uguale a 20.000 righe Viene applicato l'approccio di convalida incrociata. Il numero predefinito di riduzioni dipende dal numero di righe.
Se il set di dati contiene meno di 1.000 righe, vengono usate 10 riduzioni.
Se le righe sono uguali a o comprese tra 1.000 e 20.000, vengono usate tre riduzioni.

Calcolo per eseguire l'esperimento

I processi di Machine Learning automatizzato con Python SDK v2 (o l'interfaccia della riga di comando v2) sono attualmente supportati solo nell'ambiente di calcolo remoto di Azure Machine Learning (cluster o istanza di calcolo).

Altre informazioni sulla creazione di risorse di calcolo con Python SDKv2 (o CLIv2).

Configurare le impostazioni di esperimento

Sono disponibili diverse opzioni che è possibile usare per configurare l'esperimento di Machine Learning automatizzato. Questi parametri di configurazione vengono impostati nel metodo dell'attività. È anche possibile impostare le impostazioni di training del processo e i criteri di uscita con le impostazioni training e limits.

L'esempio seguente mostra i parametri obbligatori per un'attività di classificazione che specifica l'accuratezza come metrica primaria e 5 riduzioni di convalida incrociata.

from azure.ai.ml.constants import AssetTypes
from azure.ai.ml import automl, Input

# note that this is a code snippet -- you might have to modify the variable values to run it successfully

# make an Input object for the training data
my_training_data_input = Input(
    type=AssetTypes.MLTABLE, path="./data/training-mltable-folder"
)

# configure the classification job
classification_job = automl.classification(
    compute=my_compute_name,
    experiment_name=my_exp_name,
    training_data=my_training_data_input,
    target_column_name="y",
    primary_metric="accuracy",
    n_cross_validations=5,
    enable_model_explainability=True,
    tags={"my_custom_tag": "My custom value"}
)

# Limits are all optional
classification_job.set_limits(
    timeout_minutes=600, 
    trial_timeout_minutes=20, 
    max_trials=5,
    enable_early_termination=True,
)

# Training properties are optional
classification_job.set_training(
    blocked_training_algorithms=["logistic_regression"], 
    enable_onnx_compatible_models=True
)

Selezionare il tipo di attività di Machine Learning (problema di ML)

Prima di poter inviare il processo di Machine Learning automatizzato, è necessario determinare il tipo di problema di Machine Learning che si sta risolvendo. Questo problema determina la funzione usata dal processo di Machine Learning automatizzato e gli algoritmi del modello applicati.

Il ML automatizzato supporta attività basate su dati tabulari (classificazione, regressione, previsione), attività di visione artificiale (ad esempio Classificazione immagini e Rilevamento oggetti) e attività di elaborazione del linguaggio naturale (ad esempio attività di classificazione del testo e riconoscimento di entità). Per altre informazioni, vedere l'articolo sui tipi di attività. Per altre informazioni sulla configurazione dei processi di previsione, vedere la guida alla previsione delle serie temporali.

Algoritmi supportati

Il Machine Learning automatizzato prova modelli e algoritmi diversi durante il processo di automazione e ottimizzazione. Gli utenti non devono specificare l'algoritmo.

Il metodo dell'attività determina l'elenco di algoritmi/modelli da applicare. Usare i parametri allowed_training_algorithms o blocked_training_algorithms nella configurazione training del processo AutoML per modificare ulteriormente le iterazioni con i modelli disponibili da includere o escludere.

Nell'elenco di collegamenti seguente è possibile esplorare gli algoritmi supportati per ogni attività di Machine Learning elencata di seguito.

Classificazione Regressione Previsione di una serie temporale
Logistic Regression* Elastic Net* AutoARIMA
Light GBM* Light GBM* Prophet
Gradient Boosting* Gradient Boosting* Elastic Net
Decision Tree* Decision Tree* Light GBM
K Nearest Neighbors* K Nearest Neighbors* K Nearest Neighbors
Linear SVC* LARS Lasso* Decision Tree
Support Vector Classification (SVC)* Stochastic Gradient Descent (SGD)* Arimax
Random Forest* Random Forest LARS Lasso
Extremely Randomized Trees* Extremely Randomized Trees* Extremely Randomized Trees*
Xgboost* Xgboost* Random Forest
Naive Bayes* Xgboost TCNForecaster
Stochastic Gradient Descent (SGD)* Stochastic Gradient Descent (SGD) Gradient Boosting
ExponentialSmoothing
SeasonalNaive
Media
Naive
SeasonalAverage

Con algoritmi aggiuntivi riportati di seguito.

Seguire questo collegamento per i notebook di esempio di ogni tipo di attività.

Primary metric (Metrica principale)

Il parametro primary_metric determina la metrica da usare durante il training del modello per l'ottimizzazione. Le metriche disponibili che è possibile selezionare sono determinate dal tipo di attività scelto.

La scelta di una metrica primaria per ML automatizzato da ottimizzare dipende da molti fattori. È consigliabile scegliere una metrica che rappresenti al meglio le esigenze aziendali. Valutare quindi se la metrica è adatta al profilo del set di dati (dimensioni dei dati, intervallo, distribuzione di classi e così via). Le sezioni seguenti riepilogano le metriche principali consigliate in base al tipo di attività e allo scenario aziendale.

Per informazioni sulle definizioni specifiche di queste metriche, vedere Risultati del Machine Learning automatizzato.

Metriche per gli scenari di classificazione multi-classe

Queste metriche si applicano a tutti gli scenari di classificazione, inclusi dati tabulari, immagini/visione artificiale e testo con elaborazione del linguaggio naturale.

Le metriche dipendenti dalla soglia, ad esempio accuracy, recall_score_weighted, norm_macro_recall e precision_score_weighted potrebbero non essere ottimizzate anche per i set di dati di piccole dimensioni, che hanno un'asimmetria di classe elevata (squilibrio di classe) o quando il valore della metrica previsto è molto vicino a 0,0 o 1,0. In questi casi, AUC_weighted può essere una scelta migliore per la metrica primaria. Al termine dell'automazione di Machine Learning, è possibile scegliere il modello vincente in base alla metrica più adatta alle esigenze aziendali.

Metric Casi d'uso di esempio
accuracy Classificazione delle immagini, analisi della valutazione, stima dell'abbandono
AUC_weighted Rilevamento delle frodi, classificazione delle immagini, rilevamento anomalie/rilevamento della posta indesiderata
average_precision_score_weighted Analisi valutazione
norm_macro_recall Previsione abbandono
precision_score_weighted

Metriche per scenari di classificazione con più etichette

  • Per Classificazione del testo, l'unica metrica primaria supportata è attualmente "Accuratezza".

  • Per Classificazione immagini con più etichette, le metriche principali supportate sono definite nell'enumerazione ClassificationMultilabelPrimaryMetrics

Metriche per gli scenari di riconoscimento entità denominata (NER) di testi con elaborazione del linguaggio naturale

  • Per gli scenari di riconoscimento entità denominata (NER) di testi con elaborazione del linguaggio naturale attualmente "Accuratezza" è l'unica metrica primaria supportata.

Metriche per i modelli di regressione

r2_score, normalized_mean_absolute_error e normalized_root_mean_squared_error stanno tentando di ridurre al minimo gli errori di stima. r2_score e normalized_root_mean_squared_error riducono al minimo gli errori quadratici medi mentre normalized_mean_absolute_error riduce al minimo il valore assoluto medio degli errori. Il valore assoluto tratta gli errori in tutte le dimensioni e gli errori quadratici avranno una penalità molto maggiore per gli errori con valori assoluti più grandi. A seconda che gli errori più grandi debbano essere puniti più o meno, è possibile scegliere di ottimizzare l'errore quadratico o l'errore assoluto.

La differenza principale tra r2_score e normalized_root_mean_squared_error è il modo in cui vengono normalizzati e i loro significati. normalized_root_mean_squared_error è la radice errore quadratico medio normalizzata per intervallo e può essere interpretata come la grandezza dell'errore medio per la stima. r2_score è un errore quadratico medio normalizzato da una stima della varianza dei dati. È la proporzione di variazione che può essere acquisita dal modello.

Nota

Anche r2_score e normalized_root_mean_squared_error si comportano in modo analogo come metriche primarie. Se viene applicato un set di convalida fisso, queste due metriche ottimizzano la stessa destinazione e lo stesso errore quadratico medio, e verranno ottimizzate dallo stesso modello. Quando è disponibile solo un set di training e viene applicata la convalida incrociata, il normalizzatore per normalized_root_mean_squared_error è fisso come intervallo di training impostato, ma il normalizzatore per r2_score varia per ogni riduzione in quanto è la varianza per ogni riduzione.

Se la classificazione, anziché il valore esatto, è di interesse, spearman_correlation può essere una scelta migliore perché misura la correlazione di classificazione tra valori reali e stime.

AutoML attualmente non supporta metriche primarie che misurano la differenza relativa tra previsioni e osservazioni. Le metriche r2_score, normalized_mean_absolute_errore normalized_root_mean_squared_error sono tutte misure di differenza assoluta. Ad esempio, se una stima è diversa da un'osservazione di 10 unità, queste metriche calcolano lo stesso valore se l'osservazione è di 20 unità o 20.000 unità. Al contrario, una differenza percentuale, che è una misura relativa, restituisce gli errori rispettivamente del 50% e dello 0,05%! Per ottimizzare la differenza relativa, è possibile eseguire AutoML con una metrica primaria supportata e quindi selezionare il modello con il valore mean_absolute_percentage_error o root_mean_squared_log_error migliore. Si noti che queste metriche sono indefinite quando i valori di osservazione sono zero, quindi potrebbero non essere sempre scelte ottimali.

Metric Casi d'uso di esempio
spearman_correlation
normalized_root_mean_squared_error Previsione dei prezzi (casa/prodotto/mancia), Previsione del punteggio della recensione
r2_score Ritardo della compagnia aerea, stima dello stipendio, tempo di risoluzione dei bug
normalized_mean_absolute_error

Metriche per gli scenari di previsione delle serie temporali

Le raccomandazioni sono simili a quelle indicate per gli scenari di regressione.

Metric Casi d'uso di esempio
normalized_root_mean_squared_error Stima dei prezzi (previsione), ottimizzazione dell'inventario, previsione della domanda
r2_score Stima dei prezzi (previsione), ottimizzazione dell'inventario, previsione della domanda
normalized_mean_absolute_error

Metriche per scenari di rilevamento oggetti immagine

  • Per il rilevamento di oggetti immagine, le metriche principali supportate sono definite nell'enumerazione ObjectDetectionPrimaryMetrics

Metriche per scenari di segmentazione istanze immagine

  • Per gli scenari di segmentazione istanze immagine, le metriche principali supportate sono definite nell'enumerazione InstanceSegmentationPrimaryMetrics

Definizione delle funzionalità dei dati

In ogni esperimento di Machine Learning automatizzato, i dati vengono trasformati automaticamente in numeri e vettori di numeri e anche ridimensionati e normalizzati per aiutare gli algoritmi sensibili alle funzionalità su scale diverse. Queste trasformazioni dei dati sono denominate definizione delle funzionalità.

Nota

I passaggi di definizione delle funzionalità di Machine Learning automatizzato (normalizzazione delle funzionalità, gestione dei dati mancanti, conversione dei valori di testo in formato numerico e così via) diventano parte del modello sottostante. Quando si usa il modello per le previsioni, gli stessi passaggi di definizione delle funzionalità applicati durante il training vengono automaticamente applicati ai dati di input.

Quando si configurano i processi di Machine Learning automatizzati, è possibile abilitare/disabilitare le impostazioni featurization.

La tabella seguente illustra le impostazioni accettate per la definizione delle funzionalità.

Configurazione della definizione delle funzionalità Descrizione
"mode": 'auto' Indica che i passaggi di protezione dati e definizione delle funzionalità vengono eseguiti automaticamente come parte della pre-elaborazione. Impostazione predefinita.
"mode": 'off' Indica che il passaggio di definizione delle caratteristiche non deve essere eseguito automaticamente.
"mode": 'custom' Indica che deve essere usata la definizione delle funzionalità personalizzata.

Il codice seguente illustra come fornire la definizione delle funzionalità personalizzata in questo caso per un processo di regressione.

from azure.ai.ml.automl import ColumnTransformer

transformer_params = {
    "imputer": [
        ColumnTransformer(fields=["CACH"], parameters={"strategy": "most_frequent"}),
        ColumnTransformer(fields=["PRP"], parameters={"strategy": "most_frequent"}),
    ],
}
regression_job.set_featurization(
    mode="custom",
    transformer_params=transformer_params,
    blocked_transformers=["LabelEncoding"],
    column_name_and_types={"CHMIN": "Categorical"},
)

Criteri di uscita

Sono disponibili alcune opzioni che è possibile definire nella funzione set_limits() per terminare l'esperimento prima del completamento del processo.

Criteri description
Nessun criterio Se non si definiscono parametri di uscita, l'esperimento continua fino a quando non vengono apportati ulteriori progressi sulla metrica primaria.
timeout Definisce per quanto tempo, in minuti, l'esperimento deve continuare a essere eseguito. Se non specificato, il timeout totale del processo predefinito è di 6 giorni (8.640 minuti). Per specificare un timeout inferiore o uguale a 1 ora (60 minuti), assicurarsi che le dimensioni del set di dati non siano maggiori di 10.000.000 (righe di colonna) o si verificherà un errore.

Questo timeout include la configurazione, la definizione delle funzionalità e le esecuzioni di training, ma non include le esecuzioni di ensembling e spiegabilità del modello alla fine del processo, perché queste azioni devono essere eseguite una volta completate tutte le prove (processi figlio).
trial_timeout_minutes Tempo massimo in minuti per cui ogni prova (processo figlio) può essere eseguita prima che termini. Se non specificato, viene usato un valore di 1 mese o 43.200 minuti
enable_early_termination Se terminare il processo se il punteggio non migliora a breve termine
max_trials Numero massimo di prove/esecuzioni ognuna con una combinazione diversa di algoritmi e iperparametri da provare durante un processo AutoML. Se non è specificato, il valore predefinito è 1.000 prove. Se si usa enable_early_termination il numero di prove può essere inferiore.
max_concurrent_trials Rappresenta il numero massimo di prove (processi figlio) che verrebbero eseguite in parallelo. È consigliabile associare questo numero al numero di nodi del cluster

Eseguire esperimento

Nota

Se si esegue più volte un esperimento con le stesse impostazioni di configurazione e la stessa metrica primaria, è probabile che si vedano variazioni nel punteggio finale di ogni esperimento e nei modelli generati. Gli algoritmi automatizzati di Machine Learning hanno una casualità intrinseca che può causare lievi variazioni nell'output dei modelli dall'esperimento e nel punteggio finale delle metriche del modello consigliato, ad esempio l'accuratezza. È probabile che vengano visualizzati anche i risultati con lo stesso nome del modello, ma vengono usati iperparametri diversi.

Avviso

Se sono state impostate regole nel firewall e/o nel gruppo di sicurezza di rete nell'area di lavoro, verificare che le autorizzazioni necessarie vengano concesse al traffico di rete in ingresso e in uscita come definito in Configurare il traffico di rete in ingresso e in uscita.

Avviare l'esperimento per eseguire e generare un modello. Dopo aver creato MLClient nei prerequisiti, è possibile eseguire il comando seguente nell'area di lavoro.


# Submit the AutoML job
returned_job = ml_client.jobs.create_or_update(
    classification_job
)  # submit the job to the backend

print(f"Created job: {returned_job}")

# Get a URL for the status of the job
returned_job.services["Studio"].endpoint

Più esecuzioni figlio nei cluster

Le esecuzioni figlio dell'esperimento di Machine Learning automatizzato possono essere eseguite in un cluster che esegue già un altro esperimento. Tuttavia, la tempistica dipende dal numero di nodi del cluster e se tali nodi sono disponibili per eseguire un esperimento diverso.

Ogni nodo del cluster funge da singola macchina virtuale (VM) che può eseguire una singola esecuzione di training; per il ML automatizzato questo significa un'esecuzione figlio. Se tutti i nodi sono occupati, viene accodato un nuovo esperimento. Tuttavia, se sono presenti dei nodi gratuiti, il nuovo esperimento eseguirà esecuzioni figlio di Machine Learning automatizzate in parallelo nei nodi/macchine virtuali disponibili.

Per gestire le esecuzioni figlio e quando possono essere eseguite, è consigliabile creare un cluster dedicato per esperimento e associare il numero di max_concurrent_iterations dell'esperimento al numero di nodi nel cluster. In questo modo, si usano tutti i nodi del cluster contemporaneamente con il numero di esecuzioni/iterazioni figlio simultanee desiderate.

Configurare max_concurrent_iterations nella configurazione limits. Se non è configurata, per impostazione predefinita è consentita una sola esecuzione/iterazione figlio simultanea per esperimento. Nel caso dell'istanza di calcolo, max_concurrent_trials può essere impostato come uguale al numero di core nella macchina virtuale dell'istanza di calcolo.

Esplorare modelli e metriche

Il Machine Learning automatizzato offre opzioni per monitorare e valutare i risultati del training.

Dall'interfaccia utente di Azure Machine Learning nella pagina del modello è anche possibile visualizzare gli iperparametri usati durante il training di un determinato modello e visualizzare e personalizzare il codice di training del modello interno usato.

Registrare e distribuire modelli

Dopo aver testato un modello e aver confermato di voler usarlo nell'ambiente di produzione, è possibile registrarlo per usarlo in un secondo momento.

Suggerimento

Per i modelli registrati, la distribuzione con un clic è disponibile tramite Azure Machine Learning Studio. Vedere come distribuire i modelli registrati dallo studio.

AutoML nelle pipeline

Per sfruttare AutoML nei flussi di lavoro MLOps, è possibile aggiungere passaggi del processo AutoML alle Pipeline di Azure Machine Learning. In questo modo è possibile automatizzare l'intero flusso di lavoro associando gli script di preparazione dei dati ad AutoML e quindi registrando e convalidando il modello migliore risultante.

Di seguito è riportata una pipeline di esempio con un componente di classificazione AutoML e un componente di comando che mostra l'output AutoML risultante. Si noti che si fa riferimento agli input (dati di training e convalida) e agli output (modello migliore) in passaggi diversi.

# Define pipeline
@pipeline(
    description="AutoML Classification Pipeline",
    )
def automl_classification(
    classification_train_data,
    classification_validation_data
):
    # define the automl classification task with automl function
    classification_node = classification(
        training_data=classification_train_data,
        validation_data=classification_validation_data,
        target_column_name="y",
        primary_metric="accuracy",
        # currently need to specify outputs "mlflow_model" explictly to reference it in following nodes 
        outputs={"best_model": Output(type="mlflow_model")},
    )
    # set limits and training
    classification_node.set_limits(max_trials=1)
    classification_node.set_training(
        enable_stack_ensemble=False,
        enable_vote_ensemble=False
    )

    command_func = command(
        inputs=dict(
            automl_output=Input(type="mlflow_model")
        ),
        command="ls ${{inputs.automl_output}}",
        environment="AzureML-sklearn-0.24-ubuntu18.04-py37-cpu:latest"
    )
    show_output = command_func(automl_output=classification_node.outputs.best_model)


pipeline_job = automl_classification(
    classification_train_data=Input(path="./training-mltable-folder/", type="mltable"),
    classification_validation_data=Input(path="./validation-mltable-folder/", type="mltable"),
)

# set pipeline level compute
pipeline_job.settings.default_compute = compute_name

# submit the pipeline job
returned_pipeline_job = ml_client.jobs.create_or_update(
    pipeline_job,
    experiment_name=experiment_name
)
returned_pipeline_job

# ...
# Note that this is a snippet from the bankmarketing example you can find in our examples repo -> https://github.com/Azure/azureml-examples/tree/main/sdk/python/jobs/pipelines/1h_automl_in_pipeline/automl-classification-bankmarketing-in-pipeline

Per altri esempi su come includere AutoML nelle pipeline, vedere il repository di esempi.

AutoML su larga scala: training distribuito

Per scenari di dati di grandi dimensioni, AutoML supporta il training distribuito per un set limitato di modelli:

Algoritmo distribuito Attività supportate Limite delle dimensioni dei dati (approssimativo)
LightGBM Classificazione, regressione 1 TB
TCNForecaster Previsioni 200 GB

Gli algoritmi di training distribuiti partizionano e distribuiscono automaticamente i dati tra più nodi di calcolo per il training del modello.

Nota

La convalida incrociata, i modelli ensemble, il supporto ONNX e la generazione di codice non sono attualmente supportati nella modalità di training distribuita. Inoltre, AutoML può effettuare scelte come limitare le utilità di definizione delle funzionalità disponibili e i dati di sottocampionamento usati per la convalida, la spiegazione e la valutazione del modello.

Training distribuito per la classificazione e la regressione

Per usare il training distribuito per la classificazione o la regressione, è necessario impostare le proprietà training_mode e max_nodes dell'oggetto processo.

Proprietà Descrizione
training_mode Indica la modalità di training; distributed o non_distributed. Il valore predefinito è non_distributed.
max_nodes Numero di nodi da usare per il training da ogni prova di AutoML. Questa impostazione deve essere maggiore o uguale a 4.

L'esempio di codice seguente illustra un esempio di queste impostazioni per un processo di classificazione:

from azure.ai.ml.constants import TabularTrainingMode

# Set the training mode to distributed
classification_job.set_training(
    allowed_training_algorithms=["LightGBM"],
    training_mode=TabularTrainingMode.DISTRIBUTED
)

# Distribute training across 4 nodes for each trial
classification_job.set_limits(
    max_nodes=4,
    # other limit settings
)

Nota

Il training distribuito per le attività di classificazione e regressione attualmente non supporta più versioni di valutazione simultanee. Le prove del modello sono eseguite in sequenza con ogni prova usando max_nodes nodi. Al momento l'impostazione del limite max_concurrent_trials viene ignorata.

Training distribuito per la previsione

Per informazioni sul funzionamento del training distribuito per le attività di previsione, vedere l'articolo relativo alla previsione su larga scala. Per usare il training distribuito per la previsione, è necessario impostare le proprietà training_mode, enable_dnn_training, max_nodes e facoltativamente max_concurrent_trials dell'oggetto processo.

Proprietà Descrizione
training_mode Indica la modalità di training; distributed o non_distributed. Il valore predefinito è non_distributed.
enable_dnn_training Flag per abilitare i modelli di rete neurale profonda.
max_concurrent_trials Questo è il numero massimo di modelli di prova per i quali eseguire il training in parallelo. Assume il valore predefinito 1.
max_nodes Il numero totale di nodi da usare per il training. Questa impostazione deve essere maggiore o uguale a 2. Per le attività di previsione, ogni modello di prova viene sottoposto a training usando i nodi $\text{max}\left(2, \text{floor}( \text{max_nodes} / \text{max_concurrent_trials}) \right)$.

L'esempio di codice seguente illustra un esempio di queste impostazioni per un processo di previsione:

from azure.ai.ml.constants import TabularTrainingMode

# Set the training mode to distributed
forecasting_job.set_training(
    enable_dnn_training=True,
    allowed_training_algorithms=["TCNForecaster"],
    training_mode=TabularTrainingMode.DISTRIBUTED
)

# Distribute training across 4 nodes
# Train 2 trial models in parallel => 2 nodes per trial
forecasting_job.set_limits(
    max_concurrent_trials=2,
    max_nodes=4,
    # other limit settings
)

Per esempi di codice di configurazione completo, vedere le sezioni precedenti su configurazione e invio di processi.

Passaggi successivi