Shahar Azulay, CEO i współzałożyciel groundcover

Shahar Azulay, CEO i współzałożyciel groundcover to doświadczony lider w dziedzinie badań i rozwoju. Shahar posiada doświadczenie w dziedzinie bezpieczeństwa cybernetycznego i sztucznej inteligencji, pochodzące z pracy w firmach takich jak Apple (AAPL ), DayTwo i Cymotive Technologies. Shahar spędził wiele lat w dziale cyberbezpieczeństwa w biurze premiera Izraela i posiada trzy tytuły licencjata w dziedzinie fizyki, inżynierii elektrycznej i informatyki na Uniwersytecie Technicznym w Izraelu oraz Uniwersytecie w Tel Awiwie. Shahar stara się wykorzystywać wiedzę techniczną z tego bogatego doświadczenia i wprowadzać ją na współczesne pole bitwy w chmurze w najbardziej innowacyjnej formie, aby uczynić świat deweloperów lepszym miejscem.

groundcover to platforma obserwacyjności natywnie chmurowa, zaprojektowana w celu zapewnienia zespołom inżynierskim pełnej, rzeczywistej widoczności ich systemów bez złożoności lub kosztów tradycyjnych narzędzi monitorujących. Zbudowana na technologii eBPF, zbiera i koreluje logi, metryki, ślady i zdarzenia w środowiskach chmurowych i Kubernetes bez zmian w kodzie, umożliwiając szybszą analizę przyczyn i jaśniejszy wgląd w system. Platforma kładzie nacisk na przewidywalne ceny, elastyczną wdrożenie, które utrzymuje dane w chmurze klienta, oraz obserwację od końca do końca, obejmującą infrastrukturę, aplikacje i nowoczesne obciążenia napędzane przez sztuczną inteligencję.

Spójrzmy na Twoją podróż – od kierowania zespołami badań i rozwoju w biurze premiera Izraela do zarządzania inicjatywami związanymi z uczeniem maszynowym w Apple – jakie doświadczenia ostatecznie skłoniły Cię do założenia groundcover, i kiedy po raz pierwszy zauważyłeś lukę w obserwacji systemów sztucznej inteligencji?

Pchnięcie do założenia groundcover pochodziło z mojego czasu w Apple i DayTwo. Nawet z ogromnymi budżetami, byliśmy zmuszeni wybierać pomiędzy płaceniem fortuny za rejestrowanie wszystkiego, a próbkowaniem i leczeniem na ślepo. Wtedy szukaliśmy technologii, która by to rozwiązała. Gdy tylko natknęliśmy się na rozszerzony filtr pakietów Berkeley (eBPF), stało się jasne, że to zmieni wszystko. eBPF pozwala nam zobaczyć wszystko, co dzieje się w jądrze, bez polegania na zmianach w aplikacji. Nie mogłem zrozumieć, dlaczego narzędzia obserwacyjności nie korzystają z tego.

Jak Twoje doświadczenie w dziedzinie bezpieczeństwa cybernetycznego, systemów osadzonych i badań nad sztuczną inteligencją wpłynęło na wizję stojącą za groundcover, i jakie wczesne wyzwania musiałeś pokonać, budując firmę skupioną na obserwacji aplikacji i agenci napędzanych przez sztuczną inteligencję?

Moje doświadczenie w dziedzinie bezpieczeństwa cybernetycznego ukształtowało DNA firmy. W świecie wywiadu zakłada się, że nie kontroluje się aplikacji. To podejście jest powodem, dla którego groundcover nie wymaga instrumentacji. Wiem z doświadczenia, że prośba do deweloperów o modyfikację kodu jest najszybszym sposobem na zablokowanie przyjęcia.

Jak definiujesz obserwację modeli językowych, i co ją różni od tradycyjnego monitorowania lub monitorowania sztucznej inteligencji?

Obserwacja modeli językowych to praktyka instrumentacji i monitorowania systemów produkcyjnych, które wykorzystują duże modele językowe, tak aby można było przechwytywać pełny kontekst każdej inferencji: podpowiedź, kontekst, uzupełnienie, użycie tokenów, opóźnienia, błędy, metadane modelu i idealnie opinie zwrotne lub sygnały jakości.

