Nikunj Bajaj, medstifter og administrerende direktør i TrueFoundry – Interviewserie

Du har arbejdet med maskinlæringsforskning, produktions-AI hos Facebook (META ) og storstilet anbefalingsystemer, før du startede TrueFoundry — hvilke erfaringer har ført dig til at bygge en enterprise AI-infrastruktur-virksomhed, og hvilken smerte følte du ikke blev tilgodeset på det tidspunkt?

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

De fleste virksomheder havde dog separate stakke for software, maskinlæringsmodeller og generative AI. Øjeblikket du har disse separate stakke, bliver skalaering mere kompleks på grund af håndover mellem maskinlærings- og software-verdenen.

Vores hold har altid arbejdet på skæringspunktet mellem 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 vendepunkt, og når de gjorde, ville flere virksomheder have brug for en vertikalintegreret stak til at deployere og skala disse systemer effektivt. Dette var det, der til sidst førte os til at starte TrueFoundry, og vores hypotese var rigtig. AI-adopteringshastigheden accelererede efter lanceringen af ChatGPT i slutningen af 2022.

Når AI-systemer bevæger sig fra eksperimenter til daglige operationer, hvad er ændret i, hvordan virksomheder skal tænke om pålidelighed og fejl?

Indsatsen med generative AI er betydeligt højere sammenlignet med traditionelle maskinlæringsmodeller. Når disse systemer kommer i produktion, har virksomheder at gøre med en meget højere niveau af usikkerhed og ikke-determinisme, fordi LLM’er er stokastiske af natur. Agentsystemer 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 nedtur.

Virksomheder skal tænke på pålidelighed, ikke kun i forhold til op-tid, men også i forhold til ydelsesdegradering over tid.

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

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

Tilfælde som dette rejser et vigtigt spørgsmål. Når indsatsen med generative AI-systemer fortsat stiger, hvorfor er genoprettelsesprocesser stadig overvejende manuelle? Det understreger ideen om, at systemer skal være bygget med antagelsen af, at fejl vil ske, og at de skal være designet til automatisk at korrigere sig selv. Pålidelighed skal også være bygget ind i AI-stakken selv gennem brug af AI-Gateways, som kan give centraliseret routing, overvågning, guardrails og intelligent model-skiftning på tværs af udbydere.

Mange AI-nedturer bliver stadig fremstillet som tekniske hikker. Hvor ser du de virkelige økonomiske og menneskelige omkostninger begynde 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 nedturer og degraderinger offentlighedens opfattelse og overskud direkte og umiddelbart, fordi produktionsanvendelserne nu er kunde-orienterede. Denne skift fra interne tests til højtsatsede, offentlige anwendelser er årsagen til, at vi ser en øget efterspørgsel efter ledelsesmæssig opmærksomhed og tilsyn.

Når AI-systemer bliver mere integreret i operationelle arbejdsgange, bliver nedturer ikke længere kun tekniske problemer. De har i stigende grad 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 reputationsmæssig risiko?

I mission-kritiske miljøer sker eskalering næsten øjeblikkeligt, fordi disse systemer understøtter realtids-, tidsfølsomme arbejdsgange. Selv en kortvarig forstyrrelse kan stoppe 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 sundhedssektoren udvides påvirkningen 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 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. Det er derfor, at organisationer i stigende grad erkender, at AI-systemer skal være designet 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 resiliens historisk har været underprioriteret i AI-systemdesign?

Dette skyldes i høj grad 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 kontinuitet er usynlig, tenderer belønnings-systemer til at være skævede mod at udvikle nye funktioner i stedet for at sikre, at intet går galt. Derfor investerer organisationer ofte urent i funktionudvikling i stedet for i resiliens-teknisk udvikling.

Når virksomheder i stigende grad afhænger af eksterne modeller og API’er, hvilke nye sårbarheder introduceres i AI-stakken, som ledere måske ikke fuldt ud erkender endnu?

LLM’er er grundlæggende fællesressourcer, og virksomheder ejer dem ikke, som de ejer traditionel infrastruktur. Desuden kører vigtige forretnings-kritiske systemer med virksomheder på eksterne systemer, der ikke er fuldt ud testet. LLM’er selv udvikler sig hurtigt, hvilket betyder, at en model-udbyder ikke kan holdes ansvarlig for ting som latency eller model-præstation, der falder lidt, fordi de itererer over deres forskning meget hurtigt.

Fordi LLM’er er fællesressourcer, kan latency stige, fordi en anden forbruger af disse LLM’er udfører en bestemt handling. Der er mange af disse fejlpunkter, der introduceres på grund af LLM’ernes grundlæggende natur, 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 tilstrækkelige system-redundanser for at designe et resilient system.

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

Organisationer skal vende tilbage til de grundlæggende principper for distribueret systemdesign. 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 anderledes. Vi skal antage, at model-udbydere vil opleve latency-problemer, degraderinger eller nedturer, og inkorporere redundans, så applikationer forbliver resiliante på tværs af forskellige fejlscenarier.

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

Når flere AI-systemer kommer i produktion, vil resiliens blive en grundlæggende forventning. Hvis en udbyder ikke kan vise deres grafer og metrikker for op-tid og samlet resiliens, vil de ikke engang blive overvejet. Når resiliens bliver en grundlæggende forventning på tværs af udbydere, vil de afgørende faktorer skifte mod brugeroplevelse, ydelsesoptimering, overvågning og højere niveau-produktfunktioner. Over tid vil komponenter som en AI-Gateway og automatiske failover-funktioner blive grundlæggende elementer i enterprise AI-infrastruktur.

Settende fremad, hvad betyder “produktionsklar” AI virkelig i en verden, hvor AI forventes at være kontinuerligt tilgængelig, ikke kun lejlighedsvis nyttig?

Produktionsklare AI-systemer skal være overvågelige, kontrollerbare og genoprettelige. Alle disse tre krav skal være opfyldt.

Til at være overvågelige skal holdene have 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 brugerne begynder at bemærke dem.

Til at være kontrollerbare skal det inkludere trafik-styring, 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 kontrolplane, der gennemtvinger guardrails, giver konsekvent governance og ermöglicher dynamisk model-skiftning, når ydelse eller pålidelighed falder.

Og sidst, når det kommer til at være genoprettelige, skal systemer være bygget med antagelsen af, at komponenter kan være delvist eller fuldstændigt ødelagte, enten på grund af udbyder-nedturer, degraderet model-kvalitet, rate-begrænsninger eller uventede indgange fra ondsindede aktører. Automatiske 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 opnå langsigtedt kunde-tillid og vil være i stand til at løse nye problemer, når de opstår.

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