Shahar Azulay, groundcovern toimitusjohtaja ja perustaja

Shahar Azulay, groundcoverin toimitusjohtaja ja perustaja on sarja R&D-johtaja. Shahar tuo kokemusta kyberTurvallisuuden ja koneoppimisen maailmasta, työskenneltyään johtajana yrityksissä kuten Apple, DayTwo ja Cymotive Technologies. Shahar vietti monia vuosia Israelin pääministerin toimistossa kyberturvallisuusosastolla ja hänellä on kolme tutkintoa fysiikasta, sähkötekniikasta ja tietojenkäsittelytieteestä Technion Israel Institute of Technologysta sekä Tel Avivin yliopistosta. Shahar pyrkii käyttämään teknologisia tietoja tästä rikkaasta taustasta ja tuomaan ne tänään pilvi-alkuperäiseen taistelukenttään terävimmässä ja innovatiivisimmassa muodossa, jotta kehittäjien maailma olisi parempi.

groundcover on pilvi-alkuperäinen havainnollistamisalusta, joka on suunniteltu antamaan insinööritiimille täysi, reaaliaikainen näkyvyys järjestelmiinsä ilman perinteisten valvontatyökalujen monimutkaisuutta tai kustannuksia. Rakennettu eBPF-tekniikalle, se kerää ja yhdistää lokit, mittaukset, jäljitykset ja tapahtumat pilvi-alkuperäisissä ja Kubernetes-ympäristöissä ilman koodin muutoksia, mahdollistaen nopeamman juurisyyanalyysin ja selkeämmän järjestelmänäkyvyyden. Alusta korostaa ennustettavaa hinnoittelua, joustavaa käyttöönottoa, joka pitää tiedot asiakkaan pilvessä, ja päästä päähän havainnollistamista, joka kattaa infrastruktuurin, sovellukset ja modernit AI-vetovoimaiset työkuormat.

Miten sinä näet matkasi johtavana kyberturvallisuuden ja koneoppimisen R&D-tiimien johtajana Israelin pääministerin toimistossa ja miten sinä lopulta päädyit perustamaan groundcoverin, ja milloin sinä tunnistit aukon havainnollistamisessa modernissa AI-järjestelmissä?

Ajatus perustaa groundcover syntyi ajastaani Applella ja DayTwossa. Vaikka meillä oli valtavat budjetit, meidän oli valittava maksamisesta jokaisen lokin kirjaamisesta tai näytteen otosta ja sokeudesta. Silloin etsimme teknologiaa, joka ratkaisisi ongelman. Kun me törmäsimme laajennettuun Berkeley-pakettisuodattimeen (eBPF), oli selvää, että se muuttaisi kaiken. eBPF antaa meille mahdollisuuden nähdä kaikki, mitä tapahtuu ytimessä, ilman sovelluksen muutoksia. En voi ymmärtää, miksi havainnollistamistyökalut eivät hyödyntäneet sitä. AI-aukko tuli selväksi myöhemmin. Kun Kubernetes-alustamme kypsyi, näimme asiakkaiden ryntäävän GenAI-käyttöönottoihin ja kohtelevan LLM:itä kuin mustia laatikoita. He tunsivat, että malli vastasi, mutta eivät tienneet, miksi se käyttäytyi epävakaiden tai miksi kustannukset kasvoivat. Totesimme, että agenteille tyypilliset työvirrat ovat yksinkertaisesti monimutkaisia, epädeterministisiä mikropalveluita, jotka tarvitsevat saman nollakosketuksen näkyvyyden, jonka olemme jo rakentaneet.

Miten sinun taustasi kyberturvallisuuden, upotettujen järjestelmien ja koneoppimisen tutkimus- ja kehitystyössä vaikuttivat groundcoverin visioon, ja mitkä olivat varhaiset haasteet, joita sinä kohtasit rakennettaessa yhtiötä, joka keskittyy havainnollistamiseen LLM- ja agenteille sovelluksille?

