Shahar Azulay, CEO a spoluzakladatel groundcover

Shahar Azulay, CEO a spoluzakladatel groundcover je sériový líder výzkumu a vývoje. Shahar přináší zkušenosti ze světa kybernetické bezpečnosti a strojového učení, když pracoval jako líder ve společnostech jako Apple (AAPL ), DayTwo a Cymotive Technologies. Shahar strávil mnoho let v kybernetické divizi izraelského úřádu premiéra a má tři tituly v oboru fyziky, elektrotechniky a počítačových věd z Technion Israel Institute of Technology a Tel Aviv University. Shahar se snaží využít technologických poznatků z tohoto bohatého pozadí a přivést je do dnešního cloudového bojiště v nejostřejší a nejvíce inovativní formě, aby udělal svět deva lepším místem.

groundcover je cloudová platforma pro pozorovatelnost, která je navržena tak, aby poskytla inženýrským týmům plnou, reálnou viditelnost do jejich systémů bez složitosti nebo nákladů tradičních monitorovacích nástrojů. Postavená na technologii eBPF, shromažďuje a koreluje protokoly, metriky, stopy a události napříč cloudovými a Kubernetes prostředími bez změn kódu, což umožňuje rychlejší analýzu příčin a jasnější přehled systému. Platforma zdůrazňuje předvídatelné ceny, flexibilní nasazení, které udržuje data v zákaznickém cloudu, a komplexní pozorovatelnost sahající od infrastruktury po aplikace a moderní AI poháněné pracovní zátěže.

Cestou nazpět vaší cestou – od vedení kybernetických R&D týmů v izraelském úřádu premiéra po řízení ML iniciativ v Apple – co zkušenosti vás nakonec vedly ke založení groundcover a kdy jste poprvé rozpoznali mezeru v pozorovatelnosti pro moderní AI systémy?

Tlak na založení groundcover přišel z mé doby v Apple a DayTwo. I s obrovskými rozpočty jsme byli uvězněni mezi placením obrovské částky za protokolování všeho nebo vzorkováním a létáním naslepo. V té době jsme hledali technologii, která by to vyřešila. Jakmile jsme narazili na Extended Berkeley Packet Filter (eBPF), bylo jasné, že to změní všechno. eBPF nám umožňuje vidět vše, co se děje v jádru, bez závislosti na změnách aplikací. Nemohli jsme pochopit, proč nástroje pro pozorovatelnost nevyužívají toho. Mezera v AI se stala jasnou později. Jakmile naše Kubernetes platforma dospěla, viděli jsme zákazníky, kteří spěchali do GenAI nasazení, zatímco zacházeli s LLM jako s černými skříňkami. Věděli, že model reaguje, ale ne proč se chová nepředvídatelně nebo proč se náklady zvyšují. Rozpoznali jsme, že agentic pracovní postupy jsou prostě komplexní, nedeterministické mikroslužby, které potřebují stejnou bezdotykovou viditelnost, kterou jsme již vytvořili.

Jak vaše pozadí v kybernetické bezpečnosti, vestavěných systémech a strojovém učení R&D ovlivnilo vizi za groundcover a jaké rané výzvy jste čelili při budování společnosti zaměřené na pozorovatelnost pro LLM poháněné a agentic aplikace?

Mé kybernetické pozadí formovalo DNA společnosti. Ve světě inteligence se předpokládá, že nemáte kontrolu nad aplikací. To je důvod, proč groundcover nevyžaduje instrumentaci. Vími z expérience, že požadovat od vývojářů, aby změnili kód, je nejrychlejší způsob, jak zablokovat přijetí. Nejobtížnější ranou výzvou při monitorování LLM bylo soukromí. Pohorovatelnost pro AI zachycuje podněty, které mohou obsahovat citlivé PII nebo IP. Mé pozadí mi ukázalo, že podniky nebudou chtít, aby tato data opustila jejich prostředí. Proto jsme postavili naši architekturu v cloudu, která nám umožňuje poskytovat hlubokou viditelnost do chování agenta, zatímco udržujeme všechna data uvnitř zákaznického prostředí.

