Shahar Azulay, VD och medgrundare av groundcover

Shahar Azulay, VD och medgrundare av groundcover är en erfaren R&D-ledare. Shahar har erfarenhet från världen av cybersäkerhet och maskinlärning efter att ha arbetat som ledare i företag som Apple, DayTwo och Cymotive Technologies. Shahar tillbringade många år i Cyber-avdelningen vid den israeliska premiärministerns kontor och har tre examina i fysik, elektroteknik och datavetenskap från Technion Israel Institute of Technology samt Tel Aviv University. Shahar strävar efter att använda tekniska kunskaper från denna rika bakgrund och bringa dem till dagens molnbaserade strider i den skarpaste, mest innovativa formen för att göra världen av utveckling till en bättre plats.

groundcover är en molnbaserad plattform för observabilitet som är utformad för att ge utvecklingsteam fullständig, realtidsöversikt över sina system utan den komplexitet eller kostnad som traditionella övervakningsverktyg medför. Byggd på eBPF-teknik, samlar den in och korrelerar loggar, mått, spår och händelser över molnbaserade och Kubernetes-miljöer utan några 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 slut-till-slut-övervakning som omfattar infrastruktur, program och moderna AI-drivna arbetsbelastningar.

Om vi ser tillbaka på din resa – från att leda cyber R&D-lag i den israeliska premiärministerns kontor till att hantera ML-initiativ på Apple – vilka upplevelser ledde dig till att grunda groundcover, och när insåg du första gången gapet i observabilitet för moderna AI-system?

Impulsen att grunda groundcover kom från min tid på Apple och DayTwo. Även med stora budgetar var vi fast i valet mellan att betala en förmögenhet för att logga allt eller sampel och flyga blind. Då letade vi efter en teknik som skulle lösa det. Så fort vi 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 övervakningsverktyg inte utnyttjade det. AI-gapet blev tydligt senare. När vår Kubernetes-plattform mognade såg vi kunder som rusade in i GenAI-distributioner medan de behandlade LLM som svarta lådor. De visste att modellen svarade, men inte varför den betedde sig oförutsägbart eller varför kostnaderna sköt i höjden. Vi insåg att agensarbetsflöden är komplexa, icke-deterministiska mikrotjänster som behöver samma noll-beröringsöversikt som vi redan hade byggt.

Hur påverkade din bakgrund inom cybersäkerhet, inbäddade system och maskinlärningsforskning visionen bakom groundcover, och vilka tidiga utmaningar mötte du när du byggde ett företag som fokuserar på observabilitet för LLM-drivna och agensapplikationer?

Min cyberbakgrund formade företagets DNA. I underrättelsevärlden antar man att man inte kontrollerar applikationen. Det är därför groundcover inte kräver instrumentering. Jag vet från erfarenhet att att be utvecklare att modifiera kod är det snabbaste sättet att blockera antagande. Den svåraste tidiga utmaningen med LLM-övervakning var sekretess. Övervakning för AI fångar upp prompter som kan innehålla känsliga PII eller IP. Min bakgrund gjorde det uppenbart att företag inte skulle vilja att den datan lämnade deras miljö. Därför byggde vi vår molnbaserade arkitektur, som möjliggör för oss att ge djup insikt i agentbeteende samtidigt som all data hålls inom kundens egen miljö.

Hur definierar du LLM-övervakning, och vad gör den annorlunda än traditionell övervakning eller ML-övervakning?

LLM-övervakning är praktiken att instrumentera och övervaka produktionsystem som använder stora språkmodeller så att du kan fånga hela sammanhanget för varje inferens: prompten, sammanhanget, slutförandet, tokenanvändning, latens, fel, modellmetadata och idealiskt nedströmsfeedback eller kvalitetssignaler. Istället för att bara fråga “Är tjänsten uppe och snabb?” eller “Gjorde den här begäran ett fel?”, hjälper LLM-övervakning dig att besvara frågor som “Varför lyckades eller misslyckades den här specifika begäran?”, “Vad hände egentligen inuti det här flerstegsarbetsflödet?” och “Hur påverkar ändringar av prompter, sammanhang eller modellversioner kostnad, latens och utdatakvalitet?” Det är mycket annorlunda än traditionell övervakning eller till och med klassisk ML-övervakning. Äldre tillvägagångssätt är avsedda för deterministiska system, infrastrukturmått och statiska trösklar. LLM-applikationer är icke-deterministiska, öppna och starkt kontextberoende. Framgång är ofta semantisk och subjektiv, inte bara en 200- eller 500-statuskod. Det betyder att du måste spåra indata och utdata, förstå verktygsanrop och återställningsskeden, utvärdera svar för saker som hallucinationer eller policybrott och koppla tokenbaserade kostnader och fördröjningar tillbaka till den omgivande applikationen och infrastrukturen.

