Nikunj Bajaj, medgrunnlegger og administrerende direktør i TrueFoundry – Intervjuserie

Før du grunnla TrueFoundry, arbeidet du med forskning på maskinlæring, KI i produksjon hos Facebook (META ) og anbefalingssystemer i stor skala. Hvilke erfaringer førte deg mest direkte til å bygge et selskap for KI-infrastruktur til virksomheter, og hvilket problem mente du ikke ble løst den gangen?

Hos Meta betraktet vi maskinlæring som et spesialtilfelle av programvare og generativ KI som et spesialtilfelle av maskinlæring. Det ga en vertikal teknologistakk med programvare nederst, maskinlæring i midten og generativ KI øverst. I dette oppsettet følger modellene jeg bygger som maskinlæringsutvikler, det samme utrullingsmønsteret som resten av programvaren. Det gjør skalering av systemer svært enkelt.

De fleste virksomheter tok imidlertid i bruk parallelle stakker, altså separate stakker for programvare, maskinlæring og generativ KI. Med disse parallelle stakkene blir skalering mer kompleks på grunn av de nødvendige overleveringene mellom maskinlæring og programvareområdet.

Teamet vårt har alltid arbeidet i skjæringspunktet mellom utvikling av maskinlæringsmodeller og maskinlæringsinfrastruktur. Dette ga oss et særegent perspektiv: Vi kunne bringe lignende vertikale stakker inn i virksomheter og tilpasse dem til deres spesifikke krav. Mot slutten av 2021 hadde vi også en hypotese om at maskinlæring nærmet seg et vendepunkt. Når det skjedde, ville flere selskaper trenge en vertikalt integrert stakk for å sette disse systemene i drift og skalere dem effektivt. Det var dette som til slutt førte til at vi grunnla TrueFoundry, og hypotesen vår viste seg å stemme. Innføringen av KI skjøt fart etter lanseringen av ChatGPT i slutten av 2022.

Hva har endret seg i måten organisasjoner bør tenke på pålitelighet og feil, etter hvert som KI-systemer går fra eksperimentering til daglig drift?

Det står betydelig mer på spill med generativ KI enn med tradisjonelle maskinlæringssystemer. Når disse systemene går inn i produksjon, møter organisasjoner langt større tvetydighet og ikke-determinisme fordi LLM-er er stokastiske av natur. Agentbaserte systemer som bygger på dem, tilfører ytterligere tvetydighet.

Feil er dessuten ikke lenger binære. Det handler ikke bare om at systemer enten virker eller ikke virker; mange problemer viser seg som delvise feil eller forringelser som skjer i det stille. Over tid kan systemene svare med høyere latenstid, dårligere kvalitet eller feilaktig atferd. I mange tilfeller kan disse forringelsene være vanskeligere å oppdage og noen ganger enda mer skadelige enn en fullstendig driftsstans.

Organisasjoner må vurdere pålitelighet ikke bare ut fra oppetid, men også ut fra forringelse av ytelsen over tid.

TrueFailover ble lansert midt i en bølge av forstyrrelser i sky- og KI-tjenester som fikk stor oppmerksomhet. Hvilke nylige hendelser gjorde det klart at KI-pålitelighet hadde gått fra å være en ønskelig tilleggsegenskap til et grunnleggende arkitekturkrav?

En av kundene våre i helsesektoren behandler pasientforespørsler om resepter i sanntid, der det er avgjørende å svare i tide. Kunden ble rammet av en driftsstans som skyldtes en modellfeil. Arbeidsflytene deres genererer tusenvis av dollar i inntekter per sekund, og driftsstansen forstyrret noen av disse kritiske arbeidsflytene. Kunden var blant de første som tok i bruk TrueFailover, så vi kunne hjelpe med rask gjenoppretting og begrense konsekvensene.

