Shahar Azulay, Groundcoverin toimitusjohtaja ja yksi perustajista

Shahar Azulay, Groundcoverin toimitusjohtaja ja yksi perustajista on sarjatyön johtaja tutkimus- ja kehitystyössä. Shaharilla on kokemusta kyberturvallisuuden ja koneoppimisen maailmasta työskenneltyään johtotehtävissä yrityksissä, kuten Apple, DayTwo ja Cymotive Technologies. Shahar työskenteli useita vuosia Israelin pääministerin kanslian kyberosastolla ja hänellä on kolme tutkintoa fysiikasta, sähkötekniikasta ja tietojenkäsittelytieteestä Technion Israel Institute of Technologysta sekä Tel Avivin yliopistosta. Shahar pyrkii hyödyntämään tätä rikasta taustaa ja teknologista oppimaansa ja tuomaan sen nykypäivän pilvinatiiville taistelukentälle terävimmässä ja innovatiivisimmassa muodossa tehdäkseen kehitysmaailmasta paremman paikan.

maasuojus on pilvinatiivi havainnoitavuusalusta, joka on suunniteltu antamaan suunnittelutiimeille täyden, reaaliaikaisen näkyvyyden järjestelmiinsä ilman perinteisten valvontatyökalujen monimutkaisuutta tai kustannuksia. eBPF-teknologiaan perustuva se kerää ja korreloi lokeja, mittareita, jälkiä ja tapahtumia pilvinatiiveissa ja Kubernetes-ympäristöissä ilman koodimuutoksia, mikä mahdollistaa nopeamman perussyyanalyysin ja selkeämmän järjestelmäkäsityksen. Alusta korostaa ennustettavaa hinnoittelua, joustavaa käyttöönottoa, joka pitää tiedot asiakkaan pilvessä, sekä kokonaisvaltaista havainnoitavuutta, joka kattaa infrastruktuurin, sovellukset ja modernit tekoälypohjaiset työkuormat.

Kun katsot taaksepäin matkaasi – Israelin pääministerin kanslian kybertutkimus- ja kehitystiimien johtamisesta Applen koneoppimishankkeiden hallintaan – mitkä kokemukset lopulta ajoivat sinut perustamaan groundcover-yrityksen, ja milloin tunnistit ensimmäisen kerran nykyaikaisten tekoälyjärjestelmien havaittavuusvajeen?

Sysäys groundcover-palvelun löytämiseen tuli ajastani Applella ja DayTwolla. Jopa valtavilla budjeteilla olimme jumissa valitsemassa, maksoimmeko omaisuuksia kaiken lokitietojen keräämisestä vai ottaisimmeko näytteitä ja lentäisimme sokkona. Silloin etsimme teknologiaa, joka ratkaisisi tämän. Kun törmäsimme Extended Berkeley Packet Filter (eBPF) -suodattimeen, oli selvää, että se muuttaisi kaiken. eBPF antaa meille mahdollisuuden nähdä kaiken ytimessä tapahtuvan ilman, että meidän tarvitsee luottaa sovellusmuutoksiin. En voinut ymmärtää, miksi havainnointityökalut eivät hyödyntäneet tätä. Tekoälykuilu kävi selväksi myöhemmin. Kun Kubernetes-alustamme kypsyi, näimme asiakkaiden kiirehtivän GenAI-käyttöönottoja ja kohtelevan LLM:iä kuin mustia laatikoita. He tiesivät mallin reagoivan, mutta eivät tienneet, miksi se käyttäytyi arvaamattomasti tai miksi kustannukset nousivat. Ymmärsimme, että agenttiset työnkulut ovat yksinkertaisesti monimutkaisia, ei-deterministisiä mikropalveluita, jotka tarvitsevat saman nolla-kosketusnäkymän, jonka olimme jo rakentaneet.

Miten taustasi kyberturvallisuuden, sulautettujen järjestelmien ja koneoppimisen tutkimus- ja kehitystyön parissa vaikutti groundcoverin taustalla olevaan visioon, ja mitä varhaisia ​​haasteita kohtasit rakentaessasi yritystä, joka keskittyy LLM-pohjaisten ja agenttisten sovellusten havainnoitavuuteen?

