Jeff Champagne, Field CTO la Cribl – Seria de interviuri

Jeff Champagne, Field CTO la Cribl, aduce o experiență profundă în domeniul observabilității, al datelor enterprise, al strategiei de produs și al arhitecturii tehnice. Înainte de a se alătura Cribl, el a ocupat funcția de Director de Management al Produsului la Databricks și a petrecut mai mult de șapte ani la Splunk în roluri de produs, arhitectură și inginerie de sisteme globale. Experiența sa include, de asemenea, conducerea arhitecturii de sisteme la BNY ConvergEx, lucrul de inginerie senior la Premier Technology Solutions și conducerea ingineriei la Assist-2-Sell, ceea ce îi oferă o perspectivă largă asupra modului în care întreprinderile colectează, gestionează, analizează și acționează pe baza datelor operaționale la scară.

Cribl este o companie de telemetrie enterprise care se concentrează pe ajutarea echipelor IT, securitate, SRE și DevOps să colecteze, să proceseze, să direcționeze, să stocheze și să analizeze datele de observabilitate și securitate fără a fi blocate într-un singur furnizor. Compania se poziționează ca “Platforma de Inteligență Artificială pentru Telemetrie”, cu produse precum Cribl Stream pentru colectarea, reducerea, îmbogățirea și direcționarea telemetriei în timp real; Cribl Edge pentru colectarea telemetriei de la punctele de capăt neutre din punct de vedere al furnizorului; Cribl Search pentru căutarea datelor în loc; și Cribl Lake pentru stocare. Misiunea sa mai largă este de a oferi întreprinderilor mai mult control, flexibilitate și eficiență pe măsură ce volumul de telemetrie crește și operațiunile conduse de inteligență artificială necesită date mai curate și mai accesibile.

Ați lucrat în domeniul Splunk, Databricks și acum Cribl, ceea ce vă oferă o perspectivă rară asupra datelor enterprise, observabilității și infrastructurii pe multiple cicluri tehnologice. Din această perspectivă, ce pare cu adevărat diferit despre provocarea observabilității create de inteligența artificială agentică?

În observabilitatea aplicațiilor, am tratat întotdeauna cu căi de execuție complexe și ramificate, urmărind solicitări prin microservicii și corelând jurnale de-a lungul sistemelor distribuite. În operațiunile de securitate, am abordat surse de date de volum mare și disparate pentru a detecta amenințări pe sisteme care, deși complexe, se comportă în mare măsură în mod previzibil. Inteligența artificială agentică nu reinventează niciuna dintre aceste probleme; le face să explodeze simultan.

Agenții lansează decizii, invocă unelte externe și generează sub-agenți dinamic în moduri care nu sunt preeterminate la momentul scrierii. Graficul de execuție nu este doar complex, ci poate fi extrem de diferit de fiecare dată, iar volumul de telemetrie necesar pentru a reconstrui ceea ce s-a întâmplat în realitate crește exponențial cu fiecare salt. Colectarea tuturor datelor de telemetrie necesare pentru a face sistemele agenților observabile trebuie să fie atât ușor de instrumentat, cât și eficient din punct de vedere al costurilor pentru a opera la scară. Altfel, întreprinderile vor face același compromis pe care l-au făcut întotdeauna și vor reduce vizibilitatea pentru a controla costurile — exact în momentul în care nu ar trebui să devină orbi.

Pe măsură ce întreprinderile încorporează agenți autonomi în fluxurile de lucru, unde sunt cele mai mari lacune de vizibilitate între ceea ce i se cere unui agent să facă și ceea ce se întâmplă în realitate în sistemele subiacente?

Agenții finalizează fluxuri de lucru care par a fi de succes la suprafață, dar în mod liniștit fac apeluri la unelte proaste, halucinează parametri sau se abat de la obiectivul original. Consecințele apar adesea la ore după aceea într-un alt sistem.

Decuplarea începe de obicei la interpretare: o ușoară ambiguitate în instrucțiunea originală este rezolvată diferit în funcție de ceea ce agentul extrage din memorie, de uneltele disponibile în acel moment sau de modul în care o etapă anterioară din lanț a modelat contextul său. Trebuie, de asemenea, să instrumentați sistemele subiacente de care agentul depinde, deoarece un agent poate face o apelare perfect valabilă la o bază de date și totuși poate returna un răspuns greșit dacă tabela subiacentă nu a fost niciodată reîmprospătată din cauza unei sarcini ETL care a eșuat în mod silențios în amonte.

