Práticas recomendadas e solução de problemas do Hyperopt

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.

Melhores Práticas

  • As abordagens Bayesian podem ser muito mais eficientes do que a pesquisa em grade e a pesquisa aleatória. Portanto, com o algoritmo Hyperopt Tree of Parzen Estimators (TPE), você pode explorar mais hiperparâmetros e intervalos maiores. Usar o conhecimento do 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 log in MLflow também é o índice. Use hyperopt.space_eval() para recuperar os valores de parâmetro.

  • Para modelos com longos tempos de treinamento, comece experimentando com pequenos dataset 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 de parâmetros enquanto se prepara para ajustar a escala.

  • Aproveite o suporte do Hyperopt para dimensões condicionais e hiperparâmetros. Por exemplo, ao avaliar vários tipos de gradiente descendente, em vez de limitar o espaço de hiperparâmetros apenas aos hiperparâmetros comuns, você pode fazer com que o Hyperopt inclua hiperparâmetros condicionais — aqueles que são apropriados apenas para um subconjunto dos tipos. Para obter mais informações sobre como usar parâmetros condicionais, consulte Definindo um espaço de pesquisa.

  • Ao usar SparkTrials, configure o paralelismo adequadamente para clusters somente de CPU versus clusters habilitados para GPU. No Databricks, os clusters de CPU e GPU usam números diferentes de threads executor por nó worker . clusters de CPU usam vários threads executor por nó. Os clusters de GPU usam apenas um thread 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 escritas para GPUs, significa que o paralelismo máximo é reduzido em clusters de GPU, portanto, esteja ciente de quantas GPUs cada teste pode usar ao selecionar os tipos de instância de GPU. Consulte clustershabilitados para GPU para obter detalhes.

  • Não use SparkTrials em clusters autoscale . Hyperopt seleciona o valor de paralelismo quando a execução começa. Se os clusters autoscale posteriormente, o Hyperopt não poderá aproveitar o tamanho dos novos clusters .

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 você pode ignorá-lo com segurança. Para evitar esse resultado, tente ajustar o espaço do hiperparâmetro ou modificar a função objetivo.

  • Como o Hyperopt usa algoritmos de pesquisa estocástica, a perda geralmente não diminui monotonicamente a cada execução. No entanto, esses métodos geralmente encontram os melhores hiperparâmetros mais rapidamente do que outros métodos.

  • Tanto o Hyperopt quanto o Spark incorrem em sobrecarga que pode dominar a duração do teste para uma execução de teste curta (baixas dezenas de segundos). A aceleração observada pode ser pequena ou até zero.

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

SparkTrials execução dos testes nos nós worker do Spark. Este Notebook fornece diretrizes sobre como mover dataset de diferentes ordens de magnitude para nós worker ao usar SparkTrials.

Lidar com conjuntos de dados de diferentes ordens de magnitude Notebook

Abra o bloco de anotações em outra guia