Vilka utmaningar introducerar LLM-aktiverade applikationer som gör traditionella övervakningsverktyg otillräckliga?

LLM-aktiverade system introducerar flera utmaningar som exponerar begränsningarna för traditionella verktyg:

• Komplexa, flerstegsarbetsflöden – Vi flyttade från enkla “anropa en modell, få ett svar”-flöden till flerstegsagenter, flerstegspipeliner, återställningsbaserad generering och verktygsanrop. En tyst fel i något av dessa steg, till exempel återställning, berikning, inbäddning, verktygsanrop eller modellanrop, kan bryta hela upplevelsen. Traditionell övervakning ger vanligtvis inte en fullständig, spårnivåvy över dessa kedjor med prompter och svar inkluderade.
• Snabbt utvecklande AI-stackar – Lag adderar nya modeller, verktyg och leverantörer i en takt de aldrig har sett förut. I många företag kan ingen med säkerhet lista vilka modeller som är i produktion vid en given tidpunkt. Klassisk övervakning antar vanligtvis att du har tid att instrumentera SDK:er, återdistribuera och noggrant kurera vad du mäter. Det håller helt enkelt inte jämna steg med hur snabbt AI antas.
• Tokenbaserad ekonomi och kvoter – Prissättning och ratebegränsningar är bundna till token och sammanhangslängd, som ofta kontrolleras av utvecklare, prompter eller användarbetende, inte av centrala operatörer. Traditionella verktyg är inte byggda för att visa dig “vem brände hur många token på vilken modell, för vilket arbetsflöde, vid vilken latens”.
• Semantisk korrekthet istället för binär framgång – En LLM kan returnera en 200 och fortfarande hallucinera, driva bort från din prompt eller bryta mot policy. Traditionella verktyg ser det som en framgång. Du behöver övervakning som kan yta prompter och svar och ge dig tillräckligt med sammanhang för att inspektera beteende och, över tid, ansluta automatiserade kvalitetskontroller.
• Känslig indata som flödar in i tredje parter – LLM:er bjuder in användare att dela mycket känslig information genom chattliknande gränssnitt. Nu är du ansvarig för den datan, var den lagras och vilka leverantörer som ser den. Konventionella SaaS-baserade övervakningsverktyg som skickar all telemetri till en tredje part är ofta oacceptabla för dessa arbetsbelastningar.

Allt detta betyder att LLM-system kräver övervakning som är AI-medveten, sammanhangsrik och mycket mindre beroende av manuell instrumentering än de verktyg de flesta lag använder idag.

Vilka signaler eller mått är viktigast för att förstå prestanda och kvalitet på LLM-system, inklusive latens, tokenanvändning och prompt/svarbeteende?

Det finns några kategorier av signaler som betyder mycket i praktiken:

Latens och genomströmning

• Slut-till-slut-latens per begäran, inklusive modelltid och omgivande applikationstid.
• Stjärtlatenser (P90, P95, P99) per modell och per arbetsflöde.
• Genomströmning per modell, väg och tjänst, så att du vet var belastningen verkligen går.

Tokenanvändning och kostnadsdrivare

• In- och utdatatoken per begäran, brutet per modell.
• Aggregerad tokenanvändning över tid per modell, lag, användare och arbetsflöde.
• Sammanhangsstorlekar för återställningsintensiva pipeliner så att du kan se när prompter exploderar.
• Detta är vad som låter dig svara på “Vem är det som verkligen spenderar vår AI-budget och på vad?”

Prompt och svarbeteende

• De faktiska prompt- och svarnyttolasterna 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 prompter så att du kan se hur stabil beteendet är.

Tillförlitlighet och fel

• Modellspecifika felrater och typer (leverantörsfel, tidsgränser, autentiseringsfel, kvotfel).
• Fel i den omgivande arbetsflödet, till exempel verktygstidsgränser eller återställningsfel, korrelerade med LLM-anropet.

Klassisk infrastruktursammanhang

