Compartilhar via


Melhores práticas e solução de problemas do Hyperopt

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.

Práticas recomendadas

  • Abordagens bayesianas podem ser muito mais eficientes do que pesquisas dos tipos grade e aleatória. Portanto, com o algoritmo TPE (Árvore Hiperopt de Estimadores de Parzen), você pode explorar mais hiperparâmetros e intervalos maiores. O uso do conhecimento de domínio para restringir o domínio de pesquisa pode otimizar o ajuste e produzir melhores resultados.
  • Quando você usa hp.choice(), o Hyperopt retorna o índice da lista de opções. Portanto, o parâmetro registrado no MLflow também é o índice. Use hyperopt.space_eval() para recuperar os valores do parâmetro.
  • Para modelos com tempos de treinamento longos, comece a experimentar pequenos conjuntos de dados e muitos hiperparâmetros. Use o MLflow para identificar os modelos com melhor desempenho e determinar quais hiperparâmetros podem ser corrigidos. Dessa forma, você pode reduzir o espaço do parâmetro enquanto se prepara para ajustar em escala.
  • Aproveite o suporte do Hyperopt para dimensões condicionais e hiperparâmetros. Por exemplo, quando você avalia vários tipos de gradiente descendente, em vez de limitar o espaço de hiperparâmetro apenas aos hiperparâmetros comuns, pode fazer com que o Hyperopt inclua hiperparâmetros condicionais – apropriados apenas a um subconjunto das variantes. Para obter mais informações sobre o uso de parâmetros condicionais, consulte Definindo um espaço de pesquisa.
  • Ao usar SparkTrials, configure o paralelismo adequadamente para clusters habilitados para CPU somente versus habilitados para GPU. No Azure Databricks, clusters de CPU e GPU usam diferentes números de threads de executor por nó de trabalho. Os clusters de CPU usam vários threads de executor por nó. Os clusters de GPU usam apenas um thread de executor por nó, para evitar conflitos entre várias tarefas do Spark que tentam usar a mesma GPU. Embora isso geralmente seja ideal para bibliotecas gravadas para GPUs, isso significa que o paralelismo máximo é reduzido em clusters de GPU. Por isso, tenha em mente quantas GPUs cada avaliação pode usar ao selecionar tipos de instância de GPU. Confira Clusters habilitados para GPU para obter detalhes.
  • Não use SparkTrials em clusters de dimensionamento automático. O Hyperopt seleciona o valor de paralelismo quando a execução é iniciada. Se, posteriormente, o cluster for dimensionado automaticamente, o Hyperopt não poderá aproveitar o novo tamanho do cluster.

Solução de problemas

  • Uma perda relatada de NaN (não é um número) geralmente significa que a função objetiva passada para fmin() retornou NaN. Isso não afeta outras execuções e pode ser ignorado com segurança. Para evitar esse resultado, tente ajustar o espaço de hiperparâmetro ou modificar a função objetiva.
  • Como o Hyperopt usa algoritmos de pesquisa estocástica, a perda geralmente não diminui de forma monotônica a cada execução. No entanto, esses métodos geralmente encontram os melhores hiperparâmetros mais rapidamente do que outros métodos.
  • O Hyperopt e o Spark incorrem em sobrecarga que pode dominar a duração da avaliação para execuções breves de avaliação (poucas dezenas de segundos). A aceleração observada pode ser pequena ou até mesmo zero.

Notebook de exemplo: práticas recomendadas para conjuntos de dados de diferentes tamanhos

SparkTrials executa as avaliações em nós de trabalho do Spark. Este notebook fornece diretrizes sobre a movimentação de conjuntos de dados de ordens de magnitude diferentes para nós de trabalho ao usar SparkTrials.

Notebook sobre manipulação de conjuntos de dados para diferentes ordens de magnitude

Obter notebook