Shahar Azulay, CEO și Co-Fondator al groundcover

Shahar Azulay, CEO și co-fondator al groundcover, este un lider serial în domeniul R&D. Shahar aduce experiență în lumea securității cibernetice și a învățării automate, având lucrat ca lider în companii precum Apple, DayTwo și Cymotive Technologies. Shahar a petrecut mulți ani în divizia de securitate cibernetică a Biroului Prim-ministrului israelian și deține trei diplome în Fizică, Inginerie Electrică și Informatică de la Institutul Tehnologic Israelian din Technion, precum și de la Universitatea Tel Aviv. Shahar se străduiește să folosească cunoștințele tehnologice din acest mediu bogat și să le aducă în lumea actuală a războiului cibernetic, într-o formă inovatoare și ascuțită, pentru a face lumea dezvoltatorilor un loc mai bun.

groundcover este o platformă de observabilitate nativă în cloud, proiectată pentru a oferi echipelor de ingineri o vizibilitate completă și în timp real asupra sistemelor lor, fără complexitatea sau costul instrumentelor de monitorizare tradiționale. Construită pe tehnologia eBPF, colectează și corelează jurnale, metrice, urme și evenimente în medii cloud-native și Kubernetes, fără modificări de cod, permițând o analiză mai rapidă a cauzelor și o înțelegere mai clară a sistemului. Platforma pune accentul pe prețuri previzibile, implementare flexibilă care păstrează datele în cloud-ul clientului și observabilitate de la capăt la capăt, care acoperă infrastructura, aplicațiile și încărcăturile de lucru moderne, conduse de inteligența artificială.

Privind înapoi la călătoria dvs. – de la conducerea echipelor de R&D în domeniul securității cibernetice din Biroul Prim-ministrului israelian la gestionarea inițiativelor de învățare automată la Apple – care experiențe v-au împins în final spre fondarea groundcover, și când ați recunoscut pentru prima dată golul în observabilitatea sistemelor moderne de inteligență artificială?

Impulsul de a fonda groundcover a venit din perioada mea de la Apple și DayTwo. Chiar și cu bugete uriașe, eram blocați să alegem între a plăti o avere pentru a înregistra totul sau a face mostre și a zbura orb. Atunci, căutam o tehnologie care să rezolve această problemă. Odată ce am dat peste Extended Berkeley Packet Filter (eBPF), a fost clar că va schimba totul. eBPF ne permite să vedem tot ce se întâmplă în nucleu fără a ne baza pe modificări ale aplicației. Nu am putut înțelege de ce instrumentele de observabilitate nu profita de această tehnologie.

Cum a influențat background-ul dvs. în securitatea cibernetică, sisteme înglobate și R&D de învățare automată viziunea din spatele groundcover, și care au fost primele provocări cu care v-ați confruntat la construirea unei companii axate pe observabilitate pentru aplicații LLM și agenți?

Background-ul meu în securitate cibernetică a modelat ADN-ul companiei. În lumea informațiilor, presupunem că nu controlăm aplicația. Această abordare este motivul pentru care groundcover nu necesită instrumentare. Știu din experiență că a cere dezvoltatorilor să modifice codul este cel mai rapid mod de a bloca adoptarea.

Cum definiți observabilitatea LLM, și ce o face diferită de monitorizarea tradițională sau monitorizarea ML?

Observabilitatea LLM este practica de instrumentare și monitorizare a sistemelor de producție care utilizează modele de limbaj mare pentru a captura contextul complet al fiecărei inferențe: promptul, contextul, finalizarea, utilizarea tokenului, întârzierea, erorile, metadatele modelului și, ideal, feedback-ul sau semnalele de calitate din aval.

Care sunt semnalele sau metricile cele mai importante pentru înțelegerea performanței și calității sistemelor LLM, incluzând întârzierea, utilizarea tokenului și comportamentul prompt/răspuns?

Există câteva categorii de semnale care contează mult în practică:

Întârziere și debit

• Întârzierea de la capăt la capăt pentru fiecare cerere, inclusiv timpul modelului și timpul aplicației înconjurătoare.
• Întârzieri de coadă (P90, P95, P99) pentru fiecare model și flux de lucru.
• Debitul pe model, rută și serviciu, astfel încât să știți unde merge încărcătura.

Utilizarea tokenului și factorii de cost

• Tokeni de intrare și ieșire pe cerere, împărțiți pe model.
• Utilizarea tokenului agregat în timp pe model, echipă, utilizator și flux de lucru.
• Dimensiunile contextului pentru conducte grele de recuperare, astfel încât să puteți vedea când prompturile explodează.
• Acesta este ceea ce vă permite să răspundeți la “Cine cheltuiește realmente bugetul nostru de inteligență artificială și pe ce?”

Comportamentul prompt și răspuns

