Configurar a preparação do AutoML com o SDK Python V2 do Azure ML

APLICA-SE A: SDK python azure-ai-ml v2 (atual)

Neste guia, saiba como configurar uma tarefa automatizada de machine learning, AutoML e preparação com o SDK Python v2 do Azure Machine Learning. O ML automatizado escolhe um algoritmo e hiperparâmetros para si e gera um modelo pronto para implementação. Este guia fornece detalhes das várias opções que pode utilizar para configurar experimentações de ML automatizadas.

Se preferir uma experiência sem código, também pode Configurar a preparação de AutoML sem código no estúdio do Azure Machine Learning.

Se preferir submeter tarefas de preparação com a extensão da CLI v2 do Azure Machine learning, consulte Preparar modelos.

Pré-requisitos

Para este artigo, precisa de:

Configurar a área de trabalho

Para ligar a uma área de trabalho, tem de fornecer uma subscrição, um grupo de recursos e um nome de área de trabalho. Estes detalhes são utilizados no MLClientazure.ai.ml para obter uma alça para a área de trabalho do Azure Machine Learning necessária.

No exemplo seguinte, a autenticação predefinida do Azure é utilizada juntamente com a configuração da área de trabalho predefinida ou de qualquer config.json ficheiro que possa ter copiado para a estrutura de pastas. Se não config.json for encontrado, terá de introduzir manualmente o subscription_id, resource_group e área de trabalho ao criar 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 AzureML workspace
    subscription_id = "<SUBSCRIPTION_ID>"
    resource_group = "<RESOURCE_GROUP>"
    workspace = "<AZUREML_WORKSPACE_NAME>"
    ml_client = MLClient(credential, subscription_id, resource_group, workspace)

Origem de dados e formato

Para fornecer dados de preparação para o AutoML no SDK v2, tem de carregá-lo para a cloud através de uma MLTable.

Requisitos para carregar dados para uma MLTable:

  • Os dados têm de estar em formato tabular.
  • O valor a prever, coluna de destino, tem de estar nos dados.

Os dados de preparação têm de estar acessíveis a partir da computação remota. O ML v2 automatizado (SDK Python e CLI/YAML) aceita recursos de dados MLTable (v2), embora para retrocompatibilidade também suporte conjuntos de dados tabulares v1 da v1 (um Conjunto de Dados Tabular registado) através das mesmas propriedades do conjunto de dados de entrada. No entanto, a recomendação é utilizar a MLTable disponível na v2.

O seguinte código YAML é a definição de uma MLTable que pode ser colocada numa pasta local ou numa pasta remota na cloud, juntamente com o ficheiro de dados (.CSV ou ficheiro Parquet).

# MLTable definition file

paths:
  - file: ./bank_marketing_train_data.csv
transformations:
  - read_delimited:
        delimiter: ','
        encoding: 'ascii'

Por conseguinte, a pasta MLTable teria o ficheiro de definição MLTable mais o ficheiro de dados (o ficheiro bank_marketing_train_data.csv neste caso).

O seguinte mostra duas formas de criar uma MLTable.

  • A. Fornecer os dados de preparação e o ficheiro de definição de MLTable a partir da pasta local e serão carregados automaticamente para a cloud (Arquivo de Dados da Área de Trabalho predefinido)
  • B. Fornecer uma MLTable já registada e carregada para a cloud.
from azure.ai.ml.constants import AssetTypes
from azure.ai.ml import automl, Input

# A. Create MLTable for training data from your local directory
my_training_data_input = Input(
    type=AssetTypes.MLTABLE, path="./data/training-mltable-folder"
)

# B. Remote MLTable definition
my_training_data_input  = Input(type=AssetTypes.MLTABLE, path="azureml://datastores/workspaceblobstore/paths/Classification/Train")

Dados de preparação, validação e teste

Pode especificar dados de preparação separados e conjuntos de dados de validação. No entanto, os dados de preparação têm de ser fornecidos ao training_data parâmetro na função de fábrica da tarefa de ML automatizada.

