Prácticas recomendadas y flujo de trabajo sugerido

En esta página se describen las prácticas recomendadas para la búsqueda con arquitectura neuronal, suponiendo que ya has completado los tutoriales. En la primera sección se resume un flujo de trabajo completo que puedes seguir para tu tarea de búsqueda con arquitectura neuronal. En las otras secciones se proporciona una descripción detallada de cada paso. Te recomendamos que leas toda esta página antes de ejecutar tu primer trabajo de búsqueda con arquitectura neuronal.

Flujo de trabajo sugerido

A continuación, resumimos un flujo de trabajo sugerido para la búsqueda con arquitectura neuronal y proporcionamos enlaces a las secciones correspondientes para obtener más información:

  1. Divide tu conjunto de datos de entrenamiento para la búsqueda de la fase 1.
  2. Asegúrate de que tu espacio de búsqueda cumple nuestras directrices.
  3. Ejecuta el entrenamiento completo con tu modelo de referencia y obtén una curva de validación.
    1. Optimiza el tiempo de entrenamiento de tu modelo de referencia.
  4. Ejecuta las herramientas de diseño de proxy-task para encontrar la mejor tarea proxy.
  5. Haz las comprobaciones finales de tu tarea de proxy.
  6. Define el número adecuado de pruebas totales y pruebas paralelas y, a continuación, inicia la búsqueda.
  7. Monitoriza el gráfico de búsqueda y detenlo cuando converja, muestre un gran número de errores o no muestre ningún signo de convergencia.
  8. Realiza un entrenamiento completo con las 10 mejores pruebas elegidas de tu búsqueda para obtener el resultado final. Para el entrenamiento completo, puedes usar más aumentos o pesos preentrenados para obtener el mejor rendimiento posible.
  9. Analiza las métricas o los datos guardados de la búsqueda y extrae conclusiones para futuras iteraciones del espacio de búsqueda.

Búsqueda en NAS.

En la figura anterior se muestra una curva típica de búsqueda con arquitectura neuronal. El Y-axis muestra las recompensas de prueba y el X-axis muestra el número de pruebas que se han iniciado hasta el momento. Las primeras 100-200 pruebas son principalmente exploraciones aleatorias del espacio de búsqueda por parte del controlador. Durante estas exploraciones iniciales, las recompensas muestran una gran varianza porque se están probando muchos tipos de modelos en el espacio de búsqueda. A medida que aumenta el número de pruebas, el controlador empieza a encontrar mejores modelos. Por lo tanto, primero empieza a aumentar la recompensa y, después, la varianza y el crecimiento de la recompensa empiezan a disminuir, lo que muestra la convergencia. El número de pruebas en las que se produce la convergencia puede variar en función del tamaño del espacio de búsqueda, pero suele ser del orden de ~2000 pruebas.

Dos fases de la búsqueda con arquitectura neuronal: tarea proxy y entrenamiento completo

La búsqueda con arquitectura neuronal funciona en dos fases:

  • La búsqueda de la fase 1 usa una representación mucho más pequeña del entrenamiento completo, que suele completarse en 1 o 2 horas. Esta representación se denomina tarea proxy y ayuda a mantener bajo el coste de búsqueda.

  • La fase 2 (entrenamiento completo) consiste en entrenar por completo los 10 modelos con mejor puntuación de la fase 1 (búsqueda). Debido a la naturaleza estocástica de la búsqueda, es posible que el modelo superior de la fase 1 de búsqueda no sea el modelo superior durante la fase 2 de entrenamiento completo. Por lo tanto, es importante seleccionar un conjunto de modelos para el entrenamiento completo.

Como el controlador obtiene la señal de recompensa de la tarea proxy más pequeña en lugar del entrenamiento completo, es importante encontrar una tarea proxy óptima para tu tarea.

Coste de Neural Architecture Search

El coste de Neural Architecture Search se calcula de la siguiente manera: search-cost = num-trials-to-converge * avg-proxy-task-cost. Si suponemos que el tiempo de computación de proxy-task es aproximadamente 1/30 del tiempo de entrenamiento completo y que el número de pruebas necesarias para converger es de unas 2000, el coste de búsqueda será de aproximadamente 67 * full-training-cost.

Dado que el coste de Neural Architecture Search es elevado, es recomendable dedicar tiempo a ajustar la tarea proxy y usar un espacio de búsqueda más pequeño en la primera búsqueda.

División del conjunto de datos entre dos fases de la búsqueda con arquitectura neuronal

Si ya tienes los datos de entrenamiento y los datos de validación para el entrenamiento de referencia, te recomendamos que dividas el conjunto de datos de la siguiente manera para las dos fases de la búsqueda de arquitectura neuronal (NAS):

  • Entrenamiento de la fase 1: ~90% de los datos de entrenamiento
  • Validación de búsqueda de la fase 1: ~10% de los datos de entrenamiento

  • Entrenamiento de la fase 2 completo: 100% de los datos de entrenamiento

  • Validación de entrenamiento completo de la fase 2: 100% de los datos de validación

