Moshe Sambol, VP de Soluții pentru Clienți la Lightrun – Seria de Interviuri

Moshe Sambol, VP de Soluții pentru Clienți la Lightrun, aduce peste două decenii de experiență în domeniul ingineriei software, arhitectură, infrastructură cloud și conducere tehnică pentru clienți. Înainte de a se alătura Lightrun în 2022, el a petrecut aproape un deceniu la Google, unde a ocupat mai multe poziții de conducere, inclusiv manager de inginerie pentru clienți Cloud, ajutând organizațiile să adopte și să scaleze tehnologiile Google Cloud. La începutul carierei sale, Sambol a ocupat roluri de inginerie și conducere de dezvoltare la Oracle, Sun Microsystems, BMC Software și JPMorgan Chase. La Lightrun, el a condus inițial echipa de inginerie de soluții globale, devenind apoi VP de Soluții pentru Clienți, unde se concentrează pe ajutarea clienților să adopte tehnologia Runtime Insights a companiei și să traducă capacitățile sale în câștiguri măsurabile de productivitate pentru afaceri și dezvoltatori.

Lightrun este o platformă de inginerie bazată pe inteligență artificială, proiectată pentru a oferi dezvoltatorilor și agenților de inteligență artificială o vizibilitate directă asupra modului în care se comportă software-ul în timpul rulării. Tehnologia sa poate captura dinamic jurnale, instantanee, metrice, urme, valori de variabile și context de execuție din aplicații live, fără a necesita modificări de cod sau redeployări. Compania extinde în mod din ce în ce mai mult această inteligență de rulare către dezvoltarea asistată de inteligență artificială prin Lightrun MCP, care utilizează Protocolul de Context al Modelului pentru a furniza asistenți de codare și unelte agenților cu context de aplicație live, în loc de a se baza exclusiv pe codul sursă static. Acest lucru permite sistemelor de inteligență artificială să investigheze probleme de producție, să valideze ipoteze împotriva comportamentului real de execuție și să sprijine analiza cauzelor profunde, integrând controale de întreprindere, cum ar fi controlul accesului bazat pe rol și redactarea datelor sensibile.

Care a fost impactul combinației dvs. de experiență în dezvoltarea software, arhitectură, inginerie pentru clienți cloud la Google și soluții pentru clienți la Lightrun asupra înțelegerii dvs. despre ceea ce separă o demonstrație impresionantă a unui agent de inteligență artificială de un sistem care poate fi încredințat în producție?

Există o mare diferență între a arăta ce poate face un agent de inteligență artificială și a dovedi că poate fi încredințat într-un mediu de întreprindere. Acest lucru se datorează faptului că agenții sunt doar o parte a unui sistem gata de producție. Cadrul din jurul său este la fel de important. Trebuie să impună un acces cu privilegii minime, să monitorizeze activitatea, să păstreze un traseu de audit, să prevină acțiuni inacceptabil de riscante și să aducă un om atunci când este necesar.

Sistemele agenților sunt în mod inerent diferite de software-ul tradițional, deoarece dezvoltatorii nu prescriu exact cum va funcționa sistemul. Stabilim un obiectiv, oferim unelte și îndrumare, iar modelul determină cum să procedeze. Acea flexibilitate este puternică, dar o face și mai greu de prezis comportamentul sistemului.

Pentru întreprinderi, în special cele din industrii reglementate, fluxurile de lucru de producție care funcționează de obicei sau care necesită un timp imprevizibil pentru a fi finalizate sunt inacceptabile. Mediile de producție conțin date sensibile, cod sursă și proprietate intelectuală, astfel încât organizațiile trebuie să poată preveni agenții să expună aceste informații sau să ia rute creative, dar inacceptabile, pentru a-și atinge obiectivele. Acest lucru devine din ce în ce mai important, deoarece fiecare săptămână aduce un nou exemplu de sistem de inteligență artificială care, în încercarea de a atinge un obiectiv, ajunge vulnerabil la sau provoacă o exploatare de securitate.

Majoritatea liderilor cu care vorbesc încă evaluează agenții în același mod în care ar evalua un nou angajat: pe baza capacităților, judecății și rezultatelor. Adevărata întrebare nu este dacă agentul este suficient de inteligent. Este dacă sistemul din jurul său poate prinde și conține momentele în care nu este.

Mulți antreprenori au crezut inițial că construirea unui agent de inteligență artificială era în mare măsură o chestiune de scriere a unei solicitări eficiente. Ce au înțeles greșit organizațiile despre cerințele de inginerie, arhitectură și operaționale din spatele agenților gata de producție?

Cred că cea mai mare înțelegere greșită a fost o credință aproape naivă în puterea inteligenței artificiale de a rezolva orice provocare, odată ce i s-a dat o solicitare bine scrisă, un context relevant și unelte potrivite. Echipele au conectat LLM-ul lor la cod, documentație, bilete și telemetrie istorică și apoi au așteptat ca acesta să găsească în mod corect drumul către decizia corectă.

Ce nu au construit a fost un model de verificare pentru fiecare etapă a raționamentului inteligenței artificiale. Una dintre marile puteri ale inteligenței artificiale este aceea că utilizează raționamentul probabilistic, găsind și urmând una dintre multiplele căi posibile pentru a ajunge la o destinație. În medii de producție complexe și interconectate, acea putere introduce un risc grav: o singură decizie poate declanșa regresii în aval, eșecuri silențioase sau alte comportamente neașteptate care amenință reziliența operațională a unui sistem în funcțiune.

Acesta este locul în care direcționarea deterministă devine esențială. Raționamentul agentului poate rămâne probabilistic, dar punctele de control din jurul acțiunilor sale nu pot. Pentru un agent care participă la un flux de lucru de inginerie, acest lucru necesită o etapă de verificare care verifică ipoteza sa următoare împotriva realității de producție, o poartă deterministă și nu o altă ghicire probabilistică. Trebuie să vadă ce va fi consecința acelei decizii și să o aprobe doar atunci când a determinat că acțiunea este sigură.

Privind peste prima undă de agenți dezvoltați intern, care sunt cele mai comune greșeli arhitecturale pe care le observați și care pot fi corectate treptat, în loc de a necesita o reconstruire completă?

Problema de bază la care revin în mod constant este validarea. Agenții pot deveni o cutie neagră: ei colectează informații dintr-o varietate de surse și apoi iau decizii care par rezonabile în principiu, dar care nu pot fi potrivite pentru realitățile unui mediu de producție complex și murdar.

Acest lucru indică o schimbare fundamentală și este ceva despre care discutăm constant la Lightrun, pe măsură ce ajutăm clienții să construiască automatizări agenților pentru organizațiile lor de inginerie. Echipele trebuie să reconstruiască fluxul agenților în sine și să pună porți pe acțiunile agentului, pentru a se asigura că utilizarea uneltelor sale este supusă supravegherii, auditului și revizuirii. Furnizarea agentului cu o buclă de feedback puternică – inclusiv observabilitate de rulare în timp real – îi concentrează contextul asupra a ceea ce se întâmplă cu adevărat în acest moment. Acest acces este ceea ce îi permite agentului să valideze propriile decizii de proiectare, analiza cauzelor profunde și recomandările de mitigare a erorilor împotriva realității de producție, în loc de a se baza pe ipoteze bazate pe analiza statică a codului sau pe telemetrie veche.

O reconstruire dramatică nu este singura opțiune. Ce poate fi făcut treptat, și acest lucru nu este revoluționar, dar este esențial, este investiția în abilitățile care ghidă comportamentul agentului. Abilități atent create și evaluate pot împinge agentul în direcția unui flux de lucru determinist. Echipele nu au nevoie să re-arhitecteze întregul sistem pentru a obține acest beneficiu. Trebuie doar să trateze proiectarea abilităților cu același rigor pe care l-ar acorda oricărei alte logici de producție.

De ce unii agenți funcționează bine în timpul testelor controlate, dar încep să producă rezultate inconstante, incomplete sau înșelătoare atunci când sunt expuși unor utilizatori reali, date în schimbare, unelte externe și medii de producție complexe?

Testele controlate elimină cea mai mare parte a variabilității care va defini realitatea de producție cu care inteligența artificială trebuie să se confrunte. Datele sunt curate, comportamentul uneltei este previzibil, permisiunile sunt cunoscute și acoperim un drum pe care l-am anticipat. Când lansați un agent pentru a interacționa cu utilizatori reali și efectele lor asupra sistemelor live, nu comparați lucruri similare.

Utilizatorii introduc solicitări ambigue și rulează acțiuni concurente, starea sistemului este în flux constant, agentul trebuie adesea să lucreze cu date parțiale, iar uneltele externe aduc propriile lor moduri de întârziere și eșec, pe lângă aceasta. Deoarece modelul este probabilistic, fiecare nouă variabilă creează un alt loc în care fluxul de lucru poate diverge sau compune o greșeală anterioară.

