Shahar Azulay, generální ředitelka a spoluzakladatelka společnosti Groundcover

Šahar Azulajová, Generální ředitel a spoluzakladatel společnosti Groundcover je sériový lídr v oblasti výzkumu a vývoje. Shahar má zkušenosti ve světě kybernetické bezpečnosti a strojového učení, protože pracoval jako vedoucí pracovník ve společnostech, jako jsou Apple, DayTwo a Cymotive Technologies. Shahar strávil mnoho let v kybernetické divizi v kanceláři izraelského premiéra a má tři tituly z fyziky, elektrotechniky a informatiky z Technion Israel Institute of Technology a také z Tel Avivské univerzity. Shahar se snaží využít technologické poznatky z tohoto bohatého zázemí a přenést je na dnešní cloudové bojiště v nejostřejší a nejinovativnější podobě, aby svět vývoje byl lepším místem.

půdopokryvná je cloudová nativní platforma pro sledování, která je navržena tak, aby inženýrským týmům poskytla plný přehled o jejich systémech v reálném čase bez složitosti nebo nákladů na tradiční monitorovací nástroje. Je postavena na technologii eBPF a shromažďuje a koreluje protokoly, metriky, trasování a události napříč cloudovými prostředími a prostředím Kubernetes bez změn kódu, což umožňuje rychlejší analýzu hlavních příčin a jasnější přehled o systému. Platforma klade důraz na předvídatelné ceny, flexibilní nasazení, které uchovává data v cloudu zákazníka, a komplexní sledování zahrnující infrastrukturu, aplikace a moderní úlohy řízené umělou inteligencí.

Když se ohlédnete za svou cestou – od vedení týmů kybernetického výzkumu a vývoje v kanceláři izraelského premiéra až po řízení iniciativ strojového učení ve společnosti Apple – jaké zkušenosti vás nakonec přivedly k založení Groundcover a kdy jste si poprvé uvědomil mezeru v pozorovatelnosti moderních systémů umělé inteligence?

Tlak na založení groundcoveru pramenil z mého působení v Apple a DayTwo. I s obrovskými rozpočty jsme se museli rozhodovat mezi zaplacením jmění za logování všeho, vzorkováním a létáním naslepo. Tehdy jsme hledali technologii, která by to vyřešila. Jakmile jsme narazili na Extended Berkeley Packet Filter (eBPF), bylo jasné, že to všechno změní. eBPF nám umožňuje vidět vše, co se děje v jádře, aniž bychom se spoléhali na změny v aplikaci. Nechápal jsem, proč nástroje pro pozorovatelnost toho nevyužívají. Mezera v AI se později ukázala jako jasná. Jakmile naše platforma Kubernetes dozrála, viděli jsme zákazníky, jak se hrnou do nasazení GenAI a zároveň zacházejí s LLM jako s černými skříňkami. Věděli, že model reaguje, ale ne proč se chová nepředvídatelně nebo proč náklady prudce rostou. Uvědomili jsme si, že agentní pracovní postupy jsou jednoduše složité, nedeterministické mikroslužby, které potřebují stejnou bezkontaktní viditelnost, jakou jsme již vytvořili.

Jak vaše zkušenosti v oblasti kybernetické bezpečnosti, vestavěných systémů a výzkumu a vývoje strojového učení ovlivnily vizi Groundcover a s jakými ranými výzvami jste čelili při budování společnosti zaměřené na pozorovatelnost pro aplikace řízené LLM a agentní aplikace?

Moje zkušenosti v kybernetické oblasti formovaly DNA společnosti. Ve světě inteligence předpokládáte, že aplikaci neovládáte. To je důvod, proč Groundcover nevyžaduje instrumentaci. Z vlastní zkušenosti vím, že nejrychlejším způsobem, jak zablokovat její přijetí, je požádat vývojáře o úpravu kódu. Nejtěžší zpočátku výzvou při monitorování LLM bylo soukromí. Pozorovatelnost pro AI zachycuje výzvy, které mohou obsahovat citlivé osobní údaje nebo IP. Moje zkušenosti jasně ukazovaly, že podniky nechtějí, aby tato data opustila jejich prostředí. Proto jsme vytvořili naši cloudovou architekturu, která nám umožňuje poskytovat hluboký přehled o chování agentů a zároveň uchovávat všechna data v prostředí zákazníka.

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

Observabilita LLM je praxe instrumentace a monitorování produkčních systémů, které používají rozsáhlé jazykové modely, takže můžete zachytit celý kontext každého závěru: výzvu, kontext, dokončení, využití tokenů, latenci, chyby, metadata modelu a ideálně zpětnou vazbu nebo signály kvality. Namísto pouhého dotazu „Je služba funkční a rychlá?“ nebo „Došlo u tohoto požadavku k chybě?“ vám pozorovatelnost LLM pomáhá odpovědět na otázky typu „Proč byl tento konkrétní požadavek úspěšný nebo selhal?“, „Co se vlastně stalo v tomto vícekrokovém pracovním postupu?“ a „Jak změny výzev, kontextu nebo verzí modelu ovlivňují náklady, latenci a kvalitu výstupu?“. To se velmi liší od tradičního monitorování nebo dokonce klasického monitorování ML. Zastaralé přístupy jsou vyladěny pro deterministické systémy, metriky infrastruktury a statické prahové hodnoty. Aplikace LLM jsou nedeterministické, otevřené a vysoce závislé na kontextu. Úspěch je často sémantický a subjektivní, nejedná se jen o stavový kód 200 vs 500. To znamená, že musíte sledovat vstupy a výstupy, porozumět volání nástrojů a krokům načítání, vyhodnocovat reakce na věci, jako jsou halucinace nebo porušení zásad, a propojit náklady a zpoždění na úrovni tokenů zpět s okolní aplikací a infrastrukturou.

Jaké výzvy představují aplikace založené na LLM, které znemožňují tradiční nástroje pro pozorovatelnost?

Systémy založené na LLM přinášejí několik výzev, které odhalují limity tradičních nástrojů:

• Složité, vícekrokové pracovní postupy – Přešli jsme od jednoduchých postupů typu „zavolej model, získej odpověď“ k víceotáčkovým agentům, vícekrokovým kanálům, generování rozšířeného vyhledávání a používání nástrojů. Tiché selhání v kterémkoli z těchto kroků, jako je vyhledávání, obohacení, vkládání, volání nástroje nebo volání modelu, může narušit celý proces. Tradiční monitorování obvykle neposkytuje kompletní pohled na tyto řetězce na úrovni trasování včetně výzev a odpovědí.
• Rychle se vyvíjející balíčky umělé inteligence – Týmy přidávají nové modely, nástroje a dodavatele tempem, jaké dosud neviděly. V mnoha firmách si nikdo nemůže s jistotou ověřit, které modely jsou v daném okamžiku ve výrobě. Klasická pozorovatelnost obvykle předpokládá, že máte čas na instrumentaci SDK, jejich opětovné nasazení a pečlivé třídění toho, co měříte. To jednoduše nedrží krok s tím, jak rychle se umělá inteligence zavádí.
• Ekonomika a kvóty založené na tokenech – Ceny a limity rychlosti jsou vázány na tokeny a délku kontextu, které často řídí vývojáři, výzvy nebo chování uživatelů, nikoli centrální operace. Tradiční nástroje nejsou navrženy tak, aby vám ukazovaly, „kdo spálil kolik tokenů na kterém modelu, pro který pracovní postup a s jakou latencí“.
• Sémantická správnost místo binárního úspěchu – LLM může vrátit chybu 200 a přesto mít halucinace, odchýlit se od zadané nápovědy nebo porušovat zásady. Tradiční nástroje to vnímají jako úspěch. Potřebujete pozorovatelnost, která dokáže odhalit nápovědy a reakce a poskytnout vám dostatek kontextu pro kontrolu chování a postupem času i pro zavedení automatizovaných kontrol kvality.
• Citlivá vstupní data proudící do třetích stran – LLM vyzývají uživatele ke sdílení velmi citlivých informací prostřednictvím rozhraní ve stylu chatu. Nyní jste zodpovědní za tato data, kde jsou uložena a kteří dodavatelé je vidí. Konvenční sledovatelnost založená na SaaS, která veškerou telemetrii předává třetí straně, je pro tyto úlohy často nepřijatelná.

To vše znamená, že systémy LLM vyžadují pozorovatelnost, která je vědoma umělé inteligence, bohatá na kontext 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 systémů LLM, včetně latence, využití tokenů a chování při výzvách/reakcích?

V praxi existuje několik kategorií signálů, které jsou velmi důležité:

Latence a propustnost

• Celková latence na požadavek, včetně modelového času a času okolní aplikace.
• Latence ocasu (P90, P95, P99) pro každý model a každý pracovní postup.
• Propustnost podle modelu, trasy a služby, abyste věděli, kam zátěž skutečně směřuje.

Využití tokenů a faktory ovlivňující náklady

• Vstupní a výstupní tokeny na požadavek, rozdělené podle modelu.
• Agregované využití tokenů v čase podle modelu, týmu, uživatele a pracovního postupu.
• Velikosti kontextu pro náročné kanály načítání, abyste viděli, kdy se výzvy hromadí.
• To vám umožní odpovědět na otázku „Kdo vlastně utrácí náš rozpočet na umělou inteligenci a na co?“

Chování v pohotovosti a odezvě

• Skutečné datové části výzev a odpovědí na reprezentativních trasách, včetně volání nástrojů a cest uvažování.
• Které nástroje se LLM rozhodl volat a v jakém pořadí.
• Rozdíl v odpovědích na podobné výzvy, abyste mohli zjistit, jak stabilní je chování.

Spolehlivost a chyby

• Míry a typy chyb specifické pro daný model (chyby poskytovatele, časové limity, problémy s autorizací, chyby kvót).
• Chyby v okolním pracovním postupu, jako například časové limity nástrojů nebo chyby při načítání, korelovaly s voláním LLM.

Klasický infra kontext

• Metriky využití CPU, paměti a sítě kontejneru pro služby orchestrující volání LLM.
• Korelované protokoly, které popisují, co se aplikace pokoušela udělat.

Když to vše vidíte na jednom místě, pozorovatelnost LLM se posune z „vím, že něco je pomalé nebo drahé“ na „vím přesně, který model, vzorec promptu a služba jsou za to zodpovědné a proč“.

Jak může pozorovatelnost pomoci týmům odhalit tiché selhání, jako je náhlý drift, halucinace nebo postupné snižování kvality výstupu?

K tichým selháním v systémech LLM obvykle dochází, když se na úrovni infrastruktury vše jeví jako „zelené“, ale skutečné chování se odchyluje. Pozorovatelnost pomáhá několika způsoby:

• Sledování celého pracovního postupu, nejen volání modelu – Zachycením celé cesty od požadavku klienta k službě, načtení, modelu a nástrojům můžete vidět, kde se chování změnilo. Například načtení mohlo začít vracet méně dokumentů nebo volání nástroje občas selhává a model improvizuje.
• Sledování výzev, kontextu a reakcí – Když můžete kontrolovat výzvy a odpovědi spolu se trasováním, je mnohem snazší odhalit případy, kdy nová verze výzvy, nová systémová instrukce nebo nový zdroj kontextu změnily chování, i když latence a chybovost zůstaly stejné.
• Filtrování a krájení na základě sémantických podmínek – Jakmile máte k dispozici bohatou telemetrii LLM, můžete filtrovat údaje jako „základní hovory delší než jednu sekundu“, „požadavky používající tuto rodinu modelů“ nebo „stopy zahrnující tuto konkrétní trasu“ a poté si přečíst výzvy a odpovědi, abyste zjistili, zda se model v konkrétním scénáři odchyluje nebo halucinuje.
• Upozorňování na SLO na úrovni podniku – Můžete definovat SLO, například „jakékoli volání LLM delší než jedna sekunda porušuje naši uživatelskou SLA“ a spouštět upozornění, když jsou tyto podmínky splněny. Postupem času lze podobné SLO propojit se skóre kvality nebo kontrolami zásad, takže budete upozorněni i při zhoršení kvality, nejen při selhání infrastruktury.

Protože vrstva pozorovatelnosti má přístup jak k signálům specifickým pro umělou inteligenci, tak k klasickým protokolům, metrikám a trasám, stává se přirozeným místem pro zachycení problémů, které by jinak nenápadně zhoršovaly uživatelský zážitek.

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

Groundcover využívá přístup navržený pro moderní systémy umělé inteligence. Na úrovni jádra používáme senzor založený na eBPF k monitorování provozu napříč mikroslužbami bez změn kódu nebo opětovného nasazení. Jakmile zavedete pracovní postup LLM, můžeme tato volání automaticky objevit. Pokud zítra začnete používat nový model, jako je Anthropic, OpenAI nebo Bedrock, Groundcover tento provoz automaticky zachytí. To vám dává:

• Komplexní trasování víceskokových pracovních postupů – Vidíte celou cestu požadavku napříč službami, včetně případů, kdy je použita LLM nebo nástroj.
• Hluboký kontext každého volání LLM – Každé volání zahrnuje použitý model, latenci, využití tokenů, výzvy, odpovědi a korelované protokoly a metriky infrastruktury.
• Výkonné filtrování podle latence a podmínek – Můžete například filtrovat všechna volání Claude 3.5 delší než jedna sekunda a okamžitě prozkoumat trasy, které porušily vaši SLA.
• Upozornění a dashboardy vázané na chování LLM – Jakmile jsou data k dispozici, můžete vytvářet upozornění na porušení SLA nebo vytvářet dashboardy, které sledují latenci, propustnost, využití tokenů a chyby.

Protože je vše shromažďováno na okraji sítě pomocí eBPF a uloženo ve vašem vlastním cloudu, získáte tento vysoce podrobný pohled, aniž byste museli přidávat instrumentaci do každého volání agenta nebo nástroje.

Jaká rizika v oblasti zabezpečení dat a dodržování předpisů se podle vás objevují v nasazení LLM a jak může sledovatelnost pomoci tato rizika snížit?

Nasazení LLM s sebou nese některá specifická datová rizika:

• Neomezený vstup uživatele – Uživatelé mohou do chatbotů a rozhraní s umělou inteligencí zadávat extrémně citlivé informace. Může se jednat o osobní údaje, údaje o zákaznících nebo regulované informace, které jste nikdy nezamýšleli shromažďovat.
• Poskytovatelé modelů třetích stran – Jakmile tato data odešlete externímu poskytovateli LLM, jste zodpovědní za to, kam se dostala, jak jsou uložena a kteří subzpracovatelé jsou zapojeni. To má zásadní důsledky pro GDPR, umístění dat a důvěru zákazníků.
• Telemetrie jako druhá kopie citlivých dat – Pokud váš observability stack odešle kompletní datové části dodavateli SaaS, máte nyní další kopii těchto citlivých informací mimo vaše prostředí.

Architektura Groundcoveru je navržena tak, aby řešila přesně tyto problémy:

• Používáme cloudový model „přines si vlastní“ (Bring your own cloud), kde backend pro plnou observaci běží uvnitř vašeho cloudového účtu, v podúčtu, jako plně spravovaná datová rovina. Řídicí rovinu, která systém škáluje a spravuje, provozujeme my, ale k vašim telemetrickým datům nepřistupujeme, neukládáme je ani nezpracováváme.
• Protože dokážeme bezpečně zachytit datové části ve vašem vlastním prostředí, můžete sledovat výzvy, odpovědi a pracovní postupy, aniž by tato data kdykoli opustila váš cloud. Neexistuje žádné úložiště vašich LLM tras u třetích stran ani žádné další odesílání dat, o které byste se museli starat.
• Díky tomuto přehledu můžete vidět, kdo co nahrává a kam to běží, detekovat neočekávané použití citlivých dat a vynucovat zásady týkající se povolených modelů a regionů.

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í, uchovávání dat a dodržování předpisů.

S tím, jak organizace přecházejí z jedné integrace LLM na mnoho služeb založených na umělé inteligenci, se obvykle objevují provozní výzvy týkající se přehlednosti, spolehlivosti a nákladů?

První integrace obvykle zahrnuje jeden model v jednom pracovním postupu. V této fázi se věci zdají být zvládnutelné. Jakmile týmy vidí hodnotu, jejich využití prudce vzroste a objeví se několik problémů:

• Rozrůstání modelů a dodavatelů – Týmy neustále testují nové modely. Rychle se stane nejasným, které z nich jsou ve výrobě a jak se používají.
• Překvapivé náklady z používání tokenů – Spotřeba tokenů roste s délkou kontextu a složitostí pracovního postupu. Bez přehledu o využití tokenů v jednotlivých modelech a pracovních postupech je řízení nákladů velmi obtížné.
• Závislost spolehlivosti na externích dodavatelích – Uživatelská API se stávají citlivými na latenci modelu nebo chyby, což může narušit SLA, i když je základní infrastruktura v pořádku.
• Rostoucí dluh z instrumentace – Tradiční pozorovatelnost předpokládá, že můžete v případě potřeby přidat instrumentaci. V rychle se rozvíjejících systémech umělé inteligence na to vývojáři jen zřídka mají čas.

Groundcover tyto problémy řeší automatickým vyhledáváním provozu s využitím umělé inteligence a následným poskytnutím:

• Centrální přehled o tom, které modely a dodavatelé se používají.
• Dashboardy zobrazující latenci, propustnost a využití tokenů v čase.
• Korelace mezi chováním LLM a službami, které na něm závisí
• Upozornění na narušení SLO z důvodu umělé inteligence.

Díky tomu je mnohem snazší přejít od „jedné skvělé funkce umělé inteligence“ k „umělá inteligence je vetkána do desítek klíčových služeb“, aniž by došlo ke ztrátě kontroly.

Jak se podle vás bude v příštích pěti letech vyvíjet pozorovatelnost LLM s tím, jak se zrychluje rozvoj agentní umělé inteligence, multimodelové orchestrace a regulačních tlaků?

Jsme stále v začátcích. Během příštích pěti let očekávám několik velkých změn:

• Od úrovně požadavku k porozumění na úrovni agenta – Pozorovatelnost se rozšíří tak, aby zachytila ​​sekvence nástrojů, cesty uvažování a logiku opakování, nejen volání modelů.
• Bohatší sémantické a politické signály – Standardními metrikami se stanou automatizované kontroly kvality halucinací, bezpečnostních problémů a shody se značkou.
• Užší propojení se správou a ochranou soukromí – S rostoucí regulací bude pozorovatelnost sloužit také jako vrstva vynucování a auditu pro umístění dat, uchovávání a schválené používání modelů.
• Cross model, optimalizace pro více dodavatelů – Týmy budou dynamicky směrovat provoz mezi modely na základě výkonu a nákladů, a to na základě pozorovatelných dat v reálném čase.
• Méně manuální instrumentace – Techniky jako sběr dat založený na eBPF a automatické vyhledávání se stanou výchozími, aby týmy mohly inovovat bez zpomalení.

Stručně řečeno, pozorovatelnost LLM se vyvine z „příjemného mít dashboardy pro AI“ do centrálního nervového systému, který propojuje spolehlivost, kontrolu nákladů, správu dat a kvalitu produktů napříč vším, co organizace s AI dělá.

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