Vediamo un argomento che unisce architetture dati e machine learning.

Normalmente in machine learning si parte da dati di training già puliti, si fa il training e si ottiene il modello che a sua volta, con una serie di dati reali, produce dei risultati. In produzione tutto questo non è sufficiente e non si ha tanta importanza nella fase di train e serve ma nei dati in se. Bisogna prepare bene i dati per il ML, avendo il rischio di garbage in, garbage out in quanto i computer elaborano in modo acritico anche un insieme di dati in entrata palesemente insensati (garbage in) producendo, a loro volta, un risultato insensato (garbage out). La fase di prepare dei dati è quindi fondamentale, mediamente:

• 80% del tempo è data preparation
• 5% del tempo è identificazione del modello
• 5% del tempo è training
• 5% del tempo è deployment e altri lavori minori

Bisogna poi, per i risultati, fare data validation, data monitoring ed eventuali correzioni.

I dati di input vengono mediamente divisi in training (grandi) e serving (piccoli) come già sappiamo.

Pipeline ML tipica

Nella fase di prepare dei dati di training bisogna valutare quali sono le feature rilevanti, fare data exploration dei valori delle feature, quali sono le migliori pratiche per estrarre dai valori delle feature i migliori valori per il modello di machine learning etc... Si parla di feature selection e feature engineering. Bisogna poi valutare il modello, capendo se è abbastanza buono, se deve essere modificato o se servono più dati o più feature.

In produzione però bisogna andare oltre, basti pensare che magari una fonte dei dati subisce un refactoring e tutto il modello si “rompe”, avendo data failure, con performance che crollano o peggio, se si parla di reinforcment learning, si ha il modello che viene allenato con dati errati (e riaddestrare è costoso). Si vede quindi che il problema non è il modello in se ma i dati.

Bisogna quindi validare i dati in input al modello prima di darli in pasto al modello per capire se è tutto corretto. Bisogna tenere conto anche delle “deviazioni” dei dati che dipendono dalle situazioni a contorno dell’environment (ad esempio un modello per il traffico addestrato l’anno scorso non vale ora causa pandemia). I problemi vanno quindi fixati, per poter poi ricreare i dati di testing serving e riprendere l’intero ciclo di vita.

Dal punto di vista del personale si hanno almeno 3 figure:

• l’esperto di ML, che studia il modello
• il software / web engineering (SWE), che effettivamente sviluppa il modello
• il site reliability engineering (SRE), che si occupa appunto di fixare i vari problemi (sia dei dati che di interazione con il cliente)

Crisp-DM Reference Model

Quelli cerchiati in giallo sono quelli di cui non ci siamo occupati fin’ora.

Più nel dettaglio: