Shahar Azulay, administrerende direktør og medgründer av groundcover

Shahar Azulay, Administrerende direktør og medgründer av Groundcover er en serieleder innen forskning og utvikling. Shahar har erfaring fra cybersikkerhet og maskinlæring, etter å ha jobbet som leder i selskaper som Apple, DayTwo og Cymotive Technologies. Shahar tilbrakte mange år i cyberavdelingen ved den israelske statsministerens kontor og har tre grader i fysikk, elektroteknikk og informatikk fra Technion Israel Institute of Technology samt Tel Aviv University. Shahar streber etter å bruke teknologisk lærdom fra denne rike bakgrunnen og bringe den til dagens skybaserte slagmark i den skarpeste og mest innovative formen for å gjøre utviklingsverdenen til et bedre sted.

bunndekke er en skybasert observasjonsplattform som er utviklet for å gi ingeniørteam full sanntidsinnsikt i systemene sine uten kompleksiteten eller kostnadene ved tradisjonelle overvåkingsverktøy. Bygget på eBPF-teknologi, samler og korrelerer den logger, målinger, spor og hendelser på tvers av skybaserte og Kubernetes-miljøer uten kodeendringer, noe som muliggjør raskere rotårsaksanalyse og tydeligere systeminnsikt. Plattformen vektlegger forutsigbar prising, fleksibel distribusjon som holder data i kundens sky, og ende-til-ende-observasjon som spenner over infrastruktur, applikasjoner og moderne AI-drevne arbeidsbelastninger.

Når du ser tilbake på reisen din – fra å lede cyber-FoU-team i den israelske statsministerens kontor til å administrere maskinlæringsinitiativer hos Apple – hvilke erfaringer var det som til slutt drev deg mot å grunnlegge Groundcover, og når innså du først gapet i observerbarhet for moderne AI-systemer?

Drivkraften bak å grunnlegge Groundcover kom fra tiden min hos Apple og DayTwo. Selv med enorme budsjetter sto vi fast med valget mellom å betale en formue for å logge alt, eller å ta samplinger og fly i blinde. Den gangen lette vi etter en teknologi som kunne løse dette. Da vi kom over Extended Berkeley Packet Filter (eBPF), var det tydelig at det ville forandre alt. eBPF lar oss se alt som skjer i kjernen uten å være avhengige av applikasjonsendringer. Jeg forsto ikke hvorfor observasjonsverktøy ikke utnyttet dette. Gapet i AI ble tydelig senere. Da Kubernetes-plattformen vår modnet, så vi kunder som hastet inn i GenAI-distribusjoner mens de behandlet LLM-er som svarte bokser. De visste at modellen reagerte, men ikke hvorfor den oppførte seg uforutsigbart eller hvorfor kostnadene steg. Vi innså at agentiske arbeidsflyter rett og slett er komplekse, ikke-deterministiske mikrotjenester som trenger den samme berøringsfrie synligheten som vi allerede hadde bygget.

Hvordan påvirket din bakgrunn innen cybersikkerhet, innebygde systemer og maskinlærings-FoU visjonen bak groundcover, og hvilke tidlige utfordringer møtte du da du bygde et selskap sentrert rundt observerbarhet for LLM-drevne og agentiske applikasjoner?

Min cyberbakgrunn formet selskapets DNA. I etterretningsverdenen antar man at man ikke kontrollerer applikasjonen. Den tilnærmingen er grunnen til at Groundcover ikke krever instrumentering. Jeg vet av erfaring at det å be utviklere om å endre kode er den raskeste måten å blokkere adopsjon på. Den vanskeligste tidlige utfordringen med LLM-overvåking var personvern. Observerbarhet for AI fanger opp ledetekster som kan inneholde sensitiv PII eller IP. Min bakgrunn gjorde det åpenbart at bedrifter ikke ville ønske at disse dataene skulle forlate miljøet deres. Det er derfor vi bygde vår skybaserte arkitektur, som lar oss gi dyp innsikt i agenters atferd samtidig som alle dataene holdes i kundens eget miljø.

