Descrittore

La selezione del modello empirica prevede di effettuare molti test con diversi iperpara- metri relativi al modello e all’algoritmo di apprendimento. Il numero e la complessit`a degli iperparametri rende difficile la gestione mediante l’uso di flags da impostare, o da far passare come parametri a riga di comando. Per questo motivo si `e scelto di utilizzare un approccio che prevedesse l’uso di un file di configurazione dove fossero contenute tutte le informazioni necessarie all’addestramento.

Questo file, chiamato descrittore, `e codificato in XML e contiene le informazioni principali del:

4.1 Libreria felix 75

Task contenente le informazioni operative relative all’esecuzione dell’addestramento; Data dove sono contenuti i path del dataset e della cartella in cui andranno salvati i

risultati. In questa parte verranno inoltre definiti il tipo di dataset usato (flat o grafo) e il tipo di separazione;

Model dove viene espresso il tipo di modello e i suoi iperprametri. Il numero e tipo di iperparametri sono informazioni modello-specifiche, come il numero di unit`a nascoste e di layers per il Multilayer Perceptron, o il tipo di funzione di attivazione per le unit`a;

Learning dove vengono espressi tutti i parametri dell’algoritmo di apprendimento, come learning rate o weight decay, oltre che gli stop criteria usati;

Ad esempio, nella parte relativa al Task una delle informazioni che `e possibile fornire `e il numero di trial il cui valore, se maggiore di 1, permette di addestrare diverse istanze con pesi iniziali diversi, e conservare la migliore. In questo caso l’andamento di tutte le istanze addestrate `e conservato nel file del risultato, e pu`o essere analizzato separatamente mediante il tool felix-reader.

Ogni descrittore deve contenere queste parti, le cui informazioni verranno passate ai rispettivi componenti della libreria felix (vedere Sez. 4.1.1). La lettura, ed even- tuale salvataggio, del descrittore `e gestita mediante la classe TaskDescriptor, la quale contiene alcune funzioni di utilit`a e quattro istanze pubbliche di DescriptorParameter che contengono tutte le informazioni relative al training:

Listing 4.30: Strutture Relative alle Varie componenti

DescriptorParameter* taskParameters; DescriptorParameter* dataParameters; DescriptorParameter* modelParameters;

DescriptorParameter* learningAlgorithmParameters;

La classe DescriptorParameter non `e altro che una rappresentazione logica degli iper- parametri, e segue da vicino la struttura ad albero del linguaggio XML. Definita ricorsi- vamente, la classe DescriptorParameter contiene al suo interno il nome (corrispondente al tag name XML), una lista di attributi, dei riferimenti ai parametri figli e una serie di funzionalit`a utili alla navigazione e al reperimento di un sottoparametro specifico. Gli attributi vengono gestiti mediante una classe DescriptorAttribute che, oltre alla coppia

di attributi name e value, presenta diverse sottoclassi specifiche, a seconda del tipo di attributo, come DescriptorIntAttribute e DescriptorBoolAttribute.

Dato che la libreria non ha controllo su quanto presente nel file del descrittore, queste sottoclassi permettono di effettuare una validazione del descrittore passato.

Ogni componente principale di felix, come i modelli, i vari algoritmo di apprendi- mento e dataset, riceve nel costruttore, dalla sua abstract factory, un’istanza di De- scriptorParameter contente tutti gli iperparametri necessari al componente per essere creato, come ad esempio il numero di unit`a e layers in un MultiLayerPerceptron o la learning rate di una classe Backpropagation.

Ognuno di questi componenti implementa una funzione statica getParameters che restituisce un’istanza di DescriptorParameter, contenente un template di tutti i para- metri necessari alla classe per poter essere istanziata, e questo viene usato per effettuare una validazione dei parametri passati. L’idea di base `e la seguente: una volta che si implementa un componente nuovo, si assume che l’istanza di DescriptorParameter pas- sata contenga lo stesso numero e tipo di parametri presenti in quella restituita dalla funzione getParameters della stessa classe.

Durante l’utilizzo della libreria, il descrittore `e la prima cosa che deve essere cari- cata, in quanto contenente tutte le informazioni necessarie ad istanziare le successive componenti. Una volta caricato il descrittore, verranno passati i relativi oggetti De- scriptorParameter, contenenti i valori settati nel file, ai relativi componenti per mez- zo del costruttore. Questo viene fatto esplicitamente, ad esempio quando si vuole istanziare un modello specifico, o per mezzo di un’abstract factory che, sempre se- guendo l’esempio, selezioner`a il modello corretto in base alle informazioni presenti nel descrittore.

Questo approccio permette di gestire tutti i parametri della libreria in un unico file lasciando, allo stesso tempo, totale libert`a nella gestione dei parametri per i singoli componenti.

Un esempio completo di descrittore `e presente in App. C.3.

4.1.6.1 Descrittore Grid

Una variante del descrittore `e rappresentata dal grid, che permette di generare facil- mente una famiglia di descrittori, che rappresentano varianti di un singolo descrittore di partenza.

4.1 Libreria felix 77

L’utilizzo principale del grid `e quello di effettuare una Double CV specificando in modo semplice i parametri che devono essere messi a griglia, rispetto ad un certo descrittore, chiamato descrittore originale. Un descrittore grid si presenta come un file XML il cui tag principale porta il nome di GridDescriptor, e che possiede, all’interno dell’attributo path del tag taskDescriptor, un riferimento al file descrittore originale.

Oltre al tag taskDescriptor, presenta un tag Data che definisce il tipo di loop esterno da usare, con i suoi parametri, come ad esempio il numero di folds della CV esterna.

I successivi tag si limitano a specificare solamente quei parametri che devono essere variati, rispetto al descrittore originale. Per specificare un parametro oggetto della variazione, contenuto in un attributo del descrittore originario, il descrittore grid re- plicher`a la struttura dei tag del descrittore originario, limitandosi a riportare i nomi dei tag (senza gli attributi) fino ad arrivare al tag che contiene l’attributo che si vuole modificare. A questo punto nel grid sar`a inserito un tag figlio, avente come nome l’at- tributo da modificare, e come attributi le keywords from, to e tick che rappresentano la variazione da eseguire.

Ad esempio, se volessimo testare un descrittore variando la learning rate dell’algo- ritmo di apprendimento, magari testandola sull’intervallo η ∈ [0.1, 0.5] con scatti di 0.1 `e sufficiente inserire questo tag all’interno del descrittore grid:

Listing 4.31: Esempio di Variante Inserita nel Grid

<Learning>

<learningRate from="0.1" to="0.5" tick="0.1"/> </Learning>

In questo modo, viene identificato nel descrittore originale l’attributo learningRate del seguente tag:

Listing 4.32: Attributo Individuato nel Descrittore

<Learning name="Backpropagation" learningRate="0.1" weightDecay="0.01"

saveExtendedLogging="True">

e il sistema provveder`a a generare 5 istanze diverse di TaskDescriptor, ognuna rappre- sentante una variazione della learning rate dell’algoritmo di apprendimento.

Questo `e gestito mediante la classe GridDescriptor che si occupa di caricare il file del descrittore grid, tipicamente avente estensione .grid, e di generare le istanze di TaskDescriptor corrispondenti.