Nikunj Bajaj, Co-Founder og CEO af TrueFoundry – Interview Serie

Du har arbejdet på tværs af maskinlæringsforskning, produktions-AI på Facebook og store anbefalingssystemer, før du co-foundede TrueFoundry — hvilke erfaringer fik dig til at bygge en enterprise AI-infrastruktur-virksomhed, og hvilken smerte følte du ikke blev behandlet på det tidspunkt?

I Meta så vi på maskinlæringsmodeller som en specialtilfælde af software, og GenAI som en specialtilfælde af maskinlæringsmodeller, hvilket resulterede i en vertikal stak med software nederst, maskinlæringsmodeller i midten og GenAI øverst. I denne opsætning, hvis jeg er en maskinlæringsudvikler, følger modellerne jeg bygger den samme deployment-mønster som resten af softwaren, hvilket gør det meget nemt at skala systemer.

De fleste virksomheder deployerede dog parallelt stakke, hvilket betyder, at de havde separate stakke til software, maskinlæringsmodeller og GenAI. Øjeblikket du har disse parallelt stakke, bliver skalaering mere kompleks på grund af håndoverne, der kræves mellem maskinlæringsmodeller og software-verdenen.

Vores hold har altid arbejdet på skæringen af at bygge maskinlæringsmodeller og maskinlærings-infrastruktur, så vi havde en unik synsvinkel, som vi kunne bringe lignende vertikale stakke til virksomheder og tilpasse dem til deres specifikke krav. Vi havde også en hypotese mod slutningen af 2021, at maskinlæringsmodeller nærmede sig et inflexionspunkt, og når de gjorde, ville flere virksomheder have brug for en vertikal-integreret stak til at deployere og skala disse systemer effektivt. Dette var, hvad der ultimativt førte os til at co-foundinge TrueFoundry, og vores hypotese var rigtig. AI-adopteringsaccelererende efter lanceringen af ChatGPT i slutningen af 2022.

Da AI-systemer bevæger sig fra eksperimenter til hverdagsoperationer, hvad er ændret i, hvordan organisationer skal tænke om pålidelighed og fejl?

Spilleinsatsen for Gen AI er betydeligt højere sammenlignet med traditionelle maskinlæringsmodeller. Da disse systemer bevæger sig i produktion, har organisationer at gøre med et meget højere niveau af usikkerhed og ikke-determinisme, fordi LLM’er er stokastiske af natur. Agensystemer bygget oven på dem tilføjer yderligere usikkerhed.

Derudover er fejl ikke længere binære. I stedet for, at systemer enten fejler eller ikke fejler, viser mange problemer sig som delvise fejl eller stille degraderinger. Systemer kan svare med højere latency, degraderet kvalitet eller forkert adfærd over tid. I mange tilfælde kan disse degraderinger være sværere at opdage og undertiden endda mere skadelige end en hård afbrydelse.

Organisationer skal tænke om pålidelighed ikke kun i forhold til uptime, men også ydelsesdegradering over tid.

TrueFailover blev lanceret midt i en bølge af højprofilerede cloud- og AI-service-forstyrrelser. Hvad nylige begivenheder gjorde det klart, at AI-pålidelighed havde skiftet fra en “nice-to-have” til en kernearkitekturkrav?

En af vores sundheds-kunder, der behandler realtids-, tidsfølsomme patientanmodninger relateret til recepter, blev ramt af en afbrydelse forårsaget af en model-fejl. Deres arbejdsgange genererer tusinder af dollars i omsætning per sekund, og afbrydelsen forstyrrede nogle af disse kritiske arbejdsgange. Som en tidlig TrueFailover-kunde kunne vi hjælpe med hurtig genoprettelse, og virkningen blev begrænset.

Begivenheder som denne rejser et vigtigt spørgsmål. Da spilleinsatsen for Gen AI-systemer fortsætter med at stige, hvorfor er genoprettelsesprocesser stadig overvejende manuelle? Det bekræftede ideen om, at systemer skal være bygget med antagelsen af, at fejl vil ske, og at de skal være designede til at korrigere sig selv automatisk. Pålidelighed skal også være bygget ind i AI-stakken selv gennem brugen af AI-Gateways, som kan give centraliseret routing, overvågning, guardrails og intelligent model-skiftning på tværs af udbydere.

Mange AI-afbrud bliver stadig ramt som tekniske hikker. Hvor ser du de virkelige økonomiske og menneskelige omkostninger begynder at dukke op, når AI-systemer går ned?

Enterprise AI er udviklet til et punkt, hvor disse hikker ikke længere kun påvirker interne arbejdsgange. I dag påvirker afbrydelser og degraderinger offentlig opfattelse og overskud direkte og umiddelbart, fordi produktionsbrugs-tilfældene nu er kunde-orienterede. Dette skift fra interne tests til høj-spille- og offentligt-orienterede applikationer er, hvorfor vi ser en stigende efterspørgsel efter ledelsesmæssig opmærksomhed og tilsyn.

Da AI-systemer bliver mere integreret i operationelle arbejdsgange, bliver afbrydelser ikke længere kun tekniske problemer. De har mere og mere direkte forretnings-, kunde- og reputationsmæssige konsekvenser.

I mission-kritiske miljøer som apoteker, sundhedsoperationer eller kundesupport, hvor hurtigt kan AI-nedtid eskalere til operationel eller reputationsrisiko?

I mission-kritiske miljøer sker eskalering næsten øjeblikkeligt, fordi disse systemer understøtter realtids-, tidsfølsomme arbejdsgange. Selv en kort afbrydelse kan standse kritiske processer, forsinke servicelevering eller afbryde downstream-systemer, der afhænger af disse output, og skabe kaskade-operationelle effekter på tværs af organisationen.

