Jeff Champagne, Field CTO w firmie Cribl – seria wywiadów

Jeff Champagne, Field CTO w firmie Cribl, posiada bogate doświadczenie w zakresie obserwowalności, danych przedsiębiorstw, strategii produktów i architektury technicznej. Przed dołączeniem do Cribl pełnił funkcję Dyrektora Zarządzającego Produktami w Databricks i spędził ponad siedem lat w Splunk, gdzie zajmował się stanowiskami związanymi z produktem, architekturą i inżynierią systemów globalnych. Jego doświadczenie obejmuje również kierownictwo w dziedzinie architektury systemów w BNY ConvergEx, pracę inżynierską w Premier Technology Solutions oraz wczesne doświadczenie w dziedzinie inżynierii w Assist-2-Sell, co daje mu szeroką perspektywę na to, jak przedsiębiorstwa gromadzą, zarządzają, analizują i podejmują działania w oparciu o dane operacyjne w skali.

Cribl to przedsiębiorstwo telemetryczne, które koncentruje się na pomocy zespołom IT, bezpieczeństwa, SRE i DevOps w zbieraniu, przetwarzaniu, trasowaniu, przechowywaniu i analizie danych obserwowalności i bezpieczeństwa bez blokowania się na jednego dostawcę. Firma pozycjonuje się jako „Platforma AI dla Telemetrii”, z produktami takimi jak Cribl Stream do zbierania, redukcji, wzbogacania i trasowania telemetrycznych danych w czasie rzeczywistym; Cribl Edge do zbierania telemetrycznych danych punktów końcowych w sposób niezależny od dostawcy; Cribl Search do wyszukiwania danych na miejscu; oraz Cribl Lake do przechowywania. Jej szerszym celem jest dać przedsiębiorstwom więcej kontroli, elastyczności i wydajności, gdy objętość telemetrycznych danych rośnie, a operacje napędzane przez AI wymagają czystszych, bardziej dostępnych danych.

Pracowałeś w Splunk, Databricks i teraz w Cribl, co daje ci rzadką perspektywę na dane przedsiębiorstw, obserwowalność i infrastrukturę na przestrzeni wielu cykli technologicznych. Z tej perspektywy, co naprawdę różni się w wyzwaniu obserwowalności stworzonym przez AI-agenty?

W obserwowalności aplikacji zawsze mieliśmy do czynienia z złożonymi, rozgałęzionymi ścieżkami wykonania, śledzeniem żądań przez mikrousługi i korelacją logów w systemach rozproszonych. W operacjach bezpieczeństwa zajmowaliśmy się źródłami danych o dużej objętości i rozproszeniu, aby wykryć zagrożenia w systemach, które, choć złożone, zachowują się w większości przewidywalnie. AI-agenci nie zmieniają tych problemów; wybuchają je jednocześnie.

Agenci łączą decyzje, wywołują zewnętrzne narzędzia i dynamicznie tworzą pod-agenci w sposób, który nie jest określony w czasie pisania. Graf wykonania nie jest tylko złożony, ale może być dzikko inny za każdym razem, a objętość telemetrycznych danych wymaganych do odtworzenia tego, co się naprawdę stało, rośnie wykładniczo z każdym skokiem. Zbieranie wszystkich telemetrycznych danych niezbędnych do uczynienia systemów agenticznych obserwowalnymi musi być zarówno łatwe w instrumentacji, jak i efektywne w kosztach, aby działać w skali. W przeciwnym razie przedsiębiorstwa będą dokonywać tego samego kompromisu, jaki zawsze robili, i zmniejszą widoczność, aby kontrolować koszty — dokładnie w najgorszym momencie, aby stracić wzrok.

Gdzie są największe luki widoczności między tym, co agent AI jest poproszony o zrobienie, a tym, co naprawdę dzieje się w podstawowych systemach, gdy przedsiębiorstwa wbudowują agenci autonomiczne w swoje przepływy pracy?

Agenci kończą przepływy pracy, które wyglądają na powodzenie na powierzchni, podczas gdy cicho robią złe wywołania narzędzi, halucynują parametry lub odbiegają od pierwotnego celu. Konsekwencje często pojawiają się godziny później w innym systemie.