• Încărcăturile reale de prompt și răspuns pe urme reprezentative, inclusiv apeluri de instrumente și căi de raționament.
• Care instrumente a ales LLM să apeleze și în ce secvență.
• Variabilitatea în răspunsuri pentru prompturi similare, astfel încât să puteți spune cât de stabilă este comportarea.

Fiabilitate și erori

• Ratele de eroare specifice modelului și tipurile de erori (erori de furnizor, timpi de așteptare, probleme de autentificare, erori de cotă).
• Eșecuri în fluxul de lucru înconjurător, cum ar fi timpi de așteptare ale instrumentelor sau erori de recuperare, corelate cu apelul LLM.

Contextul infrastructurii clasice

• Metrii CPU, memorie și rețea pentru containerele care orchestrează apelurile dvs. LLM.
• Jurnale corelate care descriu ce a încercat să facă aplicația.

Când puteți vedea toate acestea într-un singur loc, observabilitatea LLM trece de la “știu că ceva este lent sau scump” la “știu exact care model, tip de prompt și serviciu sunt responsabile și de ce”.

Cum poate observabilitatea ajuta echipele să detecteze eșecuri silențioase, cum ar fi derivarea promptului, halucinațiile sau degradarea treptată a calității ieșirii?

Eșecurile silențioase în sistemele LLM de obicei apar atunci când totul pare “verde” la nivelul infrastructurii, dar comportamentul real se abate. Observabilitatea ajută în câteva moduri:

• Urmarirea fluxului de lucru complet, nu doar apelul modelului – Prin capturarea întregului traseu al unei cereri de la client la serviciu la recuperare la model la instrumente, puteți vedea unde s-a schimbat comportamentul. De exemplu, poate recuperarea a început să returneze mai puține documente, sau un apel de instrument este în mod intermittent defect, iar modelul improvizează.
• Păstrarea prompturilor, contextului și răspunsurilor în vedere – Când puteți inspecta prompturi și răspunsuri alături de urme, devine mult mai ușor să identificați cazurile în care o nouă versiune de prompt, o nouă instrucțiune de sistem sau o nouă sursă de context a schimbat comportamentul, chiar dacă întârzierea și ratele de eroare au rămas aceleași.
• Filtrarea și tăierea pe condiții semantice – Odată ce aveți telemetrie LLM bogată, puteți filtra până la lucruri precum “apeluri de bază rock peste o secundă”, “cererile care folosesc această familie de modele” sau “urme care implică această rută particulară”, apoi citiți prompturile și răspunsurile pentru a vedea dacă modelul se abate sau halucinează într-un anumit scenariu.
• Alerte pe SLO-uri la nivel de afaceri – Puteți defini SLO-uri precum “orice apel LLM peste o secundă încalcă SLA-ul nostru cu față către utilizator” și declanșați alerte atunci când aceste condiții sunt îndeplinite. În timp, SLO-uri similare pot fi legate de scoruri de calitate sau verificări de politică, astfel încât să primiți alerte atunci când calitatea se degradează, nu doar atunci când infrastructura eșuează.

Deoarece stratul de observabilitate are acces la semnalele specifice AI și la jurnalele, metricele și urmele clasice, devine un loc natural pentru a prinde probleme care ar fi altfel degradează în mod silențios experiența utilizatorului.

Cum abordează groundcover diagnosticarea întârzierilor imprevizibile sau a comportamentului neașteptat în fluxurile de lucru cu agenți multi-pași și apeluri de instrumente?

groundcover adoptă o abordare proiectată pentru sistemele moderne de inteligență artificială. Utilizăm un senzor bazat pe eBPF la nivel de nucleu pentru a observa traficul între microservicii fără modificări de cod sau redeploiări. Îndată ce introduceți un flux de lucru LLM, putem descoperi automat aceste apeluri. Dacă începeți să utilizați un nou model, cum ar fi Anthropic, OpenAI sau Bedrock, mâine, groundcover capturează automat acel trafic.

Care sunt riscurile de securitate a datelor și conformitate care apar în implementările LLM, și cum poate observabilitatea ajuta la reducerea acestor riscuri?

Implementările LLM aduc câteva riscuri de securitate a datelor unice:

• Intrări de utilizator nelimitate – Utilizatorii pot introduce informații extrem de sensibile în interfețele de tip chatbot și AI. Acest lucru poate include date personale, date ale clienților sau informații reglementate pe care nu le-ați intenționat să le colectați.
• Furnizori de modele terțe – Odată ce trimiteți aceste date către un furnizor LLM extern, sunteți responsabil pentru unde ajung, cum sunt stocate și care subprocessori sunt implicați. Acest lucru are implicații majore pentru GDPR, rezidența datelor și încrederea clienților.
• Telemetria ca a doua copie a datelor sensibile – Dacă stiva dvs. de observabilitate trimite încărcături complete către un furnizor SaaS, aveți acum o altă copie a acelor informații sensibile stocate în afara mediului dvs.

