Niniejszy artykuł to notatki z webinaru „Davis Copilot Live series” przeprowadzonego przez zespół Dynatrace. Wszystkie przemyślenia, obserwacje i strategie przedstawione poniżej pochodzą od prelegentów: Safiyyah (Principal Solutions Consultant), Gabby (Senior Product Manager) oraz Thomas (Technical Architect).

TL;DR

Dynatrace jako „Customer Zero” – firma wykorzystuje własną platformę do monitorowania Davis Copilot, odpowiadając tym samym na pytania klientów o monitoring LLM
Architektura RAG z wbudowanym bezpieczeństwem – wszystkie komponenty bazują na Retrieval Augmented Generation z filtrami PII reduction projektowanymi od początku
Probabilistyczna natura LLM – już dodanie jednej kolumny w prompt może zmienić output, dlatego wymagane są specjalne strategie testowania
Wymuszone aktualizacje modeli – dostawcy LLM wycofują modele w ciągu roku, co zmusza do ciągłego testowania regresji
Dynamiczny wzrost adopcji – ponad 10% miesięczny wzrost unique accounts oraz 4-krotny wzrost invocations między majem a sierpniem 2024
Dashboard adopcji dla klientów – nowa funkcjonalność umożliwiająca organizacjom monitorowanie własnego wykorzystania AI
Przyszłość w agentic AI – nadchodzące funkcjonalności skoncentrują się na autonomicznych agentach z zachowaniem bezpieczeństwa i skalowalności

Od pytania klienta do roli Customer Zero

Historia monitorowania Davis Copilot rozpoczęła się od prostego zapytania klienta, które przedstawiła Safiyyah z zespołu Dynatrace. Klient zapytał wprost: „czy jako Dynatrace możecie powiedzieć nam, co powinniśmy monitorować w naszych LLM i silnikach generative AI?”

W odpowiedzi zespół podjął strategiczną decyzję, aby Dynatrace stało się „Customer Zero” dla własnego Davis Copilot. Oznaczało to wykorzystanie wewnętrznej platformy do monitorowania własnego rozwiązania AI, co pozwoliło na dzielenie się praktycznymi doświadczeniami z klientami.

Fundament architektury: RAG jako podstawa

Thomas, architect odpowiedzialny za Davis Generative AI, wyjaśnił, że wszystkie umiejętności Davis Copilot opierają się na Retrieval Augmented Generation (RAG). Podejście to polega na pobraniu odpowiedniego kontekstu, zbudowaniu rozszerzonego prompt oraz wysłaniu go do modelu językowego.

Wyzwania związane z Dynatrace Query Language

Generowanie DQL z języka naturalnego okazało się szczególnie trudnym zadaniem z kilku powodów, które zidentyfikował Thomas:

Ograniczona popularność DQL – język ten nie jest tak rozpowszechniony w internecie jak SQL
Brak głębokiego zrozumienia – żaden z dostępnych LLM nie posiada kompleksowego zrozumienia semantyki i składni DQL
Schema agnostic database – Grail data lake funkcjonuje jako generyczny data lakehouse, co utrudnia generowanie zapytań dostosowanych do kontekstu konkretnego klienta

Semantyczne indeksowanie i reduction danych osobowych

Zespół rozwiązał problem braku kontekstu poprzez budowanie semantycznie indeksowanych danych klienta co 24 godziny (pod warunkiem wyrażenia zgody przez klienta). System analizuje dane w Grail – metryki, logi, business events oraz inne informacje – tworząc w ten sposób zrozumienie kontekstu klienta. Te dynamiczne dane łączy się następnie ze statycznymi informacjami o Grail dostępnymi w dokumentacji, która jest aktualizowana tygodniowo z każdym sprint release.

Thomas podkreślił jednak, że PII reduction został wbudowany w architekturę od samego początku. Nie stanowił on dodatku, lecz fundamentalną decyzję projektową wynikającą z obaw klientów dotyczących wysyłania prywatnych danych do zewnętrznych dostawców LLM. Wszystkie dane opuszczające kontekst Dynatrace przechodzą przez filtry PII reduction. System wykorzystuje również content filters od dostawcy LLM, które używają modeli machine learning do rozróżnienia między szkodliwymi a nieszkodliwymi zapytaniami.

Monitoring workloadów AI: od developmentu do produkcji

Probabilistyczna natura LLM jako główne wyzanie

Według Thomasa, LLM są znacznie bardziej probabilistyczne niż tradycyjne serwisy. Nawet jeśli dostawcy twierdzą, że ich modele są reprodukowalne, w rzeczywistości reagują inaczej już przy dodaniu jednej kolumny w prompt. Ta nieprzewidywalność prowadzi do niestabilnych testów, dlatego wymaga specjalnego podejścia do testowania.

Lista kontrolna: testowanie LLM w fazie development

Przed implementacją:

Zaprojektuj mock responses LLM dla testów jednostkowych
Zaplanuj testy integracyjne z rzeczywistymi wywołaniami LLM (wyższe koszty)
Przygotuj zestaw testów regresji dla aktualizacji modeli
Ustal KPI specyficzne dla każdego AI skill (różne od tradycyjnych F1 score)

W trakcie developmentu:

Monitoruj wyniki regresji build po build poprzez alerty Dynatrace
Analizuj każdy znaczący spadek wydajności
Zatrzymaj proces development przy nieudanych testach regresji (automatyczne failing build)

Przy wymuszonych aktualizacjach modeli (co około rok):

Przeprowadź pełne testowanie regresji
Porównaj output starej vs nowej wersji modelu
Zbadaj różnice w zachowaniu (mogą być dramatyczne nawet przy minor updates)

Davis Predictive AI do własnego monitorowania

Thomas wyjaśnił, że zespół wykorzystuje własny Davis Predictive AI do monitorowania generative AI offering. Ustawiają automated baselines na metryki podzielone na różne wymiary. Jeśli spodziewane koszty z seasonal pattern przekroczą określony próg, otrzymują alerty i mogą głębiej analizować problem oraz planować skalowanie wdrożenia.

KPI dla porównań tekst-do-tekst

Thomas przedstawił fundamentalne wyzanie: obliczenie F1 score czy root mean squared error dla predykcji temperatury jest łatwe, ale porównywanie tekstu z tekstem nie jest ani łatwe, ani tanie. Zespół wykorzystuje podejścia takie jak „LLM as a judge” – kolejny large language model do oceny output systemu względem ustalonego baseline. Dane z self-monitoring są następnie używane w procesach manualnych do analizy możliwości ulepszenia podejścia RAG oraz jakości kontekstu.

Skalowanie i self-monitoring w praktyce

Thomas opisał dev-centric GitOps approach dla wielu zespołów korzystających z backend service. Centralny zespół generative AI dostarcza ogólny framework testowania uruchamiany w build pipelines, natomiast poszczególne zespoły aplikacji dostarczają swoje zestawy danych testowych w prostym formacie do centralnych pipeline regresji.

Na każdej instalacji Davis Copilot zespół ma zainstalowany Python agent. Gdy wystąpią problemy z LLM orchestration workflow, mogą przejść do aplikacji Traces i zobaczyć ślady od UI przez wszystkie etapy w platformie aż do implementacji Python orchestration framework.

Gabby wyjaśniła różnicę między LLM invocations a skill invocations. Każda standardowa konwersacja z Copilot chat wymaga trzech wywołań large language models na każde skill invocation. Ta granularność pozwala zespołowi precyzyjnie zidentyfikować miejsce wystąpienia problemu – od problemów z user input (guardrails, content filters) przez błędy systemowe po problemy na poziomie indywidualnych wywołań LLM.

Adopcja i spostrzeżenia z danych

Wzrost miesiąc do miesiąca

Gabby przedstawiła dane adopcji z ostatnich czterech miesięcy, pokazujące konsystentny wzrost mimo osiągnięcia statusu GA w lutym 2024:

Unique accounts – ponad 10% wzrost każdego miesiąca
Unique users – jeszcze bardziej agresywny wzrost niż accounts (ekspansja w organizacjach)
Core skills – 4-krotny wzrost invocations między majem a sierpniem 2024
Wzorzec adopcji – typowy przepływ: pilotaż przez garstką osób, następnie wdrożenie na organizację

Dashboard adopcji dla klientów

Gabby opisała ewolucję od wewnętrznych dashboardów do rozwiązania skierowanego do klientów. Klienci chcieli mieć te same spostrzeżenia o adopcji Davis Copilot w swoich środowiskach. Dashboard będzie dostępny do końca września i pokaże:

Active users w środowisku w czasie
Wskaźniki adopcji poszczególnych funkcji oraz success/failure rates
Przegląd głównych tematów w pytaniach użytkowników na wysokim poziomie
Informacje o błędach – kiedy rzeczy idą źle (guardrails, problemy z generowaniem DQL)
Wykorzystanie zasobów – bajty danych skanowanych przez zapytania generowane przez Copilot

Przyszłe funkcjonalności i agentic AI

Dostępne obecnie

Query explanations – pierwsza funkcjonalność zbudowana podczas AI journey, oferująca podsumowanie wysokiego poziomu oraz podział każdej części poleceń DQL. Thomas wyjaśnił, że służyła do generowania par natural language i zapytań DQL dla treningu systemu.

Troubleshooting guide suggestions – oparte na vector similarity. System automatycznie sugeruje istniejące przewodniki troubleshooting przy problemach podobnych do wcześniej rozwiązanych.

W fazie preview

Workflow actions umożliwiają integrację generative AI z automation engine Dynatrace. Przykłady przypadków użycia z transkryptu:

Analiza najdroższych zapytań log: „otrzymasz przegląd pięciu najdroższych zapytań. Proszę, podaj sugestie, jak można to zoptymalizować”
Generowanie raportów CISO na podstawie zapytań DQL
Raporty o wynikach compliance dla podatności

Gabby podkreśliła, że celowo wstrzymali marketing query explanations do okresu po lecie, ponieważ obserwują spowolnienie adopcji w miesiącach letnich.

Przyszłość: agentic AI

Gabby potwierdziła, że agentic AI to najbardziej ekscytujący kierunek rozwoju, jednak szczegóły będą dostępne w listopadzie podczas następnego spotkania. Thomas dodał perspektywę techniczną – skupienie na budowaniu solidnego fundamentu dla technologii agentic z zachowaniem skali i bezpieczeństwa, ponieważ wiele dostępnych serwerów MCP nie jest właściwie zbudowanych.

Praktyczne wnioski dla AI observability

Doświadczenie Dynatrace jako Customer Zero pokazuje kluczowe aspekty monitorowania workloadów AI:

Bezpieczeństwo musi być wbudowane od początku – PII reduction nie może być dodatkiem, lecz podstawową zasadą całego systemu.

Testowanie AI wymaga nowego podejścia – probabilistyczna natura LLM sprawia, że tradycyjne metody testowania nie wystarczą. W rezultacie potrzebne są wyspecjalizowane frameworki oraz KPI różne od klasycznych metryk machine learning.

Observability na wielu poziomach – od indywidualnych wywołań LLM po metryki na poziomie skill pozwala na precyzyjną diagnostykę problemów w złożonych workflow AI.

Adopcja wymaga dedykowanej analityki – zrozumienie zachowań użytkowników oraz wzorców adopcji jest kluczowe dla iteracji produktu, szczególnie gdy wdrożenie następuje stopniowo w organizacjach.

Jak zauważył Thomas, przyszłość leży w budowaniu solidnego fundamentu dla technologii agentic, który nie będzie wymagał przebudowy w perspektywie roku. Dynatrace oferuje unikalną pozycję łączenia danych observability z danymi biznesowymi dla uzyskania spostrzeżeń w sekundach czy minutach.

Lista kontrolna: gotowość na monitorowanie AI

Na podstawie doświadczeń zespołu Dynatrace można stworzyć praktyczną listę kontrolną dla organizacji planujących wdrożenie monitorowania systemów AI:

Architektura:

Czy mamy pełne zrozumienie budowy naszego systemu AI i przepływu danych?
Czy zabezpieczenia PII są wbudowane od początku, a nie dodane później?

Jakość i wydajność:

Jakie konkretne metryki zdefiniowaliśmy dla mierzenia jakości i trafności odpowiedzi?
W jaki sposób śledzimy opóźnienia i dbamy o szybkość odpowiedzi systemu?
Czy mamy mechanizmy do oceny output tekst-do-tekst (np. „LLM as a judge”)?

Kontrola kosztów:

Czy monitorujemy koszty zapytań do API modeli językowych?
Czy mamy automated baselines z seasonal patterns dla alertów kosztowych?

Bezpieczeństwo i stabilność:

Jakie zabezpieczenia wdrożyliśmy dla ochrony danych wrażliwych?
Czy przygotowaliśmy regression testing dla wymuszonych aktualizacji modeli?

Zespół i procesy:

Czy w procesie monitorowania uczestniczą osoby z perspektywą produktową i techniczną?
Czy mamy dev-centric GitOps approach dla wielu zespołów?

Kluczowy insight

LLM nie są rozwiązaniem „ustaw i zapomnij”

Standardowo myślimy: Raz wdrożony model ML działa długo i stabilnie jak tradycyjne oprogramowanie, wymagając minimalnego utrzymania.

W praktyce okazuje się, że: Dostawcy LLM zmuszają do aktualizacji co rok, wycofują starsze modele dla najnowszych wersji, a każda aktualizacja może dramatycznie zmienić zachowanie systemu nawet przy drobnych zmianach wersji.

Dlaczego to jest istotne: Zmusza to do budowania infrastruktury ciągłego testowania regresji od pierwszego dnia, nie jako funkcji nice-to-have. Jak mówi Thomas: „możesz być zaskoczony, jak różnie system reaguje” po każdej wymuszonej aktualizacji.

Test na jutro: Następnym razem gdy planujesz implementację AI, zamiast skupiać się tylko na początkowym wdrożeniu, zacznij od zaprojektowania frameworku testowania regresji i sprawdź, jak często Twój dostawca LLM wycofuje modele.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: [AI observability unfiltered: How we monitor Dynatrace CoPilot AMA Session LinkedIn]

Tag: Dynatrace Copilot

AI observability unfiltered: jak Dynatrace monitoruje własny Davis Copilot #EN281