La división de datos de la fase 2 del entrenamiento completo es la misma que la del entrenamiento normal. Sin embargo, la búsqueda de la fase 1 usa una división de datos de entrenamiento para la validación. Usar datos de validación diferentes en las fases 1 y 2 ayuda a detectar cualquier sesgo de búsqueda de modelos debido a la división del conjunto de datos. Asegúrate de que los datos de entrenamiento se barajan bien antes de particionarlos y de que el 10% final de los datos de entrenamiento tenga una distribución similar a la de los datos de validación originales.

Datos escasos o desequilibrados

No se recomienda la búsqueda de arquitectura con datos de entrenamiento limitados ni con conjuntos de datos muy desequilibrados en los que algunas clases sean muy raras. Si ya estás usando aumentos pesados para tu entrenamiento de referencia debido a la falta de datos, no se recomienda la búsqueda de modelos.

En este caso, solo puedes ejecutar la búsqueda de aumento augmentation-search para buscar la mejor política de aumento en lugar de buscar una arquitectura óptima.

Diseño de espacios de búsqueda

  • La búsqueda de arquitectura no debe combinarse con la búsqueda de aumento ni con la búsqueda de hiperparámetros (como la tasa de aprendizaje o la configuración del optimizador). El objetivo de la búsqueda de arquitecturas es comparar el rendimiento del modelo A con el del modelo B cuando solo hay diferencias basadas en la arquitectura. Por lo tanto, los ajustes de aumento y de hiperparámetros deben seguir siendo los mismos.

  • La búsqueda de aumentos se puede realizar en una fase diferente después de la búsqueda de arquitectura.

  • La búsqueda con arquitectura neuronal puede alcanzar un tamaño de espacio de búsqueda de hasta 10^20. Sin embargo, si el espacio de búsqueda es mayor, puedes dividirlo en partes mutuamente exclusivas. Por ejemplo, puedes buscar el codificador por separado del decodificador o del encabezado. Si quieres hacer una búsqueda conjunta en todos ellos, puedes crear un espacio de búsqueda más pequeño en torno a las mejores opciones individuales que hayas encontrado anteriormente.

  • (Opcional) Puedes escalar el modelo desde el diseño de bloques al diseñar un espacio de búsqueda. La búsqueda de diseños de bloques debe hacerse primero con un modelo reducido. De esta forma, el coste del tiempo de ejecución de la tarea proxy será mucho menor. Después, puedes hacer una búsqueda independiente para ampliar el modelo. Para obtener más información, consulta Examples of scaled down models.

Optimizar el tiempo de entrenamiento y de búsqueda

Antes de ejecutar la búsqueda de arquitectura neuronal, es importante optimizar el tiempo de entrenamiento de tu modelo de referencia. De esta forma, ahorrarás costes a largo plazo. Estas son algunas de las opciones para optimizar el entrenamiento:

  • Maximizar la velocidad de carga de datos:
    • Asegúrate de que el segmento en el que residen tus datos esté en la misma región que tu trabajo.
    • Si usas TensorFlow, consulta Best practice summary. También puedes probar a usar el formato TFRecord para tus datos.
    • Si usas PyTorch, sigue las directrices para entrenar PyTorch de forma eficiente.
  • Usa el entrenamiento distribuido para aprovechar varias máquinas o aceleradores.
  • Usa el entrenamiento con precisión mixta para acelerar significativamente el entrenamiento y reducir el uso de memoria. Para obtener información sobre el entrenamiento con precisión mixta de TensorFlow, consulta este artículoMixed Precision.
  • Algunos aceleradores (como A100) suelen ser más rentables.
  • Ajusta el tamaño del lote para asegurarte de que estás maximizando la utilización de la GPU. En el siguiente gráfico se muestra la infrautilización de las GPUs (al 50%). Uso de GPU Aumentar el tamaño del lote puede ayudar a utilizar más las GPUs. Sin embargo, el tamaño del lote debe aumentarse con cuidado, ya que puede provocar errores de falta de memoria durante la búsqueda.
  • Si determinados bloques de arquitectura son independientes del espacio de búsqueda, puedes probar a cargar puntos de control preentrenados para estos bloques y así acelerar el entrenamiento. Los puntos de control preentrenados deben ser iguales en todo el espacio de búsqueda y no deben introducir sesgos. Por ejemplo, si tu espacio de búsqueda es solo para el decodificador, el codificador puede usar puntos de control preentrenados.

Número de GPUs por prueba de búsqueda

