Shahar Azulay, CEO e Co-Fondatore di groundcover

Shahar Azulay, CEO e co-fondatore di groundcover è un leader R&D seriale. Shahar porta con sé l’esperienza nel mondo della sicurezza informatica e dell’apprendimento automatico, avendo lavorato come leader in aziende come Apple, DayTwo e Cymotive Technologies. Shahar ha trascorso molti anni nel settore della sicurezza informatica presso l’Ufficio del Primo Ministro israeliano e detiene tre lauree in Fisica, Ingegneria Elettrica e Informatica presso il Technion Israel Institute of Technology e l’Università di Tel Aviv. Shahar si impegna a utilizzare le conoscenze tecnologiche derivanti da questo ricco background e a portarle nel campo della battaglia nativa cloud più innovativa e affilata, per rendere il mondo dello sviluppo un posto migliore.

groundcover è una piattaforma di osservabilità cloud-native progettata per fornire ai team di ingegneria una visibilità completa e in tempo reale dei propri sistemi senza la complessità o il costo degli strumenti di monitoraggio tradizionali. Costruita sulla tecnologia eBPF, raccoglie e correla log, metriche, tracce ed eventi in ambienti cloud-native e Kubernetes senza modifiche al codice, consentendo un’analisi più rapida delle cause radice e una comprensione più chiara del sistema. La piattaforma enfatizza la tariffazione prevedibile, la flessibilità di distribuzione che mantiene i dati nel cloud del cliente e l’osservabilità end-to-end che copre infrastrutture, applicazioni e carichi di lavoro moderni guidati dall’AI.

Guardando indietro al tuo percorso – dalla guida di team R&D di sicurezza informatica all’Ufficio del Primo Ministro israeliano alla gestione di iniziative di apprendimento automatico in Apple – quali esperienze ti hanno spinto a fondare groundcover e quando hai riconosciuto per la prima volta il divario nell’osservabilità per i sistemi AI moderni?

La spinta a fondare groundcover è arrivata dal mio tempo in Apple e DayTwo. Anche con enormi budget, eravamo bloccati a scegliere tra pagare una fortuna per registrare tutto o campionare e volare alla cieca. All’epoca, stavamo cercando una tecnologia che avrebbe risolto quel problema. Una volta che abbiamo incontrato l’Extended Berkeley Packet Filter (eBPF), era chiaro che avrebbe cambiato tutto. L’eBPF ci consente di vedere tutto ciò che accade nel kernel senza affidarsi a modifiche dell’applicazione. Non riuscivo a capire perché gli strumenti di osservabilità non stavano sfruttando quel vantaggio. Il divario nell’AI è diventato chiaro in seguito. Una volta che la nostra piattaforma Kubernetes è maturata, abbiamo visto i clienti che si affrettavano a implementare GenAI mentre trattavano i LLM come scatole nere. Sapevano che il modello rispondeva, ma non perché si comportava in modo imprevedibile o perché i costi schizzavano. Ci siamo resi conto che i flussi di lavoro agente sono semplicemente microservizi complessi e non deterministici che necessitano della stessa visibilità zero-touch che avevamo già costruito.

Come ha influenzato la tua esperienza nel settore della sicurezza informatica, dei sistemi incorporati e della R&D di apprendimento automatico la visione dietro groundcover, e quali sfide hai affrontato all’inizio nella costruzione di un’azienda centrata sull’osservabilità per applicazioni LLM e agentiche?

Il mio background nel settore della sicurezza informatica ha plasmato il DNA dell’azienda. Nel mondo dell’intelligence, si assume di non controllare l’applicazione. Quell’approccio è il motivo per cui groundcover non richiede strumentazione. So per esperienza che chiedere ai developer di modificare il codice è il modo più veloce per bloccare l’adozione. La sfida più difficile all’inizio con il monitoraggio LLM è stata la privacy. L’osservabilità per l’AI cattura prompt che possono contenere dati sensibili PII o IP. Il mio background ha reso ovvio che le aziende non avrebbero voluto che quei dati lasciassero il loro ambiente. È per questo che abbiamo costruito la nostra architettura in-cloud, consentendoci di fornire una visibilità approfondita sul comportamento dell’agente mentre manteniamo tutti i dati all’interno dell’ambiente del cliente.

