Nikunj Bajaj, mede-oprichter en CEO van TrueFoundry – Interviewreeks

U hebt gewerkt aan machine learning-onderzoek, productie-AI bij Facebook (META ) en grote aanbevelingssystemen voordat u TrueFoundry oprichtte — welke ervaringen hebben u het meest rechtstreeks aangezet om een ondernemingsbrede AI-infrastructuurbedrijf op te richten, en welke pijn was er niet aangepakt op dat moment?

Bij Meta zagen we machine learning als een speciaal geval van software, en GenAI als een speciaal geval van machine learning, wat resulteerde in een verticale stack met software aan de onderkant, machine learning in het midden en GenAI bovenaan. In deze setup, als ik een machine learning-ontwikkelaar ben, volgen de modellen die ik bouw hetzelfde implementatiepatroon als de rest van de software, wat het schalen van systemen heel rechttoe rechtaan maakt.

De meeste ondernemingen daarentegen implementeerden parallelle stacks, wat betekent dat ze afzonderlijke stacks hadden voor software, machine learning en GenAI. Het moment dat u deze parallelle stacks hebt, wordt schalen complexer vanwege de overdrachten die nodig zijn tussen machine learning en de softwarewereld.

Ons team heeft altijd gewerkt aan het snijvlak van het bouwen van machine learning-modellen en machine learning-infrastructuur, dus we hadden een uniek perspectief dat we konden brengen naar ondernemingen en aanpassen voor hun specifieke vereisten. We hadden ook een hypothese tegen het einde van 2021 dat machine learning een keerpunt naderde, en toen het dat deed, zouden meer bedrijven een verticaal geïntegreerde stack nodig hebben om deze systemen effectief te implementeren en te schalen. Dit is uiteindelijk de reden waarom we TrueFoundry hebben opgericht, en onze hypothese was juist. AI-adoptie versnelde na de lancering van ChatGPT eind 2022.

Terwijl AI-systemen van experimenten naar dagelijkse operaties gaan, wat is er veranderd in de manier waarop organisaties moeten denken over betrouwbaarheid en falen?

De inzet van Gen AI is aanzienlijk hoger in vergelijking met traditionele machine learning-systemen. Terwijl deze systemen in productie gaan, hebben organisaties te maken met een veel hoger niveau van onzekerheid en niet-determinisme, omdat LLM’s van nature stochastisch zijn. Agente-systemen die op hen zijn gebouwd, voegen nog meer onzekerheid toe.

Bovendien zijn fouten niet langer binaire. In plaats van dat systemen simpelweg falen of niet falen, verschijnen veel problemen als gedeeltelijke fouten of stille degradaties. Systemen kunnen reageren met hogere latentie, verslechterde kwaliteit of onjuist gedrag over tijd. In veel gevallen kunnen deze degradaties moeilijker te detecteren zijn en soms zelfs schadelijker zijn dan een harde storing.

Organisaties moeten denken aan betrouwbaarheid niet alleen in termen van uptime, maar ook prestatiedegradatie over tijd.

TrueFailover was gelanceerd tijdens een golf van hoogprofielcloud- en AI-dienstverstoringen. Welke recente gebeurtenissen maakten het duidelijk dat AI-betrouwbaarheid was verschoven van een “leuk om te hebben” naar een kernarchitectuurvereiste?

Een van onze zorgklantenen die in real-time, tijdsgevoelige patiëntaanvragen verwerkt met betrekking tot recepten, werd getroffen door een storing veroorzaakt door een modelstoring. Hun workflows genereren duizenden dollars aan omzet per seconde, en de storing verstoorden enkele van deze kritieke workflows. Als vroege TrueFailover-klant konden we helpen bij een snelle herstel, en de impact werd beperkt.

