Shahar Azulay, CEO og medgrunnlegger av groundcover

Shahar Azulay, CEO og medgrunnlegger av groundcover er en serial R&D-leder. Shahar bringer erfaring fra verden av cybersikkerhet og maskinlæring, etter å ha arbeidet som leder i selskaper som Apple (AAPL ), DayTwo og Cymotive Technologies. Shahar tilbrakte mange år i Cyber-divisjonen i det israelske statsministerens kontor og har tre grader i fysikk, elektroingeniør og datavitenskap fra Technion Israel Institute of Technology samt Tel Aviv University. Shahar streber etter å bruke tekniske kunnskaper fra denne rike bakgrunnen og bringe det til i dagens cloud-native slagmark i den skarpeste, mest innovative formen for å gjøre verden av dev en bedre plass.

groundcover er en cloud-native observabilitetsplattform designet for å gi ingeniørteam full, sanntidsvisning av deres systemer uten kompleksiteten eller kostnadene til tradisjonelle overvåkingsverktøy. Bygget på eBPF-teknologi, samler den inn og korrelerer logger, målinger, spor og hendelser over cloud-native- og Kubernetes-miljøer uten kodeendringer, og muliggjør raskere årsaksanalyse og tydeligere systeminnsikt. Plattformen legger vekt på forutsigbar prising, fleksibel distribusjon som holder data i kundens sky, og sluttpunkt-til-sluttpunkt-observabilitet som omfatter infrastruktur, applikasjoner og moderne AI-drevne arbeidsbelastninger.

Se tilbake på din reise – fra å lede cyber R&D-team i det israelske statsministerens kontor til å håndtere ML-initiativer i Apple – hva erfaringer førte til at du grunnla groundcover, og når oppdaget du gapet i observabilitet for moderne AI-systemer?

Pådrivet til å grunnlegge groundcover kom fra min tid i Apple og DayTwo. Selv med enorme budsjetter, var vi fanget mellom å betale en formue for å logge alt eller å prøve og fly blindt. Da lette vi etter en teknologi som ville løse det. Så snart vi møtte Extended Berkeley Packet Filter (eBPF), var det klart at det ville endre alt. eBPF lar oss se alt som skjer i kjernen uten å avhenge av applikasjonsendringer. Jeg kunne ikke forstå hvorfor overvåkingsverktøy ikke tok fordel av det. Gapet i AI ble klart senere. Så snart vår Kubernetes-plattform moden, så vi kunder som ruslet inn i GenAI-utrolleringer mens de behandlet LLM-er som svarte bokser. De visste at modellen svarte, men ikke hvorfor den oppførte seg uforutsigbart eller hvorfor kostnadene skjøt i været. Vi innsett at agens-arbeidsflyter er komplekse, ikke-deterministiske mikrotjenester som trenger samme null-berøringsvisning vi allerede hadde bygget.

Hvordan påvirkede din bakgrunn i cybersikkerhet, innebygde systemer og maskinlæring R&D visjonen bak groundcover, og hva tidlige utfordringer møtte du da du bygde et selskap sentrert på observabilitet for LLM-drevne og agens-applikasjoner?

Min cyber-bakgrunn formet selskapets DNA. I etterretningens verden antar du at du ikke kontrollerer applikasjonen. Den tilnærmingen er hvorfor groundcover ikke krever instrumentering. Jeg vet fra erfaring at å be utviklere om å modifisere kode er den raskeste måten å blokkere adopsjon på. Den hardeste tidlige utfordringen med LLM-overvåking var personvern. Observabilitet for AI fanger opp promter som kan inneholde sensitive PII eller IP. Min bakgrunn gjorde det åpenbart at bedrifter ikke ville ha den dataene forlate deres miljø. Derfor bygde vi vår in-cloud-arkitektur, som lar oss gi dypt innsikt i agent-atferd mens alle data holdes inne i kundens eget miljø.

Hvordan definerer du LLM-observabilitet, og hva gjør den forskjellig fra tradisjonell overvåking eller ML-overvåking?

LLM-observabilitet er praksisen med å instrumentere og overvåke produksjonssystemer som bruker store språkmodeller så du kan fange full kontekst av hver inferens: prompten, konteksten, fullføringen, token-bruken, forsinkelsen, feilene, modellmetadataene og ideal sett nedstrøms tilbakemelding eller kvalitetssignaler. I stedet for bare å spørre “Er tjenesten oppe og rask?” eller “Feilet denne forespørselen?”, hjelper LLM-observabilitet deg å svare på spørsmål som “Hvorfor lyktes eller feilet denne bestemte forespørselen?”, “Hva skjedde egentlig inne i denne flertrinns-arbeidsflyten?” og “Hvordan påvirker endringer i promter, kontekst eller modellversjoner kostnaden, forsinkelsen og utgangskvaliteten?” Dette er svært forskjellig fra tradisjonell overvåking eller klassisk ML-overvåking. Arvete tilnærming er avstemt for deterministiske systemer, infrastruktur-målinger og statiske terskler. LLM-applikasjoner er ikke-deterministiske, åpne og høyt kontekst-avhengige. Suksess er ofte semantisk og subjektiv, ikke bare en 200 vs 500 statuskode. Det betyr at du må spore inn- og ut-data, forstå verktøksamtaler og hentingstrinn, evaluere svar for ting som hallusinasjoner eller politikkbrudd, og koble token-nivå-kostnader og forsinkelser tilbake til den omgivende applikasjonen og infrastrukturen.