Rozłączenie zwykle zaczyna się od interpretacji: niewielka niejasność w oryginalnej instrukcji zostaje rozwiązana inaczej w zależności od tego, co agent pobiera z pamięci, jakie narzędzia są dostępne w tym momencie, lub jak poprzedni krok w łańcuchu ukształtował jego kontekst. Musisz również zinstrumentować systemy podrzędne, od których zależy agent, ponieważ agent może wykonać idealnie sformatowane wywołanie bazy danych i nadal zwrócić błędną odpowiedź, jeśli podstawowa tabela nigdy nie została odświeżona, ponieważ zadanie ETL nie powiodło się cicho w górę.

Agent zrobił dokładnie to, o co został poproszony; dane, którym ufał, były po prostu nieświeże.

Dlaczego tradycyjne narzędzia obserwowalności są często niewystarczające do monitorowania systemów AI-agenticznych?

Po pierwsze, zostały one zbudowane wokół sztywnych, własnościowych schematów i przewidywalnych kształtów danych. Ślady agenticzne nie spełniają tych oczekiwań — są objętościowe, bardzo zróżnicowane pod względem struktury i zawierają typy danych, takie jak pełny tekst podpowiedzi, łańcuchy rozumowania modelu i ładunki wywołań narzędzi, których legacy narzędzia nie zostały zaprojektowane, aby je bez znaczącej pracy przekształcającej. Otwarte standardy, takie jak semantyczne konwencje GenAI OpenTelemetry, pojawiają się, aby rozwiązać ten problem, ale wiele platform legacy nie zostało zbudowanych, aby skorzystać z nich.

Po drugie, równanie skali i kosztów rozpadają się szybko. Jeden agent obsługujący obciążenia produkcyjne może wygenerować więcej telemetrycznych danych w ciągu godziny niż cały stos aplikacji wyprodukował w ciągu dnia, a większość tradycyjnych platform pobiera opłaty za objętość pobraną i przechowywaną. To tworzy niemożliwy kompromis — albo zinstrumentuj wszystko i zmierzyć się z kosztami ucieczki, albo zmniejsz widoczność w systemach, w których potrzebujesz jej najbardziej.

Gdy agent AI zawiedzie, jak mogą organizacje określić, czy przyczyną było model, warstwa pobierania, zależność API, problem z uprawnieniami czy problem infrastruktury podrzędnej?

Wyizolowanie przyczyny pierwotnej awarii agenticznej jest procesem eliminacji warstw. Działa tylko wtedy, gdy Twoja telemetria obejmuje wszystkie warstwy w sposób ciągły. Sygnały opóźnienia i błędów na zakresie modelu wskazują na sam model. Zakresy pobierania mówią Ci, czy kontekst zwrócony był istotny czy nieświeży. Zakresy wywołań narzędzi ujawniają nieudane zależności API lub błędy uprawnień.

Jak już wspomniano, potrzebujesz również telemetrycznych danych z systemów podrzędnych, od których zależy agent, ponieważ agent może wykonać idealnie sformatowane wywołanie i nadal wyprodukować błędną odpowiedź, jeśli dane, którym ufał, nigdy nie zostały odświeżone. Żaden sygnał nie opowiada całej historii, dlatego korelowanie we wszystkich tych warstwach w jednym miejscu jest tym, co różni zespoły, które mogą szybko debugować awarie agenticzne, od tych, które nadal zgadują.

Jakie rodzaje danych telemetrycznych stają się najważniejsze, gdy przedsiębiorstwa próbują zrozumieć zachowanie agenta w skali?

Podstawą jest nadal MELT — metryki, zdarzenia, logi i ślady — ale waga przechyla się znacznie, gdy przechodzisz do systemów agenticznych. Metryki mówią Ci, że coś jest nie tak, a logi dają Ci surowy zapis tego, co się stało, ale żadne z nich nie mogą odtworzyć łańcucha rozumowania, który agent podążał, aby dojść do błędnej odpowiedzi. To jest tam, gdzie ślady stają się najbardziej krytycznym sygnałem.

W tradycyjnym systemie rozproszonym ślad pokazuje Ci, jak żądanie przeszło przez usługi. W systemie agenticznym pokazuje Ci, jak model rozumu przez problem, które narzędzia wywołał, jaki kontekst pobrał, gdzie rozgałęził się i co zdecydował na każdym kroku. Bez tego śladu patrzysz na wyjście bez możliwości wyjaśnienia, jak tam dotarłeś.

Inne sygnały MELT nie znikają; metryki dotyczące użycia tokenów i opóźnień mają znaczenie dla kosztów i wydajności, a logi z systemów podrzędnych pozostają niezbędne. Ale ślady są tym, co czyni zachowanie agenta czytelnym w skali.

