Esta página foi traduzida pela API Cloud Translation.

Design de tarefas de proxy

Antes de executar uma tarefa de pesquisa de arquitetura neural para pesquisar um modelo ideal, defina a sua tarefa de proxy. Stage1-search usa uma representação muito menor de uma preparação completa do modelo que normalmente termina no prazo de duas horas. Esta representação é denominada tarefa de proxy e reduz o custo de pesquisa significativamente. Cada teste durante a pesquisa prepara um modelo com as definições da tarefa de proxy.

As secções seguintes descrevem o que está envolvido na aplicação do design de tarefas de proxy:

Abordagens para criar uma tarefa de proxy.
Requisitos de uma boa tarefa de proxy.
Como usar as três ferramentas de design de tarefas de proxy para encontrar a tarefa de proxy ideal, que reduz o custo da pesquisa e mantém a qualidade da pesquisa.

Abordagens para criar uma tarefa de proxy

Existem três abordagens comuns para criar uma tarefa de proxy, que incluem o seguinte:

Use menos passos de preparação.
Use um conjunto de dados de preparação com subamostragem.
Use um modelo reduzido.

Use menos passos de preparação

A forma mais simples de criar uma tarefa de proxy é reduzir o número de passos de preparação para o preparador e comunicar uma pontuação ao controlador com base nesta preparação parcial.

Use um conjunto de dados de preparação com subamostragem

Esta secção descreve a utilização de um conjunto de dados de preparação com subamostragem para uma pesquisa de arquitetura e uma pesquisa de política de aumento.

Pesquisa de arquitetura

Pode criar uma tarefa de proxy usando um conjunto de dados de preparação com subamostragem durante a pesquisa de arquitetura. No entanto, quando fizer uma subamostragem, siga estas diretrizes:

Misturar os dados aleatoriamente entre fragmentos.
Se os dados de preparação estiverem desequilibrados, faça uma subamostragem para os equilibrar.

Pesquisa de políticas de aumento com o aumento automático

Ignore esta secção se não estiver a executar uma pesquisa apenas de aumento e estiver apenas a executar a pesquisa de arquitetura normal. Use auto-augment para pesquisar a política de aumento. É preferível fazer uma subamostragem dos dados de preparação e executar uma preparação completa do que reduzir o número de passos de preparação. A preparação completa com aumento significativo mantém as pontuações mais estáveis. Além disso, use os dados de preparação reduzidos para manter o custo da pesquisa mais baixo.

Tarefa de proxy com base no modelo reduzido

Também pode reduzir a escala do modelo em relação ao modelo de base para criar uma tarefa de proxy. Isto também pode ser útil quando quiser separar a pesquisa de design de blocos da pesquisa de dimensionamento.

No entanto, quando reduz a escala do modelo e quer usar uma restrição de latência, use uma restrição de latência mais rigorosa para o modelo com escala reduzida. Sugestão: pode reduzir a escala do modelo base e medir a respetiva latência para definir esta restrição de latência mais rigorosa.

Para o modelo reduzido, também pode reduzir a quantidade de aumento e regularização em comparação com o modelo de base original.

Exemplos de um modelo reduzido

Para tarefas de visão computacional em que faz a preparação com base em imagens, existem três formas comuns de reduzir a escala de um modelo:

Reduzir a largura do modelo: um número de canais.
Reduzir a profundidade do modelo: um número de camadas e repetições de blocos.
Reduzir ligeiramente o tamanho das imagens de preparação (para não eliminar funcionalidades) ou recortar as imagens de preparação, se a sua tarefa o permitir.

Leitura sugerida: o artigo sobre o EfficientNet oferece excelentes informações sobre o dimensionamento de modelos para tarefas de visão computacional. Também explica como as três formas de expansão estão relacionadas entre si.

A pesquisa Spinenet é outro exemplo de escalabilidade de modelos usada com a pesquisa de arquitetura neural. Para a pesquisa de fase 1, reduz o número de canais e o tamanho da imagem.

Tarefa de proxy com base numa combinação

As abordagens funcionam de forma independente e podem ser combinadas em diferentes graus para criar uma tarefa de proxy.

Requisitos de uma boa tarefa de proxy

Uma tarefa de proxy tem de cumprir determinados requisitos antes de poder dar uma recompensa estável ao controlador e manter a qualidade da pesquisa.

Correlação de classificação entre a pesquisa da fase 1 e a preparação completa da fase 2

Quando usa uma tarefa de proxy para a pesquisa de arquitetura neural, uma suposição fundamental para uma pesquisa bem-sucedida é que, se o modelo A tiver um desempenho melhor do que o modelo B durante a preparação da tarefa de proxy da fase 1, o modelo A tem um desempenho melhor do que o modelo B para a preparação completa da fase 2. Para validar esta suposição, tem de avaliar a correlação de classificação entre as recompensas da pesquisa de fase 1 e da fase 2 de preparação completa em ~10 a 20 modelos no seu espaço de pesquisa. Estes modelos são denominados correlation-candidate-models.

A figura abaixo mostra um exemplo de uma correlação fraca (correlation-score = -0,03), o que torna esta tarefa de proxy um mau candidato para uma pesquisa:

$Correlação fraca.$

Cada ponto no gráfico representa um modelo candidato à correlação. O eixo x representa as pontuações de preparação completa da fase 2 para os modelos e o eixo y representa as pontuações de tarefas de proxy da fase 1 para os mesmos modelos. Observe o ponto mais alto. Este modelo obteve a pontuação mais elevada na tarefa de proxy (eixo y), mas tem um desempenho fraco durante a fase 2 de preparação completa (eixo x) em comparação com outros modelos. Por outro lado, a figura abaixo mostra um exemplo de uma boa correlação (correlation-score = 0,67), o que torna esta tarefa de proxy um bom candidato para uma pesquisa:

Se a sua pesquisa envolver uma restrição de latência, verifique também se existe uma boa correlação para os valores de latência.

