AI observability w aplikacjach korzystających z modeli językowych: jak śledzić koszty tokenów, opóźnienia, błędy i jakość odpowiedzi oraz czym taki monitoring różni się od klasycznego observability

Aplikacja oparta na modelu językowym może zwrócić HTTP 200, zmieścić się w limicie czasu i jednocześnie wykonać swoje zadanie źle. Model może odpowiedzieć płynnie, ale podać nieprawdziwą informację. Agent może wykonać sześć wywołań narzędzi zamiast dwóch i podnieść koszt obsługi użytkownika pięciokrotnie. RAG może pobrać dokumenty, lecz nie te, które były potrzebne. Z kolei pozornie niewinna zmiana promptu potrafi zwiększyć odpowiedź z 500 do 2500 tokenów i wyraźnie podnieść rachunek za API.

Dlatego AI observability nie jest po prostu klasycznym monitoringiem z dodaną metryką liczby tokenów. Klasyczne observability odpowiada przede wszystkim na pytania: czy usługa działa, jak długo odpowiada, ile generuje błędów i gdzie wystąpiło wąskie gardło. W aplikacji LLM dochodzą kolejne: ile kosztowała konkretna odpowiedź, jaki model ją wygenerował, jakie dokumenty otrzymał, ile razy wywołał narzędzia, czy odpowiedź była zgodna z wymaganiami i czy użytkownik dostał faktycznie dobry wynik.

To zmienia sposób projektowania telemetryki. Jednostką, którą trzeba obserwować, przestaje być wyłącznie request HTTP. W praktyce ważniejszy staje się pełny przebieg zadania użytkownika — trace obejmujący wywołania modeli, retrieval, narzędzia, retry, fallbacki i walidację wyniku.

Dlaczego monitoring LLM musi widzieć więcej niż CPU, RAM, status HTTP i czas odpowiedzi

W klasycznym backendzie wiele awarii jest binarnych. Baza danych odpowiada albo nie. Endpoint zwraca 200 albo 500. Kolejka mieści się w założonym opóźnieniu albo zaczyna rosnąć. Oczywiście istnieją przypadki subtelniejsze, ale infrastruktura daje stosunkowo jednoznaczne sygnały.

Model językowy może natomiast technicznie działać idealnie i biznesowo zawieść.

Przykład: użytkownik pyta system obsługi klienta o termin wypowiedzenia umowy. API modelu odpowiada w 1,8 sekundy, nie ma żadnego wyjątku, zużycie CPU aplikacji jest niskie, a wszystkie komponenty są zielone. Model podaje jednak termin 30 dni, chociaż właściwy dokument mówi o 14 dniach. Dla Prometheusa wszystko wygląda dobrze. Dla firmy jest to incydent jakościowy.

Dlatego typowy trace aplikacji LLM powinien wyglądać mniej więcej tak:

• żądanie użytkownika,
• klasyfikacja intencji,
• wyszukiwanie dokumentów w bazie wektorowej lub wyszukiwarce,
• lista pobranych dokumentów i ich relevance score,
• zbudowanie promptu,
• wywołanie konkretnego modelu i konkretnej jego wersji,
• liczba tokenów wejściowych i wyjściowych,
• wywołania narzędzi,
• ewentualne ponowienia,
• walidacja odpowiedzi,
• końcowy wynik zwrócony użytkownikowi.

Taki przebieg powinien dostać jeden trace ID. Bez tego analiza awarii szybko zamienia się w ręczne sklejanie logów z kilku usług.

OpenTelemetry rozwija osobne konwencje semantyczne dla generatywnej AI. W telemetryce GenAI pojawiają się między innymi informacje o dostawcy modelu, używanym modelu, liczbie tokenów czy operacji wykonywanej przez system. To dobry kierunek, ponieważ zapobiega tworzeniu pięciu różnych nazw tej samej metryki w pięciu usługach.

Nie oznacza to jednak, że należy bezrefleksyjnie logować cały prompt i odpowiedź.

Prompty są często danymi użytkownika. Mogą zawierać nazwiska, numery umów, adresy e-mail, treść dokumentów, informacje kadrowe lub inne dane osobowe. W Polsce oznacza to konieczność patrzenia na telemetrykę również przez pryzmat RODO: zakres zbieranych danych, cel ich przetwarzania, dostęp, retencję i możliwość usuwania.