Wiele dyskusji o AI nadal koncentruje się ciężko na halucynacjach. Czy przedsiębiorstwa zaniżają awarie operacyjne, takie jak złe pobierania, złamane integracje, skoki opóźnienia lub brakujący kontekst?

Większość halucynacji w produkcji nie jest awarią modelu; są to awarie operacyjne w przebraniu. Złe pobieranie zwraca nieświeży lub niepełny kontekst, a model wypełnia tę lukę czymś, co brzmi prawdopodobnie. Złamana integracja oznacza, że agent nigdy nie otrzymał danych, których potrzebował, aby podejmować decyzje w sposób prawidłowy. Brakujący kontekst z powodu nieudanego zadania ETL wygląda jak halucynacja, ale jest to naprawdę problem infrastruktury.

Gdy zespoły nie mogą zobaczyć różnicy, domyślają się tego, co mogą kontrolować, co zwykle jest modelem samym w sobie. Iterują systemy podpowiedzi, dodają barierki ochronne i doskonalą ramy oceny, i chociaż te techniki mają realną wartość, leczą objaw, a nie przyczynę. W moim doświadczeniu najbardziej opłacalne inwestycje to prawie zawsze jakość i świeżość danych w warstwie pobierania. Dobrze ugruntowany agent z czystymi, bieżącymi danymi będzie wykonywał lepiej niż jeden z ciężko zaprojektowanymi podpowiedziami, pracującym z nieświeżym lub niepełnym kontekstem.

Gdy agenci stają się bardziej autonomiczni, co powinny zespoły przedsiębiorstw rejestrować, śledzić lub monitorować, aby utrzymać odpowiedzialność, nie zalewając się hałasem?

Podstawą jest nadal MELT, ale odpowiedzialność za systemy agenticzne wymaga nałożenia ramy oceny na tradycyjną telemetrię. Metryki, zdarzenia i logi ujawniają awarie infrastruktury i złamane integracje, które mogą skazić zachowanie agenta przed odpowiedzią modelu; ślady dają Ci łańcuch rozumowania, aby zrozumieć, dlaczego doszedł do pewnej odpowiedzi. Ale żadne z nich nie mówią Ci, czy odpowiedź była naprawdę poprawna, i to jest tam, gdzie ocena LLM-as-sędzia wypełnia lukę. Te same możliwości AI, które napędzają agenci, mogą być użyte do oceny ich, oceniania wyjść pod kątem dokładności, ugruntowania i ukończenia zadania w skali, której żaden proces przeglądu ludzkiego nie może dorównać.

Przed produkcją działa jako brama jakości, łapiąc regresje przed tym, jak dotrą do użytkowników. W produkcji staje się ciągłym monitorem, próbkującym ruchu na żywo i flagującym odpowiedzi, które spadają poza akceptowalne progi. Kluczem do uniknięcia hałasu jest uznanie, że nie każdy przepływ pracy agenta niesie ze sobą takie same ryzyko, co oznacza odejście od jednolitego monitorowania w stronę czegoś, co branża zaczyna nazywać pętlą-ludzką governance. Definiujesz wzorce zachowania i progi ufności z wyprzedzeniem, pozwalasz agentom działać, i rezerwujesz interwencję ludzką dla wyjątków.

Jaką rolę mogą odegrać potoki telemetryczne w pomaganiu zespołom bezpieczeństwa, SRE, danych i AI w pracy z wspólnym widokiem zachowania agenta?

Zespoły bezpieczeństwa, SRE, inżynierowie danych i zespoły AI patrzą na różne plasterki tego samego problemu przez różne narzędzia, i żaden z nich nie ma pełnego obrazu samodzielnie. Powodem, dla którego potoki telemetryczne stały się standardową częścią nowoczesnej architektury danych przedsiębiorstwa, jest to, że rozwiązują dokładnie ten problem: jeden dobrze zarządzany potok w górę strumienia wszystkich Twoich narzędzi zapewnia, że każdy zespół pracuje z tymi samymi znormalizowanymi, wzbogaconymi danymi bez specjalnych agentów i kolektorów wdrożonych dla każdego zespołu.

To elastyczność ma znaczenie na dwóch poziomach. Po pierwsze, jest to warstwowanie danych. Dobrze zaprojektowany potok telemetryczny pozwala Ci dopasować dane do odpowiedniej strategii przechowywania i analizy, abyś nie płacił cen analitycznych za dane, których potrzebujesz tylko do długoterminowego przechowywania zgodności. Po drugie, jest to opcjonalność, gdy krajobraz narzędzi AI nadal ewoluuje szybko. Przedsiębiorstwa, które budują swoją strategię obserwowalności wokół ekosystemu jednego dostawcy, będą musiały stawić czoła kosztownym projektom migracji za każdym razem, gdy pojawia się lepsze narzędzie.

