Architettura di NIN

L’architettura finale di NIN dovrebbe ormai essere abbastanza chiara: non è altro che una serie di MLP convolutional layer, al termine della quale vi è un global average pooling. La rete NIN è costituita nello specifico da 4 MLP convolutional layer. Al termine del terzo MLP layer è stato aggiunto un dropout layer, per limitare ulteriormente l’overfitting. In origine tuttavia la rete aveva un MLP convolutional layer in meno, come mostrato in figura 5.11. NIN è stata progettata nel 2013, nella successiva competizione ILSVRC del 2014 è stato aggiunto il MLP convolutional layer in più.

L’attuale versione, ottimizzata prima di essere presentata alla competi-zione ILSVRC dell’anno successivo è presente nella figura 5.12. Questa è la

Figura 5.12: Architettura attuale di NIN (4 MLP convolutional layer)

Figura 5.13: I parametri utilizzati da NIN

versione che verrà considerata nella tesi.

I 4 attuali layer convoluzionali principali, cioè i primi layer di ciascun MLP layer, hanno le seguenti caratteristiche:

• il primo possiede 96 kernel con un receptive field 11 x 11 e stride 4. • il secondo possiede 256 kernel con un receptive field 5 x 5 e stride 1. • il terzo possiede 384 kernel con un receptive field 3 x 3 e stride 1. • il quarto possiede 1024 kernel con un receptive field 3 x 3 e stride 1. Si noti che come al solito il numero di kernel aumenta scendendo lungo la rete, mentre le dimensioni del receptive field diminuiscono.

Il numero di classi su NIN viene specificato nell’ultimo layer convoluzio-nale prima del global average pooling.

NIN dunque utilizza un numero molto minore di parametri rispetto ad AlexNet ed alle VGG, come mostrato in figura 5.13, principalmente per l’assenza dei FC layer.

Il modello introdotto da NIN è stato utilizzato da molti altri team ed è inoltre stato testato su altre reti già esistenti. Potrebbe rappresentare una sorta di nuovo standard per le reti neurali convoluzionali, per avere comunque buone prestazioni utilizzando un numero inferiore di parametri; si tenga conto che non tutti i team sono comunque interessati a questo.

5.4 GoogLeNet

L’ultima rete analizzata è chiamata GoogLeNet ([18]), costruita nel 2014 da un team di dipendenti di Google e chiamata così in onore di una delle più vecchie, ovvero LeNet. GoogLeNet è sicuramente la rete che possiede l’ar-chitettura più complessa fra quelle viste, ma ciò è dovuto agli obbiettivi che il team voleva raggiungere. Come si era visto con le reti VGG, il metodo più diretto per aumentare le performance di una CNN è quello di aumentare le loro dimensioni lungo la profondità (“going deeper”). Tuttavia per GoogLe-Net l’aumento è inteso sia come incremento di profondità, cioè il numero di livelli che la rete possiede, e sia come incremento della larghezza della rete, ovvero il numero di layer presenti su uno stesso livello. GoogLeNet si è ci-mentata dunque anche nella sfida di aumentare la larghezza di una rete, cosa che prima nemmeno si ipotizzava per il semplice fatto che non di riuscirebbe a gestire l’enorme quantità di dati che si verrebbe a creare.

Con un aumento della larghezza della rete, si intende la possibilità di svolgere su uno stesso volume di input all’interno della rete, diversi tipi con-voluzioni, o meglio utilizzare ogni volta un layer convoluzionale con dei kernel di dimensioni diverse. Nel caso di GoogLeNet, essa prevede di effettuare tre tipi di convoluzione su un determinato volume di input:

• una convoluzione con dei kernel di dimensioni 1 x 1 • una convoluzione con dei kernel di dimensioni 3 x 3 • una convoluzione con dei kernel di dimensioni 5 x 5

Le feature ottenute da ciascuna convoluzione vengono poi successivamen-te successivamen-tenusuccessivamen-te tutsuccessivamen-te in considerazione nei layer successivi. Si dovrebbe quindi cominciare a capire perchè prima si parlava di un’enorme quantità di dati: per ogni livello della rete, invece di avere i dati di un singolo layer convolu-zionale, si hanno i dati di ben 3 layer convoluzionali; oltre a questo c’è da tenere conto del fatto che è necessario anche un tempo maggiore per effet-tuare tutte le operazioni di ciascun layer convoluzionale, in particolare per le convoluzioni con i kernel di dimensioni maggiori (3 x 3 e 5 x 5).

Ad ogni modo, l’aumento delle dimensioni, sia in profondità che in lar-ghezza, di una rete porta due svantaggi significativi:

• innanzitutto reti di grandi dimensioni utilizzano un numero sempre maggiore di parametri e ciò può rendere una rete più incline all’over-fitting, soprattutto nel caso in cui nel dataset non vi fossero molte immagini

• inoltre l’aumento delle dimensioni di una rete porta ad una dramma-tica crescita di potenza computazionale necessaria per l’allenamento. Ad esempio, se si hanno due layer convoluzionali consecutivi, un au-mento uniforme del numero dei kernel utilizzati porta ad un auau-mento quadratico della computazione totale. Dato che nella realtà la potenza computazionale disponibile è sempre finita, è preferibile una distribu-zione efficiente delle risorse rispetto ad un aumento sconsiderato delle dimensioni della rete, anche quando l’obbiettivo è quello di aumentare la qualità dei risultati.

L’approccio fondamentale per andare incontro ai due problemi citati è quello di passare da un’architettura completamente connessa ad un’architet-tura sparsa, anche all’interno delle convoluzioni.

Per questo motivo anche GoogLeNet non fa uso degli enormi FC layer nel modo in cui AlexnNet e nelle reti VGG: GoogLeNet ne utilizza solo uno alla fine e fra l’altro il team sostiene che non è nemmeno assolutamente necessario per il corretto funzionamento della rete, ma è stato aggiunto per tentare di migliorare ancora di più la rete stessa. Ad ogni modo, questo FC layer è completamente connesso ad un volume molto piccolo quando viene utilizzato, e quindi non possiede moltissimi parametri. GoogLeNet infatti prende spunto da NIN ed utilizza i layer convoluzionali 1 x 1 con stride 1 (CCCP layer su NIN), seguiti dai soliti layer di ReLU. Tuttavia su GoogLeNet i layer convoluzionali 1 x 1 hanno anche un altro scopo: vengono principalmente utilizzati come moduli per la riduzione della dimensioni prima di effettuare convoluzioni computazionalmente più costose come quelle con i kernel 3 x 3 o 5 x 5, per rimuovere eventuali “colli di bottiglia” all’interno della rete. In questo modo è stato possibile aumentare non solo la profondità della rete, ma anche la sua larghezza, senza un significativo calo delle performance.