Compartilhar via

Conceitos do Hyperopt

  • Artigo

Observação

A versão de código aberto do Hyperopt não está mais sendo mantida.

O Hyperopt será removido na próxima versão principal do DBR ML. O Azure Databricks recomenda usar o Optuna para uma experiência semelhante e acesso a algoritmos de ajuste de hiperparâmetros mais atualizados.

Este artigo descreve alguns dos conceitos que você precisa saber para usar o Hyperopt distribuído.

Nesta seção:

Para obter exemplos que ilustram como usar o Hyperopt no Azure Databricks, consulte Hyperopt.

fmin()

Você usa fmin() para realizar uma execução do Hyperopt. Os argumentos para fmin() são mostrados na tabela; consulte a Documentação para o Hyperopt para obter mais informações. Para obter exemplos de como usar cada argumento, consulte os notebooks de exemplo.

Nome do argumento Descrição
fn Função objetiva. O Hyperopt chama essa função com valores gerados do espaço de hiperparâmetro fornecido no argumento de espaço. Essa função pode retornar a perda como um valor escalar ou em um dicionário (consulte a documentação do Hyperopt para obter detalhes). Normalmente, essa função contém código para treinamento de modelo e cálculo de perda.
space Define o espaço de hiperparâmetro a ser pesquisado. O Hyperopt fornece grande flexibilidade na forma como esse espaço é definido. Você pode escolher uma opção categórica, como algoritmo, ou distribuição probabilística para valores numéricos, como uniforme e registro.
algo O algoritmo de pesquisa do Hyperopt a ser usado para pesquisar o espaço de hiperparâmetro. Os mais comumente usado são hyperopt.rand.suggest para Pesquisa Aleatória e hyperopt.tpe.suggest para TPE.
max_evals Número de configurações de hiperparâmetro a serem tentadas (o número de modelos a serem ajustados).
max_queue_len O número de configurações de hiperparâmetro que o Hyperopt deve gerar antecipadamente. Como o algoritmo de geração de TPE do Hyperopt pode levar algum tempo, pode ser útil aumentar isso além do valor padrão de 1, mas geralmente não mais do que a configuração SparkTrialsparallelism.
trials Um objeto Trials ou SparkTrials . Use SparkTrials quando você chamar algoritmos de máquina única, como os métodos Scikit-learn na função objetiva. Use Trials quando você chamar algoritmos de treinamento distribuídos, como métodos MLlib ou Horovod na função objetiva.
early_stop_fn Uma função de parada antecipada opcional para determinar se fmin deve parar antes que max_evals seja atingido. O padrão é None. A assinatura de entrada da função é Trials, *args e a assinatura de saída é bool, *args. O booliano de saída indica se deve parar ou não. *args é qualquer estado em que a saída de uma chamada para early_stop_fn sirva como entrada para a próxima chamada. Trials pode ser um objeto SparkTrials. Ao usar SparkTrials, não é garantido que a função de parada antecipada seja executada após cada avaliação e, em vez disso, é sondada. Exemplo de uma função de parada antecipada

A classe SparkTrials

SparkTrials é uma API desenvolvida pelo Databricks que permite a distribuição de uma execução do Hyperopt sem que você precise fazer outras alterações em seu código do Hyperopt. SparkTrials acelera o ajuste de máquina única distribuindo avaliações para trabalhadores do Spark.

Observação

SparkTrials é projetado para paralelizar cálculos para modelos de ML de máquina única, como o scikit-learn. Para modelos criados com algoritmos de ML distribuídos como MLlib ou Horovod, não use SparkTrials. Nesse caso, o processo de criação de modelo é paralelizado automaticamente no cluster e você deve usar a classe do Hyperopt padrão Trials.

Esta seção descreve como configurar os argumentos que você passa para SparkTrials e os aspectos de implementação do SparkTrials.

Argumentos

SparkTrials aceita dois argumentos opcionais:

  • parallelism: o número máximo de avaliações a serem avaliadas simultaneamente. Um número mais alto permite o teste de expansão de mais configurações de hiperparâmetro. Como o Hyperopt propõe novas avaliações com base nos resultados anteriores, há uma compensação entre paralelismo e adaptabilidade. Para um max_evals fixo, um paralelismo maior acelera os cálculos, mas um paralelismo menor pode levar a melhores resultados, já que cada iteração tem acesso a resultados mais antigos.

    Padrão: número de executores do Spark disponíveis. Máximo: 128. Se o valor for maior que o número de tarefas simultâneas permitidas pela configuração do cluster, o SparkTrials reduz o paralelismo para esse valor.

  • timeout: o número máximo de segundos que uma chamada fmin() pode levar. Quando esse número é excedido, todas as execuções são encerradas e o fmin() sai. As informações sobre execuções concluídas são salvas.

Implementação

Ao definir a função objetiva fn passada para fmin() e ao selecionar uma configuração de cluster, é útil entender como o SparkTrials distribui as tarefas de ajuste.

No Hyperopt, uma avaliação geralmente corresponde ao ajuste de um modelo em uma configuração de hiperparâmetros. O Hyperopt gera avaliações de forma iterativa, as avalia e repete.

Com o SparkTrials, o nó de driver do cluster gera novas avaliações e nós de trabalho avaliam essas avaliações. Cada avaliação é gerada com um trabalho do Spark que tem uma tarefa e é avaliada na tarefa em um computador de trabalho. Se o cluster estiver configurado para executar várias tarefas por trabalho, então várias avaliações poderão ser avaliadas de uma vez nesse trabalho.

SparkTrials e MLflow

O ML do Databricks Runtime dá suporte ao registro do MLflow dos trabalhos. Você pode adicionar o código de registro personalizado na função objetiva que passa para o Hyperopt.

SparkTrials registra os resultados de ajuste como execuções de MLflow aninhados da seguinte maneira:

  • Execução principal ou pai: a chamada para fmin() é registrada como a execução principal. Se houver uma execução ativa, o SparkTrials registra nessa execução ativa e não encerra a execução quando o fmin() retornar. Se não houver nenhuma execução ativa, o SparkTrials criará uma nova execução, registrará nela e terminará a execução antes de fmin() retornar.
  • Execuções filhas: cada configuração de hiperparâmetro testada (uma "avaliação") é registrada como uma execução filha na execução principal. Os registros de log do MLflow dos trabalhos também são armazenados nas execuções filha correspondentes.

Ao chamar fmin(), o Databricks recomenda o gerenciamento de execução do MLflow ativo; ou seja, encapsule a chamada para fmin() dentro de uma instrução with mlflow.start_run():. Isso garante que cada chamada fmin() seja registrada em uma execução principal do MLflow separada e facilita o log de marcas, parâmetros ou métricas extras para a execução.

Observação

Quando você chama o fmin() várias vezes na mesma execução de MLflow ativa, o MLflow registra essas chamadas para a mesma execução principal. Para resolver conflitos de nome para parâmetros e marcas registrados, o MLflow anexa um UUID aos nomes com conflitos.

Ao fazer registro dos trabalhos, você não precisa gerenciar execuções explicitamente na função objetiva. Chame mlflow.log_param("param_from_worker", x) na função objetiva para registrar um parâmetro na execução filha. Você pode registrar parâmetros, métricas, marcas e artefatos na função objetiva.