Jak definujete LLM pozorovatelnost a co ji dělá odlišnou od tradičního monitorování nebo ML monitorování?

LLM pozorovatelnost je praxe instrumentace a monitorování produkčních systémů, které využívají velké jazykové modely, aby zachytili plný kontext každého odvození: podnět, kontext, dokončení, token použití, latence, chyby, model metadata a ideálně i zpětnou vazbu nebo signály kvality. Místo toho, abyste se ptali pouze „Je služba aktivní a rychlá?“ nebo „Došlo k chybě této žádosti?“, LLM pozorovatelnost vám pomáhá odpovědět na otázky jako „Proč tato konkrétní žádost uspěla nebo selhala?“, „Co se vlastně stalo uvnitř této vícekrokové pracovní postupy?“ a „Jak změny v podnětech, kontextu nebo verzích modelů ovlivňují náklady, latenci a kvalitu výstupu?“ To je velmi odlišné od tradičního monitorování nebo dokonce klasického ML monitorování. Legacy přístupy jsou optimalizovány pro deterministické systémy, infrastrukturní metriky a statické prahové hodnoty. LLM aplikace jsou nedeterministické, otevřené a vysoce kontextově závislé. Úspěch je často sémantický a subjektivní, ne jen 200 vs 500 status kód. To znamená, že musíte sledovat vstupy a výstupy, pochopit nástrojové volání a kroky načtení, vyhodnotit odpovědi na věci, jako jsou halucinace nebo porušení zásad, a propojit tokenové náklady a zpoždění se surrounding aplikací a infrastruktury.

Jaké výzvy LLM poháněné aplikace představují, které činí tradiční nástroje pro pozorovatelnost nedostatečnými?

LLM poháněné systémy představují několik výzev, které odhalují limity tradičních nástrojů:

• Složitá, vícekroková pracovní postupy – Přecházíme od jednoduchých „volání modelu, získání odpovědi“ toků k vícekrokovým agentům, vícekrokovým potrubím, načtení posílené generaci a nástrojovému použití. Tichá chyba v kterémkoli z těchto kroků, jako je načtení, obohacování, vkládání, nástrojové volání nebo volání modelu, může rozbít celý zážitek. Tradiční monitorování obvykle vám nedává kompletní, stop-level pohled na tyto řetězce s podněty a odpověďmi zahrnuty.
• Rychle se vyvíjející AI stacky – Týmy přidávají nové modely, nástroje a dodavatele v tempu, které nikdy předtím neviděli. Ve mnoha společnostech nikdo nemůže s jistotou říci, které modely jsou v produkci v daném okamžiku. Klasická pozorovatelnost obvykle předpokládá, že máte čas na instrumentaci SDK, redeploy a pečlivé kurátorství toho, co měříte. To prostě nedokáže držet krok s tím, jak rychle je AI přijímán.
• Token-based ekonomika a kvóty – Ceny a limity jsou vázané na tokeny a délku kontextu, které jsou často řízeny vývojáři, podněty nebo uživatelským chováním, ne centrálními operacemi. Tradiční nástroje nejsou postaveny tak, aby vám ukázaly „kdo spálil kolik tokenů na kterém modelu, pro kterou pracovní postup, s jakou latencí“.
• Sémantická korektnost místo binárního úspěchu – LLM může vrátit 200 a přesto halucinovat, odchýlit se od vašeho podnětu nebo porušit zásady. Tradiční nástroje vidí to jako úspěch. Potřebujete pozorovatelnost, která může povýšit podněty a odpovědi a dát vám dostatečný kontext pro inspekci chování a v průběhu času zapojit automatizované kontroly kvality.
• Citlivá vstupní data proudící do třetích stran – LLM vás vyzývají k sdílení velmi citlivých informací prostřednictvím chatbotů a AI poháněných rozhraní. Nyní jste zodpovědní za tato data, kde jsou uložena a které dodavatele je vidí. Konvenční SaaS založené na pozorovatelnosti, které odesílají všechny telemetrická data třetí straně, jsou často nepřijatelné pro tyto pracovní zátěže.

