Nikunj Bajaj, medgrunnlegger og CEO av TrueFoundry – Intervju-serie

Du har arbeidet med maskinlæringsforskning, produksjons-AI hos Facebook (META ) og store anbefalingsystemer før du grunnla TrueFoundry — hva erfaringer førte deg direkte til å bygge en bedrifts AI-infrastruktur-selskap, og hva smerte følte du ikke ble behandlet på den tiden?

Hos Meta, så vi på maskinlærings som en spesialtilfelle av programvare, og GenAI som en spesialtilfelle av maskinlærings, noe som resulterte i en vertikal stak med programvare nederst, maskinlærings midt i og GenAI øverst. I denne oppsettet, hvis jeg er en maskinlæringsutvikler, følger modellene jeg bygger samme deployeringsmønster som resten av programvaren, noe som gjør skalerings-systemer veldig enkelt.

De fleste bedrifter, derimot, deployerte parallell-staker, noe betød at de hadde separate staker for programvare, maskinlærings og GenAI. Øyeblikket du har disse parallell-stakene, blir skalerings kompleksitet større på grunn av hånd-oversitt mellom maskinlærings- og programvare-verden.

Vårt team har alltid arbeidet på skjæringspunktet mellom å bygge maskinlæringsmodeller og maskinlærings-infrastruktur, så vi hadde en unik synsvinkel som vi kunne bringe lignende vertikale staker til bedrifter og tilpasse dem for deres spesifikke krav. Vi hadde også en hypotese mot slutten av 2021 at maskinlærings var nær et vendepunkt, og når det gjorde, ville flere bedrifter trenge en vertikalt integrert stak for å deployere og skalerer disse systemene effektivt. Dette er hva som til slutt førte oss til å grunnlegge TrueFoundry, og vår hypotese var riktig. AI-adoptsjon akselererte etter lanseringen av ChatGPT i slutten av 2022.

Når AI-systemer flytter fra eksperimentering til hverdags-operasjoner, hva har endret seg i måten organisasjoner bør tenke om pålitelighet og feil?

Innsatsen med Gen AI er betydelig høyere sammenlignet med tradisjonelle maskinlærings-systemer. Når disse systemene flytter inn i produksjon, håndterer organisasjoner en mye høyere nivå av usikkerhet og ikke-determinisme fordi LLM-er er stokastiske av natur. Agentsystemer bygget på toppen av dem legger til ytterligere usikkerhet.

I tillegg er feil ikke lenger binære. I stedet for at systemene enten feiler eller ikke feiler, viser mange problemer seg som delvis feil eller stille degraderinger. Systemene kan svare med høyere latent, degradert kvalitet eller feil atferd over tid. I mange tilfeller kan disse degraderingene være vanskeligere å oppdage og noen ganger enda mer skadelige enn en hard nedtiden.

Organisasjoner må tenke på pålitelighet ikke bare i forhold til oppetid, men også på ytelses-degradering over tid.

TrueFailover ble lansert i en bølge av høyprofilerte sky- og AI-tjenesteforsinkelser. Hva nylige hendelser gjorde det klart at AI-pålitelighet hadde skiftet fra et “hyggelig å ha” til et kjerne-arkitektonisk krav?

En av våre helsetjenestekunder som behandler sanntids-, tidssensitive pasientforespørsler relatert til resepter ble rammet av en nedtid på grunn av en modellfeil. Deres arbeidsflyter genererer tusenvis av dollar i inntekt per sekund, og nedtiden forstyrte noen av disse kritiske arbeidsflytene. Som en tidlig TrueFailover-kunde, kunne vi hjelpe med rask gjenoppretting, og påvirkningen ble begrenset.

Hendelser som denne reiser et viktig spørsmål. Når innsatsen med Gen AI-systemer fortsetter å øke, hvorfor er gjenopprettingsprosesser fortsatt hovedsakelig manuelle? Det understreket ideen om at systemer bør bygges med antagelsen om at feil vil skje, og de bør være designet for å automatisk korrigere seg selv. Pålitelighet må også bygges inn i AI-staken selv gjennom bruk av AI-gateway, som kan gi sentralisert ruting, overvåking, beskyttelse og intelligent modell-skifting over leverandører.

Mange AI-nedtider blir fremdeles rammet som tekniske hikker. Hvor ser du de virkelige økonomiske og menneskelige kostnadene begynner å dukke opp når AI-systemer går ned?

Bedrifts-AI har utviklet seg til et punkt hvor disse hikkene ikke lenger bare påvirker interne arbeidsflyter. I dag påvirker nedtider og degraderinger offentlig oppfatning og inntekt direkte og umiddelbart, fordi produksjonsanvendelsene nå er kunde-orienterte. Dette skiftet fra intern testing til høy-innsats, offentlig-orienterte applikasjoner er hvorfor vi ser økt etterspørsel etter ledelses oppmerksomhet og tilsyn.

Når AI-systemer blir mer integrert i operasjonelle arbeidsflyter, blir nedtider ikke lenger bare tekniske problemer. De har økende bedrifts-, kunde- og omdømmeskonsekvenser.

I kritiske miljøer som apotek, helsetjenester eller kundesupport, hvor raskt kan AI-nedtid eskalere til operasjonell eller omdømmesrisiko?

I kritiske miljøer skjer eskalering nesten umiddelbart fordi disse systemene støtter sanntids-, tidssensitive arbeidsflyter. Selv en kortvarig nedtid kan stoppe kritiske prosesser, forsinke tjenesteyting eller avbryte nedstrøms-systemer som avhenger av disse utgangene, og skape en kaskade av operasjonelle effekter på hele organisasjonen.

