Shahar Azulay, CEO en medeoprichter van Groundcover

Shahar Azulay, De CEO en medeoprichter van Groundcover is een ervaren leider in onderzoek en ontwikkeling. Shahar heeft ruime ervaring in de wereld van cybersecurity en machine learning, opgedaan als leidinggevende bij bedrijven zoals Apple, DayTwo en Cymotive Technologies. Hij werkte jarenlang bij de cyberafdeling van het Israëlische kabinet en behaalde drie diploma's in natuurkunde, elektrotechniek en informatica aan het Technion Israel Institute of Technology en de Universiteit van Tel Aviv. Shahar streeft ernaar de technologische kennis uit deze rijke achtergrond te gebruiken en deze op de meest innovatieve manier toe te passen in de huidige cloud-native wereld, om zo de ontwikkelaarswereld te verbeteren.

bodembedekker Dit is een cloud-native observatieplatform dat is ontworpen om engineeringteams volledig en realtime inzicht te geven in hun systemen, zonder de complexiteit of kosten van traditionele monitoringtools. Gebouwd op eBPF-technologie, verzamelt en correleert het logs, metrics, traces en gebeurtenissen in cloud-native en Kubernetes-omgevingen zonder codeaanpassingen. Dit maakt snellere oorzaakanalyse en een duidelijker systeeminzicht mogelijk. Het platform legt de nadruk op voorspelbare prijzen, flexibele implementatie waarbij data in de cloud van de klant blijft, en end-to-end observatie die infrastructuur, applicaties en moderne AI-gestuurde workloads omvat.

Terugkijkend op uw loopbaan – van het leiden van cyber-R&D-teams op het kantoor van de Israëlische premier tot het managen van ML-initiatieven bij Apple – welke ervaringen hebben u uiteindelijk ertoe bewogen Groundcover op te richten, en wanneer realiseerde u zich voor het eerst de lacune in de observeerbaarheid van moderne AI-systemen?

De drijfveer om Groundcover op te richten kwam voort uit mijn tijd bij Apple en DayTwo. Zelfs met enorme budgetten zaten we vast in een dilemma: ofwel een fortuin betalen om alles te loggen, ofwel steekproeven nemen en blind vliegen. Destijds zochten we naar een technologie die dat probleem zou oplossen. Toen we Extended Berkeley Packet Filter (eBPF) tegenkwamen, was het duidelijk dat dit alles zou veranderen. eBPF laat ons alles zien wat er in de kernel gebeurt, zonder afhankelijk te zijn van applicatiewijzigingen. Ik begreep niet waarom observability-tools daar geen gebruik van maakten. De AI-kloof werd later duidelijk. Toen ons Kubernetes-platform volwassen was, zagen we klanten massaal GenAI-implementaties uitvoeren, terwijl ze LLM's als black boxes behandelden. Ze wisten dat het model reageerde, maar niet waarom het zich onvoorspelbaar gedroeg of waarom de kosten zo hoog opliepen. We realiseerden ons dat agentische workflows simpelweg complexe, niet-deterministische microservices zijn die dezelfde zero-touch zichtbaarheid nodig hebben die we al hadden ontwikkeld.

Hoe heeft uw achtergrond in cybersecurity, embedded systemen en R&D op het gebied van machine learning de visie achter Groundcover beïnvloed, en welke uitdagingen bent u in de beginfase tegengekomen bij het opbouwen van een bedrijf dat zich richt op observability voor LLM-gestuurde en agentische applicaties?

Mijn achtergrond in cybersecurity heeft het DNA van het bedrijf gevormd. In de inlichtingenwereld ga je ervan uit dat je de applicatie niet beheert. Die aanpak is de reden waarom Groundcover geen instrumentatie vereist. Ik weet uit ervaring dat ontwikkelaars vragen om code aan te passen de snelste manier is om acceptatie te blokkeren. De grootste uitdaging in het begin met LLM-monitoring was privacy. Observability voor AI legt prompts vast die gevoelige persoonsgegevens of IP-adressen kunnen bevatten. Mijn achtergrond maakte duidelijk dat bedrijven die gegevens niet buiten hun eigen omgeving wilden hebben. Daarom hebben we onze cloudarchitectuur gebouwd, waardoor we diepgaand inzicht kunnen bieden in het gedrag van agents, terwijl alle gegevens binnen de eigen omgeving van de klant blijven.

Hoe definieer je LLM-observeerbaarheid en wat maakt het anders dan traditionele monitoring of ML-monitoring?

LLM-observability is de praktijk van het instrumenteren en monitoren van productiesystemen die gebruikmaken van grote taalmodellen, zodat je de volledige context van elke inferentie kunt vastleggen: de prompt, context, voltooiing, tokengebruik, latentie, fouten, modelmetadata en idealiter downstream feedback of kwaliteitssignalen. In plaats van alleen te vragen "Is de service beschikbaar en snel?" of "Is deze aanvraag mislukt?", helpt LLM-observability je vragen te beantwoorden zoals "Waarom is deze specifieke aanvraag geslaagd of mislukt?", "Wat is er precies gebeurd in deze workflow met meerdere stappen?" en "Hoe beïnvloeden wijzigingen in prompts, context of modelversies de kosten, latentie en uitvoerkwaliteit?". Dit is heel anders dan traditionele monitoring of zelfs klassieke ML-monitoring. Traditionele benaderingen zijn afgestemd op deterministische systemen, infrastructuurstatistieken en statische drempelwaarden. LLM-toepassingen zijn niet-deterministisch, open en sterk contextafhankelijk. Succes is vaak semantisch en subjectief, niet alleen een statuscode van 200 versus 500. Dat betekent dat je de invoer en uitvoer moet traceren, de aanroepen van tools en de ophaalstappen moet begrijpen, reacties moet evalueren op zaken als hallucinaties of beleidsschendingen, en de kosten en vertragingen op tokenniveau moet koppelen aan de omringende applicatie en infrastructuur.

Welke uitdagingen brengen LLM-toepassingen met zich mee waardoor traditionele observatietools ontoereikend zijn?

LLM-gestuurde systemen brengen verschillende uitdagingen met zich mee die de beperkingen van traditionele instrumenten blootleggen:

• Complexe workflows met meerdere stappen – We zijn overgestapt van eenvoudige workflows van "roep een model aan, krijg een reactie" naar meerstapsagenten, meerstaps pipelines, retrieval-augmented generation en het gebruik van tools. Een stille fout in een van deze stappen, zoals retrieval, enrichment, embedding, tool-call of model-call, kan de hele ervaring verstoren. Traditionele monitoring biedt meestal geen volledig overzicht op traceniveau van deze ketens, inclusief prompts en reacties.
• Snel evoluerende AI-stacks – Teams voegen in een ongekend tempo nieuwe modellen, tools en leveranciers toe. In veel bedrijven kan niemand met zekerheid opnoemen welke modellen er op een bepaald moment in productie zijn. Klassieke observability gaat er meestal van uit dat je tijd hebt om SDK's te instrumenteren, opnieuw te implementeren en zorgvuldig te bepalen wat je meet. Dat is simpelweg niet toereikend om de snelheid waarmee AI wordt geaccepteerd bij te benen.
• Tokengebaseerde economie en quota – Prijzen en snelheidslimieten zijn gekoppeld aan tokens en de duur van de context, die vaak worden bepaald door ontwikkelaars, prompts of gebruikersgedrag, en niet door een centrale beheerafdeling. Traditionele tools zijn niet ontworpen om te laten zien "wie hoeveel tokens heeft verbruikt op welk model, voor welke workflow, met welke latentie".
• Semantische correctheid in plaats van binair succes. – Een LLM kan een score van 200 halen en toch hallucineren, afdwalen van de opdracht of het beleid overtreden. Traditionele tools beschouwen dat als een succes. Je hebt observatie nodig die opdrachten en reacties aan het licht brengt en je voldoende context geeft om gedrag te inspecteren en, na verloop van tijd, geautomatiseerde kwaliteitscontroles in te voeren.
• Gevoelige invoergegevens die naar derden worden doorgestuurd – LLM's nodigen gebruikers uit om zeer gevoelige informatie te delen via chatachtige interfaces. U bent nu verantwoordelijk voor die gegevens, waar ze worden opgeslagen en welke leveranciers ze kunnen inzien. Conventionele, op SaaS gebaseerde observability, waarbij alle telemetrie naar een derde partij wordt verzonden, is vaak onacceptabel voor dit soort workloads.

