Mosze Sambol, VP ds. Rozwiązań dla Klientów w Lightrun – Seria Wywiadów

Mosze Sambol, VP ds. Rozwiązań dla Klientów w Lightrun, posiada ponad dwie dekady doświadczenia w zakresie inżynierii oprogramowania, architektury, infrastruktury chmury i technicznych stanowisk kierowniczych. Przed dołączeniem do Lightrun w 2022 roku, spędził blisko dekadę w Google, gdzie zajmował się kilkoma stanowiskami kierowniczymi, w tym menedżerem inżynierii klienta chmury, pomagając organizacjom w przyjęciu i skalowaniu technologii Google Cloud. Wcześniej w swojej karierze, Sambol zajmował stanowiska inżynierskie i kierownicze w firmach Oracle, Sun Microsystems, BMC Software i JPMorgan Chase. W Lightrun, początkowo kierował globalnymi rozwiązaniami inżynierskimi, a następnie został VP ds. Rozwiązań dla Klientów, gdzie koncentruje się na pomocy klientom w przyjęciu technologii Runtime Insights i tłumaczeniu jej możliwości w wymierne korzyści biznesowe i produktywnościowe.

Lightrun to platforma inżynierskiej niezawodności oparta na sztucznej inteligencji, zaprojektowana w celu zapewnienia deweloperom i agentom sztucznej inteligencji bezpośredniej widoczności w zakresie zachowania oprogramowania podczas jego działania. Jej technologia może dynamicznie przechwytywać dzienniki, migawki, dane pomiarowe, ślady, wartości zmiennych i kontekst wykonania z aplikacji na żywo bez wymogu zmian w kodzie lub ponownych wdrożeń. Firma stopniowo rozszerza tę inteligencję czasu wykonywania na rozwój oprogramowania wspomaganego przez sztuczną inteligencję za pośrednictwem Lightrun MCP, który wykorzystuje Model Context Protocol, aby zapewnić asystentom kodowania i narzędziom agentywnym kontekst aplikacji na żywo, a nie tylko kod statyczny. Umożliwia to systemom sztucznej inteligencji badanie problemów produkcyjnych, weryfikację hipotez w odniesieniu do rzeczywistego zachowania wykonywania i wspieranie analizy przyczynowo-skutkowej, jednocześnie uwzględniając kontrolę enterprise, taką jak dostęp oparty na rolach i redakcja danych wrażliwych.

Twoja kariera obejmuje rozwój oprogramowania i architekturę, inżynierię klienta chmury w Google, globalne rozwiązania inżynierskie i obecnie rozwiązania dla klientów w Lightrun. Jak ta kombinacja budowania oprogramowania i pracy bezpośrednio z klientami enterprise ukształtowała twoje zrozumienie tego, co odróżnia imponującą demonstrację agenta sztucznej inteligencji od systemu, który może być zaufany w produkcji?

Istnieje duża różnica między pokazaniem, co może zrobić agent sztucznej inteligencji, a udowodnieniem, że może być zaufany w środowisku enterprise. Wynika to z faktu, że agenci są tylko częścią systemu gotowego do produkcji. Ramy wokół niego są równie ważne. Muszą one egzekwować dostęp z najniższymi uprawnieniami, monitorować aktywność, zachowywać ślad audytowy, zapobiegać nieakceptowalnym ryzykownym działaniom i wzywać człowieka, gdy jest to konieczne.

Systemy agentywności różnią się od tradycyjnego oprogramowania, ponieważ deweloperzy nie określają dokładnie, jak system będzie działał. Ustawiamy cel, zapewniamy narzędzia i wskazówki, a model decyduje, jak postąpić. Ta elastyczność jest potężna, ale również sprawia, że zachowanie systemu jest trudniejsze do przewidzenia.