I sektorer som sundhedspleje udvider virkningen sig ud over operationel forstyrrelse til kundeoplevelse og service-resultater. Hvis en patient ikke kan opfylde sin recept på tid, kan der være reelle konsekvenser. Det er ikke kun et problem for patienten, men det kan også skade et apoteks eller sundhedsudbyders rygte. I mission-kritiske miljøer, hvor tillid er en faktor, er det afgørende, at systemer forbliver online. Dette er, hvorfor organisationer mere og mere erkender, at AI-systemer skal være designede med antagelsen af, at fejl vil ske, og at genoprettelsesmekanismer skal aktiveres automatisk for at minimere risiko.

Du har sagt, at mange hold arkitekter for funktion i stedet for kontinuitet. Hvorfor tror du, at resilience historisk har været underprioriteret i AI-system-design?

Dette kommer hovedsagelig ned til incitamenter inden for organisationer. Nye funktioner er synlige og spændende. De låser op for demos, funktioner og produktmuligheder, som ledelsen kan se øjeblikkeligt.

Kontinuitet, per definition, er usynlig, når tingene fungerer godt. Fordi det, incitament-systemer tenderer til at være skævede mod at skibe nye funktioner i stedet for at sikre, at intet går galt. Som resultat heraf investerer organisationer ofte uproportionligt i funktion-udvikling i stedet for i resiliens-teknik.

Da virksomheder mere og mere afhænger af eksterne modeller og API’er, hvilke nye sårbarheder introduceres i AI-stakken, som ledere måske ikke fuldt ud værdsætter endnu?

LLM’er er fundamentalt fællesressourcer, og virksomheder ejer dem ikke, som de gør traditionel infrastruktur. Derudover kører vigtige forretnings-kritiske systemer med virksomheder på eksterne systemer, der ikke er fuldt ud testet i tid. LLM’er selv udvikler sig hurtigt, hvilket betyder, at en model-udbyder ikke kan holdes ansvarlig for ting som latency eller model-ydelse, der går lidt ned, fordi de itererer på deres forskning meget hurtigt.

Fordi LLM’er er fællesressourcer, kan latency springe, fordi en anden forbruger af disse LLM’er tager en bestemt handling. Der er mange af disse fejlpunkter, der introduceres, fordi de fundamentale egenskaber ved LLM’er, og virksomheder i denne nye verden har simpelthen ikke fuld kontrol. Uden fuld kontrol kan den bedste ting, en virksomhed kan gøre, være at oprette nok system-redundanser til at designe et resiliens-system.

Uden at fokusere på specifikke produkter, hvordan skal organisationer omstrukturere AI-arkitektur til at antage fejl i stedet for at behandle afbrydelser som sjældne kant-tilfælde?

Organisationer skal vende tilbage til de første principper for distribueret system-design. Software-systemer blev bygget på antagelsen af, at netværkskomponenter og maskiner ville fejle, og at en hel region kunne gå ned.

AI-systemer skal ikke være forskellige. Vi skal antage, at model-udbydere vil opleve latency-problemer, degraderinger eller afbrydelser, og inkorporere redundans, så applikationer forbliver resiliens på tværs af forskellige fejl-scenarier.

Forventer du, at AI-resilience bliver en afgørende faktor i platform- og udbyder-valg, ligesom hvordan uptime og redundans formede cloud-infrastruktur-beslutninger?

Da flere AI-systemer bevæger sig i produktion, vil resilience blive en basal forventning. Hvis en udbyder ikke kan vise deres grafer og målinger på uptime og samlet resiliens, vil de ikke engang blive overvejet. Når resilience bliver en grundlæggende forventning på tværs af udbydere, vil afgørende faktorerne skifte mod brugeroplevelse, ydelsesoptimering, overvågning og højere niveau-produktfunktioner. Over tid vil komponenter som en AI-Gateway og automatiseret failover-kapacitet blive kerne-fundamentale elementer i enterprise AI-infrastruktur.

At se fremad, hvad betyder “produktionsklar” AI i en verden, hvor AI forventes at være kontinuerligt tilgængelig, ikke kun lejlighedsvis hjælpsom?

Produktionsklar AI-systemer skal være overvågelige, kontrollerbare og genoprettelige. Alle disse tre bokse skal være markeret.

Til produktion-AI skal være overvågelig, har hold brug for dyb indsigt i model-opførsel, latency, fejl-rater, token-brug, drift og fejl-mønstre. Uden stærk overvågning bliver det meget svært at opdage degraderinger, før brugere begynder at bemærke dem.

Til systemer skal være kontrollerbare, det inkluderer trafik-formning, rate-begrænsning, guardrails, politik-gennemførelse og intelligent routing på tværs af modeller og udbydere. Dette er, hvor en AI-Gateway bliver grundlæggende, fungerer som en centraliseret kontrol-plan, der gennemtvinger guardrails, giver konsekvent governance og muliggør dynamisk model-skiftning, når ydelse eller pålidelighed falder.

Og til sidst, når det kommer til at være genoprettelig, skal systemer være bygget med antagelsen af, at komponenter kan være delvist eller fuldstændigt ødelagte, enten på grund af udbyder-afbrud, degraderet model-kvalitet, rate-grænser eller uventede input fra ondsindede aktører. Automatiserede failover- og selv-healing-mekanismer skal være native til arkitekturen, ikke manuelle playbooks udløst efter noget går galt.

Dette er den retning, vi arbejder mod i TrueFoundry. Udbydere, der definerer produktionsklarhed på denne måde, kombinerer overvågning, centraliseret kontrol og automatiseret genoprettelse, vil tjene langsigtede kunde-tillid og vil være i stand til at løse nye problemer, da de opstår.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge TrueFoundry.