Arhitectura groundcover este proiectată pentru a aborda exact aceste preocupări:

• Utilizăm un model “aduceți-vă propriul cloud”, în care întreaga parte din spate a observabilității rulează în contul dvs. de cloud, într-un subcont, ca o parte de date complet gestionată. Partea de control care o scalează și o gestionează este operată de noi, dar nu avem acces, nu stocăm și nu prelucrăm datele dvs. de telemetrie.
• Deoarece putem captura în siguranță încărcăturile în mediul dvs., puteți observa prompturi, răspunsuri și fluxuri de lucru fără ca aceste date să părăsească vreodată cloud-ul dvs. Nu există stocare de către terți a urmelor LLM și nu există egress de date suplimentar de îngrijorat.
• Cu această vizibilitate, puteți vedea cine încarcă ce și unde curge, detectați utilizarea neașteptată a datelor sensibile și impuneți politici cu privire la care modele și regiuni sunt permise.

În alte cuvinte, observabilitatea devine nu numai un instrument de fiabilitate și cost, ci și un punct de control cheie pentru confidențialitate, rezidența datelor și conformitate.

Pe măsură ce organizațiile trec de la o singură integrare LLM la multiple servicii conduse de inteligență artificială, care provocări operaționale tind să apară în jurul vizibilității, fiabilității și costului?

Prima integrare este de obicei un singur model într-un singur flux de lucru. La acest stadiu, lucrurile par gestionabile. Însă, de îndată ce echipele văd valoarea, utilizarea explodează și apar câteva provocări:

• Extinderea modelului și a furnizorului – Echipele testează noi modele în mod constant. Curând, devine neclar care dintre ele sunt în producție și cum sunt utilizate.
• Surprize de cost din cauza utilizării tokenului – Consumul de tokenuri crește odată cu lungimea contextului și complexitatea fluxului de lucru. Fără vizibilitate asupra utilizării tokenurilor pe model și flux de lucru, gestionarea costurilor este foarte dificilă.
• Dependențe de fiabilitate față de furnizorii externi – API-urile cu față către utilizator devin sensibile la întârzierea modelului sau la erori, care pot perturba SLA-urile chiar și atunci când infrastructura de bază este sănătoasă.
• Cresc datoriile de instrumentare – Observabilitatea tradițională presupune că puteți adăuga instrumentare atunci când este nevoie. În stivele de inteligență artificială în mișcare rapidă, dezvoltatorii rareori au timp pentru asta.

groundcover abordează acestea prin:

• Vizibilitate centralizată asupra modelelor și furnizorilor utilizați.
• Panouri de bord care arată întârzierea, debitul și utilizarea tokenului în timp.
• Corelarea între comportamentul LLM și serviciile care depind de el.
• Alerte pentru încălcarea SLO-urilor conduse de inteligență artificială.

Acest lucru face mult mai ușor să treceți de la “o funcție de inteligență artificială cool” la “inteligența artificială este împletită în zeci de servicii critice” fără a pierde controlul.

Privind înainte, cum anticipați că observabilitatea LLM va evolua în următorii cinci ani, pe măsură ce inteligența artificială agențială, orchestrarea multi-model și presiunile reglementare se accelerează?

Suntem încă în zilele timpurii. În următorii cinci ani, aștept câteva schimbări majore:

• De la nivelul de cerere la nivelul de agent – Observabilitatea se va extinde pentru a captura secvențe de instrumente, căi de raționament și logică de reluare, nu doar apeluri de modele.
• Semnale semantice și de politică mai bogate – Verificări automate de calitate pentru halucinații, probleme de siguranță și aliniere cu marca vor deveni metrice standard.
• Legături mai strânse cu guvernanța și confidențialitatea – Pe măsură ce reglementarea crește, observabilitatea va servi și ca strat de aplicare și audit pentru rezidența datelor, retenția și utilizarea modelului aprobat.
• Optimizarea multi-model și multi-furnizor – Echipele vor ruta traficul dinamic între modele pe baza performanței și costului, ghidate de datele de observabilitate în timp real.
• Less instrumentare manuală – Tehnici precum colectarea bazată pe eBPF și descoperirea automată vor deveni implicit, astfel încât echipele să poată inova fără a se încetini.

În scurt, observabilitatea LLM va evolua de la “bun de avut tablouri de bord pentru inteligență artificială” în sistemul nervos central care leagă fiabilitatea, controlul costului, guvernanța datelor și calitatea produsului în tot ceea ce face o organizație cu inteligența artificială.

Mulțumim pentru acest interviu minunat, cititorilor care doresc să afle mai multe, ar trebui să viziteze groundcover.