Making AI uncool again - Parte 1: il debito tecnico
Primo passo verso quei temi "noiosi" che limitano la reale adozione dell'AI nelle aziende
Original in Italian; automatic translation into English available here.
Intro
Vi considerate esperti o appassionati di Intelligenza Artificiale? Avete sentito parlare di Jeremy Howard?
Se la combinazione di queste due risposte è “SI” e poi “NO”… you’re missing out!1
Quest’uomo sorridente in foto appartiene sicuramente alla folta schiera delle menti brillanti che da tempo sono nel mondo della tecnologia e dell’AI.
Già fondatore di Fastmail nel 1999 e poi Chief Scientist e presidente di Kaggle nei primi 3 anni di vita della piattaforma (2010-2013), penso che Howard sia noto ai più per il suo ruolo di fondatore di fast.ai, dal 2016 un ottimo punto di riferimento per chi vuole imparare cosa siano realmente le reti neurali. La sua carriera è impressionante e include vari incarichi universitari e anche parecchi anni nella consulenza manageriale, esperienza che lo ha portato a mettere nella sua biografia su Kaggle:
Ex-management consultant, now nearly fully recovered.
Howard mi ha ispirato il titolo di questo articolo e della serie che verrà. Già nel lontanissimo 2016, aveva capito che stava montando l’hype sul deep learning e aveva associato a fast.ai questo motto:
Making neural nets uncool again
Oggi penso sia proprio il caso di allargare il perimetro: tutto il mondo dell’AI va reso un po’ più uncool, un po’ più noioso… o almeno, questo se poi si vuole andare oltre i titoli di giornali e se con l’AI si vuole realmente fare qualcosa che non sia una presentazione con effetto wow.
Perché questa serie di post
È tutta colpa di ChatGPT e Sam Altman, ma arriviamoci per passi.
Era il 2006 quando Amazon Web Services lanciò sul mercato i due primi servizi Cloud, S3 (Simple Storage Service) ed EC2 (Elastic Cloud Compute). Era nato il Cloud, qualcosa che avrebbe rivoluzionato il mondo, non solo tecnologico.
Oggi non avremmo Netflix, AirBNB, Uber, Spotify e molte altre, se non fosse stato per il Cloud. Ma tantissime altre aziende, direi quasi tutte (ad eccezione dei dinosauri che si sa, non hanno fatto una bella fine), usano oggi uno o più cloud provider.
Ecco: nei primi anni non sono state molte le persone non-tech che si sono convinte (o illuse) di aver capito a fondo cosa fosse il Cloud e quali vantaggi potesse portare. È stato chiaro ai più, fin da subito, che capire e sfruttare al meglio il Cloud fosse un tema per esperti tech - e questo ha portato ad uno sviluppo e un’adozione in gran parte sana per questo nuovo paradigma tecnologico.
Nel mondo dell’AI è diverso. Se approfondire il cloud e padroneggiarlo sul serio è un’arrampicata, o almeno una camminata in montagna di media difficoltà, dare un assaggio all’AI sembra facile come una passeggiata al lago: possono farlo tutti. Basta andare su ChatGPT e chiedergli la prima cosa che ci passa per la testa: è un attimo tuffarsi di slancio nell’effetto di Dunning Kruger2!
Il risultato che vedo è una forchetta che si allarga tra aspettative e risultati nel mondo dell’AI, specialmente quella generativa.
Perché l’adozione di una strategia sull’AI va a rilento? Perché ci vuole così tanto, quando usare l’AI è così semplice, e pure gratis? Perché non siamo neanche lontanamente veloci come [inserisci nome a caso di società di consulenza] sostiene che potremmo/dovremmo essere?
Molti leader e manager si fanno queste domande. E per trovare delle risposte non servono consulenze dal costo di migliaia di euro a slide, ma solo un po’ di impegno per approfondire qualche tematica noiosa che spesso rappresenta il vero ostacolo.
Cos’è il debito tecnico
Dovendo scegliere il primo argomento uncool, ho deciso di concentrarmi sul debito tecnico.
Le definizioni sono tante. Personalmente vedo il debito tecnico come l’accumulo di una serie di soluzioni quick and dirty, messe in piedi quando si è dovuto prioritizzare la velocità rispetto alla pulizia di software o architetture.
Ma anche una mancanza di cura per tutto ciò che è tecnologia. Perché, come sa bene chi fa software, non si dovrebbe raggiungere mai la versione final: o un software diventa inutile - e allora va dismesso - oppure va tenuto aggiornato.
Esattamente come per il debito finanziario, anche per quello tecnico più si va avanti e più aumentano gli interessi… e pure gli anatocismi3, esattamente come nel mondo bancario.
E sempre proseguendo la metafora economica, non tutto il debito è cattivo.
In una prima fase (lancio di un sofware, di un data product, di qualsiasi cosa tech) è del tutto normale prendersi qualche libertà: troppo controllo, troppa governance, troppi standard uccidono l’innovazione. E soprattutto il successo del progetto (quale che sia) non è certo. Ma se tutto fila liscio… bisogna invertire la rotta e combattere il debito tecnico.
Il rapporto tra AI e debito tecnico
A prima vista, il tema di oggi potrebbe sembrare puramente legato al mondo dell’IT, ed in particolare alle sue aree più convenzionali: applicativi di ogni sorta, infrastrutture, sicurezza e tanto altro.
Invece molti progetti di AI si scontrano regolarmente con problematiche di debito tecnico.
L’AI come soluzione standalone ha infatti sicuramente il suo spazio e il suo valore nel mondo delle imprese (pensiamo ai già citati tool conversazionali general-purpose basati sugli LLM, oppure agli assistenti al coding), ma dove l’AI può e deve dare risultati tangibili è nell’integrazione con il mondo aziendale esistente e il suo coacervo di tecnologie, che nella maggior parte delle grandi aziende sono cronicamente in crescita.
È qui che nascono i problemi: si investe su AI e tecnologia all’avanguardia… e poi ci si scontra con l’interfacciamento a sistemi di altre epoche e spesso abbandonati al proprio destino.
Ma c’è anche una seconda tipologia di debito tecnico legata all’AI. Pensiamo a Langchain, forse il più famoso framework per sviluppare RAG4. In un contesto velocissimo come quello della GenAI, il team di sviluppo si è buttato a capofitto per integrare tanti LLM diversi, rimanendo ad una versione 0.x in cui la backward compatibility5 è sostanzialmente un optional.
Per chi usa questo framework (e tanti altri), la tentazione di restare ad una versione “consolidata” è alta, rimanendo indietro di decine o centinaia (!) di release. Ma tanti auguri nel momento in cui sarà necessario fare un aggiornamento!6
Un mostro a tante teste
Penso che il debito tecnico sia un tema difficilissimo da affrontare, un mostro a più teste in cui tanti elementi distinti concorrono ad un crescita che sembra ineluttabile.
Il primo aspetto problematico (e anche il più ovvio) è che ridurre il debito tecnico non porta risultati economici nel breve termine e tutti, dai product owner ai team di sviluppo, preferiscono lavorare su nuove feature, piuttosto che “mettere ordine”. E su questo c’è davvero poco da stupirsi: tipicamente ci si accorge dell’impatto devastante del debito tecnico in occasione di qualche incidente in produzione, oppure quando ha raggiunto proporzioni gigantesche.
Un secondo punto da considerare è legato al fatto che ogni azienda si trova sempre in un contesto mutevole, sia a livello interno che in termini di mercato. Investire tempo e denaro nel ridurre il debito tecnico su un software o un’architettura è sempre una scommessa: non si può escludere che la rilevanza di quella componente tecnologica venga superata (per mille motivi) e quindi lavorare sul debito tecnico può anche rivelarsi tempo perso.
Ultimo, e a mio avviso più importante, è un semplice tema di incentivi. Il top management di un’azienda ha tipicamente obiettivi a breve-medio termine (trimestrali e annuali) e le figure apicali hanno mandati della durata di alcuni (pochi) anni. Dimentichiamoci di Jensen Huang, da oltre 30 anni CEO di Nvidia: di solito i vari CxO hanno durata ben più breve.
E quindi perché ai livelli più alti bisognerebbe occuparsi di debito tecnico, quando si può semplicemente cercare di spostare ancora un pochino più avanti il momento di un intervento… che poi magari toccherà ad altri?
Conclusioni
Il debito tecnico è sempre più presente nelle aziende complesse, con effetti deleteri a 360°.
E quando il lavoro è parcellizzato, senza una chiara visione tech e magari con un abuso dell'outsourcing verso società esterne, la prospettiva non è rosea.
Esiste una qualche via d’uscita?
Ci sono tanti spunti interessanti:
Qualcuno ha proposto di inserirlo come liability nei bilanci d’impresa;
Finalmente qualcun altro si è reso conto che il debito tecnico è un serissimo rischio per un M&A di successo, quindi deve essere oggetto di assessment né più né meno degli aspetti finanziari e legali;
Più in generale, se ne parla ripetutamente anche nel mondo della consulenza manageriale.
Sono buoni passi in avanti e personalmente penso che sia fondamentale che ogni manager o leader (anche non tecnico) abbia chiaro questo concetto.
Sicuramente questa conoscenza condivisa sul tema è un buon punto di partenza. Personalmente però non ho trovato un framework o un modus operandi standard per gestire questo argomento spinoso… al momento, ritengo che stia ad ogni leader tecnico di trovare la propria ricetta per prioritizzarlo nelle attività dei team, prima che sia troppo tardi o che ostacoli le innovazioni, a cominciare dall’AI!
“Vi state perdendo qualcosa!”
Una distorsione cognitiva nella quale individui poco esperti e poco competenti in un campo tendono a sovrastimare la propria preparazione giudicandola, a torto, superiore alla media (come recita Wikipedia)
Gli interessi sugli interessi
Retrieval Augmented Generation: l’approccio ormai classico per integrare un LLM general purpose (es. di OpenAI, Anthropic e altri) con base documentali private.
Il fatto che una versione successiva sia sempre compatibile con la precedente, e che quindi un aggiornamento non “rompa” gli sviluppi fatti a partire dalle versioni precedenti
Mia esperienza personale (non legata al mio lavoro): ho giocato un po’ con Langchain per la prima volta a Febbraio 2023, su consiglio di un amico. Versione 0.0.78. L’ho un po’ ignorato per 2-3 mesi… quando l’ho usato di nuovo erano arrivati alla 0.0.178, con cambiamenti enormi al framework.
Grazie, finalmente un insight molto chiaro sui problemi del settore IT e quindi drll'adozione dell'I.A.!!
molto interessante. Penso sia difficilissimo da misurare il valore del debito tecnico per una infrastruttura