I sektorer som helsetjenester, går påvirkningen utover operasjonell forstyrrelse til kundeopplevelse og tjenesteytelsesresultater. Hvis en pasient ikke kan fylle sin resept på tide, kan det ha virkelige konsekvenser. Ikke bare er dette et problem for pasienten, men det kan også skade et apoteks eller helsetjenesteleverandørs omdømme. I kritiske miljøer hvor tillit er en faktor, er det avgjørende at systemer forblir online. Dette er hvorfor organisasjoner stadig mer anerkjenner at AI-systemer må være designet med antagelsen om at feil vil skje og at gjenopprettingsmekanismer må aktiveres automatisk for å minimere risiko.

Du har sagt at mange team arkitekter for funksjonalitet fremfor kontinuitet. Hvorfor tror du at motstand har historisk sett blitt underprioritert i AI-systemdesign?

Dette kommer hovedsakelig ned til incitamenter innen organisasjoner. Nye funksjoner er synlige og spennende. De låser opp demoer, funksjoner og produktmuligheter som ledelsen kan umiddelbart se.

Kontinuitet, per definisjon, er usynlig når ting fungerer bra. Fordi av dette, er belønningssystemer skjeve mot å levere nye funksjoner fremfor å sikre at ingenting bryter. Som et resultat, investerer organisasjoner ofte ubalanseert i funksjonsutvikling fremfor i motstandsingeniørarbeid.

Når bedrifter stadig mer avhenger av eksterne modeller og API-er, hva nye sårbarheter introduseres i AI-staken som ledere kanskje ikke helt anerkjenner ennå?

LLM-er er fundamentalt delte ressurser, og bedrifter eier dem ikke som de gjør tradisjonell infrastruktur. I tillegg, kjører viktige forretnings-kritiske systemer med bedrifter på eksterne systemer som ikke er fullt ut tidsteste. LLM-er selv utvikler raskt, noe betyr at en modell-leverandør ikke kan holdes ansvarlig for ting som latency eller modell-ytelse som går ned, fordi de itererer på sin forskning veldig raskt.

Fordi LLM-er er delte ressurser, kan latency øke fordi en annen forbruker av disse LLM-ene tar en bestemt handling. Det er mange av disse feilpunkter som introduseres på grunn av den fundamentale naturen til LLM-er, og bedrifter i denne nye verden har ikke full kontroll. Uten full kontroll, er det beste en bedrift kan gjøre å skape nok system-redundanser for å designe et motstandsdyktig system.

Uten å fokusere på spesifikke produkter, hvordan bør organisasjoner omtenke AI-arkitektur for å anta feil fremfor å behandle nedtider som sjeldne kanttilfeller?

Organisasjoner bør returnere til de første prinsippene for distribuerte systemdesign. Programvaresystemer ble bygget på antagelsen om at nettverkskomponenter og maskiner ville feile, og at en hel region kunne gå ned.

AI-systemer bør ikke være forskjellige. Vi bør anta at modell-leverandører vil oppleve latency-problemer, degraderinger eller nedtider, og inkorporere redundans så applikasjoner forblir motstandsdyktige over forskjellige feilscenarier.

Forventer du at AI-motstand blir et avgjørende faktor i plattform- og leverandørvalg, likt hvordan oppetid og redundans formede sky-infrastruktur-beslutninger?

Når flere AI-systemer flytter inn i produksjon, vil motstand bli en selvfølge. Hvis en leverandør ikke kan vise sine grafer og målinger på oppetid og total motstand, vil de ikke bli vurdert. Når motstand blir en basis-forventning over leverandører, vil avgjørende faktorene skifte mot brukeropplevelse, ytelsesoptimalisering, overvåking og høyere-nivå produktfunksjoner. Over tid, vil komponenter som en AI-gateway og automatiske feilovergangskapasiteter bli core-grunnleggende elementer i bedrifts AI-infrastruktur.

Ser du fremover, hva betyr “produksjonsklar” AI virkelig i en verden hvor AI forventes å være kontinuerlig tilgjengelig, ikke bare av og til nyttig?

Produksjonsklare AI-systemer bør være overvåkbare, kontrollerbare og gjenopprettable. Alle disse boksene må være avmerket.

For produksjons-AI å være overvåkbare, trenger teamer dyp synlighet inn i modell-atferd, latency, feilrater, token-bruk, drift og feil-mønster. Uten sterk overvåking, blir det veldig vanskelig å oppdage degraderinger før brukere begynner å merke dem.

For systemer å være kontrollerbare, inkluderer det trafikk-forming, ratelimit, beskyttelse, policy-gjennomføring og intelligent ruting over modeller og leverandører. Dette er hvor en AI-gateway blir grunnleggende, og fungerer som en sentralisert kontrollplan som håndhever beskyttelse, gir konsekvent styring og muliggjør dynamisk modell-skifting når ytelse eller pålitelighet synker.

Og til slutt, når det gjelder å være gjenopprettable, bør systemer være bygget med antagelsen om at komponenter kan være delvis eller fullstendig ødelagte, enten på grunn av leverandør-nedtider, degradert modellkvalitet, ratelimit eller uventede inndata fra skadelige aktører. Automatiske feilovergangs- og selv-hele-mekanismer bør være native til arkitekturen, ikke manuelle håndbøker utløst etter at noe går galt.

Dette er retningen vi arbeider mot i TrueFoundry. Leverandører som definerer produksjonsklarhet på denne måten, kombinert med overvåking, sentralisert kontroll og automatisert gjenoppretting, vil tjene langvarig kunde-tillit og vil kunne fortsette å løse nye problemer som oppstår.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke TrueFoundry.