Shahar Azulay, VD och medgrundare av Groundcover

Shahar Azulay, VD och medgrundare av Groundcover är en ständig ledare inom forskning och utveckling. Shahar har erfarenhet inom cybersäkerhet och maskininlärning efter att ha arbetat som ledare i företag som Apple, DayTwo och Cymotive Technologies. Shahar tillbringade många år inom cyberavdelningen vid den israeliska premiärministerns kansli och har tre examina i fysik, elektroteknik och datavetenskap från Technion Israel Institute of Technology samt Tel Avivs universitet. Shahar strävar efter att använda tekniska lärdomar från denna rika bakgrund och föra dem till dagens molnbaserade slagfält i den vassaste och mest innovativa formen för att göra utvecklingsvärlden till en bättre plats.

ground är en molnbaserad observationsplattform utformad för att ge ingenjörsteam fullständig insyn i sina system i realtid utan komplexiteten eller kostnaden för traditionella övervakningsverktyg. Byggd på eBPF-teknik samlar och korrelerar den loggar, mätvärden, spår och händelser över molnbaserade och Kubernetes-miljöer utan kodändringar, vilket möjliggör snabbare rotorsaksanalys och tydligare systeminsikt. Plattformen betonar förutsägbar prissättning, flexibel distribution som håller data i kundens moln och heltäckande observationsförmåga som omfattar infrastruktur, applikationer och moderna AI-drivna arbetsbelastningar.

När du ser tillbaka på din resa – från att leda cyberforsknings- och utvecklingsteam i Israels premiärministers kansli till att hantera maskininlärningsinitiativ på Apple – vilka erfarenheter drev dig slutligen mot att grunda Groundcover, och när insåg du först bristen på observerbarhet för moderna AI-system?

Drivkraften att grunda groundcover kom från min tid på Apple och DayTwo. Även med enorma budgetar satt vi fast med att välja mellan att betala en förmögenhet för att logga allt eller att sampla och flyga i blindo. Då letade vi efter en teknik som skulle lösa det. När vi väl stötte på Extended Berkeley Packet Filter (eBPF) var det tydligt att det skulle förändra allt. eBPF låter oss se allt som händer i kärnan utan att förlita oss på applikationsändringar. Jag kunde inte förstå varför observationsverktyg inte utnyttjade det. AI-gapet blev tydligt senare. När vår Kubernetes-plattform mognat såg vi kunder rusa in i GenAI-distributioner medan de behandlade LLM:er som svarta lådor. De visste att modellen svarade, men inte varför den betedde sig oförutsägbart eller varför kostnaderna steg. Vi insåg att agentiska arbetsflöden helt enkelt är komplexa, icke-deterministiska mikrotjänster som behöver samma zero-touch-insyn som vi redan hade byggt.

Hur påverkade din bakgrund inom cybersäkerhet, inbyggda system och maskininlärningsforskning och utveckling visionen bakom groundcover, och vilka tidiga utmaningar mötte du när du byggde ett företag med fokus på observerbarhet för LLM-drivna och agentiska applikationer?

Min cyberbakgrund formade företagets DNA. I underrättelsevärlden antar man att man inte kontrollerar applikationen. Det är den metoden som gör att Groundcover inte kräver instrumentering. Jag vet av erfarenhet att det snabbaste sättet att blockera implementering är att be utvecklare att ändra kod. Den svåraste tidiga utmaningen med LLM-övervakning var integritet. Observerbarhet för AI fångar upp uppmaningar som kan innehålla känsliga PII eller IP. Min bakgrund gjorde det uppenbart att företag inte ville att den informationen skulle lämna deras miljö. Det är därför vi byggde vår molnbaserade arkitektur, vilket gör det möjligt för oss att ge djup insyn i agenternas beteende samtidigt som all data hålls i kundens egen miljö.

Hur definierar du LLM-observerbarhet, och vad skiljer den från traditionell övervakning eller ML-övervakning?

LLM-observabilitet är praxisen att instrumentera och övervaka produktionssystem som använder stora språkmodeller så att du kan fånga hela kontexten för varje inferens: prompt, kontext, slutförande, tokenanvändning, latens, fel, modellmetadata och helst nedströms feedback eller kvalitetssignaler. Istället för att bara fråga "Är tjänsten igång och snabb?" eller "Fick den här begäran ett fel?", hjälper LLM-observabilitet dig att svara på frågor som "Varför lyckades eller misslyckades just den här begäran?", "Vad hände egentligen i detta flerstegsarbetsflöde?" och "Hur påverkar ändringar av prompter, kontext eller modellversioner kostnad, latens och utdatakvalitet?". Det skiljer sig mycket från traditionell övervakning eller till och med klassisk ML-övervakning. Äldre metoder är anpassade för deterministiska system, infrastrukturmätvärden och statiska tröskelvärden. LLM-applikationer är icke-deterministiska, öppna och mycket kontextberoende. Framgång är ofta semantisk och subjektiv, inte bara en statuskod på 200 vs 500. Det innebär att du måste spåra indata och utdata, förstå verktygsanrop och hämtningssteg, utvärdera svar på saker som hallucinationer eller policyöverträdelser, och koppla kostnader och förseningar på tokennivå tillbaka till den omgivande applikationen och infrastrukturen.

