Configurar o treinamento de AutoML para dados tabulares com a CLI do Azure Machine Learning e o SDK do Python

  • Artigo

APLICA-SE A:Extensão de ML da CLI do Azure v2 (atual)SDK do Python azure-ai-ml v2 (atual)

Neste guia, saiba como configurar um machine learning automatizado, AutoML ou trabalho de treinamento com o SDK do Python para Azure Machine Learning v2. O ML automatizado escolhe um algoritmo e hiperparâmetros para você e gera um modelo pronto para implantação. Este guia fornece detalhes das várias opções que você pode usar para configurar experimentos de ML automatizado.

Se preferir uma experiência sem código, você também poderá Configurar o treinamento AutoML sem código no Estúdio do Azure Machine Learning.

Pré-requisitos

Para usar as informações do SDK, instale o SDK v2 para Python do Azure Machine Learning.

Para instalar o SDK, você pode:

  • Crie uma instância de computação, que já tenha instalado o SDK mais recente do Python para o Azure Machine Learning e esteja configurada previamente para fluxos de trabalho de ML. Consulte Criar uma instância de computação do Azure Machine Learning para obter mais informações.
  • Instalar o SDK no computador local

Configurar seu workspace

Para se conectar a um espaço de trabalho, você precisa fornecer uma assinatura, um grupo de recursos e um nome do espaço de trabalho.

Os detalhes do Workspace são usados no MLClient do azure.ai.ml para obter um identificador para o workspace do Azure Machine Learning necessário.

No exemplo a seguir, a autenticação padrão do Azure é usada junto com a configuração de espaço de trabalho padrão ou de qualquer arquivo config.json que você possa ter copiado para a estrutura de pastas. Se nenhum config.json for encontrado, será preciso inserir manualmente a subscription_id, o resource_group e o workspace ao criar o 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)

Fonte de dados e formato

Para fornecer dados de treinamento para AutoML no SDK v2, você precisa carregá-los na nuvem por meio de uma MLTable.

Requisitos para carregar dados em uma MLTable:

  • Os dados devem estar em formato de tabela.
  • O valor que você quer prever, coluna de destino, deve estar presente nos dados.

Os dados de treinamento devem ser acessíveis a partir da computação remota. O ML automatizado v2 (SDK do Python e CLI/YAML) aceita ativos de dados da MLTable (v2), embora para compatibilidade com versões anteriores também ofereça suporte a conjuntos de dados de tabela v1 da v1 (um conjunto de dados tabular registrado) por meio das mesmas propriedades do conjunto de dados de entrada. No entanto, a recomendação é usar a MLTable disponível na v2. Neste exemplo, presumimos que os dados sejam armazenados no caminho local, ./train_data/bank_marketing_train_data.csv

Você pode criar uma MLTable usando a mltable SDK do Python como no exemplo a seguir:

import mltable

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

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

Esse código cria um novo arquivo, ./train_data/MLTable, que contém o formato do arquivo e as instruções de carregamento.

Agora, a pasta ./train_data tem o arquivo de definição MLTable mais o arquivo de dados, bank_marketing_train_data.csv.

Para obter mais informações sobre MLTable, consulte o artigo instruções para mltable

Dados de treinamento, validação e teste

Você pode especificar dados de treinamento e conjuntos de dados de validação separados, no entanto, os dados de treinamento devem ser fornecidos para o parâmetro training_data na função de fábrica do trabalho de ML automatizado.

Se você não especificar explicitamente um parâmetro validation_data ou n_cross_validation, o ML automatizado aplicará técnicas padrão para determinar como a validação será executada. Essa determinação depende do número de linhas no conjuntos de dados atribuído ao parâmetro training_data.

Tamanho dos dados de treinamento Técnica de validação
Maior que 20.000 linhas A divisão de dados de treinamento/validação é aplicada. O padrão é levar 10% do conjunto de dados de treinamento inicial como o conjunto de validação. Por sua vez, esse conjunto de validação é usado para cálculo de métricas.
Menor ou igual a 20.000 linhas A abordagem de validação cruzada é aplicada. O número padrão de dobras depende do número de colunas.
Se o conjunto de registros for menor que 1.000 linhas, serão usadas 10 dobras.
Se as linhas forem iguais a, ou estiverem entre 1.000 e 20.000, serão usadas três dobras.

Computação para executar o experimento

Atualmente, só há suporte para trabalhos de ML automatizado com o SDK v2 do Python (ou a CLI v2) na computação remota do Azure Machine Learning (instância de computação ou cluster).

Saiba mais sobre como criar computação com o SDKv2 do Python (ou CLIv2).

