Compartilhar via

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 artigo, aprenda a configurar um trabalho de treinamento de aprendizado de máquina automatizado (AutoML) com o Azure Machine Learning Python SDK v2. O ML automatizado escolhe um algoritmo e hiperparâmetros para você e gera um modelo pronto para implantação. Esse artigo fornece detalhes das várias opções que você pode usar para configurar experimentos automatizados de aprendizado de máquina.

Se você preferir uma experiência sem código, também pode Configurar treinamento de ML automatizado sem código para dados tabulares com a IU do estúdio.

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:

Configurar seu workspace

Para se conectar a um espaço de trabalho, você precisa fornecer uma assinatura, um grupo de recursos e um 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.

O exemplo a seguir usa a autenticação padrão do Azure com a configuração padrão do espaço de trabalho ou a configuração de um arquivo config.json na estrutura de pastas. Se não encontrar nenhum config.json, você precisará inserir manualmente o ID da assinatura, o grupo de recursos e o espaço de trabalho 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)

Especificar fonte de dados e formato

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

Requisitos para carregar dados em uma MLTable:

  • Os dados devem estar em formato de tabela.
  • O valor a ser previsto, coluna de destino, deve estar nos dados.

Os dados de treinamento devem ser acessíveis a partir da computação remota. O ML automatizado v2 (Python SDK e CLI/YAML) aceita ativos de dados MLTable (v2). Para compatibilidade com versões anteriores, ele também oferece suporte a conjuntos de dados tabulares v1 da v1, um conjunto de dados tabular registrado, por meio das mesmas propriedades do conjunto de dados de entrada. Recomendamos que você use o MLTable, disponível na v2. Nesse exemplo, os dados são 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, veja Trabalhando com tabelas no Azure Machine Learning.

Dados de treinamento, validação e teste

Você pode especificar conjuntos de dados de treinamento e de validação separados. Os dados de treinamento devem ser fornecidos ao parâmetro training_data na função de fábrica do seu trabalho de aprendizado de máquina automatizado.

Se você não especificar explicitamente um parâmetro validation_data ou n_cross_validation, o Automated ML aplicará técnicas padrão para determinar como a validação será realizada. 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 e 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 dados tiver menos de 1.000 linhas, serão usadas dobras décuplas.
Se as linhas forem iguais ou entre 1.000 e 20.000, três dobras serão usadas.

Computação para executar o experimento

Atualmente, trabalhos automatizados de aprendizado de máquina com o Python SDK v2 (ou CLI v2) só são suportados no cluster de computação remota ou na instância de computação do Azure Machine Learning. Para obter mais informações sobre como criar computação com o Python SDKv2 ou CLIv2, veja Treinar modelos com o Azure Machine Learning CLI, SDK e REST API.

Configurar as definições do experimento

Há várias opções que você pode usar para configurar experimentos de aprendizado de máquina 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 primária 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

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

O ML automatizado oferece suporte a diferentes tipos de tarefas:

  • Tarefas baseadas em dados tabulares

    • classificação
    • regressão
    • previsão

  • Tarefas de visão computacional, incluindo

    • Classificação de imagens
    • Detecção de objetos

  • Tarefas de processamento de linguagem natural, incluindo

    • Classificação de texto
    • Reconhecimento de Entidade

Para obter mais informações, veja os tipos de tarefas. Para obter mais informações sobre como configurar trabalhos de previsão, veja Configurar o AutoML para treinar um modelo de previsão de série temporal.

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 ou modelos a serem aplicados. Para modificar ainda mais as iterações com os modelos disponíveis para incluir ou excluir, use os parâmetros allowed_training_algorithms ou blocked_training_algorithms na configuração training do trabalho.

Na tabela a seguir, explore os algoritmos suportados por tarefa de aprendizado de máquina.

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 outros algoritmos:

Para exemplos de notebooks de cada tipo de tarefa, veja automl-standalone-jobs.

Métrica principal

O parâmetro primary_metric determina a métrica a ser usada durante o treinamento do modelo para otimização. O tipo de tarefa escolhido determina as métricas que você pode selecionar.

A escolha de uma métrica primária para otimização do aprendizado de máquina 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 perfil do seu conjunto de dados, incluindo tamanho dos dados, intervalo e distribuição de classe. 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.

Para saber mais sobre as definições específicas dessas métricas, veja Avaliar resultados de experimentos automatizados de aprendizado de máquina.

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 ou visão computacional e texto de processamento de linguagem natural (NLP-Text).

Métricas dependentes de limite, como accuracy, recall_score_weighted, norm_macro_recall, e precision_score_weighted podem não ser otimizadas tão bem para conjuntos de dados pequenos, com grande distorção de classe (desequilíbrio de classe) ou quando o valor da métrica esperado é 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 aprendizado de máquina automatizado, você pode escolher o modelo vencedor com base na métrica mais adequada às necessidades do seu negócio.

Metric Casos de uso de exemplo
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 classificação de texto com vários rótulos, atualmente “Precisão” é a única métrica primária suportada.

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

Métricas para cenários de Reconhecimento de Entidade Nomeada de texto NLP

Para o reconhecimento de entidade nomeada de texto NLP (NER), atualmente 'Precisão' é a única métrica primária suportada.

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 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 de todas as magnitudes da mesma forma e erros ao quadrado têm uma penalidade muito maior para erros com valores absolutos maiores. Dependendo se erros maiores devem ser mais punidos ou não, você pode escolher otimizar o erro quadrático 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 o modelo consegue capturar.

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 otimizarão o mesmo alvo, o erro quadrático 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 pode ser uma escolha melhor. Ele mede a correlação de classificação entre valores reais e previsões.