• Container-CPU, minne och nätverksmått för tjänsterna som orkestrerar dina LLM-anrop.
• Korrelerade loggar som beskriver vad applikationen försökte göra.

När du kan se allt detta på en plats, flyttar LLM-övervakning från “Jag vet att något är långsamt eller dyrt” till “Jag vet exakt vilken modell, promptmönster och tjänst som är ansvarig och varför”.

Hur kan övervakning hjälpa lag att upptäcka tysta fel som promptdrift, hallucinationer eller gradvis försämring av utdatakvalitet?

Tysta fel i LLM-system händer vanligtvis när allt ser “grönt” ut på infrastrukturnivå, men det faktiska beteendet är på drift. Övervakning hjälper på flera sätt:

• Spåra hela arbetsflödet, inte bara modellanropet – Genom att fånga hela vägen för en begäran från klient till tjänst till återställning till modell till verktyg kan du se var beteendet förändrades. Till exempel kanske återställning började returnera färre dokument, eller ett verktygsanrop är intermittent fel och modellen improviserar.
• Hålla prompter, sammanhang och svar i vy – När du kan inspektera prompter och svar bredvid spår, blir det mycket lättare att upptäcka fall där en ny promptversion, en ny systeminstruktion eller en ny sammanhangskälla förändrade beteendet, även om latens och felrater förblev desamma.
• Filtrera och skära på semantiska villkor – När du har rik LLM-telemetri kan du filtrera ner till saker som “bedrock-anrop över en sekund”, “begäranden som använder den här modellfamiljen” eller “spår som involverar den här specifika vägen”, sedan läsa prompter och svar för att se om modellen drar eller hallucinerar i ett specifikt scenario.
• Varning för affärsnivå-SLO:er – Du kan definiera SLO:er som “varje LLM-anrop över en sekund bryter mot vår användarvänliga SLA” och utlösa varningar när dessa villkor uppfylls. Över tid kan liknande SLO:er kopplas till kvalitetspoäng eller policykontroller så att du får varningar när kvaliteten försämras, inte bara när infrastrukturen misslyckas.

Eftersom övervakningslagret har tillgång till både AI-specifika signaler och klassiska loggar, mått och spår, blir det en naturlig plats för att catcha problem som annars skulle försämra användarupplevelsen tyst.

Hur stöder groundcovers tillvägagångssätt diagnostisering av oförutsägbar latens eller oväntat beteende inom flerstegsagenter och verktygsanrop?

groundcover använder en tillvägagångssätt 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 några kodändringar eller omdistributioner. Så fort du introducerar ett LLM-arbetsflöde kan vi auto-upptäcka dessa anrop. Om du börjar använda en ny modell som Anthropic, OpenAI eller Bedrock imorgon, fångar groundcover den trafiken automatiskt. Det ger dig:

• Slut-till-slut-spår av flerstegsarbetsflöden – Du ser hela vägen för en begäran över tjänster, inklusive var en LLM eller verktyg används.
• Djup sammanhang för varje LLM-anrop – Varje anrop innehåller den använda modellen, latensen, tokenanvändningen, prompter, svar och korrelerade loggar och infrastrukturmått.
• Kraftfull filtrering på latens och villkor – Till exempel kan du filtrera alla Claude 3.5-anrop över en sekund och omedelbart inspektera spår som bröt mot din SLA.
• Varningar och instrumentpaneler kopplade till LLM-beteende – När datan är tillgänglig kan du skapa varningar för SLA-brott eller bygga instrumentpaneler som spårar latens, genomströmning, tokenanvändning och fel.

Eftersom allt samlas in på kanten av eBPF och lagras i din egen molnmiljö, får du den här högupplösta vyn utan att lägga till instrumentering inuti varje agent eller verktygsanrop.

Vilka datasäkerhets- och regelefterlevnadsrisker ser du som uppstår i LLM-distributioner, och hur kan övervakning hjälpa till att minska dessa risker?

LLM-distributioner medför några unika datasäkerhetsrisker:

• Ogränsad användarindata – Användare kan skriva extremt känslig information i chatbottar och AI-aktiverade gränssnitt. Det kan innehålla personuppgifter, kunddata eller reglerad information som du aldrig avsåg att samla in.
• Tredjepartsmodellleverantörer – När du skickar den datan till en extern LLM-leverantör är du ansvarig för var den går, hur den lagras och vilka underleverantörer som är inblandade. Det har stora implikationer för GDPR, dataresidens och kundförtroende.
• Telemetri som en andra kopia av känslig data – Om din övervakningsstack skickar fulla nyttolaster till en SaaS-leverantör har du nu en annan kopia av den känsliga informationen som ligger utanför din miljö.

