diseño evolutivo de arquitecturas de deep learning para...

Escuela Técnica Superior de Ingenieros

Informáticos

Universidad Politécnica de Madrid

Diseño evolutivo de arquitecturas deDeep Learning para detección de vías

de transporte.

Trabajo Fin de MásterMáster Universitario en Inteligencia Artificial

AUTOR: Víctor de la Fuente CastilloTUTORES: Francisco Serradilla García y

Javier de Lope Asiaín

ii

2019

Agradecimientos

Me gustaría agradecer a Francisco Serradilla su labor como mentor y su constanciay paciencia como amigo. Gracias también al resto de miembros del grupo Mercator,en especial a Miguel Ángel Manso y Ramón Alcarría, por su colaboración en elproyecto. Al Instituto Geográfico Nacional por financiarlo y ayudar a impulsar lainvestigación en nuestro país.

Gracias a Carolina por estar siempre a mi lado en el proceso continuo de práctica yaprendizaje vital, por su paciencia, amor y atención.

Con mis padres siempre estaré en deuda por todo lo que me han dado y enseñado,además de por haber sido mis mecenas en este punto crucial de mi carrera académica.

A mi familia, a todos mis compañeros y amigos, a aquellos con los que comparto adiario la práctica de la vía, a mis gnomos, mis fantasmas y a las musas; porque mehan ayudado a ser quién no podía imaginar o no veía que ya era.

De corazón, gracias a todos.

iii

iv AGRADECIMIENTOS

Resumen

El presente trabajo explora, en el contexto de ortofotografía aérea para elmantenimiento y revisión de cartografía, la detección automática de vías detransporte mediante Deep Learning empleando técnicas evolutivas para el diseñoautomático de la arquitectura de red. Con ese propósito se han implementado: unalibrería de algoritmos genéticos guiados por gramáticas usada para el diseño de laarquitectura, una codificación propia y metagramática (para guiar la generación dearquitecturas) y una librería sobre TensorFlow capaz de realizarentrenamiento/evaluación sobre entornos multi-GPU con estimación automáticadel tamaño de lote de entrenamiento en función de la memoria disponible.

v

vi RESUMEN

Abstract

This work explores, in the context of aerial orthophoto for cartographymanagement, the automatic detection of transport ways using Deep Learning andevolutive techniques for the automatic design of the network architecture. To thatpurpose the following has been implemented: framework for grammar guidedgenetic programming used for the network architecture design, novel codingscheme and metagrammar (to guide the network architecture generation),framework over TensorFlow for multi-GPU training/evaluation with automaticestimation of training batch size for the available memory.

vii

viii ABSTRACT

Índice general

Agradecimientos iii

Resumen v

Abstract vii

1. Introducción 11.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Estado del arte 32.1. Conceptos preliminares . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2. Cronología de arquitecturas de red en ILSVRC . . . . . . . . . . . . . 52.3. Sistemas aplicados al reconocimiento en imágenes aéreas . . . . . . . 262.4. Búsqueda de arquitecturas de red . . . . . . . . . . . . . . . . . . . . 28

3. Sistemas desarrollados 353.1. Evaluación de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2. Detalles del dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3. Modelos ajustados manualmente . . . . . . . . . . . . . . . . . . . . . 40

3.3.1. Modelos evaluados . . . . . . . . . . . . . . . . . . . . . . . . 403.3.2. Entorno de pruebas . . . . . . . . . . . . . . . . . . . . . . . . 413.3.3. Resultados de la evaluación . . . . . . . . . . . . . . . . . . . 423.3.4. Conclusiones preliminares del primer hito . . . . . . . . . . . . 43

3.4. VBrain: Librería de Deep Learning . . . . . . . . . . . . . . . . . . . 453.4.1. Estimación del tamaño de lote máximo para entrenamiento . . 49

3.5. V3gie: Librería GGGP . . . . . . . . . . . . . . . . . . . . . . . . . . 503.6. VGNet: Diseño de arquitecturas RNA mediante GGGP . . . . . . . . 52

3.6.1. Codificación: Expresiones estructurales . . . . . . . . . . . . . 533.6.2. Generación automática de código . . . . . . . . . . . . . . . . 593.6.3. Metagramática . . . . . . . . . . . . . . . . . . . . . . . . . . 603.6.4. Función de fitness . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.7. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.7.1. Hardware empleado . . . . . . . . . . . . . . . . . . . . . . . . 673.7.2. Experimentos con 100 ejemplos por clase . . . . . . . . . . . . 68

ix

x ÍNDICE GENERAL

3.7.3. Experimentos con 800 ejemplos por clase . . . . . . . . . . . . 723.7.4. Experimentos con dataset final . . . . . . . . . . . . . . . . . 76

3.8. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903.9. Líneas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A. Anexos 95A.1. Herramienta model-trainer.py . . . . . . . . . . . . . . . . . . . . . . 95A.2. Herramienta model-evolver.py . . . . . . . . . . . . . . . . . . . . . . 97A.3. Glosario de abreviaturas y acrónimos . . . . . . . . . . . . . . . . . . 99

Bibliografía 101

Índice de figuras

2.1. Arquitectura R-CNN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Arquitectura SPPnet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3. Módulos Inception sin reducción de dimensionalidad y con ella. . . . . 92.4. Módulos ResNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5. Arquitectura Fast R-CNN. . . . . . . . . . . . . . . . . . . . . . . . . 112.6. Arquitectura Faster R-CNN. . . . . . . . . . . . . . . . . . . . . . . . 122.7. Esquema de RPN y ejemplos de detección empleando las propuestas

de RPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.8. Factorización de convoluciones. . . . . . . . . . . . . . . . . . . . . . 142.9. Módulos Inception-v3. . . . . . . . . . . . . . . . . . . . . . . . . . . 152.10. Arquitectura R-FCN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.11. Arquitectura DSSD. . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.12. Arquitectura Inception-v4, con detalle de la red Stem. . . . . . . . . . 182.13. Arquitectura Inception-ResNet (v1 y v2), con detalle de la red Stem. 192.14. Módulos Inception-ResNet-v2. . . . . . . . . . . . . . . . . . . . . . . 192.15. Ejemplo de convolución 3× 3 deformable. . . . . . . . . . . . . . . . 202.16. Ejemplo de bloque DenseNet. . . . . . . . . . . . . . . . . . . . . . . 212.17. Arquitectura DPN propuesta por los autores en dos formas equivalentes. 212.18. Comparación de módulos ResNet y ResNeXt. . . . . . . . . . . . . . 222.19. Estructura FractalNet genérica y casos de ejemplo. . . . . . . . . . . 232.20. Ejemplos de ejecución de drop-path (local y global) para módulo

FractalNet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.21. Ejemplo de segmentación de una imagen empleando Mask R-CNN. . 242.22. Ejemplo de FPN que detalla la conexión lateral que combina sumando. 252.23. Ejemplo de bloque SE. . . . . . . . . . . . . . . . . . . . . . . . . . . 262.24. Variantes de módulos empleando unidades SE. . . . . . . . . . . . . . 272.25. Deep Solar arquitectura de clasificación. . . . . . . . . . . . . . . . . 282.26. Arquitectura NAS con RL. . . . . . . . . . . . . . . . . . . . . . . . . 292.27. Arquitectura NAS con RL, controlador RNN. . . . . . . . . . . . . . 292.28. Arquitectura NAS con RL, controlador RNN con árboles de operadores. 302.29. Arquitectura NASNet para los datasets CIFAR-10 e ImageNet. . . . . 312.30. Ejemplo del funcionamiento del controlador del espacio de búsqueda

NASNet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.31. Representación jerárquica de HierarchyEvo. . . . . . . . . . . . . . . 33

xi

xii ÍNDICE DE FIGURAS

2.32. Arquitecturas empleadas por HierarchyEvo. . . . . . . . . . . . . . . 33

3.1. Ejemplos de imágenes que no contienen vías. . . . . . . . . . . . . . . 383.2. Ejemplos de imágenes que contienen vías con su cartografía asociada

(color indica tipo de vía). . . . . . . . . . . . . . . . . . . . . . . . . . 393.3. Arquitectura Base del modelo CNN-PC. . . . . . . . . . . . . . . . . 413.4. Modelos ajustados manualmente. Resultados de accuracy en test

evaluados con k-fold (k=10). . . . . . . . . . . . . . . . . . . . . . . . 433.5. Modelos ajustados manualmente. Resultados de RMS en test

evaluados con k-fold (k=10). . . . . . . . . . . . . . . . . . . . . . . . 443.6. Entrenamiento de redes con paralelismo a nivel de datos. . . . . . . . 473.7. Esquema general de funcionamiento del sistema completo. . . . . . . 533.8. Ejemplo de funcionamiento del operador de suma con padding. . . . . 553.9. Ejemplo de grafo de estructura simple. . . . . . . . . . . . . . . . . . 573.10. Ejemplo de grafo de estructura con conexión residual. . . . . . . . . . 583.11. Ejemplo de grafo de estructura con conexiones tipo Inception-ResNet

o DPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.12. Evolución por generación en experimentos con 100 primeros ejemplos

con aumentación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.13. Ejemplo de red con oscilaciones en métricas debidas a diferencias en

el contexto de evaluación. . . . . . . . . . . . . . . . . . . . . . . . . 723.14. Evolución por generación en experimentos con 800 ejemplos con

aumentación de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . 733.15. Entrenamiento del mejor individuo con 800 ejemplos por clase, test 1

(generación 10 modelo 17). . . . . . . . . . . . . . . . . . . . . . . . . 763.16. Sobreajuste en arquitecturas no puramente convolucionales: 800

ejemplos por clase, test 1. . . . . . . . . . . . . . . . . . . . . . . . . 773.17. Evolución por generación en experimentos con 2.5k y 3.3k ejemplos

por clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.18. Evolución por generación en experimentos con 2.5k y 3.3k ejemplos

por clase, metagramática v3. . . . . . . . . . . . . . . . . . . . . . . . 813.19. Modelo test2 gen3model6. . . . . . . . . . . . . . . . . . . . . . . . . 833.20. Modelo test3 gen17model6. . . . . . . . . . . . . . . . . . . . . . . . . 833.21. Modelo test5 gen9model3. . . . . . . . . . . . . . . . . . . . . . . . . 843.22. Modelo test6 gen18model37. . . . . . . . . . . . . . . . . . . . . . . . 853.23. Modelo test6 gen17model38. . . . . . . . . . . . . . . . . . . . . . . . 853.24. Ejemplos de imágenes que contienen vías parcial o totalmente ocultas

por los árboles y errores de etiquetado. . . . . . . . . . . . . . . . . . 893.25. Modelo test6gen17model38. Oscillaciones debidas a BN en el

Accuracy en test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Índice de tablas

2.1. Arquitectura Inception-v3. . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1. Estructura base de CNN-PC empleada para los modelos ajustadosmanualmente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2. Modelos ajustados manualmente. Hiperparámetros de cada modelo. . 423.3. Modelos ajustados manualmente. Resultados de RMS y accuracy

detallados (evaluados por kfold=10). . . . . . . . . . . . . . . . . . . 443.4. VGNet: Detalles hardware de los servidores empleados. . . . . . . . . 683.5. Parámetros de experimentos para 100 ejemplos por clase con

aumentación de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . 693.6. Parámetros de experimentos para 800 ejemplos por clase con

aumentación de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . 723.7. Efecto de un límite de tiempo de entrenamiento demasiado reducido:

ejemplos de test 2 generación 1. . . . . . . . . . . . . . . . . . . . . . 743.8. Parámetros de experimentos para 2.5k y 3.3k ejemplos por clase. . . . 783.9. Mejores resultados de experimentos con 2.5k y 3.3k ejemplos por clase. 793.10. Parámetros de experimentos para 2.5k y 3.3k ejemplos por clase,

metagramática v3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.11. Arquitecturas para 2.5k y 3.3k ejemplos por clase, metagramática v3. 823.12. Métricas de los cinco mejores modelos asociadas al conjunto de test. . 863.13. test2gen3model6: matriz de confusión asociada al conjunto de test. . . 863.14. test3gen17model6: matriz de confusión asociada al conjunto de test. . 863.15. test5gen9model3: matriz de confusión asociada al conjunto de test. . . 873.16. test6gen18model37: matriz de confusión asociada al conjunto de test. 873.17. test6gen17model38: matriz de confusión asociada al conjunto de test. 873.18. test6gen17model38 Oscilaciones en métricas de test y relación con BN. 91

xiii

xiv ÍNDICE DE TABLAS

Capítulo 1

Introducción

1.1. Contexto

El presente Trabajo Fin de Máster (TFM) se desarrolla como parte del proyectoCartobot dentro del convenio entre la Universidad Politécnica de Madrid (UPM), através del grupo de Investigación Mercator, y el Instituto Geográfico Nacional (IGN).Dicho convenio incluye la investigación de nuevas metodologías de descubrimientode cambios en el territorio mediante la utilización de técnicas no convencionales.Uno de los objetivos del proyecto es estudiar la viabilidad de los métodos de DeepLearning para la detección de cambios en la información geográfica de referencia dela Base Topográfica Nacional a Escala 1:25.000 (BTN25) a partir de imágenes delPlan Nacional de Ortofotografía Aérea (PNOA).

1.2. Objetivos

De cara al presente TFM el interés principal del IGN es ser capaces de detectarsituaciones en las cuales la cartografía de BTN25 no coincide con las imágenes dePNOA, con el fin de identificar cambios, nos centramos en la detección de víasde transporte (autopistas, carreteras, caminos, etc). Es importante mencionar queel conjunto de datos de PNOA etiquetados y empleados para el proyecto se hagenerado en el proyecto Cartobot desde cero y evolucionará durante todo la duracióndel convenio, esto ha llevado a tener que ir desarrollando el TFM en cada una desus fases con distintas versiones del dataset a medida que estas se encontrabandisponibles y dar la retroalimentación en cada momento de cómo mejorarlo.

Los objetivos definidos son los siguientes:

Revisión del estado del arte ("State of The Art" o SoTA) sobre arquitecturasde redes de neuronas artificiales empleadas para reconocimiento de imágenesy diseño automático de arquitecturas.

1

2 CAPÍTULO 1. INTRODUCCIÓN

Ajuste manual de un primer modelo de red para la detección de vías detransporte (autopistas, carreteras y caminos) en imágenes de PNOAevaluado mediante k-fold sobre el dataset inicial.

Desarrollo de una librería para entrenar y evaluar los modelos en entornos conmúltiples Unidades de Proceso de Gráficos (GPUs).

Desarrollo de una librería para el diseño de los modelos de red empleadosde forma automática mediante el uso de algorítmos genéticos guiados porgramática.

Diseño de un lenguaje expresiones para la de definición de redes y unametagramática de arquitecturas de red para clasificación de imágenes.

Empleo del sistema anteriormente descrito para la obtención de redes dedetección de vías de transporte.

Estudio de los resultados obtenidos y valoraciones en relación al dataset decara a su mejora.

Capítulo 2

Estado del arte

La presente sección contiene una revisión de las distintas arquitecturas de redempleadas (incluyendo aquellas necesarias para su comprensión al nivel de detallenecesario) por los sistemas situados en los primeros puestos del Imagenet LargeScale Visualization Recognition Challenge (ILSVRC) (Russakovsky y col. 2015)desde el año 2012 al 2017 (actualmente el dataset se encuentra en la web deKaggle). Posteriormente se extiende la revisión a sistemas aplicados en el contextode reconocimiento sobre imágenes de fotografía aérea.

2.1. Conceptos preliminares

Antes de comenzar con la revisión del estado del arte vamos a repasar muybrevemente algunos conceptos preliminares.

Rectified Linear Unit (ReLU): Es una función de activación ampliamenteutilizada en el contexto de Deep Learning que se calcula mediante la fórmula f(x) =max(0, x). Cuenta entre sus ventajas con una eleva velocidad de cálculo (debido a susimplicidad) y ayuda además a paliar el problema del desvanecimiento de gradientesque se produce en redes profundas. No obstante para valores inferiores a x = 0 lafunción tiene un gradiente cero. Se suele denominar a aquellas unidades ReLU quese encuentran en ese estado como "muertas" o "dead ReLU" (no pueden aprender).

leaky Rectified Linear Unit (leaky-ReLU o lReLU): Esta unidad intentapaliar el problema de las ReLU muertas. Por encima de x = 0 se comporta igualque ReLU pero por debajo devuelve w · x (obteniendo así una pequeña pendientepara valores típicos de w de 0.01 o 0.02).

Softmax: Es una función frecuentemente empleada en la capa de salida enproblemas de clasificación. Toma N valores reales de salida y los normaliza en unadistribución de probabilidad sobre N clases. En ese sentido cada valor de salida desoftmax estará en el intervalo [0,1] y la suma de los N valores será 1.

3

4 CAPÍTULO 2. ESTADO DEL ARTE

Softmax suele emplearse en combinación con la entropía cruzada como función decoste para entrenar la red.

Dropout (Hinton y col. 2012): Una manera de entender dropout es queteniendo el parámetro rate, cada neurona sobre la que se aplica dropout tiene unaprobabilidad=rate de ser omitida de la red (internamente TensorFlow emplea valorde salida cero en caso de omitirse y escala el valor de salida en caso contrario). Suobjetivo es prevenir el overfitting o sobreentrenamiento de la red.

Convolución: Nos centraremos en la convolución bidimensional aplicada en losmodelos revisados. Se trata de una operación con cuatro parámetros básicos descritosa continuación.

Dimensión del filtro o kernel. Pueden ser ancho y alto por separado en el casode ser estos son distintos, pero suele emplearse el mismo valor para ambos.

Número de características o canales de salida (lo denominaremosoutChannels).

Strides: puede traducirse como "pasos" y representa el tamaño del paso dedesplazamiento al ir aplicando el kernel sobre la entrada.

Padding: tipo de relleno empleado. Puede ser "SAME", que completa laentrada rellenando con ceros en caso de no disponer de un valor para unaposición (a veces se denomina padding "ZERO"), o "VALID" que no emplearelleno alguno.

La operación toma una entrada de dimensiones [batch, height, width, inChannels]y la procesa mediante un filtro o kernel de dimensiones [kernelHeight, kernelWidth,inChannels, outChannels]. A nivel conceptual emplea el filtro como una "ventana"de tamaño dimensión que desliza sobre la entrada en pasos del tamaño indicadopor strides para calcular para cada punto de entrada un número outChannels decanales o características de salida. Es importante indicar que si empleamos stridesde uno las dimensiones espaciales no variarán siempre que el padding sea "SAME"(que suele ser el valor empleado por defecto).El valor de la salida de la convolución para un punto se calcula mediante la siguienteecuación (suponiendo que los canales se encuentran en la última dimensión de losdatos de entrada).

out[b, x, y, k] =∑

di,dj ,q

kernel[di, dj, q, k]∗in[b, strides1∗x+di, strides2∗y+dj, q] (2.1)

Siendo di y dj respectivamente cada una de las posiciones del kernel de la convoluciónen sus dimensiones espaciales (las correspondientes a alto y ancho) y aplicándoseesta ventana sobre la entrada siempre que se cumplan las condiciones necesarias enfunción del tipo de padding empleado.

2.2. CRONOLOGÍA DE ARQUITECTURAS DE RED EN ILSVRC 5

Pooling: Emplea un mecanismo de ventana deslizante (con avance en pasos detamaño stride) semejante al visto en el caso de la operación de convolución paraobtener de cada posición de entrada un valor aplicando una función dada. En cadapunto se evalúa dicha función para su contexto de vecindad (entendiendo comocontexto de vecindad las posiciones adyacentes al punto en que evaluamos empleandouna ventana de dimensión dada). Tenemos dependiendo de la función empleadadistintos tipos de pooling, por ejemplo Max-pooling o Average-pooling.

Programación genética guiada por gramática o Grammar GuidedGenetic Programming (GGGP): Se trata de un tipo algoritmo evolutivo queemplea como representación de las soluciones árboles de derivación que han sidogenerados mediante una gramática formal. En ese sentido se utilizan operadores deinicialización, cruce y mutación que emplean la información contenida en dichagramática (p.ej. cruces que intercambian nodos no terminales entre los padres paragenerar descendencia gramaticalmente válida).En el caso del presente TFM se considerá un mecanismo valioso de cara introducirconocimiento de dominio además de corrección estructural en las arquitecturas deredes generadas por el algoritmo evolutivo.

2.2. Cronología de arquitecturas de red en ILSVRC

AlexNet (Krizhevsky, Sutskever e Hinton 2012). Una variante de este modeloganó primer y segundo lugar en ILSVRC-2012 (en tareas de localización [errortop5 0.342] y clasificación [error top5 0.164]). Introducen además Local ResponseNormalization (LRN) como técnica para mejorar la generalización. Detalles delmodelo (la entrada son imágenes 224× 224 RGB):

1. Convolución (Conv): 96 kernels de tamaño 11×11×3 con stride 4 y activaciónReLU.

2. LRN y Max-Pool (MP) 3× 3 con stride 2.

3. Conv: 256 kernels de tamaño 5× 5× 48 y activación ReLU.

4. LRN y MP 3× 3 con stride 2.

5. Conv: 384 kernels de tamaño 3× 3× 256, y activación ReLU.



8. Full Connected (FC): 4096 neuronas, activación ReLU y dropout (probabilidadde drop 0.5).

9. FC: 4096 neuronas, activación ReLU y dropout (probabilidad de drop 0.5)


10. FC: 4096 neuronas y activación ReLU.

11. Capa softmax: 1000 salidas.

VGG (referenciada por los autores también como ConvNet) (Simonyany Zisserman 2014). Ganó ILSVRC-2014 en clasificación+localización ordenando losresultados por error de localización (errores top5 de localización=0.253 yclasificación=0.074):

Cuatro primeras posiciones ordenando por error de localización (seguidos porGoogleLeNet).

Puestos segundo a quinto ordenando por error de clasificación (primeraposición para GoogleLeNet).

La arquitectura de red empleada es básicamente una red convolucional profunda,los tres modelos presentados a ILSCVRC-2014 tenían la siguiente estructura:

1. Diez capas convolucionales de kernel 3× 3, tres de 1× 1 y tres capas FC.

2. Trece capas convolucionales y tres FC.

3. Dieciséis capas convolucionales 3× 3 y tres FC.

Las tres versiones tienen en común:

Todas las convoluciones se aplican con stride 1 y activación ReLU.

