Jeff Champagne, Field CTO ve společnosti Cribl – Interview Series

Jeff Champagne, Field CTO ve společnosti Cribl, má hluboké zkušenosti v oblasti sledovatelnosti, podnikových dat, produktové strategie a technické architektury. Předtím, než se připojil k Criblu, působil jako ředitel produktového managementu ve společnosti Databricks a strávil více než sedm let ve společnosti Splunk na seniorních pozicích v oblasti produktu, architektury a globálního systémového inženýrství. Jeho zkušenosti také zahrnují vedení systémové architektury ve společnosti BNY ConvergEx, seniorní inženýrskou práci ve společnosti Premier Technology Solutions a ranou inženýrskou práci ve společnosti Assist-2-Sell, což mu dává široký přehled o tom, jak podniky shromažďují, spravují, analyzují a činí rozhodnutí na základě provozních dat v rozsahu.

Cribl je podniková společnost pro telemetrii, která se zaměřuje na pomoc týmům IT, bezpečnosti, SRE a DevOps při shromažďování, zpracování, směrování, ukládání a analýze dat sledovatelnosti a bezpečnosti bez uzamčení do jediného dodavatele. Společnost se prezentuje jako „AI platforma pro telemetrii“, s produkty jako Cribl Stream pro sběr telemetrie v reálném čase, Cribl Edge pro sběr telemetrie na koncových bodech, Cribl Search pro vyhledávání dat na místě a Cribl Lake pro úložiště. Jejich širší mise je dát podnikům více kontroly, flexibility a efektivity, jak rostou objemy telemetrie a operace poháněné umělou inteligencí vyžadují čistější a přístupnější data.

Máte zkušenosti z práce ve společnostech Splunk, Databricks a nyní Cribl, což vám dává vzácný pohled na podniková data, sledovatelnost a infrastrukturu napříč několika technologickými cykly. Z tohoto pohledu, co se zdá skutečně odlišné o výzvě sledovatelnosti vytvořené agenty s umělou inteligencí?

V oblasti sledovatelnosti aplikací jsme vždy řešili složitou, větvící se cestu provádění, stopování požadavků přes mikroslužby a korelování protokolů napříč distribuovanými systémy. V bezpečnostních operacích jsme řešili vysoké objemy, rozdílné zdroje dat pro detekci hrozeb napříč systémy, které, i když jsou složité, se chovají převážně předvídatelným způsobem. Agenci s umělou inteligencí nevytvářejí žádnou z těchto problémů; spíše je explozivně zvětšují.

Agenti řetězí rozhodnutí, vyvolávají externí nástroje a dynamicky spouštějí sub-agenty způsoby, které nejsou předem stanoveny v době psaní. Grafový diagram provádění není jen složitý, ale může být také velmi odlišný každým okamžikem, a objem telemetrie potřebné pro rekonstrukci toho, co se skutečně stalo, roste exponenciálně s každým krokem. Shromažďování veškeré telemetrie potřebné pro to, aby agenci mohli být sledováni, musí být jak snadno instrumentovatelné, tak i nákladově efektivní pro provoz v rozsahu. Jinak podniky budou dělat stejné ústupky, které vždy dělaly, a sníží viditelnost, aby kontrolovaly náklady — přesně ve špatnou dobu, aby oslepily.

Jaké jsou největší mezery ve viditelnosti mezi tím, co je agentovi uloženo, a tím, co se skutečně děje napříč základními systémy, když podniky začleňují autonomní agenty do pracovních postupů?

Agenti dokončují pracovní postupy, které na povrchu vypadají úspěšně, zatímco potichu dělají špatné volání nástrojů, halucinují parametry nebo se odchylují od původního cíle. Následky se často projeví později v jiném systému.

Odpojení obvykle začíná u interpretace: malá nejednoznačnost v původním pokynu se vyřeší jinak v závislosti na tom, co agent načte z paměti, které nástroje jsou k dispozici v daném okamžiku, nebo jak předchozí krok v řetězci ovlivnil jeho kontext. Musíte také instrumentovat downstream systémy, na které se agent spoléhá, protože agent může udělat dokonale vytvořený databázový volání a přesto vrátit špatnou odpověď, pokud podkladová tabulka nebyla nikdy aktualizována, protože ETL úloha selhala potichu upstream.

Agent udělal přesně to, co mu bylo uloženo; data, kterým důvěřoval, byla prostě zastaralá.

Proč jsou tradiční nástroje sledovatelnosti často nedostatečné pro monitorování agenticích systémů s umělou inteligencí?

Nejprve byly postaveny kolem rigidních, proprietárních schémat a předvídatelných tvarů dat. Agenci s umělou inteligencí se těmto očekáváním nevyhovují — jsou objemné, vysoce variabilní ve struktuře a zahrnují datové typy, jako je plný textový prompt, řetězce modelového rozumu a datové náklady nástrojů, které tradiční nástroje nebyly navrženy k ingestování bez významné transformační práce. Otevřené standardy, jako jsou sémantické konvence OpenTelemetry’s GenAI, se objevují, aby řešily tento problém, ale mnoho legacy platforem nebylo postaveno tak, aby z nich těžit.

Druhým důvodem je, že rovnice rozsahu a nákladů se rychle rozpadá. Jeden agent, který zpracovává produkční zátěž, může vygenerovat více telemetrie za hodinu, než celý aplikační stack za den, a většina tradičních platforem účtuje za objem ingestované a uložené telemetrie. To vytváří nemožnou kompromis — buď instrumentovat vše a čelit nákladům, nebo snížit viditelnost do systémů, kde ji nejvíce potřebujete.

Jak mohou organizace určit, zda kořenová příčina selhání agenta byla modelem, vrstvou načítání, závislostí API, problémem s oprávněním nebo problémem s downstream infrastrukturou?

Určení kořenové příčiny selhání agenta je proces eliminace napříč vrstvami. To funguje pouze tehdy, pokud vaše telemetrie pokrývá všechny tyto vrstvy konzistentně. Signály latence a chyby na modelových rozhraních ukazují na samotný model. Rozhraní načítání ukazují, zda kontext vrácený byl relevantní nebo zastaralý. Volání nástrojů odhalují selhání závislostí API nebo chyby oprávnění.

Jak bylo zmíněno, potřebujete také telemetrii ze downstream systémů, na které se agent spoléhá, protože agent může udělat dokonale vytvořený volání a přesto vyprodukovat špatnou odpověď, pokud data, kterým důvěřoval, nebyla nikdy aktualizována. Žádný jediný signál nevypráví celou historii, a proto korelace napříč všemi těmito vrstvami na jednom místě je to, co odlišuje týmy, které mohou rychle diagnostikovat selhání agentů, od těch, které stále hádají.

Jaké typy telemetrických dat se stávají nejdůležitějšími, když podniky se snaží porozumět chování agentů v rozsahu?

Základním kamenem je stále MELT — metriky, události, protokoly a stopy — ale váha se značně posune, když se přesunete do agenticích systémů. Metriky vám říkají, že něco je špatně, a protokoly vám dávají surový záznam toho, co se stalo, ale ani jeden z nich nemůže rekonstruovat řetězec rozumu, který agent následoval, aby dospěl k špatné odpovědi. To je místo, kde stopy se stávají nejkritičtějším signálem.

V tradičním distribuovaném systému stopa ukazuje, jak se požadavek pohyboval napříč službami. V agenticím systému ukazuje, jak model řešil problém, které nástroje vyvolal, jaký kontext načítal, kde se větvil a co rozhodl na každém kroku. Bez této stopy se díváte na výstup bez možnosti vysvětlit, jak jste se tam dostali.

Ostatní signály MELT nezmizí; metriky na využití tokenů a latenci jsou důležité pro náklady a výkon, a protokoly ze downstream systémů zůstávají nezbytné. Ale stopy jsou to, co činí chování agentů čitelnými v rozsahu.

Mnohé diskuse o umělých inteligencích se stále soustředí silně na halucinace. Podceňují podniky operační selhání, jako jsou špatné načítání, rozbité integrace, latence nebo chybějící kontext?

Most halucinací ve výrobě nejsou selháním modelu; jsou operačními selháními v přestrojení. Špatné načítání vrátí zastaralý nebo neúplný kontext, a model vyplní mezeru něčím, co zní přesvědčivě. Rozbitá integrace znamená, že agent nikdy nezískal data, která potřeboval k rozumnému rozhodnutí, a chybějící kontext z selhané ETL úlohy vypadá jako halucinace, ale ve skutečnosti je to infrastrukturní problém.

Když týmy nevidí rozdíl, defaultují na to, co mohou ovládat, což je obvykle samotný model. Iterují na systémech promptů, přidávají ochranné lišty a rafinují evaluační rámce, a zatímco tyto techniky mají skutečnou hodnotu, řeší symptom spíše než příčinu. Z mé zkušenosti je nejvyšší investice téměř vždy kvalita a čerstvost dat ve vrstvě načítání. Dobře založený agent s čistými, aktuálními daty bude vždy outperformovat agenta, který je těžce promptován a pracuje se zastaralým nebo neúplným kontextem.

Jak by měly podnikové týmy logovat, stopovat nebo monitorovat, aby udržely odpovědnost bez toho, aby se zahltili hlukem?

Základním kamenem je stále MELT, ale odpovědnost za agenticí systémy vyžaduje vrstvení evaluačního rámce na top tradiční telemetrie. Metriky, události a protokoly odhalují infrastrukturní selhání a rozbité integrace, které mohou znečistit chování agenta, než model zareaguje; stopy vám dávají řetězec rozumu, aby rozuměli, proč dospěl k určité odpovědi. Ale ani jeden z nich vám neřekne, zda odpověď byla skutečně správná, a to je místo, kde LLM-as-judge evaluation vyplňuje mezeru. Stejné AI schopnosti, které pohánějí agenty, lze použít k jejich hodnocení, bodování výstupů pro přesnost, zakotvení a dokončení úkolu v rozsahu, který žádný lidský proces nemůže zvládnout.

Před výrobou to funguje jako kvalitní brána, chytající regrese předtím, než se dostanou k uživatelům. Ve výrobě se stává kontinuálním monitorem, který vzorkuje živý provoz a signalizuje odpovědi, které spadají mimo přijatelné prahové hodnoty. Klíčem k tomu, aby se zabránilo hluku, je uznání toho, že ne každý agentní workflow nese stejná rizika, což znamená přechod od uniformního monitorování k něčemu, co průmysl začíná nazývat lidskou smyčkou. Definujete behaviorální bazény a prahové hodnoty dopředu, necháte agenty operovat a rezervujete lidskou intervenci pro výjimky.

Jakou roli mohou telemetrické potrubí sehrát při pomoci bezpečnostním, SRE, datovým a AI týmům pracovat z sdíleného pohledu na chování agentů?

Bezpečnostní týmy, SRE, datoví inženýři a AI týmy se dívají na různé řezy stejného problému prostřednictvím různých nástrojů, a žádný z nich nemá úplný obrázek sám o sobě. Důvod, proč se telemetrická potrubí stala standardní součástí moderní podnikové datové architektury, je, že řeší přesně tento problém: jednoduché, dobře spravované potrubí nad všemi nástroji zajišťuje, že každý tým pracuje se stejnými normalizovanými, obohacenými daty bez speciálních agentů a sběračů nasazených pro každý tým.

Tato flexibilita má význam na dvou úrovních. První je tiering dat. Dobře navržené telemetrické potrubí umožňuje vám přizpůsobit data správné strategii úložiště a analýzy, abyste neplatili ceny analytické úrovně za data, která potřebujete pouze pro dlouhodobou retenci souladu. Druhá je možnost, jakmile se AI nástrojový krajina bude dále rychle vyvíjet. Podniky, které postaví svou strategii sledovatelnosti kolem ekosystému jediného dodavatele, budou čelit drahým migračním projektům, kdykoli se objeví lepší nástroj.

Jaké chyby vidíte podniky dělat, když se snaží přizpůsobit stávající monitorovací postupy na agenticí systémy s umělou inteligencí?

Nejčastější chyba, kterou vidím, je sahání po stávajících premium platformách pro sledovatelnost, aby shromáždily agenticí stopy, aniž by se nejprve zamysleli nad náklady. Agenticí stopy jsou velké, variabilní a objemné způsoby, které tradiční aplikační telemetrie nejsou, a většina premium platforem účtuje za ingestovanou a uloženou telemetrii. Faktura se může stát vážným problémem, než týmy vůbec uvědomí, co se děje, a typická odpověď je snížit to, co shromažďují. Výsledkem je nejhorší z obou světů: vysoké náklady a neúplná viditelnost.

Druhou chybou je aplikování nesprávného mentálního modelu na to, co by mělo být monitorováno. Tradiční infrastrukturní monitorování se ptá „Je systém up?“ a vyvolává upozornění, když tomu tak není. Tato otázka je nezbytná, ale je daleko od dostatečné pro agenticí systémy, kde infrastruktura může být dokonale zdravá, zatímco agent potichu dělá špatná rozhodnutí, načítá zastaralá data nebo se odchyluje od svého původního cíle. Týmy, které přizpůsobují stávající dashboardy a prahové hodnoty na agentní workflow, často přesvědčují sami sebe, že mají pokrytí, zatímco ve skutečnosti sledují pouze „potrubí“.

Třetí chybou je, že se instrumentace bere jako věc, která se udělá později. Podniky, které pilotují agenty rychle a přecházejí do výroby, aniž by se zamyslely nad sledovatelností, nakonec skončí v drahých cyklech oprav. Týmy, které úspěšně škálují nasazení agentů, instrumentují brzy, stanovují bazény, zatímco provoz je nízký a chování je předvídatelné, a budují svůj evaluační rámec, než ho potřebují, spíše než až poté, co něco půjde špatně.

Pohledem do budoucnosti, stane se infrastrukturní viditelnost předpokladem pro podnikovou adopci umělých inteligencí, stejně jako se sledovatelnost cloudu stala nezbytnou pro velká cloudová migrace?

Paralela s cloudem je extrémně podobná. Nejdůležitější věc, kterou říkám zákazníkům, když přesouvají infrastrukturu do cloudu, je, že nejsou „lifting a shifting“. Nasazují zcela novou architekturu s novými schopnostmi. Všechno to musí být instrumentováno a monitorováno způsoby, pro které předchozí nástroje nebyly nastaveny. Podniky, které přeskočily tento krok, narazily na kaskádové selhání, které nemohly diagnostikovat, spirálové náklady, které nemohly vysvětlit, a výpadky, které nemohly zabránit. Sledovatelnost se stala základem důvěry, který umožnil cloudové škálování, a stejný vzorec se nyní odehrává s agenticí umělou inteligencí, rychleji a s vyššími sázkami.

Hlavním důvodem, proč agenti budou potřebovat tento typ dohledu trvale, je, že jsou nepredikovatelní podle designu, jejich chování se objevuje v době běhu, a jejich efektivní schopnost roste pokaždé, když se připojí nový nástroj. Statická certifikace před nasazením nemůže pokrýt systém, jehož akční povrch se mění s každou integrací. Agenti budou operovat v definovaných hranicích důvěry, a tyto hranice se budou rozšiřovat, jakmile se sledovatelnost, politika a evaluační infrastruktura zrát. Tyto hranice samy o sobě nikdy nezmizí, a to není stav selhání. Je to, jak fungují všechny významné autonomní systémy na světě.

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