Configurar as definições do experimento

Existem várias opções que você pode usar para configurar o experimento de ML automatizado. Esses parâmetros de configuração são definidos em seu método de tarefa. Você também pode definir configurações de treinamento de trabalho e critérios de saída com as configurações training e limits.

O exemplo a seguir mostra os parâmetros necessários para uma tarefa de classificação que especifica a precisão como a métrica principal e cinco dobras de validação cruzada.

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
)

Selecione o tipo de tarefa de aprendizado de máquina (problema de ML)

Antes de enviar o trabalho de ML automatizado, determine o tipo de problema de aprendizado de máquina que está sendo resolvido. Esse problema determina qual função seu trabalho de ML automatizado usa e quais algoritmos de modelo ele aplica.

O ML automatizado dá suporte a tarefas baseadas em dados tabulares (classificação, regressão, previsão), tarefas de visual computacional (como Classificação de Imagem e Detecção de Objetos) e tarefas de processamento de linguagem natural (como tarefas de Classificação de texto e Reconhecimento de entidade). Consulte nosso artigo sobre tipos de tarefa para obter mais informações. Consulte nosso guia de previsão de série temporal para obter mais detalhes sobre como configurar trabalhos de previsão.

Algoritmos compatíveis

O machine learning automatizado testa diferentes modelos e algoritmos durante o processo de automação e ajuste. Como usuário, você não precisa especificar o algoritmo.

O método de tarefa determina a lista de algoritmos/modelos a serem aplicados. Use os parâmetros allowed_training_algorithms ou blocked_training_algorithms na configuração training do trabalho do AutoML para modificar ainda mais as iterações com os modelos disponíveis a serem incluídos ou excluídos.

Na lista a seguir, você pode explorar os algoritmos com suporte por tarefa de aprendizado de máquina listados abaixo.

classificação Regressão Previsão de série temporal
Regressão logística* Rede elástica* AutoARIMA
GBM claro* GBM claro* Prophet
Gradient boosting* Gradient boosting* Rede elástica
Árvore de decisão* Árvore de decisão* GBM claro
K-ésimo vizinhos mais próximos* K-ésimo vizinhos mais próximos* K-ésimo vizinhos mais próximos
SVC linear* LARS Lasso* Árvore de decisões
SVC (Classificação de vetores de suporte)* SGD (Gradiente estocástico descendente)* Arimax
Floresta aleatória* Floresta aleatória LARS Lasso
Árvores extremamente aleatórias* Árvores extremamente aleatórias* Árvores extremamente aleatórias*
Xgboost* Xgboost* Floresta aleatória
Naive Bayes* Xgboost TCNForecaster
SGD (Gradiente estocástico descendente)* SGD (Gradiente estocástico descendente) Gradient Boosting
ExponentialSmoothing
SeasonalNaive
Média
Naive
SeasonalAverage

Com algoritmos adicionais abaixo.

Siga este link para obter exemplos de notebooks de cada tipo de tarefa.

Métrica principal

O parâmetro primary_metric determina a métrica a ser usada durante o treinamento do modelo para otimização. As métricas disponíveis que você poderá selecionar serão determinadas pelo tipo de tarefa que você escolher.

A escolha da métrica primária para otimizar o ML automatizado depende de muitos fatores. Recomendamos que a sua consideração principal seja escolher uma métrica que melhor represente suas necessidades de negócios. Em seguida, considere se a métrica é adequada para o seu perfil de conjunto de dados (tamanho de dados, intervalo, distribuição de classe etc.). As seções a seguir resumem as métricas primárias recomendadas com base no tipo de tarefa e no cenário de negócios.

Saiba mais sobre as definições específicas dessas métricas em Entender os resultados do machine learning automatizado.

Métricas para cenários de várias classes de classificação

Essas métricas se aplicam a todos os cenários de classificação, incluindo dados tabulares, imagens/pesquisa visual computacional e Texto NLP.

As métricas dependentes de limite, como accuracy, recall_score_weighted, norm_macro_recall e precision_score_weighted, podem não realizar otimizações tão boas para conjuntos de dados pequenos e com distorção de classe muito grande (desequilíbrio de classe) ou quando o valor esperado da métrica é muito próximo de 0,0 ou 1,0. Nesses casos, AUC_weighted pode ser uma opção melhor para a métrica primária. Após a conclusão do ML automatizado, você pode escolher o modelo vencedor baseado na métrica mais adequada para suas necessidades de negócios.

Métrica Exemplos de casos de uso
accuracy Classificação de imagem, análise de sentimentos, previsão de rotatividade
AUC_weighted Detecção de fraudes, classificação de imagem, detecção de anomalias/de spam
average_precision_score_weighted Análise de sentimento
norm_macro_recall Previsão de rotatividade
precision_score_weighted