Hvordan definerer du LLM-observabilitet, og hva skiller den fra tradisjonell overvåking eller ML-overvåking?

LLM-observabilitet er praksisen med å instrumentere og overvåke produksjonssystemer som bruker store språkmodeller, slik at du kan fange opp hele konteksten til hver slutning: ledeteksten, konteksten, fullføringen, tokenbruken, latensen, feilene, modellmetadataene og ideelt sett nedstrøms tilbakemeldinger eller kvalitetssignaler. I stedet for å bare spørre «Er tjenesten oppe og rask?» eller «Oppsto det en feil i denne forespørselen?», hjelper LLM-observabilitet deg med å svare på spørsmål som «Hvorfor lyktes eller mislyktes denne forespørselen?», «Hva skjedde egentlig i denne flertrinns arbeidsflyten?» og «Hvordan påvirker endringer i ledetekster, kontekst eller modellversjoner kostnader, latens og utdatakvalitet?» Det er veldig forskjellig fra tradisjonell overvåking eller til og med klassisk ML-overvåking. Eldre tilnærminger er innstilt for deterministiske systemer, infrastrukturmålinger og statiske terskler. LLM-applikasjoner er ikke-deterministiske, åpne og svært kontekstavhengige. Suksess er ofte semantisk og subjektivt, ikke bare en statuskode på 200 vs 500. Det betyr at du må spore inndata og utdata, forstå verktøykall og hentetrinn, evaluere svar for ting som hallusinasjoner eller brudd på retningslinjene, og koble kostnader og forsinkelser på tokennivå tilbake til den omkringliggende applikasjonen og infrastrukturen.

Hvilke utfordringer introduserer LLM-drevne applikasjoner som gjør tradisjonelle observerbarhetsverktøy utilstrekkelige?

LLM-drevne systemer introduserer flere utfordringer som avdekker begrensningene til tradisjonelle verktøy:

• Komplekse arbeidsflyter med flere trinn – Vi gikk fra enkle «kall en modell, få et svar»-flyter til flertrinnsagenter, flertrinnsrørledninger, utvidet generering av henting og verktøybruk. En stille feil i noen av disse trinnene, for eksempel henting, berikelse, innebygging, verktøykall eller modellkall, kan ødelegge hele opplevelsen. Tradisjonell overvåking gir deg vanligvis ikke en komplett oversikt over disse kjedene på spornivå med inkluderte ledetekster og svar.
• Raskt utviklende AI-stabler – Team legger til nye modeller, verktøy og leverandører i et tempo de aldri har sett maken til. I mange selskaper kan ingen med sikkerhet liste opp hvilke modeller som er i produksjon til enhver tid. Klassisk observerbarhet forutsetter vanligvis at du har tid til å instrumentere SDK-er, distribuere på nytt og nøye kuratere det du måler. Det holder rett og slett ikke tritt med hvor raskt AI blir tatt i bruk.
• Tokenbasert økonomi og kvoter – Pris- og hastighetsgrenser er knyttet til tokener og kontekstlengde, som ofte kontrolleres av utviklere, ledetekster eller brukeratferd, ikke av sentral drift. Tradisjonelle verktøy er ikke bygget for å vise deg «hvem som brente hvor mange tokener på hvilken modell, for hvilken arbeidsflyt, med hvilken latens».
• Semantisk korrekthet i stedet for binær suksess – En LLM kan returnere en 200 og fortsatt hallusinere, drive bort fra prompten din eller bryte med policyen. Tradisjonelle verktøy ser på det som en suksess. Du trenger observerbarhet som kan avdekke prompter og svar og gi deg nok kontekst til å inspisere atferd og over tid koble til automatiserte kvalitetskontroller.
• Sensitive inndata som flyter til tredjeparter – LLM-er inviterer brukere til å dele svært sensitiv informasjon via chat-lignende grensesnitt. Nå er du ansvarlig for disse dataene, hvor de lagres og hvilke leverandører som ser dem. Konvensjonell SaaS-basert observerbarhet som sender all telemetri til en tredjepart er ofte uakseptabelt for disse arbeidsbelastningene.

