Jeff Champagne, Field CTO at Cribl – Haastattelusarja

Jeff Champagne, Criblin Field CTO, tuo laaja kokemus observoitavuuden, yritysdatan, tuotestrategian ja teknisen arkkitehtuurin alueilta. Ennen Cribliin liittymistään hän toimi tuotejohtajana Databricksissä ja työskenteli yli seitsemän vuotta Splunkissa seniorifield-tuote-, arkkitehtuuri- ja globaali systeemien insinöörirooleissa. Taustansa sisältää myös järjestelmäarkkitehtuuri johtajuutta BNY ConvergExissä, seniori-insinööritöitä Premier Technology Solutionsissa ja varhaisia insinöörijohtamisrooleja Assist-2-Sellissä, mikä antaa hänelle laajan näkemyksen siitä, miten yritykset keräävät, hallinnoivat, analysoivat ja toimivat operatiivisilla tiedoilla laajassa mittakaavassa.

Cribl on yritysten tietovirta-alan yritys, joka on keskittynyt auttamaan IT-, turvallisuus-, SRE- ja DevOps-tiimejä keräämään, prosessoimaan, reitittämään, tallentamaan ja analysoimaan observoitavuus- ja turvallisuustietoja ilman, että he joutuvat lukittumaan yhden toimittajan kanssa. Yritys määrittelee itsensä “Telemetrian AI-alustaksi”, jolla on tuotteita kuten Cribl Stream reaaliaikaisen telemetrian keräämiseen, vähentämiseen, rikastamiseen ja reitittämiseen; Cribl Edge-vendorin riippumattomaan päätepisteen telemetrian keräämiseen; Cribl Search tiedon hakemiseen paikallisesti; ja Cribl Lake tallentamiseen. Sen laajempi tehtävä on antaa yrityksille enemmän valtaa, joustavuutta ja tehokkuutta, kun telemetrian määrä kasvaa ja AI-vetoinen toiminta vaatii puhtaampaa, helpommin saatavilla olevaa tietoa.

Olet työskennellyt Splunkissa, Databricksissä ja nyt Criblissä, mikä antaa sinulle harvinaisen näkymän yritysdatan, observoitavuuden ja infrastruktuurin kehitykseen useiden teknologioiden aikana. Mikä tuntuu aidosti erilaiselta observoitavuuden haasteessa, jonka agenteille tekoäly luo?

Sovellusobservoitavuudessa olemme aina käsitelleet monimutkaisia, haarautuvia suorituspolut, jäljittäen pyynnöt mikropalvelujen ja korreloimalla lokit jakeluun. Turvallisuustoiminnassa olemme ratkaisseet suurivolyymisen, erilaiset tietolähteet havaitsemaan uhkia järjestelmissä, jotka ovat kompleksisia, mutta käyttäytyvät suurelta osin ennustettavasti. Agenteille tekoäly ei keksimässä uudelleen kumpaakaan ongelmaa; se räjäyttää ne samanaikaisesti.

Agentit ketjuvat päätöksiä, kutsuvat ulkoisia työkaluja ja synnyttävät aliprosesseja dynaamisesti tapoja, jotka eivät ole ennalta määrättyjä kirjoitusaikana. Suorituskuvio ei ole vain monimutkainen, se voi olla villin erilainen joka kerta, ja telemetrian määrä, joka tarvitaan observoitavuuden rakentamiseen, kasvaa eksponentiaalisesti jokaisen hyppäyksen kanssa. Kaiken tarvittavan telemetrian kerääminen agenteille on oltava sekä helppoa instrumentoida että kustannustehokasta toimia laajassa mittakaavassa. Muuten yritykset tekevät saman kompromissin kuin aina ennen ja rajoittavat näkyvyyttä kustannusten hallitsemiseksi — juuri silloin, kun on väärä aika mennä sokeaksi.