Las capas FC usan dropout.

Se emplea MP, dependiendo del modelo cada una, dos o tres capasconvolucionales.

Region-based Convolutional Network (R-CNN) (Girshick y col. 2014) secompone de tres módulos principales (Fig. 2.1):

1. Propuesta de regiones independientes de la clase.

Producen alrededor de dos mil propuestas de regiones y el artículoespecifica que el método para obtenerlas puede variar, no obstanteemplean búsqueda selectiva.

2. Redes convolucionales para la extracción de vectores de características delongitud fija por cada clase a partir de las regiones propuestas.

Emplean AlexNet preentrenada con el dataset ILSVRC-2012.

3. Se emplean Support Vector Machines (SVM), una por clase, para laclasificación final.


Figura 2.1: Arquitectura R-CNN. Fuente: (Girshick y col. 2014).

Spatial Pyramid Pooling Network (SPPnet) (He y col. 2014) trata deeliminar la restricción de tamaño fijo de entrada que algunos modelos imponen, yque lleva a la necesidad de realizar recortes (cropping) o estiramientos (warping)que pueden producir respectivamente el riesgo de generar regiones que nocontienen el objeto completo o la aparición de distorsiones en las imágenes. En losmodelos típicos se emplean múltiples capas convolucionales seguidas de capascompletamente conexas. SPPnet inserta tras la última capa convolucional (y antesde la primera completamente conexa) una capa de Spatial Pyramid Pooling (SPP)que emplea el concepto de Spatial Pyramid Matching (Lazebnik, Schmid y Ponce2006) y genera una salida de longitud fija empleando pooling en l conjuntos(siendo l el nivel de la pirámide empleada) de subdivisiones espaciales (tambiéndenominadas bins) y concatenando sus salidas (Fig. 2.2).

Figura 2.2: Arquitectura SPPnet. Fuente: (He y col. 2014).

Highway Networks (Srivastava, Greff y Schmidhuber 2015) emplea unmecanismo inspirado en las Long-Short Term Memory (LSTM). El módulo de


construcción propuesto introduce la posibilidad de que una capa pueda combinarsu salida con la entrada que recibe mediante una implementa la funcióny = H(x,WH) · T (x,WT ) + x · C(x,WC), siendo H la operación realizada poruna capa, T (Transformation gate) la puerta aprendida para combinar la entradade dicha capa con su salida por un factor C (Carry gate). En concreto se usaC = 1− T .

GoogleLeNet (también denominada arquitectura Inception) (Szegedy y col.2015) ganó el primer puesto en ILSVRC-2014 en clasificación+localizaciónordenando por error de clasificación (error top5 clasificación=0.0665 sin realizarlocalización) y quinto puesto en clasificación+localización ordenando por error delocalización (errores top5 clasificación=0.148 y localización=0.264). Empleando unconjunto de modelos (ensemble) de detección (preentrenando con datos deILSVRC12) obtienen el primer puesto en detección de objetos (mean AveragePrecision [mAP]=0.439 y ganador en 142 categorías de objetos). El modelo empleamenos parámetros que el presentado por (Krizhevsky, Sutskever e Hinton 2012)dos años antes, a la vez que mejora la precisión del mismo.

La arquitectura Inception rompe con la idea de construir redes convolucionalesprofundas simplemente apilando capas de convolución y pooling, con el añadido dealgunas completamente conexas al final de la red. El bloque básico de construcciónes el módulo Inception que emplea múltiples caminos en paralelo a partir de unamisma entrada y concatena las salidas de dichos caminos para obtener la salida delmódulo. Se proponen dos variantes del módulo Inception con y sin reducción dedimensionalidad (empleando para ello convoluciones de 1×1) (Fig. 2.3). Nótese queal emplear stride 1 se conservan las dimensiones.

Es interesante mencionar que esta arquitectura introduce la idea de incorporarclasificadores auxiliares para mejorar la convergencia en redes de gran profundidad.Posteriormente en (Szegedy y col. 2016) se concreta que no ayudan a mejorar dichaconvergencia en etapas tempranas del entrenamiento pero si más adelante.

Resumiendo la arquitectura de GoogLeNet, ignorando los clasificadores auxiliarestenemos la siguiente estructura:

1. Conv, MP, LRN, Conv, Conv, LRN, MP

2. 2 módulos Inception apilados, MP

3. 5 módulos Inception apilados, MP

4. 2 módulos Inception apilados

5. Average pool, FC, softmax


Figura 2.3: Módulos Inception (a) sin reducción de dimensionalidad y (b) con ella.Fuente: (Szegedy y col. 2015).


Batch Normalization (BN) (Ioffe y Szegedy 2015) presenta la técnica de BNy la evalúa incorporada a la arquitectura Inception, esta variante se denomina enocasiones BN-Inception o Inception-v2 dentro de la bibliografía.

Residual Networks (ResNet) (He y col. 2016a) ganó ILSVRC-2015(empleando conjunto de modelos) tanto en detección sin emplear datos adicionales(mAP=0.621 y gana en 194 categorías de objetos) como enclasificación+localización (errores top5 de localización=0.090 yclasificación=0.356). El modelo emplea la idea de conexiones residuales de modoque cada una o más capas una conexión de identidad o atajo (algunas vecesreferida como conexión de salto) se crea desde la entrada de dichas capas hasta lasalida de las mismas para emplear la suma resultante como nueva salida.Obtenemos de este modo que la nueva salida será f(x) + x.

Se propusieron y aplicaron dos bloques estructurales para construir las redesResNet (Fig. 2.4). Uno de ellos para las variantes de 18/34 capas y otro para lasversiones de 50/101/152 capas que incorpora lo que los autores denominan"bottleneck" (cuello de botella) consistente en aplicar dos convoluciones 1× 1 parareducir/restaurar la dimensionalidad al comienzo/final del módulorespectivamente. Posteriormente en (He y col. 2016b) se estudian los efectos devariar los componentes del bloque residual.

Figura 2.4: Módulos para (a) ResNet 34 y (b) ResNet 50/101/152. Fuente: (He y col.2016a).

Fast R-CNN (Girshick 2015) es un modelo diseñado para acelerar elentrenamiento de redes convolucionales profundas aprendiendo al mismo tiempo aclasificar y localizar los objetos como se ve en (Fig. 2.5). Se probó empleandomodelos como AlexNet o VGG16 reemplazando las últimas capas(MP+FC+softmax) por la estructura definida a continuación (pasos 2 y 3).

El sistema sigue los siguientes pasos:1. Una red convolucional profunda procesa la imagen completa para obtener lo

que los autores denominan mapas convolucionales de características (convfeature maps).


Figura 2.5: Arquitectura Fast R-CNN. Fuente: (Girshick 2015).

2. Para cada propuesta de objeto una capa de pooling de Regiones de Interés(Region of Interest o RoI) produce un vector de características de longitudfija. Los autores describen esta capa como un caso concreto de SPP para unapirámide de un solo nivel.

3. Una serie de capas FC alimentan las siguientes ramas en paralelo:

FC y softmax para el número de clases a diferenciar con la adición de unaclase por defecto o catch-all class.

Capas FC que dan como salida las cuatro coordenadas de las cajas decontorno (bounding boxes) como números reales.

Faster R-CNN (Ren y col. 2015) mejora Fast R-CNN empleando una RegionProposal Network (RPN), una red completamente convolucional que genera parala imagen completa predicciones de contornos de objetos y una puntuación de comode probable es que se presente un objeto en una posición concreta (objectness scores).Para proponer k regiones se generan 4k coordenadas para los bounding boxes y 2kpara la presencia o no de objeto.

Las coordenadas de los contornos son relativos a los anclajes (anchors) que a suvez dependen del centro de la ventana deslizante empleada y tienen asociadosdos parámetros (escala y aspecto). Esto se hace para lograr invariancia a latraslación.

La RPN y la red clasificadora comparten algunas capas convoluciones. Unesquema de la arquitectura puede verse en (Fig. 2.6)

Sobre las características de la última capa compartida se ejecuta una pequeñared convolucional de dimensión de entrada n×n, empleando los autores n = 3(Fig. 2.7).

Los autores presentan además la operación de RoI pooling, que es un casoespecial de SPP con un solo nivel de pirámide.


Figura 2.6: Arquitectura Faster R-CNN. Fuente: Ross Girshick, Facebook AIResearch(FAIR). https://github.com/rbgirshick/py-faster-rcnn.

Figura 2.7: Esquema de RPN y ejemplos de detección empleando las propuestas deRPN. Fuente: (Ren y col. 2015).


Inception-v3 (Szegedy y col. 2016) emplea factorización de convolucionespara reemplazar convoluciones de dimensión superior a 3× 3 por combinaciones deconvoluciones de dimensión inferior o incluso el empleo de factorizacionesempleando convoluciones asimétricas. Un ejemplo de cada tipo de factorizacionesaplicadas puede verse en (Fig. 2.8). El motivo de dicha factorización es reducir elcoste computacional (no se tiene en cuenta la memoria adicional que puederesultar necesaria para almacenar los resultados intermedios de las convolucionesfactorizadas ni del número de características para cada una); por ejemplo losautores explican que las convoluciones de 5× 5 tienen un coste computacional 2.79veces superior a las de 3 × 3. No obstante indican que en la práctica el empleo dela factorización tipo n × n a n × 1 más 1 × n no daba buenos resultados en capastempranas.

Las tres variantes del módulo Inception presentadas Inception-v3 se pueden veren (Fig. 2.9) y la arquitectura propuesta es la mostrada en la (Tabla 2.1).

Type Patch size/stride or remarks Input size

conv 3× 3/2 299× 299× 3conv 3× 3/1 149× 149× 32conv padded 3× 3/1 147× 147× 32pool 3× 3/2 147× 147× 64conv 3× 3/1 73× 73× 64conv 3× 3/2 71× 71× 80conv 3× 3/1 35× 35× 1923× Inception (Fig. 2.9a) 35× 35× 2885× Inception (Fig. 2.9b) 17× 17× 7682× Inception (Fig. 2.9c) 8× 8× 1280pool 8× 8 8× 8× 2048linear logits 1× 1× 2048softmax classifier 1× 1× 1000

1 En algunos puntos se emplea entre módulos Inceptionreducción de dimensiones del grid mediante módulos queemplean stride=2 al final de cada subrama, antes de laconcatenación.

2 Se emplea padding cero en la convolución indicada y enlos módulos Inception que no reducen la dimensión delos datos.

Tabla 2.1: Arquitectura Inception-v3. Fuente: (Szegedy y col. 2016).

YOLO (You Only Look Once) (Redmon y col. 2016) emplea como entrada, adiferencia de modelos que emplean propuestas de regiones, la imagen completaredimensionada. La arquitectura busca ante todo la velocidad de cara a entornosde tiempo real. La red divide la imagen en una malla S × S, calcula para cadacelda B bounding boxes con su confianza asociada (x, y, w, h y confidence) y


(a) Ejemplo de convolución 5× 5 factorizadacomo dos simétricas de 3× 3.

(b) Ejemplo de convolución 3× 3 factorizadacomo dos asimétricas 3× 1 y 1× 3.

Figura 2.8: Factorización de convoluciones. Fuente: (Szegedy y col. 2016).


(a) A: Módulo para capasiniciales con factorizaciónsimétrica.

(b) B: Módulo para capasintermedias con factorizaciónasimétrica. Recomiendan n =7.

(c) C: Módulo Inception paracapas finales para generarrepresentaciones de altadimensionalidad.

Figura 2.9: Módulos Inception-v3. Fuente: (Szegedy y col. 2016).


además de C probabilidades condicionales Pr(Classi|Object) para cada celda depertenencia a una clase concreta . A nivel de arquitectura interna, se emplea unared convolucional (incluye capas de MP con stride = 2 para reducir dimensiones yconvoluciones 1 × 1 para reducir el espacio de características) y dos capas FC alfinal. La dimensión del tensor de salida es S × S × (B ∗ 5 + C).

Single Shot MultiBox Detector (SSD) (Liu y col. 2016) emplea cajas decontorno por defecto, con un par de parámetros (ratio y aspect), de forma que elsistema predice la presencia o ausencia de cada clase de objeto en dichas cajas a la vezque modifica sus parámetros para adaptarlas. A nivel de arquitectura se empleancapas de convoluciones a diferentes resoluciones combinándose las característicaspara la predicción, dichas capas se construyen sobre un modelo base (usan VGG16en sus pruebas). SSD mejora en velocidad a YOLO.

Region-based Fully Convolutional Networks (R-FCN) (Dai y col. 2016)a diferencia de Fast R-CNN o Faster R-CNN, que aplican el sistema una vez porcada región, procesa toda la imagen de una vez. Es una arquitectura convolucionalcompartida entre dos fases (Fig. 2.10): propuesta de RoIs (con RPN) y clasificaciónde dichas regiones. La última capa convolucional produce k2∗(C+1) características,siendo C el número de clases (con una adicional para el fondo) y k la dimensión deuna malla k × k que representa información en posiciones relativas (p.ej. k = 3las celdas representarían arriba-izquierda, arriba-centro, ..., abajo-derecha). Esascaracterísticas se pasan por un RoI pooling sensible a la posición (en el caso delartículo la media por cada clase) y posteriormente un softmax.

Figura 2.10: Arquitectura R-FCN. Fuente: (Dai y col. 2016).

Deconvolutional Single Shot Detector (DSSD) (Fu y col. 2017) combinaSSD con ResNet y añade al final de la arquitectura capas deconvolucionales (Fig.2.11) con la finalidad de incorporar en la detección de objetos información contextualde mayor escala.


Figura 2.11: Arquitectura DSSD. Fuente: (Fu y col. 2017).

Inception-v4 (Szegedy y col. 2017) emplea la arquitectura mostrada en (Fig.2.12) usando como módulos Inception A, B (con n = 7) y C con las estructurasvistas en (Fig. 2.9).

Inception-ResNet (v1 y v2) (Szegedy y col. 2017) surgen como resultadoevaluar la combinación de la arquitectura Inception con ResNet. TantoInception-ResNet-v1 como Inception-ResNet-v2 emplean la arquitectura que se veen (Fig. 2.13) pero en el caso de v2 la red Stem empleada es la misma queInception-v4 (Fig. 2.12). Los módulos Inception-ResNet entre ambas versionesvarían en el número de características calculadas por algunas de las convolucionespero no a nivel estructural, por ello se incluye solamente el esquema de losmódulos Inception-ResNet-v2 en (Fig. 2.14). Se indica que en este caso que pormotivos técnicos (concretamente de memoria disponible) se emplea BN solo sobrecapas tradicionales pero no sobre las sumas residuales.

Deformable Convolutional Networks (DCN) (Dai y col. 2017) añadeoffsets a las posiciones usuales de la matriz donde se muestrean los datos paracalcular las convoluciones (Fig. 2.15). De esta manera se permite realizardeformaciones libres del "campo perceptivo" de la convolución. Son unageneralización de "atrous convolutions", también denominadas convolucionesdilatadas (dilated convolutions). Sugieren emplear una convolución tradicionalpara aprender los offsets de la convolución deformable a partir de lascaracterísticas de entrada y emplear para la convolución deformable interpolaciónbilinear para muestrear el espacio de entrada. También proponen RoI poolingdeformable y presentan una variante DCN de R-FCN.

MobileNet (Howard y col. 2017) es un modelo pensado para aplicaciones devisión en dispositivos empotrados reduciendo la dimensión y coste del modelo.Emplea, con el fin de reducir el coste computacional, en lugar de convolucionestradicionales un mecanismo de factorización de las mismas que las reemplaza poruna convolución en profundidad seguida de un convolución 1 × 1 (a nivel de


Figura 2.12: Arquitectura Inception-v4, con detalle de la red Stem a la derecha. La’V’ indica el uso de padding "valid" en lugar de "same" (empleado por defecto).Fuente: (Szegedy y col. 2017).


Figura 2.13: Arquitectura Inception-ResNet (v1 y v2), con detalle de la red Stem deInception-RestNet-v1 a la derecha. La ’V’ indica el uso de padding "valid" en lugarde "same" (empleado por defecto). Fuente: (Szegedy y col. 2017).

Figura 2.14: Módulos Inception-ResNet-v2. De izquierda a derecha variantes delmódulo: A, B y C. Fuente: (Szegedy y col. 2017).


Figura 2.15: Ejemplo de convolución 3× 3 deformable. Fuente: (Dai y col. 2017).

punto).

Densely Connected Convolutional Network (DenseNet) (Huang y col.2017) es una extensión del modelo residual de ResNet que añade conexionesresiduales no solo a la salida del módulo sino a las de todos los consecutivos (Fig.2.16). No obstante a diferencia de ResNet no combina característicassumando sino concatenando. Las capas entre módulos densos se denominancapas de transición y emplean convoluciones y MP para cambiar las dimensionesde los mapas de características. El modelo presentado presenta resultados similaresa ResNet pero con bastantes menos parámetros entrenables. El factor decrecimiento hace referencia al número de características generadas por cada bloque.

Dual Path Networks (DPN) (Chen y col. 2017) proponen combinar las ideasde ResNet y DenseNet en un bloque estructural unificado. La idea es que un módulodispone de una entrada compuesta por dos rutas de datos (una residual y otra densa)(Fig. 2.17). La salida del módulo se divide en dos, sumando una parte a la rutaresidual mientras que la otra se concatena a la ruta de conexión densa.

ResNeXt (Xie y col. 2017) incorpora la idea de cardinalidad al bloque residualtipo ResNet para incrementar el número de caminos paralelos a la conexiónresidual (Fig. 2.18). Este modelo ganó el segundo puesto (usando un conjunto demodelos) en ILSVRC-2016 en la tarea de clasificación+localización (errores top5de clasificación=0.03031 y localización=0.737308).

Wide Residual Networks WRNs (Zagoruyko y Komodakis 2016) pretendenreducir el número de capas necesarias en arquitecturas ResNet mediante un


Figura 2.16: Ejemplo de bloque DenseNet de cinco capas y factor de crecimientocuatro (L = 5, k = 4). Fuente: (Huang y col. 2017).

Figura 2.17: Arquitectura DPN propuesta por los autores en dos formas equivalentes.Fuente: (Chen y col. 2017).


Figura 2.18: Izquierda: módulo ResNet. Derecha: módulo ResNeXt k = 32.Fuente: (Xie y col. 2017).

incremento en el número de características calculadas por cada convolución delbloque residual por un factor k (llamado ancho de la red, k = 1 resultaría en unbloque ResNet clásico) y añade una capa de dropout entre las convolucionales delbloque residual. Se demostró que el modelo entrenaba más rápido que una ResNettradicional con menos capas pero un número similar de parámetros a entrenar.

FractalNet (Larsson, Maire y Shakhnarovich 2016) presentan una alternativapara redes de gran profundidad sin emplear conexiones residuales (una alternativa aResNet o incluso a las Highway Networks). Los autores sugieren que pueden no sernecesarias las conexiones residuales para entrenar redes profundas de forma efectiva,sino simplemente la posibilidad de variar durante el aprendizaje la profundidadefectiva de la red.

Una red fractal se define mediante una estructura recursiva empleando lassiguientes funciones:

f1(z) = conv(z)

fC+1(z) = [fC ◦ fC ]⊕

[conv(z)]

Siendo C el ancho o número de columnas de la red resultante, ◦ indica composicióny⊕

el operador de unión (join). Se pueden emplear múltiples opciones para eloperador de unión (p.ej. concatenación o adición) si bien los autores optan poremplear la media a nivel de elementos (implica mismo número de canales ocaracterísticas). También aclaran que en la unión, a diferencia de en la arquitecturaResNet, no se da prioridad a ninguna ruta frente a otra. Los resultados equiparanen las pruebas con el dataset de ImageNet su modelo con ResNet.

Para definir una red fractal se emplean B bloques cd ancho C teniendo la redresultante una profundidad de B ∗ 2C−1.


El resultado de aplicar dicho método de construcción se aprecia con claridad en(Fig. 2.19).

Figura 2.19: Estructura FractalNet genérica, caso para C = 4 y ejemplo de redFractalNet completa. Fuente: (Larsson, Maire y Shakhnarovich 2016).

Proponen también la técnica de drop-path (Fig. 2.20), una adaptación de dropouta la arquitectura fractal aplicada antes de las uniones de forma local (cada ramatiene una probabilidad y se garantiza que en cada unión al menos una se conserve) oglobal (seleccionando una columna). En las pruebas emplean un ratio de local/globaldel 50 %.

Figura 2.20: Ejemplos de ejecución de drop-path (local y global) para móduloFractalNet con C = 4. Fuente: (Larsson, Maire y Shakhnarovich 2016).

Mask R-CNN (He y col. 2017) es una extensión de Faster R-CNN que añadeuna rama de salida para generar predicción de máscaras de segmentación de objetos


(máscara binaria con resolución a nivel de píxel) a partir de cada RoI (Fig. 2.21).

Figura 2.21: Ejemplo de segmentación de una imagen empleando Mask R-CNN.Fuente: (He y col. 2017).

Feature Pyramid Networks (FPN) (Lin y col. 2017a) emplean unaarquitectura con predicción a múltiples niveles de resolución con pasos dereducción y ampliación (downsampling y upsampling) conectados entre si al mismonivel de resolución mediante conexiones laterales de salto, empleandoconvoluciones de 1 × 1 para reducir las dimensiones de los canales (Fig. 2.22). Elmodelo es independiente de la arquitectura convolucional empleada como base,aunque se evaluó con ResNet.

RetinaNet (Lin y col. 2017b) propone Focal Loss (FL), una modificación dela entropía cruzada para reducir el peso del coste de ejemplos bien clasificados. Suobjetivo es paliar el desequilibrio extremo entre clases durante el entrenamiento. Laidea es centrar el esfuerzo de aprendizaje en conjuntos con pocos ejemplos difícilesde clasificar y muchos ejemplos fáciles. Nace de la existencia en muchos sistemas dereconocimiento visual de un gran desequilibrio en el número de ejemplos entre laclase de fondo (background class) y objetos (foreground class).

FL se calcula mediante, en caso de predicción binaria, con la fórmula: FL(pt) =−(1 − pt)