Dergelijke incidenten roepen een belangrijke vraag op. Terwijl de inzet van Gen AI-systemen blijft stijgen, waarom zijn herstelprocessen nog steeds grotendeels handmatig? Het versterkte het idee dat systemen moeten worden gebouwd met de veronderstelling dat storingen zullen optreden, en dat ze moeten worden ontworpen om zichzelf automatisch te corrigeren. Betrouwbaarheid moet ook worden ingebouwd in de AI-stack zelf door het gebruik van AI-Gateways, die centrale routing, observatie, beveiligingshekken en intelligente modelwisseling over providers kunnen bieden.

Veel AI-storingen worden nog steeds geframed als technische haperingen. Waar ziet u de echte economische en menselijke kosten beginnen te verschijnen wanneer AI-systemen uitvallen?

Ondernemingsbrede AI is geëvolueerd tot het punt waarop deze haperingen niet langer alleen interne workflows beïnvloeden. Vandaag hebben storingen en degradaties een directe invloed op de perceptie van het publiek en de winst, omdat de productiegevallen nu klantgericht zijn. Deze verschuiving van interne tests naar hoogwaardige, publiekgerichte toepassingen is de reden waarom we een toename zien in de vraag naar uitvoerend toezicht en aandacht.

Terwijl AI-systemen dieper worden ingebed in operationele workflows, zijn storingen niet langer alleen technische problemen. Ze hebben steeds vaker directe gevolgen voor het bedrijf, de klant en de reputatie.

In missie-kritieke omgevingen zoals apotheken, zorgoperaties of klantenservice, hoe snel kan AI-uitval escaleren naar operationeel of reputatierisico?

In missie-kritieke omgevingen gebeurt escalatie bijna onmiddellijk, omdat deze systemen real-time, tijdsgevoelige workflows ondersteunen. Zelfs een korte storing kan kritieke processen stoppen, de dienstverlening vertragen of downstreamsystemen die afhankelijk zijn van die uitvoer, onderbreken, waardoor er een cascade van operationele effecten ontstaat in de organisatie.

In sectoren zoals de zorg heeft de impact zich uitgebreid tot klantervaring en dienstresultaten. Als een patiënt zijn recept niet op tijd kan innen, kunnen er echte gevolgen zijn. Dit is niet alleen een probleem voor de patiënt, maar kan ook de reputatie van een apotheek of zorgverlener schaden. In missie-kritieke omgevingen waar vertrouwen een factor is, is het van cruciaal belang dat systemen online blijven. Daarom erkennen organisaties steeds vaker dat AI-systemen moeten worden ontworpen met de veronderstelling dat storingen zullen optreden en dat herstelmechanismen automatisch moeten worden geactiveerd om risico’s te minimaliseren.

U hebt gezegd dat veel teams architectuur ontwerpen voor functionaliteit in plaats van continuïteit. Waarom denkt u dat veerkracht historisch gezien ondergeschikt is aan AI-systeemontwerp?

Dit komt grotendeels door de stimulansen binnen organisaties. Nieuwe functionaliteiten zijn zichtbaar en spannend. Ze ontgrendelen demos, functies en productmogelijkheden die leiderschap onmiddellijk kan zien.

Continuïteit, per definitie, is onzichtbaar wanneer alles goed werkt. Omdat van dit, beloningssystemen zijn vaak scheef naar het ontwikkelen van nieuwe functionaliteiten in plaats van het waarborgen dat niets kapot gaat. Als gevolg daarvan investeren organisaties onevenredig veel in de ontwikkeling van functionaliteiten in plaats van in veerkrachttechniek.

Terwijl ondernemingen steeds vaker extern modellen en API’s gebruiken, welke nieuwe kwetsbaarheden worden er geïntroduceerd in de AI-stack die leiders mogelijk nog niet volledig waarderen?

LLM’s zijn fundamenteel gedeelde resources, en ondernemingen bezitten ze niet zoals traditionele infrastructuur. Bovendien draaien belangrijke, bedrijfskritieke systemen bij ondernemingen op externe systemen die niet volledig zijn getest. LLM’s zelf evolueren snel, wat betekent dat een modelaanbieder niet aansprakelijk kan worden gesteld voor dingen zoals latentie of modelprestaties die een beetje dalen, omdat ze snel itereren op hun onderzoek.