Dla przedsiębiorstw, zwłaszcza tych w branżach regulowanych, przepływy pracy produkcyjnej, które zwykle działają lub zajmują nieprzewidywalną ilość czasu, są niedopuszczalne. Środowiska produkcyjne zawierają dane wrażliwe, kod źródłowy i własność intelektualną, więc organizacje muszą być w stanie uniemożliwić agentom ujawnienie tych informacji lub podjęcie kreatywnych, ale nieakceptowalnych działań w celu osiągnięcia swoich celów. Staje się to coraz bardziej istotne, ponieważ każdy tydzień przynosi nowy przykład systemu sztucznej inteligencji, który, w swoim dążeniu do osiągnięcia celu, staje się podatny na lub powoduje eksploitację bezpieczeństwa.

Większość liderów, z którymi rozmawiam, nadal ocenia agenci w sposób, w jaki oceniliby nowego pracownika: pod kątem zdolności, osądu i wyników. Prawdziwe pytanie nie brzmi, czy agent jest wystarczająco inteligentny. Chodzi o to, czy system wokół niego może przechwytywać i ograniczać momenty, w których nie jest.

Wiele przedsiębiorstw początkowo uważało, że budowanie agenta sztucznej inteligencji było w dużej mierze kwestią napisania skutecznej wskazówki. Co organizacje nie zrozumiały w zakresie wymagań inżynierskich, architektonicznych i operacyjnych dotyczących agentów gotowych do produkcji?

Uważam, że największe nieporozumienie polegało na niemal naiwnym przekonaniu o mocy sztucznej inteligencji do rozwiązania każdego wyzwania, o ile tylko podano dobrze napisaną wskazówkę, odpowiedni kontekst i odpowiednie narzędzia. Zespoły połączyły swoje LLM z kodem, dokumentacją, biletami i historycznymi danymi telemetrycznymi, a następnie oczekiwały, że będzie ono w sposób prawidłowy dochodzić do słusznych wniosków.

Nie zbudowali jednak modelu weryfikacji dla każdego kroku rozumowania sztucznej inteligencji. Jedną z wielkich zalet sztucznej inteligencji jest to, że używa rozumowania probabilistycznego, znajdując i podejmując jedną z wielu możliwych dróg do celu. W złożonych, połączonych środowiskach produkcyjnych ta sama siła wprowadza poważne ryzyko: pojedyncza decyzja może wywołać zależne regresje, ciche awarie lub inne nieoczekiwane zachowania, które zagrażają operacyjnej wytrzymałości działającego systemu.

To, gdzie staje się niezwykle ważna deterministyczna kierowca. Rozumowanie agenta może pozostać probabilistyczne, ale punkty kontrolne wokół jego działań nie mogą. Dla agenta biorącego udział w przepływie pracy inżynierskiej wymaga to kroku weryfikacji, który sprawdza jego hipotetyczne następne działanie w odniesieniu do rzeczywistości produkcyjnej, bramki deterministycznej, a nie kolejnej probabilistycznej próby. Musi on zobaczyć, jaki będzie skutek tej decyzji, i zatwierdzić ją tylko wtedy, gdy stwierdzi, że działanie jest bezpieczne.

Patrząc na pierwszą falę wewnętrznie opracowanych agentów enterprise, jakie są najczęstsze błędy architektoniczne, które widzisz, a które problemy mogą być poprawione stopniowo, a nie wymagają całkowitej przebudowy?

Podstawową sprawą, do której nieustannie wracam, jest walidacja. Agenci mogą stać się czarną skrzynką: zbierają informacje z różnych źródeł, a następnie podejmują decyzje, które wydają się rozsądne w teorii, ale mogą nie być odpowiednie dla realiów złożonego środowiska produkcyjnego.