γ · log(pt) Siendo γ un parámetro que ajusta el ratio de suavizado en elcoste de ejemplos bien clasificados (se sugiere usar γ = 2). Por su parte pt toma elvalor p (la probabilidad estimada por el modelo a la clase) en caso de prediccióncorrecta y 1 − p en caso contrario. Los autores encontraron mejoras multiplicandoFL por un factor αt (un peso a nivel de clase que puede establecerse como el inversode la frecuencia de dicha clase o bien como un hiperparámetro ajustable). A nivelde arquitectura RetinaNet emplea una red FPN sobre una ResNet.

Squeeze-and-Excitation Networks (SENets) (Hu, Shen y Sun 2018) seempleó para obtener el ILSVRC-2017 los cinco primeros puestos (empleando


Figura 2.22: Ejemplo de FPN que detalla la conexión lateral que combina sumando.Fuente: (Lin y col. 2017a).


conjuntos de modelos) en clasificación+localización ordenados por error declasificación (errores top5 del mejor resultado clasificación=0.022 ylocalización=0.591). Emplean unidades Squeeze-and-Excitation como bloque deconstrucción para aprender de forma adaptativa las relaciones a nivel de canalesdel espacio de características (Fig. 2.23). Podemos observar con mayor detalle suimplementación en algunas de las variantes de módulos estructurales presentadasmostradas en (Fig. 2.24).

El sistema emplea dos pasos:

1. Squeeze, genera descriptores de canal (estadísticas globales por canal).

Implementado con Average Pooling global a nivel de canal.

2. Excitation aprende las relaciones entre canales y emplea un parámetro de ratiode reducción r para limitar la complejidad y mejorar la generalización.

Implementado con dos capas FC (con funciones de activación ReLU ysigmoide respectivamente) y posteriormente multiplicación a nivel decanal con los datos de entrada (una variante del esquema de conexiónresidual).

Figura 2.23: Ejemplo de bloque SE. Fuente: (Hu, Shen y Sun 2018).

Por otra parte se presentan y evalúan variantes modificadas de arquitecturasconocidas incorporando módulos SE, concretamente: SE-VGG, SE-Inception (Fig.2.24a), SE-ResNet (Fig. 2.24b), SE-Inception-ResNet-v2 y SE-ResNeXt.

2.3. Sistemas aplicados al reconocimiento enimágenes aéreas

Podemos encontrar numerosos casos de aplicación de entre los cuales vamos acentrarnos en dos que aparentemente suponen extremos opuestos a nivel dedimensión y complejidad estructural de las redes empleadas. Dado que una de lasfases futuras del convenio con el IGN contempla la adaptación de las tareasrealizadas en este TFM al etiquetado semántico a nivel de píxel aprovechamospara dar un contexto más específico a esta revisión de sistemas aplicados.

2.3. SISTEMAS APLICADOS AL RECONOCIMIENTO EN IMÁGENES AÉREAS27

(a)

(b)

Figura 2.24: Variantes de módulos empleando unidades SE. Fuente: (Hu, Shen y Sun2018).


