Pular para o conteúdo principal

Conceitos do Hyperopt

nota

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. A Databricks recomenda o uso do Optuna para otimização de nó único ou do RayTune para obter uma experiência semelhante à funcionalidade de ajuste de hiperparâmetro distribuído Hyperopt, que foi descontinuada. Saiba mais sobre o uso do RayTune no Databricks.

Este artigo descreve alguns dos conceitos que o senhor precisa conhecer para usar o Hyperopt distribuído.

Nesta secção:

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

fmin()​

O senhor usa fmin() para executar uma Hyperopt execução. Os argumentos para fmin() são mostrados na tabela; consulte a documentação do site Hyperopt para obter mais informações. Para obter exemplos de como usar cada argumento, consulte o Notebook de exemplo.

Nome do argumento

Descrição

fn

Função objetiva. O Hyperopt chama essa função com valores gerados a partir do espaço de hiperparâmetros fornecido no argumento space. Essa função pode retornar a perda como um valor escalar ou em um dicionário (consulte os documentos do Hyperopt para obter detalhes). Normalmente, essa função contém código para treinamento de modelos e cálculo de perdas.

space

Define o espaço de hiperparâmetros a ser pesquisado. O Hyperopt oferece grande flexibilidade na definição desse espaço. O senhor pode escolher uma opção categórica, como algoritmo, ou uma distribuição probabilística para valores numéricos, como uniforme e log.

algo

Algoritmo de pesquisa Hyperopt a ser usado para pesquisar o espaço do hiperparâmetro. Os mais usados são hyperopt.rand.suggest para pesquisa aleatória e hyperopt.tpe.suggest para TPE.

max_evals

Número de configurações de hiperparâmetros a serem testadas (o número de modelos a serem ajustados).

max_queue_len

Número de configurações de hiperparâmetro que o Hyperopt deve gerar antecipadamente. Como o algoritmo de geração de Hyperopt TPE pode levar algum tempo, pode ser útil aumentar esse valor além do valor default de 1, mas geralmente não maior do que a configuração SparkTrials parallelism.

trials

Um objeto Trials ou SparkTrials. Use SparkTrials quando o senhor chamar algoritmos de máquina única, como os métodos do scikit-learn na função objetiva. Use Trials quando chamar algoritmos de treinamento distribuído, como os métodos MLlib ou Horovod na função objetiva.

early_stop_fn

Uma função opcional de parada antecipada para determinar se fmin deve parar antes que max_evals seja alcançado. O padrão é None. A assinatura de entrada da função é Trials, *args e a assinatura de saída é bool, *args. O booleano de saída indica se o senhor deve ou não parar. *args é qualquer estado em que a saída de uma chamada para early_stop_fn serve como entrada para a próxima chamada. Trials pode ser um objeto SparkTrials. Ao usar SparkTrials, a função de parada antecipada não tem garantia de execução após cada tentativa e, em vez disso, é sondada. Exemplo de uma função de parada antecipada

A classe SparkTrials​

SparkTrials é uma API desenvolvida pela Databricks que permite que o senhor distribua uma execução do Hyperopt sem fazer outras alterações no código do Hyperopt. SparkTrials acelera o ajuste de uma única máquina, distribuindo as tentativas para Spark trabalhador.

nota

SparkTrials foi projetado para paralelizar os cálculos de modelos 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 modelos é automaticamente paralelizado no clustering e o senhor deve usar a classe default Hyperopt Trials.

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

Argumentos​

SparkTrials usa dois argumentos opcionais:

  • parallelism: Número máximo de ensaios a serem avaliados simultaneamente. Um número maior permite que o senhor amplie o teste de mais configurações de hiperparâmetros. Como o Hyperopt propõe novas tentativas com base em resultados anteriores, há uma compensação entre paralelismo e adaptabilidade. Para um max_evals fixo, um maior paralelismo acelera os cálculos, mas um menor paralelismo pode levar a melhores resultados, pois cada iteração tem acesso a mais resultados anteriores.

    padrão: Número de Spark executor disponível. Máximo: 128. Se o valor for maior do que o número de tarefas concorrentes permitidas pela configuração de clustering, o site SparkTrials reduzirá o paralelismo a esse valor.

  • timeout: Número máximo de segundos que uma chamada fmin() pode levar. Quando esse número for excedido, todas as execuções serão encerradas e o site fmin() sairá. as informações sobre a execução concluída são salvas.

Implantação​

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

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

Com SparkTrials, o nó condutor do seu clustering gera novas tentativas e os nós worker avaliam essas tentativas. Cada tentativa é gerada com um Spark Job que tem uma tarefa e é avaliada na tarefa em uma máquina worker. Se o seu clustering estiver configurado para executar várias tarefas por worker, então várias tentativas poderão ser avaliadas de uma só vez nesse worker.

SparkTrials e MLflow​

Databricks Runtime ML suporta o registro em MLflow a partir do trabalhador. O senhor pode adicionar código de registro personalizado na função objetiva que passa para o Hyperopt.

SparkTrials logs O ajuste resulta em uma execução aninhada em MLflow da seguinte forma:

  • Execução principal ou principal: A chamada para fmin() é registrada como a execução principal. Se houver uma execução ativa, SparkTrials logs para essa execução ativa e não encerra a execução quando fmin() retorna. Se não houver nenhuma execução ativa, SparkTrials cria uma nova execução, logs para ela e termina a execução antes que fmin() retorne.
  • Execução secundária: Cada configuração de hiperparâmetro testada (uma "tentativa") é registrada como uma execução filha sob a execução principal. MLflow log Os registros do trabalhador também são armazenados na execução filha correspondente.

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

nota

Quando o senhor chama fmin() várias vezes dentro da mesma execução ativa MLflow, MLflow logs essas chamadas para a mesma execução principal. Para resolver conflitos de nomes para parâmetros e tags de registros, o site MLflow acrescenta um UUID aos nomes com conflitos.

Ao fazer o logon do trabalhador, o senhor não precisa gerenciar a execução explicitamente na função objetiva. Chame mlflow.log_param("param_from_worker", x) na função objetiva para log um parâmetro para a execução filha. O senhor pode log parâmetros, métricas, tags e artefatos na função objetiva.

Última atualização em