Hendelser som denne reiser et viktig spørsmål: Når stadig mer står på spill med generative KI-systemer, hvorfor er gjenopprettingsprosessene fortsatt i stor grad manuelle? Det styrket tanken om at systemer bør bygges med utgangspunkt i at feil vil skje, og utformes slik at de retter seg selv automatisk. Pålitelighet må også bygges inn i selve KI-stakken gjennom KI-gatewayer som kan tilby sentralisert ruting, observerbarhet, sikkerhetsmekanismer og intelligent bytte mellom modeller fra ulike leverandører.

Mange driftsstanser i KI blir fortsatt fremstilt som små tekniske problemer. Hvor ser du at de reelle økonomiske og menneskelige kostnadene begynner å vise seg når KI-systemer går ned?

KI i virksomheter har utviklet seg så langt at disse problemene ikke lenger bare påvirker interne arbeidsflyter. I dag påvirker driftsstanser og forringelser publikums oppfatning og overskuddet direkte og umiddelbart, fordi produksjonsapplikasjonene nå betjener kunder. Overgangen fra intern testing til applikasjoner som er tilgjengelige for publikum og der mye står på spill, er grunnen til at vi ser økt behov for oppmerksomhet og tilsyn fra toppledelsen.

Etter hvert som KI-systemer integreres dypere i operative arbeidsflyter, er driftsstanser ikke lenger bare tekniske problemer. De får i økende grad direkte konsekvenser for virksomheten, kundene og omdømmet.

Hvor raskt kan KI-nedetid utvikle seg til en operasjonell risiko eller omdømmerisiko i kritiske miljøer som apotek, helsetjenester eller kundestøtte?

I kritiske miljøer skjer eskaleringen nesten umiddelbart fordi disse systemene støtter arbeidsflyter i sanntid der rettidig behandling er avgjørende. Selv et kort avbrudd kan stanse kritiske prosesser, forsinke levering av tjenester eller forstyrre etterfølgende systemer som er avhengige av disse resultatene, og skape en kjedereaksjon av driftsmessige konsekvenser i hele organisasjonen.

I sektorer som helsevesenet går konsekvensene utover driftsforstyrrelser og påvirker også kundeopplevelsen og resultatene av tjenestene. Hvis en pasient ikke får hentet ut reseptmedisinen i tide, kan det få reelle følger. Det er ikke bare et problem for pasienten; det kan også skade omdømmet til apoteket eller helsetjenesteleverandøren. I kritiske miljøer der tillit er viktig, er det helt avgjørende at systemene holder seg i drift. Derfor erkjenner organisasjoner i økende grad at KI-systemer må utformes med utgangspunkt i at feil vil oppstå, og at gjenopprettingsmekanismer må aktiveres automatisk for å minimere risikoen.

Du har sagt at mange team utformer arkitekturen med tanke på kapabilitet fremfor kontinuitet. Hvorfor tror du robusthet historisk har fått lavere prioritet i utformingen av KI-systemer?

Dette skyldes i stor grad insentivene i organisasjonene. Nye kapabiliteter er synlige og spennende. De åpner for demonstrasjoner, funksjoner og nye produktmuligheter som ledelsen kan se umiddelbart.

Kontinuitet er per definisjon usynlig når alt fungerer godt. Belønningssystemer har derfor en tendens til å favorisere lansering av nye funksjoner fremfor å sikre at ingenting går i stykker. Som følge av dette investerer organisasjoner ofte uforholdsmessig mye i utvikling av kapabiliteter sammenlignet med det tekniske arbeidet med å sikre robusthet.

Hvilke nye sårbarheter i KI-stakken kan ledere fortsatt undervurdere etter hvert som virksomheter blir mer avhengige av eksterne modeller og API-er?

LLM-er er grunnleggende sett delte ressurser, og virksomheter eier dem ikke slik de eier tradisjonell infrastruktur. Viktige forretningskritiske systemer i virksomheter kjører dessuten på eksterne systemer som ennå ikke er fullt ut prøvd over tid. LLM-ene selv utvikler seg raskt, noe som betyr at en modellleverandør ikke kan holdes ansvarlig for forhold som latenstid eller en liten nedgang i modellens ytelse, fordi leverandøren gjennomfører nye forskningsiterasjoner svært raskt.