Omdat LLM’s gedeelde resources zijn, kan latentie omhoog schieten omdat een andere consument van deze LLM’s een specifieke actie onderneemt. Er zijn veel van deze foutpunten die worden geïntroduceerd vanwege de fundamentele aard van LLM’s, en ondernemingen in deze nieuwe wereld hebben eenvoudigweg geen volledige controle. Zonder volledige controle, is de beste optie voor een onderneming om voldoende systeemredundantie te creëren om een veerkrachtig systeem te ontwerpen.

Zonder specifieke producten te noemen, hoe moeten organisaties hun AI-architectuur opnieuw overwegen om uit te gaan van falen in plaats van storingen te behandelen als zeldzame randgevallen?

Organisaties moeten terugkeren naar de eerste principes van gedistribueerde systeemontwerp. Softwaresystemen werden gebouwd op de veronderstelling dat netwerkcomponenten en machines zouden falen, en dat een hele regio naar beneden zou gaan.

AI-systemen zouden niet anders moeten zijn. We moeten aannemen dat modelaanbieders latentieproblemen, degradaties of storingen zullen ervaren, en redundantie incorporeren zodat toepassingen over verschillende foutscenarios blijven werken.

Verwacht u dat AI-veerkracht een beslissende factor wordt in platform- en leveranciersselectie, net zoals uptime en redundantie de beslissingen over cloud-infrastructuur hebben gevormd?

Terwijl meer AI-systemen in productie gaan, zal veerkracht een vereiste worden. Als een leverancier zijn grafieken en metrieken over uptime en algehele veerkracht niet kan laten zien, zal hij niet eens in overweging worden genomen. Zodra veerkracht een basisverwachting wordt over alle leveranciers, zullen de beslissende factoren verschuiven naar gebruikerservaring, prestatie-optimalisatie, observatie en hogere productmogelijkheden. Na verloop van tijd zullen componenten zoals een AI-Gateway en automatische failover-mogelijkheden core-foundational elementen van ondernemingsbrede AI-infrastructuur worden.

Als we vooruitkijken, wat betekent “productieklare” AI echt in een wereld waarin AI continu beschikbaar moet zijn, en niet alleen af en toe nuttig?

Productieklare AI-systemen moeten observeerbaar, controleerbaar en herstelbaar zijn. Alle drie deze vakjes moeten worden aangevinkt.

Voor productie-AI om observeerbaar te zijn, hebben teams diepe zichtbaarheid nodig in modelgedrag, latentie, foutpercentages, tokengebruik, drift en foutpatronen. Zonder sterke observatie wordt het heel moeilijk om degradaties te detecteren voordat gebruikers ze beginnen op te merken.

Voor systemen om controleerbaar te zijn, omvat dit verkeersvorming, ratelimiet, beveiligingshekken, beleidsuitvoering en intelligente routing over modellen en aanbieders. Dit is waar een AI-Gateway core-foundational wordt, als een centraal controlevlak dat beveiligingshekken handhaaft, consistent governance biedt en dynamische modelwisseling mogelijk maakt wanneer prestaties of betrouwbaarheid dalen.

En ten slotte, als het gaat om herstelbaar te zijn, moeten systemen worden gebouwd met de veronderstelling dat componenten gedeeltelijk of volledig kapot kunnen gaan, ofwel vanwege aanbiederstoringen, verslechterde modelkwaliteit, ratelimieten of onverwachte invoer van kwaadwillige actoren. Geautomatiseerde failover- en self-healingmechanismen moeten native zijn aan de architectuur, niet handmatige playbooks die worden geactiveerd nadat iets misgaat.

Dit is de richting waarin we bij TrueFoundry werken. Leveranciers die productieklare AI op deze manier definiëren, door observatie, centrale controle en geautomatiseerd herstel te combineren, zullen langetermijnklantvertrouwen verdienen en in staat zijn om nieuwe problemen op te lossen naarmate ze ontstaan. Bedankt voor het geweldige interview, lezers die meer willen leren, moeten TrueFoundry bezoeken.