conceitos de hiperopção

Observação

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

Hyperopt não será mais pré-instalado em Databricks Runtime ML 17.0 e acima. A Databricks recomenda o uso do Optuna para obter 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.

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

fmin()

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

nome do argumento

Descrição

fn

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

space

Define o espaço de hiperparâmetros a ser pesquisado. O Hyperopt fornece grande flexibilidade em 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 logs.

algo

Algoritmo de pesquisa Hyperopt a ser usado para pesquisar o espaço de hiperparâmetros. Os mais comumente 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âmetros que o Hyperopt deve gerar antecipadamente. Como o algoritmo de geração do Hyperopt TPE pode levar algum tempo, pode ser útil aumentá-lo além do valor default de 1, mas geralmente não maior que a configuração SparkTrials parallelism.

trials

Um objeto Trials ou SparkTrials . Use SparkTrials ao chamar algoritmos de máquina única, como métodos Scikit-Learn na função objetiva. Use Trials ao chamar algoritmos de treinamento distribuído, como métodos MLlib ou Horovod na função objetivo.

early_stop_fn

Uma função opcional de parada antecipada para determinar se fmin deve parar antes de max_evals ser alcançado. default é None. A assinatura de entrada da função é Trials, *args e a assinatura de saída é bool, *args. A saída Boolean indica se deve ou não parar. *args é qualquer estado, onde 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, é pesquisada. Exemplo de uma função de parada antecipada

A classe SparkTrials

SparkTrials é uma API desenvolvida pela Databricks que permite distribuir uma execução Hyperopt sem fazer outras alterações em seu código Hyperopt. SparkTrials acelera o ajuste de máquina única distribuindo testes para worker Spark .

Observação

SparkTrials foi projetado para paralelizar cálculos para modelos de ML de máquina única, como Scikit-Learn. Para modelos criados com algoritmos de ML distribuídos, como MLlib ou Horovod, não use SparkTrials. Neste caso, o processo de construção do modelo é paralelizado automaticamente nos clusters e você deve usar a classe Hyperopt default Trials.

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

argumentos

SparkTrials recebe dois argumentos opcionais:

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

    default: número de executores do Spark disponíveis. Máximo: 128. Se o valor for maior que o número de tarefas concorrentes permitidas pela configuração clusters , SparkTrials reduz o paralelismo a esse valor.

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

Implementação

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

No Hyperopt, uma tentativa geralmente corresponde ao ajuste de um modelo em uma configuração de hiperparâmetros. O Hyperopt gera testes iterativamente, avalia-os e repete.

Com SparkTrials, o nó do driver de seus clusters gera novos testes e os nós worker avaliam esses testes. Cada tentativa é gerada com um Spark Job que tem uma tarefa e é avaliada na tarefa em uma máquina worker . Se seus clusters estiverem configurados para executar várias tarefas por worker, várias tentativas poderão ser avaliadas de uma só vez nesse worker.

SparkTrials e MLflow

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

SparkTrials logs resultados de ajuste como execução de MLflow aninhada da seguinte forma:

  • Execução principal ou pai: a chamada para fmin() é logs como a execução principal. Se houver uma execução ativa, SparkTrials logs nessa execução ativa e não terminará a execução quando fmin() retornar. Se não houver nenhuma execução ativa, SparkTrials cria uma nova execução, logs nela e termina a execução antes que fmin() retorne.

  • Execuções secundárias: cada configuração de hiperparâmetro testada (uma “avaliação”) é logs como uma execução secundária na execução principal. Os registros logs do MLflow do worker também são armazenados na execução do filho correspondente.

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

Observação

Quando você chama fmin() várias vezes na mesma execução ativa do MLflow, o MLflow logs essas chamadas na mesma execução principal. Para resolver conflitos de nomes para parâmetros e tags logs , o MLflow acrescenta um UUID aos nomes com conflitos.

Ao efetuar login do worker, você não precisa gerenciar a execução explicitamente na função objetivo. Chame mlflow.log_param("param_from_worker", x) na função objetivo para logs um parâmetro na execução filha. Você pode logs parâmetros, métricas, tags e artefatos na função objetivo.