Alt dette betyr at LLM-systemer krever observerbarhet som er AI-bevisst, kontekstrik og langt mindre avhengig av manuell instrumentering enn verktøyene de fleste team bruker i dag.

Hvilke signaler eller målinger er viktigst for å forstå ytelsen og kvaliteten til LLM-systemer, inkludert latens, tokenbruk og prompt-/responsatferd?

Det er noen få kategorier av signaler som er svært viktige i praksis:

Latens og gjennomstrømning

• Ende-til-ende-forsinkelse per forespørsel, inkludert modelltid og omkringliggende applikasjonstid.
• Haleforsinkelser (P90, P95, P99) per modell og per arbeidsflyt.
• Gjennomstrømning etter modell, rute og tjeneste, slik at du vet hvor lasten egentlig går.

Tokenbruk og kostnadsdrivere

• Input- og output-tokener per forespørsel, fordelt på modell.
• Aggregert tokenbruk over tid per modell, team, bruker og arbeidsflyt.
• Kontekststørrelser for hentetunge pipelines, slik at du kan se når ledetekster eksploderer.
• Dette er hva som lar deg svare på «Hvem bruker egentlig AI-budsjettet vårt, og på hva?»

Rask og responsatferd

• De faktiske prompt- og responsnyttelastene på representative spor, inkludert verktøykall og resonnementsbaner.
• Hvilke verktøy LLM valgte å kalle og i hvilken rekkefølge.
• Varians i svar for lignende spørsmål, slik at du kan se hvor stabil oppførselen er.

Pålitelighet og feil

• Modellspesifikke feilrater og -typer (leverandørfeil, tidsavbrudd, autentiseringsproblemer, kvotefeil).
• Feil i den omkringliggende arbeidsflyten, som for eksempel tidsavbrudd for verktøy eller hentefeil, korrelerte med LLM-kallet.

Klassisk infrakontekst

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

Når du kan se alt dette på ett sted, beveger LLM-observabilitet seg fra «Jeg vet at noe er tregt eller dyrt» til «Jeg vet nøyaktig hvilken modell, hvilket ledetekstmønster og hvilken tjeneste som er ansvarlige, og hvorfor».

Hvordan kan observerbarhet hjelpe team med å oppdage stille feil som rask avvik, hallusinasjoner eller gradvis forringelse av utdatakvaliteten?

Stille feil i LLM-systemer skjer vanligvis når alt ser «grønt» ut på infrastrukturnivå, men den faktiske oppførselen er i drift. Observerbarhet hjelper på noen måter:

• Sporing av hele arbeidsflyten, ikke bare modellkallet – Ved å fange opp hele banen til en forespørsel fra klient til tjeneste til henting til modell til verktøy, kan du se hvor oppførselen endret seg. For eksempel kan hentingen ha begynt å returnere færre dokumenter, eller et verktøykall mislykkes av og til, og modellen improviserer.
• Å ha oversikt over spørsmål, kontekst og svar – Når du kan inspisere prompter og svar sammen med spor, blir det mye enklere å oppdage tilfeller der en ny promptversjon, en ny systeminstruksjon eller en ny kontekstkilde endret virkemåten, selv om latens og feilrater forble de samme.
• Filtrering og slicing på semantiske betingelser – Når du har omfattende LLM-telemetri, kan du filtrere ned til ting som «berggrunnskall over ett sekund», «forespørsler som bruker denne modellfamilien» eller «spor som involverer denne bestemte ruten», og deretter lese instruksjonene og svarene for å se om modellen driver eller hallusinerer i et bestemt scenario.
• Varsling om SLO-er på forretningsnivå – Du kan definere SLO-er som «enhver LLM-samtale over ett sekund bryter med vår brukervendte SLA» og utløse varsler når disse betingelsene er oppfylt. Over tid kan lignende SLO-er knyttes til kvalitetspoeng eller policykontroller, slik at du blir varslet når kvaliteten forringes, ikke bare når infrastrukturen svikter.