En primer lugar podemos encontrar en (Volpi y Tuia 2017) un caso de aplicaciónque cubre desde la clasificación al etiquetado semántico a nivel de píxel. En dichotrabajo se preentrenan las redes con el dataset de ILSVRC para posteriormentetrabajar con el dataset "2D Semantic Labeling Contest (WG-II/4)"(http://www2.isprs.org/commissions/comm3/wg4/semantic-labeling.html).Dicho dataset contiene imágenes etiquetadas a nivel de píxel de las ciudadesalemanas de Vaihingen y Potsdam. El modelo empleado para clasificación,CNN-PC, es una red convolucional de complejidad estructural relativamente baja(solo consta de cuatro convoluciones si ignoramos normalizaciones, max pools,dropout y capa FC softmax de salida). Se detallará su estructura completa másadelante.

Prácticamente en el otro extremo de complejidad nos encontramos (Yu y col. 2018)que emplea transfer learning para adaptar un modelo Inception-V3, preentrenadouna vez más con el dataset de ILSVRC. Si ignoramos la parte de segmentación y noscentramos en la arquitectura empleada para clasificación (Inception V3, Fig. 2.25)podemos fácilmente observar la diferencia de complejidad a la que nos referíamos enla comparación con CNN-PC.

Figura 2.25: Deep Solar arquitectura de clasificación. Editado a partir de: (Yu y col.2018).

2.4. Búsqueda de arquitecturas de red

El problema de la búsqueda de arquitecturas de red (NAS, Network ArchitectureSearch), se ha intentado resolver empleando diversos enfoques. Revisaremos variosde ellos de cara a tratar de extraer conceptos generales, entre otros, en relación ala representación usada para la codificación del espacio de búsqueda y el tipo deoperadores empleados.

Se han revisado dos familias de aprendizaje distintas para la generación dearquitecturas:

Aprendizaje por refuerzo (RL, Reinforcement Learning): NAS con RL (Zophy Le 2016) y NASNet Search Space (Zoph y col. 2017) o ENAS (Pham y col.2018).

2.4. BÚSQUEDA DE ARQUITECTURAS DE RED 29

Técnicas evolutivas: HierarchyEvo (Liu y col. 2017) y AmoebaNet (Realy col. 2018). En este punto se desea simplemente mencionar el trabajo de(Couchet, Manrique y Porras 2007) que ha servido como inspiración de caraa la aplicación de GGGP en el contexto de NAS.

La arquitectura NAS con RL (Zoph y Le 2016) (Fig. 2.26) emplea una redrecurrente (RNN) para la creación de modelos mediante la generación desecuencias de hiperparámetros (Fig. 2.27); posteriormente dicho modelo degeneración se amplía para contemplar arquitecturas más complejas de conexión(Fig. 2.28). En este contexto se denomina base del árbol al número de nodos hoja(en los experimentos presentados por los autores del paper se emplean árboles debase 8).

Figura 2.26: Arquitectura NAS con RL. Fuente: (Zoph y Le 2016).

Figura 2.27: Arquitectura NAS con RL, controlador RNN. Fuente: (Zoph y Le 2016).

El espacio de búsqueda NASNet (Zoph y col. 2017) se apoya sobre laarquitectura NAS con RL (Zoph y Le 2016). Permite emplear un pequeño datasetpara buscar un bloque estructural de construcción para posteriormente transferirloun conjunto de datos de mayores dimensiones (para ello se apilan varias copias delbloque estructural encontrado).


Figura 2.28: Arquitectura NAS con RL, controlador RNN con árboles de operadores.Fuente: (Zoph y Le 2016). Izquierda: árbol de proceso base 2. Centro: controlador.Derecha: bloque generado.

Los autores denominan NASNet a la mejor arquitectura encontrada en susexperimentos para el dataset CIFAR-10.Aunque no vamos a describirlo, se propone además ScheduledDropPath (Zophy Le 2016) como nuevo método de regularización con el fin de mejorar lageneralización de los modelos.

De cara a la estructura de red generada (Fig. 2.29), se emplean dos tipos demódulos (también llamados Cells): Normal y Reduction (usan stride 2).

Para la generación de un modelo el controller RNN escoge en cada paso dosestados ocultos (de entre todos los disponibles hasta el momento) y los procesarespectivamente mediante la elección de dos operadores para finalmentecombinarlos empleando: suma a nivel de elementos o concatenación en ladimensión de filtros/características. Podemos observar un ejemplo concreto en(Fig. 2.30).

El tipo de operadores contemplados por la red controlador (controller) paragenerar los modelos (agrupados por tipo):

identity

1× 1 o 3× 3 conv.

3× 3 dilated conv.

3× 3, 5× 5 o 7× 7 depthwise-separable conv.

1 × 7 seguida de 7 × 1 conv (hemos observado este tipo de conexión en laarquitectura Inception v3).

1× 3 seguida de 3× 1 conv.

3× 3, 5× 5 o 7× 7 max pooling.

3× 3 average pooling.


Figura 2.29: Arquitectura NASNet para los datasets CIFAR-10 e ImageNet. Fuente:(Zoph y col. 2017).


Figura 2.30: Ejemplo del funcionamiento del controlador del espacio de búsquedaNASNet. Fuente: (Zoph y col. 2017).

ENAS realiza la búsqueda de un subgrafo óptimo dentro de un grafo de proceso demayores dimensiones que representa el espacio de búsqueda completo. El controladoren este caso lo que escoge son las aristas que se incluirán en el modelo. En estesentido las autores de ENAS argumentan que el controlador de NASNet, al emplearsolamente dos nodos de proceso en cada paso, es menos flexible.

Una vez más en este caso se emplea una arquitectura que combina de formasemejante al caso anterior la alternancia entre bloques de convolución (en el caso deestar diseñando redes convolucionales) y reducción para formar la arquitectura finalde la red. Es importante indicar que uno de los motivos principales de las diferenciasde tiempos que se presentan para el diseño es la compartición de pesos entre todoslos modelos hijos (subconjuntos del grafo de proceso global).

Tiempo de diseño para CIFAR-10:

Diseño de la red completa NAS (21-28 días) y ENAS (0.32 días).

Diseño de un bloque estructural NAS (3-4 días) y ENAS (0.45 días).

HierarchyEvo emplea un sistema de representación jerárquica (Fig. 2.31) quepermite la combinación de bloques dentro de distintos niveles de complejidad hastaobtener el modelo completo (o bien diseñar bloques estructurales que se emplearánmás adelante).

La codificación emplea para cada subgrafo un conjunto de operaciones disponiblesy una matriz de adyacencia para indicar la conectividad entre ellas. Los operadoresempleados en el primer nivel de la jerarquía son los siguientes:

1× 1 conv de C canales

3× 3 depthwise conv


Figura 2.31: Representación jerárquica de HierarchyEvo. Los superíndices de losoperadores (on) indican su nivel jerárquico. Fuente: (Liu y col. 2017).

3× 3 separable conv de C canales

3× 3 max-pooling

3× 3 average-pooling

identity

La arquitectura final de la red emplea los bloques diseñados (también llamados cells)en la estructura que vemos en (Fig. 2.32).

Figura 2.32: Arquitecturas empleadas por HierarchyEvo. Fuente: (Liu y col. 2017).

De cara a combinar resultados de dos nodos experimentan con la concatenaciónen espacio de características. Consideran la suma a nivel de elementos como un casoconcreto que puede cubrirse con una concatenación seguida de una convolución 1×1.

Todas las primitivas empleadas utilizan, en caso se ser aplicable, stride 1 y paddingpara conservar las dimensiones espaciales. Todas las operaciones de convoluciónvan seguidas de BN y activación ReLU. Además el número de canales se fija a


una constante C (se entiende que un número mayor puede obtenerse mediante laconcatenación).

De cara al algoritmo genético empleado:

La inicialización genera un individuo aleatorio como cadena de conexionesidentidad y aplica un número alto de mutaciones (en torno a 1000) para obtenercada individuo de la población inicial.

La mutación elige un nivel de jerarquía y un motivo estructural de dicho nivelpara añadir, modificar o eliminar un enlace.

Se emplea selección por torneo.

Para el fitness de una red se emplea el accuracy sobre el conjunto de validación,entrenando desde cero y durante un número determinado de epochs.

Se permite que el tamaño de la población aumente en el tiempo.

Para paliar variaciones en las métricas de un modelo se emplea el accuracymedio entre 4 iteraciones de entrenamiento/validación.

Se utiliza ampliación artificial del conjunto de entrenamiento mediante recortesy giros.

Informan de tiempos de evaluación de entorno a una hora por individuo (cadamodelo de red evaluado).

AmoebaNet emplea el espacio de búsqueda NASNet combinado con lo quedenominan evolución con envejecimiento o regularizada.

Capítulo 3

Sistemas desarrollados

En las secciones siguientes se presentan las tareas previas de análisis de riesgosy las características del conjunto de datos empleados, así como las tareas realizadasen cada fase del proyecto hasta la fecha de presentación del presente trabajo.

De cara a la implementación de las librerías propias no se incluyen detalles delAPI (Application Program Interface) debido a que se consideran menos relevantesque la descripción de las técnicas de alto nivel aplicadas y por la extensión queresultaría necesaria para incluirlos. En su lugar nos centraremos en remarcaraquellos aspectos que hayan podido requerir un esfuerzo significativo o sean de máscompleja comprensión (p.ej. el impacto sobre la memoria empleada por TensorFlowdel formato de codificación de los datos y la necesidad de su gestión explícita).

3.1. Evaluación de riesgos

Existen diversas fuentes potenciales de riesgo de cara a la realización exitosade las tareas que se acometen, algunas de ellas derivan de la logística propia delproyecto y otras de la viabilidad de la aplicación de las técnicas exploradas. En estasección se exploran y se presentan para cada escenario las medidas de gestión deriesgos contempladas para mitigar el efecto que puedan tener respecto a los hitosentregables y el éxito final del proyecto.

En primer lugar a nivel de recursos materiales y lógicos existen dos posibles fuentesprincipales a contemplar: el dataset y las máquinas necesarias para el entrenamientode las redes. Desde un principio partimos de la inexistencia previa del conjuntode datos de ejemplo que será progresivamente generado por personal asociado alproyecto, tanto de la parte del IGN como del Grupo Mercator. En ese sentido cadafase del presente TFM y de los hitos asociados se acometerá con la versión disponibledel conjunto de datos.

En el caso de que por cualquier problema dicho conjunto de datos no se faciliteen tiempo y/o forma adecuadas se emplearán datasets públicos (o subconjuntos de

35

36 CAPÍTULO 3. SISTEMAS DESARROLLADOS

los mismos de dimensiones reducidas en caso de que resulte necesario) o bien segenerará de forma manual un conjunto reducido etiquetado manualmente por elautor del presente TFM.

A nivel de hardware, se dimensiona inicialmente en el pliego de contratación delproyecto con la compra por parte del IGN de dos servidores con cuatro GPUs cadauno. Por motivos legales relacionados con cambios de licencia de uso del hardwarede Nvidia, se modificó la solicitud inicial que indicaba el uso de GPUs 2080Ti pormodelos legalmente aplicables dentro del contexto del proyecto. De los dos servidoresla idea es que en el medio plazo uno de ellos se emplee como entorno de desarrolloy el otro para producción, no obstante se cuenta con disponer de ambos durante larealización de este trabajo.

Si por cualquier problema tanto a nivel presupuestario como logístico no sedispusiese del hardware citado se contemplan diversas opciones, por un lado laadquisición por parte del grupo de investigación de una máquina con al menos dosGPUs a nivel de potencia de cálculo y memoria del modelo indicado anteriormente(2080Ti). En caso de no disponer de capacidad para adquirir dicho equipo setrabajará sobre un servidor disponible actualmente que cuenta con una sola GPUNvidia 980Ti con 5GB de RAM y se intentará obtener una cesión tiempo deproceso en el servidor con dos GPUs ubicado en el Instituto Universitario deInvestigación del Automóvil (INSIA) del que se dispone para otros proyectos. Eneste último caso resultará necesario coordinar dicho tiempo de uso para no afectaral resto de usuarios del servidor.Finalmente en el caso de que ninguna de las opciones anteriores resulte posible setrabajará con un equipo propio con una sola GPU adaptando las dimensiones delas pruebas realizadas al hardware disponible.

Dado que dentro de la revisión del estado del arte se encuentran proyectos deaplicación de técnicas de deep learning a escenarios de reconocimiento deestructuras en imagen aérea, partimos de una relativa confianza frente a laviabilidad de la clasificación. No obstante dado que el propio convenio reconoce lanaturaleza eminentemente de investigación de esta parte del proyecto noslimitaremos a aplicar las técnicas y presentar los resultados obtenidos de cara a suanálisis posterior. En cualquier caso si por cualquier motivo no resultase viable portiempos la aplicación de técnicas evolutivas guiadas por gramática para el diseñode la arquitectura completa de la red, pasaríamos a la aplicación de un algoritmogenético clásico para optimizar los hiperparámetros de uno o varios modelospreviamente diseñados manualmente o extraídos de la bibliografía revisada.En ese sentido de cara a reducir los tiempos de ejecución del algoritmo evolutivo,los cuales se saben elevados por la aplicación en trabajos previos, se contemplanvarias alternativas:

Uso de subconjuntos del dataset para entrenar y evaluar cada individuo.

3.2. DETALLES DEL DATASET 37

Estudiar la viabilidad de emplear un número reducido de epochs deentrenamiento para muestrear la capacidad de un modelo concreto paraaprender y/o generalizar.

Reducir las dimensiones de las imágenes y/o emplear escala de grises en lugarde RGB.

Estas propuestas, especialmente la última, contribuirían además a reducir elimpacto a nivel de tiempo de cálculo y memoria empleada en escenarios en los quetengamos que trabajar con GPUs de capacidades reducidas frente a lasinicialmente planificadas.

Finalmente si por motivos asociados al tipo de datos empleado (dificultades porejemplo relacionadas con la oclusión total o parcial de las vías en las ortofotos)no resultase posible la clasificación adecuada se pasaría a analizar la necesidad deemplear datos de espectro no visible (p.ej. imagen de infrarrojo o LiDAR) en aquellosescenarios en los que se encuentren disponibles o se pueda contemplar su obtención.

3.2. Detalles del dataset

El conjunto de datos empleados se compone de imágenes capturadas dentro delPNOA de dimensiones 256 × 256 en formato RGBA (el canal alpha no contieneinformación y se elimina en una fase de carga y preproceso de los datos). Dichasimágenes se dividen en dos categorías de cara al presente TFM etiquetadasmanualmente por personal asociado al proyecto (grupo Mercator e IGN):

1. Imágenes de la categoría "contiene vías de transporte" (es importante indicarque engloba varios tipos de vías: autovías, carreteras secundarias, etc).

2. Imágenes de la categoría "no contiene vías de transporte".

Igualmente se dispone de imágenes del mismo formato de cartografía BTN25categorizadas asociadas a las anteriores de forma biyectiva. Todas ellas se organizandentro de "hojas" por su zona geográfica, usándose en el proyecto a la fecha deescritura de la presente memoria cuatro hojas: h533, ochagavia, etxalar y almonaster.

Se muestran a continuación ejemplos de dichas imágenes para ambas categoríasde cara a ilustrar las posibles complicaciones del proceso todas pertenecientes a laprimera versión del dataset, concretamente a la hoja h533. En el caso de lacategoría de imágenes que "no contienen vías de transporte", véase (Fig. 3.1),podemos observar distintos tipos de formaciones naturales (p.ej. cauces de ríossecos o cambios de terreno) o artificiales (p.ej. cultivos o construcciones) que nosdan una idea de algunas formaciones que puede resultar a veces confuso diferenciarde ciertas clases de vías de transporte como carreteras secundarias y/o caminos.

Como ejemplos de diversos tipos de vías dentro de la misma hoja (h533) junto consu cartografía BTN25 asociada podemos ver los mostrados en (Fig. 3.2). Observamos


(a) (b) (c)

(d) (e) (f)

(g) (h) (i)

Figura 3.1: Ejemplos de imágenes que no contienen vías.

3.2. DETALLES DEL DATASET 39

(a) (b) (c)

(d) (e) (f)

(g) (h) (i)

(j) (k) (l)

Figura 3.2: Ejemplos de imágenes que contienen vías con su cartografía asociada(color indica tipo de vía).


a pesar de tratarse de datos originados con una diversidad geográfica limitada, laheterogeneidad de los tipos de vías y de los entornos en los que podemos encontrarlas.

Debido a que el TFM se integra dentro de un proyecto sujeto a convenio con hitostemporales establecidos ha resultado necesario trabajar en cada momento con lasversiones del conjunto de datos disponibles, que ha ido variando tanto en volumende imágenes etiquetadas como en calidad del proceso de etiquetado o dispersióngeográfica de las hojas de datos facilitadas por el IGN para el procedimiento deetiquetado.

3.3. Modelos ajustados manualmente

El presente apartado describe las tareas iniciales realizadas de cara a laevaluación de viabilidad del uso de Redes de Neuronas Artificiales (RNAs) (en estafase arquitecturas tipo CNNs) para la clasificación automática de imágenes defotografías aéreas con el fin de detectar la presencia de vías de transporte. Para lapresente entrega trabajamos con clasificación a nivel de imagen.

Se presentarán los modelos de RNAs evaluados (incluyendo su estructura a nivelde capas, distintas variaciones de hiperparámetros y técnicas de normalización y/oregularización aplicadas en cada caso), plataforma y métricas de test recolectadaspor evaluación cruzada para el análisis de dichos modelos. Finalmente se incluyenlas conclusiones derivadas del presente estudio experimental de cara a orientar lomejor posible la investigación en la fase siguiente del proyecto.

Este primer entregable del TFM, fijado entre los hitos del convenio del proyectoCartobot, sirve como prospección de viabilidad de la clasificación de imágenes PNOApara detectar la presencia de vías. Por requisitos de fecha de entrega del hito deproyecto asociado se realiza con la primera versión disponible del conjunto de datos(la más reducida en dimensión de todas las empleadas) y con una arquitecturahardware bastante reducida, al no haber resultado posible la compra de los servidoresdel proyecto por motivos de presupuesto.

3.3.1. Modelos evaluados

La estructura de red base de la que partimos corresponde al modelo CNN-PC(Volpi y Tuia 2017). Dicha red consiste estructuralmente en una CNN de cuatrocapas (Fig. 3.3) compuesta cada una por una convolución (usando función deactivación leaky-ReLU [lReLU]) con max pool. La capa de salida escompletamente conexa, con función de activación softmax y tantas neuronas comoel número de clases a identificar (en el presente trabajo son dos: "no contiene vías

3.3. MODELOS AJUSTADOS MANUALMENTE 41

de transporte" y "contiene vías de transporte"). Se puede observar dichaestructura en detalle en la (Tabla 3.1).

Figura 3.3: Arquitectura Base del modelo CNN-PC.

Capa Parámetros

Conv + MP Conv 7× 7× 32 lReLU, MP 3× 3 stride=2Conv + MP Conv 5× 5× 64 lReLU, MP 3× 3 stride=2Conv + MP Conv 5× 5× 128 lReLU, MP 3× 3 stride=2Conv + MP Conv 5× 5× 256 lReLU, MP 3× 3 stride=2FC Dos neuronas (una por clase) con función de activación softmax.

Tabla 3.1: Estructura base de CNN-PC empleada para los modelos ajustadosmanualmente.

Se aplica en todos los casos normalización sobre los pesos de las capasconvolucionales y dropout (obviamente solo activo durante la fase deentrenamiento) después de cada una de ellas (a excepción de la capa de salidasoftmax). El tipo de normalización y probabilidad de mantener cada valor en eldropout (keep-prob) varía en función del modelo concreto evaluado.Concretamente se han evaluado las normalizaciones LRN y BN, así como laregularización L2. Para la inicialización de los pesos se emplea en todos los casos lainicialización mejorada de Xavier (Glorot y Bengio 2010) y como método deentrenamiento se emplea el algoritmo de Adam (Kingma y Ba 2014) con distintosvalores para el parámetro alpha (empleando como función de coste la entropíacruzada). Los distintos conjuntos de hiperparámetros empleados para los modelosson detallados en la (Tabla 3.2).

3.3.2. Entorno de pruebas

Las pruebas de esta primera fase se han realizado en un servidor (Akira) UbuntuGNU/Linux:


Modelo Hiperparámetros

CNN-PC Normalización BN, dropout con keep-prob=0.5 en todas lascapas y regularización L2. Alpha=1e-4 Epochs=800

Modelo 1 (M1) Normalización LRN, dropout con keep-prob=0.7 solo en laúltima capa. Alpha=1e-5 Epochs=300

Modelo 2 (M2) (M1 variando epochs) Epochs=400Modelo 3 (M3) (M1 variando epochs) Epochs=600Modelo 4 (M4) Normalización BN, dropout con keep-prob=0.6 solo en la

última capa. Alpha=1e-5 Epochs=300Modelo 5 (M5) Normalización BN, dropout con keep-prob=0.7 solo en la

última capa. Alpha=1e-5 Epochs=300Modelo 6 (M6) (M5 variando epochs) Epochs=400Modelo 7 (M7) (M5 variando epochs) Epochs=500Modelo 8 (M8) (M5 variando epochs) Epochs=600Modelo 9 (M9) (M5 variando epochs) Epochs=700

Tabla 3.2: Modelos ajustados manualmente. Hiperparámetros de cada modelo.

CPU Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

16GB RAM

GPU GeForce GTX 980 5.94GiB

Partimos de un conjunto inicial de imágenes de PNOA que en este punto deldesarrollo constaba de:

373 Imágenes de la categoría "contiene vías de transporte".

368 Imágenes de la categoría "no contiene vías de transporte".

En ese sentido es importante recalcar que las limitaciones de potencia de cálculoy el tiempo de proceso, en el que se traducen al ejecutar cada una de las pruebas, halimitado la dimensión de las RNAs evaluadas en esta primera fase. Entre otras cosasesto ha obligado a emplear lotes de 40 imágenes para poder entrenar empleando laGPU. En cuanto al coste en tiempos de ejecución téngase en cuenta por ejemploque el Modelo 7, que entrena durante 500 epochs, usando unas 700 imágenes deejemplo tarda en hacerlo en torno a 30 minutos. Esto supone que para evaluar estemodelo por k-fold (con k=10) necesitamos 5 horas (inicialmente se intentó emplearevaluación 10x10 k-fold lo cual supondría en este caso 50 horas solo para evaluar unmodelo).

3.3.3. Resultados de la evaluación

La evaluación de todos los modelos se ha realizado por evaluación cruzada k-fold(k=10) recolectándose medidas en test del accuracy (Fig. 3.4) (tomando la salida

3.3. MODELOS AJUSTADOS MANUALMENTE 43

más alta de la red como clase reconocida para la imagen de entrada) y del RootMean Square Error (RMS) (Fig. 3.5). Ambas se presentan detalladas en la tabla acontinuación. No obstante se detallan dichos resultados en la (Tabla 3.3).

Figura 3.4: Modelos ajustados manualmente. Resultados de accuracy en testevaluados con k-fold (k=10).

En base a los resultados obtenidos el modelo de red seleccionado para la entregadel primer hito del proyecto es el Modelo 7 (M7).

3.3.4. Conclusiones preliminares del primer hito

Las restricciones de cara al tiempo de entrega para el primer hito del convenio ya nivel hardware, principalmente de GPU, han limitado notablemente el alcance delos resultados presentados en esta primera fase, los cuales no obstante nos permitenconcluir la viabilidad de los modelos basados en CNNs de cara al reconocimiento devías de transporte y clasificación automática de imágenes aéreas aplicado dentro delámbito del presente proyecto y partiendo de los datos disponibles en esta fase.


Figura 3.5: Modelos ajustados manualmente. Resultados de RMS en test evaluadoscon k-fold (k=10).

RMS AccuracyModelo mean std mean std

CNN-PC 0.439 0.089 0.721 0.104Modelo 1 (M1) 0.494 0.022 0.610 0.056Modelo 2 (M2) 0.505 0.030 0.618 0.061Modelo 3 (M3) 0.525 0.034 0.617 0.050Modelo 4 (M4) 0.421 0.097 0.714 0.116Modelo 5 (M5) 0.413 0.104 0.725 0.130Modelo 6 (M6) 0.412 0.094 0.746 0.097Modelo 7 (M7) 0.385 0.115 0.783 0.120Modelo 8 (M8) 0.406 0.060 0.761 0.078Modelo 9 (M9) 0.400 0.086 0.761 0.105

Tabla 3.3: Modelos ajustados manualmente. Resultados de RMS y accuracydetallados (evaluados por kfold=10).

No se han evaluado, en esta primera fase, arquitecturas alternativas (por ejemploredes residuales y/o deconvolucionales), de mayores dimensiones o técnicas de diseño

3.4. VBRAIN: LIBRERÍA DE DEEP LEARNING 45

automático de arquitecturas de RNAs por las mismas restricciones de tiempo yhardware. Por ello estos resultados se ofrecen como punto de partida de cara ajustificar el interés de intensificar los esfuerzos de investigación en este sentido.

En cuanto al conjunto de datos empleado en el entrenamiento y la evaluaciónde los modelos se concluye que la dimensión es excesivamente reducida (una vezmás restricciones de tiempo y hardware limitaban este aspecto) y se procederá ala ampliación y revisión del mismo. Además en esta versión del dataset se detectandiferencias de escala entre algunos de los ejemplos empleados y resulta necesarioampliar la dispersión geográfica de los mismos. De cara a la fase siguiente se puedenademás emplear mecanismos de aumentación artificial del juego de datos mediante eluso, por ejemplo, de rotaciones de las imágenes o la introducción de ruido controladoen las mismas.

3.4. VBrain: Librería de Deep Learning con gestiónautomática de recursos

Para permitir el entrenamiento automatizado de las redes generadas por elsistema evolutivo se desarrolla la librería VBrain sobre TensorFlow. Dicha libreríase ha diseñado para ser capaz de realizar una estimación automática del tamaño delote de entrenamiento que ajuste lo más posible la memoria usada a la disponible.De este modo se pueden entrenar múltiples modelos de red sin necesitar usar untamaño predefinido para todos ellos que pueda resultar subóptimo en muchos casos(deberíamos establecer el mínimo común). Al mismo tiempo ofrece un API de altonivel, semejante a la que podemos encontrarnos en librerías como Keras o tf.layers,que incluye funciones para gestionar el dataset, entrenamiento de redes yevaluación de las mismas usando diversos mecanismos. Permite además en todomomento y sin alterar el código de las redes trabajar en entornos que cuenten conmúltiples GPUs.

Es importante indicar que el uso de VBrain no se restringe únicamente alsistema evolutivo, todos los modelos diseñados manualmente y evaluadosanteriormente la emplean. Igualmente se usa en tareas de investigación de cara aestudiar el comportamiento de un modelo dado, el impacto de los hiperparámetrossobre las métricas, etc. Para su uso por consola de comandos se ha desarrollado lautilidad "model-trainer.py" cuya descripción figura en el anexo correspondiente.

La librería desarrollada cumple con varios objetivos:

Ofrecer un interfaz sobre TensorFlow que gestione de forma transparente elentrenamiento sobre entornos multi-GPU (concretamente se emplearáparalelismo a nivel de datos para realizar entrenamiento multi-torre).

Realizar una estimación automática del tamaño de lote para entrenar unmodelo de red dado (resultará especialmente útil para evaluar los individuos


de la población en el sistema evolutivo). Para ello:

• Se lleva un inventario de variables internas de los modelos.

• Se ha ajustado empíricamente una función para la estimación de lamemoria que empleará TensorFlow durante el entrenamiento de la red.

• Se gestiona de forma explícita el formato interno de los datos.

Entrenamiento por minibatch.

Funciones básicas de evaluación (train & test, K-Fold, N× K-Fold).

Otras funciones de utilidad (p.ej. carga del dataset, gestión de sesiones).

El paralelismo a nivel de datos empleado procesa sobre cada torre un lotedistinto de datos de entrada empleando variables de modelo compartidas.Posteriormente calcula la función de coste y los gradientes en cada torre (GPU).Finalmente unifica dichos gradientes para aplicar el paso de entrenamiento sobrelas variables compartidas (en base a las pruebas de velocidad realizadas sobre lasmáquinas empleadas el dispositivo más rápido para almacenar las variablescompartidas ha resultado ser la CPU). El esquema puede observarse en (Fig. 3.6).

De forma muy resumida se ofrece una clase (VBrain) cuyos métodos incluyendiversas funciones que realizan cada una de las operaciones típicas empleadas enarquitecturas de Deep Learning (convoluciones, capas FC, pooling, etc). Esasfunciones proxy se encargan de:

Registrar las variables necesarias en el dispositivo compartido (reutilizándolasen cada torre).

Incluirlas en el registro interno (en función de su uso) para estimar memoriaempleada por el modelo al entrenar.

Gestionar los nodos de proceso en cada torre adecuadamente.

Desde el punto de vista de uso la clase que implementa un modelo sólo necesitaheredar de VBrain y definir la función "init_model_layers" (empleando en ella lasfunciones indicadas). Un ejemplo sencillo:

class mi_modelo (VBrain_Model ) :def in i t_model_layers ( s e l f ) :

layer_0 = s e l f . model_inputlayer_1 = s e l f . conv2d_block ( layer_0 , 16 , s i z e =3, s t r i d e =1,

normal i ze r=None )layer_2 = s e l f . dropout ( layer_1 , r a t e =0.2)layer_3 = s e l f . conv2d_block ( layer_2 , 32 , s i z e =2, s t r i d e =2,

normal i z e r=s e l f . batch_normal izat ion )


Figura 3.6: Entrenamiento de redes con paralelismo a nivel de datos. Fuente:(https://www.tensorflow.org/tutorials/images/deep_cnn).

layer_4 = s e l f . max_pool ( layer_3 , s i z e =2, s t r i d e =2)_layer_4 = s e l f . f l a t e n ( layer_4 )layer_5 = s e l f . f c ( _layer_4 , 16)out = s e l f . softmax ( layer_5 )

En este caso tenemos una red que implementa en orden (la función de activaciónpor defecto es leaky-ReLU):

Conv 3× 3, 16 canales, stride=1, sin normalización

Dropout rate=0.2

Conv 2× 2, 32 canales, stride=2, BN

MP 2× 2, stride=2

flatten

FC size=16


Softmax con tantas salidas como se haya configurado la librería al inicializarla.

La librería se encarga de construir para cada torre disponible (cada GPU) unaréplica de dicha red reutilizando/compartiendo las variables internas cuando resultenecesario. Igualmente el tipo de función de coste que se emplea se detecta en funcióndel tipo de operación de la capa de salida (softmax, en nuestro caso, usa la entropíacruzada).

Es importante indicar que se realiza una gestión interna automática del formatode datos empleado por TensorFlow para reducir la memoria empleada.Existen dos formatos NHWC y NCHW. En ese sentido las letras hacen referencia a:

N: Número de ejemplos

H,W: Alto y ancho respectivamente.

C: canales o features.

Existe una especie de conflicto respecto al formato de datos asumido como máseficiente y no todas las operaciones están implementadas en TensorFlow para todoslos formatos al ejecutarse en un tipo de dispositivo (CPU o GPU). En ese sentidosi intentamos ejecutar un operador en un dispositivo con unos datos en un formatoque no se soporta obtendremos un error (p.ej. "Conv2DCustomBackpropFilterOponly supports NHWC").

Al emplear Nvidia por defecto formato NCHW y TensorFlow NHWC, esteúltimo internamente genera operadores adicionales de forma automática cuandoconsidera necesario (p.ej."BiasAdd_6-0-0-TransposeNCHWToNHWC-LayoutOptimizer"). Dichosoperadores y sus variables (de salida y/o internas) consumen memoria.

De cara a evitar dichos operadores internos, generados para el cambio de formato,la librería VBrain controla internamente dicho formato. Se soportan los siguientesmodos de funcionamiento:

NCHW

NHWC

NHWC2NCHW: (empleado por defecto y en este TFM) convierte los datos solouna vez (de NHWC a NCHW) antes de pasarlos a la entrada del modelo (sila salida es una imagen se realiza la conversión de vuelta al formato original).

NCHW2NHWC: funciona de forma análoga al modo anterior pero con NCHWcomo formato "externo" al modelo.


Al emplear el modo NHWC2NCHW (en nuestro caso trabajamos únicamente conGPUs de Nvidia) estamos realizando una sola operación de trasposición ycontrolamos su coste de memoria.

3.4.1. Estimación del tamaño de lote máximo paraentrenamiento

Para el cálculo del tamaño máximo recomendado de lote de entrenamiento(estimando la memoria empleada durante el entrenamiento de un modelo),contamos con (todo en MB):

devFreeM: memoria libre en una torre (se asume una arquitectura homogéneade GPUs).

tfLibraryM: memoria base aproximada que ocupa TensorFlow al inicializarse.

perSampleM: memoria de variables cuya ocupación varía en función del númerode ejemplos del lote.

notPerSampleM: memoria de variables de dimensión fija.

phM: placeholders empleados para almacenar la entrada y la salida (en estecaso por dos al necesitar almacenar la obtenida y la deseada) de la red.

gradientCalcMem: para el cálculo de gradientes: sabemos que se emplea unalista de pares tipo (variable-gradientes, variable) en el que ambos elementostienen las mismas dimensiones. Internamente no disponemos de detalles delresto de variables empleadas.

Para calcular el tamaño máximo estimado de lote que podemos emplear paraentrenar utilizamos las siguientes ecuaciones:

maxBatchSize = � devFreeM − notPerSampleM

phM + perSampleM + gradientM + gradientPerSampleM�

gradientM = gradientCalcMem ∗ agradientPerSampleM = perSampleM ∗ b

Se han ajustado experimentalmente los coeficientes a y b empleando una bateríade redes generadas a partir de la gramática o procedentes de los modelosmanuales. Para dichas redes se ha comprobado experimentalmente el tamañomáximo de lote empleable para entrenar en dos servidores con capacidades dememoria de GPU diferentes y se ha buscado que la predicción fuese lo más cercanaposible a la óptima.


Los valores fijados finalmente han sido a = 1 y b = 0.15. El ajuste de la estimaciónmediante un sistema más elaborado excede los objetivos de este proyecto.

En los experimentos realizados, con la última versión del dataset a fecha de laescritura de esta memoria, el sistema evolutivo ha evaluado 2586 redes y de ellassolamente 32 han dado error de memoria al calcularse mal el tamaño de lote yemplearse uno demasiado grande. Esto supone un 1.237 % de errores al estimar yque el 98.762 % de redes durante esos experimentos se han podido entrenar con éxito.

3.5. V3gie: Librería GGGP

La librería V3gie implementa un algoritmo de programación genética guiadapor gramática (GGGP) (Whigham 1995) cuyo esquema general de funcionamientodentro del sistema final (incluyendo VGNet y VBrain) se muestra gráficamente enla (Fig. 3.7), para más detalles consúltese (Algoritmo 1). Se parametrizan lagramática y la función de fitness a partir de un individuo dado con el fin de que lalibrería pueda ser aplicada a la resolución de otros problemas distintos al NAS.Igualmente se ha simplificado la descripción para obviar otras funciones auxiliarespara realizar, entre otras tareas, el seguimiento y depuración del proceso deevolución de acuerdo con el problema específico al que se aplique la librería.

De cara a los operadores empleados:

Generación de individuos: método basado en Grammar-Based InitializationMethod (GBIM) (García-Arnau y col. 2006) o GROW (Koza y Koza 1992)(este último solo se ha empleado en tareas de depuración en el contexto delTFM).

Mutación: Grammar-Based Mutation (GBM) (Couchet y col. 2007) oconvencional (no empleado en el TFM).

Selección por torneo parametrizable.

Cruce Whingham (WX) (Whigham 1995).

El reemplazo de una población por la nueva se realiza en bloque (la libreríadesarrollada permite usar elitismo pero no se ha aplicado en este TFM).

Es importante indicar que el método empleado para la inicialización/mutación sebase en GBIM/GBM con las siguiente modificaciones:

Permite trabajar sin necesidad de tener desde cada nodo terminal unaproducción compuesta solamente por nodos terminales (las denominaremospor simplicidad producciones por defecto de aquí en adelante).

3.5. V3GIE: LIBRERÍA GGGP 51

Algoritmo 1 V3gie: Algoritmo de evolución.Require: grammar = gramática para generación de individuosRequire: fn_fitness = función para evaluar el fitness de un individuo dadoRequire: pop_size = tamaño de la poblaciónRequire: max_depth = profundidad máxima para el árbol de derivación de un

individuoRequire: use_gbim = uso o no de variante de GBIM para inicialización y mutaciónRequire: p_cross, p_mut = probabilidades de cruce y mutaciónRequire: tournament_size = tamaño de torneo empleado para el cruceRequire: elitism = número de elementos a emplear por el elistimo (None desactiva

la estrategia elitista)Require: max_generations, stop_fitness = criterios de parada (stop_fitness puede

ser None)generation_number ← 0if use_gbim thenpopulation ← new_population_gbim(grammar, pop_size,max_depth)

elsepopulation ← new_population_grow(grammar, pop_size,max_depth)

end ifwhile generation_number < max_generations do

evaluate_population_fitness(population, fn_fitness)best_fitness ← get_best_fitness(population)best_individual ← get_best_individual(population)if (stop_fitness �= None)AND(best_fitness ≥ stop_fitness) then

breakend ifnew_population ← []if elitism �= None thennew_population+ = get_best(population, elitism)

end ifwhile size(new_population) < pop_size doparents ← tournament_selection(population, tournament_size)children ← crossover_whigham_WX(parents, p_cross)if use_gbim thenchildren ← mutation_gbim(children, p_mut,max_depth)

elsechildren ← mutation(children, p_mut,max_depth)

end ifnew_population+ = children

end whilegeneration_number ← generation_number + 1population ← new_population

end whilereturn best_individual


No garantiza el mismo nivel de uniformidad en la generación.

Para generar un árbol de derivación se escoge aleatoriamente una profundidaden el intervalo [min_depth,max_depth] (GBIM emplea [1,max_depth]).

Estas modificaciones permiten obtener una metagramática más legible y se hanobtenido buenos resultados en las pruebas realizadas en el contexto del problema debúsqueda de arquitecturas de red del presente TFM. Además el autor de este trabajoentiende que se evita introducir un sesgo al establecer en las producciones por defectoestructuras que tendrán mayor probabilidad de ser generadas (p.ej. tener un tipode módulo ResNet por defecto que además puede generarse por la vía habitual). Noobstante la demostración formal de esto queda fuera del alcance de este TFM y secontemplará entre las líneas futuras de investigación.

No obstante es importante indicar que se requiere, en caso de optar por no incluirlas citadas producciones por defecto, que la primera producción de todos los nodoslleve a una recursión finita (es decir las producciones recursivas o con dependenciascruzadas no deben ser las primeras).

3.6. VGNet: Diseño de arquitecturas RNAmediante GGGP

Se presenta VGNet, un método para diseñar evolutivamente la arquitectura dered neuronal más adecuada para resolver un problema dado. Dicho sistema se haimplementado y aplicado, dentro del contexto de un proyecto real para el IGN, a laclasificación de imágenes con los objetivos descritos previamente. El sistema empleaGGGP, usando la librería de desarrollo propio V3gie, para buscar la arquitecturade red capaz de dar los mejores resultados sobre el conjunto de datos de validación.El funcionamiento del sistema completo es el que se muestra en la (Fig. 3.7). Dichosistema une las funciones de las librerías descritas anteriormente (V3gie y VBrain)con los siguientes componentes:

Codificación de arquitecturas de red mediante lenguaje de expresiones dediseño propio (fácilmente extensible para la inclusión de operadores nuevos).

Generación automática de código para VBrain a partir de dichas expresiones.

Metagramática diseñada para definir las reglas de construcción de expresionesde arquitecturas a explorar (una vez más pensada para dejar un amplio margende libertad al usuario para su modificación en el futuro).

3.6. VGNET: DISEÑO DE ARQUITECTURAS RNA MEDIANTE GGGP 53

Figura 3.7: Esquema general de funcionamiento del sistema completo.

En las secciones siguientes se describirán los detalles del sistema comenzandopor la codificación, metagramática y generación automática de código de las redespara la librería VBrain. Posteriormente se detallará el algoritmo propuesto(incluyendo función de fitness empleada y distintas estrategias de particionamientoempleadas para separar conjuntos de entrenamiento y validación) y cómointeractúan todos los componentes descritos (VBrain, V3gie y VGNet) paraconformar el sistema completo. Para detalles de la herramiento desarrollada comointerfaz por línea de comandos se ha desarrollado "model-evolver.py" (su interfazde uso se incluye en el anexo asociado).

3.6.1. Codificación: Expresiones estructurales

Para codificar la estructura de las redes se define un lenguaje de expresiones capazde representar con relativa simplicidad muchas de las arquitecturas encontradas enla revisión del estado del arte con ciertas excepciones. Una de ellas por ejemploes la arquitectura DenseNet debido a que implica intersecciones entre los enlaces(el sistema de expresiones mediante corchetes no permite este tipo de esquema deconexión).


Igualmente es importante indicar que se contemplan solo redes con un punto deentrada y otro de salida por las necesidades del proyecto (al encontrarnos ante unproblema únicamente de clasificación resulta innecesario aplicar modelos como porejemplo Faster-RCNN). No obstante se pueden realizar cambios en ese sentido(podemos ampliar el lenguaje y modificar la metagramática con facilidad) y secontemplan en el futuro ciertas extensiones, bien de cara a generalizar el sistemapara adaptarlo a otro tipo de problemas o en caso de modificarse más adelante lasnecesidades del proyecto.

Las expresiones empleadas tienen los siguientes componentes:

In, Out: Representan los puntos de entrada y salida de datos de la redrespectivamente.

"[", "]": Indican ramas de operadores en paralelo que comparten una mismaentrada de datos (se emplea el separador "," entre ramas).

direct: Indica una conexión directa entre dos puntos de la red sin que seapliquen operadores, se emplea para las conexiones de tipo residual.

Nodos de proceso: Existen dos subtipos principales a nivel funcional:

• Operadores tradicionales: convolución (CONV), poolings (MP y AP),dropout, capas FC, softmax y flatten.

• Operadores de unificación: concatenación de características o suma conpadding. Se aplican inmediatamente después del cierre de ramas paralelasde proceso para unificar los resultados.

Algunos de los nodos de proceso tradicionales emplean una codificaciónparamétrica con formato operador[-parámetro]{0,n}. El número y valoresválidos de cada parámetro varía en función del operador concreto. Algunas notasimportantes:

Flatten: Siempre se aplanan los datos antes de pasar a las capas FC pornecesidades del API.

FC: La función de activación empleada, en las pruebas realizadas hasta la fechade redacción de esta memoria de TFM, en todas las capas FC es leaky-ReLU,con la excepción de la capa de salida (operador SOFTMAX).

SOFTMAX: las dimensiones de la capa de salida no se indican porquedependen del problema y no son un parámetro a ajustar (este parámetro segestiona a nivel de librería en VBrain).


Los parámetros de los operadores empleados:

CONV-i-j-k-l: i (dimensión), j (número de características generadas), k (stride)y l (normalización empleada).

MP-m-k y AP-m-k: m (dimensión) y k (stride).

DROPOUT-r: r (rate).

FC-s: s (tamaño).

Se propone un nuevo operador de unificación, la suma con padding, que persigueun doble propósito:

En el caso de igual número de canales en las entradas puede servir como unaconexión de suma residual tipo ResNet.

En el caso de distinto número de canales en las entradas, al sumar los primerosy concatenar el resto sirve para implementar una conexión tipo DPN conciertas limitaciones.

Su funcionamiento se ilustra en la (Fig. 3.8) y consiste en introducir padding deforma condicional (relleno de ceros) en caso de existir diferencias en el número decanales de sus operandos. Es importante indicar que se asume que dichos operadostienen las mismas dimensiones espaciales. Esto último se garantizará para lasexpresiones que generaremos en el sistema mediante el control a través de lametagramática de las posiciones y número de las operaciones con stride > 1.

Figura 3.8: Ejemplo de funcionamiento del operador de suma con padding.


En primer lugar solo podemos considerar una conexión como de tipo DPN en elcaso de que una de las ramas genere un número mayor de canales que la entradaque recibe. En segundo lugar en el caso de módulos en serie nos encontramos otrasrestricciones adicionales. Tomemos como ejemplo el supuesto de intentarespecificar el empleo de dos módulos tipo DPN en serie usando el siguienteesquema de subexpresión (existen otras opciones):

... [Submódulo1 , direct] SUM [Submódulo2 , direct] SUM ...

Observamos en este caso que:

Submódulo2 recibe para procesar en los primeros canales los de la entradaoriginal procesados de forma residual por submódulo1 y el primer SUM,seguidos de los que ha concatenado dicho SUM (canales adicionalesgenerados por submódulo1).

El primer operador SUM se comporta como una conexión DPN.

El segundo operador SUM procesa residualmente todos los canales resultantesdel primer SUM (incluidos los adicionales generados por submódulo1).

Si nos referiremos al número de canales original y de los submódulos 1 y 2respectivamente como C, C1 y C2. Este esquema de conexión representa, entreotras arquitecturas, dos módulos DPN en serie en las siguientes condiciones:

Se cumple que C < C1 < C2

Una vez entrenada la red, en la salida del submódulo 2 los C1 canales a partirde la posición C+1 (los C primeros son los que afectan a la conexión residual)se conservan intactos. Se entiende que esto tiene una probabilidad inferior aespecificar directamente el número de canales a tratar como residuales y así secontemplará en las líneas de trabajo futuras.

No obstante siguiendo este razonamiento podríamos llegar incluso a considerar laarquitectura DPN como un caso específico de ResNet (en el caso de usar nuestrooperador de suma con padding). A medida que se desea emplear más módulos enserie estas suposiciones se vuelven cada vez menos asumibles (a nivel de la bajaprobabilidad que supone que sean verificadas).

Ejemplos de codificación de arquitecturas

A continuación se muestran algunos ejemplos de codificación junto al grafocorrespondiente a la estructura representada por cada expresión. Se omite endichos grafos la representación del nodo flatten, que siempre separa las capasconvolucionales de las FC, por claridad.


Como primer ejemplo tomamos una red sencilla "In CONV-2-2-2-BN DROPOUT-0.0 AP-3-2 flatten FC-16 SOFTMAX Out" que se compone de las siguientes capas:

Convolución con los siguientes parámetros:

1. Dimensión 2, es decir la convolución es 2× 2.2. Características de salida 2.3. Stride 2.4. Normalización en batch.

Dropout con rate 0, es decir en este caso inactivo.

Average Pool con dimensión 3 (es decir pooling 3× 3) y stride=2

Flatten.

Capa FC de dimensión 16.

Softmax (con tantas salidas como clases tenga el problema).

Esta estructura lineal da como resultado el grafo que puede verse en (Fig. 3.9).

Figura 3.9: Ejemplo de grafo de estructura simple.

Para ilustrar una estructura residual simple podemos tomar como ejemplo lasiguiente expresión "In [ CONV-2-2-1-BN DROPOUT-0.2 , direct ] SUM MP-2-2flatten FC-16 SOFTMAX Out" y su grafo asociado es el que vemos en (Fig. 3.10).La arquitectura en este caso sería:

Entrada

Rama1

• Conv 2× 2, 2 características, stride=1, BN• Dropout rate=0.2

Rama2 (conexión directa o residual)

Suma con padding de Rama1 y Rama2

MP 2× 2, stride=2

flatten

FC tamaño 16

Softmax (con tantas salidas como clases tenga el problema)


Figura 3.10: Ejemplo de grafo de estructura con conexión residual.

Finalmente para mostrar una estructura de red con una complejidad algo mayorsi tomamos la expresión "In [ [ CONV-2-32-1-BN DROPOUT-0.1 AP-3-1 , CONV-1-128-1-BN DROPOUT-0.1 CONV-2-16-1-BN DROPOUT-0.4 , CONV-3-256-1-BN DROPOUT-0.3 ] CONCAT , direct ] SUM CONV-1-256-2-None flatten FC-16 SOFTMAX Out" obtenemos el grafo mostrado en (Fig. 3.11). En este caso elmódulo con rutas de proceso paralelas se puede ver como una variante de módulotipo Inception-ResNet o DPN (debido al comportamiento del operador de suma conpadding).La arquitectura en este caso sería:

Entrada

Rama1

• Rama1-1

◦ Conv 2× 2, 32 características, stride=1, BN◦ Dropout rate=0.1◦ AP 3× 3, stride=1

• Rama1-2

◦ Conv 1× 1, 128 características, stride=1, BN◦ Dropout rate=0.1◦ Conv 2× 2, 16 características, stride=1, BN◦ Dropout rate=0.4

• Rama1-3

◦ Conv 3× 3, 256 características, stride=1, BN◦ Dropout rate=0.3

• Concatenación de Ramas 1-1, 1-2 y 1-3.

Rama2 (conexión directa o residual)

Suma con padding de Rama1 y Rama2

Conv 1× 1, 256 características, stride=2, sin normalización

flatten

FC tamaño 16

Softmax (con tantas salidas como clases tenga el problema)


Figura 3.11: Ejemplo de grafo de estructura con conexiones tipo Inception-ResNeto DPN.

3.6.2. Generación automática de código

La codificación de la arquitectura mediante las expresiones paramétricas permiteuna traducción a código para VBrain casi directa mediante el uso de un sencilloparser para controlar las rutas paralelas (incluyendo su nivel de anidación) y laentrada a emplear para cada operación. Dicho código generado constituirá el fenotipoque usa más adelante nuestro sistema evolutivo para evaluar cada individuo, siendosu genotipo asociado el árbol de derivación de la expresión correspondiente.

Como ejemplo ilustrativo se presenta el código generado a partir de la expresiónmostrada anteriormente en la (Fig. 3.11):

class vgnet_model_0 (VBrain_Model ) :def in i t_model_layers ( s e l f ) :

layer_0 = s e l f . model_input#BEGIN BLOCK#_BEGIN BLOCKlayer_1 = s e l f . conv2d_block ( layer_0 , 32 , s i z e =2, s t r i d e =1,

normal i z e r=s e l f . batch_normal izat ion )layer_2 = s e l f . dropout ( layer_1 , r a t e =0.1)layer_3 = s e l f . average_pool ( layer_2 , s i z e =3, s t r i d e =1)#_New branchlayer_4 = s e l f . conv2d_block ( layer_0 ,128 , s i z e =1, s t r i d e =1,

normal i z e r=s e l f . batch_normal izat ion )layer_5 = s e l f . dropout ( layer_4 , r a t e =0.1)layer_6 = s e l f . conv2d_block ( layer_5 , 16 , s i z e =2, s t r i d e =1,

normal i z e r=s e l f . batch_normal izat ion )layer_7 = s e l f . dropout ( layer_6 , r a t e =0.4)#_New branchlayer_8 = s e l f . conv2d_block ( layer_0 ,256 , s i z e =3, s t r i d e =1,

normal i z e r=s e l f . batch_normal izat ion )layer_9 = s e l f . dropout ( layer_8 , r a t e =0.3)#_END BLOCKlayer_10 = s e l f . concat ( [ layer_3 , layer_7 , layer_9 ] )#New branch#Direc t connect ion#END BLOCKlayer_11 = s e l f . sum_intel l igent_padding ( layer_10 , layer_0 )layer_12 = s e l f . conv2d_block ( layer_11 , 256 , s i z e =1, s t r i d e =2,