Jakie błędy widzisz przedsiębiorstwa popełniające, gdy próbują przerobić istniejące praktyki monitorowania na wdrożenia AI-agenticzne?

Najczęstszym błędem, który widzę, jest sięganie po istniejące premium platformy obserwowalności, aby zebrać ślady agentów, nie myśląc przez implikacje kosztowe. Ślady agenticzne są duże, zróżnicowane i objętościowe w sposób, w jaki tradycyjna telemetria aplikacji nie jest. Większość platform premium pobiera opłaty za pobranie i przechowywanie. Rachunek może stać się poważnym problemem, zanim zespoły nawet zrozumieją, co się dzieje, a typowa odpowiedź jest zmniejszenie tego, co zbierają. Rezultatem jest najgorszy z obu światów: wysoki koszt i niepełna widoczność.

Drugim błędem jest zastosowanie niewłaściwego modelu myślowego do tego, co monitorowanie ma odpowiedzieć. Tradycyjne monitorowanie infrastruktury pyta „Czy system jest w górę?” i podnosi alerty, gdy nie jest. To pytanie jest konieczne, ale nie jest nawet blisko wystarczające dla systemów agenticznych, gdzie infrastruktura może być idealnie zdrowa, podczas gdy agent cicho podejmuje złe decyzje, pobiera nieświeże dane lub odbiega od swojego pierwotnego celu. Zespoły, które przerabiają istniejące pulpity i progi alarmowe na przepływy pracy agentów, często przekonują się, że mają pokrycie, kiedy tak naprawdę tylko obserwują rury.

Trzecim błędem jest traktowanie instrumentacji jako rzeczywistości. Przedsiębiorstwa, które pilotażowo wprowadzają agenci szybko i przechodzą do produkcji bez przemyślenia obserwowalności, kończą się w kosztownych cyklach remediacji, odbudowując architekturę zbierania danych po pierwszym znaczącym awarii produkcyjnej. Zespoły, które skalują wdrożenia agentów najbardziej skutecznie, zinstrumentują wcześnie, ustanowią podstawy, gdy ruch jest niski i zachowanie jest przewidywalne, i zbudują swoją ramę oceny, zanim będą jej potrzebować, a nie po tym, jak coś pójdzie nie tak.

Spójrzając w przyszłość, czy widoczność infrastruktury stanie się warunkiem wstępnym dla przyjęcia AI przez przedsiębiorstwa w tym samym sposób, w jaki obserwowalność w chmurze stała się niezbędna dla dużych migracji chmurowych?

Porównanie do chmury jest niezwykle podobne. Najważniejszą rzeczą, którą mówię klientom, gdy przenoszą infrastrukturę do chmury, jest to, że nie przenoszą i nie przenoszą. Wdrażają nową architekturę z nowymi możliwościami. Wszystko to musi być zinstrumentowane i monitorowane w sposób, w jaki poprzednie narzędzia nie były ustawione. Przedsiębiorstwa, które pominęły ten krok, napotkały na awarie w kaszkach, których nie mogły zdiagnozować, koszty spiralne, których nie mogły wyjaśnić, i awarie, których nie mogły zapobiec. Obserwowalność stała się fundamentem zaufania, który uczynił skalę chmury możliwą, i ten sam wzorzec rozgrywa się teraz z AI-agencjami, poruszając się szybciej i z wyższymi stawkami.

Głównym powodem, dla którego agenci będą potrzebować tego rodzaju nadzoru niezależnie, jest to, że są nieprzewidywalne z założenia, ich zachowanie pojawia się w czasie wykonywania, a ich skuteczna zdolność rośnie za każdym razem, gdy łączysz nowe narzędzie. Statyczna certyfikacja przed wdrożeniem nie może pokryć systemu, którego powierzchnia działania zmienia się z każdą integracją. Agenci będą działać w określonych granicach zaufania, a te granice będą się rozszerzać z czasem, gdy infrastruktura obserwowalności, polityki i oceny dojrzeje. Same granice nigdy nie znikną, i to nie jest stan awarii. To jest to, jak każdy znaczący autonomiczny system na świecie już działa.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Cribl.