Kun yritykset upottavat autonomiset agentit työnkulkuun, missä ovat suurimmat näkyvyyden aukot siitä, mitä tekoälyagentti pyydetään tekemään ja mitä todella tapahtuu perustuvissa järjestelmissä?

Agentit suorittavat työnkulkuja, jotka näyttävät onnistuneilta pinnan alla, mutta hiljaisesti tekevät huonoja työkalukutsuja, kuvittelevat parametreja tai poikkeavat alkuperäisestä tavoitteesta. Seuraukset usein tulevat esiin myöhemmin toisessa järjestelmässä.

Erilleenajo yleensä alkaa tulkinnasta: pieni epäselvyys alkuperäisessä ohjeessa ratkaistaan eri tavoin riippuen siitä, mitä agentti hakee muistista, mitkä työkalut ovat käytettävissä kyseisellä hetkellä tai miten edellinen vaihe ketjussa muovasi sen kontekstia. Sinun on myös instrumentoitava alijärjestelmiä, joista agentti riippuu, koska agentti voi tehdä täysin muodollisen tietokantakutsun ja silti palauttaa väärän vastauksen, jos perustuvan taulun tietoja ei koskaan päivitetty, koska ETL-työ epäonnistui hiljaisesti ylävirtaan.

Agentti teki juuri sen, mitä sille sanottiin; tiedot, joissa se luotti, olivat vain vanhentuneita.

Miksi perinteiset observoitavuustyökalut ovat usein riittämättömiä agenteille tekoälyjärjestelmien seuraamiseen?

Ensinnäkin, ne on rakennettu joustamattomien, omistajiin perustuvien skeemojen ja ennustettavien tietorakenteiden ympärille. Agenteille tekoälyjäljet eivät noudata näitä odotuksia — ne ovat tilavuutta, hyvin muuttuvia rakenteessa ja sisältävät tietotyyppejä kuten täydellisen ohjekyselyn tekstin, mallin päättelyketjujen ja työkalukutsujen kuormia, joita perinteiset työkalut eivät ole suunniteltu ottamaan ilman merkittävää muodonmuutos työtä. Avoin standardi kuten OpenTelemetrian GenAI- semanttiset konventiot kehittyy osoittamaan tämän, mutta monet perinteiset alustat eivät ole rakennettu hyödyntämään niitä.

Toiseksi, mittakaava ja kustannusyhtälö menevät nopeasti rikki. Yksittäinen agentti, joka käsittelee tuotantotyönkulkuja, voi tuottaa enemmän telemetriaa tunnissa kuin koko sovelluspinorakenne tuotti päivässä, ja useimmat perinteiset alustat laskuttavat tilavuuden mukaan ja tallennetaan. Se luo mahdottoman kompromissin — joko instrumentoi kaikki ja kohtaa pakoilevat kustannukset, tai rajoita näkyvyys järjestelmissä, joissa tarvitset sitä eniten.

Kun tekoälyagentti epäonnistuu, miten organisaatiot voivat määrittää, oliko juurisyy malli, hakukerros, API-riippuvuus, käyttöoikeusongelma vai alijärjestelmän infrastruktuuriongelma?

Juurisyyntä agenteille tekoälyepäonnistumisessa on prosessi poissulkevaa useiden kerrosten yli. Se toimii vain, jos telemetria kattaa kaikki nämä kerrokset johdonmukaisesti. Latenssi- ja virhesignaalit mallin osalla osoittavat LLM:ään itseensä. Hakukerroksen jäljet kertovat, oliko palautettu konteksti relevantti vai vanhentunut. Työkalukutsujen jäljet paljastavat epäonnistuneet API-riippuvuudet tai käyttöoikeusvirheet.

Kuten mainittiin, tarvitset myös telemetriaa alijärjestelmistä, joista agentti riippuu, koska agentti voi tehdä täysin muodollisen kutsun ja silti tuottaa väärän vastauksen, jos tieto, johon se luotti, ei koskaan päivitetty. Yksikään signaali ei kerro koko tarinaa, joten korreloiminen kaikkien näiden kerrosten yli on se, mikä erottaa tiimit, jotka voivat vikadiagnostiikkaa nopeasti, niistä, jotka arvaavat yhä.