Métricas para cenários de várias rótulos de classificação

  • Para a classificação de texto, a 'Precisão' atual com vários rótulos é a única métrica principal com suporte.

  • Para vários rótulos de classificação de imagem, as métricas principais com suporte são definidas na Enumeração ClassificationMultilabelPrimaryMetrics

Métricas para cenários de NER de Texto NLP (Reconhecimento de Entidade Nomeada)

  • Para o NER de Texto NLP (Reconhecimento de Entidade Nomeada) atualmente, "Precisão" é a única métrica principal com suporte.

As métricas usadas em cenários de regressão

r2_score, normalized_mean_absolute_error e normalized_root_mean_squared_error estão todos tentando minimizar os erros de previsão. r2_score e normalized_root_mean_squared_error estão minimizando erros ao quadrado médios enquanto normalized_mean_absolute_error minimiza o valor absoluto médio de erros. O valor absoluto trata erros em todas as magnitudes, e erros ao quadrado terão uma penalidade muito maior para erros com valores absolutos maiores. Dependendo se erros maiores devem ser mais ou não, é possível optar por otimizar o erro ao quadrado ou o erro absoluto.

A principal diferença entre r2_score e normalized_root_mean_squared_error é a maneira como são normalizados e seus significados. normalized_root_mean_squared_error é o erro quadrado médio raiz normalizado por intervalo e pode ser interpretado como a magnitude média do erro para previsão. r2_score é o erro quadrado média normalizado por uma estimativa de variação de dados. É a proporção de variação que pode ser capturada pelo modelo.

Observação

r2_score e normalized_root_mean_squared_error também se comportam da mesma forma que as métricas primárias. Se um conjunto de validação fixo for aplicado, essas duas métricas estão otimizando o mesmo destino, erro ao quadrado médio e serão otimizadas pelo mesmo modelo. Quando apenas um conjunto de treinamento estiver disponível e a validação cruzada for aplicada, ele será ligeiramente diferente, pois o normalizador para normalized_root_mean_squared_error é fixo como o intervalo de conjunto de treinamento, mas o normalizador para r2_score variaria para cada dobra, pois é a variação para cada dobra.

Se a classificação, em vez do valor exato for de interesse, spearman_correlation poderá ser uma opção melhor, pois ela mede a correlação de classificação entre valores reais e previsões.

Atualmente, o AutoML não dá suporte a nenhuma métrica primária que meça a diferença relativa entre previsões e observações. As métricas r2_score, normalized_mean_absolute_error e normalized_root_mean_squared_error são todas medidas de diferença absoluta. Por exemplo, se uma previsão for diferente de uma observação em 10 unidades, essas métricas calcularão o mesmo valor se a observação for de 20 unidades ou 20.000 unidades. Por outro lado, uma diferença percentual, que é uma medida relativa, apresenta erros de 50% e 0,05%, respectivamente! Para otimizar a diferença relativa, você pode executar o AutoML com uma métrica primária com suporte e, em seguida, selecionar o modelo com o melhor mean_absolute_percentage_error ou root_mean_squared_log_error. Observe que essas métricas são indefinidas quando qualquer valor de observação é zero, portanto, elas podem nem sempre ser boas escolhas.

Métrica Exemplos de casos de uso
spearman_correlation
normalized_root_mean_squared_error Previsão de preço (casa/produto/gorjeta), revisar previsão de pontuação
r2_score Atraso de companhia aérea, estimativa de salário, tempo de resolução de bug
normalized_mean_absolute_error

As métricas usadas em cenários de Previsão de Série Temporal

As recomendações são semelhantes às observadas em cenários de regressão.

Métrica Exemplos de casos de uso
normalized_root_mean_squared_error Previsão de preço (previsão), otimização de estoque, previsão de demanda
r2_score Previsão de preço (previsão), otimização de estoque, previsão de demanda
normalized_mean_absolute_error

Métricas para cenários de Detecção de Objeto de Imagem

  • Para detecção de objeto de imagem, as métricas principais com suporte são definidas na Enumeração ObjectDetectionPrimaryMetrics

Métricas para cenários de segmentação de instância de imagem

  • Para cenários de segmentação de instância de imagem, as métricas principais com suporte são definidas na Enumeração InstanceSegmentationPrimaryMetrics

Definição de recursos de dados

Em cada experimento de ML automatizado, seus dados são automaticamente transformados em números e vetores de números e também dimensionados e normalizados para ajudar algoritmos que são sensíveis a recursos que estão em escalas diferentes. Essas transformações de dados são chamadas de definição de recursos.