Hva utfordringer introduserer LLM-drevne applikasjoner som gjør tradisjonelle overvåkingsverktøy utilstrekkelige?

LLM-drevne systemer introduserer flere utfordringer som avslører grensene for tradisjonelle verktøy:

• Komplekse, flertrinns-arbeidsflyter – Vi har flyttet fra enkle “ring en modell, få et svar” -flyter til flertrinns-agenter, flertrinns-pipelines, henting-forsterket generering og verktøysbruk. En stille feil i noen av disse trinnene, som henting, beriking, innkapsling, verktøksamtale eller modellkall, kan bryte hele opplevelsen. Tradisjonell overvåking gir vanligvis ikke en fullstendig, spor-nivå-oversikt over disse kjedene med promter og svar inkludert.
• Raskt utviklende AI-staker – Teamene legger til nye modeller, verktøy og leverandører i en takt de aldri har sett før. I mange selskaper kan ingen med sikkerhet liste opp hvilke modeller som er i produksjon på et gitt øyeblikk. Klassisk overvåking antar at du har tid til å instrumentere SDK-er, gjøre omhyggelige kureringer og målinger. Det holder bare ikke tritt med hvor raskt AI blir adoptert.
• Token-basert økonomi og kvoter – Prising og ratelimiter er knyttet til token og kontekstlengde, som ofte kontrolleres av utviklere, promter eller brukeratferd, ikke av sentral drift. Tradisjonelle verktøy er ikke bygget for å vise deg “hvem brente hvor mange token på hvilken modell, for hvilken arbeidsflyt, på hvilken forsinkelse”.
• Semantisk korrekthet i stedet for binær suksess – En LLM kan returnere en 200 og likevel hallusinere, gli vekk fra din prompt eller bryte politikk. Tradisjonelle verktøy ser på det som en suksess. Du trenger overvåking som kan fremheve promter og svar og gi deg nok kontekst til å inspisere atferd og over tid plugge i automatiserte kvalitetskontroller.
• Følsomme inndata som flyter inn i tredjeparter – LLM-er inviterer brukerne til å dele svært følsomme opplysninger gjennom chat-lignende grensesnitt. Nå er du ansvarlig for den dataen, hvor den lagres og hvilke underleverandører som ser den. Konvensjonell SaaS-basert overvåking som sender all telemetri til en tredjepart er ofte uakseptabel for disse arbeidsbelastningene.

Alt dette betyr at LLM-systemer krever overvåking som er AI-bevisst, kontekst-rik og langt mindre avhengig av manuell instrumentering enn de verktøyene de fleste teamene bruker i dag.

Hvilke signaler eller målinger er viktigst for å forstå ytelsen og kvaliteten til LLM-systemer, inkludert forsinkelse, token-bruk og prompt/svar-atferd?

Det finnes noen kategorier av signaler som betyr mye i praksis:

Forsinkelse og gjennomstrømming

• Ende-til-ende-forsinkelse per forespørsel, inkludert modelltid og omgivende applikasjons tid.
• Hale-forsinkelser (P90, P95, P99) per modell og per arbeidsflyt.
• Gjennomstrømming per modell, rute og tjeneste, så du vet hvor lasten faktisk går.

Token-bruk og kostnadsdrivere

• Inndata- og utdatatoken per forespørsel, oppdelt etter modell.
• Sammenslått token-bruk over tid per modell, team, bruker og arbeidsflyt.
• Kontekst-størrelser for henting-tyngde-pipelines så du kan se når promter eksploderer.
• Dette er hva som lar deg svare “Hvem bruker egentlig vår AI-budsjett og på hva?”

Prompt- og svar-atferd

• De faktiske prompt- og svar-nyttelastene på representative spor, inkludert verktøksamtaler og resoneringsspor.
• Hvilke verktøy LLM-en valgte å ringe og i hvilken rekkefølge.
• Varians i svar for lignende promter så du kan se hvor stabilt atferden er.

Pålitelighet og feil