Se não especificar explicitamente um validation_data parâmetro ou n_cross_validation , o ML automatizado aplica técnicas predefinidas para determinar como a validação é executada. Esta determinação depende do número de linhas no conjunto de dados atribuído ao seu training_data parâmetro.

Tamanho dos dados de preparação Técnica de validação
Maior que 20 000 linhas A divisão de dados de preparação/validação é aplicada. A predefinição é assumir 10% do conjunto de dados de preparação inicial como o conjunto de validação. Por sua vez, esse conjunto de validação é utilizado para cálculo de métricas.
Menor ou igual a 20 000 linhas É aplicada uma abordagem de validação cruzada. O número predefinido de pastas depende do número de linhas.
Se o conjunto de dados for inferior a 1000 linhas, são utilizadas 10 pastas.
Se as linhas forem iguais ou entre 1000 e 20 000, são utilizadas três pastas.

Computação para executar a experimentação

Atualmente, as tarefas de ML automatizadas com o SDK Python v2 (ou CLI v2) só são suportadas na computação remota do Azure ML (instância de cluster ou computação).

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

Configurar as definições de experimentação

Existem várias opções que pode utilizar para configurar a experimentação de ML automatizada. Estes parâmetros de configuração são definidos no seu método de tarefa. Também pode definir definições de preparação de trabalhos e critérios de saída com as set_training() funções e set_limits() , respetivamente.

O exemplo seguinte mostra os parâmetros necessários para uma tarefa de classificação que especifica a precisão como a métrica primária e 5 pastas de validação cruzada.

# note that the below is a code snippet -- you might have to modify the variable values to run it successfully
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=["LogisticRegression"], 
    enable_onnx_compatible_models=True
)

Selecione o tipo de tarefa de machine learning (problema de ML)

Antes de poder submeter a tarefa de ML automatizada, tem de determinar o tipo de problema de machine learning que está a resolver. Este problema determina a função que a tarefa de ML automatizada utiliza e que algoritmos de modelo se aplicam.

O ML Automatizado suporta tarefas baseadas em dados tabulares (classificação, regressão, previsão), tarefas de imagem digitalizada (como Classificação de Imagens e Deteção de Objetos) e tarefas de processamento de linguagem natural (como classificação de texto e tarefas de Reconhecimento de Entidades). Saiba mais sobre os tipos de tarefas.

Algoritmos suportados

O machine learning automatizado tenta diferentes modelos e algoritmos durante o processo de automatização e otimização. Enquanto utilizador, não é necessário especificar o algoritmo.

O método de tarefa determina a lista de algoritmos/modelos a aplicar. Utilize os allowed_training_algorithms parâmetros ou blocked_training_algorithms na set_training() função setter para modificar ainda mais as iterações com os modelos disponíveis para incluir ou excluir.

Na seguinte lista de ligações, pode explorar os algoritmos suportados por tarefa de machine learning listada abaixo.

Classificação Regressão Previsão de Série Temporal
Regressão Logística* Rede Elástica* AUTOARIMA
GBM claro* GBM claro* Profeta
Aumento de Gradação* Aumento de Gradação* Elastic Net
Árvore de Decisões* Árvore de Decisões* GBM claro
K Vizinhos Mais Próximos* K Vizinhos Mais Próximos* K Vizinhos Mais Próximos
Linear SVC* Laço LARS* Árvore de Decisões
Classificação de Vetores de Suporte (SVC)* Descendente de Gradação Estocástica (SGD)* 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 PrevisãoTCN
Descendente de Gradação Estocástica (SGD)* Descendente de Gradação Estocástica (SGD) Aumento de Gradação
ExponentialSmoothing
SazonalNaive
Média
Naive
SazonalAverage

Com algoritmos adicionais abaixo.

Siga esta ligação para, por exemplo, blocos de notas de cada tipo de tarefa.

Métrica primária

O primary_metric parâmetro determina a métrica a utilizar durante a preparação de modelos para otimização. As métricas disponíveis que pode selecionar são determinadas pelo tipo de tarefa que escolher.

