Nikunj Bajaj, cofondator și CEO al TrueFoundry – Seria de interviuri

Înainte de a fonda TrueFoundry, ați lucrat în cercetarea învățării automate, cu AI în producție la Facebook (META ) și cu sisteme de recomandare la scară largă. Ce experiențe v-au îndreptat cel mai direct spre construirea unei companii de infrastructură AI pentru întreprinderi și ce problemă considerați că nu era abordată atunci?

La Meta, priveam învățarea automată ca pe un caz particular al software-ului și AI generativă ca pe un caz particular al învățării automate. Rezultatul era o stivă verticală cu software-ul la bază, învățarea automată la mijloc și AI generativă în partea de sus. În această structură, modelele pe care le construiesc ca dezvoltator de învățare automată urmează același tipar de implementare ca restul software-ului, ceea ce face extinderea sistemelor foarte simplă.

Majoritatea companiilor implementau însă stive paralele, adică stive separate pentru software, învățare automată și AI generativă. Când apar aceste stive paralele, extinderea devine mai complicată din cauza transferurilor necesare între lumea învățării automate și cea a software-ului.

Echipa noastră a lucrat întotdeauna la intersecția dintre construirea modelelor de învățare automată și infrastructura de învățare automată. Aveam astfel o perspectivă unică: puteam aduce companiilor stive verticale similare și le puteam adapta cerințelor lor specifice. Spre sfârșitul lui 2021 aveam și ipoteza că învățarea automată se apropia de un punct de cotitură. Când acesta avea să apară, mai multe companii urmau să aibă nevoie de o stivă integrată vertical pentru implementarea și extinderea eficientă a acestor sisteme. Asta ne-a determinat în cele din urmă să fondăm TrueFoundry, iar ipoteza s-a dovedit corectă. Adoptarea AI s-a accelerat după lansarea ChatGPT la sfârșitul lui 2022.

Pe măsură ce sistemele AI trec de la experimente la activitatea zilnică, ce s-a schimbat în felul în care organizațiile ar trebui să privească fiabilitatea și defecțiunile?

Miza AI generative este considerabil mai mare decât cea a sistemelor tradiționale de învățare automată. Când sistemele intră în producție, organizațiile se confruntă cu mult mai multă ambiguitate și nedeterminism, deoarece modelele lingvistice mari sunt, prin natura lor, stocastice. Sistemele bazate pe agenți construite deasupra lor adaugă și mai multă ambiguitate.

În plus, defecțiunile nu mai sunt binare. Sistemele nu doar funcționează sau se opresc: multe probleme apar ca defecțiuni parțiale sau degradări silențioase. În timp, sistemele pot răspunde mai lent, pot produce rezultate de calitate mai slabă sau se pot comporta incorect. Adesea, aceste degradări sunt mai greu de detectat și uneori chiar mai dăunătoare decât o întrerupere completă.

Organizațiile trebuie să privească fiabilitatea nu doar prin prisma disponibilității, ci și a degradării performanței în timp.

TrueFailover a fost lansat în timpul unui val de întreruperi foarte mediatizate ale serviciilor cloud și AI. Ce evenimente recente au arătat clar că fiabilitatea AI trecuse de la un avantaj opțional la o cerință arhitecturală esențială?

Unul dintre clienții noștri din sănătate procesează în timp real solicitări ale pacienților legate de rețete, pentru care timpul este critic. A fost afectat de o întrerupere provocată de o defecțiune a modelului. Fluxurile sale de lucru generează venituri de mii de dolari pe secundă, iar întreruperea a perturbat câteva dintre aceste fluxuri critice. Acesta era unul dintre primii clienți TrueFailover, așa că l-am putut ajuta să își reia rapid activitatea, iar impactul a fost limitat.

Asemenea incidente ridică o întrebare importantă: pe măsură ce miza sistemelor AI generative crește, de ce procesele de restabilire sunt încă în mare parte manuale? Incidentul a întărit ideea că sistemele trebuie construite presupunând că vor apărea defecțiuni și proiectate să se corecteze automat. Fiabilitatea trebuie integrată în însăși stiva AI, prin componente AI Gateway care oferă rutare centralizată, observabilitate, mecanisme de protecție și comutare inteligentă între modelele diferiților furnizori.

Multe întreruperi AI sunt încă descrise drept mici probleme tehnice. Unde vedeți că încep să apară adevăratele costuri economice și umane când sistemele AI nu mai funcționează?

AI în companii a evoluat până la punctul în care aceste probleme nu mai afectează doar fluxurile de lucru interne. În prezent, întreruperile și degradările influențează direct și imediat percepția publicului și profiturile, deoarece utilizările în producție sunt acum orientate către clienți. Trecerea de la testarea internă la aplicații publice cu miză mare explică nevoia crescută de atenție și supraveghere din partea conducerii.

Pe măsură ce sistemele AI se integrează mai profund în fluxurile operaționale, întreruperile nu mai sunt doar probleme tehnice. Au tot mai des consecințe directe asupra afacerii, clienților și reputației.

În medii esențiale pentru activitate, cum sunt farmaciile, serviciile medicale sau asistența pentru clienți, cât de repede poate deveni indisponibilitatea AI un risc operațional sau reputațional?

În mediile critice, escaladarea se produce aproape imediat, deoarece sistemele susțin fluxuri de lucru în timp real, în care momentul intervenției contează. Chiar și o scurtă întrerupere poate opri procese esențiale, întârzia furnizarea serviciilor sau perturba sistemele ulterioare care depind de acele rezultate, producând efecte operaționale în cascadă în întreaga organizație.