groundcovers arkitektur är utformad för att hantera exakt dessa problem:

• Vi använder en “bring your own cloud”-modell där den fullständiga övervakningsbackend körs inom din molnkonto, i ett underkonto, som en fullständigt hanterad dataplan. Kontrollplanet som skalar och hanterar det körs av oss, men vi har inte tillgång till, lagrar eller bearbetar din telemetri data.
• Eftersom vi kan säkert samla in nyttolaster i din egen miljö kan du övervaka prompter, svar och arbetsflöden utan att den datan någonsin lämnar din moln. Det finns ingen tredjeparts lagring av dina LLM-spår och ingen extra datautgång att oroa sig för.
• Med den här insikten kan du se vem som laddar upp vad och var det flödar, upptäcka oväntad användning av känslig data och verkställa policyer kring vilka modeller och regioner som är tillåtna.

Med andra ord blir övervakning inte bara ett verktyg för tillförlitlighet och kostnad, utan också en viktig kontrollpunkt för sekretess, dataresidens och regelefterlevnad.

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

Den första integrationen är vanligtvis en enda modell i ett enda arbetsflöde. Vid den punkten känns saker hanterbara. Så fort lag ser värdet, exploderar användningen och flera utmaningar dyker upp:

• Modell- och leverantörsspridning – Lag testar nya modeller konstant. Det blir snabbt oklart vilka modeller som är i produktion och hur de används.
• Kostnadsöverraskningar från tokenanvändning – Tokenkonsumtionen ökar med sammanhangslängd och arbetsflödeskomplexitet. Utan insikt i tokenanvändning per modell och arbetsflöde är det svårt att hantera kostnader.
• Tillförlitlighetsberoende av externa leverantörer – Användarvänliga API:er blir känsliga för modelllatens eller fel, som kan störa SLA:er även när kärninfrastrukturen är frisk.
• Ökande instrumenterings skuld – Traditionell övervakning antar att du kan lägga till instrumentering när du behöver det. I snabbt rörliga AI-stackar har utvecklare sällan tid för det.

groundcover hanterar detta genom att auto-upptäcka AI-trafik och sedan ge dig:

• Central synlighet för vilka modeller och leverantörer som används.
• Instrumentpaneler som visar latens, genomströmning och tokenanvändning över tid.
• Korrelation mellan LLM-beteende och de tjänster som är beroende av det
• Varningar för AI-drivna SLO-brott.

Det gör det mycket lättare att skala från “en cool AI-funktion” till “AI är vävt in i dussintals kritiska tjänster” utan att förlora kontroll.

Om vi ser framåt, hur förväntar du dig att LLM-övervakning kommer att utvecklas under de närmaste fem åren när agens-AI, multi-modellorkestrering och regeleftertryck accelererar?

Vi är fortfarande i de tidiga dagarna. Under de närmaste fem åren förväntar jag mig ett par stora skift:

• Från begäranivå till agentnivåförståelse – Övervakning kommer att expandera för att fånga verktygssekvenser, resonemangsvägar och omstartlogik, inte bara modellanrop.
• Rikare semantiska och policybaserade signaler – Automatiserade kvalitetskontroller för hallucinationer, säkerhetsproblem och varumärkesöverensstämmelse kommer att bli standardmått.
• Tätare koppling till styrning och sekretess – När reglering växer, kommer övervakning också att fungera som ett verkställande och granskningslager för dataresidens, lagring och godkänd modellanvändning.
• Korsmodell, multileverantörs optimering – Lag kommer att dirigera trafik över modeller dynamiskt baserat på prestanda och kostnad, guidade av realtidsövervakningsdata.
• Mindre manuell instrumentering – Tekniker som eBPF-baserad insamling och auto-upptäckt kommer att bli standard, så att lag kan innovativa utan att sakta ner.

I korthet kommer LLM-övervakning att utvecklas från “nice to have”-instrumentpaneler för AI till det centrala nervsystemet som kopplar tillförlitlighet, kostnadskontroll, datastyrning och produktkvalitet över allt ett företag gör med AI.

Tack för det underbara samtalet, läsare som vill lära sig mer kan besöka groundcover.