Escolher uma 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 as suas necessidades empresariais. Em seguida, considere se a métrica é adequada para o seu perfil de conjunto de dados (tamanho de dados, intervalo, distribuição de classes, etc.). As secções seguintes resumem as métricas primárias recomendadas com base no tipo de tarefa e no cenário empresarial.

Saiba mais sobre as definições específicas destas métricas em Compreender os resultados de machine learning automatizados.

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

Estas métricas aplicam-se a todos os cenários de classificação, incluindo dados tabulares, imagens/imagem digitalizada e NLP-Text.

As métricas dependentes de limiares, como accuracy, recall_score_weighted, norm_macro_recalle precision_score_weighted podem não ser otimizadas também para conjuntos de dados pequenos, têm distorção de classe grande (desequilíbrio de classe) ou quando o valor de métrica esperado está muito próximo de 0,0 ou 1,0. Nesses casos, AUC_weighted pode ser uma escolha melhor para a métrica primária. Após a conclusão do ML automatizado, pode escolher o modelo vencedor com base na métrica mais adequada às suas necessidades empresariais.

Metric Casos de utilização de exemplo
accuracy Classificação de imagens, Análise de sentimentos, predição de Churn
AUC_weighted Deteção de fraudes, Classificação de imagens, Deteção de anomalias/deteção de spam
average_precision_score_weighted Análise de sentimentos
norm_macro_recall Predição de alterações
precision_score_weighted

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

  • Para Classificação de texto, atualmente, a "Precisão" de várias etiquetas é a única métrica primária suportada.

  • Para Etiquetas múltiplas de classificação de imagens, as métricas primárias suportadas são definidas no ClassificationMultilabelPrimaryMetrics Enum

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

  • Para o NLP Text NER (Reconhecimento de Entidade Nomeada) atualmente "Precisão" é a única métrica primária suportada.

Métricas para cenários de regressão

r2_scoree normalized_mean_absolute_errornormalized_root_mean_squared_error estão todos a tentar minimizar os erros de predição. r2_score e normalized_root_mean_squared_error estão a minimizar os erros quadrados médios enquanto normalized_mean_absolute_error está a minimizar o valor absoluto médio dos erros. O valor absoluto trata os erros de todas as magnitudes e os erros quadrados terão uma penalização muito maior por erros com valores absolutos maiores. Dependendo se os erros maiores devem ou não ser punidos, pode 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 forma como são normalizados e os seus significados. normalized_root_mean_squared_error é um erro quadrado médio de raiz normalizado por intervalo e pode ser interpretado como a magnitude média do erro para a predição. r2_score é um erro quadrado médio normalizado por uma estimativa da variância dos dados. É a proporção de variação que pode ser capturada pelo modelo.

Nota

r2_score e normalized_root_mean_squared_error também se comportam da mesma forma que as métricas primárias. Se for aplicado um conjunto de validação fixo, estas duas métricas estão a otimizar o mesmo destino, erro quadrado médio e serão otimizadas pelo mesmo modelo. Quando apenas um conjunto de preparação está disponível e a validação cruzada é aplicada, seria ligeiramente diferente, uma vez que o normalizador para normalized_root_mean_squared_error é corrigido como o intervalo de conjunto de preparação, mas o normalizador para r2_score variaria para cada dobra, uma vez que é a variância para cada dobra.

Se a classificação, em vez do valor exato for de interesse, pode ser uma escolha melhor, spearman_correlation uma vez que mede a correlação de classificação entre valores reais e predições.

No entanto, atualmente, nenhuma métrica primária para regressão resolve a diferença relativa. Todos , normalized_mean_absolute_errore normalized_root_mean_squared_error tratem um erro de predição de r2_score20 mil $ da mesma forma para um trabalhador com um salário de 30 mil dólares como um trabalhador a ganhar 20 milhões de dólares, se estes dois pontos de dados pertencerem ao mesmo conjunto de dados para regressão ou à mesma série temporal especificada pelo identificador da série temporal. Na realidade, prever apenas 20 mil dólares de um salário de 20 milhões de dólares é muito próximo (uma pequena diferença relativa de 0,1%), enquanto os 20 mil dólares de 30 mil dólares não são fechados (uma grande diferença relativa de 67%). Para resolver o problema da diferença relativa, pode preparar um modelo com métricas primárias disponíveis e, em seguida, selecionar o modelo com o melhor mean_absolute_percentage_error ou root_mean_squared_log_error.