Kyberturvallisuuden taustani muovasi yhtiön DNA:ta. Viisaassa maailmassa oletetaan, että sovellusta ei voida hallita. Tästä syystä groundcover ei vaadi instrumentointia. Tiedän kokemuksesta, että kehittäjien pyytäminen muokkaamaan koodia on nopein tapa estää omaksuminen. Haasteellisin varhainen haaste LLM:n valvonnassa oli yksityisyys. AI-havainnollistaminen kaappaa kehotuksia, jotka saattavat sisältää herkkää PII- tai IP-tietoa. Taustani teki selväksi, että yritykset eivät halua, että tieto jätetään heidän ympäristönsä ulkopuolelle. Tämän vuoksi rakensimme pilviarkkitehtuurimme, joka antaa meille mahdollisuuden syvään näkyvyyteen agentin käyttäytymiseen samalla, kun pidämme kaikki tiedot asiakkaan omassa ympäristössä.

Miten sinä määrittelet LLM-havainnollistamisen, ja miten se eroaa perinteisestä valvonnasta tai ML-valvonnasta?

LLM-havainnollistaminen on tuotannon järjestelmien välineistössä ja valvontaa, jotta voidaan kaapata kunkin inferenssin täysi konteksti: kehote, konteksti, täydennys, tokenin käyttö, viive, virheet, mallin metatiedot ja ihanteellisesti alihankkijoiden palaute tai laatusignaalit. Sen sijaan, että kysytään vain “Onko palvelu ylös ja nopea?” tai “Eikö tämä pyyntö epäonnistunut?”, LLM-havainnollistaminen auttaa sinua vastaamaan kysymyksiin “Miksi tämä tietty pyyntö onnistui tai epäonnistui?”, “Mitä todella tapahtui tässä monivaiheisessa työvirrassa?” ja “Miten muutokset kehoituksiin, kontekstiin tai malliversioihin vaikuttavat kustannuksiin, viiveisiin ja tulosteen laatuun?” Tämä on erilainen kuin perinteinen valvonta tai jopa klassinen ML-valvonta. Perinteiset lähestymistavat on säädetty deterministisiin järjestelmiin, infrastruktuurin metriikkaan ja staattisiin kynnyksiin. LLM-sovellukset ovat epädeterministisiä, avoimia ja hyvin kontekstiriippuvaisia. Menestyksen on usein semanttinen ja subjektiivinen, ei pelkästään 200 vs 500 tilakoodi. Tämä tarkoittaa, että sinun on jäljitetty syötteitä ja tulosteita, ymmärrettävä työkalukutsuja ja hakuvaiheita, arvioitu vastauksia asioiden kaltaisia kuin hallucinaatiot tai politiikkavirheet ja yhdistetty tokenin kustannukset ja viiveet ympäröivään sovellukseen ja infrastruktuuriin.

Mitä haasteita LLM-pohjaiset sovellukset tuovat, jotka tekevät perinteiset valvontatyökalut riittämättömiksi?

LLM-järjestelmät tuovat useita haasteita, jotka paljastavat perinteisten työkalujen rajat:

• Monimutkaiset, monivaiheiset työvirrat – Siirryimme yksinkertaisista “kutsu malli, hae vastaus” -virroista monivaiheisiin agenteihin, monivaiheisiin putkiin, hakuvahvistettuun generointiin ja työkalujen käyttöön. Hiljainen epäonnistuminen missä tahansa näistä vaiheista, kuten hakuvaiheessa, rikastamisessa, upottamisessa, työkalukutsussa tai mallikutsussa, voi rikkoa koko kokemuksen. Perinteinen valvonta ei yleensä anna sinulle täydellistä, jäljitystasoa näkymää näistä ketjuista kehoitusten ja vastausten kanssa.
• Nopeasti kehittyvät AI-pinot – Tiimit testaavat uusia malleja jatkuvasti. Useissa yrityksissä kukaan ei voi varmasti kertoa, mitkä mallit ovat tuotannossa kulloinkin. Klassinen havainnollistaminen olettaa, että sinulla on aikaa instrumentoida SDK:ita, uudelleen käyttöönottaa ja huolellisesti kuratoida mitä mitataan. Tämä ei vain pysy mukana siitä, kuinka nopeasti AI:ta omaksutaan.
• Token-pohjainen talous ja kiintiöt – Hinnat ja nopeusrajoitukset ovat sidottu tokeniin ja kontekstin pituuteen, jotka usein määrätään kehittäjien, kehoitusten tai käyttäjän käyttäytymisen mukaan, eivät keskusoperaattorin mukaan. Perinteiset työkalut eivät ole suunniteltu näyttämään sinulle “kuka poltti kuinka monta tokenia, mihin malliin, missä viiveessä”.
• Semanttinen oikeellisuus sijaan binäärisen onnistumisen – LLM voi palauttaa 200 ja silti hallucinoida, poiketa kehotuksesta tai rikkoa politiikkaa. Perinteiset työkalut näkevät tämän onnistumisena. Sinun tarvitsee havainnollistamista, joka voi tuoda kehotukset ja vastaukset ja antaa sinulle riittävästi kontekstia tarkastella käyttäytymistä ja yhdistää ajan myötä automaattisia laatusyötteitä.
• Herkillä syötteillä, jotka virtaavat kolmansiin osapuoliin – LLM:t kutsuvat käyttäjiä jakamaan erittäin herkillä tiedoilla chat-tyyppisissä käyttöliittymissä. Nyt sinä olet vastuussa siitä, mihin se data menee, miten se tallennetaan ja mitkä alihankkijat osallistuvat siihen. Perinteinen SaaS-pohjainen havainnollistaminen, joka lähettää kaiken telemetrian kolmannelle osapuolelle, on usein vastaanottamaton näille työkuormille.

Kaikki tämä tarkoittaa, että LLM-järjestelmät vaativat havainnollistamista, joka on AI-tietoinen, kontekstiriikas ja vähemmän riippuvainen manuaalisesta instrumentoinnista kuin työkalut, joita useimmat tiimit käyttävät tänään.

Mitä signaaleja tai mittareita on tärkeää ymmärtää LLM-järjestelmien suorituskyvyn ja laadun, mukaan lukien viive, tokenin käyttö ja kehote/vastauskäyttäytyminen?

On muutamia signaaleja, jotka ovat tärkeitä käytännössä:

Viive ja läpäisy

• Päästä päähän viive kunkin pyynnön mukaan, mukaan lukien mallin aika ja ympäröivän sovelluksen aika.
• Häntäviiveet (P90, P95, P99) kunkin mallin ja työvirran mukaan.
• Läpäisy kunkin mallin, reitin ja palvelun mukaan, jotta tiedät, mihin kuormitus todella menee.

Tokenin käyttö ja kustannusvaikuttimet

• Syöte- ja tulostetokenit kunkin pyynnön mukaan, jaettuna mallikohtaisesti.
• Tokenin käytön yhteenveto ajan myötä kunkin mallin, tiimin, käyttäjän ja työvirran mukaan.
• Kontekstin koot hakuvaiheisille putkille, jotta voit nähdä, milloin kehotukset räjähtävät.
• Tämä on se, joka antaa sinulle vastauksen “Kuka todella kuluttaa AI-budjettiamme ja mihin?”

Kehote- ja vastauskäyttäytyminen

• Todelliset kehote- ja vastauskuormat edustavilla jäljityksillä, mukaan lukien työkalukutsut ja päättelypolut.
• Mitä työkaluja LLM valitsi ja missä järjestyksessä.
• Vaihtelu vastauksissa samankaltaisille kehoituksille, jotta voit nähdä, kuinka vakaata käyttäytyminen on.

Luotettavuus ja virheet

• Mallikohtaiset virheluvut ja tyypit (toimittajan virheet, aikakatkaisut, auth-ongelmat, kiintiövirheet).
• Epäonnistumiset ympäröivässä työvirrassa, kuten työkaluajan katkaisu tai hakuvirheet, yhdistetty LLM-kutsuun.