normal i ze r=None )layer_13 = s e l f . f l a t e n ( layer_12 )layer_14 = s e l f . f c ( layer_13 , 16)layer_15 = s e l f . f c ( layer_14 , 2 , a c t f=None )out = s e l f . softmax ( layer_15 )

Podemos observar como las rutas de ejecución paralelas se marcan mediantecomentarios "BEGIN_BLOCK" y "END_BLOCK" empleando el prefijo "_"para indicar niveles adicionales de anidación tantas veces como resulte necesario(para facilitar la lectura del código generado).

Igualmente podemos observar en las dos operaciones de agregación (procesan comoentrada las salidas de distintas ramas de proceso) presentes en esta red como el parserse ha encargado de mantener el control de las entradas necesarias en cada caso:

En layer_10 se realiza una operación de concatenación de las salidas de tresrutas paralelas de ejecución (layer_3, layer_7, layer_9).

En el caso de layer_11, la segunda rama por ejemplo es una conexión residualy se ha controlado su punto de origen (layer_0).

3.6.3. Metagramática

Comenzaremos abstrayéndonos de los detalles de bajo nivel para poderobservar la estructura de los bloques principales que componen la metagramática.Por ello en las descripciones de alto nivel nos desviaremos ocasionalmente de dichametagramática, omitiendo nodos no terminales intermedios, en favor de la claridady comprensión.

El nodo raíz "<ANN>" describe la estructura general de la red al mayor nivelde abstracción y se puede observar en el diagrama siguiente (se omiten la entrada yla salida para simplificar):

�� 〈HIGH_LEVEL_NET 〉〈REDUCE_DIM 〉 ‘flatten’ 〈FC 〉 ‘SOFTMAX’ ��

Tenemos una estructura compuesta por:

Entrada de la red.

Una serie de módulos de alto nivel que incluye capas convolucionales y variostipos de estructuras de conexión (Inception, ResNet/DPN eInception-ResNet).

Una capa de reducción de dimensionalidad (emplea una convolución o poolcon stride=2). Se fuerza su presencia para reducir las dimensiones de lascapas siguientes (esto es debido al alto coste de memoria de las capas FC encomparación con las convolucionales).


Se aplana la salida de las capas anteriores para pasar alimentar una serie decapas FC (el número máximo de capas de este tipo es uno de los parámetrosde la metagramática).

Capa Softmax con tantas salidas como clases tengamos definidas en nuestroproblema.

Salida.

Los módulos estructurales contemplados se definen en"<HIGH_LEVEL_NET>", que básicamente sirve para generar secuenciascompuestas por dichos módulos:

�� 〈CONV_BLOCK 〉〈RESNET_BLOCK 〉

〈INCEPTION_BLOCK 〉〈INCEPTION_RESNET_BLOCK 〉

��

El nodo no terminal "<CONV_BLOCK>" se emplea para generar redesconvolucionales y tiene una estructura relativamente simple:

�� 〈CONV 〉〈DROPOUT 〉〈CONV 〉〈DROPOUT 〉〈POOL〉

��

La presencia forzosa de "<DROPOUT>" se añadió tras comprobar en los primerosexperimentos el impacto que tenía en la capacidad para generalizar de las redes. Enese sentido, aunque se fuerza la presencia de dicho operador, se puede inhibir sisu parámetro rate se establece a 0.0. Esto significa que podemos tener el módulodropout en un estado inactivo y que posteriormente mediante cruce o mutación seactive y viceversa.

Un par de variantes de "<CONV_BLOCK>" son "<CONV_NET_S1>" y"<REDUCE_DIM>" que tienen la misma estructura básica con la diferencia deque emplean solamente convoluciones y pools con stride uno o dos respectivamente.

Los siguientes bloques estructurales permiten esquemas de conexión con ramasde proceso paralelas y varían en el operador de agregación que se aplica para unirlas características calculadas por las distintas ramas. Se han contemplado, comose comentaba anteriormente, tres esquemas de conexión y uno de ellos, debido alcomportamiento del operador SUM (suma con padding), sirve para representar dosestructuras de conexión (ResNet y DPN) con ciertas limitaciones.

Los grupos de ramas paralelas se delimitan entre ‘[’ y ‘]’, empleándose entre ramasel separador ‘,’.


Mediante "<RESNET_BLOCK>" se generan ramas convolucionales (sinreducción de dimensionalidad, es decir empleando siempre stride=1) paralelas yuna conexión directa que funciona como conexión residual.

�� ‘[’‘,’

�‘<CONV_BLOCK_S1>’ �� ‘,’ �� ‘direct’ �� ‘]’ �� ‘SUM’ ��

En "<INCEPTION_BLOCK>" se contemplan dos tipos de módulosInception, con y sin reducción de dimensiones (usando "<PARALLEL_BLOCK>"y "<PARALLEL_BLOCK_REDUCE_DIM>" respectivamente). En este punto,por claridad, vamos a omitir estos dos bloques intermedios reemplazándolos por lasestructuras que generan internamente. En ambos casos el número mínimo de ramasque se generan es dos (la repetición se realiza como mínimo ese número de veces).

�� ‘[’‘,’

�‘<CONV_NET_S1>’

�

‘<CONV_NET_S1>’‘<REDUCE_DIM>‘ \ ‘,’

�

� ‘]’ �� ‘CONCAT’ ��

El esquema de conexiones de "<INCEPTION_RESNET_BLOCK>" (unavez más el número mínimo de ramas o repeticiones del bloque"<CONV_NET_S1>" es dos) combina una estructura interna tipo Inception(concatena en el espacio de características las salidas de sus ramas) con unaconexión con suma residual:

�� ‘[’ ‘[’‘,’

�‘<CONV_NET_S1>’ �� ‘]’ �� ‘CONCAT’ �� ‘,’ �� ‘direct’ �� ‘]’ �� ‘SUM’ ��

Es importante indicar que en este punto, hasta donde tiene conocimiento el autorde este TFM, estamos aportando un esquema de conexión nuevo debido, comohemos comentado anteriormente, al comportamiento del operador de sumaempleado. Dependiendo del número de características podemos encontrarnos antemódulos híbridos de un tipo que podríamos denominar "Inception-DPN". Elestudio formal y en detalle de su comportamiento queda una vez más fuera delalcance del TFM y se incluirá en las líneas futuras de investigación.


Entrando en la descripción a bajo nivel, la metagramática empleada para redesde clasificación tiene los siguientes parámetros:

fM: Número máximo de capas FC.

fS: Conjunto de dimensiones a emplear para las capas FC.

cD: Conjunto de dimensiones a emplear para las convoluciones.

cF: Conjunto de números de características a emplear para las convoluciones.

cpS: Conjunto de strides a emplear para las convoluciones y los pool.

pT: Conjunto de tipos de pool a emplear.

pD: Conjunto de dimensiones a emplear para los pool.

norm: Conjunto de normalizaciones a emplear.

dR: Conjunto de valores a emplear para el rate de los dropout.

Como parámetros para la metagramática se han empleado los siguientes para laspruebas:

fM: 3

fS: {8, 16, 32}

cD: {1, 2, 3}

cF: {2, 4, 8, 16, 32, 64, 128, 256}

cpS: {1,2}

pT: {‘MP’, ‘AP’}

pD: {2, 3}

norm: {‘None’, ‘BN’}

dR: {0.0, 0.1, 0.2, 0.3, 0.4}

Algunas decisiones en relación a los valores fijados para dichos parámetros decara a las pruebas se deben a los límites en los recursos disponibles a nivel dememoria en las GPUs o tiempo disponible para las pruebas. Otros sin embargo sehan establecido en base a las pruebas manuales o las primeras etapas de desarrollodel sistema evolutivo de diseño de arquitecturas de red.


Se justifica evitar el uso de dimensiones superiores a tres para las convolucionesy pools en base a los resultados obtenidos por (Szegedy y col. 2016) empleandoconvoluciones factorizadas para reemplazar a aquellas de dimensiones superiores.Igualmente se fija un límite en el número de capas FC por el coste computacional quesuponen en comparación con las convolucionales (especialmente a nivel de memorianecesaria para almacenar los pesos de las conexiones del modelo y sus gradientesasociados durante el entrenamiento).

De cara a los valores para el rate de los dropout se incluye el valor 0.0 comomecanismo para permitir al sistema inhabilitar dichos componentes ya que supresencia se fuerza por gramática. La decisión incluir forzosamente los operadoresde dropout se justifica empíricamente debido a su impacto en la capacidad degeneralización de los modelos tanto los evaluados manualmente comoevolucionados por el sistema. En este aspecto el coste del diseño manual se centramuchas veces en ajustar los parámetros rate de los módulos presentes de la maneramás adecuada.

A continuación se detalla la última versión de la metagramática empleada en elproyecto a fecha de escribir la presente memoria de TFM.

GfM,fS,cD,cF,cpS,pT,pD,norm,dR = {S=ANN, ΣN,cpS, ΣT,fS,cD,cF,cpS,pT,pD,norm,dR}

ΣN,cpS ={ ANN, HIGH_LEVEL_NET, REDUCE_DIM, FC, RESNET_BLOCK,INCEPTION_BLOCK, INCEPTION_RESNET_BLOCK, CONV_NET,CONV_BLOCK, CONV_NET_S1, CONV_BLOCK_S1,PARALLEL_CONV_NETS, PARALLEL_BLOCK_REDUCE_DIM,PARALLEL_CONV_NETS_REDUCE_DIM, REDUCE_DIM,PARALLEL_BLOCK, CONV, POOL, NORM, DROPOUT }∪ { CONV_Sk, POOL_Sk } ∀k ∈ cpS

ΣT,fS,cD,cF,cpS,pT,pD,norm,dR ={ ‘In’, ‘Out’, ‘flatten’, ‘SOFTMAX’, ‘direct’, ‘CONCAT’, ‘SUM’, ‘DROPOUT’, ‘[’,‘]’, ‘,’, ‘direct’ }∪ { CONV-i-j-k-l } ∀i ∈ cD, ∀j ∈ cF, ∀k ∈ cpS, ∀l ∈ norm∪ { p-m-k } ∀p ∈ pT, ∀m ∈ pD, ∀k ∈ cpS∪ { n } ∀n ∈ norm∪ { DROPOUT-r } ∀r ∈ dR∪ { FC-s } ∀s ∈ fS

〈ANN 〉 ::= ‘In’ 〈HIGH_LEVEL_NET 〉〈REDUCE_DIM 〉 ‘flatten’ 〈FC 〉 ‘SOFTMAX’‘Out’


〈HIGH_LEVEL_NET 〉 ::= 〈CONV_BLOCK 〉| 〈RESNET_BLOCK 〉| 〈INCEPTION_BLOCK 〉| 〈INCEPTION_RESNET_BLOCK 〉| 〈HIGH_LEVEL_NET 〉〈HIGH_LEVEL_NET 〉

〈FC 〉 ::= 〈FC_BLOCK 〉| 〈FC_BLOCK 〉〈DROPOUT 〉1 〈FC_BLOCK 〉1| ...| 〈FC_BLOCK 〉〈DROPOUT 〉1〈FC_BLOCK 〉1...〈DROPOUT 〉fM 〈FC_BLOCK 〉fM

〈CONV_NET 〉 ::= 〈CONV_BLOCK 〉 | 〈CONV_BLOCK 〉〈CONV_NET 〉

〈CONV_BLOCK 〉 ::= 〈CONV 〉〈DROPOUT 〉 | 〈CONV 〉〈DROPOUT 〉〈POOL〉

〈CONV_NET_S1 〉 ::= 〈CONV_BLOCK_S1 〉 | 〈CONV_BLOCK_S1 〉〈CONV_NET_S1 〉

〈CONV_BLOCK_S1 〉 ::= 〈CONV_S1 〉〈DROPOUT 〉 | 〈CONV_S1 〉〈DROPOUT 〉〈POOL_S1 〉

〈RESNET_BLOCK 〉 ::= ‘[’ 〈CONV_NET_S1 〉 ‘,’ ‘direct’ ‘]’ ‘SUM’

〈INCEPTION_BLOCK 〉 ::= 〈PARALLEL_BLOCK 〉 ‘CONCAT’| 〈PARALLEL_BLOCK_REDUCE_DIM 〉 ‘CONCAT’

〈PARALLEL_CONV_NETS 〉 ::= 〈CONV_NET_S1 〉 ‘,’ 〈CONV_NET_S1 〉| 〈PARALLEL_CONV_NETS 〉 ‘,’ 〈CONV_NET_S1 〉

〈PARALLEL_BLOCK_REDUCE_DIM 〉 ::= ‘[’〈PARALLEL_CONV_NETS_REDUCE_DIM 〉 ‘]’