Metric Casos de utilização de exemplo
spearman_correlation
normalized_root_mean_squared_error Predição de preços (casa/produto/sugestão), Previsão de classificação de revisão
r2_score Atraso da companhia aérea, Estimativa salarial, Tempo de resolução de erros
normalized_mean_absolute_error

Métricas para cenários de Previsão de Série Temporal

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

Metric Casos de utilização de exemplo
normalized_root_mean_squared_error Predição de preços (previsão), Otimização do inventário, Previsão da procura
r2_score Predição de preços (previsão), Otimização do inventário, Previsão da procura
normalized_mean_absolute_error

Métricas para cenários de Deteção de Objetos de Imagem

  • Para Deteção de Objetos de Imagem, as métricas primárias suportadas são definidas na Enum ObjectDetectionPrimaryMetrics

Métricas para cenários de Segmentação de Instâncias de Imagem

  • Para cenários de Segmentação de Instâncias de Imagem, as métricas primárias suportadas são definidas no InstanceSegmentationPrimaryMetrics Enum

Caracterização de dados

Em cada experimentação de ML automatizada, os seus dados são automaticamente transformados em números e vetores de números mais (ou seja, converter texto em numérico) também dimensionados e normalizados para ajudar determinados algoritmos sensíveis a funcionalidades que estão em escalas diferentes. Esta transformação de dados, dimensionamento e normalização é referida como caracterização.

Nota

Os passos de caracterização de machine learning automatizados (normalização de funcionalidades, processamento de dados em falta, conversão de texto em numérico, etc.) tornam-se parte do modelo subjacente. Ao utilizar o modelo para predições, os mesmos passos de caracterização aplicados durante a preparação são aplicados automaticamente aos dados de entrada.

Ao configurar as suas tarefas de ML automatizadas, pode ativar/desativar as featurization definições com a .set_featurization() função setter.

A tabela seguinte mostra as definições aceites para caracterização.

Configuração de Caracterização Descrição
"mode": 'auto' Indica que, como parte do pré-processamento, as proteções de dados e os passos de caracterização são executados automaticamente. Predefinição.
"mode": 'off' Indica que o passo de caracterização não deve ser feito automaticamente.
"mode": 'custom' Indica que deve ser utilizado o passo de caracterização personalizado.

O código seguinte mostra como a caracterização personalizada pode ser fornecida neste caso para uma tarefa 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

Existem algumas opções que pode definir na set_limits() função para terminar a experimentação antes da conclusão da tarefa.

Critérios descrição
Sem critérios Se não definir parâmetros de saída, a experimentação continuará até que não sejam feitos mais progressos na métrica primária.
timeout Define quanto tempo, em minutos, a sua experimentação deve continuar a ser executada. Se não for especificado, o tempo limite total da tarefa predefinida é de 6 dias (8.640 minutos). Para especificar um tempo limite inferior ou igual a 1 hora (60 minutos), certifique-se de que o tamanho do conjunto de dados não é superior a 10 000 000 (linhas vezes coluna) ou resultados de erros.

Este tempo limite inclui execuções de configuração, caracterização e preparação, mas não inclui as execuções de explicação de modelos e de emembling no final do processo, uma vez que essas ações têm de ocorrer assim que todas as avaliações (trabalhos subordinados) forem efetuadas.
trial_timeout_minutes Tempo máximo em minutos para o qual cada avaliação (tarefa subordinada) pode ser executada antes de terminar. Se não for especificado, é utilizado um valor de 1 mês ou 43200 minutos
enable_early_termination Se pretende terminar a tarefa se a classificação não estiver a melhorar a curto prazo
max_trials O número máximo de tentativas/execuções cada uma com uma combinação diferente de algoritmos e hiperparâmetros a experimentar durante uma tarefa de AutoML. Se não for especificado, a predefinição é 1000 avaliações. Se utilizar enable_early_termination o número de avaliações utilizadas pode ser menor.
max_concurrent_trials Representa o número máximo de avaliações (trabalhos subordinados) que seriam executadas em paralelo. É uma boa prática corresponder este número ao número de nós do cluster