Dit alles betekent dat LLM-systemen een observeerbaarheid vereisen die rekening houdt met AI, contextrijk is en veel minder afhankelijk is van handmatige instrumentatie dan de tools die de meeste teams tegenwoordig gebruiken.

Welke signalen of meetwaarden zijn het belangrijkst voor het begrijpen van de prestaties en kwaliteit van LLM-systemen, waaronder latentie, tokengebruik en prompt/respons-gedrag?

Er zijn een aantal signaalcategorieën die in de praktijk erg belangrijk zijn:

Latentie en doorvoer

• De totale latentie per verzoek, inclusief de tijd die het model nodig heeft en de tijd die de omringende applicatie nodig heeft.
• Staartlatentie (P90, P95, P99) per model en per workflow.
• Doorvoer per model, route en service, zodat u weet waar de belasting daadwerkelijk naartoe gaat.

Tokengebruik en kostenfactoren

• Invoer- en uitvoertokens per verzoek, uitgesplitst per model.
• Geaggregeerd tokengebruik over tijd per model, team, gebruiker en workflow.
• Contextgroottes voor data-ophaalprocessen met veel zoekopdrachten, zodat je kunt zien wanneer prompts exploderen.
• Dit stelt je in staat om de vraag te beantwoorden: "Wie besteedt ons AI-budget nu eigenlijk en waaraan?"

Aanwijzingen en reactiegedrag

• De daadwerkelijke prompt- en response-payloads op representatieve traceringen, inclusief toolaanroepen en redeneerpaden.
• Welke instrumenten heeft het LLM gekozen en in welke volgorde?
• Variatie in reacties op vergelijkbare aanwijzingen geeft aan hoe stabiel het gedrag is.

Betrouwbaarheid en fouten

• Modelspecifieke foutpercentages en -typen (providerfouten, time-outs, authenticatieproblemen, quotafouten).
• Storingen in de omliggende workflow, zoals time-outs van tools of ophaalfouten, correleerden met de LLM-aanroep.

Klassieke infrastructuurcontext

• CPU-, geheugen- en netwerkstatistieken van de containers voor de services die uw LLM-aanroepen orkestreren.
• Gecorreleerde logbestanden die beschrijven wat de applicatie probeerde te doen.

Wanneer je dat allemaal op één plek kunt zien, verschuift de LLM-observabiliteit van "Ik weet dat iets traag of duur is" naar "Ik weet precies welk model, promptpatroon en service hiervoor verantwoordelijk zijn en waarom".

Hoe kan observeerbaarheid teams helpen bij het opsporen van stille fouten, zoals prompt-drift, hallucinaties of geleidelijke verslechtering van de outputkwaliteit?

Stille storingen in LLM-systemen treden meestal op wanneer alles er op infrastructuurniveau "groen" uitziet, maar het daadwerkelijke gedrag afwijkt. Observeerbaarheid biedt op verschillende manieren uitkomst:

• Het volledige workflowproces in kaart brengen, niet alleen de modelaanroep. Door het volledige traject van een verzoek vast te leggen – van client naar service, van ophalen naar model naar tools – kunt u zien waar het gedrag is veranderd. Misschien levert het ophalen van gegevens minder documenten op, of mislukt een toolaanroep af en toe, en past het model zich daarop aan.
• Houd daarbij de aanwijzingen, de context en de reacties in gedachten. – Wanneer je prompts en reacties samen met traceringen kunt inspecteren, wordt het veel gemakkelijker om gevallen te vinden waarin een nieuwe promptversie, een nieuwe systeeminstructie of een nieuwe contextbron het gedrag heeft veranderd, zelfs als de latentie en foutpercentages hetzelfde zijn gebleven.
• Filteren en selecteren op basis van semantische voorwaarden Zodra je over uitgebreide LLM-telemetrie beschikt, kun je filteren op zaken als 'bedrock-aanroepen langer dan één seconde', 'verzoeken die gebruikmaken van deze modelfamilie' of 'traceringen met betrekking tot deze specifieke route'. Vervolgens kun je de prompts en reacties lezen om te zien of het model afwijkt of hallucineert in een specifiek scenario.
• Waarschuwingen over SLO's op bedrijfsniveau – U kunt SLO's definiëren zoals "elk LLM-gesprek van meer dan één seconde is een schending van onze gebruikers-SLA" en waarschuwingen activeren wanneer aan die voorwaarden wordt voldaan. Na verloop van tijd kunnen vergelijkbare SLO's worden gekoppeld aan kwaliteitsscores of beleidscontroles, zodat u een melding krijgt wanneer de kwaliteit verslechtert, en niet alleen wanneer de infrastructuur uitvalt.

