Nikunj Bajaj, Co-Fondatore e Amministratore Delegato di TrueFoundry – Serie di Interviste

Ha lavorato nel campo della ricerca sull’apprendimento automatico, dell’intelligenza artificiale di produzione presso Facebook (META ) e di sistemi di raccomandazione su larga scala prima di fondare TrueFoundry — quali esperienze lo hanno spinto direttamente a costruire un’azienda di infrastrutture di intelligenza artificiale aziendale, e quale dolore non stava essere affrontato al momento?

In Meta, consideravamo l’apprendimento automatico come un caso speciale di software, e l’intelligenza artificiale generativa come un caso speciale di apprendimento automatico, il che ha portato a uno stack verticale con il software alla base, l’apprendimento automatico al centro e l’intelligenza artificiale generativa in cima. In questo setup, se sono uno sviluppatore di apprendimento automatico, i modelli che costruisco seguono lo stesso modello di distribuzione del resto del software, il che rende la scalabilità dei sistemi molto più semplice.

Tuttavia, la maggior parte delle aziende stava distribuendo stack paralleli, il che significa che avevano stack separati per software, apprendimento automatico e intelligenza artificiale generativa. Nel momento in cui si hanno questi stack paralleli, la scalabilità diventa più complessa a causa delle consegne richieste tra l’apprendimento automatico e il mondo del software.

Il nostro team ha sempre lavorato all’intersezione tra la costruzione di modelli di apprendimento automatico e l’infrastruttura di apprendimento automatico, quindi avevamo una prospettiva unica che potevamo portare a stack verticali simili alle aziende e adattarli alle loro esigenze specifiche. Avevamo anche un’ipotesi verso la fine del 2021 che l’apprendimento automatico stava raggiungendo un punto di svolta, e quando lo fece, più aziende avrebbero avuto bisogno di uno stack integrato verticalmente per distribuire e scalare questi sistemi in modo efficace. Questo è ciò che ci ha portato a fondare TrueFoundry, e la nostra ipotesi era giusta. L’adozione dell’intelligenza artificiale è accelerata dopo il lancio di ChatGPT alla fine del 2022.

Man mano che i sistemi di intelligenza artificiale si spostano dall’esperimentazione alle operazioni quotidiane, cosa è cambiato nel modo in cui le organizzazioni dovrebbero pensare all’affidabilità e al fallimento?

Le poste in gioco con l’intelligenza artificiale generativa sono significativamente più elevate rispetto ai sistemi di apprendimento automatico tradizionali. Man mano che questi sistemi si spostano in produzione, le organizzazioni si trovano ad affrontare un livello di ambiguità e non determinismo molto più alto perché gli LLM sono stocastici per natura. I sistemi agenti costruiti su di essi aggiungono ulteriore ambiguità.

Inoltre, i fallimenti non sono più binari. Invece di sistemi che semplicemente falliscono o non falliscono, molti problemi appaiono come fallimenti parziali o degradazioni silenziose. I sistemi potrebbero rispondere con una latenza più alta, una qualità degradata o un comportamento errato nel tempo. In molti casi, queste degradazioni possono essere più difficili da rilevare e a volte anche più dannose di un’interruzione completa.

Le organizzazioni devono pensare all’affidabilità non solo in termini di tempo di attività, ma anche di degradazione delle prestazioni nel tempo.

TrueFailover è stato lanciato durante un’ondata di interruzioni dei servizi cloud e di intelligenza artificiale. Quali eventi recenti hanno reso chiaro che l’affidabilità dell’intelligenza artificiale era passata da un “bello avere” a un requisito architettonico fondamentale?

Uno dei nostri clienti sanitari che elabora richieste di pazienti in tempo reale e sensibili al tempo è stato colpito da un’interruzione causata da un fallimento del modello. I loro flussi di lavoro generano migliaia di dollari di entrate al secondo, e l’interruzione ha interrotto alcuni di questi flussi di lavoro critici. Come cliente early adopter di TrueFailover, siamo stati in grado di aiutare con il recupero rapido, e l’impatto è stato contenuto.