Mitkä telemetrian tiedot tulevat tärkeimmiksi, kun yritykset yrittävät ymmärtää agentin käyttäytymistä laajassa mittakaavassa?

Pohja on edelleen MELT — mittarit, tapahtumat, lokit ja jäljet — mutta painopiste siirtyy merkittävästi, kun siirrytään agenteille tekoälyjärjestelmiin. Mittarit kertovat, onko jotain vikaa, ja lokit antavat sinulle raakarekisterin siitä, mitä tapahtui, mutta kumpikaan ei voi rekonstruoida ketjun päättelyä, jonka agentti seurasi väärään vastaukseen. Siinä jäljet ovat kriittisin signaali.

Perinteisessä jakeluun järjestelmässä jälki näyttää, miten pyyntö liikkui palvelujen läpi. Agenteille tekoälyjärjestelmässä se näyttää, miten malli päätteli ongelman, mitkä työkalut se kutsui, mitä kontekstia se haki, missä se haarautui ja mitä se päätti jokaisessa vaiheessa. Ilman tätä jälkeä olet katsomassa tulostetta ilman tapaa selittää, miten sinne päädyttiin.

Muut MELT-signaalit eivät katoa; mittarit tokenin käytöstä ja latenssista ovat tärkeitä kustannuksille ja suorituskyvylle, ja alijärjestelmien lokit ovat edelleen olennaisia. Mutta jäljet ovat se, mikä tekee agentin käyttäytymisen lukukelpoiseksi laajassa mittakaavassa.

Monet tekoälykeskustelut keskittyvät edelleen voimakkaasti harhaluuloihin. Alitetaanko yrityksissä operatiivisia epäonnistumisia, kuten huonoja hakukutsuja, rikkoontuneita integraatioita, latenssispiikkejä tai puuttuvaa kontekstia?

Useimmat harhaluulot tuotannossa eivät ole mallin virheitä; ne ovat operatiivisia epäonnistumisia naamioituneina. Huono hakukutsu palauttaa vanhentunutta tai epätäydellistä kontekstia, ja malli täyttää aukon jonkinlaisella uskottavalla äänellä. Rikkoontunut integraatio tarkoittaa, että agentti ei koskaan saanut tietoa, jota tarvittiin päättelyyn oikein alusta alkaen. Puuttuva konteksti epäonnistuneesta ETL-työstä näyttää harhaluulolta, mutta se on todella infrastruktuuriongelma.

Kun tiimit eivät voi nähdä eroa, he olettaa, mitä he voivat hallita, mikä on yleensä itse malli. He iteroida järjestelmäohjeita, lisäävät varotoimia ja jalostavat arviointikehyksiä, ja vaikka nämä tekniikat ovat arvokkaita, ne ovat hoitamassa oireita eivätkä aiheuttaa syytä. Omassa kokemuksessani korkean prioriteetin investointi on melkein aina datakvaliteetti ja tuoreus hakukerroksessa. Hyvin perusteltu agentti, jolla on puhdas ja ajantasainen tieto, suoriutuu paremmin kuin raskasti ohjelmoidun mallin, joka toimii vanhentuneesta tai epätäydellisestä kontekstista.

Kun agentit tulevat autonomisimmiksi, mitä yritysten on seurattava, jäljitettävä tai valvottava, jotta voidaan ylläpitää vastuuta ilman, että hämmästytäisiin melun määrästä?