Partea periculoasă este că agentul poate continua să pară a funcționa corect, în timp ce produce răspunsuri incorecte, dar plauzibile, construite pe baza datelor parțiale sau a ipotezelor înrădăcinate în informații învechite. Acesta este motivul pentru care agenții de producție necesită o evaluare continuă care rulează în continuare după lansare, o manipulare explicită a datelor lipsă și a eșecurilor uneltelor, precum și o verificare live a unei decizii înainte de a finaliza o acțiune cu impact ridicat.

Lightrun pune un accent semnificativ pe oferirea sistemelor de inteligență artificială acces la context de rulare. Ce informații oferă contextul de rulare care pot fi omise de jurnalele, metricele și urmele convenționale și de ce aceste informații sunt deosebit de importante pentru diagnosticarea eșecurilor agenților?

Observabilitatea convențională arată simptomele externe ale comportamentului sistemului, adesea agregate, eșantionate sau filtrate prin tablouri de bord și alerte care declanșează praguri. Acestea sunt de obicei dependente de deciziile luate de dezvoltatori la momentul scrierii codului: ce informații vor fi de interes în viitor? Ce este demn de a fi înregistrat sau măsurat? Contextul de rulare decuplează vizibilitatea de nevoia de a ști în avans ce ar putea fi de interes și oferă date granulare care arată ce se întâmplă sub capotă și cum am ajuns acolo.

Adevărata lacună este datele statice versus datele dinamice. Jurnalele, metricele și urmele convenționale sunt statice și produc un raport istoric al ceea ce s-a întâmplat. Contextul de rulare al Lightrun este dinamic. Acesta oferă agentului capacitatea de a plasa noi instrumentări în codul în funcțiune, la cerere, și de a observa valorile exacte ale variabilelor, argumentele funcțiilor, starea obiectului, stiva de apel sau condițiile de ramificare, așa cum apar.

Această distincție este deosebit de importantă pentru diagnosticarea eșecurilor în codul generat de agenți, deoarece acestea sunt adesea silențioase. Un agent poate alege uneltele greșite, poate trece argumente greșite sau poate acționa pe baza unei ipoteze învechite și totuși poate finaliza sarcina sa fără a declanșa nicio eroare. Un eșec de acest fel nu va apărea în telemetria statică, deoarece nimeni nu știa dinainte să instrumenteze pentru el. Comportamentul neașteptat necesită o investigație dinamică direct pe sistemul în funcțiune, plasând noi instrumentări exact acolo unde modelul agentului de lume s-a abătut de la realitate, în loc de a se baza pe ceea ce era deja înregistrat.

Acesta este ceea ce face contextul de rulare dinamic stratul natural de verificare pentru deciziile generate de inteligența artificială în inginerie.

Cum pot Protocolul de Context al Modelului (MCP) și straturile de integrare similare să permită agenților de codare să învețe din comportamentul real de execuție fără a le oferi acces excesiv sau nesigur la sistemele de producție?

MCP și accesul controlat la unelte externe (de exemplu, învelișuri CLI) permit unui agent să apeleze o capacitate specifică, cu scop limitat, în loc de a avea acces larg la un sistem și de a fi încredințat să se comporte. Un agent conectat printr-un server MCP pentru context de rulare poate solicita dovezi doar pentru citire, valoarea unei variabile, un drum de apel, dacă un prag a fost depășit, fără a atinge accesul de scriere, fără a necesita credențiale permanente pentru mediul de bază și fără a necesita redeployarea.

Când redesenați o generație inițială de agenți, cum ar trebui întreprinderile să abordeze permisiunile de unelte, memoria, recuperarea datelor, evaluarea, supravegherea umană și procedurile de recuperare ca părți ale unei arhitecturi coerente, în loc de caracteristici separate?

Nu puteți conecta aceste piese independent, deoarece fiecare dintre ele modifică celelalte. Cele mai bune locuri pentru a începe sunt cadrul, harnașa care controlează bucla agentului și orchestrarea generală a fluxului de lucru, care leagă împreună mai mulți agenți și alți actori. Pentru un flux de lucru de analiză a cauzelor profunde, de exemplu, echipele ar trebui să decidă ce dovezi sunt necesare, care sisteme poate inspecta agentul, dacă poate publica o concluzie sau doar să o proiecteze, când trebuie să aprobe următorul pas un om și ce se întâmplă dacă dovezi de rulare nu sunt disponibile.

