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

Hai lavorato nel campo della ricerca sull’apprendimento automatico, sull’intelligenza artificiale di produzione presso Facebook e su sistemi di raccomandazione su larga scala prima di fondare TrueFoundry — quali esperienze ti hanno spinto direttamente a costruire un’azienda di infrastrutture di intelligenza artificiale aziendale, e quale dolore non stava venendo 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 risultava in uno stack verticale con il software alla base, l’apprendimento automatico al centro e l’intelligenza artificiale generativa in alto. In questo setup, se sono uno sviluppatore di apprendimento automatico, i modelli che costruisco seguono lo stesso pattern di distribuzione del resto del software, il che rende molto più semplice la scalabilità dei sistemi.

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 hai questi stack paralleli, la scalabilità diventa più complessa a causa degli passaggi necessari 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 un punto di vista unico che potevamo portare stack verticali simili alle aziende e adattarli alle loro esigenze specifiche. Avevamo anche un’ipotesi alla 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 verticalmente integrato per distribuire e scalare questi sistemi in modo efficace. Questo è ciò che alla fine ci ha portato a fondare TrueFoundry, e la nostra ipotesi era giusta. L’adozione di intelligenza artificiale è accelerata dopo il lancio di ChatGPT alla fine del 2022.

Man mano che i sistemi di intelligenza artificiale si spostano dall’esperimento 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 molto più alto di ambiguità e non determinismo perché i LLM sono stocastici per natura. I sistemi agente 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 scorretto nel tempo. In molti casi, queste degradazioni possono essere più difficili da rilevare e talvolta anche più dannose di un’interruzione completa.

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

TrueFailover è stato lanciato tra un’ondata di interruzioni di servizi cloud e di intelligenza artificiale di alto profilo. 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 relative a prescrizioni è 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. In quanto cliente早 di TrueFailover, siamo stati in grado di aiutare con un 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à, paratie e commutazione di modelli intelligente tra i fornitori.

Molti guasti di intelligenza artificiale sono ancora presentati come intoppi tecnici. Dove vedi i veri costi economici e umani iniziare a emergere quando i sistemi di intelligenza artificiale si bloccano?

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 al cliente. Questo passaggio dall’esperimento ai casi d’uso di produzione ad alto rischio è il motivo per cui stiamo vedendo una maggiore richiesta di attenzione e supervisione da parte dei dirigenti.

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

In ambienti mission-critici come farmacie, operazioni sanitarie o supporto clienti, quanto velocemente il tempo di inattività dell’intelligenza artificiale può 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 un’interruzione breve 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 all’esperienza del cliente e ai risultati del servizio. Se un paziente non è in grado di soddisfare 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.

Hai detto che molti team progettano per la capacità piuttosto che per la continuità. Perché pensi che la resilienza 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 l’invio di nuove funzionalità piuttosto che assicurarsi che nulla si rompa. Di conseguenza, le organizzazioni investono spesso in modo sproporzionato 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?

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

Poiché i LLM sono risorse condivise, la latenza può aumentare perché un altro consumatore di questi LLM esegue un’azione specifica. Ci sono molti di questi punti di fallimento che vengono introdotti a causa della natura fondamentale dei LLM e le aziende in questo nuovo mondo semplicemente non hanno il pieno controllo. Senza il pieno controllo, 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 rivedere le organizzazioni l’architettura di intelligenza artificiale per supporre il fallimento piuttosto che trattare le interruzioni come rari casi limite?

Le organizzazioni dovrebbero tornare ai principi fondamentali della progettazione di sistemi distribuiti. I sistemi software sono stati costruiti sull’assunzione che i componenti di rete e le macchine si sarebbero guastati e che un’intera regione potrebbe andare giù.

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

Ti aspetti 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 di 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 propri grafici e metriche su tempo di attività e resilienza complessiva, non sarà nemmeno preso in considerazione. 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 “pronto per la produzione” per l’intelligenza artificiale 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à, le paratie, l’applicazione delle politiche e il routing intelligente tra modelli e fornitori. È qui che un gateway di intelligenza artificiale diventa fondamentale, agendo come un piano di controllo centralizzato che applica paratie, 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, qualità del modello degradata, limiti di velocità o input inaspettati da attori malintenzionati. I meccanismi di failover 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.