Shahar Azulay, CEO e co-fondatore di Groundcover

Shahar Azulay, CEO e cofondatore di Groundcover, Shahar è un leader di ricerca e sviluppo di lunga data. Shahar vanta una solida esperienza nel mondo della sicurezza informatica e dell'apprendimento automatico, avendo ricoperto ruoli dirigenziali in aziende come Apple, DayTwo e Cymotive Technologies. Shahar ha trascorso molti anni nella divisione Cyber ​​presso l'ufficio del Primo Ministro israeliano e ha conseguito 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 gli insegnamenti tecnologici derivanti da questo ricco background e a trasporli nell'attuale campo di battaglia del cloud nativo nella forma più incisiva e innovativa, per rendere il mondo dello sviluppo un posto migliore.

tappezzante è una piattaforma di osservabilità cloud-native progettata per offrire ai team di ingegneria una visibilità completa e in tempo reale sui propri sistemi, senza la complessità o i costi degli strumenti di monitoraggio tradizionali. Basata sulla tecnologia eBPF, raccoglie e correla log, metriche, tracce ed eventi in ambienti cloud-native e Kubernetes senza modifiche al codice, consentendo un'analisi delle cause profonde più rapida e una visione più chiara del sistema. La piattaforma punta su prezzi prevedibili, implementazione flessibile che mantiene i dati nel cloud del cliente e osservabilità end-to-end che abbraccia infrastruttura, applicazioni e moderni carichi di lavoro basati sull'intelligenza artificiale.

Ripensando al tuo percorso, dalla guida di team di ricerca e sviluppo in ambito informatico presso l'ufficio del Primo Ministro israeliano alla gestione di iniziative di apprendimento automatico presso Apple, quali esperienze ti hanno spinto a fondare Groundcover e quando hai riconosciuto per la prima volta il divario nell'osservabilità dei moderni sistemi di intelligenza artificiale?

La spinta a trovare una soluzione è nata durante il mio periodo in Apple e DayTwo. Anche con budget enormi, eravamo costretti a scegliere tra pagare una fortuna per registrare tutto o campionare e procedere alla cieca. All'epoca, cercavamo una tecnologia che risolvesse questo problema. Quando ci siamo imbattuti nell'Extended Berkeley Packet Filter (eBPF), è stato chiaro che avrebbe cambiato tutto. L'eBPF ci permette di vedere tutto ciò che accade nel kernel senza dipendere dalle modifiche delle applicazioni. Non riuscivo a capire perché gli strumenti di osservabilità non ne sfruttassero i vantaggi. Il divario nell'intelligenza artificiale è diventato chiaro in seguito. Una volta maturata la nostra piattaforma Kubernetes, abbiamo visto i clienti lanciarsi rapidamente nelle distribuzioni GenAI, trattando gli LLM come scatole nere. Sapevano che il modello rispondeva, ma non capivano perché si comportasse in modo imprevedibile o perché i costi stessero aumentando. Ci siamo resi conto che i flussi di lavoro agentici sono semplicemente microservizi complessi e non deterministici che necessitano della stessa visibilità zero-touch che avevamo già sviluppato.

In che modo la tua esperienza in sicurezza informatica, sistemi embedded e ricerca e sviluppo nel campo dell'apprendimento automatico ha influenzato la visione alla base di Groundcover e quali sfide iniziali hai dovuto affrontare nella creazione di un'azienda incentrata sull'osservabilità per applicazioni basate su LLM e agentiche?

La mia esperienza nel settore informatico ha plasmato il DNA dell'azienda. Nel mondo dell'intelligence, si dà per scontato di non avere il controllo dell'applicazione. Questo approccio è il motivo per cui Groundcover non richiede strumentazione. So per esperienza che chiedere agli sviluppatori di modificare il codice è il modo più rapido per bloccarne l'adozione. La sfida iniziale più ardua con il monitoraggio LLM è stata la privacy. L'osservabilità per l'intelligenza artificiale cattura i prompt che potrebbero contenere informazioni personali (PII) o IP sensibili. La mia esperienza ha reso ovvio che le aziende non avrebbero voluto che tali dati uscissero dal loro ambiente. Per questo motivo abbiamo sviluppato la nostra architettura in-cloud, che ci consente di fornire una visibilità approfondita sul comportamento degli agenti, mantenendo tutti i dati all'interno dell'ambiente del cliente.

Come si definisce l'osservabilità LLM e cosa la differenzia dal monitoraggio tradizionale o dal monitoraggio ML?

L'osservabilità LLM è la pratica di strumentazione e monitoraggio di sistemi di produzione che utilizzano modelli linguistici di grandi dimensioni in modo da poter catturare il contesto completo di ogni inferenza: prompt, contesto, completamento, utilizzo dei token, latenza, errori, metadati del modello e, idealmente, feedback a valle o segnali di qualità. Invece di chiedere semplicemente "Il servizio è attivo e veloce?" o "Questa richiesta ha generato un errore?", l'osservabilità LLM aiuta a rispondere a domande come "Perché questa particolare richiesta ha avuto successo o è fallita?", "Cosa è successo effettivamente all'interno di questo flusso di lavoro multifase?" e "In che modo le modifiche ai prompt, al contesto o alle versioni del modello influiscono su costi, latenza e qualità dell'output?". Questo è molto diverso dal monitoraggio tradizionale o persino dal monitoraggio ML classico. Gli approcci legacy sono ottimizzati per sistemi deterministici, metriche infrastrutturali 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 è necessario tracciare input e output, comprendere le chiamate degli strumenti e le fasi di recupero, valutare le risposte a fattori quali allucinazioni o violazioni delle policy e collegare i costi e i ritardi a livello di token all'applicazione e all'infrastruttura circostanti.

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

I sistemi basati su LLM introducono diverse sfide che mettono in luce i limiti degli strumenti tradizionali:

• Flussi di lavoro complessi e articolati in più fasi – Siamo passati da semplici flussi "chiama un modello, ottieni una risposta" ad agenti multi-turn, pipeline multi-step, generazione aumentata del recupero e utilizzo di strumenti. Un errore silenzioso in una qualsiasi di queste fasi, come il recupero, l'arricchimento, l'incorporamento, la chiamata dello strumento o la chiamata del modello, può compromettere l'intera esperienza. Il monitoraggio tradizionale di solito non fornisce una visione completa a livello di traccia di queste catene, con prompt e risposte inclusi.
• Stack di intelligenza artificiale in rapida evoluzione – I team stanno aggiungendo nuovi modelli, strumenti e fornitori a un ritmo mai visto prima. In molte aziende, nessuno è in grado di elencare con certezza quali modelli siano in produzione in un dato momento. L'osservabilità classica di solito presuppone di avere il tempo di strumentare gli SDK, ridistribuirli e curare attentamente ciò che si misura. Questo semplicemente non tiene il passo con la rapidità con cui l'IA viene adottata.
• Economia basata sui token e quote – I prezzi e i limiti di velocità sono legati ai token e alla lunghezza del contesto, che sono spesso controllati da sviluppatori, prompt o comportamento degli utenti, non dalle operazioni centrali. Gli strumenti tradizionali non sono progettati per mostrare "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 risultato di 200 e comunque avere allucinazioni, allontanarsi dal prompt o violare le policy. Gli strumenti tradizionali lo considerano un successo. È necessaria un'osservabilità che possa far emergere prompt e risposte e fornire un contesto sufficiente per ispezionare il comportamento e, nel tempo, integrare controlli di qualità automatici.
• Dati di input sensibili che fluiscono verso terze parti – Gli LLM invitano gli utenti a condividere informazioni molto sensibili tramite interfacce in stile chat. Ora sei responsabile di quei dati, di dove vengono archiviati e di quali fornitori li possono visualizzare. L'osservabilità convenzionale basata su SaaS, che invia tutta la telemetria a terze parti, è spesso inaccettabile per questi carichi di lavoro.

Tutto ciò significa che i sistemi LLM richiedono un'osservabilità che tenga conto dell'intelligenza artificiale, sia ricca di contesto e molto meno dipendente dalla strumentazione manuale rispetto agli strumenti utilizzati oggi dalla maggior parte dei team.

Quali segnali o parametri sono più importanti per comprendere le prestazioni e la qualità dei sistemi LLM, tra cui latenza, utilizzo dei token e comportamento di prompt/risposta?

Esistono alcune categorie di segnali che hanno molta importanza nella pratica:

Latenza e produttività

• Latenza end-to-end per richiesta, inclusi il tempo del modello e il tempo dell'applicazione circostante.
• Latenze di coda (P90, P95, P99) per modello e per flusso di lavoro.
• Capacità di elaborazione per modello, percorso e servizio, così puoi sapere dove sta realmente andando il carico.

Utilizzo dei token e fattori 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 pesanti, in modo da poter vedere quando i prompt stanno esplodendo.
• Questo è ciò che ti consente di rispondere alla domanda "Chi sta effettivamente spendendo il nostro budget per l'intelligenza artificiale e per cosa?"

Comportamento rapido e reattivo

• I payload effettivi di prompt e risposta su tracce rappresentative, comprese le chiamate degli strumenti e i percorsi di ragionamento.
• Quali strumenti l'LLM ha scelto di richiamare e in quale sequenza.
• Variabilità nelle risposte per richieste simili, così da poter stabilire quanto stabile sia il comportamento.

Affidabilità ed errori

• Tipi e tassi di errore specifici del modello (errori del provider, timeout, problemi di autorizzazione, errori di quota).
• Errori nel flusso di lavoro circostante, come timeout degli strumenti o errori di recupero, erano correlati alla chiamata LLM.

Contesto infra classico

• Metriche di CPU, memoria e rete del contenitore per i servizi che orchestrano le chiamate LLM.
• Registri correlati che descrivono cosa stava tentando di fare l'applicazione.

Quando è possibile vedere tutto questo in un unico posto, l'osservabilità LLM passa da "So che qualcosa è lento o costoso" a "So esattamente quale modello, schema di prompt e servizio sono responsabili e perché".

In che modo l'osservabilità può aiutare i team a rilevare errori silenziosi, come deviazioni dei prompt, allucinazioni o un graduale degrado della qualità dell'output?

I guasti silenziosi nei sistemi LLM si verificano solitamente quando tutto sembra "verde" a livello di infrastruttura, ma il comportamento effettivo è instabile. L'osservabilità è utile in diversi modi:

• Tracciare l'intero flusso di lavoro, non solo la chiamata del modello – Catturando l'intero percorso di una richiesta client, dal servizio al recupero, dal modello agli strumenti, è possibile vedere dove il comportamento è cambiato. Ad esempio, il recupero potrebbe aver iniziato a restituire meno documenti, oppure una chiamata allo strumento potrebbe non funzionare a intermittenza e il modello potrebbe improvvisare.
• Mantenere in vista richieste, contesto e risposte – Quando è possibile esaminare prompt e risposte insieme alle tracce, diventa molto più facile individuare i casi in cui una nuova versione del prompt, una nuova istruzione di sistema o una nuova origine del contesto hanno modificato il comportamento, anche se la latenza e i tassi di errore sono rimasti gli stessi.
• Filtraggio e slicing in base alle condizioni semantiche – Una volta ottenuta una telemetria LLM completa, è possibile filtrare fino a elementi come "chiamate di base in un secondo", "richieste che utilizzano questa famiglia di modelli" o "tracce che coinvolgono questo particolare percorso", quindi leggere i prompt e le risposte per vedere se il modello sta deviando o allucinando in uno scenario specifico.
• Avvisi sugli SLO a livello aziendale – È possibile definire SLO come "qualsiasi chiamata LLM di durata superiore a un secondo viola il nostro SLA rivolto all'utente" e attivare avvisi quando tali condizioni vengono soddisfatte. Nel tempo, SLO simili possono essere associati a punteggi di qualità o controlli delle policy, in modo da ricevere avvisi in caso di peggioramento della qualità, non solo in caso di guasti all'infrastruttura.

Poiché il livello di osservabilità ha accesso sia ai segnali specifici dell'IA sia ai log, alle metriche e alle tracce classici, diventa il luogo naturale in cui individuare problemi che altrimenti comprometterebbero silenziosamente l'esperienza dell'utente.

In che modo l'approccio di Groundcover supporta la diagnosi di latenze imprevedibili o comportamenti inattesi all'interno di flussi di lavoro degli agenti e chiamate di strumenti in più fasi?

Groundcover adotta un approccio progettato per i moderni sistemi di intelligenza artificiale. Utilizziamo un sensore basato su eBPF a livello di kernel per osservare il traffico tra i microservizi senza modifiche al codice o ridistribuzioni. Non appena si introduce un flusso di lavoro LLM, possiamo rilevare automaticamente tali chiamate. Se domani si inizia a utilizzare un nuovo modello come Anthropic, OpenAI o Bedrock, Groundcover acquisisce automaticamente tale traffico. Questo offre:

• Tracce end-to-end di flussi di lavoro multi-hop – È possibile visualizzare il percorso completo di una richiesta tra i servizi, incluso dove viene utilizzato un LLM o uno strumento.
• Contesto approfondito di ogni chiamata LLM – Ogni chiamata include il modello utilizzato, la latenza, l'utilizzo del token, i prompt, le risposte, i log correlati e le metriche infrastrutturali.
• Potente filtraggio su latenza e condizioni – Ad esempio, puoi filtrare tutte le chiamate Claude 3.5 della durata di un secondo e ispezionare immediatamente le tracce che hanno violato il tuo SLA.
• Avvisi e dashboard collegati al comportamento LLM – Una volta che i dati sono disponibili, è possibile creare avvisi per le violazioni degli SLA o creare dashboard che monitorano latenza, produttività, utilizzo dei token ed errori.

Poiché tutto viene raccolto all'edge da eBPF e archiviato nel tuo cloud, ottieni questa vista ad alta granularità senza dover aggiungere strumentazione in ogni agente o chiamata allo strumento.

Quali rischi per la sicurezza dei dati e la conformità emergono nelle implementazioni LLM e in che modo l'osservabilità può contribuire a ridurre tali rischi?

Le distribuzioni LLM comportano alcuni rischi specifici per i dati:

• Input utente illimitato – Gli utenti possono digitare informazioni estremamente sensibili nei chatbot e nelle interfacce basate sull'intelligenza artificiale. Possono includere dati personali, dati dei clienti o informazioni regolamentate che non si desiderava raccogliere.
• Fornitori di modelli di terze parti – Una volta inviati i dati a un fornitore LLM esterno, sei responsabile della loro destinazione, delle modalità di archiviazione e dei sub-responsabili coinvolti. Ciò ha implicazioni importanti per il GDPR, la residenza dei dati e la fiducia dei clienti.
• La telemetria come seconda copia dei dati sensibili – Se il tuo stack di osservabilità invia payload completi a un fornitore SaaS, ora disponi di un'altra copia di tali informazioni sensibili all'esterno del tuo ambiente.

L'architettura di Groundcover è progettata per rispondere esattamente a queste esigenze:

• Utilizziamo un modello "Bring Your Own Cloud" in cui il backend di osservabilità completo viene eseguito all'interno del tuo account cloud, in un sottoaccount, come piano dati completamente gestito. Il piano di controllo che lo scala e lo gestisce è gestito da noi, ma non accediamo, memorizziamo o elaboriamo i tuoi dati di telemetria.
• Grazie alla nostra capacità di acquisire payload in modo sicuro nel tuo ambiente, puoi osservare prompt, risposte e flussi di lavoro senza che i dati escano mai dal tuo cloud. Non è necessario alcun archivio di terze parti per le tue tracce LLM e non devi preoccuparti di ulteriori dati in uscita.
• Grazie a questa visibilità, puoi vedere chi sta caricando cosa e dove scorre, rilevare l'utilizzo imprevisto di dati sensibili e applicare policy sui modelli e sulle regioni consentiti.

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

Man mano che le organizzazioni passano da un'integrazione LLM a molti servizi basati sull'intelligenza artificiale, quali sfide operative tendono a presentarsi in termini di visibilità, affidabilità e costi?

La prima integrazione consiste solitamente in un singolo modello in un singolo flusso di lavoro. A questo punto, la situazione sembra gestibile. Non appena i team ne percepiscono il valore, l'utilizzo esplode e si presentano diverse sfide:

• Proliferazione di modelli e fornitori – I team testano costantemente nuovi modelli. Diventa presto poco chiaro quali siano quelli in produzione e come vengano utilizzati.
• Sorprese sui costi derivanti dall'utilizzo dei token – Il consumo di token aumenta con la lunghezza del contesto e la complessità del flusso di lavoro. Senza visibilità sull'utilizzo dei token per modello e flusso di lavoro, la gestione dei costi è molto difficile.
• Affidabilità dipendenze da fornitori esterni – Le API rivolte all'utente diventano sensibili alla latenza o agli errori del modello, che possono compromettere gli SLA anche quando l'infrastruttura principale è in buone condizioni.
• Debito crescente della strumentazione – L'osservabilità tradizionale presuppone che sia possibile aggiungere strumentazione quando necessario. Negli stack di intelligenza artificiale in rapida evoluzione, gli sviluppatori raramente hanno tempo per questo.

Groundcover affronta questi problemi rilevando automaticamente il traffico AI e fornendoti:

• Visibilità centralizzata sui modelli e sui fornitori utilizzati.
• Dashboard che mostrano latenza, produttività e utilizzo dei token nel tempo.
• Correlazione tra il comportamento dell'LLM e i servizi che da esso dipendono
• Avvisi per violazioni SLO basate sull'intelligenza artificiale.

Ciò rende molto più semplice passare da "una caratteristica AI interessante" a "l'AI è integrata in decine di servizi critici" senza perdere il controllo.

Guardando al futuro, come prevede che evolverà l'osservabilità dell'LLM nei prossimi cinque anni, con l'accelerazione dell'intelligenza artificiale agentiva, dell'orchestrazione multi-modello e delle pressioni normative?

Siamo ancora agli inizi. Nei prossimi cinque anni, mi aspetto alcuni grandi cambiamenti:

• Dalla comprensione a livello di richiesta a quella a livello di agente – L'osservabilità verrà ampliata per catturare sequenze di strumenti, percorsi di ragionamento e logica di ripetizione, non solo chiamate di modelli.
• Segnali semantici e politici più ricchi – I controlli di qualità automatizzati per rilevare allucinazioni, problemi di sicurezza e allineamento del marchio diventeranno parametri standard.
• Un legame più stretto con la governance e la privacy – Con l’aumento della regolamentazione, l’osservabilità fungerà anche da livello di controllo e di applicazione per la residenza dei dati, la conservazione e l’utilizzo di modelli approvati.
• Modello incrociato, ottimizzazione multi-fornitore – I team instraderanno il traffico tra i modelli in modo dinamico, in base alle prestazioni e ai costi, guidati dai dati di osservabilità in tempo reale.
• Meno strumentazione manuale – Tecniche come la raccolta basata su eBPF e la scoperta automatica diventeranno la norma, così i team potranno innovare senza rallentare.

In breve, l'osservabilità LLM evolverà da "cruscotti per l'intelligenza artificiale utili" a sistema nervoso centrale che collega affidabilità, controllo dei costi, governance dei dati e qualità del prodotto in tutto ciò che un'organizzazione fa con l'intelligenza artificiale.

Grazie per l'ottima intervista, i lettori che desiderano saperne di più dovrebbero visitare tappezzante.