Tenha em atenção que as recompensas dos modelos candidatos à correlação têm um bom intervalo e uma amostragem razoável do intervalo de recompensas. Caso contrário, não pode avaliar a correlação de classificação. Por exemplo, se todas as recompensas de fase 1 dos modelos candidatos à correlação estiverem centradas em apenas dois valores: 0,9 e 0,1, isto não dá variação de amostragem suficiente.

Verificação de variância

Outro requisito de uma tarefa de proxy é que não deve ter uma grande variação na precisão ou na pontuação de latência quando repetida várias vezes para o mesmo modelo sem alterações. Se isto acontecer, o sensor envia um sinal ruidoso de volta para o comando. É disponibilizada uma ferramenta para medir esta variação.

São fornecidos exemplos para mitigar a grande variância durante o treino. Uma forma é usar cosine decay como o cronograma da taxa de aprendizagem. O gráfico seguinte compara três estratégias de taxa de aprendizagem:

O gráfico mais baixo corresponde a uma taxa de aprendizagem constante. Quando a pontuação varia no final da preparação, uma pequena alteração na escolha do número reduzido de passos de preparação pode causar uma grande alteração na recompensa final da tarefa de proxy. Para tornar a recompensa da tarefa de proxy mais estável, é melhor usar uma diminuição da taxa de aprendizagem do cosseno, conforme mostrado pelas pontuações de validação correspondentes no gráfico mais elevado. Repare como o gráfico mais alto se torna mais suave no final da preparação. O gráfico do meio mostra a pontuação correspondente à diminuição gradual da taxa de aprendizagem. É melhor do que a taxa constante, mas ainda não é tão suave como a diminuição do cosseno e também requer um ajuste manual.

Os programas de taxa de aprendizagem são apresentados abaixo:

Suavização adicional

Se estiver a usar uma aumentação pesada, a curva de validação pode não ficar suficientemente suave com a diminuição do cosseno. A utilização de aumento excessivo indica a falta de dados de preparação. Neste caso, não recomendamos a utilização da pesquisa de arquitetura neural e sugerimos que use a pesquisa de aumento.

Se a forte expansão não for a causa e já tiver tentado o declínio do cosseno, mas ainda quiser alcançar uma maior suavidade, use a média móvel exponencial para o TensorFlow-2 ou a média ponderada estocástica para o PyTorch. Consulte este ponteiro de código para ver um exemplo que usa o otimizador de média móvel exponencial com o TensorFlow 2, e este exemplo de média ponderada estocástica para o PyTorch.

Se os gráficos de precisão/época dos testes tiverem o seguinte aspeto:

Em seguida, pode aplicar as técnicas de suavização mencionadas acima (como a média ponderada estocástica ou a utilização da média móvel exponencial) para obter um gráfico mais consistente, como:

Erros relacionados com a falta de memória (OOM) e a taxa de aprendizagem

O espaço de pesquisa de arquitetura pode gerar modelos muito maiores do que a sua base. Pode ter ajustado o tamanho do lote para o modelo de base, mas esta definição pode falhar quando são amostrados modelos maiores durante a pesquisa, o que resulta em erros de falta de memória (OOM). Neste caso, tem de reduzir o tamanho do lote.

O outro tipo de erro que é apresentado é um erro NaN (não é um número). Deve reduzir a taxa de aprendizagem inicial ou adicionar a restrição de gradientes.

Conforme mencionado no tutorial-2, se mais de 20% dos seus modelos de espaço de pesquisa estiverem a devolver pontuações inválidas, não executa a pesquisa completa. As nossas ferramentas de design de tarefas de proxy oferecem uma forma de avaliar a taxa de falhas.

Ferramentas de design de tarefas de proxy

As secções anteriores abordam os princípios do design de tarefas de proxy. Esta secção fornece três ferramentas de design de tarefas de proxy para encontrar automaticamente a tarefa de proxy ideal com base nas diferentes abordagens de design e que cumpre todos os requisitos.

Alterações de código necessárias

Primeiro, tem de modificar ligeiramente o código do formador para que possa interagir com as ferramentas de design de tarefas de proxy durante um processo iterativo. A imagem tf_vision/train_lib.py mostra um exemplo. Primeiro, tem de importar a nossa biblioteca:

from google.cloud.visionsolutions.nas.proxy_task import proxy_task_utils

Antes de um ciclo de formação começar no seu ciclo de formação, verifique se tem de parar a formação antecipadamente, porque a ferramenta de design de tarefas de proxy quer que use a nossa biblioteca:

if proxy_task_utils.get_stop_training(
    model_dir,
    end_training_cycle_step=<last-training-step-idx done so far>,
    total_training_steps=<total-training-steps>):
  break

Após a conclusão de cada ciclo de preparação no ciclo de preparação, atualize a nova pontuação de precisão, o passo de início e fim do ciclo de preparação, o tempo do ciclo de preparação em segundos e o total de passos de preparação.

proxy_task_utils.update_trial_training_accuracy_metric(
      model_dir=model_dir,
      accuracy=<latest accuracy value>,
      begin_training_cycle_step=<beginning training step for this cycle>,
      end_training_cycle_step=<end training step for this cycle>,
      training_cycle_time_in_secs=<training cycle time (excluding validation)>,
      total_training_steps=<total-training-steps>)

Tenha em atenção que o tempo do ciclo de preparação não deve incluir o tempo para a avaliação da pontuação de validação. Certifique-se de que o preparador calcula as pontuações de validação com frequência (evaluation-frequency) para ter uma amostragem suficiente da curva de validação. Se estiver a usar a restrição de latência, atualize a métrica de latência depois de calcular a latência:

proxy_task_utils.update_trial_training_latency_metric(
          model_dir=model_dir,
          latency=<measured_latency>)