Perinteinen infrastruktuurin konteksti

• Säiliön CPU, muisti ja verkkomittaukset palveluille, jotka orkesteroivat LLM-kutsuja.
• Yhdistetyt lokit, jotka kuvaavat, mitä sovellus yritti tehdä.

Kun voit nähdä kaiken tämän yhdessä paikassa, LLM-havainnollistaminen siirtyy “tiedän, että jotain on hitaasti tai kalliisti” “tiedän tarkalleen, mikä malli, kehotuskuviot ja palvelu ovat vastuussa siitä ja miksi”.

Miten havainnollistaminen voi auttaa tiimejä havaitsemaan hiljaisia epäonnistumisia, kuten kehotusviive, hallucinaatioita tai vasteiden laadun hitaasti heikkenemistä?

Hiljaiset epäonnistumiset LLM-järjestelmissä tapahtuvat yleensä, kun kaikki näyttää “vihreältä” infrastruktuuritasolla, mutta todellinen käyttäytyminen on poikennut. Havainnollistaminen auttaa useilla tavoilla:

• Jäljittäminen koko työvirran yli, ei vain mallikutsun – Kaappaamalla koko polku pyynnöstä asiakkaasta palveluun, hakemiseen, malliin ja työkaluihin voit nähdä, missä käyttäytyminen muuttui. Esimerkiksi hakeminen alkoi palauttaa vähemmän asiakirjoja tai työkalukutsu epäonnistui satunnaisesti ja malli improvisoi.
• Pito kehoitusten ja vastausten näkyvissä – Kun voit tarkastella kehoituksia ja vastauksia jäljitysten rinnalla, on paljon helpompaa havaita tapauksia, joissa uusi kehotusversio, uusi järjestelmäohje tai uusi kontekstilähde muutti käyttäytymistä, vaikka viive ja virheluvut pysyivät samoina.
• Suodattaminen ja viipaleminen semanttisilla ehdoilla – Kun sinulla on rikas LLM-telemetria, voit suodattaa asioita, kuten “Bedrock-kutsut yli yhden sekunnin”, “pyynnöt, jotka käyttävät tätä malliperhettä” tai “jäljitykset, jotka liittyvät tähän tiettyyn reittiin”, sitten lue kehotukset ja vastaukset, jotta voit nähdä, onko malli poikennut tai hallucinoi tietyssä skenaariossa.
• Hälytykset liiketoimintatason SLO:ille – Voit määritellä SLO:t, kuten “mikä tahansa LLM-kutsu yli yhden sekunnin rikkoaa käyttäjän näköisen SLA:ni” ja laukaista hälytyksiä, kun nämä ehdot täyttyvät. Ajan myötä samanlaiset SLO:t voidaan liittää laatusyötteisiin tai politiikkatarkastuksiin, jotta voit hälyttää, kun laatu heikkenee, ei vain, kun infrastruktuuri epäonnistuu.

Havainnollistamiskerros on luonnollinen paikka, jossa voidaan havaita ongelmat, jotka muuten heikentäisivät käyttäjäkokemusta hiljaisesti.

Miten groundcoverin lähestymistapa tukee diagnosointia epäilyttävää viivettä tai odottamatonta käyttäytymistä monivaiheisissa agenttityövirroissa ja työkalukutsuissa?

groundcover käyttää lähestymistapaa, joka on suunniteltu modernille AI-järjestelmille. Käytämme eBPF-pohjaista anturia ytimen tasolla tarkkailemaan liikennettä mikropalvelujen yli ilman koodin muutoksia tai uudelleenkäyttöönottoa. Kun sinä esittelet LLM-työvirran, voimme autonomeksi löytää ne kutsut. Jos sinä alat käyttää uutta mallia, kuten Anthropic, OpenAI tai Bedrock, huomenna, groundcover kaappaa sen liikenteen automaattisesti. Tämä antaa sinulle:

• Päästä päähän jäljitykset monivaiheisista työvirroista – Näet koko pyynnön polun palvelujen yli, mukaan lukien LLM tai työkalun käyttö.
• Syvä konteksti kunkin LLM-kutsun yli – Kunkin kutsun mukana on malli, jota käytetään, viive, tokenin käyttö, kehotukset, vastaukset ja yhdistetyt lokit ja infra-mittaukset.
• Voimakas suodattaminen viiveen ja ehtojen perusteella – Voit esimerkiksi suodattaa kaikki Claude 3.5 -kutsut yli yhden sekunnin ja välittömästi tarkastella jäljityksiä, jotka rikkoivat SLA:si.
• Hälytykset ja työpöydät, jotka liittyvät LLM-käyttäytymiseen – Kun data on saatavilla, voit luoda hälytyksiä SLA-rikkomuksille tai rakentaa työpöytiä, jotka seuraavat viivettä, läpäisyä, tokenin käyttöä ja virheitä.

Koska kaikki kerätään reunassa eBPF:llä ja tallennetaan omassa pilvessäsi, saat tämän korkean resoluution näkymän ilman instrumentointia jokaisen agentin tai työkalukutsun sisällä.

Mitä tietoturva- ja vaatimushaasteita sinä näet nousevan LLM-käyttöönotoissa, ja miten havainnollistaminen voi auttaa vähentämään näitä riskejä?

LLM-käyttöönotot tuovat joitain ainutlaatuisia tietoturvariskejä:

• Rajoittamaton käyttäjän syöte – Käyttäjät voivat jakaa erittäin herkillä tiedoilla chat-tyyppisissä AI-voimaisissa käyttöliittymissä. Tämä saattaa sisältää henkilökohtaisia tietoja, asiakastietoja tai säädeltyjä tietoja, joita et halunnut kerätä.
• Kolmannen osapuolen mallintarjoajat – Kun lähettät tämän datan ulkoiseen LLM-tarjoajalle, olet vastuussa siitä, mihin se menee, miten se tallennetaan ja mitkä alihankkijat osallistuvat siihen. Tämä on suuria vaikutuksia GDPR:lle, tietoresidensille ja asiakastietoturvalle.
• Telemetria toisena kopiona herkkää dataa – Jos havainnollistamisarkkitehturisi lähettää täydelliset kuormat SaaS-vendorille, sinulla on toinen kappale herkkää tietoa ulkopuolella ympäristöäsi.

groundcoverin arkkitehtuuri on suunniteltu vastaamaan näihin huolenaiheisiin:

• Käytämme “ota omat pilvi” -mallia, jossa koko havainnollistamisbackend toimii asiakkaan pilvessä, alitilissä, täysin hallitussa dataplaneessa. Hallintaplane, joka skaalaa ja hallinnoi sitä, toimii meillä, mutta emme pääse käsiksi, tallenna tai käsittele asiakkaan telemetriatietoja.
• Koska voimme turvallisesti kaapata kuormia asiakkaan omassa ympäristössä, voit havainnollistaa kehotukset, vastaukset ja työvirrat ilman, että data poistuu pilvestäsi. Ei ole kolmannen osapuolen tallennusta LLM-jäljityksistäsi eikä ylimääräistä dataa poistumista, josta huolehtia.
• Näkyvyyden ansiosta voit nähdä, kuka lataa mitä ja mihin se virtaa, havaita odottamattoman herkkien tietojen käytön ja pakottaa käytäntöjä, mitkä mallit ja alueet ovat sallittuja.

Toisin sanoen havainnollistaminen muuttuu ei vain luotettavuuden ja kustannusten työkaluksi, vaan myös tärkeäksi valvontapisteeksi yksityisyyden, tietoresidenssin ja vaatimustenmukaisuuden kannalta.

Kun organisaatiot laajentavat yhdestä LLM-integraatiosta useisiin AI-voimaisiin palveluihin, mitkä operatiiviset haasteet yleensä ilmestyvät näkyvyyden, luotettavuuden ja kustannusten ympärillä?