Agentul a făcut exact ceea ce i s-a spus; datele în care a avut încredere erau pur și simplu învechite.

De ce sunt adesea uneltele tradiționale de observabilitate insuficiente pentru monitorizarea sistemelor de inteligență artificială agențială?

Mai întâi, au fost construite în jurul unor scheme rigide și proprietare și forme de date previzibile. Urmele agenților nu se conformează acestor așteptări — sunt voluminoase, extrem de variabile în structură și includ tipuri de date precum textul complet al promptului, lanțurile de raționament ale modelului și încărcăturile apelurilor de unelte, pe care uneltele legacy nu au fost proiectate să le ingereze fără o transformare semnificativă. Standarde deschise precum convențiile semantice GenAI ale OpenTelemetry apar pentru a aborda acest lucru, dar multe platforme legacy nu au fost construite pentru a profita de ele.

Al doilea, ecuația de scară și cost se prăbușește rapid. Un singur agent care gestionează sarcini de producție poate genera mai multă telemetrie într-o oră decât a produs un întreg stivuit de aplicații într-o zi, iar majoritatea platformelor tradiționale taxează pe volumul inghest și stocat. Acest lucru creează un compromis imposibil — fie instrumentați totul și faceți față costurilor care au fugit de sub control, fie reduceți vizibilitatea în sistemele în care aveți nevoie de ea cel mai mult.

Când un agent de inteligență artificială eșuează, cum pot determina organizațiile dacă cauza rădăcină a fost modelul, stratul de extragere, o dependență de API, o problemă de permisiuni sau o problemă de infrastructură în aval?

Isolarea cauzei rădăcină a unei eșuări agențiale este un proces de eliminare pe straturi. Funcționează doar dacă telemetria dvs. acoperă toate straturile în mod consecvent. Semnalele de latență și erori pe spațiile modelului indică spre însuși modelul LLM. Spațiile de extragere vă spun dacă contextul returnat a fost relevant sau învechit. Spațiile apelurilor de unelte expun dependențele de API eșuate sau erorile de permisiune.

După cum am menționat, aveți nevoie, de asemenea, de telemetrie din sistemele subiacente de care agentul depinde, deoarece un agent poate face o apelare perfect valabilă și totuși poate produce un răspuns greșit dacă datele în care a avut încredere nu au fost niciodată reîmprospătate. Niciun singur semnal nu spune întreaga poveste, ceea ce explică de ce corelarea tuturor acestor straturi într-un singur loc este ceea ce separă echipele care pot depista rapid eșuări agențiale de cele care încă ghicesc.

Ce tipuri de date de telemetrie devin cele mai importante atunci când întreprinderile încearcă să înțeleagă comportamentul agenților la scară?

Fundamentul este încă MELT — metrice, evenimente, jurnale și urme — dar greutatea se schimbă considerabil atunci când vă deplasați către sisteme agențiale. Metricele vă spun că ceva este în neregulă și jurnalele vă oferă registrul brut al ceea ce s-a întâmplat, dar niciuna dintre ele nu poate reconstrui lanțul de raționament pe care un agent l-a urmat pentru a ajunge la un răspuns greșit. Acesta este punctul în care urmele devin cel mai critic semnal.

Într-un sistem distribuit tradițional, o urmă vă arată cum a trecut o solicitare prin servicii. Într-un sistem agențial, vă arată cum un model a raționat o problemă, care unelte a chemat, ce context a extras, unde s-a ramificat și ce a decis la fiecare pas. Fără această urmă, sunteți în fața unui output fără nicio modalitate de a explica cum ați ajuns acolo.

Alte semnale MELT nu dispar; metricele privind utilizarea tokenilor și latența contează pentru cost și performanță, iar jurnalele de la sistemele subiacente rămân esențiale. Dar urmele sunt ceea ce fac comportamentul agenților lizibil la scară.