A ferramenta de seleção de modelos requer o carregamento do ponto de verificação anterior para a iteração sucessiva. Para ativar a reutilização de um ponto de verificação anterior, adicione uma flag ao seu formador, conforme mostrado em tf_vision/cloud_search_main.py:

parser.add_argument(
      "--retrain_use_search_job_checkpoint",
      type=cloud_nas_utils.str_2_bool,
      default=False,
      help="True to use previous NAS search job checkpoint."
  )

Carregue este ponto de verificação antes de preparar o modelo:

if FLAGS.retrain_use_search_job_checkpoint:
    prev_checkpoint_dir = cloud_nas_utils.get_retrain_search_job_model_dir(
        retrain_search_job_trials=FLAGS.retrain_search_job_trials,
        retrain_search_job_dir=FLAGS.retrain_search_job_dir)
    logging.info("Setting checkpoint to %s.", prev_checkpoint_dir)
    # Now set your checkpoint using 'prev_checkpoint_dir'.

Também precisa do metric-id correspondente aos valores de precisão e latência comunicados pelo seu formador. Se a recompensa do seu formador (que, por vezes, é uma combinação de precisão e latência) for diferente da precisão, certifique-se de que também comunica a métrica apenas de precisão através de other_metrics do seu formador. Por exemplo, o exemplo seguinte mostra as métricas de precisão e latência comunicadas pelo nosso preparador pré-criado:

Medição da variação

Depois de modificar o código de treinador, o primeiro passo é medir a variação do treinador. Para a medição da variância, modifique a configuração de preparação da base para o seguinte:

diminuir os passos de preparação para serem executados durante apenas cerca de uma hora com apenas uma ou duas GPUs. Precisamos de uma pequena amostra de preparação completa.
use a taxa de aprendizagem de decaimento do cosseno e defina os respetivos passos para serem iguais a estes passos reduzidos, de modo que a taxa de aprendizagem fique quase zero no final.

A ferramenta de medição da variância seleciona uma amostra de um modelo do espaço de pesquisa, certifica-se de que este modelo pode iniciar a preparação sem apresentar erros de OOM ou NAN, executa cinco cópias deste modelo com as suas definições durante aproximadamente uma hora e, em seguida, comunica a variância e a suavidade da pontuação de preparação. O custo total de execução desta ferramenta é aproximadamente igual ao da execução de cinco modelos com as suas definições durante cerca de uma hora.

Inicie a tarefa de medição de variância executando o seguinte comando (precisa de uma conta de serviço):

DATE="$(date '+%Y%m%d_%H%M%S')"
project_id=<your project-id>
# You can choose any unique docker id below.
trainer_docker_id=${USER}_trainer_${DATE}
trainer_docker_file=<path to your trainer dockerfile>
region=<your job region such as 'us-central1'>
search_space_module=<path to your search space module>
accelerator_type="NVIDIA_TESLA_V100"
num_gpus=2
# Your bucket should be for your project and in the same region as the job.
root_output_dir=<gs://your-bucket>

####### Variance measurement related parameters ######
proxy_task_variance_measurement_docker_id=${USER}_variance_measurement_${DATE}
# Use the service account that you set-up for your project.
service_account=<your service account>
job_name=<your job name>
############################################################

python3 vertex_nas_cli.py build \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--trainer_docker_file=${trainer_docker_file} \
--proxy_task_variance_measurement_docker_id=${proxy_task_variance_measurement_docker_id}

# The command below passes 'dummy' arguments for the training docker.
# You need to modify them for your own docker.
python3 vertex_nas_cli.py measure_proxy_task_variance \
--proxy_task_variance_measurement_docker_id=${proxy_task_variance_measurement_docker_id} \
--project_id=${project_id} \
--service_account=${service_account} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--job_name=${job_name} \
--search_space_module=${search_space_module} \
--accelerator_type=${accelerator_type} \
--num_gpus=${num_gpus} \
--root_output_dir=${root_output_dir} \
--search_docker_flags \
dummy_trainer_flag1="dummy_trainer_val"

Depois de iniciar esta tarefa de medição de variância, recebe um link da tarefa. O nome da tarefa deve começar com o prefixo Variance_Measurement. Segue-se um exemplo da IU de tarefas:

O variance_measurement_dir vai conter todos os resultados e pode verificar os registos clicando no link Ver registos. Esta tarefa usa, por predefinição, uma CPU na nuvem para ser executada em segundo plano como uma tarefa personalizada e, em seguida, inicia e gere tarefas NAS secundárias.

Em tarefas NAS, verá uma tarefa denominada Find_workable_model_<your job name>. Esta tarefa vai analisar o seu espaço de pesquisa para encontrar um modelo que não gere nenhum erro. Assim que for encontrado um modelo deste tipo, a tarefa de medição da variância inicia outra tarefa NAS <your job name>, que executa cinco cópias deste modelo para o número de passos de preparação que definiu anteriormente. Assim que a preparação destes modelos estiver concluída, a tarefa de medição da variância mede a variância e a suavidade da pontuação e comunica-as nos respetivos registos:

Se a variação for elevada, pode explorar as técnicas indicadas aqui.

Seleção de modelo

Depois de verificar que o seu formador não tem uma variância elevada, os passos seguintes são:

para encontrar cerca de 10 correlation-candidate-models
calcular as respetivas pontuações de preparação completa, que vão servir de referência quando calcular as pontuações de correlação de tarefas proxy para diferentes opções de tarefas proxy mais tarde.

A nossa ferramenta encontra automática e eficientemente estes modelos candidatos à correlação e garante que têm uma boa distribuição de pontuações para a precisão e a latência, para que o cálculo de correlação futuro tenha uma boa base. Para isso, a ferramenta faz o seguinte:

Seleciona aleatoriamente modelos N_begin do seu espaço de pesquisa. Para o exemplo aqui, vamos assumir que N_begin = 30. A ferramenta prepara-os durante 1/30 do tempo de preparação completo.
Rejeite cinco dos 30 modelos, que não contribuem para a distribuição de precisão e latência. A figura seguinte mostra isto como exemplo. Os modelos rejeitados são apresentados como pontos vermelhos:

Prepare os 25 modelos selecionados durante 1/25 do tempo de preparação total e, em seguida, rejeite mais cinco modelos com base nas pontuações até ao momento. Tenha em atenção que a preparação dos 25 modelos é continuada a partir do respetivo ponto de verificação anterior.
Repita este processo até ficarem apenas N modelos com uma boa distribuição.
Treine estes últimos N modelos até à conclusão.

A predefinição para N_begin é 30 e pode encontrá-la como START_NUM_MODELS no ficheiro proxy_task/proxy_task_model_selection_lib_constants.py. A predefinição para N é 10 e pode ser encontrada como FINAL_NUM_MODELS no ficheiro proxy_task/proxy_task_model_selection_lib_constants.py.

O custo adicional deste processo de seleção de modelos é calculado da seguinte forma:

= (30*1/30 + 25*1/25 + 20*1/20 + 15*1/15 + 10*(remaining-training-time-fraction)) * full-training-time
= (4 + 10*(0.81)) * full-training-time
~= 12 * full-training-time

No entanto, mantenha-se acima da definição N=10. Posteriormente, a ferramenta de pesquisa de tarefas de proxy executa estes modelos N em paralelo. Por isso, certifique-se de que tem quota de GPU suficiente para tal. Por exemplo, se a sua tarefa de proxy usar duas GPUs para um modelo, deve ter uma quota de, pelo menos, 2*N GPUs.

Para a tarefa de seleção de modelos, use a mesma partição do conjunto de dados que a tarefa de preparação completa da fase 2 e use a mesma configuração do preparador para a preparação completa de base.

Agora, está tudo pronto para executar a tarefa de seleção de modelos com o seguinte comando (precisa de uma conta de serviço):

DATE="$(date '+%Y%m%d_%H%M%S')"
project_id=<your project-id>
# You can choose any unique docker id below.
trainer_docker_id=${USER}_trainer_${DATE}
trainer_docker_file=<path to your trainer dockerfile>
latency_calculator_docker_id=${USER}_model_selection_${DATE}
latency_calculator_docker_file=${USER}_latency_${DATE}
region=<your job region such as 'us-central1'>
search_space_module=<path to your search space module>
accelerator_type="NVIDIA_TESLA_V100"
num_gpus=2
# Your bucket should be for your project and in the same region as the job.
root_output_dir=<gs://your-bucket>
# Your latency computation device.
target_device_type="CPU"

####### Proxy task model-selection related parameters ######
proxy_task_model_selection_docker_id=${USER}_model_selection_${DATE}
# Use the service account that you set-up for your project.
service_account=<your service account>
job_name=<your job name>
# The value below depends on your accelerator quota. By default
# the model-selection job runs 30 trials. However, depending on
# your quota, you can choose to only run 10 trials in parallel at a time.
# However, lowering this number can increase the overall runtime for the job.
max_parallel_nas_trial=<num parallel trials>
# The value below is the 'metric-id' corresponding to the accuracy ONLY
# metric reported by your trainer. Note that this metric may
# be different from the 'reward'.
accuracy_metric_id=<set accuracy metric id used by your trainer>
latency_metric_id=<set latency metric id used by your trainer>
############################################################

python3 vertex_nas_cli.py build \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--trainer_docker_file=${trainer_docker_file} \
--latency_calculator_docker_id=${latency_calculator_docker_id} \
--latency_calculator_docker_file=${latency_calculator_docker_file} \
--proxy_task_model_selection_docker_id=${proxy_task_model_selection_docker_id}

# The command below passes 'dummy' arguments for trainer-docker
# and latency-docker. You need to modify them for your own docker.
python3 vertex_nas_cli.py select_proxy_task_models \
--service_account=${service_account} \
--proxy_task_model_selection_docker_id=${proxy_task_model_selection_docker_id} \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--job_name=${job_name} \
--max_parallel_nas_trial=${max_parallel_nas_trial} \
--accuracy_metric_id=${accuracy_metric_id} \
--latency_metric_id=${latency_metric_id} \
--search_space_module=${search_space_module} \
--accelerator_type=${accelerator_type} \
--num_gpus=${num_gpus} \
--root_output_dir=${root_output_dir} \
--latency_calculator_docker_id=${latency_calculator_docker_id} \
--latency_docker_flags \
dummy_latency_flag1="dummy_latency_val" \
--target_device_type=${target_device_type} \
--search_docker_flags \
dummy_trainer_flag1="dummy_trainer_val"

Depois de iniciar esta tarefa do controlador de seleção de modelos, recebe um link da tarefa. O nome da tarefa começa com o prefixo Model_Selection_. Segue-se um exemplo da IU de tarefas:

O model_selection_dir contém todos os resultados. Verifique os registos clicando no link View logs. Por predefinição, esta tarefa do controlador de seleção de modelos usa um CPU em Google Cloud para ser executada em segundo plano como uma tarefa personalizada e, em seguida, inicia e gere tarefas NAS secundárias para cada iteração da seleção de modelos.

Cada tarefa NAS tem um nome, como <your_job_name>_iter_3 (exceto para a iteração 0). Só é executada uma iteração de cada vez. Em cada iteração, o número de modelos (número de tentativas) diminui e a duração da preparação aumenta. No final de cada iteração, cada tarefa NAS guarda um ficheiro gs://<job-output-dir>/search/filtered_trial_scores.png que mostra visualmente que modelos foram rejeitados nesta iteração. Também pode executar o seguinte comando:

gcloud storage cat gs://<path to 'model_selection_dir'>/MODEL_SELECTION_STATE.json

que lhe mostra um resumo das iterações e do estado atual da tarefa do controlador de seleção de modelos, o nome da tarefa e links para cada iteração:

{
  "start_num_models": 30,
  "final_num_models": 10,
  "num_models_to_remove_per_iter": 5,
  "accuracy_metric_id": "top_1_accuracy_without_latency",
  "latency_metric_id": "latency_milli_seconds",
  "iterations": [
    {
      "num_trials": 30,
      "trials_to_retrain": [
        "27",
        "16",
        ...,
        "14"
      ],
      "search_job_name": "projects/123456/locations/europe-west4/nasJobs/2111217356469436416",
      "search_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/2111217356469436416/cpu?project=my-project",
      "latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/6909239809479278592",
      "latency_calculator_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/6909239809479278592/cpu?project=my-project",
      "desired_training_step_pct": 2.0
    },
    ...,
    {
      "num_trials": 15,
      "trials_to_retrain": [
        "14",
        ...,
        "5"
      ],
      "search_job_name": "projects/123456/locations/europe-west4/nasJobs/7045544066951413760",
      "search_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/7045544066951413760/cpu?project=my-project",
      "latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/2790768318993137664",
      "latency_calculator_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/2790768318993137664/cpu?project=my-project",
      "desired_training_step_pct": 28.57936507936508
    },
    {
      "num_trials": 10,
      "trials_to_retrain": [],
      "search_job_name": "projects/123456/locations/europe-west4/nasJobs/2742864796394192896",
      "search_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/2742864796394192896/cpu?project=my-project",
      "latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/1490864099985195008",
      "latency_calculator_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/1490864099985195008/cpu?project=my-project",
      "desired_training_step_pct": 101.0
    }
  ]
}

A última iteração tem o número final de modelos de referência com uma boa distribuição de pontuações. Estes modelos e as respetivas classificações são usados para a pesquisa de tarefas de proxy no passo seguinte. Se o intervalo de pontuação de precisão e latência final para os modelos de referência parecer melhor ou próximo do seu modelo de base existente, o que dá uma boa indicação inicial sobre o seu espaço de pesquisa. Se a precisão final e a pontuação de latência forem significativamente piores do que a base, reveja o seu espaço de pesquisa.

Tenha em atenção que, se mais de 20% das suas experiências na primeira iteração falharem, deve cancelar a tarefa de seleção de modelos e identificar a causa principal das falhas. Isto pode ser um problema com o seu espaço de pesquisa ou com as definições de tamanho do lote e taxa de aprendizagem.

Usar o dispositivo de latência no local para a seleção de modelos

Para usar o dispositivo de latência no local para a seleção de modelos, execute o comando select_proxy_task_models sem o docker de latência e os flags de latência-docker, porque não quer iniciar o docker de latência Google Cloud. Em seguida, use o comando run_latency_calculator_local descrito no Tutorial 4 para iniciar a tarefa da calculadora de latência no local. Em vez de transmitir a flag --search_job_id, transmita a flag --controller_job_id com o ID numérico da tarefa de seleção do modelo que recebe após executar o comando select_proxy_task_models.

Retomar tarefa do controlador de seleção de modelos

As seguintes situações requerem que retome a tarefa do controlador de seleção de modelos:

A tarefa do controlador de seleção do modelo principal termina (caso raro).
Cancela acidentalmente a tarefa do controlador de seleção do modelo.

Primeiro, não cancele a tarefa de iteração da NAS da criança (separador NAS) se já estiver em execução. Em seguida, para retomar a tarefa do controlador de seleção do modelo principal, execute o comando select_proxy_task_models como antes, mas desta vez transmita a flag --previous_model_selection_dir e defina-a para o diretório de saída da tarefa do controlador de seleção do modelo anterior. A tarefa do controlador de seleção do modelo retomado carrega o respetivo estado anterior do diretório e continua a funcionar como antes.

Pesquisa de tarefas de proxy

Depois de encontrar os modelos candidatos à correlação e as respetivas pontuações de preparação completa, o passo seguinte é usá-los para avaliar as pontuações de correlação para diferentes escolhas de tarefas de substituição e escolher a tarefa de substituição ideal. A nossa ferramenta de pesquisa de tarefas de proxy pode encontrar automaticamente uma tarefa de proxy, que oferece o seguinte:

O custo de pesquisa de NAS mais baixo.
Cumpre um limite mínimo de requisito de correlação após fornecer-lhe uma definição de espaço de pesquisa de tarefas de proxy.

Lembre-se de que existem três dimensões comuns para pesquisar uma tarefa de proxy ideal, que incluem:

Número reduzido de passos de preparação.
Quantidade reduzida de dados de preparação.
Escala do modelo reduzida.

Pode criar um espaço de pesquisa de tarefas proxy discreto através da amostragem destas dimensões, conforme mostrado aqui:

As percentagens acima são definidas apenas como uma sugestão aproximada e um exemplo. Na prática, pode escolher qualquer opção discreta. Tenha em atenção que não incluímos a dimensão training-steps no espaço de pesquisa acima. Isto acontece porque a ferramenta de pesquisa de tarefas de proxy determina o passo de preparação ideal dada uma escolha de tarefa de proxy. Considere uma escolha de tarefa de proxy de [50% training data, 25% model scale]. Defina o número de passos de preparação para o mesmo valor que na preparação de referência completa. Ao avaliar esta tarefa de proxy, a ferramenta de pesquisa de tarefas de proxy inicia a preparação dos modelos candidatos à correlação, monitoriza as respetivas pontuações de precisão atuais e calcula continuamente a pontuação de correlação de classificação (usando as pontuações de preparação completa anteriores para os modelos de referência):

Assim, a ferramenta de pesquisa de tarefas de proxy pode parar a preparação de tarefas de proxy assim que for obtida a correlação desejada (como 0,65) ou também pode parar antecipadamente se for excedida a quota de custo de pesquisa (como um limite de 3 horas por tarefa de proxy). Por conseguinte, não precisa de pesquisar explicitamente os passos de preparação. A ferramenta de pesquisa de tarefas de proxy avalia cada tarefa de proxy do seu espaço de pesquisa discreto como uma pesquisa de grelha e oferece-lhe a melhor opção.