Najgorszy wzorzec, jaki można wdrożyć, wygląda więc tak: „zapisujmy wszystkie prompty, bo kiedyś mogą przydać się do debugowania”.

Lepszy model to trzy poziomy:

• metryki dla 100% ruchu — tokeny, czas, status, model, retry, koszt, liczba wywołań narzędzi;
• pełne trace’y dla wybranej próbki — np. 1–10% zwykłego ruchu;
• treść promptów i odpowiedzi tylko tam, gdzie jest potrzebna, najlepiej po redakcji lub pseudonimizacji danych.

Szczególnie kosztownym błędem jest też brak wersjonowania. Do każdego trace’u warto przypisać przynajmniej model, wersję promptu, wersję konfiguracji RAG oraz wersję aplikacji. Jeżeli po wdrożeniu promptu support-v37 odsetek poprawnych odpowiedzi spadnie z 93% do 84%, trzeba móc zobaczyć tę zmianę bez odtwarzania konfiguracji z Git history.

To właśnie tutaj AI observability zaczyna różnić się od APM. Nie obserwujemy tylko stanu programu. Obserwujemy także zachowanie probabilistycznego komponentu, którego wynik może zmienić się bez wyjątku w logach.

Tokeny, opóźnienia i błędy: metryki, które trzeba liczyć na poziomie pojedynczego zadania

Pierwsza metryka finansowa powinna być banalna: koszt każdego wywołania modelu w pieniądzu, a nie tylko liczba tokenów.

Same tokeny niewiele mówią, gdy aplikacja korzysta z kilku modeli.

Na początku września 2026 r. GPT-5.4 w API OpenAI kosztuje 2,50 USD za milion tokenów wejściowych, 0,25 USD za milion tokenów wejściowych z cache i 15 USD za milion tokenów wyjściowych. Claude Sonnet 5 w API Anthropic kosztuje 2 USD za milion tokenów wejściowych i 10 USD za milion tokenów wyjściowych.

Dla żądania zużywającego 10 000 tokenów wejściowych i 1000 wyjściowych daje to, przy podstawowym cenniku:

• GPT-5.4: 0,025 USD za input + 0,015 USD za output = 0,040 USD,
• Claude Sonnet 5: 0,020 USD za input + 0,010 USD za output = 0,030 USD.

Przy 100 000 takich żądań różnica wynosi około 1000 USD. Nie obejmuje to dodatkowych operacji, narzędzi, innych typów danych ani potencjalnych rabatów.

To pokazuje też pułapkę klasycznego dashboardu „tokens per day”. Powinno się liczyć co najmniej:

cost_per_request
Koszt pojedynczego requestu.

cost_per_session
Łączny koszt całej rozmowy lub zadania. Agent potrafi wykonać kilkanaście requestów modelowych w ramach jednego działania użytkownika.

cost_per_successful_task
Najważniejsza metryka przy porównywaniu modeli. Tańszy token nie oznacza tańszego rozwiązania, jeżeli model częściej wymaga ponowienia zadania.

input_tokens i output_tokens osobno
Output jest u wielu dostawców znacznie droższy od inputu.

cached_input_tokens
Bez tej metryki trudno stwierdzić, czy prompt caching faktycznie obniża rachunek.

koszt według modelu, klienta, funkcji i wersji promptu
Dopiero takie rozbicie pokazuje, gdzie naprawdę uciekają pieniądze.

W praktyce przydaje się jeszcze token budget. Jeżeli zadanie, które normalnie kosztuje 0,02–0,05 USD, nagle zaczyna regularnie kosztować 0,40 USD, system powinien to wykryć. Częstą przyczyną nie jest droższy model, lecz pętla agenta, zbyt długa historia rozmowy albo wrzucanie do kontekstu dokumentów, które nie są potrzebne.

Drugim obszarem jest czas.

Nie wystarczy średnie latency. Średnia świetnie ukrywa problemy. Jeżeli 95% zapytań kończy się w dwie sekundy, a pozostałe 5% trwa 30 sekund, wynik średni będzie wyglądał znacznie lepiej niż doświadczenie pechowego użytkownika.

Minimum to p50, p95 i p99.

W aplikacjach streamingowych warto rozbić czas na dwie metryki:

• TTFT — time to first token, czyli ile użytkownik czeka na rozpoczęcie odpowiedzi;
• czas całkowity, czyli kiedy odpowiedź rzeczywiście została zakończona.

To istotne rozróżnienie. Chat może rozpocząć odpowiedź po 700 ms i generować ją przez osiem sekund. Użytkownik odbiera taki system zupełnie inaczej niż aplikację, która przez siedem sekund nic nie pokazuje, choć końcowe latency obu przypadków będzie podobne.

W agentach trzeba mierzyć jeszcze osobno:

• latency modelu,
• latency retrieval,
• latency każdego narzędzia,
• liczbę kroków agenta,
• czas oczekiwania na retry,
• czas całego zadania.

Jeżeli agent potrzebuje 24 sekund, informacja „LLM latency = 2,1 s” jest mało użyteczna, jeśli 18 sekund pochłonęło wyszukiwanie w zewnętrznym systemie CRM.

Trzecia grupa to błędy. Warto rozdzielić je przynajmniej na:

• timeouty,
• błędy 4xx,
• błędy 5xx,
• rate limiting, np. HTTP 429,
• błędy walidacji structured output,
• nieudane tool calle,
• błędy retrieval,
• przekroczenie limitu kontekstu,
• przerwane odpowiedzi,
• retry,
• uruchomienie modelu fallbackowego.

Fallback nie powinien być traktowany jako sukces bez adnotacji. Jeżeli podstawowy model nie odpowiada i aplikacja przełącza użytkownika na drugi, dostępność produktu może pozostać na poziomie 99,9%, ale koszt albo jakość zacznie się pogarszać. Osobna metryka fallback_rate bardzo szybko pokazuje taki problem.

Alarmów również nie ustawiałbym od razu na kilkadziesiąt wskaźników. Pierwszy zestaw może być krótki: wzrost p95 latency, gwałtowny wzrost kosztu jednego zadania, zwiększenie error rate, wzrost retry/fallback rate oraz przekroczenie dziennego budżetu.

Dopiero kiedy te alerty działają i ktoś faktycznie na nie reaguje, ma sens budowanie bardziej wymyślnego centrum dowodzenia.

Jakość odpowiedzi jest metryką produkcyjną, ale trzeba ją mierzyć inaczej niż uptime

Najtrudniejsza część AI observability zaczyna się wtedy, kiedy system poprawnie wykonał wszystkie operacje techniczne. Trzeba odpowiedzieć na pytanie: czy rezultat był dobry?

Nie istnieje jedna uniwersalna metryka „LLM quality”.

Dla systemu RAG może to być poprawność odpowiedzi względem dokumentów. Dla ekstrakcji danych — zgodność wartości z dokumentem źródłowym. Dla agenta obsługującego CRM — prawidłowe wykonanie zadania. Dla generatora opisów produktowych — zgodność z faktami i wymaganym formatem.

Dlatego jakość najlepiej rozdzielać na konkretne kryteria.

W systemie RAG można mierzyć między innymi:

• retrieval relevance — czy pobrano właściwe dokumenty,
• groundedness — czy twierdzenia odpowiedzi wynikają z dostarczonego kontekstu,
• correctness — czy odpowiedź jest faktycznie prawidłowa,
• citation correctness — jeśli produkt prezentuje źródła, czy wskazane fragmenty rzeczywiście wspierają odpowiedź,
• answer completeness — czy system odpowiedział na całość pytania.

W agencie ważniejsze będą:

• task success rate,
• liczba tool calli na wykonane zadanie,
• odsetek błędnych wywołań narzędzi,
• liczba retry,
• liczba kroków do osiągnięcia celu,
• koszt poprawnie zakończonego zadania.

Tu pojawia się niewygodna prawda: automatyczny evaluator oparty na innym LLM też może się mylić.

LLM-as-a-judge świetnie nadaje się do oceny dużej próbki ruchu i wychwytywania trendów, ale nie powinien bez kalibracji stać się jedynym arbitrem jakości. Najpierw trzeba przygotować ręcznie oceniony zbiór przykładów — na przykład 200–500 rzeczywistych przypadków — a następnie sprawdzić, jak oceny automatyczne korelują z ocenami człowieka.

Jeżeli evaluator przyznaje wysoką ocenę odpowiedziom, które eksperci domenowi odrzucają, dashboard jakości jest po prostu ozdobą.