Jakie wyzwania wprowadzają aplikacje napędzane przez modele językowe, które czynią tradycyjne narzędzia obserwacyjności niewystarczające?

Aplikacje napędzane przez modele językowe wprowadzają kilka wyzwań, które ujawniają ograniczenia tradycyjnych narzędzi:

• Złożone, wieloetapowe przepływy pracy – Przeszliśmy od prostych przepływów “wywołaj model, otrzymaj odpowiedź” do agentów wieloetapowych, potoków wieloetapowych, generacji wzmocnionej odzyskiwaniem i użyciem narzędzi. Cicha awaria w którymkolwiek z tych kroków, takich jak odzyskiwanie, wzbogacanie, osadzanie lub wywołanie modelu, może przerwać całe doświadczenie. Tradycyjne monitorowanie zwykle nie zapewnia pełnego, śladowego widoku tych łańcuchów z podpowiedziami i odpowiedziami włączonymi.
• Szybko ewoluujące stosy sztucznej inteligencji – Zespoły dodają nowe modele, narzędzia i dostawców w tempie, jakiego nigdy wcześniej nie widzieli. W wielu firmach nikt nie może z pewnością wymienić, które modele są w produkcji w danym momencie. Klasyczna obserwację zakłada, że masz czas na instrumentację SDK, wdrożenie i staranne kuratorowanie tego, co mierzy. To po prostu nie nadąża za tempem, w jakim sztuczna inteligencja jest przyjmowana.
• Ekonomika oparta na tokenach i limity – Ceny i limity są powiązane z tokenami i długością kontekstu, które są często kontrolowane przez deweloperów, podpowiedzi lub zachowanie użytkownika, a nie przez centralne operacje. Tradycyjne narzędzia nie są zaprojektowane tak, aby pokazywać “kto spalił ile tokenów na którym modelu, w którym przepływie pracy, z jakim opóźnieniem”.
• Poprawność semantyczna zamiast binarnego powodzenia – Model językowy może zwrócić 200 i nadal hallucynować, oddalić się od Twojej podpowiedzi lub naruszyć politykę. Tradycyjne narzędzia widzą to jako sukces. Potrzebujesz obserwacji, która może ujawnić podpowiedzi i odpowiedzi, oraz dać Ci wystarczający kontekst, aby zbadać zachowanie i, z czasem, włączyć automatyczne kontrole jakości.
• Wrażliwe dane wejściowe płynące do stron trzecich – Modele językowe zapraszają użytkowników do udostępnienia bardzo wrażliwych informacji za pośrednictwem interfejsów w stylu czatu. Teraz jesteś odpowiedzialny za te dane, gdzie są przechowywane i które poddostawcy są zaangażowane. To ma poważne implikacje dla RODO, rezydencji danych i zaufania klienta.

Wszystko to oznacza, że systemy modeli językowych wymagają obserwacji, która jest świadoma sztucznej inteligencji, bogata w kontekst i znacznie mniej zależna od ręcznej instrumentacji niż narzędzia, których używają większość zespołów.

Które sygnały lub wskaźniki są najważniejsze dla zrozumienia wydajności i jakości systemów LLM, w tym opóźnień, zużycia tokenów oraz zachowania podpowiedzi i odpowiedzi?

W praktyce szczególne znaczenie ma kilka kategorii sygnałów:

Opóźnienia i przepustowość

• Całkowite opóźnienie każdego żądania, obejmujące czas pracy modelu i pozostałej części aplikacji.
• Opóźnienia skrajne (P90, P95 i P99) dla poszczególnych modeli i przepływów pracy.
• Przepustowość według modelu, trasy i usługi, aby było wiadomo, dokąd rzeczywiście trafia obciążenie.

Zużycie tokenów i czynniki wpływające na koszty