Come definisci l’osservabilità LLM, e cosa la rende diversa dal monitoraggio tradizionale o dal monitoraggio ML?

L’osservabilità LLM è la pratica di strumentazione e monitoraggio di sistemi di produzione che utilizzano grandi modelli linguistici in modo da catturare il contesto completo di ogni inferenza: il prompt, il contesto, il completamento, l’utilizzo del token, la latenza, gli errori, i metadati del modello e, idealmente, segnali di feedback o di qualità a valle. Invece di chiedersi solo “Il servizio è attivo e veloce?” o “Questa richiesta ha generato un errore?”, l’osservabilità LLM ti aiuta a rispondere a domande come “Perché questa richiesta specifica ha avuto successo o fallito?”, “Cosa è realmente accaduto all’interno di questo flusso di lavoro multi-step?” e “Come i cambiamenti ai prompt, al contesto o alle versioni del modello stanno influenzando il costo, la latenza e la qualità dell’output?” Questo è molto diverso dal monitoraggio tradizionale o anche dal monitoraggio classico ML. Gli approcci legacy sono tarati per sistemi deterministici, metriche di infrastruttura e soglie statiche. Le applicazioni LLM sono non deterministiche, aperte e fortemente dipendenti dal contesto. Il successo è spesso semantico e soggettivo, non solo un codice di stato 200 vs 500. Ciò significa che devi tracciare input e output, comprendere le chiamate di strumenti e i passaggi di recupero, valutare le risposte per cose come allucinazioni o violazioni di politiche e collegare i costi e i ritardi a livello di token al flusso di lavoro e all’infrastruttura circostanti.

Quali sfide introducono le applicazioni alimentate da LLM che rendono insufficienti gli strumenti di osservabilità tradizionali?

I sistemi alimentati da LLM introducono diverse sfide che espongono i limiti degli strumenti tradizionali:

• Flussi di lavoro complessi e multi-step – Siamo passati da flussi semplici “chiama un modello, ottieni una risposta” a flussi multi-turn, pipeline multi-step, generazione arricchita e utilizzo di strumenti. Un fallimento silenzioso in uno di quei passaggi, come il recupero, l’arricchimento, l’incorporamento, la chiamata di strumenti o la chiamata del modello, può interrompere l’intera esperienza. Il monitoraggio tradizionale di solito non ti fornisce una visuale completa e a livello di traccia di quelle catene con prompt e risposte incluse.
• Pila di AI in rapida evoluzione – I team stanno aggiungendo nuovi modelli, strumenti e fornitori a un ritmo che non hanno mai visto prima. In molte aziende, nessuno può elencare con certezza quali modelli sono in produzione in un dato momento. L’osservabilità classica presume che tu abbia il tempo per strumentare gli SDK, ridistribuire e curare attentamente ciò che si misura. Ciò semplicemente non tiene il passo con la velocità con cui l’AI sta essere adottata.
• Economia e quote basate sui token – I prezzi e i limiti di velocità sono legati ai token e alla lunghezza del contesto, che sono spesso controllati dagli sviluppatori, dai prompt o dal comportamento dell’utente, e non dalle operazioni centrali. Gli strumenti tradizionali non sono progettati per mostrarti “chi ha bruciato quanti token su quale modello, per quale flusso di lavoro, a quale latenza”.
• Correttezza semantica invece del successo binario – Un LLM può restituire un 200 e ancora allucinare, allontanarsi dal tuo prompt o violare le politiche. Gli strumenti tradizionali vedono ciò come un successo. Hai bisogno di un’osservabilità che possa portare in superficie i prompt e le risposte e darti abbastanza contesto per ispezionare il comportamento e, nel tempo, collegare controlli di qualità automatizzati.
• Dati di input sensibili che fluiscono in terze parti – I LLM invitano gli utenti a condividere informazioni estremamente sensibili attraverso interfacce di tipo chat. Ora sei responsabile per quei dati, dove vengono archiviati e quali fornitori li vedono. L’osservabilità SaaS convenzionale che spedisce tutta la telemetria a un fornitore di terze parti è spesso inaccettabile per questi carichi di lavoro.

Tutto ciò significa che i sistemi LLM richiedono un’osservabilità che sia consapevole dell’AI, ricca di contesto e molto meno dipendente dalla strumentazione manuale degli strumenti che la maggior parte dei team utilizza oggi.

Quali segnali o metriche sono più importanti per comprendere le prestazioni e la qualità dei sistemi LLM, inclusi la latenza, l’utilizzo dei token e il comportamento prompt/risposta?

Ci sono alcune categorie di segnali che contano molto nella pratica:

Latenza e throughput

• Latenza end-to-end per richiesta, inclusa la latenza del modello e del tempo dell’applicazione circostante.
• Latenze della coda (P90, P95, P99) per modello e per flusso di lavoro.
• Throughput per modello, percorso e servizio, in modo da sapere dove sta andando realmente il carico.

Utilizzo dei token e driver di costo

• Token di input e output per richiesta, suddivisi per modello.
• Utilizzo aggregato dei token nel tempo per modello, team, utente e flusso di lavoro.
• Dimensioni del contesto per pipeline di recupero pesante in modo da poter vedere quando i prompt esplodono.
• Questo è ciò che ti consente di rispondere “Chi sta realmente spendendo il nostro budget AI e per cosa?”

Comportamento prompt e risposta

• I payload effettivi dei prompt e delle risposte su tracce rappresentative, inclusi percorsi di strumenti e percorsi di ragionamento.
• Quali strumenti l’LLM ha scelto di chiamare e in quale sequenza.
• Variabilità nelle risposte per prompt simili in modo da poter dire quanto stabile è il comportamento.

Affidabilità e errori

• Tassi di errore specifici del modello e tipi (errori del fornitore, timeout, problemi di autenticazione, errori di quota).
• Fallimenti nel flusso di lavoro circostante, come timeout di strumenti o errori di recupero, correlati con la chiamata LLM.

Contesto classico infra

• Metriche CPU, memoria e rete dei contenitori per i servizi che orchestrano le tue chiamate LLM.
• Log correlati che descrivono cosa stava cercando di fare l’applicazione.

Quando puoi vedere tutto ciò in un unico posto, l’osservabilità LLM passa da “So che qualcosa è lento o costoso” a “So esattamente quale modello, pattern di prompt e servizio sono responsabili e perché”.

Come può aiutare l’osservabilità a rilevare fallimenti silenziosi come la deriva dei prompt, le allucinazioni o il degrado graduale della qualità dell’output?

I fallimenti silenziosi nei sistemi LLM di solito si verificano quando tutto sembra “verde” a livello di infrastruttura, ma il comportamento reale è in deriva. L’osservabilità aiuta in diversi modi:

• Tracciando l’intero flusso di lavoro, non solo la chiamata del modello – Catturando l’intero percorso di una richiesta dal client al servizio al recupero al modello agli strumenti, puoi vedere dove è cambiato il comportamento. Ad esempio, forse il recupero ha iniziato a restituire meno documenti o una chiamata di strumento sta fallendo intermittente e il modello sta improvvisando.
• Mantenendo i prompt, il contesto e le risposte in vista – Quando puoi ispezionare i prompt e le risposte accanto alle tracce, diventa molto più facile individuare casi in cui una nuova versione del prompt, una nuova istruzione di sistema o una nuova fonte di contesto ha cambiato il comportamento, anche se la latenza e i tassi di errore sono rimasti gli stessi.
• Filtrando e affettando su condizioni semantiche – Una volta che hai una telemetria LLM ricca, puoi filtrare verso cose come “chiamate bedrock oltre un secondo”, “richieste che utilizzano questa famiglia di modelli” o “tracce che coinvolgono questo particolare percorso”, poi leggi i prompt e le risposte per vedere se il modello sta derivando o allucinando in uno scenario specifico.
• Segnalazione di SLO a livello aziendale – Puoi definire SLO come “qualsiasi chiamata LLM oltre un secondo viola il nostro SLA utente” e attivare avvisi quando vengono soddisfatte quelle condizioni. Nel tempo, SLO simili possono essere collegati a punteggi di qualità o controlli di politica in modo da ricevere avvisi quando la qualità si degrada, non solo quando fallisce l’infrastruttura.

Perché il livello di osservabilità ha accesso sia ai segnali specifici dell’AI che ai log, metriche e tracce classiche, diventa un punto naturale per catturare problemi che altrimenti degraderebbero silenziosamente l’esperienza utente.

Come supporta l’approccio di groundcover la diagnosi di latenza imprevedibile o comportamento inatteso all’interno di flussi di lavoro di agenti multi-step e chiamate di strumenti?

groundcover adotta un approccio progettato per i sistemi AI moderni. Utilizziamo un sensore basato su eBPF a livello di kernel per osservare il traffico attraverso i microservizi senza modifiche al codice o ridistribuzioni. Non appena introduci un flusso di lavoro LLM, possiamo auto-scoprire quelle chiamate. Se inizi a utilizzare un nuovo modello come Anthropic, OpenAI o Bedrock domani, groundcover cattura automaticamente quel traffico. Ciò ti dà:

• Tracce end-to-end di flussi di lavoro multi-hop – Vedi l’intero percorso di una richiesta attraverso i servizi, inclusa l’LLM o lo strumento utilizzato.
• Contesto approfondito su ogni chiamata LLM – Ogni chiamata include il modello utilizzato, la latenza, l’utilizzo dei token, i prompt, le risposte e i log e le metriche di infrastruttura correlate.
• Filtraggio potente sulla latenza e sulle condizioni – Ad esempio, puoi filtrare tutte le chiamate Claude 3.5 oltre un secondo e ispezionare immediatamente le tracce che hanno violato il tuo SLA.
• Avvisi e dashboard legati al comportamento LLM – Una volta che i dati sono disponibili, puoi creare avvisi per violazioni del SLA o costruire dashboard che tracciano la latenza, il throughput, l’utilizzo dei token ed gli errori.

Perché tutto viene raccolto ai margini da eBPF e archiviato nel tuo cloud, ottieni una visibilità ad alta granularità senza aggiungere strumentazione all’interno di ogni agente o chiamata di strumento.

Quali rischi di sicurezza dei dati e di conformità vedi emergere nelle implementazioni LLM, e come può aiutare l’osservabilità a ridurre quei rischi?

Le implementazioni LLM presentano alcuni rischi di sicurezza dei dati unici:

• Input utente non limitato – Gli utenti possono digitare informazioni estremamente sensibili in interfacce di tipo chat e interfacce AI. Ciò può includere dati personali, dati dei clienti o informazioni regolamentate che non intendevi raccogliere.
• Fornitori di modelli di terze parti – Una volta che invii quei dati a un fornitore LLM esterno, sei responsabile per dove vanno, come vengono archiviati e quali subprocessori sono coinvolti. Ciò ha importanti implicazioni per il GDPR, la residenza dei dati e la fiducia del cliente.
• Telemetria come seconda copia di dati sensibili – Se la tua pila di osservabilità spedisce payload completi a un fornitore SaaS, ora hai un’altra copia di quei dati sensibili che si trova al di fuori del tuo ambiente.

L’architettura di groundcover è progettata per affrontare proprio quelle preoccupazioni:

• Utilizziamo un modello “porta il tuo cloud” in cui l’intera infrastruttura di osservabilità viene eseguita all’interno del tuo account cloud, in un sottaccount, come piano di dati completamente gestito. Il piano di controllo che lo scala e lo gestisce è eseguito da noi, ma non accediamo, archiviamo o elaboriamo i tuoi dati di telemetria.
• Perché possiamo catturare payload in sicurezza all’interno del tuo ambiente, puoi osservare i prompt, le risposte e i flussi di lavoro senza che quei dati lascino mai il tuo cloud. Non c’è archiviazione di terze parti delle tue tracce LLM e non c’è ulteriore uscita dei dati di cui preoccuparsi.
• Con quella visibilità, puoi vedere chi sta caricando cosa e dove fluisce, rilevare un uso imprevisto di dati sensibili ed applicare politiche su quali modelli e regioni sono autorizzati.

In altre parole, l’osservabilità diventa non solo uno strumento di affidabilità e costo, ma anche un punto di controllo chiave per la privacy, la residenza dei dati e la conformità.

Man mano che le organizzazioni scalano da un’integrazione LLM a molti servizi alimentati da AI, quali sfide operative tendono a emergere intorno alla visibilità, all’affidabilità e al costo?

La prima integrazione è di solito un modello singolo in un flusso di lavoro singolo. A quel punto, le cose sembrano gestibili. Appena i team vedono il valore, l’uso esplode e diverse sfide appaiono:

• Diffusione di modelli e fornitori – I team testano costantemente nuovi modelli. Presto diventa chiaro che non è chiaro quali modelli sono in produzione e come vengono utilizzati.
• Sorprese di costo a causa dell’utilizzo dei token – Il consumo di token cresce con la lunghezza del contesto e la complessità del flusso di lavoro. Senza visibilità sull’utilizzo dei token per modello e flusso di lavoro, gestire i costi è molto difficile.
• Dipendenze di affidabilità da fornitori esterni – Le API utente diventano sensibili alla latenza del modello o agli errori, che possono interrompere gli SLA anche quando l’infrastruttura di base è sana.
• Debito di strumentazione in aumento – L’osservabilità tradizionale presume che tu possa aggiungere strumentazione quando necessario. Nelle pile AI in rapida evoluzione, gli sviluppatori raramente hanno il tempo per farlo.

groundcover affronta queste sfide fornendo:

• Visibilità centrale su quali modelli e fornitori vengono utilizzati.
• Dashboard che mostrano la latenza, il throughput e l’utilizzo dei token nel tempo.
• Correlazione tra il comportamento LLM e i servizi che dipendono da esso
• Avvisi per violazioni del SLA guidate dall’AI.

Ciò rende molto più facile scalare da “una funzionalità AI cool” a “l’AI è intessuta in dozzine di servizi critici” senza perdere il controllo.

Guardando avanti, come ti aspetti che l’osservabilità LLM evolva nei prossimi cinque anni man mano che l’AI agente, l’orchestrazione multi-modello e le pressioni regolamentari accelerano?

Siamo ancora ai primi giorni. Nei prossimi cinque anni, mi aspetto alcuni grandi cambiamenti:

• Dal livello di richiesta al livello di agente – L’osservabilità si estenderà per catturare sequenze di strumenti, percorsi di ragionamento e logica di ritentativi, non solo chiamate di modelli.
• Segnali semantici e di politica più ricchi – Controlli di qualità automatizzati per allucinazioni, problemi di sicurezza e allineamento con il marchio diventeranno metriche standard.
• Collegamento più stretto con la governance e la privacy – Man mano che la regolamentazione cresce, l’osservabilità servirà anche come livello di applicazione e audit per la residenza dei dati, la conservazione e l’uso dei modelli approvati.
• Ottimizzazione cross-modello e cross-fornitore – I team routeranno il traffico attraverso i modelli in modo dinamico in base alle prestazioni e ai costi, guidati da dati di osservabilità in tempo reale.
• Meno strumentazione manuale – Tecniche come la raccolta basata su eBPF e l’auto-scoperta diventeranno il default, in modo che i team possano innovare senza rallentare.

In sintesi, l’osservabilità LLM evolverà da “bella da avere dashboard per l’AI” al sistema nervoso centrale che collega l’affidabilità, il controllo dei costi, la governance dei dati e la qualità del prodotto attraverso tutto ciò che un’organizzazione fa con l’AI.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare groundcover.