Omdat de observatielaag toegang heeft tot zowel de AI-specifieke signalen als de klassieke logboeken, statistieken en traceringen, is het een natuurlijke plek om problemen op te sporen die anders ongemerkt de gebruikerservaring zouden verslechteren.

Hoe ondersteunt de aanpak van Groundcover het diagnosticeren van onvoorspelbare latentie of onverwacht gedrag binnen meerstaps agentworkflows en toolaanroepen?

Groundcover hanteert een aanpak die is ontworpen voor moderne AI-systemen. We gebruiken een op eBPF gebaseerde sensor op kernelniveau om het verkeer tussen microservices te observeren zonder codeaanpassingen of herimplementaties. Zodra u een LLM-workflow introduceert, kunnen we die aanroepen automatisch detecteren. Als u morgen een nieuw model zoals Anthropic, OpenAI of Bedrock gaat gebruiken, legt Groundcover dat verkeer automatisch vast. Dat levert u het volgende op:

• Volledige tracering van workflows met meerdere tussenstappen – Je ziet het volledige traject van een aanvraag door alle services heen, inclusief waar een LLM of tool wordt gebruikt.
• Diepgaande context bij elke LLM-oproep – Elk gesprek bevat informatie over het gebruikte model, de latentie, het tokengebruik, prompts, reacties en bijbehorende logboeken en infrastructuurstatistieken.
• Krachtige filtering op latentie en omstandigheden – U kunt bijvoorbeeld filteren op alle Claude 3.5-aanroepen die langer dan één seconde duren en direct de traceringen inspecteren die uw SLA hebben overschreden.
• Waarschuwingen en dashboards gekoppeld aan LLM-gedrag Zodra de gegevens beschikbaar zijn, kunt u waarschuwingen instellen voor schendingen van de SLA of dashboards bouwen die latentie, doorvoer, tokengebruik en fouten bijhouden.

Doordat alles aan de rand van het netwerk door eBPF wordt verzameld en in uw eigen cloud wordt opgeslagen, krijgt u dit zeer gedetailleerde overzicht zonder dat u instrumentatie hoeft toe te voegen aan elke agent- of toolaanroep.

Welke risico's op het gebied van gegevensbeveiliging en compliance ziet u ontstaan ​​bij LLM-implementaties, en hoe kan observability helpen om die risico's te verminderen?

LLM-implementaties brengen enkele unieke datarisico's met zich mee:

• Onbegrensde gebruikersinvoer Gebruikers kunnen uiterst gevoelige informatie invoeren in chatbots en AI-gestuurde interfaces. Dit kan persoonlijke gegevens, klantgegevens of gereguleerde informatie omvatten die u nooit had willen verzamelen.
• Aanbieders van modellen van derden – Zodra u die gegevens naar een externe LLM-aanbieder stuurt, bent u verantwoordelijk voor waar ze terechtkomen, hoe ze worden opgeslagen en welke subverwerkers erbij betrokken zijn. Dit heeft grote gevolgen voor de AVG, de verblijfplaats van gegevens en het vertrouwen van de klant.
• Telemetrie als tweede kopie van gevoelige gegevens Als uw observability-stack volledige payloads naar een SaaS-leverancier verzendt, hebt u nu nog een kopie van die gevoelige informatie buiten uw eigen omgeving.

De architectuur van de bodembedekking is ontworpen om precies aan die problemen tegemoet te komen:

• We hanteren een 'bring your own cloud'-model, waarbij de volledige observatie-backend binnen uw cloudaccount draait, in een subaccount, als een volledig beheerd dataplane. Het controleplane dat de schaalbaarheid en het beheer regelt, wordt door ons beheerd, maar wij hebben geen toegang tot uw telemetriegegevens, slaan deze niet op en verwerken ze niet.
• Omdat we gegevens veilig in uw eigen omgeving kunnen vastleggen, kunt u prompts, reacties en workflows observeren zonder dat die gegevens uw cloud ooit verlaten. Er is geen opslag van uw LLM-traceringen door derden en u hoeft zich geen zorgen te maken over extra gegevensuitvoer.
• Met dat inzicht kunt u zien wie wat uploadt en waar het naartoe stroomt, onverwacht gebruik van gevoelige gegevens detecteren en beleid afdwingen met betrekking tot welke modellen en regio's zijn toegestaan.