Kyberturvallisuustaustani muovasi yrityksen DNA:ta. Älykkyysmaailmassa oletetaan, ettet hallitse sovellusta. Tämän lähestymistavan vuoksi groundcover ei vaadi instrumentointia. Tiedän kokemuksesta, että kehittäjien pyytäminen muokkaamaan koodia on nopein tapa estää käyttöönotto. Vaikein haaste LLM-valvonnassa alussa oli yksityisyys. Tekoälyn havainnoitavuus tallentaa kehotteita, jotka saattavat sisältää arkaluonteisia henkilötietoja tai IP-osoitteita. Taustani teki selväksi, että yritykset eivät haluaisi kyseisen datan poistuvan ympäristöstään. Siksi rakensimme pilviarkkitehtuurimme, jonka avulla voimme tarjota syvällisen näkyvyyden agenttien toimintaan pitäen samalla kaikki tiedot asiakkaan omassa ympäristössä.

Miten määrittelet LLM:n havaittavuuden, ja mikä erottaa sen perinteisestä seurannasta tai koneoppimisen seurannasta?

LLM-havainnoitavuus on käytäntöä, jossa instrumentoidaan ja valvotaan tuotantojärjestelmiä, jotka käyttävät laajoja kielimalleja, jotta voit tallentaa jokaisen päätelmän koko kontekstin: kehotteen, kontekstin, valmistumisen, tunnuksen käytön, latenssin, virheet, mallin metatiedot ja mieluiten alavirran palautteen tai laatusignaalit. Sen sijaan, että kysyttäisiin vain "Onko palvelu toiminnassa ja nopea?" tai "Tekisikö tämä pyyntö virheen?", LLM-havainnoitavuus auttaa sinua vastaamaan kysymyksiin, kuten "Miksi tämä tietty pyyntö onnistui tai epäonnistui?", "Mitä oikeastaan ​​tapahtui tässä monivaiheisessa työnkulussa?" ja "Miten kehotteiden, kontekstin tai malliversioiden muutokset vaikuttavat kustannuksiin, latenssiin ja tulosteen laatuun?". Tämä on hyvin erilainen kuin perinteinen valvonta tai edes klassinen koneoppimisvalvonta. Perinteiset lähestymistavat on viritetty deterministisille järjestelmille, infrastruktuurimittareille ja staattisille kynnysarvoille. LLM-sovellukset ovat ei-deterministisiä, avoimia ja erittäin kontekstista riippuvaisia. Onnistuminen on usein semanttista ja subjektiivista, ei vain 200 vs. 500 -tilakoodia. Tämä tarkoittaa, että sinun on jäljitettävä syötteet ja tuotokset, ymmärrettävä työkalukutsuja ja hakuvaiheita, arvioitava vastauksia esimerkiksi hallusinaatioiden tai käytäntörikkomusten varalta ja yhdistettävä token-tason kustannukset ja viiveet takaisin ympäröivään sovellukseen ja infrastruktuuriin.

Mitä haasteita LLM-pohjaiset sovellukset tuovat mukanaan, jotka tekevät perinteisistä havainnointityökaluista riittämättömiä?

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