Fordi LLM-er er delte ressurser, kan latenstiden øke brått når en annen bruker utfører en bestemt handling. LLM-enes grunnleggende natur innfører mange slike feilpunkter, og virksomheter har rett og slett ikke full kontroll i denne nye verdenen. Uten full kontroll er det beste en virksomhet kan gjøre, å bygge inn tilstrekkelig redundans for å utforme et robust system.

Uten å fokusere på bestemte produkter: Hvordan bør organisasjoner tenke nytt om KI-arkitektur slik at de regner med at feil vil skje, fremfor å behandle driftsstanser som sjeldne særtilfeller?

Organisasjoner bør vende tilbake til grunnprinsippene for utforming av distribuerte systemer. Programvaresystemer ble bygget med utgangspunkt i at nettverkskomponenter og maskiner ville svikte, og at en hel region kunne gå ned.

KI-systemer bør ikke være annerledes. Vi bør anta at modellleverandører vil oppleve latenstidsproblemer, forringelser eller driftsstanser, og bygge inn redundans slik at applikasjonene forblir robuste i ulike feilscenarioer.

Forventer du at KI-robusthet blir en avgjørende faktor ved valg av plattform og leverandør, slik oppetid og redundans har formet beslutninger om skyinfrastruktur?

Når flere KI-systemer går inn i produksjon, blir robusthet et minstekrav. Hvis en leverandør ikke kan vise grafer og målinger for oppetid og samlet robusthet, vil leverandøren ikke engang bli vurdert. Når robusthet blir en grunnleggende forventning til alle leverandører, vil de avgjørende faktorene flytte seg til brukeropplevelse, ytelsesoptimalisering, observerbarhet og produktets kapabiliteter på høyere nivå. Med tiden vil komponenter som en KI-gateway og automatiske failover-funksjoner bli sentrale grunnelementer i virksomheters KI-infrastruktur.

Hva betyr egentlig “produksjonsklar” KI fremover i en verden der KI forventes å være kontinuerlig tilgjengelig og ikke bare nyttig av og til?

Produksjonsklare KI-systemer bør kunne observeres, styres og gjenopprettes. Alle tre kravene må være oppfylt.

For at KI i produksjon skal kunne observeres, trenger team inngående innsikt i modellatferd, latenstid, feilrater, tokenbruk, drift og feilmønstre. Uten sterk observerbarhet blir det svært vanskelig å oppdage forringelser før brukerne begynner å legge merke til dem.

Muligheten til å styre systemene omfatter trafikkregulering, begrensning av forespørselsraten, sikkerhetsmekanismer, håndheving av retningslinjer og intelligent ruting mellom modeller og leverandører. Her blir en KI-gateway grunnleggende, som et sentralisert styringslag som håndhever sikkerhetsmekanismer, sørger for enhetlig styring og muliggjør dynamisk bytte av modell når ytelsen eller påliteligheten faller.

Til slutt, for at systemer skal kunne gjenopprettes, bør de bygges med utgangspunkt i at komponenter kan være delvis eller helt ute av funksjon. Årsaken kan være driftsstans hos leverandøren, dårligere modellkvalitet, grenser for forespørselsraten eller uventede inndata fra ondsinnede aktører. Automatisk failover og mekanismer for selvreparasjon bør være innebygd i arkitekturen, fremfor manuelle prosedyrer som først utløses etter at noe går galt.

Dette er retningen vi arbeider mot i TrueFoundry. Leverandører som definerer produksjonsklarhet på denne måten, ved å kombinere observerbarhet, sentralisert styring og automatisk gjenoppretting, vil oppnå langsiktig tillit hos kundene og kunne fortsette å løse nye problemer etter hvert som de oppstår.

Takk for det flotte intervjuet. Lesere som ønsker å vite mer, kan besøke TrueFoundry.