Odată ce contractul este clar, harnașa și cadrul oferă mecanismele cu care să impună aceste linii directoare. Porțile MCP pot fi utilizate pentru a limita accesul agentului la capacități specifice relevante pentru scopul său. Uneltele pot fi acordate cu privilegii minime. Memoria poate fi supravegheată, cu date sensibile redactate în mod determinist. Recuperarea poate fi proiectată în jurul dovezilor de care are nevoie fluxul de lucru.

Evaluarea, supravegherea și procedurile de recuperare închid apoi bucla. Sistemul ar trebui să măsoare dacă concluziile sunt corecte și susținute, să aducă un om atunci când riscul sau incertitudinea depășește un prag definit și să se oprească sau să se retragă la o recomandare doar pentru citire atunci când nu poate strânge suficiente dovezi. Un registru de audit comun ar trebui să lege declanșatorul, permisiunile, dovezile, apelurile uneltelor, aprobările, acțiunea și rezultatul. Acesta este ceea ce face aceste componente o arhitectură de producție, în loc de șase caracteristici separate.

Care ar trebui să fie măsurile de siguranță care înconjoară agenții care pot inspecta aplicații live sau pot participa la fluxurile de lucru de inginerie a fiabilității site-ului, în special în medii reglementate în care controlul accesului, confidențialitatea, auditabilitatea și stabilitatea operațională sunt critice?

Acesta a fost unul dintre principalele întrebări de proiectare atunci când am construit Lightrun AI SRE. Un AI SRE funcționează aproape de unele dintre cele mai sensibile sisteme ale unei organizații, astfel că l-am proiectat ca un actor operațional privilegiat, nu ca un asistent de chat. O decizie importantă a fost separarea planului de inspecție de planul de acțiune. AI SRE strânge dovezi prin integrări doar pentru citire și instrumentări de rulare sandboxate ale Lightrun, cu acces restricționat de identitate, chiriaș, serviciu și mediu. Poate inspecta execuția live și genera dovezi lipsă, dar stratul de inspecție de rulare nu poate modifica starea aplicației.

Într-un mediu reglementat, acea limită trebuie să fie susținută de controlul accesului bazat pe rol, autentificare unică, izolare de chiriași, redactare a informațiilor cu caracter personal, controale de reținere și un traseu de audit care arată care unelte și dovezi au susținut fiecare concluzie. De asemenea, avem nevoie de limite operaționale cu privire la cât de multe date pot fi colectate, cu ce frecvență poate fi interrogat rularea și care acțiuni necesită aprobare. Dacă dovezile lipsesc sau o concluzie nu poate fi verificată, AI SRE ar trebui să spună asta și să transmită decizia unui om, în loc să acționeze ca și cum ar ști mai mult decât știe. Scopul este autonomia controlată: suficient de utilă pentru a accelera o investigație, dar suficient de constrânsă pentru a rămâne în siguranță pentru sistemul live.

Pe măsură ce întreprinderile trec de la agenții experimentali, care ar trebui să fie măsurătorile care să determine dacă un agent este cu adevărat gata de producție și cum anticipați că relația dintre agenții de inteligență artificială și inginerii umani va evolua în următorii ani?

Aș judeca pregătirea pentru producție prin frecvența cu care acțiunile unui agent de inteligență artificială produc rezultatele dorite, concluziile sale rezistă împotriva a ceea ce era cu adevărat adevărat în producție, concluziile nevalidate sunt prinse înainte de acțiune și dacă eșuează în mod vizibil și sigur atunci când dovezile lipsesc. Pentru agenții de inginerie, acuratețea rezultatului verificat, acoperirea dovezilor, timpul necesar pentru a confirma cauza profundă, rata de recuperare cu succes și rezultatele post-acțiune sunt metricile de bază pe care ar trebui să le urmărim.

În următorii ani, anticipez că agenții vor prelua mai multă colectare de dovezi și investigații inițiale, precum și supravegherea fluxurilor de lucru agenților și învățarea continuă din experiență și feedback, în timp ce inginerii vor stabili politici, vor rezolva ambiguitățile, vor aproba acțiuni cu risc ridicat și vor direcționa sistemele agenților care se auto-îmbunătățesc. Încrederea se va extinde flux de lucru cu flux de lucru. Agenții care pot urmări concluziile lor înapoi la dovezi live și pot divulga în mod clar ceea ce nu au putut verifica vor câștiga o autonomie mai mare. Cei care nu pot nu vor rămâne limitați la sarcini înguste, cu risc scăzut, indiferent de cât de fluent sună.

Mulțumim pentru acest interviu minunat, cititorilor care doresc să afle mai multe despre Lightrun.