Procedimientos recomendados y solución de problemas de Hyperopt
Nota:
La versión de código abierto de Hyperopt ya no se mantiene.
Hyperopt se quitará en la siguiente versión principal de DBR ML. Azure Databricks recomienda usar Optuna para obtener una experiencia similar y acceder a algoritmos de ajuste de hiperparámetros más actualizados.
procedimientos recomendados
- Los enfoques bayesianos pueden ser mucho más eficaces que la búsqueda en cuadrícula y la búsqueda aleatoria. Por lo tanto, con el algoritmo de estimadores de Árbol de Parzen (TPE) de Hyperopt, puede explorar más hiperparámetros e intervalos más grandes. El uso de conocimientos de dominio para restringir el dominio de búsqueda puede optimizar el ajuste y generar mejores resultados.
- Cuando se usa
hp.choice(), Hyperopt devuelve el índice de la lista de opciones. Por lo tanto, el parámetro registrado en MLflow también es el índice. Utilicehyperopt.space_eval()para recuperar los valores de parámetro. - Para los modelos con tiempos de entrenamiento largos, empiece a experimentar con conjuntos de datos pequeños y muchos hiperparámetros. Use MLflow para identificar los modelos de mejor rendimiento y determinar qué hiperparámetros se pueden solucionar. De esta manera, puede reducir el espacio de parámetros mientras se prepara para ajustar a escala.
- Aproveche la compatibilidad de Hyperopt con dimensiones condicionales e hiperparámetros. Por ejemplo, al evaluar varios tipos de descenso de gradiente, en lugar de limitar el espacio de hiperparámetros a solo los hiperparámetros comunes, puede hacer que Hyperopt incluya hiperparámetros condicionales, los que solo son adecuados para un subconjunto de los tipos. Para obtener más información sobre el uso de parámetros condicionales, consulte Definición de un espacio de búsqueda.
- Cuando se usa
SparkTrials, configure el paralelismo adecuadamente para los clústeres habilitados solo para CPU en comparación con los clústeres habilitados para GPU. En Azure Databricks, los clústeres de CPU y GPU usan diferentes números de subprocesos de ejecutor por nodo de trabajo. Los clústeres de CPU usan varios subprocesos de ejecutor por nodo. Los clústeres de GPU solo usan un subproceso ejecutor por nodo para evitar conflictos entre varias tareas de Spark que intentan usar la misma GPU. Aunque esto suele ser óptimo para las bibliotecas escritas para GPU, significa que se reduce el paralelismo máximo en clústeres de GPU, por lo que debe tener en cuenta cuántas GPU puede usar cada versión de prueba al seleccionar tipos de instancia de GPU. Consulte Clústeres habilitados para GPU para obtener más información. - No use
SparkTrialsen clústeres de escalado automático. Hyperopt selecciona el valor de paralelismo cuando comienza la ejecución. Si el clúster se escala automáticamente más adelante, Hyperopt no podrá aprovechar el nuevo tamaño del clúster.
Solución de problemas
- Una pérdida notificada de NaN (no un número-not a number) suele significar que la función objetivo se pasa al NaN
fmin()devuelto. Esto no afecta a otras ejecuciones y puede omitirlo de forma segura. Para evitar este resultado, intente ajustar el espacio de hiperparámetros o modificar la función de objetivo. - Dado que Hyperopt usa algoritmos de búsqueda estocásticos, la pérdida normalmente no disminuye de forma monótica con cada ejecución. Sin embargo, estos métodos suelen encontrar los mejores hiperparámetros más rápidamente que otros métodos.
- Tanto Hyperopt como Spark incurren en una sobrecarga que puede dominar la duración de la prueba para las ejecuciones de prueba cortas (decenas de segundos bajas). La velocidad que observe puede ser pequeña o incluso cero.
Cuaderno de ejemplo: procedimientos recomendados para conjuntos de datos de diferentes tamaños
SparkTrials ejecuta las pruebas en los nodos de trabajo de Spark. En este cuaderno se proporcionan directrices sobre cómo debe mover conjuntos de datos de diferentes órdenes de magnitud a los nodos de trabajo cuando se usa SparkTrials.