Nikunj Bajaj, Co-Fondator și CEO al TrueFoundry – Seria de Interviuri

Ați lucrat în domeniul cercetării învățării automate, al producției de AI la Facebook și al sistemelor de recomandare la scară largă, înainte de a fonda TrueFoundry — care au fost experiențele care v-au împins cel mai direct spre construirea unei companii de infrastructură AI de nivel întreprindere, și ce durere nu a fost abordată la momentul respectiv?

La Meta, am considerat inteligența artificială ca pe un caz special de software, și GenAI ca pe un caz special de inteligență artificială, ceea ce a rezultat într-un stivuit vertical cu software-ul la bază, inteligența artificială în mijloc și GenAI în vârf. În această configurație, dacă sunt un dezvoltator de inteligență artificială, modelele pe care le construiesc urmează același model de implementare ca și restul software-ului, ceea ce face ca scalarea sistemelor să fie foarte simplă.

Majoritatea întreprinderilor, însă, implementează stive paralele, ceea ce înseamnă că au stive separate pentru software, inteligență artificială și GenAI. În momentul în care aveți aceste stive paralele, scalarea devine mai complexă din cauza predărilor necesare între lumea inteligenței artificiale și lumea software-ului.

Echipa noastră a lucrat întotdeauna la intersecția dintre construirea de modele de inteligență artificială și infrastructura de inteligență artificială, astfel că am avut o perspectivă unică pe care am putut-o aduce în întreprinderi și am adaptat-o pentru cerințele lor specifice. Am avut și o ipoteză la sfârșitul anului 2021 că inteligența artificială se apropia de un punct de inflexiune, și când s-a întâmplat, mai multe companii au avut nevoie de o stivă integrată vertical pentru a implementa și scala aceste sisteme în mod eficient. Acesta a fost motivul care ne-a condus la fondarea TrueFoundry, și ipoteza noastră a fost corectă. Adoptarea inteligenței artificiale a accelerat după lansarea ChatGPT la sfârșitul anului 2022.

Cum se schimbă modul în care organizațiile ar trebui să gândească despre fiabilitate și eșec, pe măsură ce sistemele de inteligență artificială trec de la experimentare la operațiuni de zi cu zi?

Mizele pentru sistemele Gen AI sunt semnificativ mai mari comparativ cu sistemele tradiționale de inteligență artificială. Pe măsură ce aceste sisteme trec în producție, organizațiile se confruntă cu un nivel mult mai mare de ambiguitate și non-determinism, deoarece LLM-urile sunt stohastice din natură. Sistemele agenților construite pe baza acestora adaugă și mai multă ambiguitate.

În plus, eșecurile nu mai sunt binare. În loc ca sistemele să fie pur și simplu defecte sau nu, multe probleme apar sub forma unor eșecuri parțiale sau degradări silențioase. Sistemele pot răspunde cu latență mai mare, calitate degradată sau comportament incorect în timp. În multe cazuri, aceste degradări pot fi mai greu de detectat și, uneori, chiar mai dăunătoare decât o închidere dură.

Organizațiile trebuie să gândească despre fiabilitate nu doar în termeni de timp de funcționare, ci și despre degradarea performanței în timp.

TrueFailover a fost lansat în mijlocul unei valuri de întreruperi ale serviciilor cloud și AI de mare vizibilitate. Care au fost evenimentele recente care au făcut clar că fiabilitatea AI a trecut de la a fi “de dorit” la a fi o cerință arhitecturală de bază?

Unul dintre clienții noștri din domeniul sănătății, care procesează cereri în timp real și sensibile pentru prescripții medicale, a fost afectat de o întrerupere cauzată de o defecțiune a modelului. Fluxurile lor de lucru generează mii de dolari pe secundă, iar întreruperea a perturbat unele dintre aceste fluxuri critice. Ca client timpuriu al TrueFailover, am putut să-i ajutăm la recuperarea rapidă, iar impactul a fost limitat.

