La Computer Vision (CV) è una delle specializzazioni dell’intelligenza artificiale (AI) per le quali, così come per il Natural Language Processing (NLP), negli ultimi anni si può osservare un trend sempre crescente di casi d’uso in diversi settori. Prendendo in esame i paper di ricerca specifici degli ultimi 2/3 anni si può notare una netta maggioranza di proposte di nuovi algoritmi di Deep Learning, GAN, Semantic Segmentation, etc. e/o ottimizzazioni di quelli esistenti avulse da contesti applicativi reali. Il mondo accademico spesso sembra perdere di vista la realtà dell’industria, rendendo così difficile (se non impossibile in alcuni casi) l’applicazione pratica di nuove idee teoriche. Stesso mindset si ha modo di osservare nelle iniziative con studenti universitari e con Data scientist freschi di laurea. Ecco, in base all’esperienza nel settore di chi scrive, quali sono gli scenari effettivi e le sfide da affrontare quando si tratta di mettere in produzione sistemi di Computer Vision.
I 12 punti da affrontare per produrre sistemi di Computer Vision
Il tutto si può riassumere in 12 punti. Una parte di questi punti è comune a tutti i casi di Computer Vision, una parte è più specifica per determinati settori produttivi, alcuni comuni anche ad altri casi di AI.
Domain Knowledge
Il miglior tipo di approccio a sistemi di Computer Vision (e in generale di AI) consiste nello stabilire una conversazione continua con gli stakeholder e i destinatari del sistema. Prima di lanciarsi in qualsiasi Proof of Concept (PoC) o implementazione diretta è importante comprendere a fondo il tipo di business che essi conducono e quali siano i loro veri bisogni e problemi. È facile, se si ragiona solamente con la mentalità da Data Scientists/ML Engineers, lanciarsi subito in proposte di implementazione che pur essendo assolutamente valide da un punto di vista tecnico e basate su algoritmi che sono lo stato dell’arte per l’AI, non rappresentano la soluzione adatta per il caso specifico. È importante in questa fase includere tutti i team members e non restringere questo dialogo a un singolo referente.
Allo stesso tempo bisogna intraprendere un percorso formativo verso i destinatari del sistema in modo da metterli al corrente di cosa significhi veramente AI, al di là dell’hype che viene quotidianamente generato sull’argomento, principalmente da media non del settore e da taluni vendors di tecnologie e servizi, che può generare in loro false aspettative.
Queste pratiche non vanno fatte solo nella fase iniziale di un progetto: è un percorso di tipo continuo e iterativo,
- Regolamentazioni
Alcuni settori, quali ad esempio, l’healthcare, il manufatturiero o il farmaceutico, sono soggetti a diverse regolamentazioni che non possono essere ignorate in fase di definizione dei requisiti, disegno e implementazione di sistemi di Computer Vision. A questi vanno aggiunti, dipendentemente dall’area geografica oltre che dal settore, anche altre regolamentazioni sulla protezione dei dati, quali GDPR, CCPA, HIPAA, etc.
Accesso ai dati
A parte le leggi sulla protezione dei dati e altre regolamentazioni specifiche di alcuni settori, diverse multinazionali hanno anche delle regolamentazioni interne che definiscono chi possa avere accesso o meno a dati di produzione. Quindi, bisogna esserne al corrente sin dall’inizio e capire se esistono già processi di anonimizzazione dei dati oppure bisogna considerarne l’implementazione ai fini di training, validazione e testing dei modelli. Nonostante le loro regole interne di protezione dei dati siano consolidate da tempo, esistono ancora molte aziende che non hanno predisposto processi snelli e automatizzati per garantire accesso ai dati per fini di sviluppo software o implementazione di sistemi AI e/o per la loro anonimizzazione.
Scarsità di dati
Una volta superato lo scoglio dell’accesso, spesso ci si accorge che per alcuni fenomeni da osservare la disponibilità di dati specifici non è tale da poter far partire il prototyping dei modelli e per poter imbastire il loro processo iniziale di apprendimento. Questa è una situazione non infrequente nei sistemi di Computer Vision in ambito industriale, in particolar modo nei casi di visual inspection, dove alcune tipologie di difetti, per quanto particolarmente critici e quindi non trascurabili, si presentano raramente nell’arco di un lungo periodo di tempo per una linea di prodotto/i. Bisogna quindi identificare questi casi nelle fasi iniziali del progetto e predisporre strategie per mitigarne gli effetti (one-shot or few-shot learning, data augmentation, synthetic data generation, etc.).
Qualità dei dati
La stragrande maggioranza di paper di ricerca di sistemi di Computer Vision utilizza data set di pubblico dominio, quali per esempio ImageNet[1], Fashion MNIST[2], CIFAR-10[3], etc., o data set curati ad hoc, che includono immagini o video a ottima risoluzione e spesso perfettamente a fuoco, un numero di immagini bilanciato per ciascuna categoria, complete di label e di tutti i relativi metadati e spesso anche una divisione tra immagini per il training e per il testing già fatta con una distribuzione uniforme delle varie classi. Questo scenario non si incontra mai nel mondo reale. In ambito industriale, per esempio, le fotocamere e videocamere montate su macchinari di visual inspection o altri macchinari o sistemi di sorveglianza hanno una risoluzione molto bassa e le immagini includono anche altre informazioni non necessarie oltre alle regioni di interesse: quindi operazioni complesse di pre-processing sono necessarie prima che immagini o video possano essere utilizzati per training e validazione di modelli e per poter riprodurre quanto descritto nei paper (e verificarne l’applicabilità al caso specifico). Per rendere ancora più complesso lo scenario, diversi vendor non prevedono la possibilità di interfacciarsi programmaticamente con i macchinari industriali che producono, rendendo così difficile o in alcuni casi impossibile l’acquisizione automatica di metadati. Ovviamente immagini provenienti dalla produzione industriale non sono provviste di label, quindi bisogna predisporre sistemi smart di labelling per gli SME (Subject Matter Experts) oltre che lavorare in piena sinergia con essi per poter creare un context per immagini e video e procedere verso strategie di unsupervised learning.
Questi task normalmente occupano circa il 40% del tempo dedicato a progetti di Computer Vision.
Questo punto, insieme a quelli precedentemente descritti, fa chiaramente capire come i progetti di sistemi Computer Vision in ambito produttivo siano decisamente diversi, non solo da contesti di pura ricerca, ma anche da competizioni online, dove tutto è già apparecchiato per poter iniziare a fare prototyping e training (cosa che poco tempo fa su Twitter, parafrasando una frase di un famoso film del 1939[4], mi ha fatto coniare a riguardo il detto, “we’re not in Kaggle anymore”).
Competenze tecniche
Un altro grosso problema derivante principalmente dall’hype intorno alla AI, riguarda la direzione degli investimenti in termini di competenze. Capita ancora oggi di vedere molte aziende lanciarsi per la prima volta in progetti di Machine Learning (ML) o AI, destinare capitali significativi per l’assunzione di Data Scientist, trascurando di procurarsi altre figure essenziali che permettono di evitare di incappare in casi di debito tecnico insormontabile e di rendere i progetti di successo. Oppure capita di vedere altre aziende che, pensando di risparmiare, tendono a creare unicorni convertendo Software Engineer senza alcun bagaglio specifico in Data Scientist o ML Engineer. Altre ancora, facendosi abbagliare da vendor di tool e servizi per ML e AI spacciati come low o no-code, pensano che non siano affatto necessarie persone con le giuste qualifiche. Tutte queste strategie non funzionano: c’è bisogno di creare team multi-disciplinari, fatti di persone con le giuste competenze (tecniche e non), da considerare come investimento e non come costi.
A questo riguardo voglio aggiungere anche un altro problema specifico per il mercato italiano. È noto a tutti che nello scorso decennio c’è stata una massiccia migrazione all’estero di professionisti italiani dell’IT, Big Data e ML/IA che ha di fatto quasi prosciugato per le aziende operanti nel mercato italiano il bacino di competenze da cui poter attingere. Per diversi motivi (salari non adeguati alle competenze ed esperienza dimostrate e anche al reale costo della vita, mancanza di meritocrazia, impossibilità di lavoro parzialmente da remoto e/o orari flessibili, mancanza di visione strategica nel medio e lungo periodo, disparità basate sull’età e sul sesso) non è affatto facile trovare qualcuno bravo disposto a rientrare in Italia. Quindi si è scatenata la caccia ai neo-laureati nelle discipline sopra menzionate. Il problema di questa strategia, a mio avviso, basandomi su esperienze professionali personali e osservando l’evoluzione del mondo AI al di fuori dei confini nazionali, è che un professionista italiano che ha maturato esperienze all’estero ha avuto modo di testare il proprio valore sul campo in casi d’uso in produzione che fino a 2/3 anni fa erano impensabili in Italia e ha quindi avuto modo di acquisire anche competenze di particolari contesti di business, non solo tecniche, fondamentali per progetti AI e che inevitabilmente non si possono avere venendo direttamente dall’università. Quindi l’Italia in questo fronte rischia di rimanere ancora indietro rispetto a molti paesi EU e non EU anche nel medio termine.
Infrastruttura tecnica
L’hype attorno all’AI fa inoltre si che molte aziende, sia per poter strombazzare le loro iniziative nello specifico, sia per mancanza di maturità, decidano di accelerare i tempi iniziando le varie fasi di un progetto prima che l’infrastruttura sia stata definita o ancora in fase di implementazione. Questo provoca inevitabilmente, in particolare per applicazioni di CV, rallentamenti rispetto ai tempi di realizzazione previsti o addirittura il fallimento di una iniziativa. È necessario porsi parecchie domande sull’infrastruttura tecnica prima di buttarsi a capofitto nella esecuzione di un progetto di Computer Vision, quali ad esempio: che tool servono realmente a Data Scientist e ML Engineer per poterne massimizzare la produttività? Qual è la tipologia di storage che più si adatta al tipo di dati coinvolti? È possibile una soluzione completamente cloud based o ci sono delle restrizioni tali da dover considerare una soluzione ibrida? Qual è la potenza di calcolo stimata? Serviranno GPUs o sarà possibile farne a meno? E tantissime altre che non possono essere posticipate a lavori in corso.
Purtroppo le strategie di molti vendor non aiutano in questa conversazione con il business. A volte in buona fede, in quanto non a conoscenza di come funziona uno specifico settore e/o dei reali bisogni di progetto, altre volte perché il loro unico obiettivo è quello di indirizzare il cliente verso la soluzione che massimizza solo il loro ROI. Ma è compito degli architect e dei delivery lead traghettare verso l’infrastruttura tecnica ottimale per lo specifico progetto.
Riproducibilità degli esperimenti
Implementare modelli per Computer Vision in ambito produttivo non è la stessa cosa che fare il training e la validazione per un progetto personale da condividere su GitHub o partecipare a qualche competizione in Kaggle. Un aspetto critico in questo processo riguarda la riproducibilità degli esperimenti, cioè la possibilità di ricreare un workflow per un modello e raggiungere le stesse conclusioni di quello originale. I principali frameworks per ML/AI forniscono API di alto livello che rendono l’implementazione del codice necessario per il design, hyperparameter tuning, training, validation e inference relativamente facile e veloce (stessa cosa per quanto riguarda la maggioranza di librerie accessorie per image pre-processing, data augmentation, qualsiasi post-inference activity). Ma, una volta che sono state raggiunte o superate le KPI prefissate, non basta fare il versioning di un modello serializzato e del relativo codice sorgente. Così facendo si perdono una marea di informazioni (data lineage, criteri utilizzati per lo split del data source iniziale in training and testing data, data shuffling, feature engineering, valori utilizzati per gli hyperparameter, metriche di accuratezza, metriche di sistema, hardware utilizzato, etc.) che impediscono di riprodurre e verificare il processo di training e validazione di un modello. Se poi si tiene anche conto del fatto che normalmente per un determinato problema si eseguono più esperimenti con più di un modello e/o lo stesso modello con diverse configurazioni di hyperparameter, allora si può capire che è importante anche poter eseguire una comparazione fra esperimenti prima di decidere quale modello possa essere il candidato ideale da poter muovere in produzione e risulterà anche impossibile fare un’analisi a posteriori nei casi in cui le performance in produzione siano inferiori alle aspettative.
A tale scopo bisogna impostare un sistema di experiment tracking come parte integrante delle ML/AI pipelines, ma anche educare i Data Scientist a pensare che i modelli su cui stanno lavorando non dovranno alla fine essere utilizzati solo nel loro environment, ma in un contesto produttivo reale.
Automazione
Techniche di Continuous Integration (CI) e Continuous Delivery (CD) sono ormai parte integrante della cultura di quasi tutte le aziende che sviluppano prodotti e servizi software. Lo stesso tipo di approccio DevOps si applica perfettamente anche nella gestione end-to-end di ML/AI pipeline, che però richiede anche l’adozione di altre pratiche specifiche (l’experiment tracking è una di queste). Mentre per un Software Engineer avere una mentalità DevOps è parte integrante del suo DNA, lo stesso non vale spesso per un Data scientist, la cui mentalità è più orientata alla ricerca che al delivery. Questo è un aspetto su cui bisogna lavorare molto sin dal primo giorno di un progetto per evitare l’accumularsi di un debito tecnico destinato a diventare insormontabile.
Monitoraggio
La messa in produzione di un modello per sistemi di Computer Vision è solo l’inizio. Un sistema di monitoraggio delle performance (che può anche includere funzionalità di explanability) in produzione, che prima o poi sono destinate a deteriorarsi, deve essere già operativo prima di procedere con il primo rilascio. Anche nei casi in cui le performance di un modello continuino ad essere accettabili, le informazioni provenienti dal monitoraggio sono un ottimo feedback per Data Scientista e ML Engineer per capire se ci possano essere margini di miglioramento.
Business value
Qual è l’unico modo sicuro per capire se un determinato sistema di Computer Vision sta generando il business value previsto? La risposta è semplice: mettere il sistema in produzione. Non esiste altro modo: non basta aver dimostrato di aver trovato la giusta architettura e conseguito altissime performance per i/il modello/i coinvolti. Altro motivo in più per seguire le best practice e suggerimenti ai punti precedenti.
Comunicazione
ML/AI in generale e Computer Vision in particolare, sono ambiti ai quali modelli di business tradizionali non si adattano perfettamente. Inoltre, come già indicato in precedenza, l’hype esistente contribuisce parecchio a confondere le idee di stakeholder e sponsor. Quindi, in tutte le fasi di progetto, dall’inception alla messa in produzione e successiva gestione, è importante stabilire il giusto livello di comunicazione, fatto su misura per l’audience specifica, in modo da generare chiarezza su quanto si ha in piano di fare, quanto è stato completato e sui risultati ottenuti e poter così ottenere il riscontro desiderato. Questa abilità è qualcosa che si può imparare solo sul campo ed è compito di tech managers e delivery leads guidare figure tecniche meno esperte nella preparazione delle presentazioni e del linguaggio giusto da utilizzare in base al tipo di audience.
Conclusioni
A questo punto ci si starà molto probabilmente chiedendo se a questa trattazione non manca qualcosa. Non c’è alcun esplicito riferimento in questo articolo alle sfide prettamente specifiche per gli algoritmi di Computer Vision. Questa mancanza è voluta: come accennato all’inizio, un grosso contributo in questa direzione continua a venire dall’Università e dalla Ricerca. Il compito di bravi professionisti AI è quello di tradurre quei concetti teorici in solide realtà e generare business value seguendo best practice come quelle sopra descritte.
- https://image-net.org/ ↑
- https://github.com/zalandoresearch/fashion-mnist ↑
- http://www.cs.toronto.edu/~kriz/cifar.html ↑
- https://en.wikipedia.org/wiki/The_Wizard_of_Oz_(1939_film) ↑