• Monimutkaiset, monivaiheiset työnkulut – Siirryimme yksinkertaisista ”kutsu malli, pyydä vastaus” -työnkuluista monivaiheisiin agentteihin, monivaiheisiin provisseihin, haun ja lisätyn generoinnin sekä työkalujen käyttöön. Hiljainen virhe missä tahansa näistä vaiheista, kuten haussa, rikastamisessa, upottamisessa, työkalukutsussa tai mallikutsussa, voi rikkoa koko kokemuksen. Perinteinen valvonta ei yleensä anna täydellistä, jäljitystason kuvaa näistä ketjuista kehotteineen ja vastauksineen.
• Nopeasti kehittyvät tekoälypinot – Tiimit lisäävät uusia malleja, työkaluja ja toimittajia ennennäkemättömällä tahdilla. Monissa yrityksissä kukaan ei voi luottavaisesti listata, mitkä mallit ovat tuotannossa milläkin hetkellä. Klassinen havaittavuus yleensä olettaa, että sinulla on aikaa instrumentoida SDK:ita, ottaa ne uudelleen käyttöön ja kuratoida huolellisesti mittaamiasi malleja. Tämä ei yksinkertaisesti pysy tekoälyn käyttöönoton vauhdissa.
• Token-pohjainen taloustiede ja kiintiöt – Hinnoittelu ja nopeusrajoitukset on sidottu tokeneihin ja kontekstin pituuteen, joita usein ohjaavat kehittäjät, kehotteet tai käyttäjien toiminta, eivätkä keskitetyt operaattorit. Perinteisiä työkaluja ei ole rakennettu näyttämään, "kuka poltti kuinka monta tokenia missäkin mallissa, missä työnkulussa ja millä latenssilla".
• Semanttinen oikeellisuus binäärisen menestyksen sijaan – LLM voi palauttaa arvon 200 ja silti hallusinoida, ajautua pois kehotteistasi tai rikkoa sääntöjä. Perinteiset työkalut näkevät tämän menestyksenä. Tarvitset havaittavuutta, joka voi nostaa esiin kehotteita ja vastauksia ja antaa sinulle riittävästi kontekstia käyttäytymisen tarkastamiseksi ja ajan myötä automatisoitujen laatutarkastusten kytkemiseksi päälle.
• Arkaluonteisten syöttötietojen virtaus kolmansille osapuolille – LLM-asiantuntijat kutsuvat käyttäjiä jakamaan erittäin arkaluonteisia tietoja chat-tyyppisten käyttöliittymien kautta. Nyt olet vastuussa tiedoista, niiden tallennuspaikasta ja siitä, ketkä toimittajat näkevät ne. Perinteinen SaaS-pohjainen havainnointijärjestelmä, jossa kaikki telemetriatiedot toimitetaan kolmannelle osapuolelle, on usein mahdotonta hyväksyä näissä työkuormissa.

Kaikki tämä tarkoittaa, että LLM-järjestelmät vaativat tekoälytietoista, kontekstirikastettua havaittavuutta, joka on paljon vähemmän riippuvainen manuaalisista instrumentoinneista kuin työkalut, joita useimmat tiimit käyttävät nykyään.

Mitkä signaalit tai mittarit ovat tärkeimpiä LLM-järjestelmien suorituskyvyn ja laadun ymmärtämisen kannalta, mukaan lukien latenssi, tokenien käyttö ja kehotteiden/vastausten käyttäytyminen?

Käytännössä on paljon merkitystä seuraavilla signaalikategorioilla:

Latenssi ja läpäisykyky

• Päästä päähän -latenssi pyyntöä kohden, mukaan lukien mallinnusaika ja sitä ympäröivä sovellusaika.
• Häntälatenssit (P90, P95, P99) mallikohtaisesti ja työnkuluittain.
• Suorituskyky mallin, reitin ja palvelun mukaan, jotta tiedät minne kuorma todella menee.

Tokenin käyttö ja kustannustekijät

• Syöttö- ja lähtötokenit pyyntöä kohden, mallin mukaan jaoteltuna.
• Yhdistetty tokenien käyttö ajan kuluessa mallin, tiimin, käyttäjän ja työnkulun mukaan.
• Kontekstikoot raskaille hakuputkille, jotta näet, milloin kehotteet räjähtävät.
• Näin voit vastata kysymykseen "Kuka todellisuudessa käyttää tekoälybudjettiamme ja mihin?".

Kehotus- ja vastauskäyttäytyminen

• Todelliset kehotteiden ja vastausten hyötykuormat edustavissa jäljityksissä, mukaan lukien työkalukutsut ja päättelypolut.
• Mitä työkaluja LLM päätti kutsua ja missä järjestyksessä.
• Vastausten vaihtelu samankaltaisissa kehotteissa, jotta voit kertoa, kuinka vakaata käyttäytyminen on.

Luotettavuus ja virheet

• Mallikohtaiset virhetiheydet ja -tyypit (palveluntarjoajavirheet, aikakatkaisut, todennusongelmat, kiintiövirheet).
• Ympäröivän työnkulun viat, kuten työkalujen aikakatkaisut tai hakuvirheet, korreloivat LLM-kutsuun.