〈PARALLEL_CONV_NETS_REDUCE_DIM 〉 ::= 〈CONV_NET_S1 〉〈REDUCE_DIM 〉 ‘,’ 〈CONV_NET_S1 〉〈REDUCE_DIM 〉

| 〈CONV_NET_S1 〉〈REDUCE_DIM 〉 ‘,’ 〈REDUCE_DIM 〉| 〈PARALLEL_CONV_NETS_REDUCE_DIM 〉 ‘,’ 〈CONV_NET_S1 〉

〈REDUCE_DIM 〉

〈REDUCE_DIM 〉 ::= 〈CONV_S2 〉| 〈POOL_S2 〉

〈INCEPTION_RESNET_BLOCK 〉 ::= ‘[’ 〈PARALLEL_BLOCK 〉 ‘CONCAT’ ‘,’ ‘direct’‘]’ ‘SUM’

〈PARALLEL_BLOCK 〉 ::= ‘[’ 〈PARALLEL_CONV_NETS 〉 ‘]’

〈CONV 〉 ::= CONV-i-j-k-l | ... ∀i ∈ cD, ∀j ∈ cF, ∀k ∈ cpS, ∀l ∈ norm

〈CONV_Sk〉 ::= CONV-i-j-k-l | ... ∀i ∈ cD, ∀j ∈ cF, ∀k ∈ cpS, ∀l ∈ norm


〈POOL〉 ::= p-m-k | ... ∀p ∈ pT, ∀m ∈ pD, ∀k ∈ cpS

〈POOL_Sk〉 ::= p-m-k | ... ∀p ∈ pT, ∀m ∈ pD, ∀k ∈ cpS

〈NORM 〉 ::= n | ... ∀n ∈ norm

〈DROPOUT 〉 ::= ‘DROPOUT-r’ | ... ∀r ∈ dR

〈FC_BLOCK 〉 ::= ‘FC-s’ | ... ∀s ∈ fS

3.6.4. Función de fitness

VGNet combina VBrain y V3gie, empleando metagramática para la generacióny evolución de poblaciones que codifican distas arquitecturas de red en forma de lascitadas expresiones que son transformadas a código. Para ello el fenotipo de cadaindividuo, en forma de código Python para la librería VBrain, es evaluado usandodos conjuntos de datos separados y se le asigna un fitness.

En función del tipo de particionamiento empleado se usarán dos o tres conjuntosde datos separados.

Entrenamiento/Test: se entrena la red desde cero con el conjunto deentrenamiento durante un número de epochs determinado o hasta unmáximo tiempo. El fitness se obtiene con el conjunto de test.

Entrenamiento/Validación/Test: en este caso VGNet no emplea los ejemplosdel conjunto de test, usando en su lugar el conjunto de validación para elcálculo del fitness.

El particionamiento del conjunto de datos empleados entre conjunto deentrenamiento y conjunto para calcular el fitness (podemos llamarlo conjunto detest o validación dependiendo del esquema de particionamiento empleado en dos otres subconjuntos) se puede realizar de tres formas distintas:

Una sola vez por experimento: todas las generaciones y por lo tanto todos losindividuos emplean los mismos subconjuntos.

Una vez por generación: se emplean los mismos subconjuntos entre individuosdentro de la misma generación.

Una vez por individuo: como se verá en la sección de resultados se empleódurante las primeras pruebas y fue descartada.

3.7. RESULTADOS 67

Una vez una red representada por un individuo dado se ha entrenado de cerosobre el conjunto de entrenamiento, su fitness se calcula sobre el otro subconjunto(lo llamaremos en este ejemplo conjunto de test por simplicidad) como:

fitness(indv) =1

1 + 1n·∑lastTrainEpoch

i=lastTrainEpoch−(n−1) rms(indv, test, i)

Usamos n=3 para suavizar el efecto de las oscilaciones del RMS.

3.7. Resultados

En esta sección se presentan tanto los detalles de la plataforma de pruebascomo los resultados obtenidos. Dichos resultados se presentan cronológicamente yagrupados por la versión del dataset empleada (las dimensiones del mismo y otrosdetalles internos afectan a las métricas de los modelos). En cada caso se indican lasdiferencias concretas con la versión final de parámetros internos empleados ocambios en la metagramática. Se indicará igualmente el tipo de particionamientoempleado en los datos y el momento el cual se realiza dicha división.

Téngase en cuenta que hasta las últimas pruebas no se realizaba división en tressubconjuntos (entrenamiento, validación y test) dado que solamente se buscabaobservar la evolución de las poblaciones. Además el dataset se encontraba en unaversión muy temprana y no se consideraban significativos los resultados obtenidospor la presencia de errores al etiquetar las teselas. En cualquier caso seespecificarán en cada paso los detalles relevantes.

3.7.1. Hardware empleado

Durante la realización del trabajo y a fecha de la escritura de la presentememoria por motivos presupuestarios de carácter administrativo el IGN no hapodido adquirir aún los servidores con los que se contaba para la realización delproyecto. En ese sentido y siguiendo con el plan de gestión de riesgos se adoptandiversas medidas que se detallan a continuación y tienen como consecuenciatrabajar durante el desarrollo, depuración y en la fase de experimentación (incluyeciertos ajustes para llegar a la metagramática anteriormente presentada, revisionesdel dataset y empleo de versiones distintas del mismo) sobre tres servidoresdistintos con capacidades de proceso muy diferentes. Las características técnicas dedichos servidores se detallarán más adelante de forma conjunta.

En primer lugar el grupo de investigación Mercator en colaboración con el IGNlleva a cabo un plan de contingencia consistente en la compra de un servidor condos GPUs idénticas de alta gama en el cual poder realizar aquellas pruebas conmayores requisitos de carga de trabajo. Por otra parte se facilita el acceso a unservidor ubicado en el INSIA con dos GPUs pero de distinto tipo y capacidad.


Finalmente dentro de la Escuela Técnica Superior de Ingeniería de SistemasInformáticos (ETSISI) se dispone de un equipo de sobremesa con una GPUbastante más modesta de cara al desarrollo y depuración de la librería, así comopara la realización de pruebas de menor envergadura.

Los detalles hardware de los servidores se pueden ver en la (Tabla 3.4).

Servidor GPUs CPU RAM

Cartobot1 2× RTX 2080Ti (4352 núcleos CUDA)11GB

i7-8700 3.2GHz 64GB

Kaneda TITAN Xp (3840 núcleos CUDA) 12GBGTX 1080 (2560 núcleos CUDA) 8GB

i7-6700K 4GHz 16GB

Joker GTX 1060 (1280 núcleos CUDA) 6GB i7-8700 3.2GHz 16GB

Tabla 3.4: VGNet: Detalles hardware de los servidores empleados.

Llegados a este punto en caso del servidor Kaneda (acceso cedido por el INSIA),que cuenta con dos GPUs de distinto tipo, nos encontramos con un impacto elrendimiento. Esto es debido a que la librería VBrain, como se describíaanteriormente, emplea paralelismo a nivel de datos. Al ejecutar sobre dos GPUs dedistinto tipo puede pasar que la de mayor capacidad termine su proceso antes quela otra, obligándonos a esperar.

3.7.2. Experimentos con 100 ejemplos por clase

Para el primer grupo de pruebas se parte de un subconjunto compuesto por lasprimeras cien imágenes para cada clase.El objetivo de esta fase, aparte de depurar el sistema, era realizar una primeraevaluación de sus capacidades, observar tiempos necesarios para los experimentos,así como el impacto sobre los resultados del tamaño de la población y el número deepochs de entrenamiento de cada individuo.

Además, a pesar de contemplarse la normalización LRN en la gramática, al noestar implementada para la codificación NCHW, está era reemplazada en la fase degeneración de código por None. Durante las pruebas hasta la versión final, estehecho conlleva que a nivel efectivo se dispone solamente de dos tipos denormalización (BN o ninguna), teniendo la segunda el doble de probabilidad deseleccionarse que la primera. Entiéndase que todos los resultados previos a laversión final de la metagramática se presentan con el ánimo de ilustrar todo eltrabajo realizado y justificar las decisiones tomadas en cada paso del proyecto.

En este contexto se realizan tres experimentos; los parámetros comunes empleadosson los siguientes:

3.7. RESULTADOS 69

Empleamos solamente las primeras 100 imágenes por clase

Se amplia el conjunto de imágenes de entrenamiento añadiendotransformaciones artificiales, concretamente rotaciones e imágenes en espejo.

Se divide aleatoriamente para cada experimento el conjunto de datos entradaentre entrenamiento y test en una proporción 75/25 (no se diferencia unconjunto de validación en este punto).

Uso de la CPU como dispositivo compartido.

Epochs de entrenamiento máximos por red 1000 (test 1 y 2a) y 200 (test 2b).

Límite de tiempo máximo para entrenar cada red 60 minutos (test 1 y 2b) y120 minutos en (test 2a).

Alpha de entrenamiento de las redes 1e-4.

Profundidad máxima del árbol durante la generación y/o mutación 10.

Parámetros del algoritmo genético: tamaño del torneo 4, probabilidad de cruce0.7, probabilidad de mutación 0.05.

En las versiones de la metagramática anteriores a la v3 el símbolo no terminal<HIGH_LEVEL_NET> usa en su primera producción <CONV_NET> enlugar de <CONV_BLOCK> esto favorece levemente la generación de estetipo de redes.

Los detalles que diferencian cada experimento y su tiempo de ejecución puedenobservarse en la (Tabla 3.5). Las gráficas de evolución de accuracy y RMS se puedenconsultar en (Fig. 3.12). La versión de metagramática que fuerza la presencia demódulos dropout se denominará aquí en adelante versión 2 (v2).

Test Servidor(GPUs)

Divisióntrain/test

Gramáticafuerzadropout

Población Generaciones Tiempo

1 Cartobot1(2) individuo No 20 6 2d 14h2a Joker(1) individuo No 10 8 3d 14h2b Joker(1) generación Si 10 8 1d 23h

Tabla 3.5: Parámetros de experimentos para 100 ejemplos por clase con aumentaciónde datos.


Se mide además la diversidad de la población en número de individuos distintospor generación para cada experimento:

Test 1 (20 individuos): 20, 20, 20, 20, 20, 19

Test 2a (10 individuos): 10, 10, 10, 9, 8, 7, 8, 10

Test 2b (10 individuos): 10, 10, 8, 6, 8, 8, 4, 4

Esto nos permite observar que en el caso de poblaciones más pequeñas nosencontramos con perdida de diversidad, que puede llevar incluso a unestancamiento como es el caso del test 2b.

Por otra parte en relación al particionamiento (entre datos de entrenamiento yaquellos empleados para el cálculo del fitness de la red) para cada individuo enlugar de compartirlo, al menos a nivel de generación, se observan generalmentefuertes oscilaciones (Fig. 3.12b) y se considera injusta la comparación empleandoeste método. Esto es debido a que realmente los subconjuntos generados (y máscon tan pocos ejemplos) pueden contener fuertes desequilibrios entre clases o en ladificultad de los ejemplos a clasificar. Igualmente se incluye a nivel de gramáticala presencia forzosa del módulo de dropout (puede inhibirse mediante el parámetrorate = 0) dado que en general ofrece redes que generalizan más y resultados con uncomportamiento más consistente en los experimentos.

Otro detalle relevante llegados a este punto, es la confirmación de las oscilacionesque presentan las métricas de una misma arquitectura de red ante distintosparticionamientos del conjunto de entrenamiento/test, distintas inicializaciones delos pesos u orden de los ejemplos de entrenamiento (debidos al shuffle). Tomemospor ejemplo la arquitectura que presenta el mejor resultado en el test 2b (Fig. 3.13,obsérvese que sirve además como ejemplo de un dropout "desactivado").

Esta red se evaluó en múltiples ocasiones durante el experimento (los datos semuestras para el conjunto sobre el que se evalúa el fitness de la red), entre otrosmotivos debido a la pérdida de diversidad de la población durante el mismo:

Generación 5 Individuo 0: Accuracy 0.540 RMS 0.581 Epochs 200







3.7. RESULTADOS 71

(a) Test 1

(b) Test 2a

(c) Test 2b

Figura 3.12: Evolución por generación en experimentos con 100 primeros ejemploscon aumentación. Valores de RMS y Accuracy (Acc) (mínimos, máximos y medios)por generación.


Figura 3.13: Ejemplo de red con oscilaciones en métricas debidas a diferencias en elcontexto de evaluación.


Estas oscilaciones no obstante resultan más acentuadas en esta fase debido alreducido número de ejemplos empleado y ya se observaron con los modelosevaluados con k-fold en las primeras pruebas (Fig. 3.4 y Fig. 3.5).

3.7.3. Experimentos con 800 ejemplos por clase

Se modifican solamente los siguientes parámetros respecto a los empleadosanteriormente:

Empleamos 800 imágenes por clase

Límite de tiempo máximo para entrenar cada red 60 minutos en los tresexperimentos realizados.

División train/test por generación (compartida por individuos de la misma).

Metagramática v2 (la verisón que fuerza la presencia de operadores de dropoutcuyo parámetro rate puede ser cero).

Epochs de entrenamiento máximos por red 200.

Test Servidor(GPUs)

Población Prob.mutación

Generaciones Tiempo

1 Cartobot1(2) 20 0.05 12 8d 20h2 Joker(1) 10 0.05 4 1d 19h3 Joker(1) 10 0.20 8 2d 18h

Tabla 3.6: Parámetros de experimentos para 800 ejemplos por clase con aumentaciónde datos.

Podemos observar las métricas recolectadas durante los experimentos (acuraccyy RMS) en (Fig. 3.14). En el test 2 se observa nuevamente un problema de pérdidade diversidad (medida como número de individuos estrictamente distintos porgeneración) debido al reducido tamaño de la población. En el test 3 se solventaaumentando la probabilidad de mutación de forma significativa.

3.7. RESULTADOS 73

(a) Test1

(b) Test2

(c) Test3

Figura 3.14: Evolución por generación en experimentos con 800 ejemplos conaumentación de datos. Valores de RMS y Accuracy (Acc) (mínimos, máximos ymedios) por generación.


En relación a los resultados obtenidos o problemas encontrados, en el caso delentorno de una sola GPU (servidor Joker) al reducir el límite de tiempo de ejecucióna una hora, se observa que muchos modelos ven su entrenamiento interrumpido deforma prematura (en ocasiones el modelo prácticamente queda sin entrenar). Unalista con ejemplos de métricas para algunos individuos que sufren este problemadentro del test 2 se encuentra en la (Tabla 3.7).

Epochsentrenados

Accuracy RMS

6 0.4996 0.623622 0.5229 0.661267 0.5346 0.568536 0.5408 0.622788 0.5695 0.60686 0.5058 0.6195

Tabla 3.7: Efecto de un límite de tiempo de entrenamiento demasiado reducido:ejemplos de test 2 generación 1. Métricas para el conjunto en que evaluamos elfitness de la red.

En esta segunda batería de pruebas con más ejemplos empezamos a encontrarresultados mejores como es el caso de la mejor arquitectura encontrada en el test 1(generación 10 modelo 17) que obtiene en test (con el particionamiento de lageneración 10): Accuracy 0.89 RMS 0.297 Epochs 200 (Fig. 3.15). Este modeloresponde a la expresión de arquitectura:In CONV-2-128-2-BN DROPOUT-0.1 CONV-3-256-2-LRN DROPOUT-0.2AP-2-1 CONV-2-128-2-BN DROPOUT-0.1 CONV-2-128-2-BN DROPOUT-0.2AP-2-1 CONV-3-4-2-BN DROPOUT-0.2 AP-2-1 CONV-3-256-2-LRNDROPOUT-0.2 AP-2-1 CONV-2-128-2-BN DROPOUT-0.1 CONV-3-4-2-BNDROPOUT-0.1 AP-2-1 CONV-3-4-2-BN DROPOUT-0.1 AP-3-2 flatten FC-16SOFTMAX Out .

Su código asociado:

class vgnet_model_17 (VBrain_Model ) :def in i t_model_layers ( s e l f ) :

layer_0 = s e l f . model_inputlayer_1 = s e l f . conv2d_block ( layer_0 ,128 , s i z e =2, s t r i d e =2,

normal i z e r=s e l f . batch_normal izat ion )layer_2 = s e l f . dropout ( layer_1 , r a t e =0.1)layer_3 = s e l f . conv2d_block ( layer_2 ,256 , s i z e =3, s t r i d e =2,

normal i ze r=None )layer_4 = s e l f . dropout ( layer_3 , r a t e =0.2)

3.7. RESULTADOS 75

layer_5 = s e l f . average_pool ( layer_4 , s i z e =2, s t r i d e =1)layer_6 = s e l f . conv2d_block ( layer_5 ,128 , s i z e =2, s t r i d e =2,

normal i z e r=s e l f . batch_normal izat ion )layer_7 = s e l f . dropout ( layer_6 , r a t e =0.1)layer_8 = s e l f . conv2d_block ( layer_7 ,128 , s i z e =2, s t r i d e =2,

normal i z e r=s e l f . batch_normal izat ion )layer_9 = s e l f . dropout ( layer_8 , r a t e =0.2)layer_10 = s e l f . average_pool ( layer_9 , s i z e =2, s t r i d e =1)layer_11 = s e l f . conv2d_block ( layer_10 , 4 , s i z e =3, s t r i d e =2,

normal i z e r=s e l f . batch_normal izat ion )layer_12 = s e l f . dropout ( layer_11 , r a t e =0.2)layer_13 = s e l f . average_pool ( layer_12 , s i z e =2, s t r i d e =1)layer_14 = s e l f . conv2d_block ( layer_13 ,256 , s i z e =3, s t r i d e =2,

normal i ze r=None )layer_15 = s e l f . dropout ( layer_14 , r a t e =0.2)layer_16 = s e l f . average_pool ( layer_15 , s i z e =2, s t r i d e =1)layer_17 = s e l f . conv2d_block ( layer_16 ,128 , s i z e =2, s t r i d e =2,

normal i z e r=s e l f . batch_normal izat ion )layer_18 = s e l f . dropout ( layer_17 , r a t e =0.1)layer_19 = s e l f . conv2d_block ( layer_18 , 4 , s i z e =3, s t r i d e =2,

normal i z e r=s e l f . batch_normal izat ion )layer_20 = s e l f . dropout ( layer_19 , r a t e =0.1)layer_21 = s e l f . average_pool ( layer_20 , s i z e =2, s t r i d e =1)layer_22 = s e l f . conv2d_block ( layer_21 , 4 , s i z e =3, s t r i d e =2,

normal i z e r=s e l f . batch_normal izat ion )layer_23 = s e l f . dropout ( layer_22 , r a t e =0.1)layer_24 = s e l f . average_pool ( layer_23 , s i z e =3, s t r i d e =2)layer_25 = s e l f . f l a t e n ( layer_24 )layer_26 = s e l f . f c ( layer_25 , 16)layer_27 = s e l f . f c ( layer_26 , 2 , a c t f=None )out = s e l f . softmax ( layer_27 )

No obstante todavía no vamos a considerar este resultado como relevante nicompletamente fiable por dos motivos: las reducidas dimensiones del conjunto deentrenamiento y que si bien los pesos de la red no tienen información sobre elconjunto de test, la arquitectura si ha podido verse afectada por ejemplos que enotra generación estuviesen en la partición de entrenamiento. En las pruebas finales,con la última versión del dataset, esto último se solventará empleando unparticionamiento entrenamiento/validación/test para garantizar la imparcialidadde la métrica que se ofrece para el modelo diseñado por VGNet.


Figura 3.15: Entrenamiento del mejor individuo con 800 ejemplos por clase, test1 (generación 10 modelo 17). El prefijo TEST indica valores obtenidos sobre elconjunto en que se evalúa el fitness de la red (en este caso se empleaba solamenteparticionamiento entrenamiento/test).

En este punto de los experimentos se observa como las arquitecturas nocompletamente convolucionales tienden a sobreajustar, en el sentido de queparecen aprender de memoria sin generalizar en (Fig. 3.16) podemos observar estecomportamiento en dos modelos: uno con arquitectura de conexión DPN (sumaresidual y concatenación del resto de canales) y el otro tipo Inception(concatenación de canales). Este comportamiento se atribuye al relativamentereducido tamaño del número de ejemplos si no se tiene en cuenta el procedimientode aumentación de datos (al emplear giros podría no aportar datos realmentenuevos en el caso de diferenciar por textura y/o color).

3.7.4. Experimentos con dataset final

Para la última versión disponible del dataset el conjunto de ejemplos se componede:

2545 Imágenes de la categoría "contiene vías de transporte".

3370 Imágenes de la categoría "no contiene vías de transporte".

3.7. RESULTADOS 77

(a) g0m4

(b) g0m9

(c) g0m4 entrenamiento (d) g0m9 entrenamiento

Figura 3.16: Sobreajuste en arquitecturas no puramente convolucionales: 800ejemplos por clase, test 1. El prefijo TEST indica valores obtenidos sobre elconjunto en que se evalúa el fitness de la red (en este caso se empleaba solamenteparticionamiento entrenamiento/test).


En las secciones siguientes se detallan los resultados obtenidos con losexperimentos durante la última fase de desarrollo y depuración del sistema.Finalmente se ofrecen resultados de las pruebas con la versión definitiva ypresentada en este TFM.

Pruebas con metagramática v2b

En este punto se elimina finalmente LRN de los tipos de normalización en lametagramática (versión v2b) para reflejar su estado de no implementado con elformato NCHW y por lo tanto su ausencia de implementación en la libreríaVBrain. También se emplea un límite tiempo máximo de entrenamiento por red de120 minutos. Las poblaciones en ambos casos son de 20 individuos, diferenciándoseambos experimentos en la profundidad máxima aplicada a GBIM y el uso o no deaumentación artificial del conjunto de entrenamiento. Detalles de las pruebas en la(Tabla 3.8).

Si bien se emplea el servidor Kaneda (2 GPUs heterogéneas, lo cual hace alsistema funcionar al ritmo de la menos potente al haberse diseñado VBrain paratrabajar específicamente con sistemas homogéneos) el rendimiento respecto aCartobot1 es claramente inferior lo cual impide una comparación directa entiempos de ejecución entre experimentos. No obstante con ánimo de que el informeresulte lo más exhaustivo posible se incluyen dichos tiempos igualmente.

Test Servidor(GPUs)

Prof. Máx. Aumentación Generaciones Tiempo

