Optimización de hiperparámetros para afinar los modelos de transformadores preentrenados de Hugging Face

Los grandes modelos de Transformer basados ​​en la atención han logrado avances masivos en el procesamiento del lenguaje natural (NLP). Sin embargo, entrenar estas gigantescas redes desde cero requiere una enorme cantidad de datos y poder de cómputo. Para conjuntos de datos de NLP más pequeños, una estrategia simple pero efectiva es tomar un transformador previamente entrenado, generalmente entrenado sin supervisión en conjuntos de datos muy grandes, y optimizarlo en el conjunto de datos de interés. Hugging Face mantiene un gran zoológico modelo de estos Transformers pre-entrenados, haciéndolos fácilmente accesibles incluso para el usuario novato.

Sin embargo, el ajuste fino de estos modelos aún requiere conocimiento experto, ya que son muy sensibles a sus hiperparámetros, como la tasa de aprendizaje o el tamaño de la pila. En esta publicación, mostramos cómo ajustar estos hiperparámetros utilizando el marco de ajuste de hiperparámetros distribuidos (HPO) de código abierto Syne Tune. Syne Tune nos permite encontrar una mejor configuración de hiperparámetros que logra una mejora relativa entre el 1 y el 4 % en comparación con los hiperparámetros estándar en los conjuntos de datos de referencia GLUE populares. La elección del modelo preentrenado también puede considerarse como un hiperparámetro y, por lo tanto, Syne Tune lo selecciona automáticamente. Para un problema de clasificación de texto, esto da como resultado un aumento de precisión adicional de alrededor del 5 % en comparación con el modelo estándar. Sin embargo, podemos automatizar más decisiones que un usuario necesita tomar; Demostramos esto al exponer también el tipo de instancia como un hiperparámetro, que luego usamos para implementar el modelo. Al elegir el tipo de instancia correcto, podemos encontrar configuraciones que equilibren mejor el costo y la latencia.

Para obtener una introducción a Syne Tune, consulte Ejecución de hiperparámetros distribuidos y trabajos de ajuste de arquitectura neuronal con Syne Tune.

Ajuste de hiperparámetros con Syne Tune

Usaremos el conjunto de referencia GLUE que consta de nueve conjuntos de datos para tareas de comprensión del lenguaje natural como Para hacer esto, adaptaremos el script de entrenamiento run_glue.py de Hugging Face. Los conjuntos de datos de GLUE vienen con un conjunto de entrenamiento y puntuación predefinido con etiquetas, y un conjunto de prueba de reserva sin etiquetas. Por lo tanto, dividimos el conjunto de entrenamiento en un conjunto de entrenamiento y uno de validación (división del 70 %/30 %) y usamos el conjunto de puntuación como nuestro conjunto de datos de prueba de reserva. Además, estamos agregando otra función de devolución de llamada a la API del entrenador de Hugging Face que informará el rendimiento de la validación a Syne Tune después de cada época. Ver el siguiente código:

import transformers

from syne_tune.report import Reporter

class SyneTuneReporter(transformers.trainer_callback.TrainerCallback):

    def __init__(self):
        self.report = Reporter()

    def on_evaluate(self, args, state, control, **kwargs):
        results = kwargs['metrics'].copy()
        results['step'] = state.global_step
        results['epoch'] = int(state.epoch)
        self.report(**results)

Comenzamos optimizando los hiperparámetros de entrenamiento típicos: la tasa de aprendizaje, la relación de calentamiento para aumentar la tasa de aprendizaje y el tamaño de la pila para ajustar un modelo BERT (Bert-Base-Cased) preentrenado, que es el modelo predeterminado. en el ejemplo de Hugging Face. Ver el siguiente código:

config_space = dict()
config_space['learning_rate'] = loguniform(1e-6, 1e-4)
config_space['per_device_train_batch_size'] =  randint(16, 48)
config_space['warmup_ratio'] = uniform(0, 0.5)

Como nuestro método HPO, usamos ASHA, que muestrea aleatoriamente configuraciones de hiperparámetros de manera uniforme e iterativa deja de evaluar configuraciones de bajo rendimiento. Aunque los métodos más sofisticados usan un modelo probabilístico de la función objetivo, como BO o MoBster, usamos ASHA para este artículo porque no requiere ninguna suposición de espacio de búsqueda.

