Predicción del rendimiento de una red neuronal profunda para optimizar sus hiperparámetros.

UNIVERSIDAD DE SANTIAGO DE COMPOSTELA ESCUELA T´ ECNICA SUPERIOR DE INGENIER´ IA Predicci´on del rendimiento de una red neuronal profunda para optimizar sus hiperpar´ametros. Autor/a: Juan Pablo Garc´ıa Amboage Tutores: Anselmo Tom´as Fern´andez Pena Eric Gustaf Ted Wulff Grado en Ingenier´ıa Inform´atica Julio 2023 Trabajo de Fin de Grado presentado en la Escuela T´ecnica Superior de Ingenier´ıa de la Universidad de Santiago de Compostela para la obtenci´on del Grado en Ingenier´ıa Inform´atica Agradecimientos I aknowledge CERN Openlab, CoE RAISE and the J¨ulich Supercomputing Center for supporting this work and providing the needed computing infrastructure. I am especially grateful to Eric and Maria for giving me such a special opportunity. A mi tutor Tom´as por haberse prestado a esta colaboraci´on, por su apoyo y disponibilidad durante el proyecto. A mis amigos, especialmente a mis compa˜neros del doble grado por todos estos a˜nos juntos. Por ´ultimo, a mi familia. 3 4 Resumen Este trabajo estudia el uso de predictores de rendimiento con el objetivo de acelerar la optimizaci´on de hiperpar´ametros de modelos de aprendizaje profundo. M´as concretamente, se muestra c´omo la regresi´on de vectores de soporte, tanto en su versi´on cl´asica como cu´antica, es un modelo con buena capacidad para predecir el rendimiento de la red neuronal para reconstrucci´on de flujo de part´ıculas MLPF. Adem´as, se introduce un nuevo algoritmo para optimizaci´on de hiperpar´ametros, denominado Swift-Hyperband, que permite hacer uso de predictores de rendimiento, tanto cl´asicos como cu´anticos, para acelerar la optimizaci´on de hiperpar´ametros. En las pruebas realizadas, tanto para MLPF como para otros modelos objetivo de distintos dominios, Swift-Hyperband demostr´o una capacidad de optimizaci´on similar, o incluso superior, a la de los algoritmos existentes c´omo Hyperband y Fast-Hyperband a costa de un menor consumo de recursos computacionales. 5 6 ´ Indice general 1. Introducci´on 1 1.1. Reconstrucci´on de flujo de part´ıculas . . . . . . . . . . . . . . . . 2 1.2. Optimizaci´on de Hiperpar´ametros . . . . . . . . . . . . . . . . . . 3 1.2.1. Predicci´on de rendimiento . . . . . . . . . . . . . . . . . . 5 1.3. Computaci´on cu´antica mediante annealers ............. 6 1.4. Objetivos del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Organizaci´on de la memoria . . . . . . . . . . . . . . . . . . . . . 8 2. Estado del conocimiento del problema 9 2.1. Estado del arte de HPO y m´etodos de early-stopping ....... 9 2.1.1. Early-stopping ......................... 11 2.2. Predicci´on del rendimiento para HPO . . . . . . . . . . . . . . . . 14 2.2.1. Fast-Hyperband . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3. Adaptaci´on del modelo SVR a Q-SVR . . . . . . . . . . . . . . . 17 3. Materiales 21 3.1. Recursos Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Conjuntos de datos de curvas de aprendizaje . . . . . . . . . . . . 21 3.3. Librer´ıas................................ 23 4. Metodolog´ıa 25 4.1. EstudioPreliminar .......................... 25 4.1.1. Predicci´on de rendimiento de MLPF con SVRs . . . . . . . 26 4.1.2. Predicci´on de rendimiento de MLPF con Q-SVRs . . . . . 27 4.2. Integraci´on de los predictores con HPO . . . . . . . . . . . . . . . 30 4.2.1. Fast-Hyperband . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.2. Swift-Hyperband . . . . . . . . . . . . . . . . . . . . . . . 32 5. Pruebas y discusi´on de resultados 37 5.1. Predicci´on de rendimiento de MLPF . . . . . . . . . . . . . . . . 37 5.1.1. Resultados con SVRs cl´asicas . . . . . . . . . . . . . . . . 37 5.1.2. Resultados con Q-SVRs . . . . . . . . . . . . . . . . . . . 39 5.2. Comparativa de los algoritmos de HPO . . . . . . . . . . . . . . . 40 7 5.2.1. Paralelizaci´on de Swift-Hyperband . . . . . . . . . . . . . 43 5.3. Par´ametros utilizados en las pruebas . . . . . . . . . . . . . . . . 44 6. Conclusiones y posibles ampliaciones 47 6.1. Trabajofuturo ............................ 48 A. Manuales T´ecnicos 49 A.1. Estructura de ficheros . . . . . . . . . . . . . . . . . . . . . . . . 49 A.2. Creaci´on del entorno . . . . . . . . . . . . . . . . . . . . . . . . . 52 A.3. Reproducci´on de los resultados . . . . . . . . . . . . . . . . . . . 53 B. Manuales de usuario 55 C. Licencia 57 Bibliograf´ıa 63 8 ´ Indice de figuras 1.1. Representaci´on gr´afica de la predicci´on de rendimiento. . . . . . . 5 2.1. Representaci´on de la idea general de los m´etodos de early-stopping. 12 4.1. Representaci´on gr´afica del algoritmo Swift-Hyperband. . . . . . . 33 5.1. Predicci´on de rendimiento de MLPF mediante SVRs cl´asicas. . . . 38 5.2. Valores de test reales frente a predichos mediante Q-SVR. . . . . 39 5.3. Resultados tras 10 ejecuciones simuladas de Hyperband, Fast-Hyperband y Swift-Hyperband para distintos modelos objetivo. . . . . . . . . 41 5.4. Resultados tras 5 ejecuciones de Hyperband, Fast-Hyperband y Swift-Hyperband. .......................... 42 5.5. Speedup de la versi´on distribuida de Swift-Hyperband. . . . . . . . 44 9 4CAP´ ITULO 1. INTRODUCCI ´ ON no se garantiza una elecci´on ´optima de hiperpar´ametros, m´as bien ayuda a seleccionar un conjunto de hiperpar´ametros “aceptable”. Adem´as, la tendencia actual en el aprendizaje autom´atico es trabajar con arquitecturas cada vez m´as complejas lo que hace que seleccionar buenos hiperpar´ametros se vuelve una tarea a´un m´as complicada. Estos modelos tienen un mayor n´umero de hiperpar´ametros que pueden interactuar entre s´ı, de forma que no exista, por ejemplo, una tasa de aprendizaje ´optima de forma “aislada” si no que un cierto valor fijado de tasa de aprendizaje puede ser mejor o peor dependiendo del valor que tomen los dem´as hiperpar´ametros. El aprendizaje autom´atico automatizado (AutoML) es una disciplina que busca mitigar (o incluso eliminar) la necesidad de la experiencia de los expertos en el desarrollo de modelos de aprendizaje autom´atico [37], a cambio de un incremento en los recursos computacionales usados en el desarrollo de los modelos. Uno de los componentes clave del AutoML es la optimizaci´on de hiperpar´ametros (HPO por sus siglas en ingl´es) que abarca los distintos algoritmos y estrategias para buscar y seleccionar autom´aticamente configuraciones de hiperpar´ametros ´optimas. Cuando los hiperpar´ametros a optimizar afectan a la arquitectura del modelo hay autores que hablan de “b´usqueda de arquitectura neuronal” (NAS por sus siglas en ingl´es) [29]. En este trabajo no haremos esta distinci´on y usaremos el t´ermino optimizaci´on de hiperpar´ametros para referirnos a la optimizaci´on de cualquier tipo de hiperpar´ametro. Para que un m´etodo de HPO pueda ser considerado bueno debe tener la capacidad de encontrar buenas configuraciones cuando se aplica a distintos tipos de modelos o arquitecturas [37, 15]. Es decir, el proceso de optimizaci´on de hiperpar´ametros se afronta como una optimizaci´on de “caja negra” [20, 15] en la que se busca minimizar la funci´on de p´erdida del modelo tras haber sido entrenado un n´umero fijado de ´epocas. El t´ermino “caja negra” se debe a que no se dispone de una expresi´on matem´atica expl´ıcita que represente la p´erdida del modelo como una funci´on de sus hiperpar´ametros y del n´umero de ´epocas de entrenamiento. De esta forma, se busca optimizar una funci´on muy costosa de evaluar, ya que conocer su valor exacto para una cierta configuraci´on de hiperpar´ametros implica entrenar el modelo N´epocas con dicha configuraci´on. Es por esto que la optimizaci´on de hiperpar´ametros es un proceso que, a menudo, tiene un alto coste computacional. Los algoritmos habituales de optimizaci´on de hiperpar´ametros requieren entrenar total o parcialmente el modelo con distintas configuraciones para acabar seleccionando un solo modelo y descartando todos los dem´as [2, 37]. 1.2. OPTIMIZACI ´ ON DE HIPERPAR ´ AMETROS 5 Figura 1.1: Representaci´on gr´afica de la predicci´on de rendimiento. 1.2.1. Predicci´on de rendimiento Diferentes autores han observado que es posible predecir el rendimiento (en t´erminos de p´erdida, precisi´on u otras m´etricas) que tendr´a un modelo de aprendizaje autom´atico tras ser entrenado un cierto n´umero Nde ´epocas con una determinada configuraci´on de hiperpar´ametros [2, 11, 8, 19, 33]. La idea general de la predicci´on de rendimiento es usar un modelo auxiliar que llamaremos predictor de rendimiento que toma como caracter´ısticas informaci´on sobre valores de los hiperpar´ametros y la curva de aprendizaje parcial del modelo objetivo entrenado M´epocas con M < N para predecir el valor que tendr´a de la curva de aprendizaje en la ´epoca N[19, 33], como se muestra en la Figura 1.1. Usar estrategias de predicci´on de rendimiento tiene un gran potencial para acelerar la optimizaci´on de hiperpar´ametros y ahorrar as´ı recursos computacionales [19, 33, 2]. Si dispusi´eramos de un predictor de rendimiento ideal para un un modelo, podr´ıamos entrenar las distintas configuraciones de hiperpar´ametros del modelo unas pocas ´epocas, predecir su rendimiento final y completar el entrenamiento solo para aquella configuraci´on para la que predecimos un mejor rendimiento. Desgraciadamente las cosas no son tan sencillas, ya que un predictor de rendimiento para un modelo es a su vez otro modelo que debe ser entrenado usando curvas de aprendizaje del modelo objetivo [19, 33, 2]. Por esta raz´on, es importante que el predictor de rendimiento sea un modelo relativamente simple y r´apido de entrenar (al menos en comparaci´on con el modelo objetivo) y que no necesite ver un gran n´umero de ejemplos de entrenamiento para poder hacer buenas pre- 6CAP´ ITULO 1. INTRODUCCI ´ ON dicciones [2] ya que, para generar estos ejemplos, es necesario entrenar el modelo objetivo. Por otra parte, ning´un predictor de rendimiento ser´a capaz de predecir de forma exacta el valor final de la curva de aprendizaje [19, 33]. Adem´as, la idea de usar predictores de rendimiento en combinaci´on con HPO es relativamente novedosa, por lo que, aunque existen algoritmos propuestos para integrar el uso de predictores de rendimiento con HPO estos no se encuentran disponibles, al menos en la actualidad, en los principales frameworks de HPO como RayTune [17]. 1.3. Computaci´on cu´antica mediante annealers Los annealers cu´anticos implementan un paradigma de computaci´on cu´antica de prop´osito espec´ıfico diferente de la, m´as conocida, computaci´on cu´antica basada en puertas. En esta secci´on daremos una peque˜na idea o intuici´on sobre los fundamentos y aplicaciones de los annealers cu´anticos sin entrar en demasiados detalles sobre los conceptos f´ısicos que tienen detr´as. Los annealers cu´anticos se basan en el modelo de computaci´on cu´antica adiab´atica y permiten resolver problemas de optimizaci´on que pueden ser planteados como problemas de minimizaci´on de energ´ıa Ising o mediante su formulaci´on equivalente como problemas de optimizaci´on binaria cuadr´atica sin restricciones (QUBO por sus siglas en ingl´es) [27]. La f´ormula general de un problema QUBO se puede ver en la siguiente ecuaci´on: minimizar: afQ(a) = a⊤Qa, (1.1) donde a∈ {0,1}NyQes una matriz triangular superior de dimensi´on N×N. Los problemas Ising (o equivalentemente los problemas QUBO) son problemas de optimizaci´on discreta, tambi´en conocida como optimizaci´on combinatoria [27]. En estos problemas la funci´on a optimizar se define sobre un espacio finito: en los problemas Ising sobre una cadena de -1s y 1s de longitud fija y en los problemas QUBO una cadena de 1s y 0s de longitud fija [27]. Estos problemas son NP duros por lo que cualquier problema en la clase de complejidad NP puede ser representado como un problema de este tipo del tama˜no adecuado [6]. La estrategia de los annealers cu´anticos para resolver estos problemas que pueden ser entendidos como problemas de minimizaci´on de energ´ıa es representar cada una las variables l´ogicas del problema de forma f´ısica usando c´ubits que pueden valer 0, 1 o estar en un estado de superposici´on. Inicialmente, todas las variables del problema comienzan en un estado de superposici´on, a continuaci´on se aplican una serie de perturbaciones que reflejan las relaciones entre las variables 1.4. OBJETIVOS DEL TRABAJO 7 l´ogicas del problema. Mediante estas perturbaciones, el sistema formando por el conjunto de c´ubits evolucionar´a a un estado de m´ınima energ´ıa que representa la soluci´on del problema [6, 27]. Se debe tener en cuenta que el proceso de comenzar en un estado de superposici´on y evolucionar hacia un estado de m´ınima energ´ıa es probabil´ıstico. Por esta raz´on, lo que haremos ser´a repetir este proceso varias veces, que denominaremos ciclos, obteniendo numerosas “soluciones”. De entre todas ellas, la que m´as veces se repita ser´a la que, m´as probablemente, se corresponda con la soluci´on del problema de partida [27] El ordenador cu´antico al que tenemos acceso es un modelo de la empresa D- Wave que tambi´en proporciona un framework para preparar y enviar problemas al ordenador de forma relativamente c´omoda. Simplemente requiere al usuario que env´ıe el problema planteado como un QUBO o un problema Ising y que elija una serie de par´ametros relativos al proceso f´ısico que tiene lugar para resolver el problema, como pueden ser el n´umero ciclos o la duraci´on de los mismos. 1.4. Objetivos del trabajo En el marco del proyecto europeo CoE RAISE y del CERN Openlab hay inter´es en estudiar la integraci´on de t´ecnicas de predicci´on de rendimiento con los procesos optimizaci´on de hiperpar´ametros, y en especial en su aplicabilidad en la optimizaci´on de la red de reconstrucci´on de flujo de part´ıculas MLPF en futuros ciclos de su desarrollo. Cabe destacar que, mediante el uso de t´ecnicas de HPO aplicadas a MLPF se ha conseguido reducir su p´erdida en torno a un 44 % con respecto de la versi´on inicial de la red [36]. Por otra parte, como avanz´abamos anteriormente, mediante CoE RAISE tenemos acceso al annealer cu´antico del J¨ulich Supercomputing Center. Investigadores de este centro de supercomputaci´on han desarrollado regresores que pueden ser entrenados en dicho computador cu´antico. Aline´andonos con el trabajo que algunos de ellos han realizado, o est´an realizando, nos hemos propuesto el objetivo de usar estos regresores cu´anticos para realizar predicci´on de rendimiento, dando lugar a un proceso de optimizaci´on de hiperpar´ametros que integre el uso de recursos cu´anticos. El objetivo principal de este trabajo ser´a estudiar el uso de t´ecnicas de HPO basadas en predicci´on de rendimiento y su idoneidad para una red neuronal dise˜nada para reconstrucci´on de flujo de part´ıculas. Como subobjetivos destacamos: Estudiar la idoneidad del uso de regresi´on de vectores de soporte (SVR por sus siglas en ingl´es) para predecir el rendimiento de MLPF dadas distintas 8CAP´ ITULO 1. INTRODUCCI ´ ON configuraciones de hiperpar´ametros e informaci´on sobre sus curvas parciales de aprendizaje. Hacer uso de un annealer cu´antico para entrenar los modelos de regresi´on por vectores de soporte, realizando las adaptaciones necesarias para poder hacer uso de esta tecnolog´ıa dadas las limitaciones actuales de la misma. Debemos tener en cuenta que no se espera una ventaja en el uso de los regresores cu´anticos frente al uso de regresores cl´asicos. De este modo, la raz´on para querer usar los regresores cu´anticos para hacer HPO es m´as una especie de prueba de concepto, para ver si, a´un a pesar de las limitaciones actuales, es posible integrar con ´exito tecnolog´ıas cu´anticas con HPO. Adem´as, es importante mencionar que ´unicamente disponemos de 3 minutos de tiempo de ejecuci´on al mes el ordenador cu´antico que son compartidos con los dem´as socios del proyecto CoE RAISE. 1.5. Organizaci´on de la memoria Esta memoria se estructura de la siguiente forma: En el Cap´ıtulo 1 se realiza una revisi´on del estado del conocimiento sobre optimizaci´on de hiperpar´ametros y la predicci´on de rendimiento y se introduce matem´aticamente el modelo SVR cu´antico. En el Cap´ıtulo 2 se introducen los materiales m´as relevantes utilizados durante el proyecto. En el Cap´ıtulo 4 se describe la metodolog´ıa seguida durante el proyecto y se introduce el algoritmo Swift-Hyperband, ideado durante la realizaci´on de este trabajo. En el Cap´ıtulo 5 se presentan las pruebas y resultados para los predictores de rendimiento para MLPF y para los algoritmos de HPO junto con un an´alisis de los mismos. Finalmente, en el cap´ıtulo Cap´ıtulo 6 se extraen conclusiones y se proponen l´ıneas de trabajo futuro. Es conveniente mencionar que en esta memoria no se incluye ning´un apartado con una descripci´on t´ecnica de MLPF y sus hiperpar´ametros ni de ninguno de los dem´as modelos utilizados para probar los algoritmos de HPO. As´ı, afrontamos el HPO como un proceso de optimizaci´on de caja negra. Este enfoque es habitual en la literatura de HPO [2, 16, 15, 37]. Adem´as, incluir esta informaci´on se saldr´ıa del alcance del trabajo y supondr´ıa un aumento excesivo del tama˜no de esta memoria. Cap´ıtulo 2 Estado del conocimiento del problema 2.1. Estado del arte de HPO y m´etodos de earlystopping La optimizaci´on de hiperpar´ametros no es un problema exclusivo del aprendizaje profundo, aunque es cierto que, tal y como avanz´abamos en la introducci´on, en los ´ultimos a˜nos el HPO ha cobrado una especial importancia en este ´ambito. A´un as´ı, m´as all´a de las particularidades que pueda haber en la aplicaci´on de HPO en distintos dominios, existen unas bases comunes para todos ellos [37]. De esta forma, en la actualidad, la filosof´ıa general del HPO se puede reducir a los siguientes pasos: 1. Seleccionar los hiperpar´ametros a optimizar y sus rangos, lo que se conoce como espacio de b´usqueda. 2. Seleccionar conjuntos de hiperpar´ametros o configuraciones dentro del espacio de b´usqueda. 3. Evaluar el rendimiento del modelo con diferentes configuraciones. 4. Determinar cu´al es la configuraci´on ´optima El primero de estos pasos no est´a automatizado, por lo que es responsabilidad del investigador o el desarrollador del modelo [37]. En un caso ideal se incluir´ıan en el espacio de b´usqueda todos los hiperpar´ametros del modelo como candidatos a ser optimizados. El problema es que hacer esto, a menudo, resulta en un espacio de b´usqueda de gran dimensionalidad lo que puede dificultar el desarrollo de los siguientes pasos. De esta forma, dependiendo del n´umero de hiperpar´ametros del modelo, puede quedar a criterio del investigador decidir qu´e hiperpar´ametros considera m´as influyentes en el rendimiento del modelo y cu´ales dejar fuera 9 10 CAP´ ITULO 2. ESTADO DEL CONOCIMIENTO DEL PROBLEMA del proceso de HPO. Asimismo, para definir el rango de cada uno de los hiperpar´ametros es necesario una vez m´as confiar en la experiencia previa o recurrir a la literatura sobre modelos similares. Una vez que el dise˜nador del modelo ha realizado el primer paso comienza la parte autom´atica, formada por los 3 siguientes pasos del HPO. En los m´etodos actuales de HPO es habitual que los pasos 2 y 3 interact´uen entre s´ı de forma iterativa, de forma que el paso 2 genera configuraciones que “merece la pena probar” de acuerdo con alg´un modelo matem´atico, el paso 3 eval´ua dichas configuraciones y en base al resultado de esta evaluaci´on el paso 2 ajusta su modelo y vuelve a generar nuevas configuraciones para que eval´ue el paso 3 y as´ı sucesivamente [9]. El ´ultimo paso simplemente consiste en elegir la configuraci´on que, una vez entrenada, haya tenido una menor p´erdida o mayor precisi´on (dependiendo de la m´etrica de evaluaci´on) de entre todas las que se han evaluado en el paso 3. De esta forma, los algoritmos del estado del arte para HPO se pueden clasificar en dos categor´ıas: algoritmos de b´usqueda (se ocupan del paso 2) y algoritmos de evaluaci´on (se ocupan del paso 3) [37, 9]. Como avanzamos en la introducci´on, nuestro trabajo se centra en el uso de t´ecnicas de predicci´on de rendimiento para HPO. El potencial de estas t´ecnicas se encuentra en acelerar los algoritmos de la fase de evaluaci´on. Por lo tanto, nos centraremos m´as en hablar del estado del arte para esta fase que principalmente se basa en lo que se conoce como earlystopping [9, 15, 16]. En relaci´on a los algoritmos de b´usqueda, presentamos a continuaci´on un breve repaso sobre las tres principales estrategias y sus ventajas e inconvenientes: B´usqueda de rejilla ogrid search: el usuario selecciona un conjunto de valores dentro del rango de cada hiperpar´ametro, siendo el conjunto de configuraciones a evaluar el producto cartesiano de los conjuntos de partida. Su principal ventaja es que todas las configuraciones a evaluar se generan a la vez por lo que pueden ser evaluadas en paralelo. Sus desventajas son que el n´umero de configuraciones a evaluar aumenta exponencialmente al aumentar el n´umero de hiperpar´ametros a optimizar, o el n´umero de posibles valores para cada uno de ellos, y que puede ser ineficiente cuando existen relaciones ocultas entre los hiperpar´ametros o no todos tienen la misma influencia sobre el rendimiento del modelo objetivo [37, 20]. B´usqueda aleatoria: para generar las configuraciones a evaluar, se seleccionan valores dentro del rango de cada hiperpar´ametro siguiendo una distribuci´on de probabilidad que suele ser uniforme o uniforme logar´ıtmica. Su principales ventajas son que las configuraciones pueden ser evaluadas en paralelo, siempre se pueden generar nuevas configuraciones y que no se basa en ninguna suposici´on sobre el espacio de los hiperpar´ametros. Su 2.1. ESTADO DEL ARTE DE HPO Y M ´ ETODOS DE EARLY-STOPPING11 principal desventaja es que puede ser ineficiente debido a esta ausencia de suposiciones [37]. B´usqueda bayesiana: se utiliza alg´un modelo matem´atico de optimizaci´on bayesiana que genere configuraciones prometedoras en base a las configuraciones ya evaluadas. Su principales ventajas son que siempre se pueden generar nuevas configuraciones y que, si las suposiciones del modelo matem´atico son correctas, es m´as eficiente que la b´usqueda aleatoria. Su principal desventaja es la falta de paralelismo debido a que el modelo matem´atico debe conocer la evaluaci´on de una configuraci´on antes de generar la siguiente [37, 9]. 2.1.1. Early-stopping Como mencion´abamos en la introducci´on, la optimizaci´on de hiperpar´ametros es un proceso de gran coste computacional ya que evaluar con exactitud una configuraci´on requiere entrenar el modelo objetivo con dicha configuraci´on. Si el entrenamiento de una red neuronal profunda fuese inmediato no se necesitar´ıan algoritmos de evaluaci´on, ya que ser´ıa razonable entrenar cada configuraci´on y calcular su p´erdida o precisi´on una vez completado el entrenamiento. Pero esto no es as´ı, de hecho, entrenar redes neuronales para aprendizaje profundo es un proceso que requiere un gran poder computacional, sobre todo cuando se trabaja con arquitecturas complejas. Los algoritmos de early-stopping como Succesive Halving [13], Hyperband [15] o ASHA [16], nacen para aliviar este problema y reducir el n´umero de recursos computacionales necesarios para evaluar las configuraciones. La idea com´un detr´as de todos los m´etodos de early-stopping es entrenar las configuraciones a evaluar por un cierto n´umero de ´epocas Nmenor que el n´umero de ´epocas objetivo, descartar un tanto por ciento de las configuraciones menos prometedoras en la ´epoca N(aquellas con peor p´erdida o precisi´on tras haber sido entrenadas N´epocas) y continuar entrenando las configuraciones prometedoras hasta alcanzar otro punto de decisi´on en el que, de nuevo, se descartar´an una serie de configuraciones. Este proceso se repite hasta que solo queda una o unas pocas configuraciones que son entrenadas hasta la ´epoca objetivo. La idea de este proceso se ilustra en la Figura 2.1 Los algoritmos de early-stopping constituyen actualmente el estado del arte para HPO de redes neuronales profundas ya que han demostrado emp´ıricamente [9, 37, 16] (o incluso en un marco te´orico en el caso de Hyperband [15]) su capacidad para ahorrar recursos en los procesos de HPO sin perder la facultad de encontrar buenas configuraciones. En las propuestas originales de los algoritmos de early-stopping las configuraciones a evaluar son elegidas de for- 12 CAP´ ITULO 2. ESTADO DEL CONOCIMIENTO DEL PROBLEMA Figura 2.1: Representaci´on de la idea general de los m´etodos de early-stopping. ma aleatoria [15, 16] aunque esto no tiene por que hacerse as´ı, de hecho, es relativamente sencillo integrar estos algoritmos de evaluaci´on con algoritmos de b´usqueda bayesianos, como ocurre, por ejemplo, con el algoritmo BOHB [9] (Bayesian Optimization over Hyperband) que integra Hyperband con un generador de configuraciones que sigue una estrategia de b´usqueda bayesiana. Asimismo, el framework de optimizaci´on de hiperpar´ametros RayTune permite al usuario combinar diferentes estrategias de b´usqueda con los algoritmos de evaluaci´on que implementa como ASHA o Hyperband. Una de las principales desventajas de los m´etodos de early-stopping es que pueden llegar a descartar de forma temprana configuraciones que acabar´ıan siendo buenas si hubieran completado su entrenamiento. No existe una garant´ıa de que las curvas de aprendizaje de dos configuraciones no puedan llegar a cruzarse en una ´epoca m´as avanzada que la que se us´o para tomar la decisi´on de descartar una de ellas. Sin embargo, este problema no resulta tan grave en la pr´actica, en parte porque queda mitigado por el gran n´umero de configuraciones que se pueden evaluar al usar una estrategia de early-stopping en comparaci´on con el n´umero de configuraciones que se podr´ıan evaluar con los mismos recursos si se requiriese que todas las configuraciones fuesen entrenadas hasta la ´ultima ´epoca [15]. Hyperband A continuaci´on, describiremos con algo m´as de detalle el algoritmo de earlystopping Hyperband, ya que, no solo es uno de los algoritmos m´as conocidos, si no que, adem´as, existe una integraci´on de Hyperband con predictores de rendimiento de la que hablaremos m´as adelante. 2.1. ESTADO DEL ARTE DE HPO Y M ´ ETODOS DE EARLY-STOPPING13 El algoritmo Hyperband se construye sobre el algoritmo de HPO conocido como Succesive Halving [13]. Succesive Halving es un algoritmo de early-stopping b´asico que consiste en entrenar un conjunto de configuraciones un cierto n´umero de ´epocas, descartar la mitad con peor rendimiento y repetir el proceso hasta que solo quede una configuraci´on. El algoritmo Succesive Halving toma como entrada el n´umero nde configuraciones iniciales, De esta forma , si nes grande, el algoritmo evaluar´a un mayor n´umero de configuraciones pero ser´a m´as agresivo en el sentido de que se a˜nadir´an m´as puntos de decisi´on en los que se descartan configuraciones. Por otra parte, al usar un npeque˜no se evaluar´an menos configuraciones pero el algoritmo ser´a menos agresivo, en el sentido de que habr´a menos puntos de decisi´on en los que se descartan configuraciones. As´ı, Succesive Halving requiere que el usuario tome una decisi´on con respecto al equilibrio que debe haber entre evaluar m´as configuraciones y que el algoritmo no sea demasiado agresivo. Para solucionar este problema, Hyperband genera de forma autom´atica diferentes valores de n, cada uno de ellos con un valor m´ınimo de ´epocas rque se usar´a para entrenar cada una de las nconfiguraciones antes de alcanzar el primer punto de decisi´on. De este modo, los valores de ngrandes se corresponden con un valor de rpeque˜no y exploran m´as configuraciones pero de forma m´as agresiva. Asimismo, para los valores de npeque˜nos el valor de rser´a mayor por lo que la evaluaci´on ser´a menos agresiva pero se explorar´an menos configuraciones. Por lo tanto, Hyperband no es m´as que la ejecuci´on sucesiva de Succesive Halving para distintos valores de n[15]. Cada vez que se ejecuta Succesive Halving de forma completa dentro de Hyperband se denomina un bracket y cada uno de los intervalos de entrenamiento entre dos puntos de decisi´on de un bracket se denominan una ronda. En el algoritmo 1 se muestra el pseudoc´odigo de Hyperband. Hyperband tiene dos par´ametros: Rque es el n´umero m´aximo de ´epocas que puede ser entrenada cualquiera de las configuraciones a evaluar y ηque controla la proporci´on de configuraciones que se descarta en cada ronda de Succesive Halving. El n´umero de configuraciones que pasan a la siguiente ronda es 1/η veces el n´umero de configuraciones en la ronda actual, de modo que cu´anto mayor sea ηmenos configuraciones pasan a la siguiente ronda. El algoritmo Hyperband requiere los siguientes m´etodos auxiliares: get n configurations(n): devuelve nconfiguraciones de hiperpar´ametros distintas obtenidas de un espacio de b´usqueda definido previamente. En la propuesta original del algoritmo las configuraciones son generadas aleatoriamente [15]. 20 CAP´ ITULO 2. ESTADO DEL CONOCIMIENTO DEL PROBLEMA los αny los ˆαnes PK−1 k=0 Bk−k0≤C. A˜nadiendo los t´erminos de penalizaci´on y la codificaci´on de los αˆαusando variables binarias el problema 2.7 se puede reescribir como: minimizar: a N−1 X n,m K−1 X i,j=0 1 X s,t=0 aK(sN+n)+i˜ QK(sN+n)+i,K(tN+m+j)aK(tN+m)+j(2.14) Donde ˜ Qes una matriz 2KN ×2KN cuyos elementos vienen dados por la siguiente f´ormula: ˜ QK(sN+n)+i,K(tN+m+j)=(−1)(1−δst )Bi+j−2k0(1 2k(xn, xm) + ξ)+ +δnmδijBi−k0δst(ϵ+ (−1)(1−s)(1−t)yn) (2.15) Donde δes la delta de Kronecker, esto es, δij = 1 si i=jyδij=0 si i=j[21]. Para expresar el problema 2.14 con la formulaci´on can´onica de un problema QUBO 2.12 se construye la matriz de pesos Qde la siguiente forma: Qij =     ˜ Qij +˜ Qji si i<j ˜ Qij si i=j 0 si i>j (2.16) Para entrenar una SVR en un annealer cu´antico de D-Wave, es necesario construir la matriz Qusando los datos de entrenamiento de la forma descrita por las ecuaciones anteriores y usar el software que proporciona la propia empresa para enviar el QUBO al ordenador cu´antico. Tal y como mencionamos en la introducci´on, resolver un problema en un annealer cu´antico es un proceso estoc´astico por lo que la forma de proceder es repetir el proceso de resoluci´on numerosas veces obteniendo m´ultiples resultados. Es por esto que Pasetto et al. proponen 6 formas diferentes de combinar las m´ultiples soluciones del QUBO proporcionadas por el computador cu´antico. De esta forma, al entrenar una SVR en el ordenador cu´antico generan 6 formas diferentes de hacer predicciones que difieren ligeramente entre s´ı, pero no identifican cual de las estrategias de combinaci´on es la m´as efectiva. Por ´ultimo, cabe mencionar que, siendo Nel n´umero de ejemplos de entrenamiento, entrenar una SVR cl´asica tiene un orden de complejidad temporal O(N3) [12, 6], mientras que generar el problema QUBO y entrenar la Q-SVR en el ordenador cu´antico tiene un orden de complejidad O(N) [6], asumiendo que se toma un valor de Kfijado. Cap´ıtulo 3 Materiales En este cap´ıtulo explicaremos los distintos recursos: hardware, conjuntos de datos y librer´ıas de software, utilizados para el desarrollo del trabajo. 3.1. Recursos Hardware Como ya se mencion´o en secciones anteriores, el ordenador cu´antico usado en este trabajo es un annelar cu´antico situado en el J¨ulich Supercomputing Center y producido por la empresa D-Wave. M´as concretamente, se trata del modelo Advantage System 5.3 [28] que cuenta con 5615 c´ubits conectados entre s´ı siguiendo la topolog´ıa Pegasus [7]. Usando exclusivamente computaci´on cu´antica, este computador permite resolver problemas QUBO con hasta 120 variables sin necesidad de aplicar ninguna restricci´on sobre los valores de la matriz de pesos Q(m´as all´a de que sea triangular superior). Mediante el proyecto CoE RAISE disponemos de 3 minutos mensuales de tiempo de computaci´on en el ordenador cu´antico a repartir entre todos los miembros del proyecto. Adicionalmente, mediante el CERN Openlab tenemos acceso al cl´uster de computaci´on Rusty del Flatiron Instute que cuenta con los nodos de computaci´on que se pueden ver en el Cuadro 3.1. 3.2. Conjuntos de datos de curvas de aprendizaje Para evaluar la capacidad de los predictores para predecir el rendimiento de MLPF disponemos de un conjunto de datos con curvas de aprendizaje de MLPF. M´as concretamente, el conjunto de datos est´a formado por 297 configuraciones de hiperpar´ametros distintas de MLPF junto con sus p´erdidas de validaci´on hasta la ´epoca 100. Las 297 configuraciones de hiperpar´ametros fueron generadas alea- 21 22 CAP´ ITULO 3. MATERIALES #Nodos CPU #Cores Memoria GPU Red 216 icelake 64 1 TB no n/a 640 rome 128 1 TB no InfiniBand 300 skylake 40 768 GB no OmniPath 18 icelake 64 1 TB 8x Nvidia H100- 80GB InfiniBand 36 icelake 64 1 TB 4x Nvidia A100- 80GB InfiniBand 36 icelake 64 1 TB 4x Nvidia A100- 40GB InfiniBand 22 skylake 36 768 GB 4x Nvidia V100- 32GB n/a 5 skylake 36 384 GB 2x Nvidia V100- 16GB n/a 4cascadelake, cooperlake 96-192 3-6 TB no n/a Cuadro 3.1: Nodos de computaci´on en el cl´uster de computaci´on Rusty. toriamente a partir del espacio de b´usqueda de 7 hiperpar´ametros (incluyendo la tasa de aprendizaje, el n´umero de capas de distintos tipos o el dropout, entre otros) y entrenadas en el conjunto de datos Delphes, que es un conjunto de datos generado mediante la simulaci´on de colisiones de protones en el detector CMS. Disponer de conjuntos de datos con curvas de aprendizaje resulta ´util para poder evaluar algoritmos de optimizaci´on de hiperpar´ametros sin necesidad de entrenar la red neuronal objetivo. Se puede simular la ejecuci´on de un algoritmo de HPO seleccionando configuraciones que se encuentren en el conjunto de datos en lugar de gener´andolas aleatoriamente. De esta forma, en vez de tener que entrenar las distintas configuraciones basta con leer su p´erdida o precisi´on registrada en el conjunto de datos para cada ´epoca. Con este prop´osito usaremos otros conjuntos de datos con curvas de aprendizaje adem´as del de MLPF. El primero de estos conjuntos de datos adicionales contiene curvas de aprendizaje de una red neuronal convolucional (CNN) para clasificaci´on de im´agenes similar a la que usan Li et al. [16] para probar el algoritmo de optimizaci´on de hiperpar´ametros ASHA. Este conjunto de datos fue generado por investigadores del J¨ulich Supercomputing Center y consta de 168 configuraciones junto con la precisi´on de validaci´on de cada una de ellas hasta la ´epoca 100. Las configuraciones fueron generadas aleatoriamente a partir de un espacio de b´usqueda de 5 hiperpar´ametros y entrenadas en el conjunto de datos de im´agenes CIFAR-10. 3.3. LIBRER´ IAS 23 Tambi´en disponemos de un segundo conjunto de datos con curvas de aprendizaje para otra CNN para clasificaci´on de im´agenes. Este conjunto de datos, que est´a disponible en la plataforma github1, ha sido generado por Baker et al. quienes lo usan para simular la ejecuci´on de su algoritmo Fast-Hyperband. El conjunto de datos consta de 16583 configuraciones junto con la precisi´on de validaci´on de cada una de ellas en cada ´epoca de entrenamiento. Las configuraciones fueron generadas aleatoriamente a partir de un espacio de b´usqueda de 9 hiperpar´ametros y entrenadas en el conjunto de datos de im´agenes SVHN. Finalmente, disponemos de un conjunto de datos con curvas de aprendizaje para una red neuronal recurrente (LSTM) para procesamiento de lenguaje natural. Este conjunto de datos, que est´a disponible en la plataforma github2, tambi´en ha sido generado por Baker et al. quienes lo usan para mostrar que las SVR son un buen predictor de rendimiento para esta red neuronal. El conjunto de datos consta de 281 configuraciones junto con su correspondiente perplexity de validaci´on hasta la ´epoca 59. Las configuraciones fueron generadas aleatoriamente a partir del espacio un espacio de b´usqueda con 2 hiperpar´ametros entrenadas en el conjunto de datos de frases en ingl´es Penn Treebank (PTB). 3.3. Librer´ıas Python es lenguaje de programaci´on usado en este trabajo, tanto para trabajar con los predictores de rendimiento como para implementar y probar los algoritmos de HPO. La elecci´on de este lenguaje atiende a diversas razones. Por una parte, trabajar con Python aporta m´as versatilidad que otros lenguajes, ya que nos permite tanto programar scripts como trabajar de forma interactiva mediante el uso de Jupyter Notebooks. Adem´as, Python es un lenguaje muy popular en la actualidad, especialmente en el mundo del aprendizaje autom´atico, por lo que trabajar en Python nos permite acceder a multitud de librer´ıas f´aciles de instalar y bien documentadas. Por otra parte, la red de reconstrucci´on de flujo de part´ıculas MLPF est´a implementada en Python, por lo que trabajar en este lenguaje facilita que, en el futuro, se puedan integrar los algoritmos que implementemos con MLPF para optimizar sus hiperpar´ametros. Finalmente, es importante mencionar que disponemos de una implementaci´on en Python del modelo Q-SVR desarrollado por investigadores del J¨ulich Supercomputing Center. A continuaci´on, se comentan brevemente las librer´ıas de Python m´as relevantes para este trabajo. 1https://github.com/nikdnaik/accelerating_nas-1/blob/master/data/cudaconvne t_svhn.csv 2https://github.com/nikdnaik/accelerating_nas-1/blob/master/data/lstm_ptb.c sv 24 CAP´ ITULO 3. MATERIALES scikit-learn La librer´ıa scikit-learn [24] implementa una gran variedad de modelos de clasificaci´on, regresi´on y cl´ustering en Python. Adem´as, proporciona herramientas para llevar a cabo preprocesado de datos y evaluaci´on de modelos. En este trabajo utilizamos la implementaci´on de SVR cl´asica disponible en esta librer´ıa, concretamente mediante la clase NuSVR. Adem´as, trabajamos con las herramientas que proporciona esta librer´ıa para dividir los datos en particiones de entrenamiento y test, escalar los datos y evaluar el rendimiento de las SVR. Ocean Ocean es el software que la empresa D-Wave proporciona para resolver problemas en los ordenadores cu´anticos que fabrica. Este software permite enviar problemas QUBO a un ordenador cu´antico y recibir las m´ultiples respuestas al problema generadas por el ordenador. A la hora de enviar un problema, la librer´ıa permite especificar diversos par´ametros relativos al proceso cu´antico de resoluci´on como el n´umero ciclos, la duraci´on de los ciclos o con que fuerza se deben emparejar los c´ubits que representan la misma variable l´ogica. Adem´as, la librer´ıa proporciona una herramienta para simular el proceso de resoluci´on cu´antico en el ordenador del usuario. mpi4py El paquete mpi4py (MPI for Python) proporciona las funcionalidades necesarias para utilizar la Interfaz de Paso de Mensajes (MPI, por sus siglas en ingl´es) en programas escritos en Python. De este modo, mpi4py permite desarrollar aplicaciones distribuidas en Python que aprovechen la capacidad de procesamiento de m´ultiples nodos en un cl´uster de computaci´on. En nuestro trabajo utilizaremos mpi4py para implementar la versi´on distribuida del algoritmo de HPO que hemos dise˜nado. TensorFlow TensorFlow es una librer´ıa de Python desarrollada por Google para realizar c´alculos num´ericos y construir modelos de aprendizaje autom´atico. En la actualidad, es una herramienta muy popular para desarrollar, entrenar y desplegar redes neuronales profundas ya que permite trabajar en diferentes entornos (desde port´atiles hasta cl´usters de computaci´on) y hacer uso de aceleraci´on mediante GPU. Actualmente, la red MLPF est´a implementa en TensorFlow. Nosotros usaremos TensorFlow para implementar una red neuronal sencilla que nos permitir´a probar los algoritmos de HPO m´as all´a de las ejecuciones simuladas. Cap´ıtulo 4 Metodolog´ıa En este cap´ıtulo explicaremos la metodolog´ıa seguida durante el desarrollo del trabajo. Las secciones del cap´ıtulo reflejan el orden temporal en el que se desarrollaron las diferentes etapas del trabajo, de este modo, comenzamos con un fase de estudio preliminar en la que se analiz´o la idoneidad del uso de SVRs y Q-SVRs para predicci´on de rendimiento de MLPF. Una vez completada esta etapa, pasamos a integrar los predictores de rendimiento con HPO, inicialmente, mediante el algoritmo Fast-Hyperband y, por ´ultimo, mediante un nuevo algoritmo, al que denominamos Swift-Hyperband que fue ideado durante el desarrollo de este trabajo. M´as concretamente, la metodolog´ıa se ha organizada como se indica a continuaci´on: Estudio preliminar. •Predicci´on de rendimiento de MLPF con SVRs. •Predicci´on de rendimiento de MLPF con Q-SVRs. Integraci´on de los predictores con HPO. •Fast-Hyperband •Swift-Hyperband 4.1. Estudio Preliminar Comenzaremos esta secci´on describiendo la metodolog´ıa utilizada para comprobar la idoneidad del uso de SVRs para predecir el rendimiento de MLPF, basada, principalmente, en la metodolog´ıa seguida por Baker et al. [2]. Despu´es, explicaremos la metodolog´ıa seguida a la hora de utilizar Q-SVRs para predecir el rendimiento de MLPF haciendo hincapi´e en las dificultades afrontadas durante este proceso. 25 26 CAP´ ITULO 4. METODOLOG´ IA 4.1.1. Predicci´on de rendimiento de MLPF con SVRs Comenzamos comprobando si las SVRs pueden ser usadas para predecir la p´erdida de MLPF obteniendo valores de R2similares a los que alcanzan Baker et al. para las arquitecturas estudiadas en su trabajo. Para esto trabajamos con la clase NuSVR de scikit-learn usando el kernel RBF. Esta clase implementa el modelo ν-SVR que es un modelo de regresi´on equivalente al de las SVR aunque con una formulaci´on matem´atica ligeramente distinta [3]. El uso de ν-SVRs con el kernel RBF se debe a que este es el modelo que tuvo mayor capacidad de predicci´on en los experimentos realizados por Baker et al. De esta forma, replicamos la forma de proceder de Baker et al. usando ν- SVRs para predecir la p´erdida de una configuraci´on de MLPF tras la ´epoca de entrenamiento 100 y tomando como caracter´ısticas un vector formado por la concatenaci´on de los valores de los hiperpar´ametros de la configuraci´on concatenados con la curva de aprendizaje parcial y las diferencias de primer y segundo orden. Adem´as, probaremos que ocurre al usar vectores de caracter´ısticas formados ´unicamente por la curva de aprendizaje parcial, sin incluir informaci´on relativa a los valores de los hiperpar´ametros. Probar esto resulta interesante, ya que abre la puerta a usar este m´etodo para optimizar tambi´en hiperpar´ametros categ´oricos que, de primeras, no podr´ıan incluirse en el vector de caracter´ısticas. Para evaluar las SVRs, en lugar de disponer de un ´unico conjunto de entrenamiento y otro de test, seguimos el mismo procedimiento que Baker et al. o Pasetto et al. que consiste en generar Npares de particiones de entrenamiento y test distintos y, para cada uno de estos pares, entrenar una SVR y calcular su R2en el conjunto de test. De esta manera, reportamos el R2de test medio para todos los pares. Proceder de esta forma nos permite dar una medida final del R2m´as robusta, en el sentido de que es menos dependiente de una partici´on de entrenamiento/test concreta. Igual que Baker et al., repetimos la forma de proceder descrita en el p´arrafo anterior utilizando distintos valores para la fracci´on conocida de la curva. Esto nos permitir´a ver por cuantas ´epocas es necesario entrenar MLPF con una determinada configuraci´on para poder realizar una buena predicci´on de su rendimiento. Por ´ultimo, conviene mencionar que antes de entrenar cada SVR escalamos los datos para que todas las caracter´ısticas se tomen valores entre 0 y 1, ya que est´a estudiado que, en general, esto hace que las SVRs puedan hacer predicciones m´as precisas [18]. 4.1. ESTUDIO PRELIMINAR 27 4.1.2. Predicci´on de rendimiento de MLPF con Q-SVRs Una vez estudiada la capacidad de las SVR cl´asicas para predecir el rendimiento de MLPF, pasamos a trabajar con las Q-SVR. Para esto, haremos uso de la implementaci´on en Python del modelo de Q-SVR que hemos descrito en el cap´ıtulo 2. Como ya hemos avanzado, esta implementaci´on fue desarrollada por investigadores del J¨ulich Supercomputing Center y adaptada ligeramente durante la realizaci´on de este trabajo para poder realizar el proceso de entrenamiento de forma simulada sin necesidad de conectarse al ordenador cu´antico. Para estudiar el uso de Q-SVRs como predictores de rendimiento, usaremos como valor objetivo la p´erdida de MLPF en la ´epoca 100. Sin embargo, en lugar de variar la fracci´on conocida de la curva, nos limitaremos a usar un valor fijo de fracci´on conocida de la curva, establecido en 0,25. Es decir, utilizaremos la p´erdida de cada configuraci´on desde la ´epoca inicial hasta la ´epoca 25 como caracter´ısticas para predecir la p´erdida de MLPF en la ´epoca 100. Esto se debe a que, al disponer de un tiempo de ejecuci´on limitado en el ordenador cu´antico, no tenemos la capacidad de realizar pruebas para distintos valores de la fracci´on conocida de la curva, como se hizo para las SVRs cl´asicas. Elegimos 0,25 como fracci´on conocida de la curva porque Baker et al., tambi´en centran su an´alisis en este valor, ya que es el menor valor de fracci´on conocida de la curva para el cual obtienen valores de R2por encima de 0.8 en la predicci´on del rendimiento de todas las arquitecturas que estudian. A la hora de trabajar con las Q-SVRs, nos encontramos con una serie de dificultades relacionadas tanto con el uso del computador cu´antico y el estado actual de estas tecnolog´ıas, como con la conversi´on del modelo SVR a una formulaci´on QUBO. A continuaci´on, exponemos las dificultades m´as relevantes: Tama˜no del problema Como indicamos en la secci´on 3.1, el ordenador al que tenemos acceso puede resolver problemas con hasta 120 variables binarias. Por otra parte, en la secci´on 2.3 explicamos que la formulaci´on de la SVR como un QUBO tiene 2KN variables binarias, donde K > 1 es el n´umero de variables binarias usado para representar cada variable continua αi, y Nes el n´umero de ejemplos usados en el entrenamiento. Por lo tanto, existe un compromiso entre el n´umero de ejemplos que se pueden usar en el entrenamiento de la Q-SVR y la precisi´on con la que se representan los αi. De este modo, a´un tomando un valor de K= 3, igual que en [34], lo que permite que las αipuedan tomar 8 = 2Kvalores distintos, no podremos usar m´as de 20 ejemplos en el entrenamiento de las Q-SVR, ya que 120 = 2·3·20. Inestabilidad en los resultados A la hora de realizar las primeras ejecuciones del proceso de entrenamiento 28 CAP´ ITULO 4. METODOLOG´ IA Par´ametro Descripci´on SVR ϵDistancia permitida entre un valor y su predicci´on sin acarrear penalizaci´on. γValor para el kernel RBF. CFuerza de la penalizaci´on por los errores de la regresi´on. QUBO KN´umero de variables binarias usadas para codificar cada variable continua. BBase para la codificaci´on de las variables continuas usando variables binarias. k0Exponente negativo en la codificaci´on de las variables continuas usando variables binarias. ξFuerza del t´ermino de penalizaci´on para forzar el cumplimiento de las restricciones. Cu´antico anneal time Duration de cada ciclo del proceso cu´antico de generaci´on de soluciones. num reads N´umero de ciclos de generaci´on de soluciones. chain mult Fuerza de emparejamiento entre los c´ubits que representan la misma variable del QUBO. Cuadro 4.1: Hiperpar´ametros del modelo Q-SVR y su origen. de las Q-SVRs en el ordenador cu´antico, observamos una gran inestabilidad en el R2del test, tanto al usar distintos pares de conjuntos de entrenamiento/test, lo que puede ser razonable debido a la limitaci´on del tama˜no del conjunto de entrenamiento a 20 ejemplos, como al repetir el entrenamiento sin cambiar los conjuntos de entrenamiento y test, lo que podr´ıa indicar que el proceso de resoluci´on cu´antico no se est´a realizando correctamente. Esto puede deberse, por ejemplo, a que no se est´an realizando suficientes ciclos de soluci´on del problema o porque la duraci´on de los ciclos es demasiado corta como para que el sistema tenga tiempo suficiente para evolucionar a un estado de m´ınima energ´ıa [25]. Debemos a˜nadir que, a la hora de realizar experimentos en el ordenador cu´antico, hay un problema de reproducibilidad, ya que no se puede controlar la aleatoriedad presente en el proceso f´ısico de resoluci´on fijando una “semilla” como se suele hacer para poder reproducir los procesos (pseudo)aleatorios que ocurren en un ordenador cl´asico. Multitud de hiperpar´ametros en las Q-SVR Trabajar con las Q-SVR hace que un modelo relativamente sencillo como la SVR cl´asica (ecuaci´on 2.2) se convierta en un modelo mucho m´as complejo. Por un lado, las SVRs cl´asicas ´unicamente requieren que el usuario seleccione valores para C,ϵy el par´ametro γdel kernel RBF. Adem´as, este modelo ha sido ampliamente estudiado por lo que la librer´ıa scikit-learn hace una buena elecci´on de valores “por defecto”para estos hiperpar´ametros. Por otro lado, en las Q-SVR se a˜naden nuevos par´ametros que deben ser seleccionados por el usuario, algunos de ellos relativos a la “traducci´on” de la formulaci´on cl´asica a un problema QUBO (para los que no disponemos de valores “por defecto”) y otros de ellos relativos al proceso de resoluci´on cu´antico. El Cuadro 4.1 muestra los hiperpar´ametros del modelo Q-SVR junto con una breve explicaci´on sobre cada uno de ellos. Enfrentarse a los problemas que acabamos de describir ha supuesto un desaf´ıo considerable. En primer lugar, existe una falta de literatura extensa que examine detalladamente el modelo de las Q-SVR. Por otra parte, el tiempo restringido de 4.1. ESTUDIO PRELIMINAR 29 uso del ordenador cu´antico para este proyecto supone una limitaci´on importante, ya que nos ha impedido llevar a cabo pruebas m´as numerosas del modelo y poder hacer un an´alisis emp´ırico m´as exhaustivo. A continuaci´on se explica como se ha lidiado con estas limitaciones. En relaci´on al n´umero reducido de ejemplos que pueden ser usados en el entrenamiento no hay nada que se pueda hacer para poder usar una cantidad mayor, ya que esta limitaci´on es consecuencia del tama˜no de problema m´aximo que puede resolver el ordenador de D-Wave al que tenemos acceso. A´un as´ı, lo que podemos hacer es entrenar SVR cl´asicas con 20 ejemplos para evaluar como de problem´atico es reducir el n´umero de ejemplos de entrenamiento, al margen de las dem´as limitaciones. Por otra parte, para encontrar una buena configuraci´on para las Q-SVR no podemos realizar un proceso de optimizaci´on de hiperpar´ametros debido a la restricci´on sobre el tiempo de uso del computador cu´antico. As´ı, la estrategia empleada para la selecci´on de valores para los hiperpar´ametros relacionados con la formulaci´on original de la SVR consisti´o en usar valores que sean apropiados para las SVR cl´asicas de scikit-learn entrenadas con 20 ejemplos, de forma similar al modo de proceder de Pasetto et al. En relaci´on a los hiperpar´ametros relacionados con el problema QUBO, seleccionamos valores propuestos en la literatura [34, 5] y observamos si funcionan bien en la Q-SVR simulada para no consumir tiempo de computaci´on en el ordenador cu´antico. Por ´ultimo, para los hiperpar´ametros relacionados con el proceso cu´antico, Willsch et al. [35] muestran como, en diferentes problemas, aumentar el n´umero de ciclos y la duraci´on de los mismos posibilita que el ordenador cu´antico encuentre mejores soluciones. Sin embargo, aumentar estos valores hace que incremente el tiempo de computaci´on cu´antica necesario para resolver el problema [25] lo que va en contra de nuestra restricci´on en cuanto al tiempo de ejecuci´on. Por este motivo decidimos utilizar los valores por defecto que proporciona el software de D-Wave para estos par´amatros. Adem´as, hay un tercer hiperpar´ametro relacionado con el proceso cu´antico, chain mult, que no afecta a la duraci´on del proceso de resoluci´on, sino a la “fuerza” con la que se emparejan dos c´ubits f´ısicos que representen la misma variable l´ogica. Si el valor seleccionado es demasiado bajo puede ocurrir que c´ubits que representan la misma variable l´ogica acaben tomando valores distintos lo que corrompe la soluci´on del problema. Asimismo, si el valor seleccionado es demasiado alto el proceso cu´antico favorecer´a el hecho de que los c´ubits se mantengan emparejados frente a las relaciones entre c´ubits que representan el problema a resolver, lo que resultar´a en una resoluci´on err´onea del mismo [26]. 36 CAP´ ITULO 4. METODOLOG´ IA Algoritmo 3: Rutina run then return val loss para Swift-Hyperband 2 Entrada: T, rprev, ri, nnext, d, k, D, M, new dp Inicializaci´on: L= List(), fully trained = 0, ep =rprev +⌈(ri−rprev)new dp⌉,thres = 0 for t∈Tdo l= List() for i∈ {0, .., new dp −1}do li= loss of t at epoch i(t, i) l.append(li) end if fully trained < k ·nnext or D[ri].length < d then for i∈ {new dp, .., ri}do li= loss of t at epoch i(t, i) l.append(li) end L.append(li) fully trained =fully trained + 1 D[ri].append(l) thres =L.get quantile(0,25) /* Alternativamente: thres =D[ri].get quantile(0,25) */ else if new dp /∈M[ri].keys then /* Modelo para predecir en riusando la curva hasta new dp */ M[ri][new dp] = Predictor() M[ri][new dp].train(D[ri][ : ,0 : new dp], D[ri][ : , ri]) end pred =M[ri][new dp].predict(l) if pred < thres then for i∈ {new dp, .., ri}do li= loss of t at epoch i(t, i) l.append(li) end L.append(li) fully trained =fully trained + 1 D[ri].append(l) else /* predicci´on m´as un valor muy alto para asegurar que no es menor que ninguna p´erdida real */ L.append(pred + 99999) end end end Salida: L(Lista con la p´erdida final para cada configuraci´on de T) Cap´ıtulo 5 Pruebas y discusi´on de resultados En este cap´ıtulo comenzaremos reportando y analizando los resultados del estudio preliminar sobre el uso de SVRs y Q-SVRs para predecir el rendimiento de MLPF, para pasar despu´es a presentar las pruebas realizadas para evaluar los algoritmos Fast-Hyperband y Swift-Hyperband, junto con los resultados analizados de dichas pruebas. Finalmente, incluimos una secci´on en la que se muestran los par´ametros utilizados para las SVRs, Q-SVRs y los algoritmos de HPO a la hora de generar los resultados mostrados en el cap´ıtulo. 5.1. Predicci´on de rendimiento de MLPF 5.1.1. Resultados con SVRs cl´asicas En la Figura 5.1 se muestran los resultados obtenidos mediante el uso de SVR cl´asicas para la predicci´on de la p´erdida de MLPF en la ´epoca de entrenamiento 100 usando el 20 % de los ejemplos del conjunto de datos de curvas de aprendizaje de MLPF para entrenar los predictores de rendimiento. M´as concretamente, en la Figura 5.1a se muestra el R2medio en el conjunto de test obtenido por las SVRs entrenadas/evaluadas en 10 pares distintos de entrenamiento y test para distintas fracciones conocidas de la curva. En dicha gr´afica podemos ver que, como era de esperar, cuanto mayor es la fracci´on conocida de la curva mayor es el R2de los predictores de rendimiento. Esto tambi´en ocurre en los experimentos realizados por Baker et al. para la predicci´on del rendimiento de otras redes neuronales. Adem´as, en la Figura 5.1a , tambi´en se observa que incluir los valores de los hiperpar´ametros en las caracter´ısticas usadas para para predecir el rendimiento solamente supone una ventaja cuando la fracci´on conocida de la curva es peque˜na. Es decir, la informaci´on m´as relevante para predecir el rendimiento final 37 38 CAP´ ITULO 5. PRUEBAS Y DISCUSI ´ ON DE RESULTADOS (a) R2de test medio las SVRs usando diferentes caracter´ısitcas. (b) Valores de test reales frente a predichos mediante SVR. Figura 5.1: Predicci´on de rendimiento de MLPF mediante SVRs cl´asicas. del modelo objetivo es la curva de aprendizaje parcial. Esto resulta interesante ya que nos indica que aplicar t´ecnicas de predicci´on de rendimiento puede ser viable para optimizar tambi´en hiperpar´ametros categ´oricos cuyos valores no podr´ıan ser incorporados al vector de caracter´ısticas. De entre todas las SVRs que se entrenaron para realizar la Figura 5.1a, se consideraron las que que utilizaban un 0,25 de fracci´on conocida de la curva e incluyeron los valores de los hiperpar´ametros en el vector de caracter´ısticas. De entre todas estas, se seleccion´o la SVR que obtuvo un mayor R2, concretamente un R2= 0,989 en el conjunto de test, para realizar la Figura 5.1b. Dicha figura muestra las p´erdidas predichas por la SVR frente a las p´erdidas reales de MLPF. En el caso de que todas las predicciones se realizasen de forma perfecta, los puntos de la Figura 5.1b se encontrar´ıan sobre la recta diagonal pintada en negro. Podemos ver que, a pesar de que las predicciones no son perfectas, la mayor´ıa de los puntos est´an cercanos a la recta identidad, indicando que los valores predichos son cercanos a los valores reales. Adem´as, cabe destacar que las predicciones son m´as precisas en los casos en los que la p´erdida verdadera es peque˜na. Por otra parte, las mayores discrepancias entre las predicciones y la realidad se observan principalmente al predecir el rendimiento de configuraciones con p´erdidas verdaderas relativamente altas. En el caso de utilizar las predicciones de rendimiento para optimizar hiperpar´ametros, no es de gran importancia que se produzcan discrepancias en situaciones donde la p´erdida real es alta, siempre y cuando la p´erdida predicha sea lo suficientemente alta como para descartar la configuraci´on sin completar su entrenamiento. Ya que los valores R2alcanzados mediante el uso de SVRs cl´asicas para predicci´on de rendimiento de MLPF son comparables a los obtenidos por Baker et 5.1. PREDICCI ´ ON DE RENDIMIENTO DE MLPF 39 al., podemos concluir que las SVRs cl´asicas son un modelo apto para ser usado como predictor de rendimiento para MLPF. 5.1.2. Resultados con Q-SVRs A la hora de trabajar con las Q-SVR, fue necesario, como ya hemos explicado, reducir el n´umero de ejemplos usados en el entrenamiento a 20. Adem´as, tal y como justificamos en el cap´ıtulo anterior, nos limitamos a analizar el R2de las Q-SVR usando un fracci´on conocida de la curva de 0,25 De esta forma, se entrenaron 10 Q-SVRs usando diferentes pares de entrenamiento/test. En la Figura 5.2 podemos ver las p´erdidas reales de MLPF frente a las p´erdidas predichas por la Q-SVR que mayor R2obtuvo. Figura 5.2: Valores de test reales frente a predichos mediante Q-SVR. Q-SVR Q-SVR simulada SVR cl´asica Promedio 0,880 0,901 0,889 Mayor 0,948 0,949 0,959 Menor 0,742 0,383 0,318 Desv. est´andar 0,056 0,045 0,050 Repeticiones 10 100 1000 Cuadro 5.1: Resumen de los R2de test para distintos modelos. En la Figura 5.2, podemos ver que se produce una mayor discrepancia entre los valores reales y predichos que en la Figura 5.1b, lo que cuadra con que el R2 de la Q-SVR sea m´as bajo que el de la SVR. A´un as´ı, la mayor´ıa de los puntos, especialmente aquellos con p´erdida real m´as baja, se sit´uan relativamente cercanos a la recta identidad, indicando que los valores predichos son cercanos a los valores reales. A pesar de haber usado solamente 20 ejemplos de entrenamiento, el valor de R2mostrado en la Figura 5.2 es comparable con los mejores valores de R2obte- nidos por Baker et al. al usar ν-SVRs para predecir el rendimiento de las redes neuronales consideradas en su estudio, que van desde 0,938 hasta 0,974 cuando la fracci´on conocida la curva es 0,25. Por otra parte, en el Cuadro 5.1 mostramos un resumen de los valores de R2 obtenidos usando una fracci´on conocida de la curva de 0,25 y 20 ejemplos de entrenamiento mediante Q-SVRs, Q-SVRs simuladas y SVR cl´asicas. En el caso 40 CAP´ ITULO 5. PRUEBAS Y DISCUSI ´ ON DE RESULTADOS de la SVR cl´asica, debido a su bajo coste computacional, se evalu´o el R2en 1000 particiones de entrenamiento y test distintas; la Q-SVR simulada se evalu´o en 100 particiones distintas y la Q-SVR solamente en 10 particiones debido a las limitaciones de tiempo de uso del computador cu´antico para el proyecto. Podemos observar que, a pesar de haber usado ´unicamente 20 ejemplos de entrenamiento, la SVR cl´asica, obtiene en promedio un R2similar al mostrado en la Figura 5.1a cuando la fracci´on conocida de la curva es 0,25. Esto parece indicar que no es necesario trabajar con un gran n´umero de ejemplos para entrenar las SVR para predicci´on de rendimiento. Esto es un aspecto muy positivo, ya que, para obtener Nejemplos de entrenamiento para un predictor de rendimiento es necesario entrenar hasta la ´epoca objetivo Nconfiguraciones del modelo a optimizar, lo que tiene un alto coste computacional. Volviendo sobre el Cuadro 5.1, vemos que tanto los valores de R2promedio como el mejor R2obtenidos para la Q-SVR simulada y la SVR cl´asica son bastante similares y, en ambos casos, superiores a los obtenidos por la Q-SVR. Adem´as, si nos fijamos en la desviaci´on est´andar del R2para cada modelo podemos ver que la Q-SVR es el modelo con mayor desviaci´on. Estas dos hechos podr´ıan indicar que no se han llegado a utilizar los mejores valores para los hiperpar´ametros cu´anticos de la Q-SVR. A´un as´ı, los valores de R2obtenidos corroboran que la elecci´on ha sido relativamente buena. Para concluir esta secci´on, cabe destacar que los resultados obtenidos tanto por las SVRs como por las Q-SVRs a la hora de predecir el rendimiento de MLPF fueron considerados satisfactorios tomando de referencia los valores obtenidos por Baker et al.. Esto motiv´o que se procediese a la segunda parte del trabajo, integrando el uso de predictores con los algoritmos de HPO. 5.2. Comparativa de los algoritmos de HPO Para evaluar la integraci´on de los predictores de rendimiento con HPO mediante los algoritmos Fast-Hyperband y Swift-Hyperband, realizaremos una comparativa entre Hyperband, Fast-Hyperband, Swift-Hyperband y Q-Swift-Hyperband, que es como nos referiremos a Swift-Hyperband cuando los predictores usados son Q-SVRS, simulando la ejecuci´on de cada uno de estos algoritmos usando los conjuntos de datos de curvas de aprendizaje descritos en la secci´on 3.2. Esto nos permitir´a evaluar los algoritmos de HPO, no solo tomando MLPF como modelo objetivo, si no que tambi´en para otras tres redes neuronales dise˜nadas para distintas tareas. En la literatura de HPO, es relativamente frecuente simular la ejecuci´on de los algoritmos a la hora de realizar comparativas entre ellos ya 5.2. COMPARATIVA DE LOS ALGORITMOS DE HPO 41 (a) Modelo MLPF para Delphes. (b) Modelo LSTM para PTB. (c) Modelo CNN para CIFAR-10. (d) Modelo CNN para SVHN. Figura 5.3: Resultados tras 10 ejecuciones simuladas de Hyperband, Fast- Hyperband y Swift-Hyperband para distintos modelos objetivo. que esto evita la necesidad de disponer de los elevados recursos computacionales necesarios para entrenar repetidas veces configuraciones de los modelos objetivo [2, 16]. De este modo, para cada conjunto de datos de curvas de aprendizaje, simulamos 10 ejecuciones de cada algoritmo de HPO. Para cada modelo objetivo, reportamos tanto la media del rendimiento de las configuraciones seleccionadas por cada algoritmo como la media del n´umero de ´epocas de entrenamiento necesitadas por cada algoritmo. As´ı, la comparativa realizada tiene en cuenta tanto la capacidad de los algoritmos de encontrar buenas configuraciones como los recursos necesarios para la b´usqueda de las mismas. Los resultados de esta comparativa se presentan en la Figura 5.3. Por otra parte, realizamos 5 ejecuciones reales de cada algoritmo tomando como modelo objetivo la CNN para clasificaci´on de im´agenes de la documentaci´on de RayTune que hemos mencionado en la secci´on 4.2. Estas ejecuciones se realizaron en el cl´uster de computaci´on Rusty, cuyas especificaciones se detallan en la secci´on 2.1, utilizando una GPU Nvidia A100 de 40GB para el entrenamiento 42 CAP´ ITULO 5. PRUEBAS Y DISCUSI ´ ON DE RESULTADOS Figura 5.4: Resultados tras 5 ejecuciones de Hyperband, Fast-Hyperband y Swift- Hyperband. del modelo objetivo. En este caso, al tratarse de ejecuciones reales, reportamos el tiempo medio de ejecuci´on de cada algoritmo en lugar del n´umero medio de ´epocas. Los resultados de este experimento se encuentran en la Figura 5.4 donde solo incluimos la versi´on de Swift-Hyperband que usa SVRs cl´asicas ya que no se realizaron ejecuciones Swift-Hyperband usando Q-SVRs. Esto se debe a que las medidas de seguridad del cl´uster Rusty no permiten la conexi´on con el computador cu´antico del J¨ulich Supercomputing Center. En la figura 5.3a podemos ver que, en el caso de MLPF, todos los algoritmos de HPO encuentran configuraciones exactamente igual de buenas. Esto se debe a que todos ellos encontraron la configuraci´on ´optima de entre las que se les presentaron en cada ejecuci´on simulada. Adem´as, se muestra como los algoritmos que integran predicci´on de rendimiento (Fast-Hyperband y las dos versiones de Swift-Hyperband) necesitaron menos ´epocas de entrenamiento para encontrar la configuraci´on ´optima que el algoritmo convencional Hyperband, siendo Swift- Hyperband el algoritmo que, en promedio, necesito menos ´epocas. Esto muestra que Swift-Hyperband puede ser una opci´on a tener en cuenta para acelerar la optimizaci´on de hiperpar´ametros de MLPF en futuros ciclos del desarrollo de dicho modelo. Fij´andonos ahora tanto en las ejecuciones simuladas para todos los modelos (Figura 5.3) como en las ejecuciones reales (Figura 5.4), podemos ver como, en todos los casos, los algoritmos que integran predicci´on de rendimiento, encuentran configuraciones con rendimientos muy similares a las seleccionadas por Hyperband pero consumiendo menos recursos (medidos en tiempo o en ´epocas). En todos los casos probados, el ahorro de recursos con respecto de Hyperband se sit´ua cerca del 10 % para alguno de los algoritmos. 5.2. COMPARATIVA DE LOS ALGORITMOS DE HPO 43 Si nos centramos en comparar Swift-Hyperband y Fast-Hyperband podemos ver que, en todos los casos probados menos en uno, Swift-Hyperband (tanto con SVR como con Q-SVR) necesit´o menos recursos que Fast-Hyperband. En todos los casos, Swift-Hyperband encontr´o configuraciones con mejores rendimientos en promedio que las encontradas por Fast-Hyperband. Por otra parte, si comparamos Swift-Hyperband y Q-Swift Hyperband vemos como, en todos los casos, Q-Swift-Hyperband necesit´o en promedio m´as recursos que Swift-Hyperband. Ya que la ´unica diferencia entre Swift-Hyperband y Q-Swift Hyperband es el modelo usado como predictor de rendimiento, la diferencia entre los recursos necesitados por cada algoritmo podr´ıa deberse a que las Q-SVR tengan cierta tendencia a sobreestimar el rendimiento de las configuraciones al hacer predicciones. Esta sobreestimaci´on se traducir´ıa en que Q-Swift-Hyperband se comportase de forma menos agresiva que Swift-Hyperband a la hora de descartar configuraciones de forma temprana, resultando en un menor ahorro de recursos. Esta hip´otesis se ve reforzada por el hecho de que Q-Swift-Hyperband encuentre configuraciones con rendimientos ligeramente mejores que Swift-Hyperband en la mayor´ıa de casos. Adem´as, en la Figura 5.2 observamos como las predicciones realizadas por la Q-SVR parecen tener cierta tendencia a estar por debajo del valor real en los casos con p´erdida real baja. Por ´ultimo, algo que puede resultar llamativo, es que en algunos casos Swift- Hyperband o Q-Swift-Hyperband seleccionen configuraciones que, en promedio, son ligeramente mejores que las seleccionadas por Hyperband. En un supuesto ideal en los que los predictores de rendimiento siempre realizasen predicciones perfectas, Swift-Hyperband y Q-Swift-Hyperband encontrar´ıan las mismas configuraciones que Hyperband. Sin embargo, los resultados observados, parecen indicar que, de alguna forma, los errores cometidos por los predictores de rendimiento, hacen que se descarten de forma temprana configuraciones que Hyperband promocion´o incorrectamente1en algunas rondas. Es decir, parece que, en algunos casos, los predictores de rendimiento tienen una especie de “efecto regularizador” que mitiga el principal defecto de los m´etodos de early-stopping, explicado en la secci´on 2.1.1, a la hora de descartar configuraciones. 5.2.1. Paralelizaci´on de Swift-Hyperband Tal y como indicamos en la secci´on de metodolog´ıa, se realiz´o una implementaci´on distribuida de Swift-Hyperbanda usando MPI. Para poner a prueba la aceleraci´on proporcionada por dicha implementaci´on, se midieron los tiempos de 1En el sentido de que promocion´o configuraciones que eran mejores que las dem´as al final de la ronda pero no lo son a largo plazo. 44 CAP´ ITULO 5. PRUEBAS Y DISCUSI ´ ON DE RESULTADOS Figura 5.5: Speedup de la versi´on distribuida de Swift-Hyperband. ejecuci´on de Swift-Hyperband variando el n´umero de procesos equipados con una GPU Nvidia A100 de 40 GB, desde 1 hasta 8. Estas ejecuciones se realizaron en el cl´uster de computaci´on Rusty y el modelo objetivo fue la CNN para clasificaci´on de im´agenes tomada de la documentaci´on librer´ıa RayTune. Para cada n´umero de procesos equipados con GPU se realizaron 5 ejecuciones del algoritmo y se calcul´o la media del tiempo necesitado en cada ejecuci´on. De esta forma, en la Figura 5.5, reportamos la duraci´on media de las ejecuciones para cada n´umero de GPUs de forma relativa a la duraci´on media de las ejecuciones con una sola GPU. Esta medida de duraci´on relativa se denomina speedup. De esta forma, cuando se usa una ´unica GPU el speedup es 1. En el caso de que la paralelizaci´on del algoritmo sea ideal, el speedup coincidir´a con la funci´on identidad. Por lo tanto, representar gr´aficamente el speedup facilita la comparaci´on de la aceleraci´on obtenida realmente con la aceleraci´on ideal. Los resultados mostrados en la Figura 5.5 muestran como el speedup est´a cada vez m´as lejos del caso ideal a medida que aumenta el n´umero de procesos con GPUs. Estos resultados coinciden con lo esperado ya que, cuando un bracket de Swift-Hyperband alcanza una ronda en la que quedan menos configuraciones “vivas” que GPUs, las GPUs “extra” no proporcionan ninguna aceleraci´on porque, simplemente, no se utilizan. Este problema ocurre tambi´en con la paralelizaci´on de la versi´on original del algoritmo Hyperband. De hecho, el algoritmo ASHA fue dise˜nado como una alternativa a Hyperband que puede ser paralelizada de forma eficiente [16]. 5.3. Par´ametros utilizados en las pruebas Todas las SVRs cl´asicas utilizadas para generar los resultados mostrados en este cap´ıtulo utilizan la implementaci´on proporcionada por la clase NuSVR de 5.3. PAR ´ AMETROS UTILIZADOS EN LAS PRUEBAS 45 scikit-learn. Los hiperpar´ametros de las SVRs no se han establecidos expl´ıcitamente, de forma que se han tomado los valores seleccionados autom´aticamente por scikit-learn salvo en los experimentos del Cuadro 5.1 donde se usaron los mismos par´ametros que en las Q-SVRs. Los hiperpar´ametros de las Q-SVRs y Q-SVRs simuladas se han seleccionado siguiendo la metodolog´ıa descrita en la secci´on 4.1.2 y se muestran en el Cuadro 5.2. En relaci´on a los par´ametros de los algoritmos de HPO, el valor de Rtomado en las ejecuciones simuladas se ha seleccionado en funci´on de las ´epocas disponibles en cada conjunto de datos de curvas de aprendizaje. As´ı, se ha tomado R= 100 para todos los casos excepto para la LSTM en la que se tom´o R= 60 por ser este el n´umero m´aximo de ´epocas en el conjunto de datos correspondiente. En el caso de las ejecuciones reales de los algoritmos para la red neuronal de clasificaci´on de im´agenes se tom´o R= 100 por ser esta la ´epoca objetivo indicada en el ejemplo de la documentaci´on de RayTune del que se tom´o dicha red. Los valores tomados para los dem´as par´ametros de los algoritmos junto con la justificaci´on de su elecci´on se encuentran en el Cuadro 5.3 Par´ametro ϵ γ C K B k0ξanneal time num reads chain mult Valor 0,02 0,01 67,61 3 0,5 0,005 0,01 20 1000 10 Cuadro 5.2: Valores de los hiperpar´ametros del modelo Q-SVR usados en las pruebas. Par´ametro Justificaci´on Afecta a η= 2 Valor m´as bajo posible [15] , hace que se descarten configuraciones de la forma menos agresiva posible. Todos d= 15 Alto como para que los predictores sean buenos pero no demasiado para que se puedan usar m´as predictores. Fast/Swift-Hyperband k= 0,5Uno de los valores propuestos por Baker et al. cuando presentan el algoritmo Fast-Hyperband. Fast/Swift-Hyperband ∆=0,9Uno de los valores propuestos por Baker et al. cuando presentan el algoritmo Fast-Hyperband Fast-Hyperband δ= 0 Uno de los valores propuestos por Baker et al. cuando presentan el algoritmo Fast-Hyperband Fast-Hyperband new dp = 0,5Elecci´on natural, sit´ua los puntos de decisi´on basados en predicci´on de rendimiento en el medio de cada ronda. Swift-Hyperband Cuadro 5.3: Valores de los par´ametros de los algoritmos de HPO usados en las pruebas. 52 AP´ ENDICE A. MANUALES T´ ECNICOS ⋄outfiles: directorio para almacenar los resultados de las ejecuciones simuladas. •parallel-swift-hb: ficheros necesarios para la ejecuci´on distribuida de Swift-Hyperband. ◦MPI swift hyperband cifar10.py: implementaci´on distribuida del algoritmo utilizada para generar los resultados de la Figura 5.5. ◦plots.py:Jupyer Notebook para generar la gr´afica de la Figura 5.5. ◦results: carpeta con los ficheros de texto que almacenan los resultados de las ejecuciones del algoritmo. ◦start mpi swift < n > gpus.sh: script de bash para ejecutar el algoritmo distribuido usando nGPUs en el cl´uster Rusty. requirements.txt: requisitos del entorno de Python para la ejecuci´on de los scripts del trabajo. A.2. Creaci´on del entorno Aunque existen otras formas posibles de configurar el entorno de trabajo para este proyecto, la forma recomendada es trabajar en un dispositivo con sistema operativo Linux, instalar el editor de c´odigo Visual Studio Code disponible en https://code.visualstudio.com/ para poder ejecutar los Jupyter Notebooks directamente desde el editor sin necesidad de ejecutar un Notebook Server y crear un entorno de Python que contenga las dependencias necesarias para todo el proyecto. Dicho entorno se puede crear mediante miniconda abriendo una terminal en el directorio ra´ız del proyecto y siguiendo las siguientes instrucciones: 1. Descargar miniconda mediante el comando: wget https://repo.anaconda.com/miniconda/ Miniconda-py39_4.11.0-Linux-x86_64.sh 2. Instalar miniconda mediante el comando: sh Miniconda3-py39_4.11.0-Linux-x86_64.sh Una vez completada la instalaci´on el prompt de la terminal cambiar´a para comenzar por “(base)”. De no ser as´ı, para activar miniconda basta con cerrar la terminal actual, abrir una nueva terminal en el directorio ra´ız del proyecto y ejecutar el comando: conda init 3. Una vez que est´a miniconda activado creamos un entorno para el proyecto mediante el comando: A.3. REPRODUCCI ´ ON DE LOS RESULTADOS 53 conda create -n entornoTFG python=3.9 4. Activamos el entorno del proyecto mediante el comando: conda activate entornoTFG El prompt de la terminal cambiar´a para comenzar por “(entornoTFG)”. 5. Instalamos los paquetes de Python necesarios para el proyecto mediante el comando: pip3 install -r requirements.txt 6. Abrimos el directorio ra´ız del proyecto en Visual Studio Code y seleccionamos “entornoTFG” como int´erprete de Python en los Jupyter Notebooks. A.3. Reproducci´on de los resultados Indicamos a continuaci´on como repetir la experimentaci´on presentada en la memoria: Para repetir los experimentos con SVRs cl´asicas presentados en la Figura 5.1 se debe ejecutar desde Visual Studio Code el Jupyter Notebook estudiopreliminar/code/SVR experiments.ipynb. Para repetir los experimentos con SVRs cl´asicas presentados en el Cuadro 5.1 se debe ejecutar desde Visual Studio Code el Jupyter Notebook estudio-preliminar/code/20 points SVR.ipynb. Para repetir los experimentos con QSVRs y QSVRs simuladas presentados en el Cuadro 5.1 y en la Figura 5.2 se debe ejecutar desde Visual Studio Code el Jupyter Notebook estudio-preliminar/code/QSVR experiment.ipynb, que solo funcionar´a si se dispone del c´odigo del repositorio qa summer del J¨ulich Supercomputing Center. Para repetir las ejecuciones simuladas de los algoritmos presentadas en la Figura 5.3 se debe abrir una terminal dentro del directorio HPO/coreimplementation, activar el entorno “entornoTFG” y ejecutar el comando: python3 -m simulated.main --dataset=mlpf --include_cuantum=true Esto generar´a el fichero de salida mlpf-<fecha>-out.csv con los resultados de las ejecuciones. Se debe ejecutar el comando anterior 3 veces m´as cambiando “mlpf” por “lstm”, “svhn” y “cifar10” para repetir las pruebas para todos los conjuntos de datos de curvas de aprendizaje. Se producir´a un error si no se dispone del c´odigo del repositorio hybrid-qa-workflow del J¨ulich Supercomputing Center, para evitar este error se puede establecer la flag “–include cuantum” a false y repetir parcialmente la experimentaci´on. 54 AP´ ENDICE A. MANUALES T´ ECNICOS Para repetir las ejecuciones reales de los algoritmos presentadas en la Figura 5.4 es necesario disponer de al menos una GPU Nvidia (idealmente Nvidia A100 de 40GB), se debe abrir una terminal dentro del directorio HPO/core-implementation, activar el entorno “entornoTFG” y ejecutar el comando: python3 -m cifar10.main --algorihm=swift --seed=0 Cambiando “swift” por “fast” y por “hyperband” para realizar las ejecuciones para los 3 algoritmos. Adem´as se debe variar la flag “–seed” desde 0 hasta 4 para realizar las 5 ejecuciones para cada algoritmo. Es recomendable realizar estas ejecuciones en un cl´uster de computaci´on usando el software pertinente para agendar las ejecuciones, en el caso del cl´uster Rusty se debe usar SLURM. Para repetir las ejecuciones distribuidas de Swift-Hyperband presentadas en la Figura 5.5 en el cl´uster Rusty es necesario situarse en el directorio HPO/parallel-swift-hb y ejecutar el comando: sbatch start_mpi_swift_<n>gpus.sh Variando ndesde 1 hasta 8 para agendar las ejecuciones. Ap´endice B Manuales de usuario El c´odigo del trabajo se encuentra disponible en el enlace https://nubeus c-my.sharepoint.com/:f:/g/personal/juanpablo_garcia_rai_usc_es/En LH8ZRA3BFFrpkUk3HF-DkBiDUAxNz8b4VA3kJyLUAl0w?e=Yx6pbK. En dicho c´odigo no se incluye el fichero con la clase QSVR desarrollada por los investigadores del J¨ulich Supercomputing Center ni sus ficheros auxiliares. Esto se debe a que dicho c´odigo es propiedad del J¨ulich Supercomputing Center y, por el momen- to, desean que no sea accesible fuera de los repositorios privados de su instituci´on. La estructura de ficheros del proyecto explicada se puede consultar en el Ap´endice A.1 Estructura de ficheros. Asimismo, las instrucciones relativas a la creaci´on del entorno de trabajo se pueden consultar en el Ap´endice A.2 Creaci´on del entorno. El c´odigo desarrollado durante el trabajo no consiste en un software destinado a usuarios, sino que se trata de una serie de scripts dedicados a desarrollar y probar los m´etodos y algoritmos descritos en el trabajo. A´un as´ı, se proporcionan una serie de instrucciones sobre como desarrollar un script para ejecutar los algoritmos de HPO para otros modelos objetivo. Si se dispone de un conjunto de datos de curvas de aprendizaje en formato csv donde las primeras columnas sean los hiperpar´ametros de las configuraciones y las siguientes sean la p´erdida de las configuraciones en cada ´epoca se debe modificar la clase ConfigGeneratorSim para que lea el fichero con las curvas deseado y es posible reutilizar las clases TrialSim y Predictor as´ı como el main de la carpeta simulated. Si se desea realizar ejecuciones reales del algoritmo, lo recomendable es seguir como gu´ıa el contenido de la carpeta cifar10. El usuario puede reutilizar la clase Predictor y la funci´on main existentes pero deber´a programar las siguientes clases: 55 56 AP´ ENDICE B. MANUALES DE USUARIO •TrialMiModelo: hereda de la clase Trial y debe implementar los m´etodos siguientes: ◦setup(self, config): construye un modelo listo para ser entrenado siguiendo la configuraci´on config generada por la clase ConfigGeneratorMiModelo. ◦train(self, epochs): entrena el modelo almacenado en la clase el n´umero de ´epocas indicado en el par´ametro epochs. ◦get last loss(self): devuelve la p´erdida del modelo tras su ´ultima ´epoca de entrenamiento. Si se desea trabajar con otra m´etrica que se deba maximizar en vez de minimizar, como la precisi´on del modelo, basta con devolver −1·m´etrica a maximizar. ◦get loss(self, idx): devuelve la p´erdida del modelo tras la ´epoca de entrenamiento idx. Si se desea trabajar con otra m´etrica que se deba maximizar en vez de minimizar, como la precisi´on del modelo, basta con devolver −1·m´etrica a maximizar. •ConfigGeneratorMiModelo: hereda de la clase ConfigGenerator y debe implementar los siguientes m´etodos: ◦init (self, Trial, random state): ◦get hyperparameter configuration(self, n): Si se desea cambiar el modelo usado como predictor de rendimiento el usuario deber´a implementar su propia versi´on de la clase Predictor con los siguientes m´etodos. •train(self, data): entrena el modelo de regresi´on usando los datos de data que es una lista de lista que, a su vez est´a formada por listas tal que los primeros elementos de cada lista son las caracter´ısticas para la regresi´on y el ´ultimo es el valor objetivo. •predict(self, l): devuelve una predicci´on realizada por el modelo de regresi´on ya entrenado para las caracter´ısticas almacenadas en la lista l. •get sigma(self): solo es necesario implementar este m´etodo si se desea usar el predictor con Fast-Hyperband. El m´etodo debe devolver una estimaci´on de la desviaci´on est´andar del predictor. Ap´endice C Licencia Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical 57 58 AP´ ENDICE C. LICENCIA transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of 59 this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and 60 AP´ ENDICE C. LICENCIA do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the 61 Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don’t include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright 2023 Juan Pablo Garcia Amboage Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.