1 Kaneda(2) 10 Si 24 10d 4.5h2 Cartobot1(2) 20 No 8 10d 15h

Tabla 3.8: Parámetros de experimentos para 2.5k y 3.3k ejemplos por clase.

El motivo de no emplear aumentación de datos en el experimento de mayorprofundidad de generación es compensar el tiempo de ejecución al estar evaluandode forma general modelos de red de mayores dimensiones y coste computacional.Incluso con este detalle y a pesar de ejecutarse el test 2 en el servidor con máspotencia el tiempo continúa siendo mayor sin mejoras aparentes en los resultados(Fig. 3.17 y Tabla 3.9). La diferencia en el número de generaciones se debe altiempo fijado como límite para estos dos experimentos.

Las mejores arquitecturas encontradas por ambos experimentos se muestran acontinuación.Mejor resultado Test1 (generation19-model5):In CONV-2-128-2-BN DROPOUT-0.1 MP-2-1 CONV-2-128-2-BN DROPOUT-0.3CONV-2-128-2-BN DROPOUT-0.1 MP-3-2 CONV-2-128-2-BN DROPOUT-0.3

3.7. RESULTADOS 79

(a) Test1 (b) Test2

Figura 3.17: Evolución por generación en experimentos con 2.5k y 3.3k ejemplospor clase. Valores de RMS y Accuracy (Acc) (mínimos, máximos y medios) porgeneración.

Test Mejor Individuo Accuracy RMS Epochs

1 generation19-model5 0.877 0.306 2002 generation7-model1 0.84 0.333 119

Tabla 3.9: Mejores resultados de experimentos con 2.5k y 3.3k ejemplos por clase.Métricas para el conjunto empleado para el cálculo del fitness.

MP-2-1 CONV-2-128-2-BN DROPOUT-0.1 MP-3-2 MP-3-2 flatten FC-8SOFTMAX Out

Mejor resultado Test2 (generation7-model1):In CONV-2-256-2-BN DROPOUT-0.3 AP-3-2 CONV-2-256-2-BN DROPOUT-0.3AP-3-2 CONV-3-16-2-None DROPOUT-0.1 AP-2-2 CONV-3-8-2-BN flatten FC-8SOFTMAX Out

Resultados finales con metagramática v3

En este punto se presentan los resultados finales del TFM, con las últimasversiones disponibles del dataset y la metagramática. Se describen los parámetrosde los experimentos en la (Tabla 3.10) y la evolución durante los experimentos(Fig. 3.18). Entre ellos el primer experimento (test 1) emplea particionamientosolamente entrenamiento/test (por tener un punto de comparación con resultadosanteriores). El resto de pruebas se ha realizado particionamientoentrenamiento/validación/test y en ese sentido el fitness para el diseño de laarquitectura, en estos últimos tests, emplea métricas calculadas sobre el conjuntode validación. Se ha garantizado en estos casos que el conjunto final de test no seha empleado de ninguna manera para ajustar la arquitectura de los modelos.Como se ha comentado anteriormente al emplear solo particionamientoentrenamiento/test aunque los pesos no entrenen con los datos de test la


arquitectura si se beneficia del conocimiento contenido en dicho subconjunto.

Test Servidor(GPUs)

Parámetros Generaciones Tiempo

1 Joker(1) train/test (75/25) splitgeneration, pob. 10, p-mut0.20. No emplea conjunto devalidación.

18 5d 2.5h

2 Cartobot1(2) train/validationsplit experiment,train/validation/test (72/18/10),pob. 20, prof.máx 10, p-mut 0.05

5 7d 16h

3 Kaneda(2) train/validationsplit experiment,train/validation/test (72/18/10),pob. 20, prof.máx 10, p-mut0.05, sin aumentación

19 7d 12h

5 Kaneda(2) train/validationsplit experiment,train/validation/test (72/18/10),pob. 40, prof.máx 20, p-mut0.05, sin aumentación

12 19d 21h

6 Cartobot1(2) train/validation split generation,train/validation/test (72/18/10),pob. 40, prof.máx 20, p-mut 0.05,sin aumentación

21 13d 14h

7 Cartobot1(2) train/validationsplit experiment,train/validation/test (72/18/10),pob. 40, prof.máx 20, p-mut0.05, sin aumentación

16 5d 20h

Tabla 3.10: Parámetros de experimentos para 2.5k y 3.3k ejemplos por clase,metagramática v3.

En la (Tabla 3.11) podemos ver las métricas de los mejores individuos de cadaexperimento obtenidas por VGNet en el proceso de diseño (corresponden al conjuntode datos empleado para calcular el fitness de los individuos). En el caso del test6 se incluyen además los dos mejores resultados de arquitecturas no puramenteconvolucionales a modo de referencia.

Podemos observar que el test 7 no dió buenos resultados. Se puede deber a doscausas: tener una partición del conjunto de entrenamiento realizada a nivel deexperimento (no varía por generación) desfavorable para el aprendizaje y que eltest sufrió una pérdida de diversidad severa en la población desde una etapa

3.7. RESULTADOS 81

(a) Test 1 (b) Test 2

(c) Test 3 (d) Test 5

(e) Test 6 (f) Test 7

Figura 3.18: Evolución por generación en experimentos con 2.5k y 3.3k ejemplos porclase, metagramática v3. Valores de RMS y Accuracy (Acc) (mínimos, máximos ymedios) por generación.


relativamente temprana. Esto sugiere que una probabilidad de mutación asociadadinámicamente a una medidad de diversidad podría resultar de utilidad.Concretamente si medimos el número de expresiones distintas por generación(recordando que tenemos una población de tamaño 40 en este caso) obtenemos lalista siguiente [39, 38, 37, 30, 22, 18, 15, 12, 13, 10, 12, 10, 9, 9, 11].

Test Mejor Modelo Accuracy RMS EpochsTrain

1 gen17model1 0.824 0.353 1132 gen3model6

NFC0.886 0.295 200


NFC0.864 0.339 200


NFC0.856 0.344 200

6 gen18model0NFC

0.854 0.333 200

7 gen15model36 0.746 0.423 200

Tabla 3.11: Arquitecturas para 2.5k y 3.3k ejemplos por clase, metagramática v3.Dichos datos han sido calculados con el conjunto de validación en casos que disponende uno (solamente en el experimento 1 se usa el conjunto de test al no haber uno devalidación diferenciado), es decir el conjunto empleado para calcular el fitness de lared en cada caso. Se usa por comodidad NFC para indicar Non Fully Convolutional.

Las arquitecturas de red correspondientes a los modelos con los mejores resultadosindicados en la (Tabla 3.11) se muestran a continuación, incluyendo para las cincocon los mejores resultados en validación, además de su expresión, un gráfico parafacilitar su lectura.

Modelo test1 gen17model1Expresión: In CONV-2-128-2-BN DROPOUT-0.3 CONV-2-128-2-BNDROPOUT-0.4 CONV-3-8-2-None DROPOUT-0.1 MP-2-1 CONV-1-4-1-BNDROPOUT-0.1 MP-2-1 CONV-2-128-2-BN DROPOUT-0.1 CONV-1-4-2-BNflatten FC-32 SOFTMAX Out

Modelo test2 gen3model6. Gráfico en la (Fig. 3.19).Expresión: In CONV-2-64-2-BN DROPOUT-0.2 CONV-2-16-2-None DROPOUT-0.1 CONV-2-32-1-BN DROPOUT-0.3 CONV-2-256-2-BN DROPOUT-0.0 AP-3-1 CONV-3-32-1-BN DROPOUT-0.4 AP-2-2 [ CONV-2-16-1-BN DROPOUT-0.1 ,CONV-1-256-1-None DROPOUT-0.1 AP-3-1 CONV-2-16-1-BN DROPOUT-0.2 ]CONCAT CONV-3-2-2-BN flatten FC-8 SOFTMAX Out

3.7. RESULTADOS 83

Figura 3.19: Modelo test2 gen3model6.

Modelo test3 gen17model6. Gráfico en la (Fig. 3.20).Expresión: In CONV-3-64-2-BN DROPOUT-0.1 MP-3-2 CONV-1-64-1-BNDROPOUT-0.1 MP-3-2 CONV-1-64-1-BN DROPOUT-0.1 CONV-3-64-2-BNDROPOUT-0.1 MP-3-2 CONV-1-64-1-BN DROPOUT-0.1 CONV-1-64-1-BNDROPOUT-0.1 CONV-3-64-2-BN DROPOUT-0.3 MP-3-2 CONV-3-64-2-BNDROPOUT-0.1 MP-3-2 MP-3-2 flatten FC-8 SOFTMAX Out


Modelo test5 gen9model3. Gráfico en la (Fig. 3.21).Expresión: In CONV-2-64-2-BN DROPOUT-0.2 MP-3-1 CONV-3-256-2-BNDROPOUT-0.0 CONV-2-64-2-BN DROPOUT-0.2 MP-3-1 CONV-3-256-2-BNDROPOUT-0.2 AP-3-2 CONV-3-8-1-BN DROPOUT-0.2 CONV-2-64-2-BN


DROPOUT-0.2 MP-3-1 CONV-3-256-2-BN DROPOUT-0.2 AP-3-2CONV-2-16-1-BN DROPOUT-0.0 AP-3-1 CONV-2-64-2-BN DROPOUT-0.0MP-3-1 CONV-2-2-2-BN DROPOUT-0.3 AP-3-1 [ CONV-3-128-1-NoneDROPOUT-0.3 AP-2-1 CONV-1-256-1-None DROPOUT-0.1 MP-3-1 , direct ]SUM CONV-2-64-2-BN DROPOUT-0.2 MP-3-1 CONV-1-32-2-NoneDROPOUT-0.3 AP-3-1 CONV-2-64-2-BN DROPOUT-0.4 MP-2-2CONV-3-8-1-BN DROPOUT-0.2 CONV-1-32-2-None DROPOUT-0.3 AP-3-1CONV-2-256-1-BN DROPOUT-0.4 MP-3-1 AP-2-2 flatten FC-16 SOFTMAX Out


Modelo test6 gen18model37. Gráfico en la (Fig. 3.22).Expresión: In CONV-3-64-2-BN DROPOUT-0.0 MP-3-1 CONV-3-64-2-BNDROPOUT-0.0 MP-3-1 CONV-1-128-2-None DROPOUT-0.1 AP-2-1CONV-3-64-2-BN DROPOUT-0.3 MP-3-1 CONV-1-64-1-None DROPOUT-0.4AP-2-1 CONV-1-256-1-BN DROPOUT-0.3 MP-3-1 CONV-3-64-2-BNDROPOUT-0.0 MP-3-1 CONV-2-256-2-BN DROPOUT-0.2 CONV-1-2-2-Noneflatten FC-16 SOFTMAX Out

Modelo test6 gen17model38. Gráfico en la (Fig. 3.23).Expresión: In CONV-3-64-2-BN DROPOUT-0.0 MP-3-1 CONV-1-128-2-NoneDROPOUT-0.1 AP-3-2 CONV-2-64-1-None DROPOUT-0.4 CONV-2-256-2-BNDROPOUT-0.0 CONV-3-4-2-None DROPOUT-0.0 MP-3-1 CONV-1-128-2-NoneDROPOUT-0.4 AP-3-2 CONV-2-256-2-BN DROPOUT-0.3 AP-2-1 [ [CONV-2-16-1-BN DROPOUT-0.0 , CONV-2-4-1-BN DROPOUT-0.2 AP-2-1

3.7. RESULTADOS 85


CONV-2-4-1-None DROPOUT-0.0 CONV-3-256-1-None DROPOUT-0.2 AP-2-1CONV-1-64-1-BN DROPOUT-0.1 MP-3-1 CONV-2-16-1-BN DROPOUT-0.1CONV-3-256-1-BN DROPOUT-0.3 ] CONCAT , direct ] SUM CONV-2-256-2-BNDROPOUT-0.2 CONV-2-64-1-None DROPOUT-0.4 CONV-1-2-2-None flattenFC-8 SOFTMAX Out


Modelo test6 gen18model0Expresión: In CONV-3-64-2-BN DROPOUT-0.0 MP-3-1 CONV-1-128-2-NoneDROPOUT-0.3 AP-2-1 CONV-3-4-2-None DROPOUT-0.0 MP-3-1CONV-1-128-2-None DROPOUT-0.4 AP-3-2 CONV-1-256-1-BN DROPOUT-0.3MP-3-1 [ [ CONV-2-16-1-BN DROPOUT-0.0 , CONV-2-4-1-BN DROPOUT-0.2AP-2-1 CONV-2-4-1-None DROPOUT-0.0 CONV-3-256-1-None DROPOUT-0.4AP-2-1 CONV-1-64-1-BN DROPOUT-0.4 MP-3-1 CONV-2-16-1-BNDROPOUT-0.1 CONV-3-256-1-BN DROPOUT-0.3 ] CONCAT , direct ] SUM


CONV-2-256-2-BN DROPOUT-0.2 CONV-2-64-1-None DROPOUT-0.4CONV-1-2-2-None flatten FC-8 SOFTMAX Out

Modelo test7 gen15model36Expresión: In CONV-2-16-2-BN DROPOUT-0.0 MP-3-2 MP-3-2 flatten FC-32SOFTMAX Out

Los resultados de los cinco mejores (sobre sus respectivos conjuntos de test)modelos para sus conjuntos de test se han calculado y se presentan conjuntamentelas métricas obtenidas en la (Tabla 3.12). Para mayor nivel de detalle sobre losresultados de cada modelo se incluyen además las matrices de confusión en las(Tablas 3.13, 3.14, 3.15, 3.16 y 3.17). En todos los casos se ha empleado en laevaluación el mismo tamaño de lote que se usó en entrenamiento para cadamodelo.

Modelo Accuracy TasadeError

Sensibilidad Especificidad

test2gen3model6 0.846 0.154 0.875 0.811test3gen17model6 0.868 0.132 0.880 0.853test5gen9model3 0.894 0.106 0.901 0.884test6gen18model37 0.875 0.125 0.886 0.861test6gen17model38 0.873 0.127 0.920 0.821

Tabla 3.12: Métricas de los cinco mejores modelos asociadas al conjunto de test.El porcentaje de ejemplos positivos de los distintos conjuntos de test empleados esaproximadamente del 56 %.

RealSi No Total

Predicción Si 287 41 328No 50 214 264Total 337 255 592

Tabla 3.13: test2gen3model6: matriz de confusión asociada al conjunto de test.

RealSi No Total



3.7. RESULTADOS 87

RealSi No Total



RealSi No Total



RealSi No Total



Problemas de etiquetado detectados en el dataset

Revisando los resultados de uno de los modelos entrenados, concretamente losmal clasificados, nos encontramos ante el siguiente problema (Fig. 3.24) que afectaa la última versión del dataset. En las hojas de datos de "ochagavia" y "etxalar"se han etiquetado dentro del conjunto "contiene vías" imágenes en las cuales, apesar de existir efectivamente carreteras y/o caminos, estas están ocultascompletamente o en un porcentaje muy alto por las copas de los árboles. Es decir,el operador no ha indicado realmente si la ortofoto presenta una vía visible,solamente la correspondencia entre ortofoto y cartografía. Para solucionarlo seañadirá una nueva categoría "Categoría poco clara" y se realizará la limpieza de laúltima versión del dataset en base a los resultados obtenidos por las redesgeneradas por VGNet.

Por otra parte aún existen teselas etiquetadas erróneamente dentro del conjuntode "contiene vías". Es comprensible esperar cierto nivel de error por parte decualquier operador humano durante un proceso de este tipo, no obstanteigualmente se insta a la limpieza del dataset.


Es importante entender que este hecho (errores en el etiquetado y presencia deruido) afecta negativamente a la capacidad de cualquier modelo para aprender y porello los resultados presentados en el presente TFM no han podido superar el 89.8 %de Accuracy (la empleada en el cálculo del fitness) en ningún caso. Igualmente seobserva el valor de los resultados de clasificación de los modelos generados, inclusoen los casos de error al clasificar, por indicar frecuentemente la presencia de ruido oerrores en el dataset como se ha indicado.

Efectos de batch normalization en test

Se han encontrado diversos efectos relevantes relacionados con el uso de BN alcalcular las métricas para el conjunto de test:

BN no permite evaluar adecuadamente una sola imagen si se emplea la mediadel lote (esto se debe a que en el numerador de su fórmula se resta la variablea la media y si el tamaño de dicho lote es uno esto lleva a que el numeradorsea cero). Esto puede resultar no deseable o incluso inaceptable dependiendode los requisitos del problema concreto y/o el contexto del proyecto en el quese aplica el sistema.

Las predicciones para una imagen de entrada pueden variar en función de lacomposición del lote en el que se incluye. Estas oscilaciones se deben a que lamedia y varianza (empleadas por BN) dependen del lote y se ven afectadas alvariar la composición de este en función de que se aleatorice o no el orden delos datos de entrada.

• Nos encontramos en nuestro problema con un fuerte impacto negativosobre las métricas en el caso de procesarse los ejemplos por lotes en ordende etiquetado (no aleatorizar el conjunto de test). Esto se puede deber aque el orden de las imágenes tiene una relación directa con la distribucióngeográfica de las mismas (ficheros consecutivos corresponden a imágenesgeográficamente cercanas por lo general).

• Esto puede verse magnificado en nuestro caso al no normalizarsepreviamente las imágenes de entrada.

• Queda pendiente estudiar el efecto de usar una media móvil de lasvariables internas de BN en lugar de que dependan solo del lote.

• Se ha comprobado que en nuestro problema concreto aprender losparámetros de BN offset y scale parece reducir levemente el problemasin resolverlo.

Para poder observar en detalle los efectos de oscilación e impacto de noaleatorizar se presentan las métricas de un mismo modelo (entrenado varias vecesdesde cero en cada caso) evaluado de distintas formas, y en varias ocasionesdistintas (emplearemos el término prueba para referiremos a ellas), en la (Tabla3.18) y para mejor visualización de las oscilaciones del Accuracy en la (Fig. 3.25).

3.7. RESULTADOS 89

(a) (b) (c)

(d) (e) (f)

(g) (h) (i)

(j) (k) (l)

Figura 3.24: Ejemplos de imágenes que contienen vías parcial o totalmente ocultaspor los árboles y errores de etiquetado.


Es importante indicar que en el sistema presentado, durante el diseño de la red, losconjuntos tanto de entrenamiento como de validación son aleatorizados.

Se ha entrenado la misma arquitectura de red (test6gen17model38) cuatro vecesdistintas desde cero, dos (nos referiremos a ellas como Train 1 y 2) sin aprender losparámetros scale/offset y dos aprendiéndolos (Train 3 y 4). Observamos al haberaprendido dichos parámetros una leve reducción de las oscilaciones de las métricas(debidas al empleo de lotes distintos en cada ejecución al aleatorizar) en uno de loscasos. No obstante persiste en todas el problema al no aleatorizar el orden de lasimágenes (al predecir por lotes en orden de etiquetado). Observamos una vez másque al entrenar una misma red varias veces podemos obtener resultados distintoslo cual impide realizar comparaciones directas sin emplear validación cruzada, porello el estudio en profundidad de este fenómeno se reserva para futuros trabajos deinvestigación.

Viendo las restricciones que impone BN de cara a la predicción y las variacionesen la predicción por cambios en el lote, se incluyen dos entrenamientos desde cero(Train 5 y 6) de la misma arquitectura pero eliminando por completo BN, es decir,sin normalización.

En cualquier caso estos experimentos son realizados para ilustrar los resultados encada escenario y no se emplean para seleccionar ninguna de las variantes. Esto es asídebido a que trabajamos sobre el conjunto de test y todas las decisiones en relacióna las redes se han tomado usando los conjuntos de entrenamiento y validación.

3.8. Conclusiones

En este TFM hemos abordado la problemática de la búsqueda automática dearquitecturas de red mediante técnicas evolutivas en el contexto de la detección devías de transporte en ortofotografía aérea, todo ello dentro un proyecto de aplicaciónreal para el Instituto Geográfico Nacional.

Se ha desarrollado un sistema que permite a la vez dar solución a las necesidadesactuales del proyecto y servir de plataforma de investigación y desarrollo para lasfases posteriores que incluyen, entre otros objetivos, el etiquetado semántico y ladetección inconsistencias entre cartografía y ortofoto.

Los resultados presentados permiten por una parte concluir la necesidad decontinuar mejorando y depurando tanto el dataset como el procedimiento deetiquetado del mismo. En relación al método propuesto y la librería implementada,los experimentos nos dan pruebas de la utilidad de ambas de cara a reducirsignificativamente por parte del experto el tiempo invertido en buscar laarquitectura más adecuada o evitar el uso innecesario de arquitecturas

3.8. CONCLUSIONES 91

Train-Prueba

Aleatorizael Orden

BN Accuracy Tasa deError

Sensibilidad Especificidad

1-1 Si Si 0.784 0.216 0.810 0.7491-2 Si Si 0.807 0.193 0.847 0.7601-3 Si Si 0.791 0.209 0.814 0.7591-4 Si Si 0.779 0.221 0.814 0.7351-5 No Si 0.559 0.441 0.610 0.4882-1 Si Si 0.877 0.123 0.910 0.8372-2 Si Si 0.867 0.133 0.916 0.8122-3 Si Si 0.860 0.140 0.907 0.8072-4 Si Si 0.880 0.120 0.905 0.8482-5 No Si 0.542 0.458 0.585 0.4613-1 Si Si (SO) 0.846 0.154 0.899 0.7893-2 Si Si (SO) 0.843 0.157 0.899 0.7833-3 Si Si (SO) 0.834 0.166 0.887 0.7773-4 Si Si (SO) 0.848 0.152 0.905 0.7873-5 No Si (SO) 0.556 0.444 0.601 0.4824-1 Si Si (SO) 0.834 0.166 0.887 0.7774-2 Si Si (SO) 0.850 0.150 0.905 0.7904-3 Si Si (SO) 0.840 0.160 0.898 0.7784-4 Si Si (SO) 0.834 0.162 0.895 0.7774-5 No Si (SO) 0.550 0.449 0.601 0.4775-1 No afecta No 0.731 0.269 0.936 0.6246-1 No afecta No 0.860 0.140 0.883 0.831

Tabla 3.18: test6gen17model38 Oscilaciones en métricas de test y relación con BN. Elporcentaje de ejemplos positivos del conjunto de test empleado es aproximadamentedel 56 %. "SO" indica que se ha entrenado aprendiendo los parámetros de BN scaley offset.