Met andere woorden: observeerbaarheid wordt niet alleen een instrument voor betrouwbaarheid en kostenbeheersing, maar ook een belangrijk controlepunt voor privacy, gegevensopslag en naleving van regelgeving.

Naarmate organisaties opschalen van één LLM-integratie naar meerdere AI-gestuurde services, welke operationele uitdagingen doen zich dan doorgaans voor op het gebied van zichtbaarheid, betrouwbaarheid en kosten?

De eerste integratie betreft meestal één model in één workflow. In dat stadium lijkt alles beheersbaar. Zodra teams de meerwaarde ervan inzien, explodeert het gebruik en duiken er diverse uitdagingen op:

• Wildgroei aan modellen en leveranciers – Teams testen voortdurend nieuwe modellen. Het wordt al snel onduidelijk welke modellen in productie zijn en hoe ze worden gebruikt.
• Kostenverrassingen door het gebruik van tokens Het tokenverbruik neemt toe met de lengte van de context en de complexiteit van de workflow. Zonder inzicht in het tokengebruik per model en workflow is het erg moeilijk om de kosten te beheersen.
• De betrouwbaarheid is afhankelijk van externe leveranciers. – Gebruikersgerichte API's worden gevoelig voor latentie of fouten in het model, wat de service level agreements (SLA's) kan verstoren, zelfs als de kerninfrastructuur in orde is.
• Toenemende schuld voor instrumentatie – Traditionele observability gaat ervan uit dat je instrumentatie kunt toevoegen wanneer dat nodig is. In snel veranderende AI-omgevingen hebben ontwikkelaars daar zelden tijd voor.

Groundcover pakt dit aan door automatisch AI-verkeer te detecteren en je vervolgens het volgende te bieden:

• Centraal inzicht in welke modellen en leveranciers worden gebruikt.
• Dashboards die de latentie, doorvoer en het tokengebruik in de loop van de tijd weergeven.
• Correlatie tussen LLM-gedrag en de diensten die ervan afhankelijk zijn.
• Waarschuwingen voor door AI veroorzaakte SLO-schendingen.

Dat maakt het veel gemakkelijker om op te schalen van "één coole AI-functie" naar "AI is verweven in tientallen cruciale diensten" zonder de controle te verliezen.

Hoe verwacht u dat de observeerbaarheid van LLM zich de komende vijf jaar zal ontwikkelen, nu agentische AI, multi-modelorkestratie en regelgevingsdruk toenemen?

We staan ​​nog maar aan het begin. De komende vijf jaar verwacht ik een aantal grote veranderingen:

• Van begrip op aanvraagniveau tot begrip op agentniveau – Observability zal worden uitgebreid om gereedschapssequenties, redeneerpaden en herhalingslogica vast te leggen, en niet alleen modelaanroepen.
• Rijkere semantische en beleidssignalen – Geautomatiseerde kwaliteitscontroles op hallucinaties, veiligheidsproblemen en merkconsistentie zullen standaard meetinstrumenten worden.
• Nauwere koppeling met governance en privacy. Naarmate de regelgeving toeneemt, zal observability ook dienen als een handhavings- en controlemechanisme voor de locatie, bewaring en het goedgekeurde gebruik van modellen van data.
• Optimalisatie over meerdere modellen en leveranciers – Teams zullen het verkeer dynamisch over de modellen verdelen op basis van prestaties en kosten, aangestuurd door realtime observatiegegevens.
• Minder handmatige instrumentatie – Technieken zoals eBPF-gebaseerde dataverzameling en automatische data-ontdekking worden de standaard, zodat teams kunnen blijven innoveren zonder vertraging.

Kortom, LLM-observabiliteit zal evolueren van "leuke dashboards voor AI" naar het centrale zenuwstelsel dat betrouwbaarheid, kostenbeheersing, gegevensbeheer en productkwaliteit verbindt in alles wat een organisatie met AI doet.

Bedankt voor het geweldige interview, lezers die meer willen weten, zouden moeten bezoeken bodembedekker.