Shahar Azulay, CEO og medstifter af groundcover

Shahar Azulay, CEO og medstifter af groundcover er en serie R&D-leder. Shahar bringer erfaring fra verden af cybersikkerhed og maskinlæring efter at have arbejdet som leder i virksomheder som Apple, DayTwo og Cymotive Technologies. Shahar tilbragte mange år i Cyber-afdelingen i det israelske premierministers kontor og har tre uddannelser i fysik, elektroteknik og datalogi fra Technion Israel Institute of Technology samt Tel Aviv University. Shahar stræber efter at bruge tekniske erfaringer fra denne rige baggrund og bringe det til i dagens cloud-native slagmark i den skarpeste, mest innovative form for at gøre verden af dev en bedre place.

groundcover er en cloud-native observability-platform designet til at give udviklingsteams fuld, real-time indsigt i deres systemer uden kompleksiteten eller omkostningerne ved traditionelle overvågningsværktøjer. Bygget på eBPF-teknologi, indsamler og korrelerer den logs, metrics, spor og begivenheder på tværs af cloud-native og Kubernetes-miljøer uden kodeændringer, hvilket muliggør hurtigere rodårsagsanalyse og klarere systemindsigt. Platformen fremhæver forudsigelige priser, fleksible installationer, der holder data i kundens cloud, og slut-til-slut-observability, der omfatter infrastruktur, applikationer og moderne AI-drevne workloads.

Se tilbage på din rejse – fra at lede cyber R&D-hold i det israelske premierministers kontor til at styre ML-initiativer hos Apple – hvilke erfaringer førte dig til at grundlægge groundcover, og hvornår fik du først indsigt i hullerne i observability for moderne AI-systemer?

Impulsen til at grundlægge groundcover kom fra min tid hos Apple og DayTwo. Selv med enorme budgetter var vi fastlåst i valget mellem at betale en formue for at logge alt eller at sample og flyve blindt. Dengang ledte vi efter en teknologi, der ville løse det. Så snart vi stødte på Extended Berkeley Packet Filter (eBPF), var det klart, at det ville ændre alt. eBPF giver os mulighed for at se alt, der sker i kernelen uden at afhænge af ændringer i applikationen. Jeg kunne ikke forstå, hvorfor overvågningsværktøjer ikke udnyttede det. Hullerne i AI blev klare senere. Da vores Kubernetes-platform modned, så vi kunder, der styrtede ind i GenAI-udrulninger, mens de behandlede LLM’er som sorte kasser. De vidste, at modellen svarede, men ikke hvorfor den opførte sig uforudsigeligt eller hvorfor omkostningerne steg. Vi indså, at agente-workflows er komplekse, ikke-deterministiske mikrotjenester, der kræver den samme zero-touch indsigt, vi allerede havde bygget.

Hvordan har din baggrund i cybersikkerhed, indlejrede systemer og maskinlæring R&D påvirket visionen bag groundcover, og hvilke tidlige udfordringer mødte du, da du byggede en virksomhed, der er centreret om observability for LLM-drevne og agente-applikationer?

Min cyber-baggrund formede virksomhedens DNA. I efterretningens verden antager man, at man ikke kontrollerer applikationen. Den tilgang er årsagen til, at groundcover ikke kræver instrumentation. Jeg ved fra erfaring, at at bede udviklere om at ændre kode er den hurtigste måde at blokere adoption på. Den største tidlige udfordring med LLM-overvågning var privatliv. Overvågning af AI fanger prompts, der kan indeholde følsomme personlige oplysninger eller IP. Min baggrund gjorde det åbenlyst, at virksomheder ikke ville have, at den data forlod deres miljø. Derfor byggede vi vores in-cloud-arkitektur, der giver os mulighed for at give dyb indsigt i agentadfærd, mens alle data holdes inden for kundens eget miljø.

Hvordan definerer du LLM-observability, og hvad gør det anderledes end traditionel overvågning eller ML-overvågning?

LLM-observability er praksis med at instrumentere og overvåge produktionsystemer, der bruger store sprogmodeller, så du kan fange den fulde kontekst af hver slutning: prompten, konteksten, afslutningen, token-brug, latency, fejl, model-metadata og idealiseret downstream-feedback eller kvalitetssignaler. I stedet for kun at spørge “Er tjenesten oppe og hurtig?” eller “Fejlede denne anmodning?”, hjælper LLM-observability dig med at besvare spørgsmål som “Hvorfor lykkedes eller mislykkedes denne bestemte anmodning?” og “Hvad skete der egentlig inde i denne multi-trins workflow?” Det er meget anderledes end traditionel overvågning eller klassisk ML-overvågning. Arbejdsmetoder er tilpasset deterministiske systemer, infrastruktur-metrics og statiske grænseværdier. LLM-applikationer er ikke-deterministiske, åbne og højst kontekstafhængige. Succes er ofte semantisk og subjektiv, ikke kun en 200 vs 500 statuskode. Det betyder, at du må spore inputs og outputs, forstå værktøjskald og hentningssteg, evaluere svar på ting som hallucinationer eller politikovertrædelser og tilbageforbinde token-omkostninger og forsinkelser til den omgivende applikation og infrastruktur.