Vilka utmaningar medför LLM-drivna applikationer som gör traditionella observerbarhetsverktyg otillräckliga?

LLM-drivna system introducerar flera utmaningar som blottlägger begränsningarna hos traditionella verktyg:

• Komplexa arbetsflöden i flera steg – Vi gick från enkla flöden av typen "anropa en modell, få ett svar" till agenter med flera steg, pipelines i flera steg, förstärkt generering av hämtning och verktygsanvändning. Ett tyst fel i något av dessa steg, såsom hämtning, berikning, inbäddning, verktygsanrop eller modellanrop, kan förstöra hela upplevelsen. Traditionell övervakning ger dig vanligtvis inte en komplett vy på spårningsnivå över dessa kedjor med instruktioner och svar inkluderade.
• Snabbt utvecklande AI-stackar – Team lägger till nya modeller, verktyg och leverantörer i en takt de aldrig sett tidigare. I många företag kan ingen med säkerhet lista vilka modeller som är i produktion vid varje given tidpunkt. Klassisk observerbarhet förutsätter vanligtvis att man har tid att instrumentera SDK:er, omdistribuera och noggrant sammanställa det man mäter. Det håller helt enkelt inte jämna steg med hur snabbt AI antas.
• Tokenbaserad ekonomi och kvoter – Prissättning och hastighetsgränser är knutna till tokens och kontextlängd, vilka ofta styrs av utvecklare, prompter eller användarbeteende, inte av central drift. Traditionella verktyg är inte byggda för att visa dig "vem som brände hur många tokens på vilken modell, för vilket arbetsflöde, med vilken latens".
• Semantisk korrekthet istället för binär framgång – En LLM kan returnera 200 och ändå hallucinera, glida bort från din prompt eller bryta mot policyn. Traditionella verktyg ser det som en framgång. Du behöver observerbarhet som kan lyfta fram prompter och svar och ge dig tillräckligt med kontext för att inspektera beteende och, med tiden, lägga till automatiserade kvalitetskontroller.
• Känsliga indata som flödar till tredje part – LLM:er bjuder in användare att dela mycket känslig information via chattliknande gränssnitt. Nu ansvarar du för den informationen, var den lagras och vilka leverantörer som ser den. Konventionell SaaS-baserad observerbarhet som skickar all telemetri till en tredje part är ofta oacceptabel för dessa arbetsbelastningar.

Allt detta innebär att LLM-system kräver observerbarhet som är AI-medveten, kontextrik och betydligt mindre beroende av manuell instrumentering än de verktyg som de flesta team använder idag.

Vilka signaler eller mätvärden är viktigast för att förstå prestandan och kvaliteten hos LLM-system, inklusive latens, tokenanvändning och prompt-/responsbeteende?

Det finns några kategorier av signaler som är mycket viktiga i praktiken:

Latens och dataflöde

• End-to-end-latens per begäran, inklusive modelltid och omgivande applikationstid.
• Svansförtändelser (P90, P95, P99) per modell och per arbetsflöde.
• Dataflöde per modell, rutt och tjänst, så att du vet vart lasten verkligen går.

Tokenanvändning och kostnadsdrivare

• Indata- och utdatatokens per begäran, uppdelade efter modell.
• Aggregerad tokenanvändning över tid per modell, team, användare och arbetsflöde.
• Kontextstorlekar för hämtningstunga pipelines så att du kan se när prompter exploderar.
• Det här är vad som låter dig svara på frågan ”Vem spenderar egentligen vår AI-budget och på vad?”

Prompt- och responsbeteende

• De faktiska prompt- och svarsnyttolasten på representativa spår, inklusive verktygsanrop och resonemangsvägar.
• Vilka verktyg LLM valde att anropa och i vilken sekvens.
• Varians i svar för liknande uppmaningar så att du kan avgöra hur stabilt beteendet är.

Tillförlitlighet och fel

• Modellspecifika felfrekvenser och typer (leverantörsfel, timeouts, autentiseringsproblem, kvotfel).
• Fel i omgivande arbetsflöde, såsom verktygstimeouts eller hämtningsfel, korrelerade med LLM-anropet.