Warto połączyć trzy źródła sygnału:

• offline evals wykonywane przed wdrożeniem nowego modelu lub promptu;
• online evals wykonywane na próbce rzeczywistego ruchu;
• feedback biznesowy: reklamacje, eskalacje, poprawki pracowników, ponowne zadanie pytania, rezygnację z odpowiedzi czy finalizację procesu.

Szczególnie użyteczna jest metoda porównywania wersji. Zamiast pytać „czy model ma score 0,87?”, lepiej sprawdzić: czy nowy prompt zwiększył poprawność z 88% do 93%, ile zmienił p95 latency i ile kosztuje dodatkowe pięć punktów procentowych jakości.

Dopiero wtedy można podjąć decyzję ekonomiczną.

Jeśli model A osiąga 94% poprawności przy koszcie 0,12 USD za wykonane zadanie, a model B 92% przy 0,025 USD, wybór zależy od zastosowania. W wewnętrznym narzędziu do przygotowania pierwszego szkicu model B może być oczywistym wyborem. Przy decyzji wpływającej na klienta różnica dwóch punktów procentowych może uzasadniać wyższy koszt albo dodatkową kontrolę człowieka.

Jakość trzeba również segmentować. Jedna średnia potrafi ukryć poważny problem. System może mieć 95% poprawności globalnie, a jednocześnie tylko 72% dla zapytań po polsku dotyczących określonej kategorii produktów. Dashboard powinien więc pozwalać filtrować wyniki przynajmniej według wersji modelu, języka, typu zadania, wersji promptu, źródła danych i kategorii użytkownika, o ile taki podział jest zgodny z zasadami ochrony danych.

W środowisku europejskim telemetryka nie może powstawać w oderwaniu od kwestii prawnych. AI Act obowiązuje zasadniczo od 2 sierpnia 2026 r., przy czym dla poszczególnych kategorii systemów wysokiego ryzyka przewidziano dalsze terminy przejściowe. W aktualnym harmonogramie wymagania odnoszące się do części systemów klasyfikowanych jako high-risk na podstawie Annex III mają być stosowane od 2 grudnia 2027 r., a dla części systemów związanych z produktami z Annex I — od 2 sierpnia 2028 r. Artykuł 12 AI Act przewiduje dla systemów wysokiego ryzyka techniczną możliwość automatycznego rejestrowania zdarzeń w cyklu życia systemu.

To nie jest jednak argument za zapisywaniem wszystkiego.

Jeżeli w promptach mogą znaleźć się dane osobowe, logowanie pełnej treści trzeba potraktować jak normalne przetwarzanie danych, a nie „techniczny log”. W praktyce sensowna architektura często rozdziela metryki operacyjne od payloadów. Dashboard może przechowywać identyfikator trace’u, tokeny, czasy, model i ocenę bez przechowywania kompletnej rozmowy.

Kolejne ograniczenie to retencja. Nie ma powodu, aby każda firma przechowywała pełne trace’y LLM bezterminowo. Przykładowa polityka może przewidywać dłuższą retencję zagregowanych metryk, krótszą dla szczegółowych trace’ów i jeszcze bardziej ograniczoną dla treści promptów. Konkretne okresy trzeba ustalić na podstawie celu przetwarzania, obowiązków prawnych i potrzeb operacyjnych.

Sam stos narzędzi nie musi być skomplikowany. OpenTelemetry pozwala ujednolicić generowanie trace’ów, metryk i logów, a dane można później wysyłać do istniejącego backendu observability albo rozwiązania wyspecjalizowanego w LLM. Najważniejsze jest unikanie uzależnienia modelu danych od jednego panelu. Jeżeli model, tokeny, prompt version i trace ID istnieją tylko w autorskim formacie dostawcy SaaS, późniejsza migracja boli bardziej, niż powinna.

Minimalny rekord pojedynczego wywołania LLM powinien zawierać co najmniej:

• trace_id,
• request_id,
• nazwę i wersję modelu,
• nazwę dostawcy,
• wersję promptu,
• czas rozpoczęcia,
• latency,
• TTFT przy streamingu,
• input tokens,
• cached input tokens, jeśli występują,
• output tokens,
• policzony koszt,
• status,
• typ błędu,
• retry count,
• fallback,
• identyfikatory wykorzystanych narzędzi lub źródeł RAG,
• ocenę jakości, jeśli została wykonana.