Segue-se um MnasNetexemplo de definição do espaço de pesquisa de tarefas de proxymnasnet_proxy_task_config_generator, definido no ficheiro proxy_task/proxy_task_search_spaces.py, para demonstrar como pode definir o seu próprio espaço de pesquisa:

# MNasnet training-data size choices.
MNASNET_TRAINING_DATA_PCT_LIST = [25, 50, 75, 95]

# Training data path regex pattern.
_TRAINING_DATA_PATH_REGEX = r"gs://.*/.*"


def update_mnasnet_proxy_training_data(
    baseline_docker_args_map: Dict[str, Any],
    training_data_pct: int) -> Optional[Dict[str, Any]]:
  """Updates MNasnet baseline docker to use a certain training_data_pct."""
  proxy_task_docker_args_map = copy.deepcopy(baseline_docker_args_map)
  # Imagenet training data path looks like:
  # gs://<path to imagenet data>/train-00[0-7]??-of-01024.
  if not re.match(_TRAINING_DATA_PATH_REGEX,
                  baseline_docker_args_map["training_data_path"]):
    raise ValueError(
        "Training data path %s does not match the desired pattern." %
        baseline_docker_args_map["training_data_path"])

  root_path, _ = baseline_docker_args_map["training_data_path"].rsplit("/", 1)
  if training_data_% == 25:
    proxy_task_docker_args_map["training_data_path"] = os.path.join(
        root_path, "train-00[0-1][0-4]?-of-01024*")
  elif training_data_% == 50:
    proxy_task_docker_args_map["training_data_path"] = os.path.join(
        root_path, "train-00[0-4]??-of-01024*")
  elif training_data_% == 75:
    proxy_task_docker_args_map["training_data_path"] = os.path.join(
        root_path, "train-00[0-6][0-4]?-of-01024*")
  elif training_data_% == 95:
    proxy_task_docker_args_map["training_data_path"] = os.path.join(
        root_path, "train-00[0-8][0-4]?-of-01024*")
  else:
    logging.warning("Mnasnet training_data_% %d is not supported.",
                    training_data_pct)
    return None
  proxy_task_docker_args_map["validation_data_path"] = os.path.join(
      root_path, "train-009[0-4]?-of-01024")
  return proxy_task_docker_args_map


def mnasnet_proxy_task_config_generator(
    baseline_docker_args_map: Dict[str, Any]
) -> List[proxy_task_utils.ProxyTaskConfig]:
  """Returns a list of proxy-task configs to be evaluated for MNasnet.

  Args:
    baseline_docker_args_map: A set of baseline training-docker arguments in
      the form of a dictionary of {'key', val}. The different proxy-task
      configs to try can be built by modifying this baseline.

  Returns:
    A list of proxy-task configs to be evaluated for this
    proxy-task search space.
  """
  proxy_task_config_list = []
  # NOTE: Will not search over model-scale for MNasnet.
  for training_data_% in MNASNET_TRAINING_DATA_PCT_LIST:
    proxy_task_docker_args_map = update_mnasnet_proxy_training_data(
        baseline_docker_args_map=baseline_docker_args_map,
        training_data_pct=training_data_pct)
    if not proxy_task_docker_args_map:
      continue
    proxy_task_name = "mnasnet_proxy_training_data_pct_{}".format(
        training_data_pct)
    proxy_task_config_list.append(
        proxy_task_utils.ProxyTaskConfig(
            name=proxy_task_name, docker_args_map=proxy_task_docker_args_map))
  return proxy_task_config_list

Neste exemplo, criamos um espaço de pesquisa simples sobre training-data-percent 25, 50, 75 e 95 (tenha em atenção que 100% dos dados de preparação não são usados para a pesquisa da fase 1). A função mnasnet_proxy_task_config_generator usa um modelo de base comum de argumentos do Docker de preparação e, em seguida, modifica estes argumentos para cada tamanho de dados de preparação da tarefa proxy desejada. Em seguida, devolve uma lista de proxy-task-config que é processada posteriormente pela ferramenta de pesquisa de tarefas de proxy uma a uma pela mesma ordem. Cada configuração de tarefa de proxy tem um name e um docker_args_map, que é um mapa de chave-valor para os argumentos do Docker da tarefa de proxy.

Pode implementar a sua própria definição do espaço de pesquisa de acordo com os seus próprios requisitos e criar os seus próprios espaços de pesquisa de tarefas de proxy, mesmo para mais de duas dimensões de dados de preparação reduzidos ou escala do modelo reduzida. No entanto, não é aconselhável pesquisar explicitamente os passos de preparação, uma vez que envolve cálculos repetidos desperdiçados. Deixe que a ferramenta de pesquisa de tarefas de proxy trate desta dimensão por si.

Para a sua primeira pesquisa de tarefas de proxy, pode tentar reduzir apenas os dados de preparação (tal como no exemplo MnasNet) e ignorar a escala do modelo reduzido, uma vez que o dimensionamento do modelo pode envolver vários parâmetros superiores a image-size, num-filters ou num-blocks. Na maioria dos casos, os dados de preparação reduzidos (e a pesquisa implícita em passos de preparação reduzidos) são suficientes para encontrar uma boa tarefa de proxy.

Defina o número de passos de preparação para o número usado na preparação da base de referência completa. Existem diferenças entre as configurações de preparação completa da fase 2 e as configurações de preparação da tarefa proxy da fase 1. Para a tarefa de proxy, deve reduzir o batch-size em comparação com a configuração de preparação de base completa para usar apenas 2 ou 4 GPUs. Normalmente, o treino completo usa 4 GPUs, 8 GPUs ou mais, mas a tarefa de proxy usa apenas 2 GPUs ou 4 GPUs. Outra diferença é a divisão entre a formação e a validação. Segue-se um exemplo de alterações para a configuração do MnasNet, que passa de 4 GPUs para a fase 2 de preparação completa para 2 GPUs e uma divisão de validação diferente para a pesquisa de tarefas de proxy:

Inicie a tarefa de pesquisa do controlador de tarefas proxy executando o seguinte comando (precisa de uma conta de serviço):

DATE="$(date '+%Y%m%d_%H%M%S')"
project_id=<your project-id>
# You can choose any unique docker id below.
trainer_docker_id=${USER}_trainer_${DATE}
trainer_docker_file=<path to your trainer dockerfile>
latency_calculator_docker_id=${USER}_model_selection_${DATE}
latency_calculator_docker_file=${USER}_latency_${DATE}
region=<your job region such as 'us-central1'>
search_space_module=<path to your NAS job search space module>
accelerator_type="NVIDIA_TESLA_V100"
num_gpus=2
# Your bucket should be for your project and in the same region as the job.
root_output_dir=<gs://your-bucket>
# Your latency computation device.
target_device_type="CPU"

####### Proxy task search related parameters ######
proxy_task_search_controller_docker_id=${USER}_proxy_task_search_${DATE}
job_name=<your job name>
# Path to your proxy task search space definition. For ex:
# 'proxy_task.proxy_task_search_spaces.mnasnet_proxy_task_config_generator'
proxy_task_config_generator_module=<path to your proxy task config generator module>
# The previous model-slection job provides the candidate-correlation-models
# and their scores.
proxy_task_model_selection_job_id=<Numeric job id of your previous model-selection>
# During proxy-task search, the proxy-task training is stopped
# when the following correlation score is achieved.
desired_accuracy_correlation=0.65
# During proxy-task search, the proxy-task training is stopped
# if the runtime exceeds this limit: 4 hrs.
training_time_hrs_limit=4
# The proxy-task is marked a good candidate only if the latency
# correlation is also above the required threshold.
# Note: This won't be used if you do not have a latency job.
desired_latency_correlation=0.65
# Early stop a proxy-task evaluation if you already have a better candidate.
# If False, evaluate all proxy-taask candidates.
early_stop_proxy_task_if_not_best=False
# Use the service account that you set-up for your project.
service_account=<your service account>
###################################################


python3 vertex_nas_cli.py build \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--trainer_docker_file=${trainer_docker_file} \
--latency_calculator_docker_id=${latency_calculator_docker_id} \
--latency_calculator_docker_file=${latency_calculator_docker_file} \
--proxy_task_search_controller_docker_id=${proxy_task_search_controller_docker_id}

# The command below passes 'dummy' arguments for trainer-docker
# and latency-docker. You need to modify them for your own docker.
python3 vertex_nas_cli.py search_proxy_task \
--service_account=${service_account} \
--proxy_task_search_controller_docker_id=${proxy_task_search_controller_docker_id} \
--proxy_task_config_generator_module=${proxy_task_config_generator_module} \
--proxy_task_model_selection_job_id=${proxy_task_model_selection_job_id} \
--proxy_task_model_selection_job_region=${region} \
--desired_accuracy_correlation={$desired_accuracy_correlation}\
--training_time_hrs_limit=${training_time_hrs_limit} \
--desired_latency_correlation=${desired_latency_correlation} \
--early_stop_proxy_task_if_not_best=${early_stop_proxy_task_if_not_best} \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--job_name=${job_name} \
--search_space_module=${search_space_module} \
--accelerator_type=${accelerator_type} \
--num_gpus=${num_gpus} \
--root_output_dir=${root_output_dir} \
--latency_calculator_docker_id=${latency_calculator_docker_id} \
--latency_docker_flags \
dummy_latency_flag1="dummy_latency_val" \
--target_device_type=${target_device_type} \
--search_docker_flags \
dummy_trainer_flag1="dummy_trainer_val"

Depois de iniciar esta tarefa de controlador de pesquisa de proxy, recebe um link de tarefa. O nome da tarefa começa com o prefixo Search_controller_. Segue-se um exemplo da IU de tarefas:

O search_controller_dir vai conter todos os resultados e pode verificar os registos clicando no link View logs. Por predefinição, esta tarefa usa uma CPU na nuvem para ser executada em segundo plano como uma tarefa personalizada e, em seguida, inicia e gere tarefas NAS secundárias para cada avaliação de tarefas de proxy.

Cada tarefa NAS tem um nome, como ProxyTask_<your-job-name>_<proxy-task-name>, em que <proxy-task-name> é o que o módulo gerador de configuração de tarefas de proxy fornece para cada tarefa de proxy. Só é executada uma avaliação de tarefa proxy de cada vez. Também pode executar o seguinte comando:

gcloud storage cat gs://<path to 'search_controller_dir'>/SEARCH_CONTROLLER_STATE.json

Este comando mostra um resumo de todas as avaliações de tarefas de proxy e o estado atual da tarefa do controlador de pesquisa, o nome da tarefa e os links para cada avaliação:

{
  "proxy_tasks_map": {
    "mnasnet_proxy_training_data_pct_25": {
      "proxy_task_stats": {
        "training_steps": [
          1249,
          2499,
          ...,
          18749
        ],
        "accuracy_correlation_over_step": [
          -0.06666666666666667,
          -0.6,
          ...,
          0.7857142857142856
        ],
        "accuracy_correlation_p_value_over_step": [
          0.8618005952380953,
          0.016666115520282188,
          ...,
          0.005505952380952381
        ],
        "median_accuracy_over_step": [
          0.011478611268103123,
          0.04956454783678055,
          ...,
          0.32932570576667786
        ],
        "median_training_time_hrs_over_step": [
          0.11611097933475001,
          0.22913257125276987,
          ...,
          1.6682701704073444
        ],
        "latency_correlation": 0.9555555555555554,
        "latency_correlation_p_value": 5.5114638447971785e-06,
        "stopping_state": "Met desired correlation",
        "posted_stop_trials_message": true,
        "final_training_time_in_hours": 1.6675102778428197,
        "final_training_steps": 18512
      },
      "proxy_task_name": "mnasnet_proxy_training_data_pct_25",
      "search_job_name": "projects/123456/locations/europe-west4/nasJobs/4173661476642357248",
      "search_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/4173661476642357248/cpu?project=my-project",
      "latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/8785347495069745152",
      "latency_calculator_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/8785347495069745152/cpu?project=my-project"
    },
    ...,
    "mnasnet_proxy_training_data_pct_95": {
      "proxy_task_stats": {
        "training_steps": [
          1249,
          ...,
          18749
        ],
        "accuracy_correlation_over_step": [
          -0.3333333333333333,
          ...,
          0.7857142857142856,
          -5.0
        ],
        "accuracy_correlation_p_value_over_step": [
          0.21637345679012346,
          ...,
          0.005505952380952381,
          -5.0
        ],
        "median_accuracy_over_step": [
          0.01120645459741354,
          ...,
          0.38238024711608887,
          -1.0
        ],
        "median_training_time_hrs_over_step": [
          0.11385884770307843,
          ...,
          1.5466042930547819,
          -1.0
        ],
        "latency_correlation": 0.9555555555555554,
        "latency_correlation_p_value": 5.5114638447971785e-06,
        "stopping_state": "Met desired correlation",
        "posted_stop_trials_message": true,
        "final_training_time_in_hours": 1.533235285929564,
        "final_training_steps": 17108
      },
      "proxy_task_name": "mnasnet_proxy_training_data_pct_95",
      "search_job_name": "projects/123456/locations/europe-west4/nasJobs/2341822328209408000",
      "search_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/2341822328209408000/cpu?project=my-project",
      "latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/7575005095213924352",
      "latency_calculator_job_link": "https://console.cloud.google.com/vertex-ai/locations/europe-west4/training/7575005095213924352/cpu?project=my-project"
    }
  },
  "best_proxy_task_name": "mnasnet_proxy_training_data_pct_75"
}

O proxy_tasks_map armazena o resultado de cada avaliação de tarefas de proxy e best_proxy_task_name regista a melhor tarefa de proxy para a pesquisa. Cada entrada de tarefa de proxy tem dados adicionais, como proxy_task_stats, que registam o progresso da correlação de precisão, os respetivos valores p, a precisão mediana e o tempo de preparação mediano ao longo das etapas de preparação. Também regista a correlação relacionada com a latência, se aplicável, e regista o motivo da paragem desta tarefa (como o limite de tempo de preparação excedido) e o passo de preparação em que para. Também pode ver estas estatísticas como gráficos copiando o conteúdo do search_controller_dir para a sua pasta local executando o seguinte comando:

gcloud storage cp gs://<path to 'search_controller_dir'>/* /your/local/dir

e inspecionar as imagens dos lotes. Por exemplo, o seguinte gráfico mostra a correlação da precisão com o tempo de preparação para a melhor tarefa substituta:

A sua pesquisa está concluída e encontrou a melhor configuração de tarefas de proxy. Tem de fazer o seguinte:

Defina o número de passos de preparação para a tarefa de proxy final_training_steps do vencedor.
Defina os passos de diminuição do cosseno da mesma forma que os final_training_steps, para que a taxa de aprendizagem seja quase zero no final.
[Opcional] Faça uma avaliação da pontuação de validação no final da preparação, o que poupa vários custos de avaliação.

Usar um dispositivo de latência no local para a pesquisa de tarefas de proxy

Para usar o dispositivo de latência no local para a pesquisa de tarefas de proxy, execute o comando search_proxy_task sem o docker de latência e os sinalizadores de latência-docker, porque não quer iniciar o docker de latência Google Cloud. Em seguida, use o comando run_latency_calculator_local descrito no Tutorial 4 para iniciar a tarefa da calculadora de latência no local. Em vez de transmitir o sinalizador --search_job_id, transmita o sinalizador --controller_job_id com o ID numérico da tarefa de pesquisa de proxy que recebe após executar o comando search_proxy_task.

A retomar a tarefa do controlador de pesquisa de tarefas de proxy

As seguintes situações requerem que retome a tarefa de controlador de pesquisa de proxy:

A tarefa de controlo de pesquisa da tarefa proxy principal termina (caso raro).
Cancelar acidentalmente a tarefa do controlador de pesquisa de tarefas de proxy.
Quiser expandir o espaço de pesquisa de tarefas de proxy mais tarde (mesmo após muitos dias).

Primeiro, não cancele a tarefa de iteração da NAS da criança (separador NAS) se já estiver em execução. Em seguida, para retomar a tarefa de controlo de pesquisa de proxy principal, execute o comando search_proxy_task como antes, mas desta vez transmita a flag --previous_proxy_task_search_dir e defina-a para o diretório de saída da tarefa de controlo de pesquisa de proxy anterior. A tarefa de pesquisa do controlador de tarefas de proxy retomada carrega o respetivo estado anterior do diretório e continua a funcionar como antes.

Verificações finais

As duas verificações finais da tarefa de proxy incluem o intervalo de recompensas e a poupança de dados para análise pós-pesquisa.

Intervalo de recompensas

A recompensa comunicada ao controlador deve estar no intervalo [1e-3, 10]. Se não for verdade, pode aumentar artificialmente a recompensa para atingir este objetivo.

Guarde dados para análise pós-pesquisa

O código da tarefa de proxy deve guardar quaisquer métricas e dados adicionais na localização do Cloud Storage, o que pode ser útil para analisar o espaço de pesquisa mais tarde. A nossa plataforma de pesquisa de arquitetura neural só suporta o registo de até cinco pontos flutuantes other_metrics. Todas as métricas adicionais devem ser guardadas na localização do Cloud Storage para análise posterior.