Wskazuje to na bardziej fundamentalną zmianę, a jest to coś, o czym stale rozmawiamy w Lightrun, gdy pomagamy klientom budować agentywną automatyzację dla ich organizacji inżynierskich. Zespoły muszą odbudować sam przepływ agentywności i umieścić bramki na działaniach agenta, aby upewnić się, że jego użycie narzędzi podlega nadzorowi, audytowi i przeglądowi. Zapewnienie agentowi silnej pętli sprzężenia zwrotnego – w tym obserwowalności czasu wykonywania – koncentruje jego kontekst na tym, co się naprawdę dzieje. To pozwala agentowi na weryfikację własnych decyzji projektowych, analizy przyczynowo-skutkowej i zaleceń dotyczących ograniczania błędów w odniesieniu do rzeczywistości produkcyjnej, a nie w oparciu o założenia oparte na statycznej analizie kodu lub starych danych telemetrycznych.

Całkowita przebudowa nie jest jedynym rozwiązaniem. To, co można zrobić stopniowo, a jest to nie rewolucyjne, ale istotne, to inwestowanie w umiejętności, które kierują zachowaniem agenta. Starannie opracowane i ocenione umiejętności nakierowują agenta w kierunku deterministycznego przepływu pracy. Zespoły nie muszą przebudowywać całego systemu, aby uzyskać tę korzyść. Muszą traktować projektowanie umiejętności z takim samym rygorem, jaki dają każdej innej logice produkcyjnej.

Dlaczego niektórzy agenci działają dobrze podczas kontrolowanych testów, ale zaczynają produkować niekonsekwentne, niekompletne lub mylące wyniki, gdy są narażeni na prawdziwych użytkowników, zmieniające się dane, zewnętrzne narzędzia i złożone środowiska produkcyjne?

Kontrolowane testy usuwają większość zmienności, która będzie definiowała rzeczywistość produkcyjną, z którą sztuczna inteligencja musi się zmierzyć. Dane są opracowane, zachowanie narzędzi jest przewidywalne, uprawnienia są znane, a my pokrywamy ścieżkę, którą przewidzieliśmy. Gdy wydajesz agenta do interakcji z prawdziwymi użytkownikami i ich efektami w systemach na żywo, nie porównujesz podobne z podobnym.

Użytkownicy wprowadzają niejednoznaczne żądania i uruchamiają współbieżne działania, stan systemu jest w ciągłym przepływie, agent często musi pracować na podstawie niepełnych danych, a zewnętrzne narzędzia wprowadzają swoje własne opóźnienia i tryby awaryjne. Ponieważ model jest probabilistyczny, każda nowa zmienna tworzy kolejne miejsce, w którym przepływ pracy może rozbiec się lub skumulować wcześniejszy błąd.

Niebezpieczną częścią jest to, że agent może nadal wydawać się działać poprawnie, produkując niepoprawne, ale prawdopodobne odpowiedzi, oparte na niepełnych danych lub założeniach opartych na starych informacjach. Dlatego agenci produkcyjni potrzebują ciągłej oceny, która nadal działa po uruchomieniu, jawnej obsługi brakujących danych i awarii narzędzi, oraz weryfikacji na żywo decyzji przed podjęciem działania o wysokim wpływie.

Lightrun kładzie duży nacisk na zapewnienie systemom sztucznej inteligencji dostępu do kontekstu czasu wykonywania. Jakie informacje zapewnia kontekst czasu wykonywania, których mogą nie uwzględniać konwencjonalne dzienniki, dane pomiarowe i ślady, i dlaczego informacje te są szczególnie ważne dla diagnozowania awarii agentów?

Konwencjonalna obserwowalność pokazuje zewnętrzne objawy zachowania systemu, często agregowane, pobierane próbkowo lub filtrowane za pomocą pulpitów i alertów, które wyzwalają na progach. Zazwyczaj zależą one od decyzji podejmowanych przez deweloperów w momencie, gdy kod został napisany: co będzie interesujące w przyszłości? Co warto logować lub mierzyć? Kontekst czasu wykonywania odłącza widoczność od tej potrzeby wiedzy na temat tego, co może być interesujące, i zapewnia szczegółowe dane pokazujące, co się dzieje pod maską, i jak się tam znalazło.