Figura 3.25: Modelo test6gen17model38. Oscillaciones en Accurady de test debidas aBN (con distintos parámetros). Resultados con seis entrenamientos distintos (desdecero) clasificando con cada red el conjunto de test en varias ocasiones. "SO" indicaque se ha entrenado aprendiendo los parámetros de BN scale y offset.

preentrenadas y sobredimensionadas a nivel computacional para el problema quese intenta resolver.

Más allá de uso directo como herramienta de utilidad en el proceso de búsqueda dela arquitectura, los resultados generados durante dicho proceso, a nivel de registrosde modelos evaluados y resultados asociados, son de utilidad como herramienta deestudio e investigación para tratar de comprender mejor qué tipo de operadoreso esquemas de conexión se comportan mejor ante distintos juegos de datos y losmotivos de dichos comportamientos.

Podemos emplear gramáticas generadas a medida para comprobar si en unproblema dado resulta útil o no la presencia de un operador concreto, estudiar sucomportamiento ante distintos valores de sus parámetros o dejar fijas partesenteras de la red para evolucionar otras (para incorporar conocimiento de dominioo intentar mejorar estructuras conocidas).

Los registros de los experimentos realizados se consultan de forma periódicapara tratar de encontrar formas nuevas de explicitar el conocimiento reflejado en elproceso de búsqueda realizado por el sistema, las interacciones entre parámetrosy/o conexiones o incluso para buscar nuevos módulos estructurales de conexión.

3.9. LÍNEAS FUTURAS 93

También se han presentado, permaneciendo prácticamente inexploradas demanera formal su potencia y utilidad reales:

El operador de suma con padding que permite un esquema de conexión paramódulos estructurales que denominaremos Inception-DPN (estructuralmentees similar a Inception-ResNet pero la variante de la suma empleada en nuestrocaso permite que esta se comporte aproximadamente como una conexión DPN,sumando una parte de los canales y concatenando del resto).

En el algoritmo evolutivo se emplea una variante de GBIM sin producciones"por defecto". Con ella obtenemos una gramática más legible (al no forzar lapresencia de producciones "por defecto") a costa de perder uniformidad en lageneración de poblaciones/mutaciones (recordemos que también seríanecesario estudiar si en nuestro caso las citadas producciones "por defecto"introducen en si mismas un sesgo estadístico que favorece estructurasconcretas).

3.9. Líneas Futuras

Entre las líneas de continuación, y dentro del contexto del mismo convenio decolaboración con el IGN, se contemplan diversas opciones. En primer lugar, amedio plazo, se contempla la combinación con metaclasificadores de algunos de losmodelos obtenidos como resultado de este TFM y se trabaja ya en unametagramática de arquitecturas para realizar etiquetado semántico a nivel de píxel.

En el corto plazo se encuentran pendientes las siguientes mejoras al sistema:

Implementar la normalización LRN para el formato de codificación BCHWvistos los problemas asociados al uso de BN.

Añadir métricas de diversidad poblacional y explorar la relación de las mismascon los parámetros del algoritmo GGGP.

Explorar el efecto de incorporar costes a cada tipo de nodo de proceso o a lacomplejidad global de la red en el cálculo del fitness.

Modificar el sistema para resolver el problema de detección de cambios en lacartografía.

Implementar en VBrain (e incluírlas en la metagramática) unidades de procesotipo Squeeze-and-Excitation y Wide Residual Network.

Implementar un operador de suma con padding mejorado capaz de soportarcompletamente arquitecturas tipo DPN.


Explorar variantes del operador de suma con padding empleado parámetrospara controlar la posición y número de canales que suma y/o concatena.

Modificar el sistema para soportar arquitecturas con más de un punto deentrada y/o salida de datos (p.ej. para soportar arquitecturas Faster R-CNN).

Explorar la posibilidad de incorporar otros hiperparámetros del modelo alproceso de entrenamiento.

Ampliar el lenguaje de expresiones y la metagramática para permitir otrasarquitecturas de interconexión tipo DenseNet.

Dado que uno de los problemas principales del enfoque aplicado es el tiemponecesario para la ejecución de los experimentos, resulta imperativo profundizar entécnicas más eficientes como puede ser el caso de las búsquedas de subgrafos dearquitecturas de proceso o nuevas estrategias de compartición de nodos entreindividuos (en el sentido por ejemplo de reutilización de pesos).

Por otra parte como se comentaba el análisis de los registros generados y laextracción de conocimiento latente en dichos registros es de interés tanto desde unpunto de vista meramente didáctico (las comparativas de modelos y resultadosante diversos juegos de datos pueden ser de utilidad incluso a nivel docente) comode investigación (p.ej. de cara a buscar arquitecturas nuevas o alternativas máseficientes a las actuales a nivel de memoria y/o coste de proceso).

Como se comentaba queda pendiente también estudiar formalmente:

El impacto de la ausencia de las producciones por defecto en la variante deGBIM propuesta y empleada por VGNet.

La utilidad del operador presentado de suma con padding y los móduloshíbridos Inception-DPN que permite generar la metagramática.

Estudiar formalmente el impacto de BN sobre las métricas de test así como elcomportamiento de sus parámetros scale y offset (para determinar si realmentepermiten suavizar las oscilaciones en dichas métricas).

Se tendrán en cuenta todas estas líneas como puntos de inicio para los futurosesfuerzos de investigación, así como aquellos que puedan surgir fruto de la unióncon los esfuerzos de trabajo de los otros miembros del equipo de investigación en laactualidad (redes recurrentes y transfer learning).

Apéndice A

Anexos

A.1. Herramienta model-trainer.py

De cara a realizar tareas de entrenamiento y evaluación se ha desarrollado comointerfaz de consola al API de VBrain el programa "model-trainer.py" cuya ayuda seincluye a continuación:usage : model−t r a i n e r . py [−h ] [−alpha ALPHA] [−devs DEVS [DEVS . . . ] ]

[−dev_mem DEV_MEM] [− sharedev SHAREDEV][−mod MOD][−bs BS ] [−epo EPO] [− sav SAV] [− load LOAD][− f i r s t FIRST ] [− f i l e_ i d s FILE_IDS ][−max_time MAX_TIME][− task { tt , k fo ld , f i t , conf_matrix ,

conf_matr ix_shuf f le } ][−no_augment NO_AUGMENT]

op t i ona l arguments :−h , −−help show th i s he lp message and ex i t−alpha ALPHA Train ing alpha−devs DEVS [DEVS . . . ]

Devices to use (GPUs)−dev_mem DEV_MEM Devices i d l e f r e e memory (MB)−sharedev SHAREDEV Device ho ld ing shared Vars & Ops−mod MOD Model−bs BS Batch s i z e ( auto f o r automatic

est imat ion , use then−dev_mem) .

−epo EPO Epochs−sav SAV Save model as . . . ( nosave d i s a b l e s sav ing )−load LOAD Load model− f i r s t FIRST Use f i r s t <n> images per c l a s s

( doesnt do random sampling ) . . .− f i l e_ i d s FILE_IDS Use p i c k l e f i l e with p r e s e l e c t e d

image i d s to t r a i n / eva luate . . .

95

96 APÉNDICE A. ANEXOS

−max_time MAX_TIME Max time in minutes−task { tt , k fo ld , f i t , conf_matrix , conf_matr ix_shuf f le }

Train & Test , K−Fold , f i t model , con fus i on matrix( with and without s h u f f l e o f input samples )

−no_augment TrueDisab le data augmentation load ing

A.2. HERRAMIENTA MODEL-EVOLVER.PY 97

A.2. Herramienta model-evolver.py

La herramienta de consola "model-evolver.py" representa el interfaz de consoladel sistema VGNet y permite el diseño evolutivo de arquitecturas de red para undataset dado. La descripción de sus parámetros de funcionamiento es la siguiente:

usage : model−evo lv e r . py [−h ] [−devs DEVS [DEVS . . . ] ][−dev_mem DEV_MEM][− sharedev SHAREDEV] [−bs BS ] [−epo EPO][− sav SAV][− f i r s t FIRST ] [−max_time MAX_TIME][− task {make_grammar , random , evo lve } ][−sav_path SAV_PATH][−grammar_file GRAMMAR_FILE][− indv_pre f ix INDV_PREFIX] [−vg_pop VG_POP][−vg_gen VG_GEN] [−alpha ALPHA][−fw_raw FW_RAW][− fw_cost FW_COST][− tv_sp l i t { ind iv idua l , generat ion ,

experiment } ][− t e s t TEST] [− va l i d a t i o n VALIDATION][−v3g_maxdepth V3G_MAXDEPTH][−v3g_tournament V3G_TOURNAMENT][−v3g_pcross V3G_PCROSS][−v3g_pmutation V3G_PMUTATION][−no_augment NO_AUGMENT]

op t i ona l arguments :−h , −−help show th i s he lp message and ex i t−devs DEVS [DEVS . . . ]

Devices to use (GPUs)−dev_mem DEV_MEM Devices i d l e f r e e memory (MB)−sharedev SHAREDEV Device ho ld ing shared Vars & Ops−bs BS Batch s i z e ( auto f o r automatic

est imat ion , use then−dev_mem) .

−epo EPO Train Epochs f o r each model−sav SAV Save model as . . . ( nosave d i s a b l e s sav ing )− f i r s t FIRST Use f i r s t <n> images per c l a s s . . .−max_time MAX_TIME Max time in minutes−task {make_grammar , random , evo lve }

make_grammar ( generate grammar from cur rentmetagrammmar s e t t i n g s ) ,random ind i v i dua l from grammar ( random)or evo lve

−sav_path SAV_PATH Path to saved f i l e s−grammar_file GRAMMAR_FILE


F i l e to save grammar−indv_pre f ix INDV_PREFIX

Pre f i x f o r i nd i v i dua l f i l e s−vg_pop VG_POP Populat ion s i z e−vg_gen VG_GEN Number o f g ene ra t i on s−alpha ALPHA Train ing alpha−fw_raw FW_RAW v3g ie f i t n e s s raw weight−fw_cost FW_COST v3g ie f i t n e s s component co s t weight−tv_sp l i t { ind iv idua l , generat ion , experiment }

When to s p l i t datase t i n to t r a i n and t e s tf o r each . . . t v_sp l i t

−t e s t TEST Test s i z e separed be f o r et r a i n / va l i d a t i o n s p l i t

−va l i d a t i o n VALIDATIONVal idat i on s i z e

−v3g_maxdepth V3G_MAXDEPTHI n i t i a l i z a t i o n max t r e e depth

−v3g_tournament V3G_TOURNAMENTTournament s i z e

−v3g_pcross V3G_PCROSSCross ing p r obab i l i t y

−v3g_pmutation V3G_PMUTATIONMutation p r obab i l i t y

−no_augment NO_AUGMENTDisab le data augmentation load ing

A.3. GLOSARIO DE ABREVIATURAS Y ACRÓNIMOS 99

A.3. Glosario de abreviaturas y acrónimos

AP: Average-Pool.

API: Application Program Interface.

BN: Batch Normalization.

BTN25: Base Topográfica Nacional a Escala 1:25.000.

CNN: Convolutional Neural Network.

Conv.: Convolución.

DCN: Deformable Convolutional Networks.

DenseNet: Densely Connected Convolutional Networks.

DPN: Dual Path Networks.

DSSD: Deconvolutional Single Shot Detector.

ETSISI: Escuela Técnica Superior de Ingeniería de Sistemas Informáticos.

FC: Full Connected.

FPN: Feature Pyramid Networks.

GBIM: Grammar-Based Initialization Method.

GBM: Grammar-Based Mutation.

GGGP: Grammar Guided Genetic Programming.

GPU: Graphics Processing Unit.

IGN: Instituto Geográfico Nacional.

ILSVRC: ImageNet Large Scale Visualization Recognition Challenge.

INSIA: Instituto Universitario de Investigación del Automóvil.

lReLU o leaky-ReLU: leaky Rectified Linear Unit.

LRN: Local Response Normalization.

LSTM: Long-Short Term Memory.

MP: Max-Pool.

NAS: Network Architecture Search.


NFC: Non Fully Convolutional network

PNOA: Plan Nacional de Ortofotografía Aérea.

R-CNN: Region-based Convolutional Network.

ReLU: Rectified Linear Unit.

ResNet: Residual Networks.

R-FCN: Region-based Fully Convolutional Networks.

RL: Reinforcement Learning.

RMS: Root Mean Square error.

RNAs: Redes de Neuronas Artificiales.

RNN: Recurrent Neural Network.

RoI: Region of Interest.

RPN: Region Proposal Network.

SE: Squeeze-and-Excitation.

SENet: Squeeze-and-Excitation Network.

SoTA: State of The Art.

SPP :Spatial Pyramid Pooling.

SPPnet :Spatial Pyramid Pooling Network.

SSD: Single Shot MultiBox Detector.

SVM: Support Vector Machines.

TFM: Tesis Fin de Máster.

UPM: Universidad Politécnica de Madrid.

WRN: Wide Residual Network.

YOLO: You Only Look Once.

Bibliografía

101

102 BIBLIOGRAFÍA

Bibliografía

Chen, Yunpeng y col. (2017). «Dual path networks». En: Advances in NeuralInformation Processing Systems, págs. 4467-4475.

Couchet, Jorge, Daniel Manrique y Luis Porras (2007). «Grammar-guidedneural architecture evolution». En: International Work-Conference onthe Interplay Between Natural and Artificial Computation. Springer,págs. 437-446.

Couchet, Jorge y col. (2007). «Crossover and mutation operators for grammar-guided genetic programming». En: Soft Computing 11.10, págs. 943-955.

Dai, Jifeng y col. (2016). «R-FCN: Object Detection via Region-based FullyConvolutional Networks». En: Advances in Neural Information ProcessingSystems 29. Ed. por D. D. Lee y col. Curran Associates, Inc., págs. 379-387.url: http://papers.nips.cc/paper/6465-r-fcn-object-detection-via-region-based-fully-convolutional-networks.pdf.

Dai, Jifeng y col. (2017). «Deformable convolutional networks». En: CoRR,abs/1703.06211 1.2, pág. 3.

Fu, Cheng-Yang y col. (2017). «DSSD : Deconvolutional Single Shot Detector».En: CoRR abs/1701.06659. arXiv: 1701.06659. url: http://arxiv.org/abs/1701.06659.

García-Arnau, Marc y col. (2006). «Initialization method for grammar-guided genetic programming». En: International Conference on InnovativeTechniques and Applications of Artificial Intelligence. Springer, págs. 32-44.

Girshick, Ross (2015). «Fast r-cnn». En: Proceedings of the IEEE internationalconference on computer vision, págs. 1440-1448.

Girshick, Ross y col. (2014). «Rich feature hierarchies for accurate objectdetection and semantic segmentation». En: Proceedings of the IEEEconference on computer vision and pattern recognition, págs. 580-587.

Glorot, Xavier y Yoshua Bengio (2010). «Understanding the difficulty oftraining deep feedforward neural networks». En: Proceedings of thethirteenth international conference on artificial intelligence and statistics,págs. 249-256.

He, Kaiming y col. (2014). «Spatial Pyramid Pooling in Deep ConvolutionalNetworks for Visual Recognition». En: Computer Vision – ECCV 2014.Ed. por David Fleet y col. Cham: Springer International Publishing,págs. 346-361. isbn: 978-3-319-10578-9.

103

104 BIBLIOGRAFÍA

He, Kaiming y col. (2016a). «Deep Residual Learning for Image Recognition».En: The IEEE Conference on Computer Vision and Pattern Recognition(CVPR).

— (2016b). «Identity Mappings in Deep Residual Networks». En: CoRRabs/1603.05027. arXiv: 1603.05027. url: http://arxiv.org/abs/1603.05027.

He, Kaiming y col. (2017). «Mask r-cnn». En: Computer Vision (ICCV), 2017IEEE International Conference on. IEEE, págs. 2980-2988.

Hinton, Geoffrey E. y col. (2012). «Improving neural networks by preventingco-adaptation of feature detectors». En: CoRR abs/1207.0580. arXiv: 1207.0580. url: http://arxiv.org/abs/1207.0580.

Howard, Andrew G. y col. (2017). «MobileNets: Efficient Convolutional NeuralNetworks for Mobile Vision Applications». En: CoRR abs/1704.04861.arXiv: 1704.04861. url: http://arxiv.org/abs/1704.04861.

Hu, Jie, Li Shen y Gang Sun (2018). «Squeeze-and-excitation networks».En: Proceedings of the IEEE conference on computer vision and patternrecognition, págs. 7132-7141.

Huang, Gao y col. (2017). «Densely Connected Convolutional Networks».En: The IEEE Conference on Computer Vision and Pattern Recognition(CVPR).

Ioffe, Sergey y Christian Szegedy (2015). «Batch Normalization: AcceleratingDeep Network Training by Reducing Internal Covariate Shift». En: CoRRabs/1502.03167. arXiv: 1502.03167. url: http://arxiv.org/abs/1502.03167.

Kingma, Diederik P y Jimmy Ba (2014). «Adam: A method for stochasticoptimization». En: arXiv preprint arXiv:1412.6980.

Koza, John R y John R Koza (1992). Genetic programming: on the programmingof computers by means of natural selection. Vol. 1. MIT press.

Krizhevsky, Alex, Ilya Sutskever y Geoffrey E Hinton (2012). «Imagenetclassification with deep convolutional neural networks». En: Advances inneural information processing systems, págs. 1097-1105.

Larsson, Gustav, Michael Maire y Gregory Shakhnarovich (2016).«FractalNet: Ultra-Deep Neural Networks without Residuals». En:CoRR abs/1605.07648. arXiv: 1605.07648. url: http://arxiv.org/abs/1605.07648.

Lazebnik, Svetlana, Cordelia Schmid y Jean Ponce (2006). «Beyond bagsof features: Spatial pyramid matching for recognizing natural scenecategories». En: null. IEEE, págs. 2169-2178.

Lin, Tsung-Yi y col. (2017a). «Feature pyramid networks for object detection».En: CVPR. Vol. 1. 2, pág. 4.

Lin, Tsung-Yi y col. (2017b). «Focal Loss for Dense Object Detection». En:The IEEE International Conference on Computer Vision (ICCV).

BIBLIOGRAFÍA 105

Liu, Hanxiao y col. (2017). «Hierarchical Representations for EfficientArchitecture Search». En: CoRR abs/1711.00436. arXiv: 1711.00436. url:http://arxiv.org/abs/1711.00436.

Liu, Wei y col. (2016). «SSD: Single Shot MultiBox Detector». En: ComputerVision – ECCV 2016. Ed. por Bastian Leibe y col. Cham: SpringerInternational Publishing, págs. 21-37. isbn: 978-3-319-46448-0.

Pham, Hieu y col. (2018). «Efficient Neural Architecture Search via ParameterSharing». En: CoRR abs/1802.03268. arXiv: 1802.03268. url: http://arxiv.org/abs/1802.03268.

Real, Esteban y col. (2018). «Regularized Evolution for Image ClassifierArchitecture Search». En: CoRR abs/1802.01548. arXiv: 1802.01548. url:http://arxiv.org/abs/1802.01548.

Redmon, Joseph y col. (2016). «You Only Look Once: Unified, Real-TimeObject Detection». En: The IEEE Conference on Computer Vision andPattern Recognition (CVPR).

Ren, Shaoqing y col. (2015). «Faster R-CNN: Towards Real-Time ObjectDetection with Region Proposal Networks». En: Advances in NeuralInformation Processing Systems 28. Ed. por C. Cortes y col. CurranAssociates, Inc., págs. 91-99. url: http://papers.nips.cc/paper/5638-faster-r-cnn-towards-real-time-object-detection-with-region-proposal-networks.pdf.

Russakovsky, Olga y col. (2015). «ImageNet Large Scale Visual RecognitionChallenge». En: International Journal of Computer Vision (IJCV) 115.3,págs. 211-252. doi: 10.1007/s11263-015-0816-y.

Simonyan, Karen y Andrew Zisserman (2014). «Very deep convolutionalnetworks for large-scale image recognition». En: arXiv preprintarXiv:1409.1556.

Srivastava, Rupesh Kumar, Klaus Greff y Jürgen Schmidhuber (2015).«Highway networks». En: arXiv preprint arXiv:1505.00387.

Szegedy, Christian y col. (2015). «Going deeper with convolutions». En:Proceedings of the IEEE conference on computer vision and patternrecognition, págs. 1-9.

Szegedy, Christian y col. (2016). «Rethinking the inception architecture forcomputer vision». En: Proceedings of the IEEE conference on computervision and pattern recognition, págs. 2818-2826.

Szegedy, Christian y col. (2017). «Inception-v4, inception-resnet and the impactof residual connections on learning.» En: AAAI. Vol. 4, pág. 12.

Volpi, Michele y Devis Tuia (2017). «Dense semantic labeling of subdecimeterresolution images with convolutional neural networks». En: IEEETransactions on Geoscience and Remote Sensing 55.2, págs. 881-893.

Whigham, Peter A y col. (1995). «Grammatically-based genetic programming».En: Proceedings of the workshop on genetic programming: from theory toreal-world applications. Vol. 16. 3, págs. 33-41.

106 BIBLIOGRAFÍA

Xie, Saining y col. (2017). «Aggregated residual transformations for deep neuralnetworks». En: Computer Vision and Pattern Recognition (CVPR), 2017IEEE Conference on. IEEE, págs. 5987-5995.

Yu, Jiafan y col. (2018). «DeepSolar: A Machine Learning Framework toEfficiently Construct a Solar Deployment Database in the United States».En: Joule 2.12, págs. 2605-2617.

Zagoruyko, Sergey y Nikos Komodakis (2016). «Wide Residual Networks». En:CoRR abs/1605.07146. arXiv: 1605.07146. url: http://arxiv.org/abs/1605.07146.

Zoph, Barret y Quoc V. Le (2016). «Neural Architecture Search withReinforcement Learning». En: CoRR abs/1611.01578. arXiv: 1611.01578.url: http://arxiv.org/abs/1611.01578.

Zoph, Barret y col. (2017). «Learning Transferable Architectures for ScalableImage Recognition». En: CoRR abs/1707.07012. arXiv: 1707.07012. url:http://arxiv.org/abs/1707.07012.

diseño evolutivo de arquitecturas de deep learning para...

Documents