Intelligenza artificiale, il “debito tecnico” frena le aziende: che fare

Se in molti settori l’impiego dell’intelligenza artificiale è già una realtà, per altri è ancora un terreno da scoprire valutando possibili vantaggi di business: è il caso di Industria 4.0 e IIoT (internet delle cose). Una spiegazione di questo ritardo secondo la mia personale esperienza in Big Data e AI è da ricercarsi nel cosiddetto debito tecnico accumulato da gran parte delle aziende che possono essere classificate come appartenenti a tale categoria. Ecco di cosa si tratta e i consigli per una strategia che punti a superare il problema.

Il debito tecnico delle aziende

È un concetto dell’ingegneria del software introdotto nel 1992 dall’informatico statunitense Howard G. Cunningham ed è analogo al debito fiscale. Un progetto software può accumulare debito tecnico (intendiamoci, alle volte, per diversi motivi, è normale accumularne una percentuale), ma, esattamente come per il debito fiscale, esso deve essere rimborsato. Quando ciò non accade iniziano a sorgere seri problemi. Ogni minuto speso nello scrivere codice di scarsa qualità incide come interesse su quel debito.

In ambito software esistono diversi modi per effettuare il “pagamento”, ma bisogna comunque sempre tenere a mente che l’obiettivo di tali pagamenti non è aggiungere nuove funzionalità ad un’applicazione/sistema, ma semplicemente introdurre migliorie, ridurre il numero di bugs e migliorarne la manutenzione. Il pericolo proveniente da questo tipo di debito è spesso nascosto e una strategia di rinvio di tali pagamenti si traduce alla fine in costi spropositati (senza contare altri tipi di conseguenze negative derivanti da questi ultimi).

Iniziative di Intelligenza Artificiale in Industria 4.0

Vediamo adesso in che maniera questo concetto si può applicare all’adozione di iniziative AI in ambito Industria 4.0. Quando si parla di tale argomento i riflettori sono tutti sugli algoritmi di AI da adottare o implementare per il caso specifico: il che, da un punto di vista del business non è sbagliato, ma questo dovrebbe andare di pari passo con altre considerazioni che vado adesso a spiegare. La prima cosa a cui bisognerebbe dedicare attenzione sono i dati (e quando si tratta di Deep Learning o Machine Learning stiamo parlando di Big Data, in termini quindi non solo di volume, ma anche di varietà e velocità). Per migliorare l’accuratezza dei modelli è fuor di dubbio che sia necessario disporre di dati. Il progresso tecnologico degli ultimi dieci anni ha reso possibile raccogliere dati provenienti da molteplici sorgenti (molte delle quali impensabili fino a qualche anno fa) e quindi nel 90% delle situazioni di IioT non c’è affatto carenza di dati, ma si tratta di una grande disponibilità di dati grezzi (se considerati dal punto di vista degli algoritmi). Dopo essere stati raccolti, i dati devono essere analizzati e per-processati prima che possano essere utilizzati per scopi di training e validazione dei modelli. E questa è l’area in cui il debito tecnico può accumularsi maggiormente. Esso è quindi difficile da rilevare perché esiste a livello di sistema e di dati piuttosto che a livello di codice. L’accuratezza e le predizioni di modelli AI rischiano di essere seriamente invalidati da dati non corretti.

Per avere una panoramica più precisa di tale fenomeno possiamo osservare il seguente diagramma, tratto da una ricerca di Google del 2014, che mostra le proporzioni tra i diversi componenti di un sistema AI (o anche Machine Learning o Deep Learning):

In esso si può notare quanto sia piccola la zona relativa al codice IA/ML/DL (il rettangolo nero al centro) se confrontata con le altre parti che compongono il sistema. Ciò significa che le aree più inclini ad accumulare debiti sono al di fuori del codice dello specifico campo di applicazione (ed è evidente in particolare nelle aree a sinistra e in quelle centrali come i Big Data abbiamo un ruolo chiave).

Le dipendenze dei dati

Il debito tecnico relativo al codice e quello relativo alle dipendenze dai dati non hanno lo stesso peso: il secondo è molto più pericoloso, sia per la natura dei modelli di IA, sia perché non c’è ancora la stessa disponibilità e varietà di strumenti DevOps specifici per i dati, così come esiste per il codice. Tra le dipendenze dei dati, quelle che hanno il maggiore impatto sul debito tecnologico sono le seguenti:

• Dati instabili: alcune sorgenti possono appartenere a terze parti (interne o esterne all’azienda). Spesso non sono sotto il nostro controllo e quindi c’è da aspettarsi talvolta il fenomeno del cosiddetto data drift (cambiamenti nella struttura, nella semantica o nella sorgente stessa dei dati).
• Dati poco utilizzati: questi possono rendere un sistema IA inutilmente e catastroficamente vulnerabile ai cambiamenti. Tali dati sono tipicamente relativi a funzionalità legacy.
• Basso livello di maturità dei tools per l’analisi statica delle dipendenze dei dati.
• Strategie di test sui dati.
• Riproducibilità.
• Cultura: a volte le best practice che possono migliorare l’accuratezza di un sistema a qualsiasi livello non sono incoraggiate. Di pari passo non viene fatto uno sforzo per allineare e rendere i team coinvolti equamente qualificati in termini di competenze sia di Data Science che di Data Engineering.

La definizione di debito tecnico purtroppo non fornisce una chiara definizione di metriche rigorose che dovrebbero essere monitorate nel tempo per poterlo ridurre, perché tali metriche dipendono dall’implementazione del sistema specifico. Ma la consapevolezza di ciò che il debito tecnologico è e di quali siano le sue dipendenze dai dati certamente aiutano a identificare metriche e rimedi.  Tornando al diagramma presentato precedentemente si può intuire che la dipendenza dai dati non è l’unico fattore che incide sulla generazione di debito tecnico, ma sicuramente è la prima sfida da affrontare.

Le pratiche per una strategia di successo

In generale, una strategia destinata ad essere di successo per tenere conto del debito tecnologico dei Big data per un sistema IA (ed estinguerlo al più presto) non può prescindere dalle seguenti pratiche:

• Investimenti sulle persone, in particolare su quelle aventi gli skill necessari per questo tipo di iniziative. Non bisogna mai dimenticare mai che i sistemi e i servizi sono fatti dalle persone e che quindi queste sono il valore principale.
• Dare una chance alle tecnologie Open Source. Uno dei problemi più diffusi che vedo in ambito Industria 4.0 è l’adozione di costosissimi sistemi closed source proprietari. In genere i sistemi Open Source offrono la flessibilità necessaria per adattarsi al contesto specifico, hanno una maggiore scalabilità e forniscono strumenti e funzionalità che permettono di identificare più rapidamente e monitorare in maniera efficiente le metriche del debito tecnologico. Una delle maggiori preoccupazioni dei decision maker riguardo soluzioni Open Source è stata la mancanza di supporto per esse, ma ormai per tutte le più diffuse tecnologie OS disponibili per Big Data ed AI esistono aziende che ne forniscono supporto commerciale.
• Adozione di Open Standards. Questi esistono, ma diverse aziende in Industry 4.0 continuano a fare una certa resistenza in questa direzione, con la conseguenza di far lievitare i costi di implementazione (a causa di problemi di comunicazione tra diversi machine vender per la stessa catena produttiva, richiesta di funzionalità custom non banali che richiedono tempi lunghi e talvolta non sono realizzabili, etc.).
• Adozione di processi agili, non solo a livello tecnico, ma anche di business.
• Rendere il monitoraggio e la risoluzione del debito tecnico parti integranti del processo agile.
• Passaggio ad una mentalità DevOps (a patto ovviamente di essere “agili”) per ridurre i rischi di difetti in produzione e i costi di rilascio/manutenzione in ambienti di produzione.
• Identificazione di una strategia DataOps.
• Creazione di una cultura di gestione dei dati. Così come per la qualità, in iniziative AI in Industry 4.0 i dati devono essere visti come una responsabilità condivisa attraverso diversi attori coinvolti nel processo e non possono esserlo solo per poche persone: tutti, dal business allo sviluppo, devono essere data stewards. Questo passo è importante perche’ una azienda possa veramente definirsi data-centric.

Mentre gran parte di queste pratiche (se non tutte in molti casi) sono già consolidate ed ampiamente diffuse in altri settori, nelle realtà dell’Industria 4.0 in Europa in molti casi siamo ancora agli albori, con una livello di maturità inversamente proporzionale alle dimensioni dell’azienda. Ma questo trend adesso sta cambiando, perché’ le aziende coinvolte ne hanno intuito il valore strategico e hanno raggiunto la consapevolezza che l’alternativa è rimanere tagliati fuori dalla cosiddetta rivoluzione 4.0.