Fordi observerbarhetslaget har tilgang til både de AI-spesifikke signalene og de klassiske loggene, metrikkene og sporene, blir det et naturlig sted å fange opp problemer som ellers i det stille ville forringet brukeropplevelsen.

Hvordan støtter Groundcovers tilnærming diagnostisering av uforutsigbar ventetid eller uventet oppførsel i flertrinns agentarbeidsflyter og verktøykall?

Groundcover bruker en tilnærming designet for moderne AI-systemer. Vi bruker en eBPF-basert sensor på kjernenivå for å observere trafikk på tvers av mikrotjenester uten kodeendringer eller nye distribusjoner. Så snart du introduserer en LLM-arbeidsflyt, kan vi automatisk oppdage disse kallene. Hvis du begynner å bruke en ny modell som Anthropic, OpenAI eller Bedrock i morgen, fanger Groundcover opp den trafikken automatisk. Det gir deg:

• Ende-til-ende-spor av arbeidsflyter med flere hopp – Du ser hele banen til en forespørsel på tvers av tjenester, inkludert hvor en LLM eller et verktøy brukes.
• Dyp kontekst på hver LLM-samtale – Hvert anrop inkluderer modellen som brukes, latens, tokenbruk, ledetekster, svar og korrelerte logger og infrastrukturmålinger.
• Kraftig filtrering på latens og betingelser – For eksempel kan du filtrere etter alle Claude 3.5-kall over ett sekund og umiddelbart inspisere sporene som brøt tjenestenivåavtalen din.
• Varsler og dashbord knyttet til LLM-atferd – Når dataene er tilgjengelige, kan du opprette varsler for SLA-brudd eller bygge dashbord som sporer latens, gjennomstrømning, tokenbruk og feil.

Fordi alt samles inn i utkanten av eBPF og lagres i din egen sky, får du denne oversikten med høy granularitet uten å legge til instrumentering i hvert agent- eller verktøykall.

Hvilke risikoer knyttet til datasikkerhet og samsvar ser du dukke opp i LLM-implementeringer, og hvordan kan observerbarhet bidra til å redusere disse risikoene?

LLM-implementeringer medfører noen unike datarisikoer:

• Ubegrenset brukerinndata – Brukere kan skrive inn ekstremt sensitiv informasjon i chatboter og AI-drevne grensesnitt. Dette kan inkludere personopplysninger, kundedata eller regulert informasjon som du aldri hadde til hensikt å samle inn.
• Tredjeparts modellleverandører – Når du sender disse dataene til en ekstern LLM-leverandør, er du ansvarlig for hvor de havnet, hvordan de lagres og hvilke underdatabehandlere som er involvert. Det har store implikasjoner for GDPR, datalagring og kundenes tillit.
• Telemetri som en andre kopi av sensitive data – Hvis observasjonsstakken din sender fulle nyttelaster til en SaaS-leverandør, har du nå en annen kopi av den sensitive informasjonen utenfor miljøet ditt.

Groundcovers arkitektur er utformet for å håndtere nettopp disse bekymringene:

• Vi bruker en «bring your own cloud»-modell der hele observerbarhetsbackend kjører inne i skykontoen din, i en underkonto, som et fullstendig administrert dataplan. Kontrollplanet som skalerer og administrerer det, drives av oss, men vi får ikke tilgang til, lagrer eller behandler telemetridataene dine.
• Fordi vi trygt kan fange opp nyttelaster i ditt eget miljø, kan du observere ledetekster, svar og arbeidsflyter uten at dataene noen gang forlater skyen din. Det er ingen tredjepartslagring av LLM-sporene dine og ingen ekstra datautgang å bekymre seg for.
• Med denne innsynsmuligheten kan du se hvem som laster opp hva og hvor det flyter, oppdage uventet bruk av sensitive data og håndheve retningslinjer rundt hvilke modeller og regioner som er tillatt.

Med andre ord blir observerbarhet ikke bare et pålitelighets- og kostnadsverktøy, men også et sentralt kontrollpunkt for personvern, datalagring og samsvar.

Hvilke driftsutfordringer pleier å dukke opp rundt synlighet, pålitelighet og kostnader når organisasjoner skalerer fra én LLM-integrasjon til mange AI-drevne tjenester?

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

• Modell- og leverandørspredning – Teamene tester nye modeller kontinuerlig. Det blir raskt uklart hvilke som er i produksjon og hvordan de brukes.
• Kostnadsoverraskelser fra tokenbruk – Tokenforbruket øker med kontekstlengde og arbeidsflytkompleksitet. Uten innsikt i tokenbruk per modell og arbeidsflyt er det svært vanskelig å administrere kostnader.
• Pålitelighetsavhengigheter hos eksterne leverandører – Brukerrettede API-er blir følsomme for modellforsinkelse eller -feil, noe som kan forstyrre tjenestenivåavtaler selv når kjerneinfrastrukturen er i god stand.
• Voksende instrumentgjeld – Tradisjonell observerbarhet forutsetter at du kan legge til instrumentering når det er nødvendig. I raskt utviklende AI-stabler har utviklere sjelden tid til det.

groundcover håndterer disse ved å automatisk oppdage AI-trafikk og deretter gi deg:

• Sentral innsikt i hvilke modeller og leverandører som brukes.
• Dashbord som viser latens, gjennomstrømning og tokenbruk over tid.
• Korrelasjon mellom LLM-atferd og tjenestene som er avhengige av den
• Varsler for AI-drevne SLO-brudd.

Det gjør det mye enklere å skalere fra «én kul AI-funksjon» til «AI er vevd inn i dusinvis av kritiske tjenester» uten å miste kontrollen.

Når du ser fremover, hvordan forventer du at LLM-observabilitet vil utvikle seg de neste fem årene etter hvert som agentisk AI, multimodellorkestrering og regulatorisk press akselererer?

Vi er fortsatt i den tidlige fasen. I løpet av de neste fem årene forventer jeg noen store endringer:

• Fra forespørselsnivå til forståelse på agentnivå – Observerbarheten vil utvides til å fange opp verktøysekvenser, resonnementsbaner og logikk for nye forsøk, ikke bare modellkall.
• Rikere semantiske og politiske signaler – Automatiserte kvalitetskontroller for hallusinasjoner, sikkerhetsproblemer og merkevaretilpasning vil bli standardmålinger.
• Tettere kobling med styring og personvern – Etter hvert som reguleringen øker, vil observerbarhet også fungere som et håndhevings- og revisjonslag for datalagring, oppbevaring og godkjent modellbruk.
• Kryssmodell, optimalisering av flere leverandører – Teamene vil rute trafikk på tvers av modeller dynamisk basert på ytelse og kostnader, veiledet av observerbarhetsdata i sanntid.
• Mindre manuell instrumentering – Teknikker som eBPF-basert innsamling og automatisk oppdagelse vil bli standard, slik at team kan innovere uten å sakke ned på tempoet.

Kort sagt vil LLM-observabilitet utvikle seg fra «kjekt å ha dashbord for AI» til sentralnervesystemet som forbinder pålitelighet, kostnadskontroll, datastyring og produktkvalitet på tvers av alt en organisasjon gjør med AI.

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