En la siguiente figura, comparamos la mejora relativa en el error de prueba con respecto a la configuración predeterminada del hiperparámetro Hugging Faces.

Para simplificar, limitamos la comparación a MRPC, COLA y STSB, pero también observamos mejoras similares para otros conjuntos de datos de GLUE. Para cada conjunto de datos, ejecutamos ASHA en una única instancia ml.g4dn.xlarge de Amazon SageMaker con un presupuesto de tiempo de ejecución de 1800 segundos, lo que equivale a aproximadamente 13, 7 y 9 evaluaciones de funciones completas para esos conjuntos de datos, respectivamente. Para tener en cuenta la aleatoriedad intrínseca del proceso de entrenamiento, por ejemplo, causada por el muestreo de mini lotes, ejecutamos ASHA y la configuración predeterminada para cinco repeticiones con una semilla independiente para el generador de números aleatorios e informamos la media y la desviación estándar de la mejora relativa a lo largo de las repeticiones. Podemos ver que en todos los conjuntos de datos podemos mejorar el rendimiento de la predicción entre un 1 y un 3 % en comparación con el rendimiento de la configuración predeterminada cuidadosamente elegida.

Automatice la selección del modelo pre-entrenado

Podemos usar HPO no solo para encontrar hiperparámetros, sino también para seleccionar automáticamente el modelo preentrenado correcto. Por qué queremos hacer esto? Dado que ningún modelo único funciona bien en todos los conjuntos de datos, debemos elegir el modelo correcto para un conjunto de datos determinado. Para demostrar esto, evaluaremos varios modelos populares de transformadores Hugging Face. Para cada conjunto de datos, clasificamos cada modelo en función de su rendimiento de prueba. La clasificación de los registros (consulte la figura a continuación) cambia, en lugar de que un solo modelo obtenga la puntuación más alta en cada registro. Como referencia, también mostramos el rendimiento absoluto de la prueba de cada modelo y conjunto de datos en la siguiente figura.

Para elegir automáticamente el modelo correcto, podemos transformar la elección del modelo en parámetros categóricos y agregar esto a nuestro espacio de búsqueda de hiperparámetros:

config_space['model_name_or_path'] = choice(['bert-base-cased', 'bert-base-uncased', 'distilbert-base-uncased', 'distilbert-base-cased', 'roberta-base', 'albert-base-v2', 'distilroberta-base', 'xlnet-base-cased', 'albert-base-v1'])

Aunque el espacio de búsqueda ahora es más grande, eso no significa necesariamente que sea más difícil de optimizar. La siguiente figura muestra el error de prueba de la mejor configuración observada (basada en el error de validación) en el conjunto de datos MRPC de ASHA a lo largo del tiempo cuando buscamos en la región original (línea azul) (usando un modelo preentrenado basado en BERT). ) o en la nueva área de búsqueda avanzada (línea naranja). Por el mismo presupuesto, ASHA puede encontrar una configuración de hiperparámetros mucho más potente en el ámbito de búsqueda ampliado que en el ámbito más pequeño.

Automatice la selección del tipo de instancia

En la práctica, es posible que no solo nos preocupemos por optimizar el rendimiento de la predicción. También podríamos encargarnos de otros destinos, tales como: B. Tiempo de capacitación, costos (en dólares), latencia o métricas de imparcialidad. También necesitamos tomar otras decisiones más allá de los hiperparámetros del modelo, como la selección del tipo de instancia.

Aunque el tipo de instancia no afecta el rendimiento de la predicción, tiene un gran impacto en el costo (dólares), el tiempo de ejecución del entrenamiento y la latencia. Esto último se vuelve particularmente importante cuando se implementa el modelo. Podemos formular HPO como un problema de optimización de múltiples objetivos en el que apuntamos a optimizar múltiples objetivos simultáneamente. Sin embargo, ninguna solución única optimiza todas las métricas simultáneamente. En su lugar, nuestro objetivo es encontrar un conjunto de configuraciones que equilibren mejor un objetivo con el otro. Esto se llama el conjunto de Pareto.

