• Non ci sono risultati.

Una volta avviato l’allenamento, o il fine-tuning, di una rete, dopo un de-terminato numero di iterazioni specificato dal parametro display del solver, sul terminale appariranno le informazioni che mostrano il valore attuale della funzione di loss. Il normale e corretto andamento di questi valori dovrebbe essere quello in cui la funzione di loss, all’aumentare delle iterazioni, dimi-nuisce il proprio valore. Non è detto che migliori nell’arco di poche iterazioni (anzi a volte può anche leggermente aumentare), ma l’importante è che com-plessivamente dopo ad esempio qualche centinaia di iterazioni si abbia un valore di loss un po’ più basso di quello di partenza. Se ciò non accade, vuol dire che qualcosa non va: nel migliore dei casi potrebbe essere semplicemente dovuto al fatto che alcuni parametri non sono stati settati in maniera adegua-ta; nel peggiore dei casi potrebbe essere un problema che riguarda il dataset costruito, ad esempio troppe poche informazioni, immagini di scarsa qualità o altro ancora. In questo caso bisogna intervenire direttamente sul dataset. Nel primo dei due casi si può tentare di procedere in uno dei seguenti modi (non sempre funzionano, ma spesso possono aiutare):

• se il valore di loss invece di diminuire aumenta, provare ad abbassare il valore di base del learning rate del solver. In alternativa incrementare

il suo fattore di diminuzione sempre nel solver o in casi estremi anche cambiare il suo tipo di policy (ultima cosa da fare dopo aver provato di tutto). Se ci si sente abbastanza sicuri si può anche tentare di ma-novrare il valore del learning rate direttamente all’interno di ciascun layer (molto utile nel caso di un fine-tuning) andando ad incrementare i parametri di lr_mult.

• se il valore di loss ad un certo punto non decresce più, oppure decresce ma molto e troppo lentamente, provare in questo caso ad aumentare il learning rate, sempre con una delle metodologie descritte nel punto precedente, ovviamente nel caso opposto stavolta.

4.9 Classificazione di un’immagine con Caffe

Terminato l’intero processo di allenamento (o di fine-tuning) si avrà dunque a disposizione un file .caffemodel necessario per la successiva classificazione di immagini rientranti nelle categorie del dataset, ma che non sono presenti in esso. Per questo scopo Caffe mette a disposizione un piccolo programma scritte in C++ chiamato classification.cpp. L’eseguibile di questo programma prende in input i seguenti parametri:

• il protocol buffer deploy.prototxt che verrà illustrato fra poco. • il modello risultante dall’allenamento della rete (.caffemodel ).

• il file binario per l’operazione di mean subtraction. In questo caso è obbligatorio per come è stato scritto il piccolo programma di classi-ficazione, ma con opportune modifiche si può fare in modo di farne a meno. Caffe lo ha probabilmente reso obbligatorio di base perchè spesso quest’operazione aiuta molto e non appesantisce troppo il programma. • il file synsetwords.txt per avere i nomi e le label da assegnare alle

varie classi

• il percorso dell’immagine da classificare.

Il file deploy.prototxt serve solo nelle predizioni di immagini esterne: in pratica è un file quasi uguale al file train_val.prototxt (mancano alcuni para-metri che in questo caso non sono necessari perchè non si sta allenando una rete) che serve per estrarre i dati, secondo la struttura della rete, dal suo modello binario e con essi effettuare una successiva classificazione. Nella sua creazione è dunque necessario prestare attenzione che nei due file il nome, la

Figura 4.36: Esempio di un softmax layer nel file di deploy

loro tipologia, i rispettivi parametri di ciascun layer ed il loro ordine siano esattamente gli stessi, fatta eccezione per i layer qui sotto descritti. Le uniche cose che si possono cambiare sono:

• il tipo di data layer utilizzato, purchè effettui le stesse operazioni di resize o prenda una crop delle stesse dimensioni del data layer con cui la rete è stata allenata. E’ sufficiente inserire un parametro relativo appunto ad uno di questi due dati e si può tranquillamente usare un altro data layer.