To vše znamená, že LLM systémy vyžadují pozorovatelnost, která je AI vědomá, kontextově bohatá a mnohem méně závislá na manuální instrumentaci než nástroje, které většina týmů používá dnes.

Které signály nebo metriky jsou nejdůležitější pro pochopení výkonu a kvality LLM systémů, včetně latence, token použití a podnět/odpověď chování?

Existuje několik kategorií signálů, které mají velký význam v praxi:

Latence a propustnost

• Konečná latence na žádost, včetně modelového času a okolního aplikací času.
• Tail latence (P90, P95, P99) na model a na pracovní postup.
• Propustnost podle modelu, trasy a služby, abyste věděli, kam skutečně jde zátěž.

Token použití a náklady

• Vstupní a výstupní tokeny na žádost, rozdělené podle modelu.
• Agregované token použití v čase podle modelu, týmu, uživatele a pracovního postupu.
• Velikosti kontextu pro načtení náročné potrubí, abyste mohli vidět, kdy se podněty rozšiřují.
• To vám umožňuje odpovědět na otázku „Kdo skutečně utrácel náš AI rozpočet a na co?“

Podnět a odpověď chování

• Skutečné podnět a odpověď payloads na reprezentativních stopách, včetně nástrojových volání a rozumových cest.
• Které nástroje LLM zvolil a v jakém pořadí.
• Variace v odpovědích pro podobné podněty, abyste mohli říci, jak stabilní je chování.

Spolehlivost a chyby

• Model specifické chybové míry a typy (poskytovatelé chyb, časové limity, autentizační chyby, chyby kvót).
• Neúspěchy v okolní pracovní postup, jako jsou časové limity nástrojů nebo chyby načtení, korelovány s LLM voláním.

Klasický kontext infrastruktury

• Metriky CPU, paměti a sítě pro služby, které orchestrují vaše LLM volání.
• Korelované protokoly, které popisují, co se aplikaci snažila udělat.

Když můžete vidět všechnu tuto informaci na jednom místě, LLM pozorovatelnost se posune z „vím, že něco je pomalé nebo drahé“ na „vím přesně, který model, podnětový vzorec a služba jsou odpovědné a proč“.

Jak může pozorovatelnost pomoci týmům detekovat tiché chyby, jako je podnětový drift, halucinace nebo postupné zhoršení kvality výstupu?

Tiché chyby v LLM systémech obvykle nastávají, když vše vypadá „zeleně“ na úrovni infrastruktury, ale skutečné chování se posouvá. Pohorovatelnost pomáhá několika způsoby:

• Stopování celého pracovního postupu, ne jen modelového volání – Zachycením celkové cesty žádosti od klienta ke službě k načtení k modelu k nástrojům můžete vidět, kde se chování změnilo. Například možná načtení začalo vracet méně dokumentů, nebo nástrojové volání selhává intermittently a model improvizuje.
• Udržování podnětů, kontextu a odpovědí v zobrazení – Když můžete prohlížet podněty a odpovědi spolu se stopami, stává se mnohem snadnější rozpoznat případy, kdy nová verze podnětu, nová systémová instrukce nebo nový kontextový zdroj změnil chování, i když latence a chybové míry zůstaly stejné.
• Filtrování a řezání na sémantických podmínkách – Jakmile máte bohatou LLM telemetrii, můžete filtrovat dolů na věci, jako jsou „bedrock volání přes jednu sekundu“, „žádosti, které používají tuto modelovou rodinu“, nebo „stopy, které zahrnují tuto konkrétní trasu“, a pak přečíst podněty a odpovědi, abyste viděli, zda se model posouvá nebo halucinuje v konkrétní situaci.
• Upozornění na obchodní úrovni SLO – Můžete definovat SLO, jako „jakékoli LLM volání přes jednu sekundu porušuje naši uživatelsky orientovanou SLA“ a spouštět upozornění, když jsou tyto podmínky splněny. V průběhu času podobné SLO mohou být vázané na kvalitativní skóre nebo kontrolní body, abyste byli upozorněni, když kvalita se zhoršuje, ne jen když infrastruktura selhává.