• Liczba tokenów wejściowych i wyjściowych w każdym żądaniu, z podziałem na modele.
• Łączne zużycie tokenów w czasie według modelu, zespołu, użytkownika i przepływu pracy.
• Rozmiar kontekstu w potokach intensywnie korzystających z wyszukiwania, dzięki czemu można zauważyć nadmierny wzrost podpowiedzi.
• Te dane pozwalają odpowiedzieć na pytanie: „Kto naprawdę wykorzystuje nasz budżet na AI i na co?”.

Zachowanie podpowiedzi i odpowiedzi

• Rzeczywiste treści podpowiedzi i odpowiedzi w reprezentatywnych śladach, wraz z wywołaniami narzędzi i ścieżkami rozumowania.
• Informacje o tym, które narzędzia model wybrał i w jakiej kolejności je wywołał.
• Zmienność odpowiedzi na podobne podpowiedzi, pozwalająca ocenić stabilność zachowania.

Niezawodność i błędy

• Współczynniki i rodzaje błędów dla poszczególnych modeli, w tym błędy dostawcy, przekroczenia czasu, problemy z uwierzytelnianiem i limity.
• Awarie otaczającego przepływu pracy, takie jak przekroczenia czasu narzędzi lub błędy wyszukiwania, skorelowane z wywołaniem LLM.

Klasyczny kontekst infrastruktury

• Wskaźniki procesora, pamięci i sieci kontenerów dla usług koordynujących wywołania LLM.
• Skorelowane dzienniki opisujące czynność, którą aplikacja próbowała wykonać.

Gdy wszystkie te dane są widoczne w jednym miejscu, obserwowalność LLM pozwala przejść od stwierdzenia „wiem, że coś działa wolno lub drogo” do „wiem dokładnie, który model, wzorzec podpowiedzi i usługa za to odpowiadają oraz dlaczego”.

Jak obserwowalność może pomóc zespołom wykrywać ciche awarie, takie jak dryf podpowiedzi, halucynacje lub stopniowe pogarszanie się jakości wyników?

Ciche awarie systemów LLM zwykle występują wtedy, gdy na poziomie infrastruktury wszystko wygląda prawidłowo, ale rzeczywiste zachowanie systemu zaczyna się zmieniać. Obserwowalność pomaga na kilka sposobów:

• Śledzenie całego przepływu pracy, a nie tylko wywołania modelu – Rejestrując pełną drogę żądania — od klienta przez usługę, wyszukiwanie i model po narzędzia — można zobaczyć, gdzie zmieniło się zachowanie. Być może wyszukiwanie zaczęło zwracać mniej dokumentów albo wywołanie narzędzia sporadycznie zawodzi, przez co model improwizuje.
• Stały wgląd w podpowiedzi, kontekst i odpowiedzi – Możliwość analizowania podpowiedzi i odpowiedzi obok śladów znacznie ułatwia wykrycie, że nowa wersja podpowiedzi, instrukcja systemowa lub źródło kontekstu zmieniły zachowanie, mimo że opóźnienia i liczba błędów pozostały bez zmian.
• Filtrowanie według warunków semantycznych – Bogata telemetria LLM pozwala zawężać dane do przypadków takich jak „wywołania Bedrock trwające ponad sekundę”, „żądania korzystające z tej rodziny modeli” albo „ślady obejmujące tę konkretną trasę”, a następnie czytać podpowiedzi i odpowiedzi, aby sprawdzić, czy model dryfuje lub halucynuje w określonym scenariuszu.
• Alerty oparte na celach SLO na poziomie biznesowym – Można zdefiniować cel, zgodnie z którym każde wywołanie LLM trwające ponad sekundę narusza umowę SLA widoczną dla użytkownika, i uruchamiać alerty po spełnieniu tego warunku. Z czasem podobne cele można powiązać z ocenami jakości lub kontrolami zasad, aby ostrzeżenia dotyczyły również pogorszenia jakości, a nie wyłącznie awarii infrastruktury.

Ponieważ warstwa obserwowalności ma dostęp zarówno do sygnałów charakterystycznych dla AI, jak i do klasycznych dzienników, metryk oraz śladów, jest naturalnym miejscem wykrywania problemów, które w przeciwnym razie po cichu pogarszałyby doświadczenia użytkowników.

W jaki sposób podejście groundcover pomaga diagnozować nieprzewidywalne opóźnienia lub nietypowe zachowanie w wieloetapowych przepływach agentów i wywołaniach narzędzi?

groundcover stosuje podejście opracowane z myślą o nowoczesnych systemach AI. Wykorzystujemy czujnik oparty na eBPF, działający na poziomie jądra i obserwujący ruch między mikrousługami bez zmian w kodzie ani ponownych wdrożeń. Gdy tylko pojawia się przepływ pracy LLM, możemy automatycznie wykryć jego wywołania. Jeśli jutro zaczniesz korzystać z nowego modelu, na przykład Anthropic, OpenAI lub Bedrock, groundcover automatycznie zarejestruje ten ruch. Zapewnia to:

• Kompleksowe ślady wieloetapowych przepływów – Widać pełną drogę żądania przez usługi, w tym miejsca użycia LLM lub narzędzia.
• Szczegółowy kontekst każdego wywołania LLM – Każde wywołanie obejmuje użyty model, opóźnienie, zużycie tokenów, podpowiedzi, odpowiedzi oraz skorelowane dzienniki i metryki infrastruktury.
• Zaawansowane filtrowanie według opóźnień i warunków – Można na przykład odfiltrować wszystkie wywołania Claude 3.5 trwające ponad sekundę i natychmiast przeanalizować ślady, które naruszyły SLA.
• Alerty i pulpity związane z zachowaniem LLM – Po zebraniu danych można tworzyć alerty o naruszeniach SLA oraz pulpity śledzące opóźnienia, przepustowość, zużycie tokenów i błędy.

Ponieważ wszystkie dane są zbierane na brzegu sieci przez eBPF i przechowywane w chmurze klienta, uzyskuje się tak szczegółowy obraz bez dodawania instrumentacji do każdego agenta lub wywołania narzędzia.

Jakie zagrożenia dla bezpieczeństwa danych i zgodności z przepisami pojawiają się we wdrożeniach LLM i jak obserwowalność może je ograniczyć?

Wdrożenia LLM wiążą się z kilkoma szczególnymi zagrożeniami dla danych:

• Nieograniczone dane wprowadzane przez użytkowników – Użytkownicy mogą wpisywać do chatbotów i interfejsów opartych na AI wyjątkowo wrażliwe informacje. Mogą to być dane osobowe, dane klientów lub informacje regulowane, których organizacja nigdy nie zamierzała gromadzić.
• Zewnętrzni dostawcy modeli – Po wysłaniu danych do zewnętrznego dostawcy LLM organizacja odpowiada za to, dokąd trafiły, jak są przechowywane i jacy podwykonawcy mają w tym udział. Ma to poważne konsekwencje dla RODO, miejsca przechowywania danych i zaufania klientów.
• Telemetria jako druga kopia wrażliwych danych – Jeśli system obserwowalności wysyła pełne treści do dostawcy SaaS, poza środowiskiem organizacji powstaje kolejna kopia poufnych informacji.

Architektura groundcover została zaprojektowana właśnie z myślą o tych problemach:

• Stosujemy model „bring your own cloud”, w którym całe zaplecze obserwowalności działa na koncie chmurowym klienta, na koncie podrzędnym, jako w pełni zarządzana płaszczyzna danych. My obsługujemy płaszczyznę sterowania, która skaluje środowisko i nim zarządza, ale nie uzyskujemy dostępu do danych telemetrycznych, nie przechowujemy ich ani nie przetwarzamy.
• Ponieważ pełne treści można bezpiecznie rejestrować we własnym środowisku klienta, podpowiedzi, odpowiedzi i przepływy pracy pozostają w jego chmurze. Ślady LLM nie są przechowywane przez stronę trzecią i nie powstaje dodatkowy transfer danych na zewnątrz.
• Taka widoczność pozwala sprawdzać, kto przesyła jakie dane i dokąd one trafiają, wykrywać nieoczekiwane użycie informacji wrażliwych oraz egzekwować zasady dotyczące dozwolonych modeli i regionów.