Eventi come questo sollevano una domanda importante. Man mano che le poste in gioco dei sistemi di intelligenza artificiale generativa continuano a salire, perché i processi di recupero sono ancora in gran parte manuali? Ha rafforzato l’idea che i sistemi dovrebbero essere costruiti con l’assunzione che i fallimenti si verificheranno, e che dovrebbero essere progettati per correggersi automaticamente. L’affidabilità deve anche essere costruita all’interno dello stack di intelligenza artificiale stesso attraverso l’uso di gateway di intelligenza artificiale, che possono fornire routing centralizzato, osservabilità, limiti e commutazione dei modelli intelligente tra i fornitori.

Molti fallimenti di intelligenza artificiale sono ancora inquadrati come intoppi tecnici. Dove vede emergere i reali costi economici e umani quando i sistemi di intelligenza artificiale si interrompono?

L’intelligenza artificiale aziendale è evoluta al punto in cui questi intoppi non colpiscono più solo i flussi di lavoro interni. Oggi, le interruzioni e le degradazioni colpiscono direttamente la percezione pubblica e i profitti, perché i casi d’uso di produzione sono ora rivolti ai clienti. Questo passaggio dall’esperimentazione ai casi d’uso ad alto rischio è il motivo per cui stiamo vedendo un aumento della domanda di attenzione e supervisione da parte dei dirigenti.

Man mano che i sistemi di intelligenza artificiale si integrano più profondamente nei flussi di lavoro operativi, le interruzioni non sono più solo problemi tecnici. Hanno sempre più conseguenze dirette per l’attività, i clienti e la reputazione.

In ambienti mission-critici come farmacie, operazioni sanitarie o supporto clienti, quanto velocemente può l’interruzione dell’intelligenza artificiale degenerare in rischio operativo o di reputazione?

In ambienti mission-critici, l’escalation avviene quasi immediatamente perché questi sistemi supportano flussi di lavoro in tempo reale e sensibili al tempo. Anche una breve interruzione può bloccare processi critici, ritardare la consegna del servizio o interrompere sistemi a valle che dipendono da quelle uscite, creando effetti operativi a cascata in tutta l’organizzazione.

In settori come la sanità, l’impatto si estende oltre l’interruzione operativa ai risultati del servizio e dell’esperienza del cliente. Se un paziente non è in grado di ottenere la sua prescrizione in tempo, ci possono essere conseguenze reali. Non solo è un problema per il paziente, ma può anche danneggiare la reputazione di una farmacia o di un fornitore di servizi sanitari. In ambienti mission-critici in cui la fiducia è un fattore, è fondamentale che i sistemi rimangano online. È per questo che le organizzazioni stanno sempre più riconoscendo che i sistemi di intelligenza artificiale devono essere progettati con l’assunzione che i fallimenti si verificheranno e che i meccanismi di recupero devono attivarsi automaticamente per minimizzare il rischio.

Ha detto che molti team progettano per la capacità piuttosto che per la continuità. Perché pensa che l’affidabilità sia stata storicamente depotenziata nella progettazione dei sistemi di intelligenza artificiale?

Ciò deriva in gran parte dagli incentivi all’interno delle organizzazioni. Le nuove capacità sono visibili e emozionanti. Sbloccano demo, funzionalità e possibilità di prodotto che la dirigenza può vedere immediatamente.

La continuità, per definizione, è invisibile quando le cose funzionano bene. A causa di ciò, i sistemi di ricompensa tendono a essere distorti verso lo sviluppo di nuove funzionalità piuttosto che garantire che nulla si rompa. Di conseguenza, le organizzazioni investono sproporzionatamente nello sviluppo di capacità piuttosto che nell’ingegneria della resilienza.

Man mano che le aziende si affidano sempre più a modelli e API esterni, quali nuove fragilità vengono introdotte nello stack di intelligenza artificiale che i leader potrebbero non apprezzare ancora pienamente?

Gli LLM sono fondamentalmente risorse condivise, e le aziende non li possiedono come possiedono le infrastrutture tradizionali. Inoltre, sistemi aziendali critici sono in esecuzione su sistemi esterni che non sono stati completamente testati nel tempo. Gli LLM stessi si stanno evolvendo rapidamente, il che significa che un fornitore di modelli non può essere ritenuto responsabile di cose come la latenza o le prestazioni del modello che scendono leggermente, perché stanno iterando rapidamente sulla loro ricerca.

