In questo articolo scriverò di una metodica utile per prepararsi alla fase di addestramento di un modello. Si tratta di un processo formato da 6 step, ognuno utile per assicurare che un corretto flusso di dati sia immesso nel nostro modello. Seguire questi passaggi mi ha reso più efficiente nel lavoro e più sicuro di me quando mostravo i miei risultati.

Voglio ringraziare Andriy Burkov e il suo lavoro con il libro Machine Learning Engineering. Ne ho tratto ispirazione per scrivere questo articolo ed è nel complesso un'ottima lettura: leggetelo se non l'avete già fatto.

Cominciamo.

1. Il file di schema

Il file schema viene utilizzato per tenere traccia di quali sono le tue feature, di come si comportano e delle loro proprietà generali. È utile perché garantisce che tutto il team sia aggiornato su ciò che viene fornito al modello, in tutte le fasi dello sviluppo. Fornisce inoltre al team una linea guida formale da seguire durante il debug del modello.

Crea un file che soddisfi almeno questi criteri:

contenga il nome delle feature
il loro tipo (categoriale, numerico, …)
i valori minimi e massimi consentiti
media e deviazione standard
se consente la presenza di zeri
se consente la presenza di valori non definiti (NaN, None, ...)

Sentitevi liberi di creare qualsiasi tipo di file per contenere queste informazioni. Ecco un esempio di un file schema.json che contiene queste informazioni per un set di dati sintetico.

‍

2. Il file README.md

Una delle mie attività preferite è scrivere i miei pensieri prima e durante il mio progetto di machine learning. Sfrutto il file README.md, che è il primo file che creo nel mio repository.

È essenziale che tutti i nostri ragionamenti vadano in questo file in modo che team (e anche te stesso lungo la strada) segua sempre la stessa linea. È facile gettarsi a capofitto in un'idea solo per scoprire delle ore dopo che non aveva senso secondo il brief del progetto. Esaminare il README ci aiuterà a cristallizzare le nostre intenzioni e ad essere più efficienti.

Il modo in cui strutturo il mio file README non è standard, ma generalmente segue questo schema:

scrivo dell'obiettivo e dell'idea generale dietro di esso
elenco le possibili metodologie che possono essere utilizzate per affrontare il problema
elenco pro e contro di ciascuno, commentando il più possibile ogni approccio
elenco gli aspetti sfidanti del progetto e di cosa avrei bisogno in termini di risorse e conoscenze per risolvere il problema in questo momento
l'impatto che il progetto ha sul business

Il punto 5 ci aiuta nello storytelling post-progetto, vale a dire la fase in cui presentiamo e spieghiamo i nostri risultati ad una platea. Documentare i passaggio e parlare del mio processo ci permetterà di avere una solida storia da raccontare agli stakeholder (le persone importanti che ruotano intorno al progetto, come investitori oppure il nostro capo). La comunicazione è importante quanto le nostre capacità analitiche.

3. Fissare un obiettivo di performance raggiungibile

Dovremmo parlare spesso con gli stakeholder per capire le loro aspettative sul tuo lavoro. Parla con loro del livello di prestazioni che si aspettano di vedere e della soglia di soddisfazione. Questo è un valore minimo di prestazioni che dovresti mirare a raggiungere.

Per avere un'idea di come potrebbe funzionare il modello, prendiamo questo in considerazione:

se un essere umano può fare lo stesso lavoro senza molti problemi, allora è lecito ritenere che il modello performerà a livelli simili
se inserisci nel modello dati di alta qualità, ovvero dati che contengono informazioni rilevanti sul target, è lecito ritenere che il modello perfomerà bene
se un software può ottenere buoni risultati senza usare un approccio basato sul machine learning, allora è lecito ritenere che il modello performerà a livelli simili
se un altro algoritmo di machine learning può ottenere buoni risultati su un set di dati simile,
allora è lecito ritenere che il modello performerà a livelli simili

4. Scegliere una (e una sola) metrica di performance

Questo è strettamente correlato al punto precedente. Un modello ha una performance metric che possiamo assegnargli prima dell'addestramento. Ad esempio, un compito di regressione potrebbe richiedere di impostare le metriche RMSE (Root Mean Squared Error) o MAE (Mean Absolute Error).

Bisogna scegliere la metrica che ha più senso per il problema che abbiamo davanti. Scegli una e una sola metrica di performance e non cambiarla. Confronta e monitora diversi modelli per capire come cambia la metrica tra i modelli. Parlo di selezione del modello e valutazione delle metriche di performance qui.

5. Definire una baseline

Dovremmo sempre confrontare i tuoi modelli con una baseline. Questa è una condizione "di base" dalla quale partiremo. Se confrontiamo il nostro risultato con una baseline sapremo sempre se stiamo performando meglio o peggio delle aspettative.

Una baseline varierà a seconda del nostro compito. Ecco alcuni esempi:

una baseline può essere basata sulle performance di un essere umano. Il nostro modello viene quindi confrontato con le prestazioni umane nello stesso compito
una baseline può essere una previsione casuale: l'algoritmo sceglie un valore casuale dal set di addestramento y
una baseline può seguire una regola specifica: per un compito di classificazione può restituire la classe più frequente mentre per una regressione può restituire il valore medio di y
una baseline può essere un modello semplice e rudimentale

Se il tuo modello performa meglio della baseline, allora sai che stai fornendo valore alla tua azienda/team.

6. Dividere i dati in tre partizioni

Kaggle e i vari famosi creatori di contenuti sul web hanno trattato a fondo questo aspetto, ma è ancora qualcosa a cui prestare molta attenzione prima dell'addestramento.

Dobbiamo assicurarci che i nostri dati siano divisi in tre parti: set addestramento, di validazione e di test. Ecco le differenze:

il set di addestramento (in inglese, train set) è usato per addestrare il tuo modello, ed è ciò che il nostro modello "vede" per imparare a predire il target
il set di validazione non viene mostrato al modello, ed è usato per testare algoritmi e loro parametri
il set di test non viene mostrato al modello e viene utilizzato per valutare l'intera pipeline

Mi piace usare questa metafora:

Il modello è come un bambino a scuola. Il bambino che studia a scuola è il tuo modello che impara dal train set, il bambino che fa gli esercizi a casa è il tuo modello che viene testato sul set di validazione e il bambino all'esame finale è il modello sul test set.

Ricorda che i tuoi set di validazione e test devono provenire dalla stessa distribuzione statistica del tuo set di addestramento, altrimenti il modello verrebbe esposto a dati non utili. È come il bambino che studia un capitolo su cui non sarà mai messo alla prova.

Conclusione

Ecco un sunto dei temi toccati

Usa un file schema per tenere traccia delle tue feature e delle loro proprietà
Scrivi tutte le informazioni rilevanti nel tuo file README.md durante tutte le fasi del progetto
Imposta metriche di performance raggiungibili: parla con i tuoi stakeholder per capire le loro aspettative
Scegli una e una sola metrica di performance
Confronta i tuoi modelli con una baseline per capire il valore che stai aggiungendo all'operazione
Assicurati di partizionare i dati nel modo corretto.