În sectoare precum sănătatea, impactul depășește perturbarea operațională și afectează experiența clienților și rezultatele serviciilor. Dacă un pacient nu își poate obține la timp medicamentele prescrise, pot exista consecințe reale. Nu este doar o problemă pentru pacient, ci poate afecta și reputația farmaciei sau a furnizorului de servicii medicale. În medii critice în care încrederea contează, funcționarea continuă a sistemelor este esențială. De aceea, organizațiile înțeleg tot mai bine că sistemele AI trebuie proiectate presupunând că vor apărea defecțiuni și că mecanismele de restabilire trebuie să se activeze automat pentru a minimiza riscurile.

Ați spus că multe echipe proiectează arhitectura pentru capabilități, nu pentru continuitate. De ce credeți că reziliența a primit în trecut o prioritate mai mică în proiectarea sistemelor AI?

Explicația ține în mare parte de stimulentele din organizații. Noile capabilități sunt vizibile și atrăgătoare. Permit demonstrații, funcții și posibilități de produs pe care conducerea le vede imediat.

Continuitatea este, prin definiție, invizibilă când totul merge bine. Prin urmare, sistemele de recompensare tind să favorizeze lansarea unor funcții noi în locul efortului de a preveni orice defecțiune. Organizațiile investesc astfel adesea disproporționat în dezvoltarea capabilităților față de ingineria rezilienței.

Pe măsură ce companiile se bazează tot mai mult pe modele și API-uri externe, ce vulnerabilități noi apar în stiva AI pe care conducerea poate că încă nu le înțelege pe deplin?

Modelele lingvistice mari sunt în esență resurse partajate, iar companiile nu le dețin așa cum dețin infrastructura tradițională. În plus, sisteme esențiale pentru afaceri rulează pe sisteme externe care nu au fost încă suficient verificate în timp. Modelele lingvistice mari evoluează ele însele rapid. Asta înseamnă că furnizorul unui model nu poate fi tras la răspundere pentru aspecte precum latența sau o ușoară scădere a performanței modelului, deoarece furnizorii își actualizează cercetarea foarte repede.

Fiindcă modelele lingvistice mari sunt resurse partajate, latența poate crește brusc când alt utilizator face o anumită acțiune. Natura fundamentală a acestor modele introduce numeroase puncte de defecțiune, iar companiile pur și simplu nu au control deplin în această lume nouă. Fără control deplin, cea mai bună soluție este să introducă suficientă redundanță pentru a construi un sistem rezilient.

Fără a vă concentra pe produse specifice, cum ar trebui organizațiile să regândească arhitectura AI pornind de la premisa că defecțiunile vor apărea, în loc să trateze întreruperile drept cazuri excepționale rare?

Organizațiile ar trebui să revină la principiile fundamentale ale proiectării sistemelor distribuite. Sistemele software au fost construite presupunând că echipamentele și componentele de rețea vor ceda și că o întreagă regiune poate deveni indisponibilă.

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

Vă așteptați ca reziliența AI să devină decisivă în alegerea platformelor și furnizorilor, la fel cum disponibilitatea și redundanța au influențat deciziile privind infrastructura cloud?

Pe măsură ce mai multe sisteme AI intră în producție, reziliența va deveni o condiție de bază. Dacă un furnizor nu poate prezenta grafice și indicatori privind disponibilitatea și reziliența generală, nici nu va fi luat în considerare. Când reziliența devine o așteptare minimă pentru toți furnizorii, factorii decisivi se mută spre experiența utilizatorului, optimizarea performanței, observabilitate și funcționalități de produs mai avansate. În timp, componente precum un AI Gateway și comutarea automată pe sisteme de rezervă vor deveni elemente fundamentale ale infrastructurii AI din companii.

Privind înainte, ce înseamnă cu adevărat AI pregătită pentru producție într-o lume în care trebuie să fie permanent disponibilă, nu doar utilă din când în când?

Sistemele AI pregătite pentru producție trebuie să fie observabile, controlabile și să poată fi restabilite. Toate cele trei condiții trebuie îndeplinite.

Pentru ca AI în producție să fie observabilă, echipele au nevoie de vizibilitate detaliată asupra comportamentului modelelor, latenței, ratelor de eroare, utilizării tokenurilor, derivei și tiparelor de defecțiune. Fără observabilitate solidă, degradările devin foarte greu de detectat înainte ca utilizatorii să le observe.

Controlabilitatea include modelarea traficului, limitarea frecvenței cererilor, mecanismele de protecție, aplicarea politicilor și rutarea inteligentă între modele și furnizori. Aici un AI Gateway devine fundamental, acționând ca un plan de control centralizat care impune mecanisme de protecție, asigură guvernanță consecventă și permite schimbarea dinamică a modelului atunci când performanța sau fiabilitatea scade.

În sfârșit, posibilitatea restabilirii cere sisteme construite presupunând că unele componente pot fi defecte parțial sau complet. Cauzele pot fi întreruperi la furnizori, scăderea calității modelelor, limite de frecvență a cererilor sau intrări neașteptate de la actori rău intenționați. Comutarea automată pe sisteme de rezervă și mecanismele de autoreparare trebuie integrate nativ în arhitectură, nu lăsate în seama unor proceduri manuale activate abia după apariția problemei.

Aceasta este direcția în care lucrăm la TrueFoundry. Furnizorii care definesc astfel pregătirea pentru producție, combinând observabilitatea, controlul centralizat și restabilirea automată, vor câștiga încrederea clienților pe termen lung și vor putea continua să rezolve noile probleme pe măsură ce apar.

Vă mulțumim pentru interviul excelent. Cititorii care doresc să afle mai multe pot vizita TrueFoundry.