Para analizar más a fondo esta configuración, agregamos la opción de tipo de instancia a nuestro espacio de búsqueda como un hiperparámetro categórico adicional:

config_space['st_instance_type'] = choice(['ml.g4dn.xlarge', 'ml.g4dn.2xlarge', 'ml.p2.xlarge', 'ml.g4dn.4xlarge', 'ml.g4dn.8xlarge', 'ml.p3.2xlarge'])

Usamos MO-ASHA, que adapta ASHA al escenario de objetivos múltiples mediante el uso de una ordenación no dominada. En cada iteración, MO-ASHA también elige para cada configuración el tipo de instancia en la que queremos evaluarla. Para ejecutar HPO en un conjunto heterogéneo de instancias, Syne Tune proporciona el backend de SageMaker. Con este backend, cada prueba se evalúa como un trabajo de capacitación independiente de SageMaker en su propia instancia. La cantidad de trabajadores define cuántos trabajos de SageMaker estamos ejecutando en paralelo en un momento dado. El optimizador en sí, en nuestro caso MO-ASHA, se ejecuta en la máquina local, en una computadora portátil de SageMaker o en un trabajo de capacitación de SageMaker por separado. Ver el siguiente código:

backend = SageMakerBackend(
    sm_estimator=HuggingFace(
        entry_point=str('run_glue.py'),
        source_dir=os.getcwd(),
        base_job_name="glue-moasha",
        # instance-type given here are override by Syne Tune with values sampled from `st_instance_type`.
        instance_type="ml.m5.large",
        instance_count=1,
        py_version="py38",
        pytorch_version='1.9',
        transformers_version='4.12',
        max_run=3600,
        role=get_execution_role(),
    ),
)

Las siguientes figuras muestran latencia versus error de prueba a la izquierda y latencia versus costo a la derecha para configuraciones aleatorias muestreadas por MO-ASHA (recortamos el eje para visibilidad) en el conjunto de datos MRPC después de 10 800 segundos de duración en cuatro trabajadores. El color indica el tipo de instancia. La línea negra discontinua representa el conjunto de Pareto, es decir, el conjunto de puntos que domina a todos los demás puntos en al menos un objetivo.

Podemos observar una compensación entre la latencia y el error de prueba, lo que significa que la mejor configuración con el error de prueba más bajo no logrará la latencia más baja. Según sus preferencias, puede elegir una configuración de hiperparámetros que afecte el rendimiento de la prueba pero que tenga una latencia más baja. También vemos la compensación entre latencia y costo. Por ejemplo, al usar una instancia ml.g4dn.xlarge más pequeña, agregamos solo una pequeña cantidad de latencia a una cuarta parte del costo de una instancia ml.g4dn.8xlarge.

Conclusión

En esta publicación, discutimos la optimización de hiperparámetros para afinar los modelos Hugging Face Transformer preentrenados basados ​​en Syne Tune. Hemos visto que al ajustar hiperparámetros como la tasa de aprendizaje, el tamaño de la pila y la tasa de calentamiento, podemos mejorar la configuración predeterminada cuidadosamente elegida. También podemos extender esto seleccionando automáticamente el modelo preentrenado a través de la optimización de hiperparámetros.

Con el backend SageMaker de Syne Tune, podemos tratar el tipo de instancia como un hiperparámetro. Aunque el tipo de instancia no afecta el rendimiento, tiene un impacto significativo en la latencia y el costo. Por lo tanto, al representar HPO como un problema de optimización multiobjetivo, podemos encontrar un conjunto de configuraciones que compensan de manera óptima un objetivo contra el otro. Si quiere probarlo usted mismo, consulte nuestro cuaderno de muestra.

Sobre los autores

aarón klein es científico aplicado en AWS.

Mathias Seeger es científico principal aplicado en AWS.

david salinas es científico senior aplicado en AWS.

emilio weber se unió a AWS poco después de lanzar SageMaker y desde entonces ha estado tratando de contárselo al mundo. Además de desarrollar nuevas experiencias de aprendizaje automático para los clientes, a Emily le gusta meditar y estudiar el budismo tibetano.

cedric archambeau es científico aplicado principal en AWS y miembro del Laboratorio Europeo de Aprendizaje y Sistemas Inteligentes.