Executar experimentação

Nota

Se executar uma experimentação com as mesmas definições de configuração e métrica primária várias vezes, provavelmente verá variação em cada classificação de métricas final de experimentações e modelos gerados. Os algoritmos utilizados pelo ML automatizado têm aleatoriedade inerente que pode causar uma ligeira variação na saída dos modelos pela experimentação e a classificação de métricas final do modelo recomendado, como a precisão. Provavelmente também verá resultados com o mesmo nome de modelo, mas diferentes hiperparâmetros utilizados.

Aviso

Se tiver definido regras na firewall e/ou grupo de segurança de rede através da área de trabalho, verifique se as permissões necessárias são concedidas ao tráfego de rede de entrada e saída, conforme definido em Configurar tráfego de rede de entrada e saída.

Submeta a experimentação para executar e gerar um modelo. Com os MLClient criados nos pré-requisitos, pode executar o seguinte comando na área de trabalho.


# 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 subordinadas em clusters

As execuções subordinadas de experimentação de ML automatizadas podem ser executadas num cluster que já está a executar outra experimentação. No entanto, a temporização depende do número de nós que o cluster tem e se esses nós estão disponíveis para executar uma experimentação diferente.

Cada nó no cluster atua como uma máquina virtual (VM) individual que pode realizar uma única execução de preparação; para ML automatizado, isto significa uma execução subordinada. Se todos os nós estiverem ocupados, a nova experimentação será colocada em fila. No entanto, se existirem nós gratuitos, a nova experimentação executará execuções subordinadas de ML automatizadas em paralelo nos nós/VMs disponíveis.

Para ajudar a gerir as execuções subordinadas e quando podem ser executadas, recomendamos que crie um cluster dedicado por experimentação e corresponda o número da max_concurrent_iterations experimentação ao número de nós no cluster. Desta forma, utiliza todos os nós do cluster ao mesmo tempo com o número de execuções/iterações subordinadas em simultâneo que pretende.

Configure max_concurrent_iterations na função setter .set_limits(). Se não estiver configurado, por predefinição, só é permitida uma execução/iteração subordinada simultânea por experimentação. Em caso de instância de computação, max_concurrent_trials pode ser definido como sendo o mesmo que o número de núcleos na VM da instância de computação.

Explorar modelos e métricas

O ML Automatizado oferece opções para monitorizar e avaliar os resultados da preparação.

Na IU do Azure Machine Learning na página do modelo, também pode ver os hiperparâmetros utilizados ao preparar um modelo específico e também ver e personalizar o código de preparação do modelo interno utilizado.

Registar e implementar modelos

Depois de testar um modelo e confirmar que pretende utilizá-lo em produção, pode registá-lo para utilização posterior.

Dica

Para modelos registados, a implementação com um clique está disponível através do estúdio do Azure Machine Learning. Veja como implementar modelos registados a partir do estúdio.

AutoML em pipelines

Para tirar partido do AutoML nos fluxos de trabalho do MLOps, pode adicionar passos de Tarefa autoML aos Pipelines do AzureML. Isto permite-lhe automatizar todo o fluxo de trabalho ao ligar os scripts de preparação de dados ao AutoML e, em seguida, registar e validar o melhor modelo resultante.

Segue-se um pipeline de exemplo com um componente de classificação AutoML e um componente de comando que mostra a saída automática resultante do AutoML. Tenha em atenção como as entradas (dados de validação de preparação & ) e as saídas (melhor modelo) são referenciadas em passos 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_classification = automl_classification(
    classification_train_data=Input(path="./training-mltable-folder/", type="mltable"),
    classification_validation_data=Input(path="./validation-mltable-folder/", type="mltable"),
)

# ...
# Note that the above is only 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 nos seus pipelines, consulte o nosso repositório de exemplos.

Passos seguintes