• Modell-spesifikke feilrater og typer (leverandørfeil, tidsavbrudd, autentiseringsfeil, kvote-feil).
• Feil i den omgivende arbeidsflyten, som verktøks-tidsavbrudd eller hentingsfeil, korrelert med LLM-kallet.

Klassisk infra-kontekst

• Container-CPU, minne og nettverks-målinger for tjenestene som orkestrerer dine LLM-kall.
• Korrelerte logger som beskriver hva applikasjonen prøvde å gjøre.

Når du kan se alt dette på ett sted, flytter LLM-overvåking fra “Jeg vet noe er langsomt eller dyrt” til “Jeg vet nøyaktig hvilken modell, prompt-mønster og tjeneste er ansvarlig og hvorfor”.

Hvordan kan overvåking hjelpe team å oppdage stille feil som prompt-drift, hallusinasjoner eller gradvis forverring av utgangskvalitet?

Stille feil i LLM-systemer skjer vanligvis når alt ser “grønt” ut på infra-nivå, men den faktiske atferden er i ferd med å endre seg. Overvåking hjelper på noen måter:

• Sporing av hele arbeidsflyten, ikke bare modellkallet – Ved å fange hele banen av en forespørsel fra klient til tjeneste til henting til modell til verktøy, kan du se hvor atferden endret seg. For eksempel, kanskje henting begynte å returnere færre dokumenter, eller en verktøksamtale er intermittent feil, og modellen improviserer.
• Behold promter, kontekst og svar i visning – Når du kan inspisere promter og svar sammen med spor, blir det mye enklere å spore tilfeller hvor en ny prompt-versjon, en ny system-instruks eller en ny kontekst-kilde endret atferden, selv om forsinkelsen og feilraten forble uendret.
• Filtrering og skjæring på semantiske betingelser – Når du har rik LLM-telemetri, kan du filtrere ned til ting som “bedrock-kall over ett sekund”, “forespørsler som bruker denne modell-familien” eller “spor som involverer denne bestemte ruten”, og deretter lese promter og svar for å se om modellen drifter eller hallusinerer i en bestemt scenario.
• Varsling på forretnings-nivå SLO-er – Du kan definere SLO-er som “enhver LLM-forespørsel over ett sekund bryter vår bruker-tilgjengelige SLA” og utløse varslinger når disse betingelsene er møtt. Over tid kan lignende SLO-er knyttes til kvalitetspoeng eller politikk-sjekker, så du får varslet når kvaliteten forverres, ikke bare når infrastrukturen feiler.

Fordi overvåkingslaget har tilgang til både AI-spesifikke signaler og klassiske logger, målinger og spor, blir det en naturlig plass til å fange problemer som ellers ville forverre brukeropplevelsen stille.

Hvordan støtter groundcovers tilnærming diagnostisering av uforutsigbar forsinkelse eller uventet atferd i flertrinns-agents-arbeidsflyter og verktøksamtaler?

groundcover tar en tilnærming designet for moderne AI-systemer. Vi bruker en eBPF-basert sensor på kernel-nivå for å observere trafikk over mikrotjenester uten kodeendringer eller om-distribusjoner. Så snart du introduserer en LLM-arbeidsflyt, kan vi auto-opdage disse kallene. Hvis du starter å bruke en ny modell som Anthropic, OpenAI eller Bedrock i morgen, fanger groundcover automatisk denne trafikken. Det gir deg:

• Ende-til-ende-spor av flerhops-arbeidsflyter – Du ser hele banen av en forespørsel over tjenester, inkludert hvor en LLM eller verktøy brukes.
• Dyp kontekst på hver LLM-kall – Hvert kall inkluderer modellen brukt, forsinkelsen, token-bruken, promter, svar og korrelerte logger og infra-målinger.
• Kraftig filtrering på forsinkelse og betingelser – For eksempel kan du filtrere for alle Claude 3.5-kall over ett sekund og umiddelbart inspisere spor som brøt din SLA.
• Varslinger og dashboards knyttet til LLM-atferd – Når dataene er tilgjengelige, kan du opprette varslinger for SLA-brudd eller bygge dashboards som sporer forsinkelse, gjennomstrømming, token-bruk og feil.

Fordi alt blir samlet inn på kanten av eBPF og lagret i din egen sky, får du denne høyt granulerte visningen uten å legge til instrumentering inne i hver agent eller verktøksamtale.

Hva data-sikkerhets- og retningslinje-risiko ser du oppstå i LLM-utrolleringer, og hvordan kan overvåking hjelpe med å redusere disse risikoene?

LLM-utrolleringer bringer noen unike data-risiko:

• Ubundet bruker-inndata – Brukere kan skrive ekstremt følsomme opplysninger i chat-bots og AI-drevne grensesnitt. Det kan inkludere personlige data, kunde-data eller regulerte opplysninger som du aldri mente å samle inn.
• Tredjeparts-modell-leverandører – Når du sender den dataen til en ekstern LLM-leverandør, er du ansvarlig for hvor den går, hvordan den lagres og hvilke underleverandører som er involvert. Det har store implikasjoner for GDPR, data-bosetting og kunde-tillit.
• Telemetri som en andre-kopi av følsomme data – Hvis din overvåkings-stack sender full nyttelast til en SaaS-leverandør, har du nå en annen kopi av den følsomme informasjonen som ligger utenfor din kontroll.

groundcovers arkitektur er designet for å møte nettopp disse bekymringene:

• Vi bruker en “bring din egen sky”-modell hvor hele overvåkings-bakenden kjører inne i din sky-konto, i en underkonto, som en fullt administrert dataplane. Kontrollplanet som skalerer og administrerer det, kjøres av oss, men vi har ikke tilgang til, lagrer eller prosesserer din telemetri-data.
• Fordi vi trygt kan samle inn nyttelaster i din egen miljø, kan du overvåke promter, svar og arbeidsflyter uten at dataene noen gang forlater din sky. Det finnes ingen tredjeparts-lagring av dine LLM-spor og ingen ekstra data-egress å bekymre deg for.
• Med denne visningen kan du se hvem som laster opp hva og hvor det flyter, oppdage uventet bruk av følsomme data og påtvinge politikker rundt hvilke modeller og regioner som er tillatt.

Med andre ord blir overvåking ikke bare et pålitelighets- og kost-verktøy, men også et nøkkelkontrollpunkt for personvern, data-bosetting og retningslinjer.

Når organisasjoner skalerer fra én LLM-integrasjon til mange AI-drevne tjenester, hva slags operative utfordringer dukker vanligvis opp rundt visning, pålitelighet og kost?

Den første integrasjonen er vanligvis én modell i én arbeidsflyt. På det stadiet føles ting håndterbare. Så snart teamene ser verdien, eksploderer bruken og flere utfordringer dukker opp:

• Modell- og leverandør-sprening – Teamene tester nye modeller konstant. Det blir raskt uklart hvilke modeller som er i produksjon og hvordan de brukes.
• Kost-overraskelser fra token-bruk – Token-forbruket øker med kontekst-lengde og arbeidsflyt-kompleksitet. Uten visning av token-bruk per modell og arbeidsflyt, er det vanskelig å håndtere kostnader.
• Pålitelighets-avhengighet av eksterne leverandører – Bruker-tilgjengelige API-er blir følsomme for modell-forsinkelse eller feil, som kan forstyrre SLA-er selv om core-infrastrukturen er sunn.
• Økende instrumenterings-gjeld – Tradisjonell overvåking antar at du kan legge til instrumentering når det er nødvendig. I raskt bevegende AI-staker har utviklere sjelden tid til det.

groundcover møter disse ved å auto-opdage AI-trafikk og deretter gi deg:

• Sentral visning av hvilke modeller og leverandører som brukes.
• Dashboards som viser forsinkelse, gjennomstrømming og token-bruk over tid.
• Korrelasjon mellom LLM-atferd og tjenestene som avhenger av det.
• Varslinger for AI-drevne SLO-brudd.

Det gjør det mye enklere å skale fra “én kule AI-funksjon” til “AI er innvevd i dusinvis av kritiske tjenester” uten å miste kontrollen.

Ser fremover, hvordan forventer du at LLM-overvåking vil utvikle seg de neste fem årene mens agens-AI, multi-modell-orkesering og reguleringstrykk akselerer?

Vi er fortsatt i de tidlige dagene. Over de neste fem årene forventer jeg noen store endringer:

• Fra forespørsels-nivå til agent-nivå-forståelse – Overvåking vil utvides for å fange verktøyssekvenser, resoneringsspor og retry-logikk, ikke bare modellkall.
• Rikere semantiske og politiske signaler – Automatiserte kvalitetskontroller for hallusinasjoner, sikkerhetsproblemer og merkevare-sammenfall vil bli standard-målinger.
• Tettere kobling med styring og personvern – Ettersom regulering vokser, vil overvåking også tjene som en gjennomførings- og revisjonslag for data-bosetting, -lagring og -godkjenning.
• Flere modell-, multi-leverandør-optimering – Teamene vil rute-trafikk over modeller dynamisk basert på ytelse og kost, ledet av sanntids-overvåkingsdata.
• Mindre manuell instrumentering – Teknikker som eBPF-basert innhenting og auto-opdaging vil bli standard, så teamene kan innovere uten å sakke ned.

Kort sagt vil LLM-overvåking utvikle seg fra “nice-to-have-dashboards for AI” til det sentrale nervesystemet som kobler pålitelighet, kostkontroll, data-styring og produktkvalitet over alt et selskap gjør med AI.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke groundcover.