Observação

As etapas de definição de recursos de machine learning automatizado (normalização de recursos, manipulação de dados ausentes, conversão de texto em números, etc.) tornam-se parte do modelo subjacente. Ao usar o modelo para previsões, as mesmas etapas de definição de recursos aplicadas durante o treinamento são aplicadas aos dados de entrada automaticamente.

Ao configurar seus trabalhos de ML automatizados, você pode habilitar/desabilitar as configurações featurization.

A tabela a seguir mostra as configurações aceitas para caracterização.

Configuração de definição de recursos Descrição
"mode": 'auto' Indica que, como parte do pré-processamento, verificadores de integridade dos dados e etapas de definição de recursos são executados automaticamente. Configuração padrão.
"mode": 'off' Indica que a etapa de definição de recursos não deve ser feita automaticamente.
"mode": 'custom' Indica que uma etapa de definição de recursos personalizada deve ser usada.

O código a seguir mostra como a caracterização personalizada pode ser fornecida nesse caso para um trabalho de regressão.

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"},
)

Critérios de saída

Há algumas opções que você pode definir na função set_limits() para encerrar o experimento antes da conclusão do trabalho.

Critérios descrição
Sem critérios Se você não definir nenhum parâmetro de saída, o experimento continuará até que nenhum progresso adicional seja feito na métrica primária.
timeout Define por quanto tempo, em minutos, o experimento deve continuar a ser executado. Se não for especificado, o tempo limite total padrão do trabalho será de seis dias (8.640 minutos). Para especificar um tempo limite menor ou igual a uma hora (60 minutos), verifique se o tamanho do conjunto de dados não é maior que 10.000.000 (linhas vezes coluna) ou se há erros.

Esse tempo limite inclui execuções de configuração, definição de recursos e treinamento, mas não inclui as execuções de explicação de modelo e montagem no final do processo, uma vez que essas ações precisam acontecer quando todas as avaliações (trabalhos filho) estiverem concluídas.
trial_timeout_minutes Tempo máximo em minutos em que cada avaliação (trabalho filho) pode ser executada antes de ser terminada. Se não for especificado, será usado um valor de 1 mês ou 43.200 minutos
enable_early_termination Se deve terminar o trabalho caso a pontuação não esteja melhorando em curto prazo
max_trials O número máximo de avaliações/execuções cada uma com uma combinação diferente de algoritmo e hiperparâmetros para tentar durante um trabalho do AutoML. Quando não é especificado, o padrão é 1.000 avaliações. Se usar enable_early_termination o número de avaliações usadas pode ser menor.
max_concurrent_trials Representa o número máximo de avaliações (trabalhos filhos) que seriam executadas em paralelo. É uma boa prática corresponder a esse número com o número de nós do cluster

Executar o experimento

Observação

Caso execute várias vezes um experimento com as mesmas definições de configuração e a mesma métrica primária, será possível ver uma variação na pontuação das métricas finais de cada experimento, bem como nos modelos gerados. Os algoritmos que o ML automatizado emprega têm uma aleatoriedade inerente. Por isso, o experimento pode causar uma ligeira variação na saída dos modelos e na pontuação final das métricas do modelo recomendado, como a precisão. Também será possível ver resultados com o mesmo nome do modelo, porém com diferentes hiperparâmetros usados.

Aviso

Se você tiver definido regras no firewall e/ou grupo de segurança de rede no workspace, verifique se as permissões necessárias foram concedidas aos tráfegos de rede de entrada e saída, conforme definido em Configurar os tráfegos de rede de entrada e saída.

Envie o experimento para ser executado e para gerar um modelo. Com o MLClient criado nos pré-requisitos, é possível executar o comando a seguir no workspace.


# 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

Várias execuções filhas em clusters

Execuções filhas de experimento de ML automatizados podem ser realizadas em um cluster que já esteja executando outro experimento. No entanto, o tempo depende de quantos nós o cluster tem e se esses nós estão disponíveis para executar um experimento diferente.

Cada nó no cluster atua como uma VM (máquina virtual) individual que pode realizar uma única execução de treinamento; para o ML automatizado, isso significa uma execução filha. Se todos os nós estiverem ocupados, um novo experimento será colocado na fila. Mas, se houver nós livres, o novo experimento executará a filha de ML automatizado em paralelo nos nós/VMs disponíveis.

Para ajudar a gerenciar as execuções filhas e quando elas podem ser executadas, recomendamos que você crie um cluster dedicado por experimento e coincida com o número de max_concurrent_iterations do seu experimento para o número de nós no cluster. Dessa forma, você usa todos os nós do cluster ao mesmo tempo com o número de execuções/iterações filhas simultâneas desejadas.