Atualmente, o ML automatizado não oferece 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. Em contraste, uma diferença percentual, que é uma medida relativa, gera erros de 50% e 0,05%, respectivamente. Para otimizar a diferença relativa, você pode executar o ML automatizado com uma métrica primária compatível e, em seguida, selecionar o modelo com a melhor mean_absolute_percentage_error ou root_mean_squared_log_error. Essas métricas são indefinidas quando quaisquer valores de observação são zero, portanto, elas nem sempre são boas escolhas.

Metric Casos de uso de exemplo
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 recomendações para cenários de regressão.

Metric Casos de uso de exemplo
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 objetos de imagem, as principais métricas suportadas 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 principais métricas suportadas são definidas na enumeração InstanceSegmentationPrimaryMetrics.

Definição de recursos de dados

Em cada experimento automatizado de aprendizado de máquina, seus dados são automaticamente transformados em números e vetores de números. Os dados também são 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

Etapas automatizadas de caracterização de aprendizado de máquina, como normalização de recursos, tratamento de dados ausentes e conversão de texto em numérico, tornam-se parte do modelo subjacente. Quando você usa o modelo para previsões, as mesmas etapas de caracterização aplicadas durante o treinamento são aplicadas aos seus dados de entrada automaticamente.

Ao configurar trabalhos automatizados de aprendizado de máquina, você pode habilitar ou 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, as proteções de dados e as etapas de caracterização são executadas automaticamente. Essa é a 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 set_limits() função para encerrar seu experimento antes que o trabalho seja concluído.

Critérios descrição
Sem critérios Se você não definir nenhum parâmetro de saída, o experimento continuará até que não haja mais progresso na sua métrica principal.
timeout Define por quanto tempo, em minutos, o experimento deve continuar a ser executado. Se não for especificado, o tempo limite total do trabalho padrão 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, caracterização e treinamento, mas não inclui as execuções de montagem e explicabilidade do modelo no final do processo, pois essas ações precisam acontecer depois que todos os testes (tarefas filhas) forem concluídos.
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 43200 minutos.
enable_early_termination Se deve ou não encerrar o trabalho caso a pontuação não melhore no curto prazo.
max_trials O número máximo de testes/execuções, cada um com uma combinação diferente de algoritmo e hiperparâmetros a serem tentados durante um trabalho. Se não for especificado, o padrão é 1.000 testes. Se você usar enable_early_termination, o número de testes usados ​​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 combinar esse número com o número de nós do seu cluster.

Executar o experimento

Envie o experimento para ser executado e para gerar um modelo.

Observação

Se você executar um experimento com as mesmas configurações e métricas primárias várias vezes, poderá ver variações na pontuação final das métricas de cada experimento e nos modelos gerados. Os algoritmos que o aprendizado de máquina automatizado emprega têm aleatoriedade inerente que pode causar pequenas variações na saída dos modelos pelo experimento e na pontuação final das métricas do modelo recomendado, como precisão. Você também pode ver resultados com o mesmo nome de modelo, mas diferentes hiperparâmetros usados.

Aviso

Se você tiver definido regras no firewall ou no Grupo de Segurança de Rede em seu espaço de trabalho, verifique se as permissões necessárias foram fornecidas ao tráfego de rede de entrada e saída, conforme definido em Configurar tráfego de rede de entrada e saída.

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 máquina virtual (VM) individual que pode realizar uma única execução de treinamento. Para ML automatizado, esse fato significa uma corrida infantil. Se todos os nós estiverem ocupados, um novo experimento será colocado na fila. Se houver nós livres, o novo experimento executará execuções filhas em paralelo nos nós ou máquinas virtuais disponíveis.

Para ajudar a gerenciar execuções secundárias e quando elas podem ser executadas, recomendamos que você crie um cluster dedicado por experimento e corresponda o número de max_concurrent_iterations do seu experimento ao 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 simultâneas de filhos e iterações que desejar.

Configure max_concurrent_iterations na configuração limits. Se não estiver configurado, por padrão, apenas uma execução/iteração simultânea do filho será permitida por experimento. Para uma instância de computação, max_concurrent_trials pode ser definido como o mesmo que o número de núcleos na máquina virtual 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 visualizar os hiperparâmetros usados ​​ao treinar um modelo específico, além de visualizar 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, você pode usar a implantação de um clique usando o Estúdio do Azure Machine Learning. Veja Implantar seu modelo.

Use AutoML em pipelines

Para usar o ML automatizado em seus fluxos de trabalho de operações de aprendizado de máquina, você pode adicionar etapas de trabalho do AutoML aos seus Azure Machine Learning Pipelines. Essa abordagem permite que você automatize todo o seu fluxo de trabalho conectando seus scripts de preparação de dados ao Automated ML. Em seguida, registre e valide o melhor modelo resultante.

Esse código é um pipeline de exemplo com um componente de classificação de ML automatizado e um componente de comando que mostra a saída resultante. O código faz referência às entradas (dados de treinamento e validação) e às saídas (melhor modelo) em diferentes etapas.

# 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 mais exemplos de como incluir ML automatizado em seus pipelines, veja o repositório de exemplos.

Use AutoML em escala: treinamento distribuído

Para cenários de grandes volumes de dados, o ML automatizado oferece 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 200 GB

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 ML automático pode fazer escolhas como restringir os recursos disponíveis e subamostrar dados usados ​​para validação, explicabilidade e avaliação de modelos.

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

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

Propriedade Descrição
training_mode Indica 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 em cada teste. 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, veja 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 valor é o número máximo de modelos de teste 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
)

Para obter amostras do código de configuração completo, veja as seções anteriores sobre configuração e envio de trabalho.

Conteúdo relacionado