Configurar o AutoML para treinar um modelo de previsão de séries temporais com o SDK e a CLI

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

Neste artigo, você aprenderá a configurar o AutoML para previsão de séries temporais com o ML automatizado do Azure Machine Learning no SDK do Python do Azure Machine Learning.

Para fazer isso, você deve:

  • Prepare dados para treinamento.
  • Configure parâmetros de série temporal específicos em um trabalho de série temporal.
  • Orquestrar treinamento, inferência e avaliação de modelo usando componentes e pipelines.

Para uma experiência com pouco código, consulte o Tutorial: Prever a demanda com o machine learning automatizado para conhecer um exemplo de previsão de série temporal usando o AutoML no Estúdio do Azure Machine Learning.

O AutoML usa modelos de machine learning padrão junto com modelos de série temporal conhecidos para criar previsões. Nossa abordagem incorpora informações históricas sobre a variável de destino, os recursos fornecidos pelo usuário nos dados de entrada e os recursos projetados automaticamente. Os algoritmos de pesquisa de modelo funcionam para encontrar um modelo com a melhor precisão preditiva. Para obter mais detalhes, confira nossos artigos sobre metodologia de previsão e pesquisa de modelo.

Pré-requisitos

Para este artigo, você precisa,

Dados de treinamento e validação

Os dados de entrada para previsão do AutoML devem conter séries temporais válidas no formato tabular. Cada variável deve ter sua própria coluna correspondente na tabela de dados. O AutoML requer pelo menos duas colunas: uma coluna de tempo que representa o eixo de tempo e a coluna de destino, que é a quantidade a ser prevista. Outras colunas podem servir como preditores. Para obter mais detalhes, confira como o AutoML usa seus dados.

Importante

Ao treinar um modelo para prever valores futuros, verifique se todos os recursos usados no treinamento podem ser usados ao executar previsões para o horizonte pretendido.

Por exemplo, um recurso para o preço de ações atual poderia aumentar imensamente a precisão do treinamento. No entanto, se você pretende fazer uma previsão com horizonte longo, talvez não seja possível prever com precisão valores de ações futuros correspondentes a pontos de série temporal futuros, e a precisão do modelo poderá ser prejudicada.

Os trabalhos de previsão do AutoML exigem que os dados de treinamento sejam representados como um objeto MLTable. Um MLTable especifica uma fonte de dados e as etapas para carregar os dados. Para obter mais informações e casos de uso, confira o guia de instruções do MLTable. Como um exemplo simples, suponha que os dados de treinamento estão contidos em um arquivo CSV em um diretório local, ./train_data/timeseries_train.csv.

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

import mltable