Pohja on edelleen MELT, mutta agenteille tekoälyjärjestelmissä vastuu vaatii arviointikehyksen perinteisen telemetrian päälle. Mittarit, tapahtumat ja lokit paljastavat infrastruktuurin epäonnistumiset ja rikkoontuneet integraatiot, jotka voivat turmella agentin käyttäytymisen ennen kuin malli reagoi; jäljet antavat sinulle päättelyketjun ymmärtääksesi, miksi se saavutti tietyn vastauksen. Mutta kumpikaan ei kerro, oliko vastaus itse asiassa oikein, ja siinä LLM-arvioinnin tuomioistuin täyttää aukon. Samat tekoälyominaisuudet, jotka voimauttavat agenteja, voidaan käyttää niiden arviointiin, pisteyttämällä tulosteen tarkkuudesta, perustaan ja tehtävän suorittamisesta mittakaavassa, jota mikään ihmisten tarkastusprosessi ei voi vastata.

Ennen tuotantoa se toimii laadun porttina, joka havaitsee takaiskuja ennen kuin ne pääsevät käyttäjien luokse. Tuotannossa se muuttuu jatkuva seurantaksi, joka ottaa näytteitä suorasta liikenteestä ja liputtaa vastauksia, jotka poikkeavat hyväksyttävistä kynnysarvoista. Avain välttämiseen melusta on tunnistaa, ettei jokainen agentin työnkulku kanna samaa riskiä, mikä tarkoittaa siirtymistä yhdenmukaisesta seuraamisesta kohti jotain, mitä teollisuus on aloittamassa kutsumaan ihmisten silmien ylläpidolla. Määrittele käyttäytymisen perusviivat ja luottamusrajat etukäteen, anna agenteille toimia ja varaa ihmisen väliintulo poikkeuksille.

Mikä rooli telemetriaputkistolla on auttamassa turvallisuus-, SRE-, data- ja tekoälytiimejä työskentelemään jaettuna näkemyksenä agentin käyttäytymisestä?

Turvallisuustiimit, SRE:t, data-insinöörit ja tekoälytiimit katsovat eri osia samaa ongelmaa eri työkalujen kautta, eikä kukaan heistä ole kokonaiskuvaa. Syy, miksi telemetriaputkistot ovat tulleet vakiinnutetuksi osaksi modernin yritysdatan arkkitehtuuria, on, että ne ratkaisevat täsmälleen tämän ongelman: yksi hyvin hallittu putki kaikkien työkalujen yläpuolella takaa, että jokainen tiimi työskentelee samasta normalisoidusta, rikkaammasta tiedosta ilman mukautettuja agenteja ja kerääjiä, jotka on käyttöönotettu kullekin tiimille.

Tämä joustavuus on tärkeää kahdella tasolla. Ensimmäinen on tietojen kerroksellisuus. Hyvin suunniteltu telemetriaputki antaa sinun kohdistaa tiedon oikeaan tallennus- ja analyysistrategiaan, jotta et maksa analytiikkaa tasolla, jota tarvitset vain pitkäaikaisen noudattamisen tallentamiseen. Toinen on valinnanvapaus, kun tekoälytyökalujen maisema jatkuu nopeasti kehittyvänä. Yritykset, jotka rakentavat observoitavuusstrategiansa yhden toimittajan ekosysteemin ympärille, kohtaavat kalliit siirtoprosessit joka kerta, kun parempi työkalu nousee esiin.

Mitkä virheet olet nähnyt yritysten tekemissä, kun he yrittävät sovittaa olemassa olevia seurantatapoja agenteille tekoälykäyttöön?

Yleisin virhe, jonka näen, on tarttuminen olemassa oleviin premium-observoitavuusalustoihin keräämään agenttijälkiä ilman, että ajattelevat kustannusvaikutuksia ensin. Agenteille tekoälyjäljet ovat suuria, muuttuvia ja tilavuutta, mitä perinteinen sovellustelemetria ei ole, ja useimmat premium-alustat hinnoittelevat niiden mukaan, mitä ne ottavat ja tallentavat. Lasku voi muuttua vakavaksi ongelmaksi ennen kuin tiimit edes toteavat, mitä tapahtuu, ja tyypillinen reaktio on rajoittaa sitä, mitä he keräävät. Tuloksena on pahin molemmista maailmoista: korkeat kustannukset ja epätäydellinen näkyvyys.