Hvilke udfordringer introducerer LLM-drevne applikationer, der gør traditionelle overvågningsværktøjer utilstrækkelige?

LLM-systemer introducerer flere udfordringer, der afslører begrænsningerne i traditionelle værktøjer:

• Komplekse, multi-trins workflows – Vi er gået fra simple “kalde en model, få et svar” til multi-trins-agenter, multi-trins-rørledninger, hentningsforstærket generation og værktøjsbrug. En silent fejl i nogen af disse trin, såsom hentning, berigelse, indlejring, værktøjskald eller modelkald, kan ødelægge hele oplevelsen. Traditionel overvågning giver dig normalt ikke en fuldstændig, spor-niveau-oversigt over disse kæder med prompts og svar inkluderet.
• Hurtigt udviklende AI-stacks – Hold tilføjer nye modeller, værktøjer og leverandører i en takt, de aldrig har set før. I mange virksomheder kan ingen med sikkerhed liste, hvilke modeller der er i produktion på et given tidspunkt. Klassisk overvågning antager, at du har tid til at instrumentere SDK’er, genudgive og omhyggeligt kuraterer, hvad du måler. Det holder simpelthen ikke trit med, hvor hurtigt AI bliver antaget.
• Token-baseret økonomi og kvoter – Priser og rategrænser er knyttet til tokens og kontekstlængde, der ofte kontrolleres af udviklere, prompts eller brugeradfærd, ikke af central ops. Traditionelle værktøjer er ikke bygget til at vise dig “hvem brændte hvor mange tokens på hvilken model, for hvilken workflow, på hvilken latency”.
• Semantisk korrekthed i stedet for binær succes – En LLM kan returnere en 200 og stadig hallucinere, drage væk fra din prompt eller krænke politik. Traditionelle værktøjer ser det som en succes. Du har brug for overvågning, der kan fremhæve prompts og svar og give dig nok kontekst til at inspicere adfærd og over tid indsætte automatiserede kvalitetskontroller.
• Følsomme inputdata, der flyder ind i tredjeparter – LLM’er inviterer brugere til at dele meget følsomme oplysninger gennem chat-lignende grænseflader. Nu er du ansvarlig for den data, hvor den gemmes og hvilke underleverandører ser den. Konventionel SaaS-baseret overvågning, der sender alle telemetrier til en tredjepart, er ofte uacceptabel for disse workloads.

Alt dette betyder, at LLM-systemer kræver overvågning, der er AI-bevidst, kontekstrig og langt mindre afhængig af manuel instrumentation end de værktøjer, de fleste hold bruger i dag.

Hvilke signaler eller metrics er mest vigtige for at forstå præstationen og kvaliteten af LLM-systemer, herunder latency, token-brug og prompt/svaradfærd?

Der er nogle kategorier af signaler, der betyder en del i praksis:

Latency og gennemstrømning

• Ende-til-ende-latency per anmodning, herunder modeltid og omgivende applikationstid.
• Tail-latencyer (P90, P95, P99) per model og per workflow.
• Gennemstrømning per model, rute og tjeneste, så du ved, hvor belastningen virkelig går.

Token-brug og omkostningsfaktorer

• Input- og output-tokens per anmodning, opdelt efter model.
• Sammenslået token-brug over tid per model, hold, bruger og workflow.
• Kontekststørrelser for hentningsintensive rørledninger, så du kan se, når prompts eksploderer.
• Dette er, hvad der giver dig mulighed for at svare på “Hvem bruger virkelig vores AI-budget, og på hvad?”

Prompt og svaradfærd

• De faktiske prompt- og svar-nytter på repræsentative spor, herunder værktøjskald og resoneringsspor.
• Hvilke værktøjer LLM’en valgte at kalde og i hvilken rækkefølge.
• Varians i svar for lignende prompts, så du kan se, hvor stabil adfærden er.

Pålidelighed og fejl

• Model-specifikke fejlrater og typer (leverandørfejl, timeout, auth-problemer, kvote-fejl).
• Fejl i den omgivende workflow, såsom værktøjs-timeouts eller hentningsfejl, korreleret med LLM-kaldet.