Configure max_concurrent_iterations na configuração limits. Se não estiver configurado, por padrão, apenas uma execução/iteração filha simultânea será permitida por experimento. No caso da instância de computação, é possível definir max_concurrent_trials com o mesmo o número de núcleos da VM da instância de computação.

Explorar modelos e métricas

O ML automatizado oferece opções para você monitorar e avaliar os resultados do treinamento.

Na interface do usuário do Azure Machine Learning na página do modelo, você também pode ver os hiperparâmetros usados ao treinar um modelo específico e ver e personalizar o código de treinamento do modelo interno usado.

Registro e implantação de modelos

Depois de testar um modelo e confirmar que deseja usá-lo na produção, você pode registrá-lo para uso posterior.

Dica

Para modelos registrados, a implantação com um clique está disponível por meio do Estúdio do Azure Machine Learning. Confira como implantar modelos registrados do estúdio.

AutoML em pipelines

Para aproveitar o AutoML nos fluxos de trabalho de MLOps, adicione etapas de Trabalho do AutoML aos pipelines do Azure Machine Learning. Isso permite automatizar todo o fluxo de trabalho conectando seus scripts de preparação de dados ao AutoML e, em seguida, registrando e validando o melhor modelo resultante.

Abaixo está um pipeline de exemplo com um componente de classificação do AutoML e um componente de comando que mostra a saída resultante do AutoML. Observe como as entradas (dados de validação e de treinamento) e as saídas (melhor modelo) são referenciadas em etapas diferentes.

# 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

Para obter mais exemplos sobre como incluir o AutoML em seus pipelines, confira nosso repositório de exemplos.

AutoML em escala: treinamento distribuído

Para cenários de dados grandes, o AutoML dá suporte ao treinamento distribuído para um conjunto limitado de modelos:

Algoritmo distribuído Tarefas com suporte Limite de tamanho de dados (aproximado)
LightGBM Classificação, regressão 1 TB
TCNForecaster Previsão 200GB

Algoritmos de treinamento distribuídos particionam automaticamente e distribuem seus dados entre vários nós de computação para treinamento de modelo.

Observação

Atualmente, não há suporte para validação cruzada, modelos de conjunto, suporte ao ONNX e geração de código no modo de treinamento distribuído. Além disso, o AutoML pode fazer escolhas como restringir os recursos disponíveis e os dados de sub-amostragem usados para validação, explicabilidade e avaliação de modelo.

Treinamento distribuído para classificação e regressão

Para usar o treinamento distribuído para classificação ou regressão, você precisa definir as propriedades training_mode e max_nodes do objeto de trabalho.

Propriedade Descrição
training_mode Indica o modo de treinamento; distributed ou non_distributed. Assume o padrão de non_distributed.
max_nodes O número de nós a serem usados para treinamento por cada avaliação do AutoML. A configuração deve ser maior ou igual a 4.

O exemplo de código a seguir mostra um exemplo dessas configurações para um trabalho de classificação:

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
)

Observação

Atualmente, o treinamento distribuído para tarefas de classificação e regressão não dá suporte a várias avaliações simultâneas. As avaliações de modelo são executadas sequencialmente com cada avaliação usando nós max_nodes. No momento, a configuração de limite max_concurrent_trials é ignorada.

Treinamento distribuído para previsão

Para saber como o treinamento distribuído funciona para tarefas de previsão, consulte nosso artigo previsão em escala. Para usar o treinamento distribuído para previsão, você precisa definir as propriedades training_mode, enable_dnn_training, max_nodes e, opcionalmente, max_concurrent_trials do objeto de trabalho.

Propriedade Descrição
training_mode Indica o modo de treinamento; distributed ou non_distributed. Assume o padrão de non_distributed.
enable_dnn_training Sinalizador para habilitar modelos de rede neural profundos.
max_concurrent_trials Esse é o número máximo de modelos de avaliação a serem treinados em paralelo. O valor padrão é 1.
max_nodes O número total de nós a serem usados para treinamento. Essa configuração deve ser maior ou igual a 2. Para tarefas de previsão, cada modelo de avaliação é treinado usando nós $\text{max}\left(2, \text{floor}( \text{max_nodes} / \text{max_concurrent_trials}) \right)$ .

O exemplo de código a seguir mostra um exemplo dessas configurações para um trabalho de previsão:

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
)

Consulte seções anteriores sobre configuração e envio de trabalho para obter exemplos de código de configuração completo.

Próximas etapas