Rzeczywista luka polega na danych statycznych i dynamicznych. Konwencjonalne dzienniki, dane pomiarowe i ślady są statyczne i produkują historyczne konto tego, co się wydarzyło. Kontekst czasu wykonywania Lightrun jest dynamiczny. Daje agentowi możliwość umieszczenia nowej instrumentacji w działającym kodzie, na żądanie, i obserwowania dokładnych wartości zmiennych, argumentów funkcji, stanu obiektu, stosu wywołań lub warunków gałęzi, tak jak się one zachowują.

Ta różnica jest szczególnie ważna dla diagnozowania awarii w kodzie wygenerowanym przez agenta, ponieważ awarie te są często ciche. Agent może wybrać niewłaściwe narzędzie, przekazać niewłaściwy argument lub działać na podstawie starych założeń, a nadal zakończyć swoje zadanie bez wywołania żadnego błędu. Awaria taka nie pojawi się w statycznej telemetrii, ponieważ nikt nie wiedział z wyprzedzeniem, aby zainstrumentować ją.

To, co czyni dynamiczny kontekst czasu wykonywania naturalną warstwą weryfikacji dla decyzji generowanych przez sztuczną inteligencję w inżynierii.

Jak Model Context Protocol (MCP) i podobne warstwy integracyjne mogą pozwolić agentom kodowania nauczyć się od rzeczywistego zachowania wykonywania bez nadania im nadmiernego lub niebezpiecznego dostępu do systemów produkcyjnych?

MCP i inne kontrolowane dostępy do zewnętrznych narzędzi (np. otoczki CLI) pozwalają agentowi wywołać określoną, zakresową możliwość, a nie przyznać mu szeroki dostęp do systemu i zaufać, że się zachowa. Agent połączony za pomocą serwera MCP do kontekstu czasu wykonywania może zażądać tylko do odczytu dowodów, wartości zmiennej, ścieżki wywołania, czy przekroczono próg, bez dotyku dostępu do zapisu, bez możliwości ponownego wdrożenia i bez potrzeby stałych poświadczeń do podstawowego środowiska.

Gdy przebudowujesz pierwszą generację agenta, jak przedsiębiorstwa powinny podejść do uprawnień narzędzi, pamięci, pobierania danych, oceny, nadzoru ludzkiego i procedur awaryjnych jako części spójnej architektury, a nie oddzielnych funkcji?

Nie możesz zamontować tych części niezależnie, ponieważ każda z nich zmienia inne. Najlepsze miejsca do rozpoczęcia to ramy, obejmująca pętlę agenta, oraz ogólna orkiestracja przepływu pracy, która łączy kilku agentów i innych aktorów. Dla przykładu przepływu pracy analizy przyczynowej, zespoły powinny zdecydować, jakie dowody są wymagane, które systemy agent może sprawdzić, czy może opublikować wniosek, czy tylko wykonać projekt, kiedy człowiek musi zatwierdzić następny krok, i co się stanie, jeśli dowody z czasu wykonywania są niedostępne.

Gdy ta umowa jest już jasna, ramy i obejmująca zapewniają mechanizmy, za pomocą których można egzekwować te wytyczne. Bramki MCP mogą być wykorzystywane do ograniczenia dostępu agenta do określonych możliwości istotnych dla jego celu. Narzędzia mogą być przyznane z najniższymi uprawnieniami. Pamięć może być nadzorowana, a dane wrażliwe mogą być redagowane w sposób deterministyczny. Pobieranie może być zaprojektowane wokół dowodów, których potrzebuje przepływ pracy.

Ocena, nadzór i procedury awaryjne zamykają pętlę. System powinien mierzyć, czy wnioski są poprawne i wspierane, wzywać człowieka, gdy ryzyko lub niepewność przekracza określony próg, i zatrzymać się lub wrócić do rekomendacji tylko do odczytu, gdy nie może zgromadzić wystarczających dowodów. Wspólny zapis audytowy powinien połączyć wyzwalacz, uprawnienia, dowody, wywołania narzędzi, zatwierdzenia, działanie i wynik. To, co sprawia, że te składniki są jedną architekturą produkcyjną, a nie sześcioma oddzielnymi funkcjami.

