Constructo: sistema serverless para la generación de topologías mediante Machine Learning

Facultad de Inform´atica Trabajo de Fin de Grado Constructo: Sistema serverless para la generaci´on de topolog´ıas mediante Machine Learning Por Pablo Ezquerro Moya Dirigido por Jos´ e Luis V´ azquez Poletti Juan Carlos Fabero Jim´ enez Colaborador Externo: David Pacios Izquierdo MADRID, 2023–2024 Abstract This work explores the development of a serverless system for generating network topologies using machine learning techniques, specifically through the use of YOLO models. The system leverages object recognition to automatically convert hand-drawn diagrams into digital formats that can be imported directly into GNS3 for network simulation. By automating this process, the project addresses the cumbersome and time-consuming task of manual network configuration, potentially revolutionizing network design practices in educational and professional settings. The implementation uses AWS Lambda to handle processing, providing a cost-effective and scalable solution. Este trabajo explora el desarrollo de un sistema serverless para la generaci´ on de topolog´ ıas de red utilizando t´ ecnicas de machine learning, espec´ ıficamente a trav´ es del uso de modelos YOLO. El sistema utiliza el reconocimiento de objetos para convertir autom´ aticamente diagramas dibujados a mano en formatos digitales que pueden importarse directamente en GNS3 para la simulaci´ on de redes. Al automatizar este proceso, el proyecto aborda la tarea engorrosa y que consume mucho tiempo de la configuraci´ on manual, con el potencial de revolucionar las pr´ acticas de dise˜ no de redes en entornos educativos y profesionales. La implementaci´ on utiliza AWS Lambda para manejar el procesamiento, proporcionando una soluci´ on rentable y escalable. Palabras Clave: Arquitectura Serverless, Generaci´on de Topolog´ıas de Red, Machine Learning, YOLO (You Only Look Once), Reconocimiento de Objetos, AWS Lambda, Simulaci´on de Redes GNS3. III ´ Indice general Abstract ........................................................ III Cap´ıtulo 1 Introduction....................................... 1 Cap´ıtulo 1 Introducci´on ...................................... 3 Cap´ıtulo 2 Estado del Arte ................................... 5 Cap´ıtulo 3 Tecnolog´ıas ....................................... 19 Cap´ıtulo 4 Dise˜no de Soluci´on ................................ 25 Cap´ıtulo 5 Desarrollo de la arquitectura ....................... 49 Cap´ıtulo 6 Resultados, mediciones y conclusiones .............. 57 Cap´ıtulo 6 Results, Measurements, and Conclusions. . . . . . . . . . . . 63 Bibliograf´ıa......................................................70 V Chapter 1. Introduction 1.1. Context The project we have been working on emerged as a response to the need to streamline the process of creating network topologies in the GNS3 tool. This tool allows for the design of networks to simulate real-world scenarios using various elements and components. Generally, the most tedious and demotivating part of computing is configuring the workspaces, or environments, in which to apply your knowledge. This is something that most of us who study or have studied any branch of computing can agree on. Using a tool like GNS3 allows you to experiment with different topologies using each network element independently. However, as mentioned earlier, the process of setting up the environment, the network, and its elements, is boring and monotonous. In GNS3, topology configuration is done by dragging elements from an element selector on the left side of the application. These elements must be dragged to their desired position and then connections between them must be established. When the network is small, this is not a difficult task. However, as the number of elements and network connections increases, it becomes more complicated. 1.2. Objective To address this problem, we came up with the idea of creating network topologies by drawing them manually with paper and pen. Then, a program, using object recognition techniques, would be able to interpret these drawings and automatically generate a file that can be imported into GNS3 with the resulting topology. The drawings should follow the following legend to represent the elements: 1 2 Figura 1.1: SRV Figura 1.2: Link Figura 1.3: Router Figura 1.4: Switch The process to convert the hand-drawn diagrams into importable topologies for GNS3 consists of the following steps: 1. Draw the topology by hand: The user creates a drawing using paper and pen. The symbols used must follow the provided legend to correctly represent the network elements. 2. Scan the drawing: The drawing is digitized using a scanner or a high-quality photo application. 3. Object recognition: The developed program uses image recognition techniques to identify the symbols in the drawing and their connections. The information about the detected objects is stored in a .txt file. 4. Generation of a file for GNS3: From the .txt file, a .json file is generated with the structure of a GNS3 project. This process allows users to quickly create network topologies using simple tools. Through object recognition techniques, hand-drawn sketches are transformed into real network simulation projects. Cap´ıtulo 1. Introducci´on 1.1. Contexto El proyecto en el que hemos estado trabajando surgi´ o como respuesta a la necesidad de agilizar el proceso de creaci´ on de topolog´ ıas de red en la herramienta GNS3. Esta herramienta permite dise˜ nar redes para simular escenarios reales utilizando diversos elementos y componentes. Generalmente, la parte mas tediosa y desmotivadora de la inform´ atica es la configuraci´ on de los espacios de trabajo, o entornos, en los que poder aplicar los conocimientos. Eso es algo que la mayor´ ıa de personas que estudiamos o hemos estudiado alguna rama de inform´ atica estamos de acuerdo. Usar una herramienta como GNS3 permite poder experimentar con distintas topolog´ ıas utilizando cada elemento de la red de manera independiente. Pero como hemos comentado antes, el proceso de configurar el entorno, la red y sus elementos, es algo aburrido y mon´ otono. En GNS3 la configuraci´ on de la topolog´ ıa se realiza arrastrando elementos desde un selector de elementos ubicado en la parte izquierda de la aplicaci´ on. Estos elementos hay que arrastrarlos a su posici´ on deseada y luego establecer las conexiones entre ellos. Cuando la red es peque˜ na, no es un tarea dif´ ıcil. Pero cuando se va incrementando el n´ umero de elementos y conexiones de la red, se vuelve m´ as complicado. 1.2. Objetivo Para abordar este problema, se nos ocurri´ o la idea de crear las topolog´ ıas de red dibuj´ andolas a mano con papel y bol´ ıgrafo. Luego, un programa, mediante t´ ecnicas de reconocimiento de objetos, ser´ ıa capaz de interpretar esos dibujos, y generar autom´ aticamente un archivo que pueda importarse a GNS3 con la topolog´ ıa resultante. Los dibujos deber´ an seguir la siguiente leyenda para representar los elementos: 3 10 y otros casos relacionados con la seguridad vial. El resultado y el diagrama completo es mostrado en la Figura 2.66. Figura 2.6: Resultado final tras aplicar las CNN para la detecci´ on de cascos y manos. De este trabajo se ha obtenido informaci´ on acerca de distintas metodolog´ ıas para la realizaci´ on la detecci´ on de objetos, en este caso se ha realizado mediante CNN. 2.7. Deep learning Este art´ ıculo [8] realiza una revisi´ on del estado del arte sobre las redes neuronales profundas (DNN). De estas aplicaciones se destacan desde el reconocimiento de im´ agenes hasta el reconocimiento de lenguaje natural. Se hace hincapi´ e en la importancia de mejorar a´ un m´ as la comprensi´ on de las DNN y su capacidad para el razonamiento complejo. Se mencionan 6Diagrama y resultado obtenidos del art´ ıculo: https://doi.org/10.3390/bdcc6030085 11 avances recientes en el aprendizaje de representaciones y se discute la necesidad de desarrollar nuevas estrategias que combinen el aprendizaje de representaciones con el razonamiento complejo. Se se˜ nala que el futuro de la inteligencia artificial depender´ a en gran medida de sistemas que integren ambas capacidades de manera efectiva. Tambi´ en cabe destacar que este art´ ıculo menciona que esta tecnolog´ ıa todav´ ıa est´ a sentando bases, por lo que las investigaciones realizadas todav´ ıa est´ an expandiendo los l´ ımites de esta tecnolog´ ıa. Concluye indicando que se tiene que seguir investigando sobre las DNN para la realizaci´ on de nuevas inteligencias artificiales y para la realizaci´ on de nuevas DNN. De este art´ ıculo se ha obtenido una nueva metodolog´ ıa para la realizaci´ on de las detecciones. Para este caso se ha estudiado en profundidad las DNN. 2.8. Static Analysis for AWS Best Practices in Python Code Este preprint [9] realiza un an´ alisis de distintos tipos de operaciones que se pueden realizar en Python en el contexto de AWS mediante el uso de API. Estas API permiten a los usuarios definir filtros para seleccionar nodos de acci´ on basados en criterios espec´ ıficos, como el nombre de la funci´ on o el n´ umero de argumentos. Adem´ as, las operaciones de transformaci´ on permiten modificar nodos de acci´ on o datos de acuerdo con ciertas reglas, como transformar un nodo de acci´ on en sus argumentos respectivos o sus nodos de captura de errores asociados. Este tipo de operaciones se realizan para entender el flujo de las operaciones dentro de Python. Por ejemplo, las funciones de filtrado pueden ayudar a identificar vulnerabilidades en seguridad, mientras que las operaciones de transformaci´ on de flujo de datos pueden ayudar a identificar si hay alg´ un fallo en la ruta, ya sea en la fuente o en el destino. Tambi´ en se ilustran distintos casos de uso en relaci´ on a las API. Hace referencia a una serie de trabajos de investigaci´ on relevantes en el campo del an´ alisis est´ atico de programas, como estudios sobre detecci´ on de uso incorrecto de API, inferencia de tipos est´ aticos y an´ alisis de flujo de datos en Python. Estas investigaciones proporcionan un contexto importante para comprender la importancia y la aplicaci´ on pr´ actica de las herramientas y t´ ecnicas descritas en el documento. 12 De este preprint se ha obtenido la base para la realizaci´ on de la API y c´ omo coordinarla con AWS. Tambi´ en se hace un enfoque interesante que ha servido para evitar errores en la realizaci´ on del c´ odigo en Python en AWS. 2.9. You only look once: unified, real-time object detection Este estudio [10] presenta un modelo unificado detallado para la detecci´ on de im´ agenes basado en YOLO (You Only Look Once). Para el desarrollo de este modelo se van a comparar los modelos R-CNN y Fast R-CNN. Este tipo de detecci´ on se realiza en tiempo real y est´ a basado en la realizaci´ on mediante varias capas. Despu´ es se llevan a cabo cada uno de los conjuntos de entrenamiento para los modelos R-CNN y Fast R-CNN. Figura 2.7: Detecci´ on de im´ agenes aplicado a distintos casos de uso aplicando YOLO. Concluye comparando cada uno de los modelos y estableciendo las limitaciones a la hora de implantar YOLO. Una de las principales que se destaca es la falsa detecci´ on, donde se puede observar que hay veces que YOLO puede fallar. La Figura 2.77muestra el resultado de las distintas detecciones. Este art´ ıculo ha sido revisado con el fin de determinar qu´ e versi´ on de YOLO se ajustaba m´ as a la detecci´ on que se quer´ ıa realizar. Tambi´ en se han visto sus limitaciones. 7Imagen obtenida del art´ ıculo: https://www.cv-foundation.org/openaccess/content_cvpr_2016/ html/Redmon_You_Only_Look_CVPR_2016_paper.html 13 2.10. A Cloud Based Sentiment Analysis through Logistic Regression in AWS Platform Este estudio [11] presenta un an´ alisis de sentimientos a trav´ es de la regresi´ on log´ ıstica de Amazon Web Service (AWS). Cabe destacar la inclusi´ on de AWS en el ´ ambito de cloud computing y c´ omo ha simplificado el uso del cliente para la realizaci´ on de las labores en la nube. Se destaca la importancia de la infraestructura en la nube y se mencionan caracter´ ısticas como el equilibrio de carga, la autoescalabilidad y los acuerdos de nivel de servicio. El an´ alisis de sentimientos es una herramienta interesante para comprender las opiniones de los usuarios sobre productos o servicios. Como metodolog´ ıa se ha utilizado un algoritmo de aprendizaje autom´ atico, en este caso, es la regresi´ on log´ ıstica para clasificar las opiniones de los clientes en positivas o negativas. El estudio incluye una revisi´ on exhaustiva de la literatura relacionada con el an´ alisis de sentimientos, abordando temas como la optimizaci´ on de la carga de trabajo, la clasificaci´ on de datos en la nube, el an´ alisis de opiniones en redes sociales y el uso de algoritmos de aprendizaje autom´ atico, como las redes neuronales recurrentes y las m´ aquinas de vectores de soporte. Adem´ as, se exploran herramientas y tecnolog´ ıas relevantes, como Amazon Kinesis Data Firehose, para la ingesta de datos en la nube. 14 Figura 2.8: Arquitectura realizada para el an´ alisis de sentimientos. La Figura 2.88muestra c´ omo han realizado el an´ alisis de sentimientos a trav´ es de la red social Twitter. Para ello, primero han adquirido los mensajes mediante la aplicaci´ on Tweepy, estos datos son procesados y colectados en Python. Este estudio ha sido utilizado para entender c´ omo coordinar la aplicaci´ on en Python con AWS y as´ ı ver otro caso de uso aplicado a una aplicaci´ on donde se combinan Python y AWS. 2.11. Performance Evaluation of Deep Learning Algorithm Using High-End Media Processing Board in Real-Time Environment El art´ ıculo [12] aborda la implementaci´ on de sistemas de vigilancia de tr´ afico utilizando modelos de detecci´ on de objetos basados en aprendizaje profundo, espec´ ıficamente YOLOv3, YOLOv4, YOLOv5s y YOLOv3-tiny. Se discuten varios aspectos de la implementaci´ on, incluida la configuraci´ on del hardware y el software utilizados, como el entorno de hardware con un procesador Intel Xeon Silver y una GPU NVIDIA Jetson 8Diagrama obtenido del art´ ıculo: https://cdn.techscience.cn/ueditor/files/csse/TSP_ CSSE-45-1/TSP_CSSE_31321/TSP_CSSE_31321.pdf 15 Xavier, junto con el entorno de software que incluye Python y el marco Pytorch. Se destacan m´ etricas importantes como la temperatura de la GPU, el tiempo de inferencia y la utilizaci´ on de la memoria RAM en relaci´ on con la resoluci´ on de las im´ agenes y el modelo utilizado. Se observa que el modelo YOLOv3-tiny mantiene tiempos de inferencia m´ as bajos y una menor utilizaci´ on de la GPU en comparaci´ on con otros modelos, lo que lo convierte en una opci´ on atractiva para implementaciones en la placa Jetson Xavier si se busca mantener la utilizaci´ on de la GPU bajo control. Sin embargo, se se˜ nala que YOLOv5s utiliza m´ as recursos de GPU en todas las resoluciones de imagen, lo que puede ser una consideraci´ on importante dependiendo de los requisitos del sistema. Adem´ as, se menciona que YOLOv4 y YOLOv3-tiny tienen tiempos de inferencia m´ as bajos que otros modelos, lo que los hace adecuados para aplicaciones de transmisi´ on en vivo donde se requiere una r´ apida detecci´ on de objetos en tiempo real. Cabe destacar que se demuestran casos de uso aplicados para cada tipo de YOLO. Se presenta un caso de uso para una detecci´ on de veh´ ıculos en lo que se demuestra una alta de ´ exito. Los investigadores permiten acceso a su dataset y as´ ı como las distintas detecciones para validar su caso de uso. Con este art´ ıculo se ha obtenido una perspectiva acerca de las distintas versiones de YOLO y se ha seleccionado cu´ al era la ´ optima para la presentada en este trabajo. 2.12. Ship Target Detection Algorithm Based on Improved YOLOv3 for Maritime Image Esta publicaci´ on [13] presenta un algoritmo para la detecci´ on de embarcaciones basado en AE-YOLOv3. Se ha utilizado este algoritmo para realizar detecciones en im´ agenes de alta complejidad. Para la metodolog´ ıa se compar´ o esta tecnolog´ ıa con otras, como por ejemplo, YOLOv3, SSD y Faster R-CNN. AE-YOLOv3 demuestra una mejora sustancial en la detecci´ on de objetivos peque˜ nos, la ocultaci´ on de objetivos y la informaci´ on incompleta del objetivo, lo que resulta en una reducci´ on significativa en el n´ umero de objetivos no detectados. El algoritmo AE-YOLOv3 se basa en la integraci´ on de un m´ odulo de atenci´ on de caracter´ ısticas y un m´ odulo de mejora de caracter´ ısticas, que trabajan en conjunto para mejorar la capacidad de extracci´ on de 16 caracter´ ısticas del modelo. Estos m´ odulos permiten una mayor capacidad para identificar y seguir los objetivos de las embarcaciones, incluso en situaciones donde los objetivos est´ an parcialmente ocultos o el entorno presenta un alto nivel de distracci´ on. La aplicaci´ on de AE-YOLOv3 en sistemas de seguimiento de video se destaca como una herramienta potencial para emitir advertencias tempranas de colisi´ on, reduciendo as´ ı la probabilidad de accidentes mar´ ıtimos. Al igual que se ha visto en publicaciones anteriores, esta algoritmia tiene limitaciones, como los distintos ´ angulos por los que se obtiene las im´ agenes y las condiciones ambientales. Esta publicaci´ on ha servido para el desarrollo del algoritmo de detecci´ on y as´ ı como para entender las limitaciones de los mismos. 2.13. PG-YOLO: A Novel Lightweight Object Detection Method for Edge Devices in Industrial Internet of Things Este art´ ıculo [14] presenta una detecci´ on de objetos basado en PG-YOLO que utiliza el internet de las cosas (IoT). Es capaz de procesar una inmensa cantidad de datos y realizar la detecci´ on de una forma r´ apida y precisa. Se detalla el proceso de desarrollo y validaci´ on, en donde se incluye la selecci´ on del conjunto de datos relevante, para este caso es SHWD. Se realizan una serie de comparaciones para valorar el rendimiento de PG-YOLO con otros m´ etodos de detecci´ on e objetos. Al igual que metodolog´ ıas anteriores, cabe destacar todas las limitaciones que hay al usar este tipo de algoritmos. De este art´ ıculo se ha estudiado con detenimiento toda la algoritmia utilizada para la detecci´ on de objetos, sobre todo la parte de rendimiento. 17 2.14. The Aeroplane and Undercarriage Detection Based on Attention Mechanism and Multi-Scale Features Processing Este estudio [15] detalla un algoritmo de detecci´ on para la detecci´ on de aviones, pistas y trenes de aterrizaje. Describen mejoras en la precisi´ on promedio (mAP) y en diversas m´ etricas de rendimiento para diferentes tipos de objetos detectados. Por ejemplo, se observa un aumento del 6,18 % en la mAP para pistas y trenes de aterrizaje, as´ ı como mejoras en precisi´ on y tasa de recuperaci´ on para aviones y trenes de aterrizaje. Sin embargo, tambi´ en se se˜ nala que la capacidad de detecci´ on de objetivos peque˜ nos no ha mejorado lo suficiente y que la velocidad de detecci´ on ha disminuido, con un aumento en el tiempo de detecci´ on en comparaci´ on con versiones anteriores de los algoritmos. Se han encontrado limitaciones a la hora de desarrollo del algoritmo, como por ejemplo, la necesidad de reducir la carga computacional y aumentar la capacidad de detecci´ on. De este estudio cabe destacar la metodolog´ ıa utilizada para comparar los distintos algoritmos. Se ha utilizado una metodolog´ ıa similar para comparar en t´ erminos de computaci´ on los algoritmos de detecci´ on. 2.15. Conclusiones y Tecnolog´ıas Estos proyectos han demostrado la viabilidad y la eficacia de utilizar tecnolog´ ıas avanzadas como AWS Lambda, SageMaker y YOLO para el desarrollo de sistemas de visi´ on por ordenador aplicados a la generaci´ on de topolog´ ıas de red. AWS Lambda y SageMaker han sido identificados como herramientas clave para optimizar los recursos, ofreciendo escalabilidad y eficiencia en la gesti´ on de la computaci´ on en la nube. La capacidad de AWS Lambda para manejar tareas de computaci´ on espec´ ıficas de forma eficiente, combinada con la potencia de procesamiento de SageMaker para el entrenamiento y despliegue de modelos de machine learning, proporciona una infraestructura s´ olida que respalda las necesidades avanzadas de procesamiento de nuestro proyecto. Adem´ as, la flexibilidad de Google Colab como herramienta alternativa para el entrenamiento de modelos ha permitido superar las 18 limitaciones de recursos y acceso a hardware especializado. Los modelos YOLO, por su parte, han demostrado ser extremadamente efectivos para la detecci´ on r´ apida y precisa de objetos, lo que es crucial para la interpretaci´ on de dibujos manuales de topolog´ ıas de red. La implementaci´ on de YOLOv8 ha sido particularmente beneficiosa, ofreciendo mejoras en velocidad y precisi´ on, lo que es esencial para la realizaci´ on de detecciones en tiempo real necesarias para este proyecto. En conjunto, la integraci´ on de estas tecnolog´ ıas avanzadas en nuestro proyecto no solo ha mejorado la eficiencia del proceso de digitalizaci´ on de topolog´ ıas, sino que tambi´ en ha establecido un marco robusto para futuras investigaciones y desarrollos en el campo de la visi´ on por ordenador aplicada a redes de telecomunicaciones. Cap´ıtulo 3. Tecnolog´ıas A continuaci´ on se describen las herramientas y tecnolog´ ıas utilizadas en el desarrollo del proyecto. 3.1. AWS Amazon Web Services(AWS)1, es una plataforma de servicios en la nube ofrecida por Amazon. Proporciona una amplia gama de servicios de infraestructura en la nube, como almacenamiento, c´ omputo, bases de datos, redes y muchas otras herramientas y servicios, que permiten construir y ejecutar aplicaciones de manera eficiente y rentable. Una de las ventajas clave de AWS es su flexibilidad y escalabilidad. Gracias a la pol´ ıtica de pago por uso, se pueden escalar los recursos de manera r´ apida y sencilla, permitiendo adaptarse a las fluctuaciones de la demanda sin tener sobrecoste. Se ofrecen una amplia gama de servicios entre los que se incluye almacenamiento de objetos (Amazon S3) y computaci´ on en la nube (Amazon Lambda), que usaremos en nuestro proyecto. 3.1.1. Amazon Lambda AWS Lambda2es un servicio de computaci´ on basado en eventos y sin servidor que permite ejecutar c´ odigo para casi cualquier aplicaci´ on o servicio de backend sin tener que preocuparse por gestionar o aprovisionar servidores. 3.2. GNS3 GNS3 (Graphic Network Simulation o Simulaci´ on Gr´ afica de Redes)3 es un software de c´ odigo abierto de simulaci´ on de redes que permite dise˜ nar topolog´ ıas de red complejas. Esta herramienta permite crear redes virtuales completas y emular dispositivos de red, como routers, switches y firewalls, sin necesidad de tener acceso f´ ısico a los equipos reales. 1https://aws.amazon.com/es/what-is-aws/ 2https://aws.amazon.com/es/lambda/ 3https://www.gns3.com/ 19 26 Figura 4.1: Herramienta de etiquetado de im´ agenes Figura 4.2: Conjunto de datos iniciales etiquetados 27 Con Roboflow, se ha logrado un conjunto de datos de 136 im´ agenes, partiendo de 80 dibujos originales que han sido etiquetados manualmente. Sin embargo, dado que este volumen inicial no es suficiente para entrenar adecuadamente el modelo, se han aplicado t´ ecnicas de aumento de datos, como rotaciones y otras transformaciones, para generar im´ agenes adicionales a partir de las 80 originales. Tambi´ en se ha aplicado un preprocesamiento para convertir todas las im´ agenes a escala de grises, garantizando la uniformidad del dataset. Figura 4.3: Preprocesado y asignacion de datos Este proceso nos permiti´ o obtener un conjunto de datos consistente, necesario para el entrenamiento del modelo destinado a interpretar dibujos de topolog´ ıas de red manuscritos. 4.2. Modelos Una vez que se dispone de un conjunto de datos de entrenamiento adecuado, el siguiente paso es experimentar con diferentes modelos 28 de aprendizaje autom´ atico para encontrar el que ofrezca el mejor rendimiento. Como se mencion´ o en el cap´ ıtulo sobre las tecnolog´ ıas utilizadas (3), Roboflow permite la integraci´ on directa del dataset con plataformas de experimentaci´ on como Google Colab. Gracias a esta integraci´ on, hemos podido realizar pruebas y ajustes en los modelos YOLOv4 Darknet, YOLOv5 y YOLOv8. Para poder explicar las conclusiones y el modelo que mejor se ha adaptado a nuestro caso de uso, vamos a desarrollar como est´ a compuesta la arquitectura YOLO, y las diferencias entre las versiones que han sido utilizadas. 4.2.1. YOLOv4 Darknet YOLOv41se divide en tres partes principales: Backbone, Neck, y Head. Backbone: Es la base del modelo, encargada de extraer caracter´ ısticas de la imagen. Usa CSPDarknet53 como componente principal y est´ a preentrenada en ImageNet y es responsable de extraer caracter´ ısticas clave de las im´ agenes de entrada. Este Backbone tiene la tarea de identificar patrones, bordes y formas b´ asicas en la imagen, que luego ser´ an utilizadas para detectar los componentes. Neck: utiliza PANet, que act´ ua como un conector entre el Backbone y el Head. Su funci´ on es procesar las caracter´ ısticas extra´ ıdas por el Backbone y prepararlas para la detecci´ on final. Head: Esta es la parte final del modelo, donde se realiza la detecci´ on real de objetos. Toma la informaci´ on procesada por el Backbone y el Neck y determina la ubicaci´ on y la clase de los objetos en la imagen. El Head utiliza la estructura de YOLOv3 para hacer las detecciones finales y las clasificaciones. Este segmento es responsable de predecir las clases y los cuadros delimitadores de los objetos. 1https://docs.ultralytics.com/es/models/yolov4/ 29 Figura 4.4: Esquema de la arquitectura de YOLOv4 4.2.2. YOLOv5 Tanto YOLOv4 como YOLOv5 2comparten el concepto de Backbone, Neck y Head. Sin embargo, en YOLOv5 se introducen algunas optimizaciones y simplificaciones. Backbone: YOLOv5 tambi´ en usa una versi´ on modificada de CSPDarknet53, pero con optimizaciones que simplifican la implementaci´ on y mejoran la eficiencia computacional. Esto se traduce en una estructura m´ as ligera y r´ apida. Neck: Es similar pero incluye mejoras como SPPF (Spatial Pyramid Pooling Fast), que ayuda a extraer caracter´ ısticas a diferentes escalas de manera m´ as eficiente. Se simplifica la estructura CSPDarknet53-PANet, contribuyendo a una implementaci´ on m´ as ligera. Head: YOLOv5 mantiene un enfoque similar pero con optimizaciones para hacer la estructura m´ as ligera y r´ apida, reduciendo la latencia. 4.2.3. YOLOv8 YOLOv8 incorpora mejoras significativas tanto en precisi´ on como en velocidad [19], adem´ as de la posibilidad de utilizar detecci´ on sin anclajes (anchor-free). Los anclajes son cajas delimitadoras que se utilizan para la predicci´ on de los objetos. En otras versiones de YOLO, estas cajas se ubican en lugares predefinidos sobre la imagen y se van ajustando sus medidas seg´ un va avanzando el entrenamiento. YOLOv8 predice directamente las coordenadas de las cajas delimitadoras sin depender de anclajes espec´ ıficos. 2https://docs.ultralytics.com/yolov5/tutorials/architecture_description/ 30 Backbone: En esta versi´ on, adem´ as de CSPDarknet53 se utiliza EfficientDet. Ambos aportan una gran capacidad de aprendizaje y eficiencia. Neck: YOLOv8, al igual que YOLOv5 utiliza PANet, pero la estructura de YOLOv8 permite una mejor combinaci´ on de caracter´ ısticas, lo que puede mejorar la precisi´ on en detecci´ on de objetos de diferentes tama˜ nos. Head: Se mantiene el uso de cajas ancladas para predecir objetos de diferentes formas y tama˜ nos, permitiendo tanto detecci´ on con anclajes como detecci´ on sin anclajes (anchor-free). YOLOv5, por el contrario, utiliza un enfoque tradicional basado en anclajes. 4.3. Estudio comparativo de YOLO e interpretaci´on Una vez realizado el estudio sobre las diferentes versiones de YOLO, se ha procedido a la experimentaci´ on. El primer modelo que se ha entrenado ha sido YOLOv4 con el framework de Darknet. El proceso de configuraci´ on y entrenamiento de YOLOv4 ha sido muy tedioso por varias razones. Debido a que YOLOv4 dej´ o de recibir actualizaciones oficiales despu´ es de 2020, muchas de las herramientas y bibliotecas est´ an obsoletas. Por ejemplo, algunas dependencias clave, como OpenCV y CUDA, han evolucionado a versiones que no son compatibles con el c´ odigo base de Darknet, lo que ha generado conflictos al intentar compilar el proyecto. Hemos tenido que modificar muchas variables en el Makefile para ajustar la configuraci´ on a nuestro entorno de trabajo, como rutas de archivos, opciones de compilaci´ on, configuraci´ on de la GPU y alguna variable que no estaba definida. Otro problema importante ha sido el coste computacional. El modelo YOLOv4 es bastante pesado y requiere un alto nivel de recursos para entrenamiento. En el notebook que nos proporcionaba Roboflow, la configuraci´ on predeterminada ten´ ıa par´ ametros configurados para ser ejecutados en un entorno con recursos significativos. Sin embargo, al intentar entrenar este modelo en la versi´ on gratuita de Google Colab, nos encontramos con limitaciones severas en la GPU y restricciones de tiempo de ejecuci´ on. Debido a estas restricciones, el entrenamiento no solo era lento, sino que a menudo era interrumpido 31 por restricciones de tiempo o limitaciones de recursos como se puede ver en la figura 4.5. Pese a haber intentado entrenarlo de la mejor manera posible nos hemos dado cuenta que era mejor idea explorar versiones m´ as recientes de YOLO, como YOLOv5, que se basan en frameworks m´ as recientes y tienen mejor soporte. El cambio a estas versiones m´ as modernas nos permiti´ o beneficiarnos de una comunidad m´ as activa, documentaci´ on actualizada y un mejor rendimiento en entornos de nube con limitaciones de recursos. Figura 4.5: Limitaci´ on Google Colab en entrenamiento con YOLOv4 El entrenamiento con YOLOv5 utilizando un dataset de 136 im´ agenes ha presentado varios desaf´ ıos. Aunque YOLOv5 es m´ as moderno y flexible que YOLOv4, tuvimos que ajustar el modelo para adaptarlo a nuestro caso particular. El notebook proporcionado por Roboflow viene con una configuraci´ on predeterminada que incluye un tama˜ no de imagen de 416 p´ ıxeles, un batch de 16 y 100 ´ epocas. Estas configuraciones suelen ser adecuadas para datasets medianos o grandes, pero para nuestro peque˜ no dataset de 136 im´ agenes necesitamos ajustes adicionales para optimizar el entrenamiento y evitar el sobreajuste. Nuestra soluci´ on ha sido reducir el tama˜ no del batch a 8 y aumentar el n´ umero de ´ epocas a 250, permitiendo m´ as iteraciones sobre el mismo conjunto de datos. 32 Usar un tama˜ no de batch m´ as peque˜ no, como 8, reduce la cantidad de memoria necesaria para procesar cada paso de entrenamiento, lo que ha sido beneficioso en nuestro caso, dado que tenemos recursos limitados en Google Colab. Adem´ as, esta configuraci´ on permite al modelo tener m´ as iteraciones sobre los datos, lo cual puede ayudar a mejorar el aprendizaje. Reducir el batch a 8 ha sido un acierto, ya que permite al modelo entrenarse de manera m´ as eficiente, aunque con un tiempo de entrenamiento m´ as prolongado. Sin embargo, aumentar en exceso el n´ umero de ´ epocas incrementa el riesgo de sobreajuste. Para mitigar este riesgo, hemos implementado varias estrategias, como el aumento de datos, que aumenta la diversidad del dataset. Esta t´ ecnica fue aplicada y se describe en la secci´ on de generaci´ on del dataset 4.1. Podemos ver las gr´ aficas de evoluci´ on del entrenamiento en la figura 4.6 Figura 4.6: Gr´ aficos de evoluci´ on del entrenamiento con YOLOv5 Despu´ es de probar diferentes configuraciones de ´ epocas, concluimos que 250 era una buena opci´ on bas´ andonos en los resultados obtenidos como se ven en la figura 4.7. Estos resultados confirman que los ajustes realizados han permitido optimizar el entrenamiento sin caer en el sobreajuste, proporcionando una base s´ olida para futuras mejoras. Sin embargo, los datos no cumplen nuestras expectativas, por lo que hemos decidido probar con YOLOv8 para ver si podemos obtener resultados m´ as satisfactorios. 33 Figura 4.7: Resultados del entrenamiento con YOLOv5 Complementando las m´ etricas de los resultados obtenidos, en la figura 4.8 podemos ver ejemplos de las cajas delimitadoras predichas con YOLOv5 sobre algunas topolog´ ıas. Figura 4.8: Cajas delimitadoras predichas con YOLOv5 34 Para terminar hemos querido comprobar si existe mucha diferencia entre YOLOv5 y YOLOv8, y si era suficiente para justificar el cambio. En YOLOv8, hemos hecho ajustes muy similares a YOLOv5, modificando el n´ umero de ´ epocas y el tama˜ no del batch para optimizar el rendimiento y evitar el sobreajuste. El valor predeterminado en el notebook que proporciona Roboflow para YOLOv8 es 16 para el tama˜ no del batch y 25 para el n´ umero de ´ epocas. Dado que tenemos un dataset reducido y hemos trabajado con recursos limitados en Google Colab, ajustamos el tama˜ no del batch a 4 y aumentamos el n´ umero de ´ epocas a 50. El batch m´ as peque˜ no reduce el uso de memoria y permite m´ as iteraciones, aunque puede aumentar el riesgo de sobreajuste porque el modelo tiene m´ as tiempo para memorizar el dataset. Para mitigar este riesgo, YOLOv8 tiene una caracter´ ıstica que los anteriores no ten´ ıan. Early stopping, que detiene el entrenamiento cuando ya no hay mejoras significativas, evitando el sobreajuste. Podemos ver las gr´ aficas de evoluci´ on del entrenamiento en la figura ?? Figura 4.9: Gr´ aficos de evoluci´ on del entrenamiento con YOLOv8 Los resultados obtenidos con YOLOv8, como se ven en la figura 4.10, son muy positivos considerando el tama˜ no limitado de nuestro dataset. Estos resultados sugieren que el modelo tiene un buen rendimiento general y que estamos en el camino correcto. Con un dataset m´ as grande podr´ ıamos acercarnos a un modelo casi perfecto para nuestro caso de uso, con detecciones m´ as precisas y consistentes. 35 Figura 4.10: Resultados del entrenamiento con YOLOv8 Complementando las m´ etricas de los resultados obtenidos, en la figura 4.11 podemos ver ejemplos de las cajas delimitadoras predichas con YOLOv8 sobre algunas topolog´ ıas. Figura 4.11: Cajas delimitadoras predichas con YOLOv8 42 Figura 4.15: Inferencia del modelo en formato .txt Cada l´ ınea de este archivo representa un componente de la red, y el orden de los valores en cada l´ ınea es el siguiente: tipo de componente, coordenada x, coordenada y, ancho y altura. Los tipos de componentes pueden ser: 0 para DNS, 1 para Enlace, 2 para Router y 3 para Switch. En primer lugar, leemos las l´ ıneas del archivo y almacenamos los componentes en dos listas de diccionarios: una para guardar los Enlaces y su informaci´ on, y otra para guardar los nodos y su informaci´ on. El principal desaf´ ıo al que nos enfrentamos es determinar qu´ e elementos est´ an conectados entre s´ ı seg´ un sus coordenadas. Inicialmente, hemos desarrollado una estrategia simple como punto de partida, sobre la cual realizar mejoras incrementales. En esta primera estrategia, consideramos que cada nodo solo puede establecer conexi´ on con otro nodo si son los m´ as cercanos entre s´ ı y comparten el Enlace m´ as cercano. Primero, almacenamos el nodo m´ as cercano para cada nodo de la red en la estructura connections to elements. Esta lista de diccionarios almacena para cada identificador de nodo el nodo m´ as cercano y la distancia a ´ el. Luego, para cada nodo, buscamos el enlace m´ as cercano y almacenamos en la variable connections to Links el identificador del enlace y la distancia a´ el. Finalmente, aplicamos la estrategia mencionada anteriormente: dos nodos est´ an conectados solo si comparten el enlace m´ as cercano y son los elementos m´ as cercanos entre s´ ı. Verificamos si la conexi´ on guardada en connections to elements para cada nodo es igual a la del otro nodo y luego comprobamos si ambos nodos tienen el mismo ID de enlace en connections to Links. Si ambas condiciones se cumplen, la conexi´ on es 43 v´ alida. Aunque esta estrategia proporciona una base, la estrategia es err´ onea, ya que puede perder muchas conexiones v´ alidas. En el caso del ejemplo que estamos analizando, perdemos todas las conexiones, ya que ninguna pareja de nodos cumple con las condiciones de la estrategia. Figura 4.16: Resultado primera estrategia Tras revisar los resultados obtenidos en la figura 4.16, hemos llegado a la conclusi´ on de que depender ´ unicamente del elemento m´ as cercano no proporciona una representaci´ on completa de las conexiones entre elementos. Como respuesta a esta limitaci´ on, hemos desarrollado una nueva estrategia que emplea dos umbrales distintos: uno para los Enlaces y otro para los nodos. Este enfoque nos permite almacenar todos los nodos y Enlaces que se encuentren a una distancia menor que el umbral especificado. Adem´ as, hemos realizado modificaciones en la estructura del c´ odigo para mejorar su mantenibilidad y escalabilidad. El nuevo c´ odigo incluye una funci´ on que, dado un nodo, una lista de Enlaces o de nodos, y un umbral, devuelve los elementos de la lista que cumplen con el umbral de distancia en relaci´ on al nodo dado, como se muestra en el diagrama de la figura 4.17. Adem´ as, hemos creado una funci´ on que, al recibir las listas de elementos cercanos y Enlaces cercanos, aplica una estrategia para determinar las conexiones v´ alidas. Esta estrategia sigue un enfoque similar al anterior, pero sin la necesidad de verificar si un nodo est´ a presente en las conexiones del otro nodo. Esto se debe a que ambas conexiones se han encontrado bajo el mismo umbral. En su lugar, se verifica que ambos nodos tengan un Enlace en com´ un, 44 como se ve en la figura 4.18. Este Enlace se encuentra utilizando un umbral inferior aplicado sobre los nodos, ya que debe estar en medio de ellos. Figura 4.17: Diagrama del flujo de datos para encontrar elementos cercanos a un nodo. Figura 4.18: Diagrama de validaci´ on de conexiones seg´ un la estrategia propuesta. 45 Los resultados obtenidos con esta estrategia son significativamente mejores, como se observa en al figura 4.19. En el caso que estamos mostrando como ejemplo, son perfectos. Adem´ as, esta estrategia permite ajustar los umbrales para ser m´ as precisos. Figura 4.19: Resultado segunda estrategia A partir de esta estrategia, podemos crear el archivo final necesario para importar el proyecto en la herramienta GNS3. Este proceso consta de dos partes distintas: La primera parte se centra en establecer la configuraci´ on general, que es com´ un a todos los proyectos y abarca informaci´ on detallada en el apartado 4.4.1. La segunda parte consiste en una funci´ on que toma el identificador del nodo y su informaci´ on, y devuelve un valor con formato .json que contiene toda la configuraci´ on espec´ ıfica del nodo, tal como se describe en el apartado 4.4.1. Finalmente los valores devueltos por la funcion se a˜ naden a la parte correspondiente de la variable de las configuraciones generales y se crea el .json. 46 4.5. Despliegue en AWS La implementaci´ on de soluciones tecnol´ ogicas en la nube ha revolucionado la forma en que las organizaciones escalan y gestionan sus infraestructuras de TI. AWS, siendo l´ ıder en soluciones de cloud computing, ofrece un conjunto robusto de servicios que permiten a los desarrolladores y a las empresas implementar aplicaciones de manera eficiente y segura. El despliegue de una funci´ on Lambda en AWS no es una excepci´ on a esta revoluci´ on y constituye un ejemplo clave de c´ omo se puede aprovechar la computaci´ on en la nube para ejecutar c´ odigo en respuesta a eventos con administraci´ on autom´ atica de los recursos computacionales. Esta secci´ on detalla el proceso de configuraci´ on y despliegue de una funci´ on Lambda en AWS, comenzando con la creaci´ on y configuraci´ on de usuarios IAM, seguido por la especificaci´ on y configuraci´ on del servicio Lambda. Se enfatizar´ a la importancia de una configuraci´ on adecuada de IAM para garantizar un manejo seguro y restringido de los permisos, lo cual es crucial para la protecci´ on de los recursos en la nube y la minimizaci´ on de riesgos de seguridad. Posteriormente, se discutir´ a c´ omo configurar adecuadamente el entorno de ejecuci´ on de Lambda, incluyendo la asignaci´ on de memoria y los permisos necesarios, para asegurar que la funci´ on se ejecute de manera ´ optima y coste-efectiva. 4.5.1. Usuarios IAM La gesti´ on de identidades y accesos (IAM) es fundamental para la seguridad y la administraci´ on en AWS, ofreciendo control granular sobre qui´ en puede hacer qu´ e en cada recurso de AWS. La creaci´ on de usuarios IAM espec´ ıficos para diferentes tareas asegura que los servicios operen bajo el principio de m´ ınimo privilegio, reduciendo el riesgo de accesos no autorizados o malintencionados. Al iniciar el despliegue de una funci´ on Lambda, es primordial configurar un usuario IAM con permisos precisos que permitan gestionar Lambda y otros servicios necesarios sin exceder las capacidades requeridas. El primer paso implica crear un grupo IAM con pol´ ıticas que confieren acceso necesario para operar funciones Lambda, tales como AWSLambdaFullAccess, que permite a los usuarios gestionar funciones y recursos relacionados en Lambda. Adicionalmente, se a˜ nade la pol´ ıtica IAMFullAccess temporalmente para permitir la configuraci´ on de roles y pol´ ıticas adicionales necesarias durante la fase inicial de configuraci´ on y despliegue. La creaci´ on de un usuario dentro de este grupo y la asignaci´ on 47 de credenciales de acceso program´ atico son acciones que habilitan la interacci´ on con AWS a trav´ es de la CLI o SDK, herramientas esenciales para automatizar y gestionar aplicaciones en la nube de manera eficiente. 4.5.2. Configuraci´on de Lambda Una vez establecida la gesti´ on segura de accesos mediante IAM, el siguiente paso es configurar la funci´ on Lambda propiamente. La configuraci´ on adecuada de una funci´ on Lambda incluye especificar el entorno de ejecuci´ on, los permisos y la gesti´ on de recursos. Se selecciona un entorno de ejecuci´ on que corresponda al lenguaje de programaci´ on del c´ odigo fuente, en este caso, Python 3.8. La asignaci´ on de memoria y el tiempo de ejecuci´ on m´ aximos son configurados en seg´ un las necesidades estimadas de la funci´ on, que en este caso se establecen en 250 MB de memoria y 15 segundos de tiempo de ejecuci´ on m´ aximo, respectivamente. Para permitir que la funci´ on Lambda interact´ ue eficientemente con otros servicios de AWS sin comprometer la seguridad, se crea un rol espec´ ıfico de IAM, LambdaExecutionRole, con pol´ ıticas que otorgan los permisos necesarios para ejecutar la funci´ on. Este rol incluye pol´ ıticas como AWSLambdaBasicExecutionRole, que permite a la funci´ on escribir registros en Amazon CloudWatch, esencial para monitorizar y depurar la funci´ on. La definici´ on de estos permisos asegura que la funci´ on tenga acceso solo a los recursos que necesita, cumpliendo con las mejores pr´ acticas de seguridad. Finalmente, se procede a desplegar el c´ odigo fuente mediante AWS CLI, especificando todos los par´ ametros configurados y el rol de ejecuci´ on. Este paso es crucial porque compila y activa la funci´ on en el entorno de nube, listo para ser invocado seg´ un sea necesario. La capacidad de desplegar y gestionar funciones de manera program´ atica mediante AWS CLI no solo aumenta la eficiencia, sino tambi´ en asegura que el despliegue sea repetible y consistente, eliminando errores manuales potenciales y facilitando la integraci´ on continua y la entrega continua (CI/CD) en entornos de desarrollo profesional. Cap´ıtulo 5. Desarrollo de la arquitectura Este cap´ ıtulo detalla el desarrollo y la implementaci´ on de una serie de modelos de detecci´ on de objetos basados en las versiones mejoradas del algoritmo YOLO (You Only Look Once). Comenzaremos explorando el modelo YOLOv4, implementado en AWS Lambda para optimizar tanto costos como recursos, seguido de una transici´ on hacia YOLOv5 y finalmente YOLOv8, cada uno con mejoras significativas en eficiencia y precisi´ on. Los modelos son dise˜ nados para operar en entornos serverless, aprovechando plataformas como Google Colab y Amazon SageMaker, facilitando la integraci´ on y manejo eficiente de los recursos computacionales. Esta documentaci´ on cubre desde la configuraci´ on inicial de los datasets hasta la generaci´ on final de archivos GNS3, pasando por las etapas de entrenamiento, validaci´ on y detecci´ on, con el objetivo de proporcionar una comprensi´ on exhaustiva del proceso y las tecnolog´ ıas utilizadas. 5.1. Modelo de entrenamiento de YOLOv4 Figura 5.1: Arquitectura del modelo de YOLO V4 Darknet implementado en AWS Lambda para optimizaci´ on de costos y recursos, mostrando la interacci´ on entre los componentes principales como AWS Lambda, S3 y Google Colab. El modelo de YOLO V4 Darknet es la primera arquitectura que 49 50 discutiremos. Se eligi´ o debido a su eficacia comprobada en el estado del arte y su aplicaci´ on exitosa en proyectos previos usando Darknet para detecci´ on en Amazon Web Service Lambda. Este enfoque es clave para reducir costos operativos, evitando el uso de Amazon SageMaker o endpoints que incrementan los costos por tener que gestionar su creaci´ on y eliminaci´ on continuas. En nuestro enfoque, buscamos optimizar recursos al ejecutar el detector de manera nativa en YOLOv4 desde Lambda, permitiendo procesamientos paralelos para manejar m´ ultiples detecciones y la generaci´ on simult´ anea de archivos GNS3. Para implementar esto, utilizamos un notebook generado por RoboFlow, que se puede adaptar tanto en SageMaker como en Google Colab. Este notebook se conecta a nuestra API para descargar modelos etiquetados, preparados especialmente para YOLOv4 a partir de elementos previamente dibujados a mano. Antes de iniciar el entrenamiento, estos datos se cargan en el notebook, donde se realiza el proceso de entrenamiento. Una limitaci´ on observada es que, mientras SageMaker completa el entrenamiento aunque sea lento, Google Colab frecuentemente no concluye este proceso, resultando en modelos de baja calidad debido al principio de ”garbage in, garbage out”. Esto subraya la importancia de la calidad de los datos de entrada. No obstante, el entrenamiento exitoso genera un modelo que se almacena en un bucket S3 en AWS, esencial para operar el modelo de YOLOv4 en Lambda, que requiere un archivo de pesos espec´ ıfico. El sistema est´ a configurado para que, al recibir una imagen a trav´ es de una API o un bucket S3, se active un disparador que carga el modelo de S3 para realizar la detecci´ on. Los resultados se depositan en un archivo .txt que se puede procesar posteriormente para refinar los resultados y generar un archivo GNS3 preciso. 5.2. Modelo de entrenamiento de YOLOv5 El modelo YOLOv5 representa una evoluci´ on en nuestros esfuerzos de optimizaci´ on tras experimentar con YOLOv4. Este modelo se ha seleccionado dentro del estado del arte por su capacidad para realizar un gran n´ umero de detecciones eficientes con un conjunto limitado de datos, ideal dado que nuestro dataset fue creado manualmente y es de tama˜ no reducido. La optimizaci´ on de recursos es crucial, ya que carecemos de acceso a hardware avanzado como GPU o TPU para un entrenamiento 51 Figura 5.2: Esquema del modelo YOLOv5 implementado en plataformas de computaci´ on en la nube, ilustrando la estructura de datos y el flujo de entrenamiento y detecci´ on. eficiente localmente, lo que nos lleva a utilizar plataformas como Google Colab y Amazon SageMaker para minimizar costos y aprovechar sus capacidades computacionales. Iniciamos el proceso de entrenamiento con archivos proporcionados por RoboFlow, que esta vez incluyen una estructura organizada en dos carpetas principales: una para etiquetas y configuraciones, y otra para los datos de entrenamiento, validaci´ on y test, distribuidos en tres subcarpetas separadas. Este formato facilita la gesti´ on y uso de las im´ agenes en las etapas sucesivas. Los datos son cargados a trav´ es de una API a un cuadernillo que es compatible tanto con SageMaker como con Google Colab, produciendo resultados similares en t´ erminos de tiempo y eficacia. Para esta arquitectura, hemos optado por utilizar Google Colab debido a su accesibilidad sin costo. El modelo resultante no es un archivo de pesos convencional, sino un archivo .pt compatible con PyTorch, lo cual implica un cambio significativo en la gesti´ on del modelo. Dado que YOLOv5 no se integra directamente en las funciones Lambda de AWS debido a las exigencias de hardware, como una GPU, para su funcionamiento ´ optimo, nos enfrentamos a restricciones en la implementaci´ on directa en AWS Lambda. La soluci´ on provisional ha sido utilizar Amazon SageMaker o Google Colab para recibir este modelo y realizar las detecciones, generando un archivo .txt que puede ser procesado posteriormente en una funci´ on 58 YOLO para ver su evoluci´ on. Finalmente, hemos experimentado con YOLOv8, realizando ajustes similares a los de YOLOv5 en los par´ ametros de entrenamiento. Se ha configurado un tama˜ no de batch m´ as peque˜ no y se ha aprovechado la funci´ on de early stopping para detener el entrenamiento cuando no se observaran mejoras significativas. Los resultados obtenidos han sido positivos, demostrando un buen rendimiento del modelo para el tama˜ no limitado del dataset. La pen´ ultima fase del proyecto ha sido la interpretaci´ on de las salidas de los modelos que supuso la implementaci´ on de estrategias para validar conexiones entre los elementos de la red a partir de sus coordenadas. Tambi´ en, la generaci´ on del archivo final para GNS3 implic´ o el estudio y dise˜ no del archivo que quer´ ıamos dar como salida en formato .gns3. Para finalizar, hemos probado los modelos YOLO con todos los archivos del dataset y para generar los archivos en base a estos, tambi´ en se han realizado de forma paralela 6 generaciones de topolog´ ıas para comprobar si sal´ ıan de forma correcta corriendo la funci´ on lambda varias veces con los mismos datos de detecci´ on. Estas pruebas han permitido validar la eficacia de nuestras estrategias y ajustes, garantizando la capacidad del sistema para manejar m´ ultiples tareas de forma simult´ anea y efectiva. 6.2. Evaluaci´on del Rendimiento de los Modelos de Detecci´on La selecci´ on y optimizaci´ on de modelos de detecci´ on de objetos son cruciales para el ´ exito de proyectos que involucran visi´ on por computadora, especialmente en aplicaciones que requieren la transformaci´ on de datos visuales complejos en representaciones digitales procesables. En este proyecto, se evaluaron tres modelos avanzados: YOLOv4 Darknet, YOLOv5 y YOLOv8. Cada uno de estos modelos ofrece caracter´ ısticas ´ unicas en t´ erminos de precisi´ on, velocidad y consumo de recursos computacionales. 6.2.1. Evaluaci´on de YOLOv4 Darknet Aunque YOLOv4 ha sido reconocido por su alta precisi´ on en la detecci´ on de objetos, nos enfrentamos a desaf´ ıos significativos debido a la obsolescencia de algunas bibliotecas y a la intensidad de recursos requerida para su entrenamiento. Este modelo mostr´ o una alta precisi´ on en la detecci´ on, pero su configuraci´ on y el ambiente de entrenamiento en 59 Google Colab limitaron su aplicabilidad debido a restricciones de tiempo y memoria. 6.2.2. Transici´on y Optimizaci´on con YOLOv5 Al experimentar con YOLOv5, observamos mejoras en la velocidad de entrenamiento y una gesti´ on m´ as eficiente de los recursos computacionales. Este modelo permiti´ o una mayor flexibilidad en la adaptaci´ on de los par´ ametros, como el tama˜ no del batch y el n´ umero de ´ epocas, para evitar el sobreajuste y mejorar la generalizaci´ on del modelo. Los resultados fueron prometedores, ofreciendo un balance adecuado entre precisi´ on y velocidad, adecuado para nuestro conjunto de datos de tama˜ no moderado. 6.2.3. Implementaci´on de YOLOv8 La introducci´ on de YOLOv8 marc´ o un avance significativo, especialmente en t´ erminos de eficiencia operativa y manejo de recursos. La capacidad de YOLOv8 para detener autom´ aticamente el entrenamiento cuando no se observan mejoras significativas (early stopping) optimiz´ o el uso de la nube, minimizando los costos computacionales sin sacrificar la calidad de la detecci´ on. 6.2.4. Comparaci´on de Modelos y Selecci´on Final La comparativa entre los modelos demostr´ o que YOLOv8 es el m´ as adecuado para aplicaciones que requieren una alta eficiencia en tiempo real y un manejo ´ optimo de recursos. Sin embargo, la elecci´ on del modelo adecuado debe considerar tanto el contexto de aplicaci´ on espec´ ıfico como las limitaciones de recursos. En nuestro caso, YOLOv8 proporcion´ o el mejor equilibrio, preparando el proyecto para una implementaci´ on m´ as amplia y eficiente. Esta evaluaci´ on del rendimiento no solo fundamenta nuestra selecci´ on de modelo, sino que tambi´ en contextualiza la discusi´ on sobre los costos operativos que se explorar´ an en la siguiente secci´ on, destacando c´ omo la eficiencia del modelo influye directamente en la viabilidad econ´ omica del proyecto. 6.3. Aproximaci´on de Costes para Funci´on Lambda Dado que los precios de AWS son variables, es vital realizar una aproximaci´ on de costes para la planificaci´ on presupuestaria. Para una funci´ on Lambda con 250 MB de memoria y una duraci´ on m´ axima de 15 60 segundos, procedemos a calcular los costos asociados. 6.3.1. C´alculo de Costos Los costos de AWS Lambda se descomponen en costo por petici´ on y costo por c´ omputo. El c´ alculo se puede representar de la siguiente manera: Costo Funci´ on Lambda =Costo por Petici´ on +Costo por C´ omputo Funci´ on (250 MB, 15 s) =n 106×0,2 +250 1024 ×15×n×0,00001667 donde nrepresenta el n´ umero de ejecuciones de la funci´ on. 6.3.2. An´alisis de Costos Para una mejor visualizaci´ on de estos costos, proporcionamos una tabla resumen con los costos estimados para un lote de procesamiento de 1000 archivos: Cuadro 6.1: Resumen de Costos y Tiempos para un Lote de Procesamiento (1000 archivos en total) Funci´on Tiempo (s) Costo (USD) Funci´ on Lambda (Procesamiento) 15 $0.06125 Total 15 $0.06125 6.3.3. Discusi´on Los costos calculados arrojan luz sobre la eficiencia y viabilidad econ´ omica de utilizar AWS Lambda para el procesamiento serverless en nuestro proyecto. A pesar de la baja tarifa unitaria, el costo total puede incrementarse significativamente con el aumento del n´ umero de ejecuciones, lo cual es cr´ ıtico para proyectos a gran escala. Estos resultados nos permiten considerar ajustes en la memoria asignada o la optimizaci´ on del tiempo de ejecuci´ on para controlar mejor los gastos operativos. 6.3.4. Conclusiones Esta aproximaci´ on nos permite anticipar el presupuesto necesario para el despliegue de funciones serverless en un entorno real, y subraya la importancia de optimizar tanto el c´ odigo como la asignaci´ on de recursos para minimizar los costos operacionales. 61 6.4. Objetivos Realizados Podemos destacar que, si bien el proyecto ha cumplido gran parte de los objetivos planteados en la introducci´ on, existen ´ areas donde a´ un se necesita trabajo adicional. El programa desarrollado ha demostrado su capacidad para interpretar dibujos de topolog´ ıas de red y generar autom´ aticamente un archivo compatible con GNS3 que representa los nodos, pero ha quedado como trabajo futuro el formateado de los Enlaces para seguir el estandar de .gns3. Aunque los objetivos no se han logrado en su totalidad, el proyecto ha sentado las bases para futuras mejoras y desarrollos. 6.5. An´alisis Cr´ıtico de los Resultados En este proyecto, se ha llevado a cabo una exploraci´ on exhaustiva de la generaci´ on autom´ atica de topolog´ ıas de red a trav´ es del reconocimiento de dibujos manuscritos, utilizando para ello modelos avanzados de detecci´ on de objetos como YOLOv4, YOLOv5 y YOLOv8. A pesar de los avances significativos y los resultados alentadores obtenidos, es importante reconocer las limitaciones y desaf´ ıos enfrentados durante el desarrollo. Uno de los principales retos ha sido la variabilidad en la calidad del reconocimiento de los dibujos, lo cual ha puesto de manifiesto la importancia de un preprocesamiento eficaz y una anotaci´ on precisa del dataset. Aunque se han hecho esfuerzos para mejorar la calidad del dataset mediante t´ ecnicas de aumento de datos y conversi´ on a escala de grises, el principio de “garbage in, garbage out” sigue siendo una barrera significativa para la optimizaci´ on del rendimiento del modelo. Adem´ as, el uso de plataformas como Google Colab y AWS Lambda ha presentado desaf´ ıos relacionados con la limitaci´ on de recursos y la gesti´ on de costos computacionales, especialmente cuando se trabaja con modelos computacionalmente demandantes como YOLOv4. Aunque las versiones m´ as recientes, como YOLOv8, han mostrado mejoras en eficiencia y rendimiento, la transici´ on de YOLOv4 a YOLOv8 ha requerido ajustes significativos en los par´ ametros de entrenamiento y configuraci´ on. 62 6.6. Trabajo Futuro Mirando hacia el futuro, hay varias ´ areas de mejora y expansi´ on que podr´ ıan enriquecer a´ un m´ as este proyecto. Primero, se propone la expansi´ on del dataset con m´ as dibujos y variaciones para mejorar la robustez del modelo frente a variaciones en los datos de entrada. Esto incluir´ ıa la exploraci´ on de t´ ecnicas adicionales de aumento de datos y la posible integraci´ on de aprendizaje semi-supervisado o no supervisado para aprovechar los datos no etiquetados. Tambi´ en ser´ ıa beneficioso explorar algoritmos alternativos de reconocimiento de objetos que puedan ofrecer un mejor equilibrio entre precisi´ on, velocidad y costos computacionales. Por ejemplo, la implementaci´ on de redes neuronales m´ as ligeras o la personalizaci´ on de modelos existentes para adaptarlos espec´ ıficamente a las necesidades y limitaciones del proyecto. Finalmente, para abordar las cuestiones de escalabilidad y gesti´ on de recursos en la nube, se recomienda una investigaci´ on m´ as profunda sobre las arquitecturas serverless y los modelos de precios en plataformas como AWS. Esto ayudar´ ıa a optimizar los costos y mejorar la eficiencia operativa del sistema propuesto. Chapter 6. Results, Measurements, and Conclusions 6.1. Methodology of Measurement and Cost Testing During this project, we explored the process from generating and preparing the dataset, through experimenting with different models, to developing strategies for interpreting the final data and uploading to AWS cloud. This work has allowed us to have an overview of the entire process involved in creating computer vision-oriented projects. The first part has been the most meticulous, as we had to generate a dataset from scratch. We used the Roboflow platform to manually label 80 drawings, which we consider a solid base on which to later generate more drawings using data-augmentation techniques. This resulted in a total of 136 images. Additionally, we pre-processed the images by converting them from grayscale to ensure uniformity in the data set and to prepare it for training the models. This process provided us with a coherent and diverse dataset for our project. The next phase of the project involved experimenting with the YOLOv4 Darknet, YOLOv5, and YOLOv8 models. The setup process for YOLOv4 was tedious due to the obsolescence of many tools and libraries, which created conflicts when trying to compile the project in Darknet. Moreover, the computational cost was high, especially when attempting to train the model on Google Colab with limited resources. In light of these difficulties, we explored newer versions like YOLOv5, which offers better support and performance in resource-limited environments. We adjusted the training parameters to tailor the model to our specific case, including reducing the batch size and increasing the number of epochs. This process also presented challenges, as we did not want to fall into overfitting with the adjustments made. The results obtained with this model were promising, but we experimented with the latest version of YOLO to see its evolution. Finally, we experimented with YOLOv8, making similar adjustments to the training parameters as with YOLOv5. We set up a smaller batch size and utilized the early stopping feature to halt training when no significant improvements were observed. The results were positive, demonstrating 63 64 good model performance given the limited size of the dataset. The penultimate phase of the project was the interpretation of the model outputs, which involved implementing strategies to validate connections between network elements based on their coordinates. Also, generating the final file for GNS3 involved studying and designing the file we wanted to output in .gns3 format. In conclusion, we tested the YOLO models with all the files in the dataset and to generate the files based on these, we also conducted six parallel generations of topologies to check if they were produced correctly by running the lambda function multiple times with the same detection data. These tests have validated the effectiveness of our strategies and adjustments, ensuring the system’s ability to handle multiple tasks simultaneously and effectively. 6.2. Performance Evaluation of Detection Models The selection and optimization of object detection models are crucial for the success of projects involving computer vision, especially in applications that require the transformation of complex visual data into processable digital representations. In this project, we evaluated three advanced models: YOLOv4 Darknet, YOLOv5, and YOLOv8. Each of these models offers unique features in terms of accuracy, processing speed, and computational resource consumption. 6.2.1. Evaluation of YOLOv4 Darknet Although YOLOv4 has been recognized for its high object detection accuracy, we faced significant challenges due to the obsolescence of some libraries and the resource intensity required for training. This model demonstrated high accuracy in detection, but its configuration and the training environment on Google Colab limited its applicability due to time and memory constraints. 6.2.2. Transition and Optimization with YOLOv5 When experimenting with YOLOv5, we observed improvements in training speed and more efficient management of computational resources. This model allowed greater flexibility in adapting parameters, such as batch size and number of epochs, to prevent overfitting and enhance model generalization. The results were promising, offering a suitable balance between accuracy and speed, appropriate for our 65 moderately sized dataset. 6.2.3. Implementation of YOLOv8 The introduction of YOLOv8 marked a significant advancement, especially in terms of operational efficiency and resource management. YOLOv8’s ability to automatically stop training when no significant improvements are observed (early stopping) optimized cloud usage, minimizing computational costs without sacrificing detection quality. 6.2.4. Model Comparison and Final Selection The comparison between the models demonstrated that YOLOv8 is most suitable for applications that require high real-time efficiency and optimal resource management. However, the choice of the right model should take into account both the specific application context and resource limitations. In our case, YOLOv8 provided the best balance, preparing the project for a wider and more efficient implementation. This performance evaluation not only substantiates our model selection, but also contextualizes the discussion on operational costs to be explored in the following section, highlighting how the efficiency of the model directly influences the economic viability of the project. 6.2.5. Cost Analysis For better visualization of these costs, we provide a summary table with the estimated costs for processing a batch of 1000 files: Cuadro 6.2: Summary of Costs and Times for a Processing Batch (1000 files total) Function Time (s) Cost (USD) Lambda Function (Processing) 15 $0.06125 Total 15 $0.06125 6.2.6. Discussion The calculated costs shed light on the efficiency and economic viability of using AWS Lambda for serverless processing in our project. Despite the low unit rate, the total cost can increase significantly with the number of executions, which is critical for large-scale projects. These results allow us to consider adjustments in memory allocation or optimization of execution time to better control operational expenses. 66 6.2.7. Conclusions This approach allows us to anticipate the budget needed for deploying serverless functions in a real environment and highlights the importance of optimizing both the code and resource allocation to minimize operational costs. 6.3. Achieved Objectives It should be noted that, while the project has met many of the objectives set out in the Introduction, there are areas where additional work is needed. The developed program has demonstrated its ability to interpret network topology drawings and automatically generate a GNS3 compatible file that represents the nodes, but future work remains to be done on the formatting of the Links to follow the .gns3 standard. Although the objectives have not been fully achieved, the project has laid the groundwork for future improvements and developments. 6.4. Critical Analysis of Results In this project, an exhaustive exploration of the automatic generation of network topologies through the recognition of handwritten drawings was carried out, utilizing advanced object detection models such as YOLOv4, YOLOv5 and YOLOv8. Despite significant advances and encouraging results obtained, it is important to recognize the limitations and challenges encountered during development. One of the main challenges has been the variability in the quality of the drawings’ recognition, which has highlighted the importance of effective preprocessing and accurate dataset annotation. Although efforts have been made to improve the quality of the data set using data augmentation techniques and conversion to grayscale, the principle of “garbage in, garbage out” remains a significant barrier to optimizing model performance. Moreover, the use of platforms like Google Colab and AWS Lambda has presented challenges related to resource limitations and the management of computational costs, especially when working with computationally demanding models such as YOLOv4. Although newer versions, such as YOLOv8, have shown improvements in efficiency and performance, the transition from YOLOv4 to YOLOv8 required significant adjustments in training parameters and configurations. 67 6.5. Future Work Looking ahead, there are several areas of improvement and expansion that could further enrich this project. First, an expansion of the dataset with more drawings and variations is proposed to enhance the model’s robustness against variations in input data. This would include exploring additional data augmentation techniques and the potential integration of semisupervised or unsupervised learning to leverage unlabeled data. It would also be beneficial to explore alternative object recognition algorithms that might offer a better balance between accuracy, speed, and computational costs. For example, implementing lighter neural networks or customizing existing models to specifically suit the needs and limitations of the project. Finally, to address issues of scalability and resource management in the cloud, further research on serverless architectures and pricing models on platforms like AWS is recommended. This would help optimize costs and improve the operational efficiency of the proposed system.