Klassisk infrakontext

• Container-CPU, minne och nätverksstatistik för de tjänster som orkestrerar dina LLM-anrop.
• Korrelerade loggar som beskriver vad programmet försökte göra.

När man kan se allt detta på ett ställe, går LLM-observerbarheten från "Jag vet att något är långsamt eller dyrt" till "Jag vet exakt vilken modell, vilket promptmönster och vilken tjänst som är ansvariga och varför".

Hur kan observerbarhet hjälpa team att upptäcka tysta fel, såsom snabb avvikelse, hallucinationer eller gradvis försämring av utskriftskvaliteten?

Tysta fel i LLM-system inträffar vanligtvis när allt ser "grönt" ut på infrastrukturnivå, men det faktiska beteendet avviker. Observerbarhet hjälper på några sätt:

• Spåra hela arbetsflödet, inte bara modellanropet – Genom att samla in hela sökvägen för en förfrågan, klient till tjänst, hämtning till modell till verktyg, kan du se var beteendet har förändrats. Till exempel kanske hämtningen började returnera färre dokument, eller så misslyckas ett verktygsanrop intermittent och modellen improviserar.
• Ha uppmaningar, sammanhang och svar i sikte – När du kan inspektera prompter och svar tillsammans med spår blir det mycket enklare att upptäcka fall där en ny promptversion, en ny systeminstruktion eller en ny kontextkälla ändrade beteendet, även om latens och felfrekvenser förblev desamma.
• Filtrering och slicing på semantiska villkor – När du har omfattande LLM-telemetri kan du filtrera ner till saker som "berggrundsanrop under en sekund", "förfrågningar som använder den här modellfamiljen" eller "spår som involverar den här specifika rutten", och sedan läsa uppmaningarna och svaren för att se om modellen driver eller hallucinerar i ett specifikt scenario.
• Aviseringar om SLO:er på affärsnivå – Du kan definiera SLO:er som "alla LLM-anrop under en sekund bryter mot vårt användarvänliga SLA" och utlösa varningar när dessa villkor är uppfyllda. Med tiden kan liknande SLO:er kopplas till kvalitetspoäng eller policykontroller så att du får en varning när kvaliteten försämras, inte bara när infrastrukturen slutar fungera.

Eftersom observerbarhetslagret har tillgång till både AI-specifika signaler och klassiska loggar, mätvärden och spår, blir det en naturlig plats att upptäcka problem som annars i det tysta skulle försämra användarupplevelsen.

Hur stöder Groundcovers metod diagnostisering av oförutsägbar latens eller oväntat beteende i flerstegsarbetsflöden för agenter och verktygsanrop?

Groundcover använder en metod som är utformad för moderna AI-system. Vi använder en eBPF-baserad sensor på kärnnivå för att observera trafik över mikrotjänster utan kodändringar eller omdistributioner. Så snart du introducerar ett LLM-arbetsflöde kan vi automatiskt upptäcka dessa anrop. Om du börjar använda en ny modell som Anthropic, OpenAI eller Bedrock imorgon, fångar Groundcover upp den trafiken automatiskt. Det ger dig:

• End-to-end-spår av multi-hop-arbetsflöden – Du ser hela sökvägen för en förfrågan över olika tjänster, inklusive var en LLM eller ett verktyg används.
• Djupgående kontext för varje LLM-samtal – Varje anrop inkluderar använd modell, latens, tokenanvändning, prompter, svar samt korrelerade loggar och infrastrukturmått.
• Kraftfull filtrering av latens och villkor – Till exempel kan du filtrera efter alla Claude 3.5-anrop under en sekund och omedelbart inspektera de spår som bröt mot ditt SLA.
• Aviseringar och instrumentpaneler kopplade till LLM-beteende – När informationen är tillgänglig kan du skapa aviseringar för SLA-överträdelser eller bygga dashboards som spårar latens, dataflöde, tokenanvändning och fel.

Eftersom allt samlas in i utkanten av eBPF och lagras i ditt eget moln får du denna höggranulara vy utan att lägga till instrument i varje agent- eller verktygsanrop.

Vilka datasäkerhets- och efterlevnadsrisker ser du framträda i LLM-implementeringar, och hur kan observerbarhet bidra till att minska dessa risker?

LLM-implementeringar medför vissa unika datarisker:

• Obegränsad användarinmatning – Användare kan skriva in extremt känslig information i chattrobotar och AI-drivna gränssnitt. Det kan inkludera personuppgifter, kunddata eller reglerad information som du aldrig avsett att samla in.
• Tredjepartsmodellleverantörer – När du väl skickar den informationen till en extern LLM-leverantör är du ansvarig för vart den tog vägen, hur den lagras och vilka underleverantörer som är inblandade. Det har stora konsekvenser för GDPR, datalagring och kundernas förtroende.
• Telemetri som en andra kopia av känsliga data – Om din observerbarhetsstack skickar fullständiga nyttolaster till en SaaS-leverantör har du nu en annan kopia av den känsliga informationen utanför din miljö.