• il tipo di output layer. In questo caso non ha senso calcolare un’accura-cy o una loss. Si utilizza un semplice layer di output, come ad esempio un layer Softmax (mostrato in figura 4.36), che calcoli e distribuisca le probabilità fra le classi specificate. Si noti che in questo caso il layer di output non prende in input una blob con le label: infatti le label sono in questo caso caricate esternamente dal file di synset e vengono utilizzate, dal codice di Caffe, solo alla fine per l’output su terminale. Qui infatti non c’è un training set o un validation set: la vera classe dell’immagine da classificare è ignota. Il file di synset, contenente le label, serve solamente per l’output della classe predetta dalla rete. In realtà, esattamente come era stato visto con il fine-tuning, nel file di deploy si possono omettere interamente alcuni layer a partire dalla fine della rete; non è invece possibile escludere alcuni layer interni in quanto si distrug-gerebbe la struttura della rete stessa e Caffe segnalerebbe un errore proprio perchè i valori dei parametri non risulterebbero più validi per poter effet-tuare una valida forward pass della rete. Eliminando invece ad esempio solo l’output layer finale, è comunque possibile effettuare una forward pass, solo che ovviamente cambierà l’output finale, che risulterà essere quello dell’ulti-mo layer presente nella rete. Si ricorda che qui non ci sono backward pass e quindi anche se manca un layer alla fine della rete, essa effettua comunque la sua normale elaborazione dell’immagine fino alla fine della sua sequenza di layer.

Anche in questo caso non è possibile aggiungere nuovi layer che modifi-chino la sostanziale architettura della rete, cosa che ad esempio un loss layer, o un data layer diverso, ma con gli stessi parametri di dimensioni delle im-magini, infatti non fanno. In un prossimo futuro sembra che Caffe unirà il file di deploy a quello di training, esattamente come in precedenza era stato fatto per le fasi di training e di testing durante l’allenamento: si è passati da train.prototxt e val.prototxt a train_val.prototxt e in futuro si passerà dunque a train_val_deploy.prototxt, aggiungendo un qualche tipo di parametro che distingua l’allenamento dalle predizioni esterne, esattamente come era stato raccontato all’inizio della sezione 4.6 con il parametro phase; basterebbe an-che solo aggiungere una possibilità all’insieme di valori an-che questo parametro può assumere.

Per chiunque avesse fatto un’operazione di fine-tuning si può procedere in questo caso in due modi: se non si possiede il file di deploy è necessario crearlo da zero, rispettando i vincoli precisati sopra; se invece si dispone già anche di un file di deploy è sufficiente modificare in esso il nome della rete, il nome dell’ultimo layer con parametri allenabili ed il suo numero di output (il numero di classi), facendo attenzione a mettere gli stessi valori messi nel file di training, altrimenti verrà generato un errore in fase di caricamento del modello. Quando si avrà un file di deploy completo è importante ricordarsi di aggiungere anche qui i vari parametri di lr_mult e decay_mult. Questi pa-rametri devono essere gli stessi utilizzati nel file di training della rete perchè, anche se in questo caso non si hanno delle backward propagation, i parametri letti dal modello devono avere gli stessi valori di quando sono stati utilizzati durante il training, ergo devono essere moltiplicati per gli stessi fattori, al-trimenti si avrebbero numeri diversi. Quest’ultima regola non riguarda solo il fine-tuning, ma la costruzione generale del file di deploy.

Una volta predisposto tutto è sufficiente dare da terminale, sempre dal-l’interno della cartella di Caffe, un comando simile al seguente:

./build/examples/cpp_classification/classification.bin /home/fabio/Scrivania/Reti/Googlenet/deploy.prototxt

/home/fabio/Scrivania/Risultati_test/Googlenet/modelli/_iter_2000.caffemodel

data/ilsvrc12/imagenet_mean.binaryproto /home/fabio/Scrivania/Reti/synset_words.txt /home/fabio/Scrivania/dataset/consenso_informato/val/cons_train_1.jpg