Toinen virhe on soveltaminen väärää mielialaa siihen, mitä seurantaa on tarkoitus vastata. Perinteinen infrastruktuurin seuranta kysyy “onko järjestelmä käynnissä?” ja antaa hälytyksiä, kun se ei ole. Tämä kysymys on välttämätön, mutta se ei ole riittävä agenteille tekoälyjärjestelmissä, joissa infrastruktuuri voi olla täysin terve, kun taas agentti tekee hiljaisesti huonoja päätöksiä, hakee vanhentunutta tietoa tai poikkeaa alkuperäisestä tavoitteesta. Tiimit, jotka sovittavat olemassa olevat kojut ja hälytysrajat agenttityönkulkuun, usein vakuuttavat itsensä siitä, että heillä on kattavuus, kun he vain katsovat putkea.

Kolmas virhe on käsittely instrumentointia jälkijättönä. Yritykset, jotka nopeasti käyttöönottoivat agenteja ja siirtyvät tuotantoon ilman, että ajattelevat observoitavuutta, joutuvat kalliisiin korjauskiertoihin, jälleenrakentamaan datakeräysarkkitehtuuria ensimmäisen merkittävän tuotantovirheen jälkeen. Tiimit, jotka laajentavat agenteille tekoälykäyttöä menestyksekkäästi, instrumentoivat aikaisin, määrittävät perusviivat, kun liikenne on alhainen ja käyttäytyminen on ennustettavissa, ja rakentavat arviointikehyksensä ennen kuin he tarvitsevat sitä, eivätkä sen jälkeen, kun jotain menee pieleen.

Katsoen eteenpäin, tuleeko infrastruktuurin näkyvyys olemaan edellytys yritysten tekoälyadopiotolle samalla tavalla, kuin pilvi-observoitavuus tuli välttämättömäksi suurmittakaavan pilvisiirtoon?

Vertaus pilveen on erittäin samankaltainen. Tärkein asia, jonka kerrotan asiakkaille, kun he siirtävät infrastruktuurin pilveen, on, että he eivät ole siirtämässä ja siirtämässä. He ovat käyttöönotossa uutta arkkitehtuuria uusilla kyvyillä. Kaikki tämä on instrumentoitava ja seurattava tapoja, joita aiemmat työkalut eivät välttämättä olleet asetettu. Yritykset, jotka ohittivat tämän vaiheen, kohtasivat ketjuvia epäonnistumisia, joita he eivät voineet diagnosoida, kustannuksia, joita he eivät voineet selittää, ja katkoksiin, joita he eivät voineet estää. Observoitavuus tuli perustaksi, joka teki pilven mittakaavan mahdolliseksi, ja sama malli toistuu nyt agenteille tekoälyssä, nopeammin ja korkeammilla panoksilla.

Ensisijainen syy, miksi agenteille tekoäly vaatii tällaista valvontaa loputtomiin, on, että ne on suunniteltu epädeterministisiksi, niiden käyttäytyminen syntyy suoritusaikana, ja niiden tehokas kyky kasvaa jokaisen uuden integraation myötä. Statiset ennen käyttöönottoa sertifioinnit eivät voi kattaa järjestelmää, jonka toimintapinta muuttuu jokaisen integraation myötä. Agentit toimivat määritettyjen luottamuksen rajojen sisällä, ja nämä rajat laajenevat ajan myötä, kun observoitavuus, politiikka ja arviointi-infrastruktuuri kypsyvät. Rajat itse eivät koskaan katoa, ja se ei ole epäonnistumistila. Se on, miten jokainen merkittävä autonominen järjestelmä maailmassa toimii jo.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa vierailla Cribl-sivustolla.