Majoritatea discuțiilor despre inteligența artificială se concentrează încă puternic pe halucinații. Întreprinderile subestimează eșuări operaționale, cum ar fi extrageri proaste, integrări defecte, vârfuri de latență sau lipsă de context?

Majoritatea halucinațiilor în producție nu sunt eșuări ale modelului; sunt eșuări operaționale deghizate. Extrageri proaste returnează context învechit sau incomplet, iar modelul umple golul cu ceva care sună plauzibil. O integrare defectă înseamnă că agentul nu a primit niciodată datele de care avea nevoie pentru a raționa corect din start. Lipsa contextului dintr-un job ETL eșuat pare a fi o halucinație, dar este de fapt o problemă de infrastructură.

Când echipele nu pot vedea diferența, se îndreaptă spre ceea ce pot controla, care este de obicei modelul însuși. Iterează pe prompturi de sistem, adaugă garduri de protecție și rafinează cadre de evaluare, și deși aceste tehnici au o valoare reală, ele tratează un simptom și nu cauza. În experiența mea, investiția cu cel mai mare randament este aproape întotdeauna calitatea și prospețimea datelor în stratul de extragere. Un agent bine fundamentat cu date curate și actuale va performa mai bine decât unul puternic inginerit care lucrează dintr-un context învechit sau incomplet.

Pe măsură ce agenții devin mai autonomi, ce ar trebui să înregistreze, să urmărească sau să monitorizeze echipele de întreprinderi pentru a menține responsabilitatea fără a se cufunda în zgomot?

Fundamentul este încă MELT, dar responsabilitatea pentru sistemele agențiale necesită stratificarea unui cadru de evaluare peste telemetria tradițională. Metricele, evenimentele și jurnalele aduc la suprafață eșuări de infrastructură și integrări defecte care pot corupe comportamentul agentului înainte ca modelul să răspundă; urmele vă oferă lanțul de raționament pentru a înțelege de ce a ajuns la un anumit răspuns. Dar niciuna dintre ele nu vă spune dacă răspunsul a fost într-adevăr corect, și aici evaluarea LLM-as-judge umple golul. Capabilitățile de inteligență artificială care alimentează agenții pot fi utilizate pentru a-i evalua, notând ieșirile pentru acuratețe, fundamentare și finalizarea sarcinii la o scară pe care niciun proces de revizuire umană nu o poate egala.

În pre-producție, acționează ca o poartă de calitate, capturând regresii înainte ca acestea să ajungă la utilizatori. În producție, devine un monitor continuu, eșantionând traficul live și semnalizând răspunsuri care se situează în afara pragurilor acceptabile. Cheia pentru evitarea zgomotului este recunoașterea faptului că nu fiecare flux de lucru al agentului prezintă același risc, ceea ce înseamnă trecerea de la monitorizarea uniformă la ceea ce industria începe să numească guvernare cu buclă umană. Definiți linii de bază comportamentale și praguri de încredere din start, lăsați agenții să opereze și rezervați intervenția umană pentru excepții.

Ce rol pot juca conductele de telemetrie în ajutarea echipelor de securitate, SRE, date și inteligență artificială să lucreze dintr-o perspectivă comună asupra comportamentului agenților?

Echipele de securitate, SRE, inginerii de date și echipele de inteligență artificială privesc diferite felii ale aceleiași probleme prin diferite unelte, și niciuna dintre ele nu are imaginea de ansamblu pe cont propriu. Motivul pentru care conductele de telemetrie au devenit o parte standard a arhitecturii de date enterprise moderne este că rezolvă exact această problemă: o singură conductă de telemetrie bine guvernată în amonte de toate uneltele dvs. asigură faptul că fiecare echipă lucrează din aceleași date normalizate și îmbogățite fără agenți și colectori specializați pentru fiecare echipă.

Flexibilitatea contează la două niveluri. Primul este tierul de date. O conductă de telemetrie bine proiectată vă permite să asociați datele cu strategia de stocare și analiză potrivită, astfel încât să nu plătiți prețuri de analiză pentru date de care aveți nevoie doar pentru retenția pe termen lung a conformității. Al doilea este opțiunea pe măsură ce peisajul uneltelor de inteligență artificială continuă să evolueze rapid. Întreprinderile care își construiesc strategia de observabilitate în jurul ecosistemului unui singur furnizor vor face față unor proiecte de migrare scumpe de fiecare dată când apare o unealtă mai bună.

Ce greșeli observați întreprinderile să facă atunci când încearcă să adapteze practicile de monitorizare existente la implementări de inteligență artificială agențială?

Cea mai frecventă greșeală pe care o văd este atingerea platformelor de observabilitate premium existente pentru a colecta urme de agenți fără a reflecta mai întâi asupra implicațiilor de cost. Urmele agenților sunt mari, variabile și voluminoase în moduri în care telemetria aplicațiilor tradiționale nu este. Majoritatea platformelor premium taxează pe ingestiune și stocare. Factura poate deveni o problemă serioasă înainte ca echipele să-și dea seama ce se întâmplă, iar răspunsul tipic este să reducă ceea ce colectează. Rezultatul este cel mai rău din ambele lumi: costuri ridicate și vizibilitate incompletă.

Greșeala a doua este aplicarea mentalității greșite la ceea ce ar trebui să răspundă monitorizarea. Monitorizarea tradițională a infrastructurii întreabă “sistemul este funcțional?” și ridică alerte atunci când nu este. Această întrebare este necesară, dar este departe de a fi suficientă pentru sistemele agențiale, unde infrastructura poate fi perfect sănătoasă, în timp ce agentul face în mod liniștit decizii proaste, extrage date învechite sau se abate de la obiectivul său original. Echipele care adaptează dashboard-urile și pragurile de alertă existente la fluxurile de lucru ale agenților adesea se conving că au acoperire atunci când de fapt sunt doar observând “țevile”.

Greșeala a treia este tratarea instrumentării ca o gândire de după. Întreprinderile care pilotează agenți rapid și trec la producție fără a reflecta asupra observabilității se află în cicluri de remediere scumpe, reconstruind arhitectura colectării de date după primul eșec semnificativ de producție. Echipele care escaladează implementările de agenți cu succes instrumentează devreme, stabilesc linii de bază în timp ce traficul este scăzut și comportamentul este previzibil, și construiesc cadrul lor de evaluare înainte de a avea nevoie, și nu după ce ceva merge prost.

Privind înainte, va deveni vizibilitatea infrastructurii o condiție prealabilă pentru adoptarea inteligenței artificiale de către întreprinderi, în același mod în care observabilitatea cloud-ului a devenit esențială pentru migrarea la scară largă a cloud-ului?

Paralela cu cloud-ul este extrem de similară. Cea mai importantă chestiune pe care o spun clienților atunci când mută infrastructura în cloud este că nu sunt doar ridicând și mutând. Ei implementează o arhitectură complet nouă, cu capacități noi. Toate acestea trebuie instrumentate și monitorizate în moduri în care uneltele anterioare nu erau pregătite. Întreprinderile care au sărit această etapă s-au confruntat cu eșuări în cascadă pe care nu le-au putut diagnostica, costuri care au crescut în spirală și care nu le-au putut explica, și întreruperi pe care nu le-au putut preveni. Observabilitatea a devenit fundația de încredere care a făcut posibilă scalarea cloud-ului, și același model se desfășoară acum cu inteligența artificială agențială, mișcându-se mai repede și cu mize mai mari.

Principalul motiv pentru care agenții vor necesita această supraveghere pe termen nelimitat este că sunt ne-determiniști prin design, comportamentul lor apare la runtime, iar capacitatea lor efectivă crește de fiecare dată când conectați o unealtă nouă. Certificarea statică pre-depunere nu poate acoperi un sistem a cărui suprafață de acțiune se schimbă odată cu fiecare integrare. Agenții vor opera în interiorul unor limite de încredere definite, iar aceste limite se vor extinde pe măsură ce observabilitatea, politica și infrastructura de evaluare se maturizează. Limitele însele nu vor dispărea niciodată, și acest lucru nu este o stare de eșec. Acesta este modul în care funcționează deja fiecare sistem autonom cu consecințe în lume.

Mulțumim pentru acest interviu minunat; cititorii care doresc să afle mai multe despre Cribl pot vizita Cribl.