paths = [
    {'file': './train_data/timeseries_train.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 você define um objeto de dados de entrada, que é necessário para iniciar um trabalho de treinamento, usando o SDK do Python para Azure Machine Learning da seguinte forma:

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

# Training MLTable defined locally, with local data to be uploaded
my_training_data_input = Input(
    type=AssetTypes.MLTABLE, path="./train_data"
)

Você especifica os dados de validação de maneira semelhante, criando uma MLTable e especificando uma entrada de dados de validação. Como alternativa, se você não fornecer dados de validação, o AutoML criará automaticamente divisões de validação cruzada de seus dados de treinamento a serem usadas para seleção de modelo. Confira nosso artigo sobre a seleção do modelo de previsão para obter mais detalhes. Confira também os requisitos de comprimento dos dados de treinamento para obter detalhes sobre a quantidade de dados de treinamento necessários para treinar com êxito um modelo de previsão.

Saiba mais sobre como o AutoML aplica a validação cruzada para evitar sobreajuste.

Computação para executar o experimento

O AutoML usa a Computação do Azure Machine Learning, que é um recurso de computação totalmente gerenciado, para executar o trabalho de treinamento. Nos exemplos a seguir, um cluster de cálculo denominado cpu-compute é criado:

from azure.ai.ml.entities import AmlCompute

# specify aml compute name.
cpu_compute_target = "cpu-cluster"

try:
    ml_client.compute.get(cpu_compute_target)
except Exception:
    print("Creating a new cpu compute target...")
    compute = AmlCompute(
        name=cpu_compute_target, size="STANDARD_D2_V2", min_instances=0, max_instances=4
    )
    ml_client.compute.begin_create_or_update(compute).result()

Configurar o experimento

Você usa as funções de fábrica de AutoML para configurar trabalhos de previsão no SDK do Python. O exemplo a seguir mostra como criar um trabalho de previsão definindo a métrica primária e limites de conjunto na execução de treinamento:

from azure.ai.ml import automl

# note that the below is a code snippet -- you might have to modify the variable values to run it successfully
forecasting_job = automl.forecasting(
    compute="cpu-compute",
    experiment_name="sdk-v2-automl-forecasting-job",
    training_data=my_training_data_input,
    target_column_name=target_column_name,
    primary_metric="normalized_root_mean_squared_error",
    n_cross_validations="auto",
)

# Limits are all optional
forecasting_job.set_limits(
    timeout_minutes=120,
    trial_timeout_minutes=30,
    max_concurrent_trials=4,
)

Configurações do trabalho de previsão

As tarefas de previsão têm muitas configurações específicas para previsão. As configurações mais básicas são o nome da coluna de tempo nos dados de treinamento e no horizonte de previsão.

Use os métodos ForecastingJob para definir estas configurações:

# Forecasting specific configuration
forecasting_job.set_forecast_settings(
    time_column_name=time_column_name,
    forecast_horizon=24
)

O nome da coluna de tempo é uma configuração necessária e você geralmente deve definir o horizonte de previsão de acordo com o cenário de previsão. Se os dados contiverem várias séries temporais, você poderá especificar os nomes das colunas de ID da série temporal. Essas colunas, quando agrupadas, definem a série individual. Por exemplo, suponha que você tenha dados que consistem em vendas por hora de diferentes lojas e marcas. O exemplo a seguir mostra como definir as colunas de ID da série temporal supondo que os dados contenham colunas chamadas "store" e "brand":

# Forecasting specific configuration
# Add time series IDs for store and brand
forecasting_job.set_forecast_settings(
    ...,  # other settings
    time_series_id_column_names=['store', 'brand']
)

O AutoML tentará detectar automaticamente colunas de ID da série temporal em seus dados se nenhuma for especificada.

Outras configurações são opcionais e são revisadas na próxima seção.

Configurações opcionais do trabalho de previsão

Configurações opcionais estão disponíveis para tarefas de previsão, como habilitar o aprendizado profundo e especificar uma agregação de janelas sem interrupção como destino. Uma lista completa de parâmetros está disponível na documentação de referência de previsão.

Configurações de pesquisa de modelo

Há duas configurações opcionais que controlam o espaço do modelo em que o AutoML procura o melhor modelo, allowed_training_algorithms e blocked_training_algorithms. Para restringir o espaço de pesquisa a um determinado conjunto de classes de modelo, use o parâmetro allowed_training_algorithms como no seguinte exemplo:

# Only search ExponentialSmoothing and ElasticNet models
forecasting_job.set_training(
    allowed_training_algorithms=["ExponentialSmoothing", "ElasticNet"]
)

Nesse caso, o trabalho de previsão pesquisa apenas as classes de modelo Exponential Smoothing e Elastic Net. Para remover um determinado conjunto de classes de modelo do espaço de pesquisa, use o blocked_training_algorithms como no exemplo a seguir:

# Search over all model classes except Prophet
forecasting_job.set_training(
    blocked_training_algorithms=["Prophet"]
)

Agora, o trabalho pesquisa todas as classes de modelo, exceto Prophet. Para obter uma lista de nomes de modelo de previsão aceitos em allowed_training_algorithms e blocked_training_algorithms, confira a documentação de referência de propriedades de treinamento. allowed_training_algorithms ou blocked_training_algorithms, mas não ambos, pode ser aplicado a uma execução de treinamento.

Habilitar o aprendizado profundo

O AutoML é fornecido com um modelo de DNN (rede neural profunda) personalizado chamado TCNForecaster. Esse modelo é uma rede convolucional temporal, ou TCN, que aplica métodos comuns de tarefa de geração de imagens à modelagem de série temporal. Ou seja, as convoluções "causais" unidimensionais formam a espinha dorsal da rede e permitem que o modelo aprenda padrões complexos por longas durações no histórico de treinamento. Para saber mais, confira o artigo sobre o TCNForecaster.

Diagrama mostrando os principais componentes do TCNForecaster do AutoML.

O TCNForecaster geralmente obtém maior precisão do que os modelos de séries temporais padrão quando há milhares ou mais observações no histórico de treinamento. No entanto, também leva mais tempo para treinar e varrer os modelos do TCNForecaster devido à sua maior capacidade.

Você pode ativar o TCNForecaster no AutoML definindo o sinalizador enable_dnn_training na configuração de treinamento da seguinte maneira:

# Include TCNForecaster models in the model search
forecasting_job.set_training(
    enable_dnn_training=True
)

Por padrão, o treinamento TCNForecaster é limitado a um único nó de computação e a uma única GPU, se disponível, por avaliação de modelo. Para cenários de dados grandes, recomendamos distribuir cada avaliação de TCNForecaster em vários núcleos/GPUs e nós. Confira nossa seção de artigo sobre treinamento distribuído para obter mais informações e exemplos de código.

Para habilitar o DNN para um experimento do AutoML criado no Azure Machine Learning Studio, confira as configurações de tipo de tarefa nas instruções da interface do usuário do estúdio.

Observação

  • Quando você habilita o DNN para experimentos criados com o SDK, as melhores explicações de modelo são desabilitadas.
  • O suporte de DNN para previsão em machine learning automatizado não tem suporte para execuções locais ou execuções iniciadas no Databricks.
  • Os tipos de computação de GPU são recomendados quando o treinamento de DNN está habilitado

Recursos de retardo e janela sem interrupção

Os valores recentes do destino geralmente são recursos impactantes em um modelo de previsão. Assim, o AutoML pode criar recursos de agregação de janela sem interrupção e com travamento de tempo para potencialmente melhorar a precisão do modelo.

Considere um cenário de previsão da demanda de energia em que os dados meteorológicos e a demanda histórica estão disponíveis. A tabela mostra a engenharia de recursos resultante que ocorre quando a agregação de janela é aplicada nas três últimas horas. Colunas para mínimo, máximo e soma são geradas em uma janela deslizante de três horas com base nas configurações definidas. Por exemplo, para a observação válida em 8 de setembro de 2017 às 4:00, os valores máximo, mínimo e soma são calculados usando os valores de demanda para 8 de setembro de 2017 de 1:00 às 3:00. Essa janela de três horas se desloca para preencher os dados das linhas restantes. Para obter mais detalhes e exemplos, confira o artigo de recurso de atraso.

Janelas sem interrupção como destino

Você pode habilitar recursos de agregação de janela sem interrupção e retardo para o destino definindo o tamanho da janela sem interrupção, que era três no exemplo anterior, e os pedidos de retardo que você deseja criar. Você também pode habilitar atrasos para recursos com a configuração feature_lags. No exemplo a seguir, definimos todas essas configurações como auto para que o AutoML determine automaticamente as configurações analisando a estrutura de correlação de seus dados:

forecasting_job.set_forecast_settings(
    ...,  # other settings
    target_lags='auto', 
    target_rolling_window_size='auto',
    feature_lags='auto'
)

Manipulação de séries curtas

O ML automatizado considera uma série temporal uma pequena sequência se não houver pontos de dados suficientes para conduzir as fases de treinamento e validação do desenvolvimento de modelo. Confira requisitos de comprimento de dados de treinamento para obter mais detalhes sobre os requisitos de comprimento.

O AutoML tem várias ações que podem ser executadas para séries curtas. Essas ações são configuráveis com short_series_handling_config. O valor padrão é "auto". A tabela a seguir descreve as configurações:

Configuração Descrição
auto O valor padrão para tratamento de série curta.
- Se todas as séries forem curtas, preencha os dados.
- Se nem todas as séries forem curtas, descarte as séries curtas.
pad Se short_series_handling_config = pad, o ML automatizado adiciona valores aleatórios a cada série curta encontrada. A seguir, a lista dos tipos de colunas e com o que são preenchidas:
- Colunas de objeto com NaNs
- Colunas numéricas com 0
- Colunas boolianas/lógicas com False
- A coluna de destino é adicionada com ruído branco.
drop Se short_series_handling_config = drop, o ML automatizado descarta a série curta e não será usado para treinamento ou previsão. As previsões para essas séries retornarão as da NaN.
None Nenhuma série é preenchimento ou descartado

No exemplo a seguir, definimos a manipulação de séries curtas para que todas elas sejam adicionadas ao comprimento mínimo:

forecasting_job.set_forecast_settings(
    ...,  # other settings
    short_series_handling_config='pad'
)

Aviso

O preenchimento pode afetar a precisão do modelo resultante, pois estamos introduzindo dados artificiais para evitar falhas de treinamento. Se muitas das séries são curtas, você também poderá ver algum impacto nos resultados da explicabilidade

Frequência & agregação de dados de destino

Use as opções de agregação de dados e frequência para evitar falhas causadas por dados irregulares. Os dados serão irregulares se não seguirem uma cadência definida no tempo, como por hora ou diariamente. Os dados de ponto de venda são um bom exemplo de dados irregulares. Nesses casos, o AutoML pode agregar seus dados a uma frequência desejada e, em seguida, criar um modelo de previsão a partir das agregações.

Você precisa definir as configurações frequency e target_aggregate_function para lidar com dados irregulares. A configuração de frequência aceita cadeias de caracteres DateOffset do Pandas como entrada. Os valores com suporte para a função de agregação são:

Função Descrição
sum  Soma dos valores de destino
mean  Média ou média de valores de destino
min Valor mínimo de um destino
max Valor máximo de um destino
  • Os valores da coluna de destino são agregados de acordo com a operação especificada. Normalmente, sum é apropriado para a maioria dos cenários.
  • As colunas de previsão numéricas em seus dados são agregadas por soma, média, valor mínimo e valor máximo. Como resultado, o ML automatizado gera novas colunas sufixos com o nome da função de agregação e aplica a operação de agregação selecionada.
  • Para colunas de previsão categóricas, os dados são agregados por modo, a categoria mais proeminente na janela.
  • As colunas do preditor de data são agregadas por valor mínimo, valor máximo e modo.

O exemplo a seguir define a frequência como por hora e a função de agregação como resumo:

# Aggregate the data to hourly frequency
forecasting_job.set_forecast_settings(
    ...,  # other settings
    frequency='H',
    target_aggregate_function='sum'
)

Configurações de validação cruzada personalizadas

Há duas configurações personalizáveis que controlam a validação cruzada para trabalhos de previsão: o número de dobras, n_cross_validations, e o tamanho da etapa que define o deslocamento de tempo entre dobras, cv_step_size. Confira a seleção do modelo de previsão para obter mais informações sobre o significado desses parâmetros. Por padrão, o AutoML define as duas configurações automaticamente com base nas características dos dados, mas os usuários avançados podem querer defini-las manualmente. Por exemplo, suponha que você tenha dados de vendas diários e queira que a configuração de validação consista em cinco dobras com um deslocamento de sete dias entre dobras adjacentes. O código de exemplo a seguir mostra como definir isso:

from azure.ai.ml import automl

# Create a job with five CV folds
forecasting_job = automl.forecasting(
    ...,  # other training parameters
    n_cross_validations=5,
)

# Set the step size between folds to seven days
forecasting_job.set_forecast_settings(
    ...,  # other settings
    cv_step_size=7
)

Definição de recursos personalizada

Por padrão, o AutoML aumenta os dados de treinamento com recursos projetados para aumentar a precisão dos modelos. Confira engenharia de recursos automatizada para obter mais informações. Algumas das etapas de pré-processamento podem ser personalizadas usando a configuração de engenharia de recursos do trabalho de previsão.

As personalizações com suporte para previsão estão na tabela a seguir:

Personalização Descrição Opções
Atualização de finalidade de coluna Substituir o tipo de recurso de autodetecção para a coluna especificada. "Categorical", "DateTime", "Numeric"
Atualização de parâmetro do transformador Atualização dos parâmetros para o transformador especificado. {"strategy": "constant", "fill_value": <value>}, {"strategy": "median"}, {"strategy": "ffill"}

Por exemplo, suponha que você tenha um cenário de demanda de varejo em que os dados incluem preços, um sinalizador "à venda" e um tipo de produto. O exemplo a seguir mostra como você pode definir tipos e imputers personalizados para esses recursos:

from azure.ai.ml.automl import ColumnTransformer

# Customize imputation methods for price and is_on_sale features
# Median value imputation for price, constant value of zero for is_on_sale
transformer_params = {
    "imputer": [
        ColumnTransformer(fields=["price"], parameters={"strategy": "median"}),
        ColumnTransformer(fields=["is_on_sale"], parameters={"strategy": "constant", "fill_value": 0}),
    ],
}

# Set the featurization
# Ensure that product_type feature is interpreted as categorical
forecasting_job.set_featurization(
    mode="custom",
    transformer_params=transformer_params,
    column_name_and_types={"product_type": "Categorical"},
)

Se você estiver usando o Estúdio do Azure Machine Learning para seu experimento, confira como personalizar a personalização de recursos no estúdio.

Enviando um trabalho de previsão

Após todas as configurações serem definidas, você inicia o trabalho de previsão da seguinte maneira:

# Submit the AutoML job
returned_job = ml_client.jobs.create_or_update(
    forecasting_job
)

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

# Get a URL for the job in the AML studio user interface
returned_job.services["Studio"].endpoint

Depois que o trabalho for enviado, o AutoML provisionará recursos de computação, aplicará a definição de recursos e outras etapas de preparação aos dados de entrada e começará a examinar os modelos de previsão. Para obter mais detalhes, confira nossos artigos sobre metodologia de previsão e pesquisa de modelo.

Orquestrando treinamento, inferência e avaliação com componentes e pipelines

Importante

Esse recurso está atualmente em visualização pública. Essa versão prévia é fornecida sem um contrato de nível de serviço e não é recomendada para cargas de trabalho de produção. Alguns recursos podem não ter suporte ou podem ter restrição de recursos.

Para obter mais informações, consulte Termos de Uso Complementares de Versões Prévias do Microsoft Azure.

Seu fluxo de trabalho de ML provavelmente requer mais do que apenas treinamento. Inferência ou recuperação de previsões de modelo em dados mais recentes e avaliação da precisão do modelo em um conjunto de testes com valores de destino conhecidos são outras tarefas comuns que você pode orquestrar no AzureML juntamente com trabalhos de treinamento. Para dar suporte a tarefas de inferência e avaliação, o AzureML fornece componentes, que são partes de código independentes que fazem uma etapa em um pipeline do AzureML.

No exemplo a seguir, recuperamos o código do componente de um registro de cliente:

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

# Get a credential for access to the AzureML registry
try:
    credential = DefaultAzureCredential()
    # Check if we can get token successfully.
    credential.get_token("https://management.azure.com/.default")
except Exception as ex:
    # Fall back to InteractiveBrowserCredential in case DefaultAzureCredential fails
    credential = InteractiveBrowserCredential()

# Create a client for accessing assets in the AzureML preview registry
ml_client_registry = MLClient(
    credential=credential,
    registry_name="azureml-preview"
)

# Create a client for accessing assets in the AzureML preview registry
ml_client_metrics_registry = MLClient(
    credential=credential,
    registry_name="azureml"
)

# Get an inference component from the registry
inference_component = ml_client_registry.components.get(
    name="automl_forecasting_inference",
    label="latest"
)

# Get a component for computing evaluation metrics from the registry
compute_metrics_component = ml_client_metrics_registry.components.get(
    name="compute_metrics",
    label="latest"
)

Em seguida, definimos uma função de fábrica que cria pipelines orquestrando treinamento, inferência e computação de métrica. Confira a seção de configuração de treinamento para obter mais detalhes sobre as configurações de treinamento.

from azure.ai.ml import automl
from azure.ai.ml.constants import AssetTypes
from azure.ai.ml.dsl import pipeline

@pipeline(description="AutoML Forecasting Pipeline")
def forecasting_train_and_evaluate_factory(
    train_data_input,
    test_data_input,
    target_column_name,
    time_column_name,
    forecast_horizon,
    primary_metric='normalized_root_mean_squared_error',
    cv_folds='auto'
):
    # Configure the training node of the pipeline
    training_node = automl.forecasting(
        training_data=train_data_input,
        target_column_name=target_column_name,
        primary_metric=primary_metric,
        n_cross_validations=cv_folds,
        outputs={"best_model": Output(type=AssetTypes.MLFLOW_MODEL)},
    )

    training_node.set_forecasting_settings(
        time_column_name=time_column_name,
        forecast_horizon=max_horizon,
        frequency=frequency,
        # other settings
        ... 
    )
    
    training_node.set_training(
        # training parameters
        ...
    )
    
    training_node.set_limits(
        # limit settings
        ...
    )

    # Configure the inference node to make rolling forecasts on the test set
    inference_node = inference_component(
        test_data=test_data_input,
        model_path=training_node.outputs.best_model,
        target_column_name=target_column_name,
        forecast_mode='rolling',
        forecast_step=1
    )

    # Configure the metrics calculation node
    compute_metrics_node = compute_metrics_component(
        task="tabular-forecasting",
        ground_truth=inference_node.outputs.inference_output_file,
        prediction=inference_node.outputs.inference_output_file,
        evaluation_config=inference_node.outputs.evaluation_config_output_file
    )

    # return a dictionary with the evaluation metrics and the raw test set forecasts
    return {
        "metrics_result": compute_metrics_node.outputs.evaluation_result,
        "rolling_fcst_result": inference_node.outputs.inference_output_file
    }

Agora, definimos entradas de dados de treinamento e teste supondo que elas estejam contidas em pastas locais, ./train_data e ./test_data:

my_train_data_input = Input(
    type=AssetTypes.MLTABLE,
    path="./train_data"
)

my_test_data_input = Input(
    type=AssetTypes.URI_FOLDER,
    path='./test_data',
)

Por fim, construímos o pipeline, definimos sua computação padrão e enviamos o trabalho:

pipeline_job = forecasting_train_and_evaluate_factory(
    my_train_data_input,
    my_test_data_input,
    target_column_name,
    time_column_name,
    forecast_horizon
)

# 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

Depois de enviado, o pipeline executa o treinamento autoML, a inferência de avaliação sem interrupção e o cálculo de métrica em sequência. Você pode monitorar e inspecionar a execução na interface do usuário do estúdio. Quando a execução for concluída, as previsões sem interrupção e as métricas de avaliação poderão ser baixadas para o diretório de trabalho local:

# Download the metrics json
ml_client.jobs.download(returned_pipeline_job.name, download_path=".", output_name='metrics_result')

# Download the rolling forecasts
ml_client.jobs.download(returned_pipeline_job.name, download_path=".", output_name='rolling_fcst_result')

Em seguida, você pode encontrar os resultados das métricas em ./named-outputs/metrics_results/evaluationResult/metrics.json e as previsões, no formato de linhas JSON, em ./named-outputs/rolling_fcst_result/inference_output_file.

Para obter mais detalhes sobre a avaliação sem interrupção, confira nosso artigo de avaliação do modelo de previsão.

Previsão em escala: muitos modelos

Importante

Esse recurso está atualmente em visualização pública. Essa versão prévia é fornecida sem um contrato de nível de serviço e não é recomendada para cargas de trabalho de produção. Alguns recursos podem não ter suporte ou podem ter restrição de recursos.

Para obter mais informações, consulte Termos de Uso Complementares de Versões Prévias do Microsoft Azure.

Os muitos componentes de modelos no AutoML permitem que você treine e gerencie milhões de modelos em paralelo. Para obter mais informações sobre muitos conceitos de modelos, confira a seção de muitos modelos.

Configuração de treinamento de muitos modelos

O componente de treinamento muitos modelos aceita um arquivo de configuração de formato YAML das configurações de treinamento do AutoML. O componente aplica essas configurações a cada instância do AutoML iniciada. Esse arquivo YAML tem a mesma especificação que o Trabalho de previsão mais os parâmetros adicionais partition_column_names e allow_multi_partitions.

Parâmetro Descrição
partition_column_names Nomes de coluna nos dados que, quando agrupados, definem as partições de dados. O componente de treinamento muitos modelos inicia um trabalho de treinamento independente em cada partição.
allow_multi_partitions Um sinalizador opcional que permite treinar um modelo por partição quando cada partição contém mais de uma série temporal exclusiva. O valor padrão é False.

O exemplo a seguir fornece um modelo de configuração:

$schema: https://azuremlsdk2.blob.core.windows.net/preview/0.0.1/autoMLJob.schema.json
type: automl

description: A time series forecasting job config
compute: azureml:<cluster-name>
task: forecasting
primary_metric: normalized_root_mean_squared_error
target_column_name: sales
n_cross_validations: 3

forecasting:
  time_column_name: date
  time_series_id_column_names: ["state", "store"]
  forecast_horizon: 28

training:
  blocked_training_algorithms: ["ExtremeRandomTrees"]

limits:
  timeout_minutes: 15
  max_trials: 10
  max_concurrent_trials: 4
  max_cores_per_trial: -1
  trial_timeout_minutes: 15
  enable_early_termination: true
  
partition_column_names: ["state", "store"]
allow_multi_partitions: false

Nos exemplos subsequentes, presumimos que a configuração seja armazenada no caminho, ./automl_settings_mm.yml.

Pipeline de muitos modelos

Em seguida, definimos uma função de fábrica que cria pipelines para orquestração de muitos modelos de treinamento, inferência e computação de métrica. Os parâmetros dessa função de fábrica são detalhados na tabela a seguir:

Parâmetro Descrição
max_nodes Número de nós de computação a serem usados no trabalho de treinamento
max_concurrency_per_node Número de processos do AutoML a serem executados em cada nó. Portanto, a simultaneidade total de muitos trabalhos de modelos é max_nodes * max_concurrency_per_node.
parallel_step_timeout_in_seconds Muitos modelos têm tempo limite de componentes dado em número de segundos.
retrain_failed_models Sinalizador para habilitar o novo treinamento para modelos com falha. Isso será útil se você tiver feito várias execuções anteriores de modelos que resultaram em trabalhos AutoML com falha em algumas partições de dados. Quando esse sinalizador estiver habilitado, muitos modelos iniciarão apenas trabalhos de treinamento para partições com falha anterior.
forecast_mode Modo de inferência para avaliação de modelo. Os valores válidos são "recursive" e "rolling". Confira o artigo de avaliação de modelo para obter mais informações.
forecast_step Tamanho da etapa para previsão sem interrupção. Confira o artigo de avaliação de modelo para obter mais informações.

O exemplo a seguir ilustra um método de fábrica para construir muitos modelos de pipelines de treinamento e avaliação de modelo:

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

# Get a credential for access to the AzureML registry
try:
    credential = DefaultAzureCredential()
    # Check if we can get token successfully.
    credential.get_token("https://management.azure.com/.default")
except Exception as ex:
    # Fall back to InteractiveBrowserCredential in case DefaultAzureCredential fails
    credential = InteractiveBrowserCredential()

# Get a many models training component
mm_train_component = ml_client_registry.components.get(
    name='automl_many_models_training',
    version='latest'
)

# Get a many models inference component
mm_inference_component = ml_client_registry.components.get(
    name='automl_many_models_inference',
    version='latest'
)

# Get a component for computing evaluation metrics
compute_metrics_component = ml_client_metrics_registry.components.get(
    name="compute_metrics",
    label="latest"
)
@pipeline(description="AutoML Many Models Forecasting Pipeline")
def many_models_train_evaluate_factory(
    train_data_input,
    test_data_input,
    automl_config_input,
    compute_name,
    max_concurrency_per_node=4,
    parallel_step_timeout_in_seconds=3700,
    max_nodes=4,
    retrain_failed_model=False,
    forecast_mode="rolling",
    forecast_step=1
):
    mm_train_node = mm_train_component(
        raw_data=train_data_input,
        automl_config=automl_config_input,
        max_nodes=max_nodes,
        max_concurrency_per_node=max_concurrency_per_node,
        parallel_step_timeout_in_seconds=parallel_step_timeout_in_seconds,
        retrain_failed_model=retrain_failed_model,
        compute_name=compute_name
    )

    mm_inference_node = mm_inference_component(
        raw_data=test_data_input,
        max_nodes=max_nodes,
        max_concurrency_per_node=max_concurrency_per_node,
        parallel_step_timeout_in_seconds=parallel_step_timeout_in_seconds,
        optional_train_metadata=mm_train_node.outputs.run_output,
        forecast_mode=forecast_mode,
        forecast_step=forecast_step,
        compute_name=compute_name
    )

    compute_metrics_node = compute_metrics_component(
        task="tabular-forecasting",
        prediction=mm_inference_node.outputs.evaluation_data,
        ground_truth=mm_inference_node.outputs.evaluation_data,
        evaluation_config=mm_inference_node.outputs.evaluation_configs
    )

    # Return the metrics results from the rolling evaluation
    return {
        "metrics_result": compute_metrics_node.outputs.evaluation_result
    }

Agora, construímos o pipeline por meio da função de fábrica, supondo que os dados de treinamento e teste estejam em pastas locais, ./data/train e ./data/test, respectivamente. Por fim, definimos a computação padrão e enviamos o trabalho como no seguinte exemplo:

pipeline_job = many_models_train_evaluate_factory(
    train_data_input=Input(
        type="uri_folder",
        path="./data/train"
    ),
    test_data_input=Input(
        type="uri_folder",
        path="./data/test"
    ),
    automl_config=Input(
        type="uri_file",
        path="./automl_settings_mm.yml"
    ),
    compute_name="<cluster name>"
)
pipeline_job.settings.default_compute = "<cluster name>"

returned_pipeline_job = ml_client.jobs.create_or_update(
    pipeline_job,
    experiment_name=experiment_name,
)
ml_client.jobs.stream(returned_pipeline_job.name)

Após a conclusão do trabalho, as métricas de avaliação podem ser baixadas localmente usando o mesmo procedimento que no pipeline de execução de treinamento único.

Confira também a previsão de demanda com muitos modelos de notebook para obter um exemplo mais detalhado.

Observação

Os muitos componentes de treinamento e inferência de modelos particionam condicionalmente seus dados de acordo com a configuração partition_column_names para que cada partição esteja em seu próprio arquivo. Esse processo pode ser muito lento ou falhar quando os dados são muito grandes. Nesse caso, recomendamos particionar seus dados manualmente antes de executar muitos modelos de treinamento ou inferência.

Previsão em escala: série temporal hierárquica

Importante

Esse recurso está atualmente em visualização pública. Essa versão prévia é fornecida sem um contrato de nível de serviço e não é recomendada para cargas de trabalho de produção. Alguns recursos podem não ter suporte ou podem ter restrição de recursos.

Para obter mais informações, consulte Termos de Uso Complementares de Versões Prévias do Microsoft Azure.

Os componentes de série temporal hierárquica (HTS) no AutoML permitem treinar um grande número de modelos em dados com estrutura hierárquica. Para obter mais informações, confira a seção do artigo sobre HTS.

Configuração de treinamento do HTS

O componente de treinamento HTS aceita um arquivo de configuração de formato YAML das configurações de treinamento do AutoML. O componente aplica essas configurações a cada instância do AutoML iniciada. Esse arquivo YAML tem a mesma especificação que o Trabalho de previsão, além de parâmetros adicionais relacionados às informações de hierarquia:

Parâmetro Descrição
hierarchy_column_names Uma lista de nomes de coluna nos dados que definem a estrutura hierárquica dos dados. A ordem das colunas nesta lista determina os níveis de hierarquia; o grau de agregação diminui com o índice de lista. Ou seja, a última coluna na lista define o nível folha (mais desagregado) da hierarquia.
hierarchy_training_level O nível de hierarquia a ser usado para treinamento de modelo de previsão.

Veja a segui uma configuração de exemplo:

$schema: https://azuremlsdk2.blob.core.windows.net/preview/0.0.1/autoMLJob.schema.json
type: automl

description: A time series forecasting job config
compute: azureml:cluster-name
task: forecasting
primary_metric: normalized_root_mean_squared_error
log_verbosity: info
target_column_name: sales
n_cross_validations: 3

forecasting:
  time_column_name: "date"
  time_series_id_column_names: ["state", "store", "SKU"]
  forecast_horizon: 28

training:
  blocked_training_algorithms: ["ExtremeRandomTrees"]

limits:
  timeout_minutes: 15
  max_trials: 10
  max_concurrent_trials: 4
  max_cores_per_trial: -1
  trial_timeout_minutes: 15
  enable_early_termination: true
  
hierarchy_column_names: ["state", "store", "SKU"]
hierarchy_training_level: "store"

Nos exemplos subsequentes, presumimos que a configuração seja armazenada no caminho, ./automl_settings_hts.yml.

Pipeline do HTS

Em seguida, definimos uma função de fábrica que cria pipelines para orquestração de treinamento, inferência e computação de métrica do HTS. Os parâmetros dessa função de fábrica são detalhados na tabela a seguir:

Parâmetro Descrição
forecast_level O nível da hierarquia para recuperar previsões
allocation_method Método de alocação a ser usado quando as previsões forem desagregados. Os valores válidos são "proportions_of_historical_average" e "average_historical_proportions".
max_nodes Número de nós de computação a serem usados no trabalho de treinamento
max_concurrency_per_node Número de processos do AutoML a serem executados em cada nó. Portanto, a simultaneidade total de um trabalho do HTS é max_nodes * max_concurrency_per_node.
parallel_step_timeout_in_seconds Muitos modelos têm tempo limite de componentes dado em número de segundos.
forecast_mode Modo de inferência para avaliação de modelo. Os valores válidos são "recursive" e "rolling". Confira o artigo de avaliação de modelo para obter mais informações.
forecast_step Tamanho da etapa para previsão sem interrupção. Confira o artigo de avaliação de modelo para obter mais informações.
from azure.ai.ml import MLClient
from azure.identity import DefaultAzureCredential, InteractiveBrowserCredential

# Get a credential for access to the AzureML registry
try:
    credential = DefaultAzureCredential()
    # Check if we can get token successfully.
    credential.get_token("https://management.azure.com/.default")
except Exception as ex:
    # Fall back to InteractiveBrowserCredential in case DefaultAzureCredential fails
    credential = InteractiveBrowserCredential()

# Get a HTS training component
hts_train_component = ml_client_registry.components.get(
    name='automl_hts_training',
    version='latest'
)

# Get a HTS inference component
hts_inference_component = ml_client_registry.components.get(
    name='automl_hts_inference',
    version='latest'
)

# Get a component for computing evaluation metrics
compute_metrics_component = ml_client_metrics_registry.components.get(
    name="compute_metrics",
    label="latest"
)
@pipeline(description="AutoML HTS Forecasting Pipeline")
def hts_train_evaluate_factory(
    train_data_input,
    test_data_input,
    automl_config_input,
    max_concurrency_per_node=4,
    parallel_step_timeout_in_seconds=3700,
    max_nodes=4,
    forecast_mode="rolling",
    forecast_step=1,
    forecast_level="SKU",
    allocation_method='proportions_of_historical_average'
):
    hts_train = hts_train_component(
        raw_data=train_data_input,
        automl_config=automl_config_input,
        max_concurrency_per_node=max_concurrency_per_node,
        parallel_step_timeout_in_seconds=parallel_step_timeout_in_seconds,
        max_nodes=max_nodes
    )
    hts_inference = hts_inference_component(
        raw_data=test_data_input,
        max_nodes=max_nodes,
        max_concurrency_per_node=max_concurrency_per_node,
        parallel_step_timeout_in_seconds=parallel_step_timeout_in_seconds,
        optional_train_metadata=hts_train.outputs.run_output,
        forecast_level=forecast_level,
        allocation_method=allocation_method,
        forecast_mode=forecast_mode,
        forecast_step=forecast_step
    )
    compute_metrics_node = compute_metrics_component(
        task="tabular-forecasting",
        prediction=hts_inference.outputs.evaluation_data,
        ground_truth=hts_inference.outputs.evaluation_data,
        evaluation_config=hts_inference.outputs.evaluation_configs
    )

    # Return the metrics results from the rolling evaluation
    return {
        "metrics_result": compute_metrics_node.outputs.evaluation_result
    }

Agora, construímos o pipeline por meio da função de fábrica, supondo que os dados de treinamento e teste estejam em pastas locais, ./data/train e ./data/test, respectivamente. Por fim, definimos a computação padrão e enviamos o trabalho como no seguinte exemplo:

pipeline_job = hts_train_evaluate_factory(
    train_data_input=Input(
        type="uri_folder",
        path="./data/train"
    ),
    test_data_input=Input(
        type="uri_folder",
        path="./data/test"
    ),
    automl_config=Input(
        type="uri_file",
        path="./automl_settings_hts.yml"
    )
)
pipeline_job.settings.default_compute = "cluster-name"

returned_pipeline_job = ml_client.jobs.create_or_update(
    pipeline_job,
    experiment_name=experiment_name,
)
ml_client.jobs.stream(returned_pipeline_job.name)

Após a conclusão do trabalho, as métricas de avaliação podem ser baixadas localmente usando o mesmo procedimento que no pipeline de execução de treinamento único.

Confira também a previsão de demanda com o notebook de série temporal hierárquica para obter um exemplo mais detalhado.

Observação

Os componentes de treinamento e inferência do HTS particionam condicionalmente seus dados de acordo com a configuração hierarchy_column_names para que cada partição esteja em seu próprio arquivo. Esse processo pode ser muito lento ou falhar quando os dados são muito grandes. Nesse caso, recomendamos particionar seus dados manualmente antes de executar o treinamento ou a inferência do HTS.

Previsão em escala: treinamento de DNN distribuído

Blocos de anotações de exemplo

Consulte os notebooks de amostra de previsão para ver exemplos de código detalhados de configuração de previsão avançada, incluindo:

Próximas etapas