Quando le aziende implementano strumenti di intelligenza artificiale aziendale, spesso scoprono che il loro lago di dati può essere profondo, ma è disordinato. Anche se si parte da dati accuratamente curati, una cattiva gestione delle modifiche ai dati può portare a gravi conseguenze a valle.
Chad Sanderson è CEO e fondatore di Gable.ai, dove aiuta le organizzazioni a migliorare la qualità dei dati su scala.
Ho avuto modo di parlare con lui dell'importanza della qualità dei dati e di come i contratti sui dati possano garantire che le applicazioni costruite su grandi quantità di dati mantengano la loro integrità.
D: Lei proviene da un background di giornalista. Vuole raccontarci come è finito nel mondo dei dati e come si è appassionato alla scienza dei dati e alla qualità dei dati?
Chad Sanderson: "La scienza dei dati è qualcosa che ho iniziato a praticare come giornalista perché gestivo un mio sito web e dovevo impostare la web analytics. Ho imparato tutti i GA4, ho iniziato a eseguire test A-B, una scienza dei dati molto elementare. Poi mi è piaciuta così tanto che l'ho fatta diventare il mio lavoro a tempo pieno, ho imparato la statistica e ho finito per lavorare per Oracle come analista e data scientist.
Poi ho iniziato a gestire team nel settore dei dati. All'inizio mi occupavo più che altro di sperimentazione e di team di analisi. Poi ho iniziato a spostarmi verso l'ingegneria dei dati e infine verso l'infrastruttura, le piattaforme di infrastruttura dei dati.
Ho lavorato alla piattaforma di intelligenza artificiale di Microsoft. E poi ho anche diretto la piattaforma di intelligenza artificiale e dati di una società tecnologica di trasporto merci in fase avanzata, Convoy".
D: Recentemente ha parlato all'MDS Fest dei contratti sui dati e di come questi consentano alle aziende di avere una governance dei dati federata. Vuole spiegare brevemente di cosa si tratta?
Chad Sanderson: "I contratti sui dati sono una sorta di meccanismo di implementazione della governance dei dati federati e della gestione dei dati federati.
Fondamentalmente, nel vecchio mondo, quindi nel mondo legacy, on-prem, 20 anni fa, c'erano architetti dei dati che costruivano un intero ecosistema di dati in un'azienda, a partire dai database transazionali, i sistemi ETL, tutti i vari meccanismi che trasformano i dati e li preparano per l'analisi, la scienza dei dati e l'intelligenza artificiale.
E tutti questi dati sono stati forniti agli scienziati da un team centralizzato. Si può pensare che sia lo stesso modo in cui un bibliotecario gestisce una biblioteca.
Si assicurano di quali libri arrivano, di quali libri escono, di come sono organizzati i libri, e questo rende molto facile per i ricercatori trovare le informazioni di cui hanno bisogno per i loro progetti.
Ma quello che è successo 15 anni dopo, 20 anni dopo, è che siamo passati al cloud e agli ingegneri del software, e il software si è mangiato il mondo, come dice Mark Andreessen, e ogni azienda ha deciso di diventare un'azienda di software. Il modo in cui le aziende gestivano le attività di software era lasciare che i team di ingegneri si muovessero il più velocemente possibile per costruire applicazioni in modo super iterativo e sperimentale.
Ciò significava che tutti i dati generati da queste applicazioni non erano più soggetti alla pianificazione della struttura e all'organizzazione da parte dell'architetto dei dati. Si prendevano tutte queste informazioni e le si gettavano in un luogo chiamato data lake. E il data lake era molto disordinato.
La responsabilità di dare un senso a tutte queste informazioni paludose è ricaduta sull'ingegnere dei dati. Quindi si vive un po' in entrambi i mondi, con un livello applicativo decentralizzato e totalmente federato e un livello di dati molto, molto centralizzato, con i team di data engineering che fanno del loro meglio per dare un senso a tutto questo.
Il contratto sui dati è un meccanismo che consente ai team di dati a valle e ai team di ingegneria dei dati di dire: "Ehi, stiamo iniziando a usare questi dati in un modo particolare".
Abbiamo delle aspettative in merito. E questo significa che gli ingegneri che creano i dati ne assumono la proprietà come un architetto di dati avrebbe fatto con l'intero sistema un anno prima. Ed è questo che permette alla governance di scalare, alla qualità di scalare.
Se non c'è questo, si crea una situazione molto caotica".
D: È una situazione del tipo "garbage in garbage out". Se si cambia qualcosa di molto piccolo nei dati, questo può avere profonde ramificazioni a valle.
Chad Sanderson: "Sì, è esattamente così. E ci sono molte aziende che hanno avuto impatti davvero spiacevoli dai loro modelli di IA solo grazie a modifiche relativamente piccole che gli sviluppatori delle applicazioni non considerano un grosso problema.
Ad esempio, supponiamo che si stia raccogliendo il compleanno di qualcuno per inviargli automaticamente un messaggio di auguri molto carino.
Le informazioni sul compleanno potrebbero essere memorizzate in tre colonne: mese di nascita, anno di nascita e data di nascita. Si prendono tutte queste informazioni e ci si possono fare delle cose fantasiose. Ma se l'ingegnere dice: "Sai cosa? Dividere queste informazioni in tre colonne diverse è stupido".
Voglio solo avere una colonna per la data. Non c'è problema. E lo faranno perché rende la loro applicazione più facile da usare.
Ma chiunque sia a valle e utilizzi quei dati si aspetta tre colonne. Quindi, se domani ne ricevono solo una e le due che stavano usando non ci sono più, tutto quello che avevano costruito andrà in fumo.
Questo è il tipo di cose che accadono continuamente nelle aziende".
D: Lei è il CEO di un'azienda chiamata Gable. Quali sono le principali sfide che le aziende si trovano ad affrontare e che lei spera di risolvere? In che modo la sua piattaforma affronta alcuni di questi problemi?
Chad Sanderson: "La sfida più grande che abbiamo sentito dalla maggior parte delle aziende che si muovono nello spazio dell'IA e del ML, almeno dal lato dei dati, è costituita da due aspetti. La prima è la proprietà. Se sono qualcuno che sta costruendo sistemi di IA, se sto costruendo i modelli, ho bisogno di qualcuno che si prenda la responsabilità dei dati che sto usando e che si assicuri che quei dati siano trattati come un'API.
Se siete un ingegnere del software e vi affidate all'applicazione di qualcun altro, lo fate attraverso un'interfaccia. Tale interfaccia è ben documentata. Ha aspettative molto chiare.
Ci sono degli SLA. Il sistema ha una certa quantità di tempo di attività che ci si aspetta che funzioni. Se ci sono bug, qualcuno li risolve.
Questo è il motivo per cui potete sentirvi a vostro agio nell'assumere una dipendenza da applicazioni che non sono solo quelle che avete costruito voi. E nei dati, questo è ciò che facciamo quando estraiamo i dati da un insieme di dati di qualcun altro, come ad esempio un database. E poi costruiamo un modello su di esso.
Stiamo assumendo una dipendenza da un'interfaccia, ma oggi non c'è molta proprietà su quell'interfaccia. Non c'è un vero SLA. Non c'è molta documentazione.
Può cambiare in qualsiasi momento. Se le API funzionassero così, l'intero ecosistema di Internet sarebbe nel caos. Non funzionerebbe nulla.
È questo il desiderio di molte aziende e di molti team che si occupano di dati, ovvero la possibilità di fidarsi del fatto che i dati che stanno utilizzando saranno domani gli stessi di ieri. Questo è un aspetto. E poi uno dei risultati essenziali è la qualità dei dati.
Ci interessa assicurarci che i dati corrispondano alle nostre aspettative. Supponiamo che io stia lavorando con alcuni dati di spedizione e che stia utilizzando alcune informazioni sulle distanze di spedizione delle merci. Mi aspetterei sempre che la caratteristica della distanza di spedizione significhi ciò che mi aspetto e non che improvvisamente significhi qualcosa di diverso, giusto?
Se dico che la distanza di spedizione è in miglia, domani non voglio che improvvisamente significhi chilometri, perché l'intelligenza artificiale non saprà che è cambiata da miglia a chilometri. Non ha il contesto per capirlo.
L'obiettivo di Gable è assicurarsi che ci siano aspettative e SLA molto chiari, che tutti i dati che i team utilizzano per l'IA siano chiaramente di proprietà e che l'intera organizzazione capisca come le diverse persone all'interno dell'azienda stiano utilizzando i dati e dove sia effettivamente necessario l'amore e la cura tenera".
D: L'enfasi è posta sul garantire la qualità dei dati per abilitare l'IA, ma l'IA vi permette di farlo meglio?
Chad Sanderson: "L'intelligenza artificiale è fantastica, francamente. Penso che siamo nel bel mezzo di un ciclo di hype, sicuramente, 100%.
Quindi le persone faranno affermazioni stravaganti su ciò che l'IA può fare. Ma credo che se si è realisti e ci si concentra solo su ciò che l'IA può fare in questo momento, c'è già molto valore aggiunto per la nostra azienda in particolare. Il principale valore aggiunto di Gable, la cosa che facciamo in modo diverso da tutti gli altri, è l'interpretazione del codice.
Gable non è uno strumento per i dati. Siamo uno strumento di ingegneria del software costruito per le complessità dei dati. Siamo in grado di interpretare il codice che produce dati per capire cosa sta facendo il codice.
Quindi, se ho, diciamo, un evento che viene emesso da un sistema front-end e ogni volta che qualcuno fa clic su un pulsante, c'è del codice che dice: "Ehi, questo pulsante è stato cliccato". Voglio inviare un evento chiamato pulsante cliccato a un database. E poi da quel database lo invieremo al nostro data lake.
E poi, dal nostro data lake, lo inviamo all'addestramento di modelli per un sistema di intelligenza artificiale. E Gable può dire che se un ingegnere del software decide di cambiare la struttura dell'evento del pulsante cliccato nel codice, che avrebbe un impatto su tutti quelli a valle, possiamo riconoscere che ciò è avvenuto durante il processo DevOps.
Così, quando un ingegnere del software sta esaminando GitHub e apportando modifiche al suo codice, è possibile dire: "Oh, aspettate un attimo, prima di apportare questa modifica, abbiamo rilevato che qualcosa è andato storto qui".
Gran parte dell'interpretazione del codice è stata realizzata utilizzando metodi basati sull'apprendimento automatico e sull'analisi statica.
Ma l'intelligenza artificiale, che è molto abile nel riconoscere le convenzioni, come gli schemi di codifica comuni, fa un ottimo lavoro nel fornire il contesto per cui le persone apportano modifiche al codice o qual è il loro intento. Ci sono quindi molti modi interessanti per applicare l'intelligenza artificiale al nostro prodotto in particolare".
D: Se le aziende vogliono sfruttare l'IA avranno bisogno di dati. Quali sono, secondo lei, le maggiori opportunità per le aziende di gestire e sviluppare i propri dati? Come possono capitalizzare e prepararsi a questo?
Chad Sanderson: "Penso che ogni azienda che voglia sfruttare l'IA debba elaborare una strategia sui dati. E penso che ci saranno due strategie di dati che saranno iper-rilevanti per ogni azienda.
Il primo è che in questo momento i grandi modelli iterativi, i LLM, i LLM di pubblico dominio che tutti conosciamo, come ad esempio OpenAI, Nuvola, Gemini, AnthropicTutti utilizzano principalmente dati disponibili al pubblico, dati che si possono ottenere da Internet.
E questo ha sicuramente un'utilità per un modello ampio e generale. Ma una delle sfide di questi LLM è la cosiddetta finestra di contesto: più informazioni hanno a disposizione per ragionare, peggiore è il loro lavoro. Quindi, più si riesce a fornire loro un compito ristretto con una quantità limitata di contesto, più sono efficaci.
È un po' come una persona, no? Se vi fornisco le informazioni di un libro e poi vi chiedo di un paragrafo specifico a pagina 73, la vostra capacità di ricordarlo sarà probabilmente bassa. Ma se vi do solo un capitolo da leggere, probabilmente farete un lavoro molto migliore.
Quindi, questo è un punto che mi fa pensare che molti di questi modelli generali non saranno utili per le grandi aziende. Inizieremo a vedere modelli sempre più piccoli, più orientati al contesto. Quindi si basano su contesti più piccoli.
E il modo in cui si ottiene un contesto di alta qualità e finemente sintonizzato è quello di ottenere dati eccellenti e altamente sintonizzati su quella specifica cosa che si sta guardando. E credo che questo diventerà il fossato competitivo per la maggior parte delle aziende.
Penso quindi che questo sarà un investimento enorme che molte aziende dovranno fare. Dobbiamo raccogliere il maggior numero possibile di dati di alta qualità per poterli inserire in questi modelli e non utilizzare modelli più ampi con finestre di contesto più ampie".
D: In che modo cose come il GDPR e il CCPA in California influenzeranno il modo in cui le persone o le aziende gestiscono la qualità e la sicurezza dei dati?
Chad Sanderson: "Penso che il GDPR e il CCPA siano ottimi esempi del motivo per cui molte aziende sono preoccupate di come sarà la regolamentazione di questi modelli generativi in futuro.
Anche se gli Stati Uniti dicono: "Ehi, questo va bene", se l'UE decide che non va bene, alla fine bisogna applicare questi standard a tutti, giusto? Il problema principale del GDPR è che non è possibile sapere se un cliente che accede al vostro sito web proviene dall'Europa o dagli Stati Uniti.
E certamente si può fare la geolocalizzazione e cose del genere. Ma potreste avere un europeo negli Stati Uniti che utilizza la vostra applicazione e il GDPR non fa discriminazioni tra questa persona e una che vive in Europa. Dovete essere in grado di trattarli allo stesso modo.
Ciò significa che è necessario trattare tutti i clienti allo stesso modo, perché non si sa chi sia la persona dall'altra parte. E questo richiede un sacco di governance, un sacco di innovazione tecnologica molto interessante, un sacco di cambiamenti nel modo di gestire il marketing e cose del genere. E credo che probabilmente assisteremo a qualcosa di simile con l'IA, quando la regolamentazione comincerà a essere davvero efficace.
L'Europa sta già iniziando a fare pressioni in tal senso. Ed è per questo che per molte aziende è più sicuro fare le proprie cose, giusto? Ho il mio giardino recintato.
Sto usando solo i dati raccolti dalle nostre applicazioni. E questi dati non se ne vanno. Non stiamo seguendo i clienti in giro per Internet.
Stiamo solo osservando i modelli di utilizzo dei nostri servizi. Credo che questo aspetto diventerà molto importante. L'altra cosa che penso diventerà importante sono i fornitori di dati.
I venditori di dati esistono da molto tempo, o i dati come servizio, in cui si dice: "Senti, io ti fornirò informazioni aggiornate sul tempo, e tu mi pagherai per avere accesso a quelle informazioni". E io sono quello che ha già affrontato gli ostacoli per renderle sicure, accessibili e affidabili. E mi assicuro che la qualità dei dati sia elevata.
Questo sta già accadendo. Ma credo che nei prossimi cinque-dieci anni questo fenomeno esploderà se avrete bisogno di dati che non potete raccogliere dalle vostre applicazioni interne. E credo che in questo mondo il concetto di contratti diventerà ancora più importante.
E questo sarà legato a un contratto letterale. Se pago perché i dati abbiano un certo aspetto, allora ho determinate aspettative.
Non mi aspetto che quei dati cambino improvvisamente dall'ultima volta che me li avete dati a oggi, perché ora possono davvero avere un impatto sul mio modello di apprendimento automatico, che ha un impatto sui miei profitti.
Interagiamo quotidianamente con gli strumenti di IA, ma non pensiamo quasi mai ai dati su cui si basano questi modelli. La cura e la gestione dei dati saranno fondamentali, soprattutto per le aziende che impiegano l'IA internamente".
La cura, la gestione della qualità e il controllo dei dati diventeranno sempre più cruciali man mano che le aziende costruiranno prodotti che dipendono da dati costantemente validi.
Se volete saperne di più sui contratti per i dati e su come sfruttare al meglio i dati della vostra azienda, potete contattare Chad Sanderson o per saperne di più Gable.ai.