Klassinen infrakonteksti

• LLM-puheluitasi orkestroivien palveluiden säilön suorittimen, muistin ja verkon mittarit.
• Korreloidut lokit, jotka kuvaavat, mitä sovellus yritti tehdä.

Kun kaikki tämä näkyy yhdessä paikassa, LLM:n havaittavuus siirtyy kohdasta "Tiedän, että jokin on hidasta tai kallista" asentoon "Tiedän tarkalleen, mikä malli, kehotemalli ja palvelu ovat vastuussa ja miksi".

Kuinka havaittavuus voi auttaa tiimejä havaitsemaan hiljaisia ​​​​virheitä, kuten nopeaa ajautumista, hallusinaatioita tai tulosteen laadun asteittaista heikkenemistä?

Hiljaisia ​​vikoja LLM-järjestelmissä tapahtuu yleensä silloin, kun infrastruktuuritasolla kaikki näyttää "vihreältä", mutta todellinen käyttäytyminen on ajautumista. Havaittavuus auttaa muutamalla tavalla:

• Koko työnkulun jäljittäminen, ei vain mallikutsua – Tallentamalla koko pyyntöasiakkaan polun palveluun, hausta malliin ja työkaluihin, voit nähdä, missä toiminta muuttui. Esimerkiksi haku voi olla alkanut palauttaa vähemmän dokumentteja tai työkalukutsu epäonnistuu ajoittain ja malli improvisoi.
• Kehotteiden, kontekstin ja vastausten pitäminen mielessä – Kun kehotteita ja vastauksia voi tarkastella jäljitysten rinnalla, on paljon helpompi havaita tapaukset, joissa uusi kehotteen versio, uusi järjestelmäkäsky tai uusi kontekstilähde muutti toimintaa, vaikka latenssi ja virheprosentit pysyivät samoina.
• Semanttisten ehtojen suodattaminen ja viipalointi – Kun sinulla on kattavat LLM-telemetriatiedot, voit suodattaa tiedot esimerkiksi "kallioperäpuhelut yhden sekunnin aikana", "tätä malliperhettä käyttävät pyynnöt" tai "tähän tiettyyn reittiin liittyvät jäljet" ja lukea sitten kehotteet ja vastaukset nähdäksesi, ajautuuko tai hallusinoiko malli tietyssä tilanteessa.
• Hälytykset liiketoimintatason SLO-tileistä – Voit määrittää SLO:ita, kuten ”mikä tahansa yli sekunnin kestävä LLM-puhelu rikkoo käyttäjälle suunnattua SLA:tamme”, ja laukaista hälytyksiä, kun nämä ehdot täyttyvät. Ajan myötä samankaltaisia ​​SLO:ita voidaan sitoa laatupisteisiin tai käytäntötarkistuksiin, jotta saat ilmoituksen myös laadun heikkenemisestä, ei vain infrastruktuurin vikaantumisesta.

Koska havainnointikerroksella on pääsy sekä tekoälyyn liittyviin signaaleihin että klassisiin lokeihin, mittareihin ja jäljityksiin, siitä tulee luonnollinen paikka havaita ongelmia, jotka muuten heikentäisivät huomaamattomasti käyttökokemusta.

Miten Groundcoverin lähestymistapa tukee arvaamattoman viiveen tai odottamattoman käyttäytymisen diagnosointia monivaiheisissa agenttien työnkuluissa ja työkalukutsuissa?

groundcover käyttää nykyaikaisille tekoälyjärjestelmille suunniteltua lähestymistapaa. Käytämme ydintasolla eBPF-pohjaista anturia mikropalveluiden liikenteen tarkkailuun ilman koodimuutoksia tai uudelleenkäyttöönottoja. Heti kun otat käyttöön LLM-työnkulun, voimme automaattisesti tunnistaa kyseiset kutsut. Jos alat huomenna käyttää uutta mallia, kuten Anthropic, OpenAI tai Bedrock, groundcover tallentaa kyseisen liikenteen automaattisesti. Tämä antaa sinulle:

• Monihyppyisten työnkulkujen kokonaisvaltaiset jäljet – Näet pyynnön koko polun eri palveluissa, mukaan lukien missä käytetään LLM:ää tai työkalua.
• Syvällinen konteksti jokaisesta LLM-kutsusta – Jokainen puhelu sisältää käytetyn mallin, viiveen, tunnuksen käytön, kehotteet, vastaukset sekä korreloivat lokit ja infrastruktuurimittarit.
• Tehokas suodatus latenssin ja ehtojen perusteella – Voit esimerkiksi suodattaa kaikki yli sekunnin kestävät Claude 3.5 -puhelut ja tarkastaa välittömästi jäljet, jotka rikkoivat palvelutasosopimustasi.
• LLM:n toimintaan liittyvät hälytykset ja kojelaudat – Kun tiedot ovat saatavilla, voit luoda hälytyksiä palvelutasosopimusten rikkomuksista tai rakentaa koontinäyttöjä, jotka seuraavat viivettä, läpimenoaikaa, tokenien käyttöä ja virheitä.

Koska eBPF kerää kaiken reunalla ja tallentaa sen omaan pilveesi, saat tämän erittäin tarkan näkymän lisäämättä instrumentointia jokaisen agentin tai työkalukutsun sisällä.

Mitä tietoturva- ja vaatimustenmukaisuusriskejä näet LLM-käyttöönotoissa, ja miten havainnoitavuus voi auttaa vähentämään näitä riskejä?

LLM-käyttöönotot tuovat mukanaan joitakin ainutlaatuisia datariskejä:

• Rajaton käyttäjän syöte – Käyttäjät voivat kirjoittaa erittäin arkaluontoisia tietoja chatbotteihin ja tekoälypohjaisiin käyttöliittymiin. Näitä tietoja voivat olla esimerkiksi henkilötiedot, asiakastiedot tai säännellyt tiedot, joita ei ole koskaan tarkoitus kerätä.
• Kolmannen osapuolen mallintarjoajat – Kun lähetät tiedot ulkoiselle LLM-palveluntarjoajalle, olet vastuussa siitä, minne ne menivät, miten ne tallennetaan ja mitkä alihankkijat ovat mukana. Tällä on merkittäviä vaikutuksia GDPR:ään, tietojen säilytyspaikkaan ja asiakkaiden luottamukseen.
• Telemetria arkaluonteisten tietojen toisena kopiona – Jos havainnointipinosi toimittaa täysiä hyötykuormia SaaS-toimittajalle, sinulla on nyt toinen kopio kyseisistä arkaluonteisista tiedoista ympäristösi ulkopuolella.

groundcoverin arkkitehtuuri on suunniteltu vastaamaan juuri näihin huolenaiheisiin:

• Käytämme "bring your own cloud" -mallia, jossa täysi havainnoitavuusjärjestelmä toimii pilvitilisi sisällä, alatilillä, täysin hallittuna datatasona. Skaalaavaa ja hallinnoivaa ohjaustasoa käytämme itse, mutta emme käytä, tallenna tai käsittele telemetriatietojasi.
• Koska voimme turvallisesti tallentaa hyötykuormia omassa ympäristössäsi, voit tarkkailla kehotteita, vastauksia ja työnkulkuja ilman, että tiedot poistuvat pilvestäsi. LLM-jäljityksiäsi ei säilytetä kolmannella osapuolella, eikä ylimääräisestä tiedonsiirrosta tarvitse huolehtia.
• Tämän näkyvyyden avulla voit nähdä, kuka lataa mitä ja minne tiedot siirtyvät, havaita arkaluonteisten tietojen odottamatonta käyttöä ja valvoa käytäntöjä sen suhteen, mitkä mallit ja alueet ovat sallittuja.

Toisin sanoen havainnoitavuudesta tulee paitsi luotettavuus- ja kustannustyökalu, myös keskeinen valvontapiste yksityisyyden, tietojen säilytyksen ja vaatimustenmukaisuuden varmistamiseksi.

Kun organisaatiot laajenevat yhdestä LLM-integraatiosta useisiin tekoälypohjaisiin palveluihin, mitä operatiivisia haasteita yleensä ilmenee näkyvyyden, luotettavuuden ja kustannusten suhteen?