Marköverdragets arkitektur är utformad för att ta itu med just dessa problem:

• Vi använder en "bring your own cloud"-modell där hela observerbarhetsbackend körs inuti ditt molnkonto, i ett underkonto, som ett fullständigt hanterat dataplan. Kontrollplanet som skalar och hanterar det drivs av oss, men vi varken kommer åt, lagrar eller bearbetar dina telemetridata.
• Eftersom vi säkert kan samla in nyttolaster i din egen miljö kan du observera uppmaningar, svar och arbetsflöden utan att informationen någonsin lämnar ditt moln. Det finns ingen tredjepartslagring av dina LLM-spår och ingen extra datautmatning att oroa sig för.
• Med den insynen kan du se vem som laddar upp vad och vart det flödar, upptäcka oväntad användning av känslig data och tillämpa policyer kring vilka modeller och regioner som är tillåtna.

Med andra ord blir observerbarhet inte bara ett tillförlitlighets- och kostnadsverktyg, utan också en viktig kontrollpunkt för integritet, datalagring och efterlevnad.

När organisationer skalar från en LLM-integration till många AI-drivna tjänster, vilka operativa utmaningar tenderar att uppstå kring synlighet, tillförlitlighet och kostnad?

Den första integrationen är vanligtvis en enda modell i ett enda arbetsflöde. I det skedet känns saker och ting hanterbara. Så snart team ser värde exploderar användningen och flera utmaningar uppstår:

• Modell- och leverantörsspridning – Team testar nya modeller ständigt. Det blir snabbt oklart vilka som är i produktion och hur de används.
• Kostnadsöverraskningar från tokenanvändning – Tokenförbrukningen ökar med kontextlängd och arbetsflödets komplexitet. Utan insyn i tokenanvändningen per modell och arbetsflöde är det mycket svårt att hantera kostnader.
• Tillförlitlighetsberoenden hos externa leverantörer – Användarriktade API:er blir känsliga för modellfördröjning eller fel, vilket kan störa SLA:er även när kärninfrastrukturen är felfri.
• Växande Instrumentation-skuld – Traditionell observerbarhet förutsätter att man kan lägga till instrumentering vid behov. I snabbrörliga AI-stackar har utvecklare sällan tid för det.

groundcover åtgärdar dessa genom att automatiskt upptäcka AI-trafik och sedan ge dig:

• Central insyn i vilka modeller och leverantörer som används.
• Instrumentpaneler som visar latens, dataflöde och tokenanvändning över tid.
• Korrelation mellan LLM-beteende och de tjänster som är beroende av det
• Aviseringar för AI-drivna SLO-intrång.

Det gör det mycket enklare att skala från "en cool AI-funktion" till "AI är invävd i dussintals kritiska tjänster" utan att tappa kontrollen.

Hur förväntar du dig att LLM-observabiliteten kommer att utvecklas under de kommande fem åren i takt med att agentisk AI, orkestrering av flera modeller och regeltryck accelererar?

Vi är fortfarande i början. Under de kommande fem åren förväntar jag mig några stora förändringar:

• Från förfrågningsnivå till agentnivå förståelse – Observerbarheten kommer att utökas för att fånga verktygssekvenser, resonemangsvägar och återförsökslogik, inte bara modellanrop.
• Rikare semantiska och politiska signaler – Automatiserade kvalitetskontroller av hallucinationer, säkerhetsproblem och varumärkesanpassning kommer att bli standardmätvärden.
• Tätare koppling till styrning och integritet – I takt med att regleringen växer kommer observerbarhet också att fungera som ett verkställighets- och revisionslager för datalagring, lagring och godkänd modellanvändning.
• Korsmodell, optimering av flera leverantörer – Teamen kommer att dirigera trafik över modeller dynamiskt baserat på prestanda och kostnad, vägledda av observerbarhetsdata i realtid.
• Mindre manuell instrumentering – Tekniker som eBPF-baserad insamling och automatisk identifiering kommer att bli standard, så att team kan förnya sig utan att sakta ner.

Kort sagt kommer observerbarhet inom LLM att utvecklas från "bra att ha dashboards för AI" till det centrala nervsystem som kopplar samman tillförlitlighet, kostnadskontroll, datastyrning och produktkvalitet i allt en organisation gör med AI.

Tack för den fina intervjun, läsare som vill veta mer bör besöka ground.