W systemie agentowym dodałbym jeszcze liczbę kroków, tool calls oraz koszt całego zadania, ponieważ pojedynczy call przestaje być sensowną jednostką biznesową.

Najbardziej irytujący błąd pojawia się wtedy, kiedy zespoły inwestują od razu w rozbudowany panel z kilkudziesięcioma wykresami, ale nie potrafią odpowiedzieć na proste pytanie: „dlaczego ten konkretny użytkownik dostał złą odpowiedź?”. Jeżeli z identyfikatora requestu nie da się przejść przez retrieval, prompt, model, tool calle i wynik, observability jest niekompletne niezależnie od liczby dashboardów.

FAQ: najczęstsze pytania o AI observability

Czy Prometheus, Grafana i klasyczny APM wystarczą do monitorowania aplikacji LLM?
Do infrastruktury często tak, do całości produktu — nie. Potrzebujesz dodatkowo tokenów, kosztów, identyfikacji modelu i promptu, przebiegu agentów, danych dotyczących retrieval oraz pomiaru jakości odpowiedzi. Część tych informacji można nadal wysyłać do obecnego stosu observability.

Czy trzeba zapisywać wszystkie prompty i odpowiedzi?
Nie. Pełna treść bardzo pomaga podczas debugowania, ale zwiększa koszty przechowywania i ryzyko związane z danymi osobowymi oraz informacjami poufnymi. Rozsądniejszym punktem startowym jest 100% metryk technicznych oraz kontrolowane próbkowanie treści po zastosowaniu odpowiednich zasad redakcji, dostępu i retencji.

Jaka metryka kosztowa jest najważniejsza?
Dla prostego chatu może wystarczyć koszt odpowiedzi, ale w agentach lepszą jednostką jest cost per successful task. Agent, który kosztuje mniej za pojedynczy call, ale wymaga pięciu dodatkowych kroków i częściej ponawia operacje, nie jest faktycznie tańszy.

Jak ustawić alert kosztowy?
Nie alarmuj tylko na całkowity miesięczny rachunek. Kontroluj koszt pojedynczego requestu lub zadania oraz jego p95. Gwałtowny wzrost tej wartości często ujawnia pętlę agenta, niekontrolowany retry, rozrastającą się historię konwersacji albo zbyt duży kontekst RAG, zanim problem pojawi się na fakturze.

Czy jakość da się monitorować w czasie rzeczywistym?
Tak, ale zwykle nie dla 100% ruchu i nie jednym wskaźnikiem. Na produkcji można automatycznie oceniać próbkę odpowiedzi, a wyniki okresowo kalibrować na ręcznie ocenionym zbiorze. Dla zadań o dużych konsekwencjach sam LLM-as-a-judge nie jest wystarczającym mechanizmem kontrolnym.

Co monitorować przy RAG?
Nie tylko finalną odpowiedź. Rejestruj zapytanie wyszukiwawcze, identyfikatory pobranych dokumentów, ich score, czas retrieval, rozmiar kontekstu oraz ocenę groundedness. W przeciwnym razie nie rozróżnisz błędu modelu od sytuacji, w której model po prostu dostał niewłaściwe źródła.

Czy AI observability mocno zwiększa koszty systemu?
Może. Najwięcej kosztuje zwykle przechowywanie dużej liczby pełnych trace’ów i payloadów oraz automatyczne ocenianie odpowiedzi dodatkowymi wywołaniami LLM. Dlatego metryki warto zbierać szeroko, a szczegółowe treści i kosztowne evale próbkować zgodnie z ryzykiem danego procesu.

Od czego zacząć wdrożenie?
Nie od wyboru kolejnego narzędzia SaaS. Najpierw weź 20–50 rzeczywistych requestów z produkcji i sprawdź, czy dla każdego potrafisz odtworzyć cały przebieg: model i jego wersję, wersję promptu, retrieval, tool calle, tokeny, koszt, latency, retry, fallback oraz finalny rezultat. Jeżeli którejś z tych informacji nie da się przypisać do jednego trace_id, usuń właśnie ten problem jako pierwszy. Dopiero potem buduj dashboardy i automatyczne evale.

Więcej informacji na: https://itux.pl