Incidente de acest fel ridică o întrebare importantă. Pe măsură ce mizele sistemelor Gen AI continuă să crească, de ce procesele de recuperare sunt încă în mare măsură manuale? Acest lucru a întărit ideea că sistemele ar trebui să fie construite cu presupunerea că defecțiunile vor apărea și ar trebui să fie proiectate pentru a se corecta automat. Fiabilitatea trebuie să fie integrată în stiva AI însăși prin utilizarea unor porți AI, care pot oferi rutare centralizată, observabilitate, garduri de protecție și comutare inteligentă a modelului între furnizori.

Multe întreruperi ale sistemelor AI sunt încă prezentate ca “hicuri” tehnice. Unde vedeți apărând adevăratele costuri economice și umane atunci când sistemele AI sunt închise?

Inteligența artificială la nivel de întreprindere a evoluat până la punctul în care aceste “hicuri” nu mai afectează doar fluxurile de lucru interne. Astăzi, întreruperile și degradările afectează direct și imediat percepția publică și profiturile, deoarece cazurile de utilizare în producție sunt acum orientate către clienți. Această schimbare de la testarea internă la aplicații cu risc ridicat și orientate către clienți este motivul pentru care vedem o creștere a cererii pentru atenția și supravegherea executivă.

Pe măsură ce sistemele AI devin încorporate mai adânc în fluxurile de lucru operaționale, întreruperile nu mai sunt doar probleme tehnice. Ele au consecințe directe asupra afacerilor, clienților și reputației.

În medii critice pentru misiune, cum ar fi farmacii, operațiuni de sănătate sau suport clienți, cât de repede poate escalada timpul de închidere al sistemelor AI în risc operațional sau de reputație?

În medii critice pentru misiune, escaladarea se întâmplă aproape imediat, deoarece aceste sisteme susțin fluxuri de lucru în timp real și sensibile. Chiar și o scurtă întrerupere poate opri procese critice, întârzia livrarea serviciilor sau întrerupe sistemele downstream care depind de acele ieșiri, creând efecte operaționale în cascadă în întreaga organizație.

În sectoare precum sănătatea, impactul se extinde dincolo de perturbarea operațională la experiența și rezultatele clienților. Dacă un pacient nu poate îndeplini prescripția la timp, pot apărea consecințe reale. Nu doar că este o problemă pentru pacient, dar poate și deteriora reputația unei farmacii sau a unui furnizor de sănătate. În medii critice pentru misiune, unde încrederea este un factor, este esențial ca sistemele să rămână online. De aceea, organizațiile recunosc din ce în ce mai mult că sistemele AI trebuie să fie proiectate cu presupunerea că defecțiunile vor apărea și că mecanismele de recuperare trebuie să se activeze automat pentru a minimiza riscul.

Ați spus că multe echipe proiectează pentru capacitate în loc de continuitate. De ce credeți că reziliența a fost istoric deprioritizată în proiectarea sistemelor AI?

Acest lucru se datorează în mare măsură stimulentelor din cadrul organizațiilor. Noile capacități sunt vizibile și interesante. Ele deblochează demo-uri, funcții și posibilități de produs pe care conducerea le poate vedea imediat.

Continuitatea, prin definiție, este invizibilă atunci când totul funcționează bine. Din cauza acestui fapt, sistemele de recompensare tind să fie distorsionate în favoarea dezvoltării de noi funcții, mai degrabă decât a asigurării continuității. Ca urmare, organizațiile investesc în mod disproporționat în dezvoltarea de capacități, mai degrabă decât în ingineria rezilienței.

Pe măsură ce întreprinderile se bazează din ce în ce mai mult pe modele și API-uri externe, care sunt noile fragilități introduse în stiva AI pe care liderii nu le pot aprecia pe deplin încă?

LLM-urile sunt, în esență, resurse partajate, și întreprinderile nu le dețin în mod direct, așa cum o fac cu infrastructura tradițională. În plus, sistemele de afaceri critice din cadrul întreprinderilor rulează pe sisteme externe care nu sunt pe deplin testate în timp. LLM-urile însele evoluează rapid, ceea ce înseamnă că un furnizor de modele nu poate fi ținut responsabil pentru lucruri precum latența sau performanța modelului care scade puțin, deoarece aceștia iteratează rapid asupra cercetărilor lor.