Protože vrstva pozorovatelnosti má přístup k AI specifickým signálům a klasickým logům, metrikám a stopám, stává se přirozeným místem pro odchycení problémů, které by jinak tichě zhoršovaly uživatelský zážitek.

Jak přístup groundcover podporuje diagnostiku nepředvídatelné latence nebo neočekávaného chování uvnitř vícekrokových agentů pracovních postupů a nástrojových volání?

groundcover používá přístup, který je navržen pro moderní AI systémy. Používáme eBPF založený senzor na úrovni jádra, abychom pozorovali provoz napříč mikroslužbami bez změn kódu nebo redeploye. Jakmile zavedete LLM pracovní postup, můžeme automaticky objevit tato volání. Pokud začnete používat nový model, jako je Anthropic, OpenAI nebo Bedrock, zítra, groundcover zachytí tento provoz automaticky. To vám dává:

• Konečné stopy vícekrokových pracovních postupů – Vidíte celou cestu žádosti napříč službami, včetně toho, kde je LLM nebo nástroj použit.
• Hluboký kontext pro každé LLM volání – Každé volání zahrnuje model použitý, latenci, token použití, podněty, odpovědi a korelované logy a infra metriky.
• Silné filtrování na latenci a podmínkách – Například můžete filtrovat všechny Claude 3.5 volání přes jednu sekundu a okamžitě prohlédnout stopy, které porušily vaši SLA.
• Upozornění a dashboardy vázané na LLM chování – Jakmile jsou data dostupná, můžete vytvořit upozornění pro SLA porušení nebo postavit dashboardy, které sledují latenci, propustnost, token použití a chyby.

Protože vše je shromážděno na okraji eBPF a uloženo ve vašem vlastním cloudu, získáte tuto vysokou granularitu bez přidání instrumentace uvnitř každého agenta nebo nástrojového volání.

Jaké datové bezpečnostní a compliance rizika vidíte, které vznikají v LLM nasazeních, a jak může pozorovatelnost pomoci snížit tato rizika?

LLM nasazení přinášejí některá jedinečná data rizika:

• Neomezený uživatelský vstup – Uživatelé mohou zadat velmi citlivé informace do chatbotů a AI poháněných rozhraní. To může zahrnovat osobní data, zákaznická data nebo regulovaná informace, které jste nikdy nechtěli shromažďovat.
• Třetí strany modeloví poskytovatelé – Jakmile odešlete tato data externímu LLM poskytovateli, jste zodpovědní za to, kam šla, jak je uložena a které subprocessory jsou zapojeny. To má重大 implikace pro GDPR, data residency a zákaznickou důvěru.
• Telemetrie jako druhá kopie citlivých dat – Pokud vaše pozorovatelnostní zásobník odesílá plné payloads SaaS poskytovateli, máte nyní druhou kopii těchto citlivých informací uloženou mimo vaše prostředí.

Architektura groundcover je navržena tak, aby řešila přesně tyto obavy:

• Používáme model „přineste si vlastní cloud“, kde je celý pozorovatelnostní backend spuštěn uvnitř vašeho cloudového účtu, v sub-účtu, jako plně spravovaná datová rovina. Řídicí rovina, která škáluje a spravuje ji, je spuštěna námi, ale my nebudeme mít přístup, ukládat nebo zpracovávat vaše telemetrická data.
• Protože můžeme bezpečně zachytit payloads ve vašem vlastním prostředí, můžete pozorovat podněty, odpovědi a pracovní postupy bez toho, aby tato data opustila váš cloud. Není zde žádné třetí straně uložení vašich LLM stop a žádný další data egress, o kterém byste se museli starat.
• S touto viditelností můžete vidět, kdo nahrává co a kam to proudí, detekovat neočekávané použití citlivých dat a vynucovat zásady kolem toho, které modely a regiony jsou povoleny.

Jinými slovy, pozorovatelnost se stává nejen nástrojem pro spolehlivost a náklady, ale také klíčovým kontrolním bodem pro soukromí, data residency a compliance.

Jak organizace přecházejí z jedné LLM integrace na mnoho AI poháněných služeb, jaké provozní výzvy se objevují kolem viditelnosti, spolehlivosti a nákladů?

První integrace je obvykle jeden model v jednom pracovním postupu. V té fázi se věci zdají zvládnutelné. Jakmile týmy uvidí hodnotu, použití exploduje a několik výzev se objeví:

• Model a dodavatel šíření – Týmy testují nové modely neustále. Brzy se stává nejasným, které modely jsou v produkci a jak jsou používány.
• Nákladové překvapení z token použití – Token spotřeba roste s kontextovou délkou a složitostí pracovního postupu. Bez viditelnosti do token použití podle modelu a pracovního postupu je řízení nákladů velmi obtížné.
• Spolehlivostní závislosti na externích poskytovatelích – Uživatelsky orientované API se stávají citlivými na modelovou latenci nebo chyby, které mohou narušit SLA, i když je základní infrastruktura zdravá.
• Rostoucí instrumentační dluh – Tradiční pozorovatelnost předpokládá, že můžete přidat instrumentaci, když je potřeba. V rychlém AI stacku vývojáři zřídka mají čas na to.

groundcover řeší tyto problémy tím, že automaticky objeví AI provoz a poté vám poskytne:

• Centrální viditelnost do toho, které modely a dodavatelé jsou používány.
• Dashboardy zobrazující latenci, propustnost a token použití v čase.
• Korelace mezi LLM chováním a službami, které na něj závisí
• Upozornění pro AI poháněné SLO porušení.

To dělá mnohem snadnější škálovat z „jedné cool AI funkce“ na „AI je tkaný do desítek kritických služeb“ bez ztráty kontroly.

Jak očekáváte, že se LLM pozorovatelnost bude vyvíjet v příštích pěti letech, jakmile agentic AI, multi-model orchestrace a regulační tlaky zrychlí?

Jsme stále v raných dnech. V příštích pěti letech očekávám několik velkých posunů:

• Od úrovně požadavku na úroveň agenta – Pohorovatelnost se rozšíří na zachycení nástrojových sekvencí, rozumových cest a retry logiky, ne jen modelových volání.
• Bohatší sémantické a politické signály – Automatizované kontroly kvality pro halucinace, bezpečnostní problémy a brand soulad se stanou standardními metrikami.
• Užší spojení s řízením a soukromím – Jakmile se regulace roste, pozorovatelnost bude také sloužit jako vynucovací a auditní vrstva pro data residency, retenci a schválené modelové použití.
• Multi-model, multi-dodavatel optimalizace – Týmy budou směrovat provoz napříč modely dynamicky na základě výkonu a nákladů, vedené reálnou pozorovatelností dat.
• Méně manuální instrumentace – Techniky, jako je eBPF založené shromažďování a auto-objev, se stanou výchozím, takže týmy mohou inovovat bez zpomalení.

Stručně řečeno, LLM pozorovatelnost se bude vyvíjet z „hezkých dashboardů pro AI“ na centrální nervový systém, který spojuje spolehlivost, nákladovou kontrolu, data governance a produktovou kvalitu napříč vším, co organizace dělají s AI.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit groundcover.