Obserwowalność staje się więc nie tylko narzędziem niezawodności i kontroli kosztów, lecz także kluczowym punktem kontroli prywatności, miejsca przechowywania danych i zgodności z przepisami.

Jakie problemy operacyjne związane z widocznością, niezawodnością i kosztami pojawiają się, gdy organizacje przechodzą od jednej integracji LLM do wielu usług opartych na AI?

Pierwsza integracja zwykle obejmuje jeden model w jednym przepływie pracy. Na tym etapie sytuacja wydaje się łatwa do opanowania. Gdy tylko zespoły dostrzegają wartość rozwiązania, wykorzystanie gwałtownie rośnie i pojawia się kilka problemów:

• Rozrost liczby modeli i dostawców – Zespoły stale testują nowe modele. Szybko przestaje być jasne, które z nich działają na produkcji i w jaki sposób są używane.
• Niespodziewane koszty zużycia tokenów – Zużycie tokenów rośnie wraz z długością kontekstu i złożonością przepływu pracy. Bez widoczności zużycia dla poszczególnych modeli i przepływów zarządzanie kosztami jest bardzo trudne.
• Zależność niezawodności od dostawców zewnętrznych – Interfejsy API skierowane do użytkowników stają się wrażliwe na opóźnienia lub błędy modeli, co może naruszać SLA nawet wtedy, gdy podstawowa infrastruktura działa prawidłowo.
• Rosnący dług w instrumentacji – Tradycyjna obserwowalność zakłada, że w razie potrzeby można dodać instrumentację. W szybko zmieniających się środowiskach AI programiści rzadko mają na to czas.

groundcover rozwiązuje te problemy przez automatyczne wykrywanie ruchu AI i zapewnia:

• Centralny wgląd w używane modele i firmy je dostarczające.
• Pulpity pokazujące opóźnienia, przepustowość i zużycie tokenów w czasie.
• Korelację między zachowaniem LLM a usługami, które od niego zależą.
• Alerty dotyczące naruszeń SLO spowodowanych przez AI.

Dzięki temu znacznie łatwiej przejść od „jednej ciekawej funkcji AI” do sytuacji, w której „AI jest wpleciona w dziesiątki kluczowych usług”, bez utraty kontroli.

Jak obserwowalność LLM rozwinie się w ciągu najbliższych pięciu lat wraz z przyspieszeniem rozwoju agentowej AI, orkiestracji wielu modeli i presji regulacyjnej?

Wciąż jesteśmy na wczesnym etapie. W ciągu najbliższych pięciu lat spodziewam się kilku dużych zmian:

• Od rozumienia pojedynczych żądań do rozumienia agentów – Obserwowalność rozszerzy się na sekwencje narzędzi, ścieżki rozumowania i mechanizmy ponawiania prób, zamiast obejmować wyłącznie wywołania modeli.
• Bogatsze sygnały semantyczne i dotyczące zasad – Automatyczne kontrole jakości pod kątem halucynacji, bezpieczeństwa i zgodności z marką staną się standardowymi metrykami.
• Ściślejsze powiązanie z zarządzaniem i prywatnością – Wraz z rozwojem regulacji obserwowalność stanie się również warstwą egzekwowania i audytu zasad dotyczących miejsca przechowywania danych, retencji oraz zatwierdzonych modeli.
• Optymalizacja między modelami i dostawcami – Zespoły będą dynamicznie kierować ruch do różnych modeli na podstawie wydajności i kosztu, korzystając z danych obserwowalności w czasie rzeczywistym.
• Mniej ręcznej instrumentacji – Techniki takie jak zbieranie danych oparte na eBPF i automatyczne wykrywanie staną się domyślne, dzięki czemu zespoły będą mogły wprowadzać innowacje bez spowalniania pracy.

Obserwowalność LLM przekształci się z „przydatnych pulpitów dla AI” w centralny układ nerwowy łączący niezawodność, kontrolę kosztów, zarządzanie danymi i jakość produktów we wszystkich działaniach organizacji związanych z AI.

Dziękujemy za znakomity wywiad. Czytelnicy, którzy chcą dowiedzieć się więcej, mogą odwiedzić stronę groundcover.