Deoarece LLM-urile sunt resurse partajate, latența poate crește brusc din cauza unei acțiuni specifice a altui consumator al acestor LLM-uri. Există multe puncte de defecțiune care sunt introduse din cauza naturii fundamentale a LLM-urilor, și întreprinderile în această lume nouă nu au control deplin. Fără control deplin, cel mai bun lucru pe care o întreprindere îl poate face este să creeze suficiente redundanțe ale sistemului pentru a proiecta un sistem rezilient.

Fără a se concentra pe produse specifice, cum ar trebui organizațiile să reconsidere arhitectura AI pentru a presupune defecțiune, mai degrabă decât a trata întreruperile ca cazuri rare de margine?

Organizațiile ar trebui să revină la principiile de bază ale proiectării sistemelor distribuite. Sistemele software au fost construite pe presupunerea că componentele rețelei și mașinile vor eșua, și că o întreagă regiune poate fi închisă.

Sistemele AI nu ar trebui să fie diferite. Trebuie să presupunem că furnizorii de modele vor experimenta probleme de latență, degradări sau întreruperi, și să incorporăm redundanță astfel încât aplicațiile să rămână reziliente în diferite scenarii de defecțiune.

Credeți că reziliența AI va deveni un factor decisiv în selectarea platformelor și furnizorilor, asemănător modului în care timpul de funcționare și redundanța au modelat deciziile privind infrastructura cloud?

Pe măsură ce mai multe sisteme AI trec în producție, reziliența va deveni o condiție de bază. Dacă un furnizor nu poate prezenta grafice și metrici privind timpul de funcționare și reziliența generală, nu va fi luat în considerare. Odată ce reziliența devine o așteptare de bază pentru toți furnizorii, factorii decizionali se vor muta spre experiența utilizatorului, optimizarea performanței, observabilitate și capacități de produs de nivel superior. În timp, componente precum o poartă AI și capacități de failover automate vor deveni elemente fundamentale ale infrastructurii AI de nivel întreprindere.

Privind înainte, ce înseamnă cu adevărat “gata pentru producție” în lumea în care se așteaptă ca AI-ul să fie disponibil în mod continuu, nu doar ocazional util?

Sistemele AI gata pentru producție ar trebui să fie observabile, controlabile și recuperabile. Toate aceste cerințe trebuie îndeplinite.

Pentru ca AI-ul în producție să fie observabil, echipele au nevoie de o vizibilitate profundă asupra comportamentului modelului, latenței, ratelor de eroare, utilizării token-urilor, degradării și modelelor de defecțiune. Fără o observabilitate puternică, devine foarte dificil să detectați degradările înainte ca utilizatorii să înceapă să le observe.

Pentru ca sistemele să fie controlabile, acest lucru include modelarea traficului, limitarea ratelor, gardurile de protecție, aplicarea politicilor și rutarea inteligentă între modele și furnizori. Acesta este locul în care o poartă AI devine fundamentală, acționând ca un plan de control centralizat care impune garduri de protecție, oferă guvernanță consistentă și permite comutarea dinamică a modelului atunci când performanța sau fiabilitatea scade.

Și, în cele din urmă, atunci când vine vorba de a fi recuperabil, sistemele ar trebui să fie construite cu presupunerea că componentele pot fi parțial sau complet defecte, fie din cauza întreruperilor furnizorilor, a calității degradate a modelului, a limitărilor de rată sau a intrărilor neașteptate de la actori malici. Mecanismele de failover și auto-vindecare ar trebui să fie native arhitecturii, nu cărți de joc manuale activate după ce ceva merge prost.

Aceasta este direcția în care lucrăm la TrueFoundry. Furnizorii care definesc “gata pentru producție” în acest mod, combinând observabilitatea, controlul centralizat și recuperarea automată, vor câștiga încrederea pe termen lung a clienților și vor putea continua să rezolve noi probleme pe măsură ce apar.

Mulțumim pentru acest interviu minunat; cititorii care doresc să afle mai multe pot vizita TrueFoundry.