Klassisk infra-kontekst

• Container CPU, hukommelse og netværksmetrics for tjenesterne, der orkestrerer dine LLM-kald.
• Korrelerede logs, der beskriver, hvad applikationen prøvede at gøre.

Når du kan se alt dette på et sted, flytter LLM-overvågning sig fra “Jeg ved, noget er langsomt eller dyrt” til “Jeg ved præcis, hvilken model, prompt-mønster og tjeneste er ansvarlig, og hvorfor”.

Hvordan kan overvågning hjælpe hold med at opdage silent fejl, såsom prompt-drift, hallucinationer eller gradvis nedgang i outputkvalitet?

Silent fejl i LLM-systemer sker normalt, når alt ser “grønt” på infrastruktur-niveau, men den faktiske adfærd er drænet. Overvågning hjælper på flere måder:

• Spore hele workflowet, ikke kun modelkaldet – Ved at fange hele stien for en anmodning fra klient til tjeneste til hentning til model til værktøjer kan du se, hvor adfærden ændrede sig. For eksempel kunne hentning have startet med at returnere færre dokumenter, eller et værktøjskald kunne være intermitterende fejl, og modellen improviserede.
• Holde prompts, kontekst og svar i sigte – Når du kan inspicere prompts og svar sammen med spor, bliver det meget lettere at spotte tilfælde, hvor en ny prompt-version, en ny system-instruktion eller en ny kontekstkilde ændrede adfærden, selvom latency og fejlrater forblev de samme.
• Filtrere og skære på semantiske betingelser – Når du har rig LLM-telemetri, kan du filtrere ned til ting som “bedrock-kald over en sekund”, “anmodninger, der bruger denne model-familie” eller “spor, der involverer denne bestemte rute”, og derefter læse prompts og svar for at se, om modellen dræner eller hallucinerer i en bestemt situation.
• Alarmere på forretningsniveau SLO’er – Du kan definere SLO’er som “enhver LLM-anmodning over en sekund krænker vores bruger-tilgængelige SLA” og udløse alarm, når disse betingelser er opfyldt. Over tid kan lignende SLO’er kobles til kvalitetsscores eller politikkontroller, så du får alarm, når kvaliteten forringes, ikke kun når infrastruktur fejler.

Fordi overvågningslaget har adgang til både AI-specifikke signaler og klassiske logs, metrics og spor, bliver det en naturlig placering til at fange problemer, der ellers ville nedgraderes stille.

Hvordan supporterer groundcovers tilgang diagnosticering af uforudsigelig latency eller uventet adfærd inden for multi-trins agent-workflows og værktøjskald?

groundcover tager en tilgang designet til moderne AI-systemer. Vi bruger en eBPF-baseret sensor på kernel-niveau til at observere trafik på tværs af mikrotjenester uden kodeændringer eller genudgivelser. Så snart du introducerer en LLM-workflow, kan vi auto-opdage disse kald. Hvis du starter med at bruge en ny model som Anthropic, OpenAI eller Bedrock i morgen, fanger groundcover automatisk denne trafik. Det giver dig:

• Ende-til-ende-spor af multi-hop-workflows – Du ser den fulde sti for en anmodning på tværs af tjenester, herunder hvor en LLM eller værktøj bruges.
• Dybt kontekst på hvert LLM-kald – Hvert kald inkluderer den brugte model, latency, token-brug, prompts, svar og korrelerede logs og infra-metrics.
• Kraftfuld filtrering på latency og betingelser – For eksempel kan du filtrere alle Claude 3.5-kald over en sekund og straks inspicere spor, der krænker din SLA.
• Alarm og dashboards knyttet til LLM-adfærd – Når data er tilgængelige, kan du oprette alarm for SLA-krænkelser eller bygge dashboards, der sporer latency, gennemstrømning, token-brug og fejl.

Fordi alt er indsamlet på kanten af eBPF og gemt i din egen cloud, får du denne høj-granularitet-oversigt uden at tilføje instrumentation inde i hver agent eller værktøjskald.

Hvilke data-sikkerheds- og compliance-risici ser du opstå i LLM-udrulninger, og hvordan kan overvågning hjælpe med at reducere disse risici?

LLM-udrulninger medfører nogle unikke data-risici:

• Ubundet bruger-input – Brugere kan taste ekstremt følsomme oplysninger ind i chat-bots og AI-drevne grænseflader. Det kan inkludere personlige data, kunde-data eller regulerede oplysninger, du aldrig havde til hensigt at indsamle.
• Tredjeparts-model-leverandører – Når du sender den data til en ekstern LLM-leverandør, er du ansvarlig for, hvor den går, hvordan den gemmes og hvilke underleverandører er involveret. Det har store implikationer for GDPR, data-residens og kunde-tillid.
• Telemetri som en anden kopi af følsomme data – Hvis din overvågnings-stack sender fulde nyttelaster til en SaaS-leverandør, har du nu en anden kopi af disse følsomme oplysninger uden for dit miljø.

groundcovers arkitektur er designet til at adressere netop disse bekymringer:

• Vi bruger en bring-your-own-cloud-model, hvor den fulde overvågnings-backend kører inden for din cloud-konto, i en underkonto, som en fuldt administreret dataplane. Kontrolplanet, der skalerer og administrerer det, køres af os, men vi har ikke adgang til, gemmer eller behandler din telemetri-data.
• Fordi vi kan fange nyttelaster sikkert i dit eget miljø, kan du overvåge prompts, svar og workflows uden, at data forlader din cloud. Der er ingen tredjeparts-lagring af dine LLM-spor og ingen ekstra data-egress at bekymre sig om.
• Med denne indsigt kan du se, hvem der uploader hvad og hvor det flyder, og du kan opdage uventet brug af følsomme data og gennemtvinge politikker omkring, hvilke modeller og regioner der er tilladt.

Med andre ord bliver overvågning ikke kun et værktøj til pålidelighed og omkostningskontrol, men også et nøglekontrolpunkt for privatliv, data-residens og compliance.

Når organisationer skalerer fra en LLM-integration til mange AI-drevne tjenester, hvilke operationelle udfordringer dukker op omkring synlighed, pålidelighed og omkostninger?

Den første integration er normalt en enkelt model i en enkelt workflow. På det tidspunkt føles det håndterbart. Så snart hold ser værdien, eksploderer brugen, og flere udfordringer dukker op:

• Model- og leverandør-sprawl – Hold tester nye modeller konstant. Det bliver hurtigt uklart, hvilke modeller der er i produktion og hvordan de bruges.
• Omkostnings-overraskelser fra token-brug – Token-forbrug vokser med kontekstlængde og workflow-kompleksitet. Uden indsigt i token-brug per model og workflow er det svært at styre omkostninger.
• Pålidelighedsafhængighed af eksterne leverandører – Bruger-tilgængelige API’er bliver følsomme over for model-latency eller fejl, der kan afbryde SLA’er, selv når kerne-infrastrukturen er sund.
• Voksende instrumentation-gæld – Traditionel overvågning antager, at du kan tilføje instrumentation, når det er nødvendigt. I hurtigt udviklende AI-stacks har udviklere sjældent tid til det.

groundcover adresserer disse ved at auto-opdage AI-trafik og derefter give dig:

• Central synlighed i, hvilke modeller og leverandører der bruges.
• Dashboards, der viser latency, gennemstrømning og token-brug over tid.
• Korrelation mellem LLM-adfærd og de tjenester, der afhænger af det.
• Alarm for AI-drevne SLO-krænkelser.

Det gør det meget lettere at skalerer fra “en cool AI-funktion” til “AI er vævet ind i dusinvis af kritiske tjenester” uden at miste kontrollen.

I fremtiden, hvordan forventer du, at LLM-overvågning vil udvikle sig over de næste fem år, mens agente-AI, multi-model-orchestration og regulerings-pres udvikler sig?

Vi er stadig i de tidlige dage. Over de næste fem år forventer jeg nogle store skift:

• Fra anmodningsniveau til agentniveau-forståelse – Overvågning vil udvide sig til at fange værktøjssekvenser, resoneringsspor og retry-logik, ikke kun modelkald.
• Rigere semantiske og politik-signaler – Automatiserede kvalitetskontroller for hallucinationer, sikkerhedsproblemer og brand-sammenligning vil blive standard-metrics.
• Tættere kobling til governance og privatliv – Da regulering vokser, vil overvågning også fungere som en gennemførelse- og revisionslag for data-residens, opbevaring og godkendt model-brug.
• Optimering på tværs af modeller og leverandører – Hold vil route-trafik på tværs af modeller dynamisk baseret på præstation og omkostning, guidet af real-time overvågningsdata.
• Mindre manuel instrumentation – Teknikker som eBPF-baseret indsamling og auto-opdagelse vil blive standard, så hold kan innovere uden at sakke.

I kort sagt vil LLM-overvågning udvikle sig fra “rart at have dashboards for AI” til det centrale nervesystem, der forbinder pålidelighed, omkostningskontrol, data-governance og produktkvalitet på tværs af alt, en organisation gør med AI.

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