Ensimmäinen integraatio on yleensä yksittäinen malli yksittäisessä työvirrassa. Tässä vaiheessa asiat tuntuvat hallitettavilta. Kun tiimit näkevät arvon, käyttö räjähtää ja useita haasteita ilmenee:

• Mallin ja toimittajan laajentuminen – Tiimit testaavat uusia malleja jatkuvasti. Monissa yrityksissä kukaan ei voi varmasti kertoa, mitkä mallit ovat tuotannossa kulloinkin. Klassinen havainnollistaminen olettaa, että sinulla on aikaa instrumentoida SDK:ita, uudelleen käyttöönottaa ja huolellisesti kuratoida mitä mitataan. Tämä ei vain pysy mukana siitä, kuinka nopeasti AI:ta omaksutaan.
• Kustannusyllätykset tokenin käytöstä – Tokenin kulutus kasvaa kontekstin pituuden ja työvirran monimutkaisuuden myötä. Ilman näkyvyyttä tokenin käytöstä mallikohtaisesti on vaikea hallita kustannuksia.
• Luotettavuusriippuvuudet ulkoisista toimittajista – Käyttäjän näköiset API:t ovat herkkäsiä mallin viiveelle tai virheille, jotka voivat rikkoa SLA:t, vaikka ydininfrastruktuuri on terve.
• Kasvava instrumentointivelka – Perinteinen havainnollistaminen olettaa, että voit lisätä instrumentointia tarpeen mukaan. Nopeasti muuttuvissa AI-pinoissa kehittäjillä on harvoin aikaa siihen.

groundcover vastaa näihin:

• Centralisoidun näkyvyyden, joka kertoo, mitkä mallit ja toimittajat ovat käytössä.
• Työpöydät, jotka näyttävät viivettä, läpäisyä ja tokenin käyttöä ajan myötä.
• Yhdistetty LLM-käyttäytyminen ja palvelut, jotka riippuvat siitä.
• Hälytykset AI-voimaisille SLO-rikkomuksille.

Tämä tekee siitä paljon helpompaa laajentaa “yhdestä coolista AI-ominaisuudesta” “AI on kudottu kymmeniin kriittisiin palveluihin” ilman luotettavuuden menettämistä.

Miten sinä odotat LLM-havainnollistamisen kehittyvän seuraavan viiden vuoden aikana, kun agenteille AI, monimallin orkestraatio ja sääntelypainetta kiihdytetään?

Olemme edelleen varhaisessa vaiheessa. Seuraavan viiden vuoden aikana odotan useita suuria siirtymisiä:

• Pyyntötasolta agenttitasolle ymmärrys – Havainnollistaminen laajenee kaappaamaan työkalujen järjestyksiä, päättelypolkuja ja uudelleenkäynnistyslogiikkaa, ei vain mallikutsuja.
• Rikkaammat semanttiset ja käytäntösignaalit – Automaattiset laatusyötteet hallucinaatioille, turvallisuusongelmille ja brändisopimuksille tulevat standardimittauksiksi.
• Tiukempi kytkentä hallintaan ja yksityisyyteen – Kun sääntely kasvaa, havainnollistaminen palvelee myös toteutus- ja auditkerroksena tietoresidenssille, säilyttämiselle ja hyväksyttyjen mallien käytölle.
• Ylittävä mallin, monitoimittajan optimointi – Tiimit reitittävät liikennettä dynaamisesti malleja yli suorituskyvyn ja kustannusten perusteella, johdatettuna reaaliaikaisilla havainnollistamistiedoilla.
• Vähemmän manuaalista instrumentointia – Tekniikat, kuten eBPF-pohjainen kerääminen ja autonominen löytäminen, tulevat oletusarvoiseksi, jotta tiimit voivat innovoida ilman hidastumista.

Lyhyesti sanottuna LLM-havainnollistaminen kehittyy “mukavasta, joskus havainnollistamisesta AI:lle” keskeiseksi hermoston, joka yhdistää luotettavuuden, kustannusten hallinnan, tietohallinnan ja tuotteen laadun kaiken, mitä organisaatio tekee AI:lla.

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