Ensimmäinen integraatio on yleensä yksittäinen malli yhdessä työnkulussa. Tässä vaiheessa asiat tuntuvat hallittavilta. Heti kun tiimit näkevät arvon, käyttö räjähtää ja useita haasteita ilmenee:

• Malli- ja toimittajahajoaminen – Tiimit testaavat uusia malleja jatkuvasti. Nopeasti käy epäselväksi, mitkä mallit ovat tuotannossa ja miten niitä käytetään.
• Kustannusyllätyksiä tokenien käytöstä – Tokenien kulutus kasvaa kontekstin pituuden ja työnkulun monimutkaisuuden myötä. Ilman näkyvyyttä tokenien käyttöön malli- ja työnkulkukohtaisesti kustannusten hallinta on erittäin vaikeaa.
• Luotettavuusriippuvuudet ulkoisista palveluntarjoajista – Käyttäjäkohtaiset API-rajapinnat herkistyvät mallin viiveille tai virheille, mikä voi häiritä palvelutasosopimuksia, vaikka ydininfrastruktuuri olisi kunnossa.
• Kasvava instrumentointivelka – Perinteinen havaittavuus olettaa, että instrumentointia voidaan lisätä tarvittaessa. Nopeasti kehittyvissä tekoälypinoissa kehittäjillä on harvoin aikaa siihen.

groundcover ratkaisee nämä ongelmat tunnistamalla tekoälyliikenteen automaattisesti ja tarjoamalla sinulle sitten:

• Keskitetty näkyvyys käytettyihin malleihin ja toimittajiin.
• Kojelaudat, jotka näyttävät latenssin, läpimenon ja tokenien käytön ajan kuluessa.
• LLM-käyttäytymisen ja siitä riippuvien palvelujen välinen korrelaatio
• Hälytykset tekoälyn ohjaamista SLO-murroista.

Se helpottaa paljon skaalautumista "yhdestä hienosta tekoälyominaisuudesta" "tekoälyn kudokseen kymmeniin kriittisiin palveluihin" menettämättä hallintaa.

Miten odotat LLM:n havaittavuuden kehittyvän tulevaisuuteen seuraavan viiden vuoden aikana agenttisen tekoälyn, monimallien orkestroinnin ja sääntelypaineiden kiihtyessä?

Olemme vielä alkuvaiheessa. Seuraavan viiden vuoden aikana odotan muutamia suuria muutoksia:

• Pyyntötasolta agenttitason ymmärrykseen – Havaittavuus laajenee kattamaan työkalusekvenssit, päättelypolut ja uudelleenyrityslogiikan, ei pelkästään mallikutsuja.
• Rikkaammat semanttiset ja politiikkasignaalit – Automatisoiduista laaduntarkastuksista hallusinaatioiden, turvallisuusongelmien ja brändin yhdenmukaisuuden varalta tulee vakiomittareita.
• Tiiviimpi yhteys hallintoon ja yksityisyyteen – Sääntelyn laajentuessa havaittavuus toimii myös tietojen säilytyksen, hyväksytyn mallin käytön valvonta- ja auditointikerroksena.
• Ristimalli, usean toimittajan optimointi – Tiimit reitittävät liikennettä mallien välillä dynaamisesti suorituskyvyn ja kustannusten perusteella reaaliaikaisen havainnointidatan ohjaamana.
• Vähemmän manuaalista instrumentointia – Tekniikoista, kuten eBPF-pohjaisesta keräämisestä ja automaattisesta löytämisestä, tulee oletusarvoisia, joten tiimit voivat innovoida hidastamatta tahtia.

Lyhyesti sanottuna LLM:n havaittavuus kehittyy "mukavasta, että tekoälylle on olemassa kojelaudat" -asetelmasta keskushermostoksi, joka yhdistää luotettavuuden, kustannusten hallinnan, tiedonhallinnan ja tuotteiden laadun kaikkeen, mitä organisaatio tekee tekoälyn avulla.

Kiitos upeasta haastattelusta, lukijoiden, jotka haluavat tietää lisää, kannattaa käydä maasuojus.