Usa un número menor de GPUs por prueba para reducir el tiempo de inicio. Por ejemplo, 2 GPUs tardan 5 minutos en iniciarse, mientras que 8 GPUs tardan 20 minutos. Es más eficiente usar 2 GPUs por prueba para ejecutar una tarea proxy de Neural Architecture Search.

Número total de pruebas y pruebas paralelas de búsqueda

Configuración total de la prueba

Una vez que hayas buscado y seleccionado la mejor tarea de proxy, podrás iniciar una búsqueda completa. No es posible saber de antemano cuántas pruebas se necesitarán para llegar a la convergencia. El número de pruebas en las que se produce la convergencia puede variar en función del tamaño del espacio de búsqueda, pero suele ser del orden de 2000 pruebas aproximadamente.

Recomendamos usar un valor muy alto para --max_nas_trial, aproximadamente entre 5000 y 10.000, y, a continuación, cancelar el trabajo de búsqueda antes si el gráfico de búsqueda muestra convergencia. También puedes reanudar un trabajo de búsqueda anterior con el comando search_resume. Sin embargo, no puedes reanudar la búsqueda desde otra tarea de reanudación de búsqueda. Por lo tanto, solo puedes reanudar una búsqueda original una vez.

Ajuste de pruebas paralelas

La tarea stage1-search realiza un procesamiento por lotes ejecutando --max_parallel_nas_trial pruebas en paralelo a la vez. Esto es fundamental para reducir el tiempo de ejecución general de la tarea de búsqueda. Puedes calcular el número esperado de días de búsqueda de la siguiente forma: days-required-for-search = (trials-to-converge / max-parallel-nas-trial) * (avg-trial-duration-in-hours / 24) Nota: Inicialmente, puedes usar 3000 como estimación aproximada de trials-to-converge, que es un buen límite superior para empezar. Inicialmente, puedes usar 2 horas como estimación aproximada del avg-trial-duration-in-hours, que es un buen límite superior del tiempo que tarda cada tarea proxy. Es recomendable usar el ajuste --max_parallel_nas_trial de entre 20 y 50, en función de la cuota de acelerador que tenga tu proyecto y days-required-for-search. Por ejemplo, si asignas el valor --max_parallel_nas_trial a 20 y cada tarea proxy usa dos GPUs NVIDIA T4, deberías haber reservado una cuota de al menos 40 GPUs NVIDIA T4. El ajuste de --max_parallel_nas_trial no afecta al resultado de búsqueda general, pero sí influye en el days-required-for-search. También se puede usar un valor más pequeño para max_parallel_nas_trial, como 10 (20 GPUs), pero en ese caso debes estimar aproximadamente el valor de days-required-for-search y asegurarte de que no supere el límite de tiempo de espera de los trabajos.

De forma predeterminada, el trabajo stage2-full-training suele entrenar todas las pruebas en paralelo. Normalmente, se trata de las 10 pruebas principales que se ejecutan en paralelo. Sin embargo, si cada prueba de entrenamiento completo de la fase 2 usa demasiadas GPUs (por ejemplo, ocho GPUs cada una) para tu caso práctico y no tienes una cuota suficiente, puedes ejecutar manualmente los trabajos de la fase 2 en lotes. Por ejemplo, puedes ejecutar un entrenamiento completo de la fase 2 para cinco pruebas y, después, ejecutar otro entrenamiento completo de la fase 2 para las cinco pruebas siguientes.

Tiempo de espera predeterminado de los trabajos

El tiempo de espera predeterminado de las tareas de NAS es de 14 días. Después, la tarea se cancela. Si prevés que el trabajo se ejecutará durante más tiempo, puedes probar a reanudarlo solo una vez más durante 14 días. En general, puedes publicar una oferta de empleo durante 28 días, incluido el currículum.

Ajuste de número máximo de intentos fallidos

El número máximo de pruebas fallidas debe ser aproximadamente un tercio del ajuste max_nas_trial. El trabajo se cancelará cuando el número de intentos fallidos alcance este límite.

Deberías detener la búsqueda cuando:

  • La curva de búsqueda empieza a converger (la varianza disminuye): Búsqueda en NAS. Nota: Si no se usa ninguna restricción de latencia o se usa la restricción de latencia estricta con un límite de latencia flexible, es posible que la curva no muestre un aumento de la recompensa, pero sí debería mostrar convergencia. Esto se debe a que el controlador puede haber visto buenas precisiones al principio de la búsqueda.

  • Más del 20% de tus pruebas muestran recompensas no válidas (fallos): Error de búsqueda de NAS.

  • La curva de búsqueda no aumenta ni converge (como se muestra arriba), ni siquiera después de unas 500 pruebas. Si se muestra algún aumento de la recompensa o disminución de la varianza, puedes continuar.