Práticas recomendadas e solução de problemas 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.

Melhores práticas

• Bayesian As abordagens 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), o senhor 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 o senhor usa hp.choice(), o Hyperopt retorna o índice da lista de opções. Portanto, o parâmetro log em MLflow também é o índice. Use hyperopt.space_eval() para recuperar os valores dos parâmetros.
• Para modelos com longos tempos de treinamento, comece a fazer experimentos com pequenos conjuntos de dados e muitos hiperparâmetros. Use o MLflow para identificar os modelos de melhor desempenho e determinar quais hiperparâmetros podem ser fixados. Dessa forma, o senhor pode reduzir o espaço de parâmetros enquanto se prepara para sintonizar em escala.
• Aproveite o suporte do Hyperopt para dimensões condicionais e hiperparâmetros. Por exemplo, quando o usuário avalia várias variantes de descida de gradiente, em vez de limitar o espaço de hiperparâmetros apenas aos hiperparâmetros comuns, é possível fazer com que o Hyperopt inclua hiperparâmetros condicionais - aqueles que são apropriados apenas para um subconjunto das variantes. Para obter mais informações sobre o uso de parâmetros condicionais, consulte Definição de um espaço de pesquisa.
• Ao usar o site SparkTrials, configure o paralelismo adequadamente para clustering somente de CPU versus clustering habilitado para GPU. Em Databricks, o clustering de CPU e GPU usa números diferentes de threads executor por nó worker. O clustering de CPU usa vários threads executor por nó. O clustering de GPU usa apenas um thread executor por nó para evitar conflitos entre várias tarefas Spark que tentam usar a mesma GPU. Embora isso seja geralmente ideal para bibliotecas escritas para GPUs, significa que o paralelismo máximo é reduzido no clustering da GPU, portanto, esteja ciente de quantas GPUs cada tentativa pode usar ao selecionar os tipos de instância da GPU. Consulte Clustering habilitado para GPU para obter detalhes.
• Não use o site SparkTrials no clustering de autoescala. O Hyperopt seleciona o valor do paralelismo quando a execução é iniciada. Se o clustering for dimensionado automaticamente mais tarde, o site Hyperopt não poderá aproveitar o novo tamanho do clustering.

Solução de problemas

• Uma perda relatada de NaN (não um número) geralmente significa que a função objetivo passada para fmin() retornou NaN. Isso não afeta outras execuções e o senhor 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 execução de testes curtos (poucas dezenas de segundos). A aceleração que você observa pode ser pequena ou até zero.

Caderno de exemplos: Práticas recomendadas para conjuntos de dados de diferentes tamanhos

SparkTrials executar os testes em Spark worker nodes. Este Notebook fornece diretrizes sobre como mover conjuntos de dados de diferentes ordens de magnitude para worker nodes ao usar SparkTrials.

Lidar com conjuntos de dados de diferentes ordens de magnitude Notebook

Open notebook in new tab