Poiché gli LLM sono risorse condivise, la latenza può aumentare perché un altro consumatore di queste risorse esegue un’azione specifica. Ci sono molti di questi punti di fallimento che vengono introdotti a causa della natura fondamentale degli LLM, e le aziende in questo nuovo mondo semplicemente non hanno il controllo totale. Senza il controllo totale, la migliore cosa che un’azienda può fare è creare sufficienti ridondanze di sistema per progettare un sistema resiliente.

Senza concentrarsi su prodotti specifici, come dovrebbero le organizzazioni ripensare l’architettura di intelligenza artificiale per supporre il fallimento piuttosto che trattare le interruzioni come casi limite rari?

Le organizzazioni dovrebbero tornare ai principi fondamentali della progettazione dei sistemi distribuiti. I sistemi software sono stati costruiti sull’assunzione che i componenti di rete e le macchine potessero fallire, e che un’intera regione potesse andare giù.

I sistemi di intelligenza artificiale non dovrebbero essere diversi. Dovremmo supporre che i fornitori di modelli potrebbero sperimentare problemi di latenza, degradazioni o interruzioni, e incorporare ridondanze in modo che le applicazioni rimangano resilienti in diversi scenari di fallimento.

Si aspetta che la resilienza dell’intelligenza artificiale diventi un fattore decisivo nella scelta della piattaforma e del fornitore, simile a come il tempo di attività e la ridondanza hanno plasmato le decisioni sull’infrastruttura cloud?

Man mano che più sistemi di intelligenza artificiale si spostano in produzione, la resilienza diventerà un requisito fondamentale. Se un fornitore non può mostrare i suoi grafici e le metriche su tempo di attività e resilienza complessiva, non verrà nemmeno considerato. Una volta che la resilienza diventa un’aspettativa di base tra i fornitori, i fattori decisivi si sposteranno verso l’esperienza utente, l’ottimizzazione delle prestazioni, l’osservabilità e le funzionalità di prodotto di livello superiore. Nel tempo, componenti come un gateway di intelligenza artificiale e capacità di failover automatico diventeranno elementi fondamentali dell’infrastruttura di intelligenza artificiale aziendale.

Guardando avanti, cosa significa realmente “intelligenza artificiale pronta per la produzione” in un mondo in cui l’intelligenza artificiale è attesa essere continuamente disponibile, non solo occasionalmente utile?

I sistemi di intelligenza artificiale pronti per la produzione dovrebbero essere osservabili, controllabili e recuperabili. Tutte e tre queste caselle devono essere spuntate.

Perché l’intelligenza artificiale di produzione sia osservabile, i team hanno bisogno di una visibilità approfondita sul comportamento del modello, sulla latenza, sui tassi di errore, sull’utilizzo del token, sulla deriva e sui modelli di fallimento. Senza una forte osservabilità, diventa molto difficile rilevare le degradazioni prima che gli utenti inizino a notarle.

Perché i sistemi siano controllabili, ciò include la modellazione del traffico, il limitazione della velocità, i limiti, l’applicazione delle politiche e il routing intelligente tra modelli e fornitori. Questo è il punto in cui un gateway di intelligenza artificiale diventa fondamentale, agendo come un piano di controllo centralizzato che applica limiti, fornisce una governance coerente e consente la commutazione dinamica dei modelli quando le prestazioni o l’affidabilità scendono.

E, infine, quando si tratta di essere recuperabili, i sistemi dovrebbero essere costruiti con l’assunzione che i componenti possano essere parzialmente o completamente rotti, a causa di interruzioni del fornitore, di una qualità del modello degradata, di limiti di velocità o di input inaspettati da attori malintenzionati. I meccanismi di failover automatico e di auto-guarigione dovrebbero essere nativi dell’architettura, non manuali che vengono attivati dopo che qualcosa va storto.

Questa è la direzione verso cui stiamo lavorando in TrueFoundry. I fornitori che definiscono la prontezza per la produzione in questo modo, combinando osservabilità, controllo centralizzato e recupero automatico, guadagneranno la fiducia a lungo termine dei clienti e saranno in grado di continuare a risolvere nuovi problemi man mano che emergono. Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare TrueFoundry.