Jakie zabezpieczenia powinny otaczać agenci, które mogą sprawdzić aplikacje na żywo lub uczestniczyć w przepływach inżynierii niezawodności witryny, zwłaszcza w środowiskach regulowanych, gdzie kontrola dostępu, prywatność, audytowalność i stabilność operacyjna są kluczowe?

To było jednym z centralnych pytań projektowych, gdy budowaliśmy Lightrun AI SRE. AI SRE działa w pobliżu niektórych z najbardziej wrażliwych systemów w organizacji, więc zaprojektowaliśmy ją jako uprzywilejowanego aktora operacyjnego, a nie asystenta czatu. Jedną z ważnych decyzji było oddzielenie płaszczyzny inspekcji od płaszczyzny działania. AI SRE gromadzi dowody za pomocą integracji tylko do odczytu i piaskownicowej instrumentacji czasu wykonywania Lightrun, z dostępem ograniczonym przez tożsamość, najemcę, usługę i środowisko. Może on sprawdzić wykonywanie na żywo i wygenerować brakujące dowody, ale warstwa inspekcji czasu wykonywania nie może modyfikować stanu aplikacji.

W środowisku regulowanym, ta granica musi być wspierana przez RBAC, SSO, izolację najemców, redakcję PII, kontrolę przechowywania i ślad audytowy, pokazujący, które narzędzia i dowody wspierały każdy wniosek. Potrzebujemy również ograniczeń operacyjnych dotyczących ilości danych, które mogą być pobrane, jak często można zapytać o czas wykonywania, i które działania wymagają zatwierdzenia. Jeśli dowody są niedostępne lub wniosek nie może być zweryfikowany, AI SRE powinien to powiedzieć i przekazać decyzję człowiekowi, zamiast działać, jakby wiedział więcej, niż wie. Celem jest kontrolowana autonomia: wystarczająco przydatna, aby przyspieszyć dochodzenie, ale wystarczająco ograniczona, aby pozostać bezpieczna dla systemu na żywo.

Jak przedsiębiorstwa przechodzą od eksperymentalnych agentów, jakie mierniki powinny określać, czy agent jest naprawdę gotowy do produkcji, i jak oczekujesz, że relacja między agentami sztucznej inteligencji a inżynierami ludzkimi ewoluuje w ciągu najbliższych kilku lat?

Oceniałbym gotowość do produkcji, patrząc, jak często działania agenta sztucznej inteligencji prowadzą do pożądanych wyników, jego wnioski są poprawne w odniesieniu do tego, co było naprawdę prawdziwe w produkcji, niewsparte wnioski są przechwytywane przed działaniem, i czy zawodzi on widocznie i bezpiecznie, gdy dowody nie są tam. Dla agentów inżynierskich, zweryfikowana dokładność wyników, pokrycie dowodów, czas potwierdzenia przyczyny, pomyślny wskaźnik awaryjny i wyniki po działaniu są kluczowymi miernikami, na które powinniśmy się koncentrować.

W ciągu najbliższych kilku lat oczekuję, że agenci będą brać na siebie więcej zbierania dowodów i pierwszego przejścia dochodzenia, a także nadzorowania agentywnych przepływów pracy i ciągłego uczenia się z doświadczenia i informacji zwrotnej, podczas gdy inżynierowie ustawiają politykę, rozwiązują niejasności, zatwierdzają działania o wysokim ryzyku i kierują samodoskonalającymi się systemami agentywnymi. Zaufanie będzie rosło przepływ pracy po przepływie pracy. Agenci, którzy mogą śledzić swoje wnioski do dowodów na żywo i wyraźnie ujawniać to, co nie mogli zweryfikować, zyskają większą autonomię. Ci, którzy nie mogą, pozostaną ograniczeni do wąskich, niskiego ryzyka zadań, niezależnie od tego, jak płynnie brzmią.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Lightrun.