LLM observability: tracing, metryki, logi i ewaluacje agentów AI

Obserwowalność agentów AI pozwala zajrzeć do wnętrza autonomicznego agenta dzięki tracingowi (spany obejmujące rozumowanie i wywołania narzędzi), metrykom (opóźnienie, tokeny, koszty, wskaźnik powodzenia), ustrukturyzowanym logom i ciągłym ewaluacjom. Odpowiada na pytanie, dlaczego agent podjął taką decyzję, i jest warunkiem, by w ogóle móc debugować, zabezpieczać i audytować wieloetapowych agentów na produkcji.

W przeciwieństwie do klasycznej usługi webowej agent nie podejmuje jednej decyzji typu żądanie-odpowiedź, tylko przy każdym zadaniu przechodzi przez kilka rund rozumowania przeplatanych wywołaniami narzędzi. Właśnie ta wieloetapowość sprawia, że tradycyjny monitoring jest ślepy: HTTP 200 nie mówi nic o tym, czy wywołano właściwe narzędzie z właściwymi argumentami ani czy model w połowie drogi nie skręcił w złą stronę.

Trzy najważniejsze punkty na początek:

• Obserwowalność agentów składa się z czterech filarów. Tracing, metryki, logi i ewaluacje. Zazębiają się ze sobą: ślad dostarcza ścieżkę, metryki agregację, logi kontekst, a ewaluacje ocenę jakości.
• Bez tracingu agentów nie da się debugować. Tylko hierarchiczny ślad obejmujący wszystkie spany rozumowania i wywołań narzędzi pokazuje, na którym kroku wieloetapowy łańcuch się zerwał.
• Rezydencja danych to kryterium obowiązkowe. Ponieważ ślady zawierają prompty i odpowiedzi, a więc potencjalnie dane klientów, sam backend obserwowalności staje się dla firm B2B w Europie obiektem compliance (samodzielnie hostowany Langfuse w UE, Datadog EU, Honeycomb EU).

Dlaczego bez tracingu agentów nie da się debugować

Agent jest niedeterministyczny. To samo żądanie może prowadzić do różnych wywołań narzędzi, różnej liczby rund rozumowania i różnych wyników. Gdy przebieg kończy się niepowodzeniem albo daje merytorycznie błędną odpowiedź, bez tracingu nie ma wiarygodnego sposobu, by wyizolować przyczynę. Możliwe źródła błędów w jednym żądaniu:

• LLM źle rozumował i wybrał nieodpowiednie narzędzie.
• Narzędzie zostało wywołane z błędnymi argumentami.
• Krok wyszukiwania (RAG) pobrał niewłaściwe dokumenty.
• Guardrail lub filtr PII zadziałał i zmienił kontekst.
• Wersja modelu zmieniła się po stronie serwera (zarządzane API aktualizują modele według harmonogramu dostawcy).

Płaski log wyjściowy nie rozróżnia tych przypadków. Tracing pokazuje każdy z tych kroków jako osobny span, osadzony w czasie i w łańcuchu przyczynowym. Debugowanie przestaje więc być „zgadywaniem na podstawie wyniku końcowego” i staje się „znalezieniem konkretnego spanu, który zawiódł”. W architekturze jest tak samo: service meshe zapewniają obserwowalność na poziomie sieci, a stosy agentów złożone z wielu mikrousług (orkiestrator, serwer narzędzi, memory store, baza wektorowa, usługa wyszukiwania, usługa guardraili) da się opanować tylko dzięki spójnej warstwie obserwowalności obejmującej cały system.

Cztery filary obserwowalności agentów

Tracing: spany obejmujące rozumowanie i wywołania narzędzi

Ślad odwzorowuje całe żądanie agenta w postaci drzewa. Span główny obejmuje całe żądanie; pod nim wiszą zagnieżdżone spany dla każdego wywołania LLM, każdego wywołania narzędzia, każdego kroku wyszukiwania i każdej kontroli guardraila. Każdy span zawiera dane wejściowe i wyjściowe oraz atrybuty, takie jak nazwa modelu, tokeny promptu i completion, opóźnienie oraz wyliczone na ich podstawie koszty. Ta hierarchiczna struktura to decydująca różnica w porównaniu z klasycznym, płaskim logiem żądań.

Metryki: opóźnienie, tokeny, koszty, wskaźnik powodzenia

Metryki agregują dane z wielu śladów. Rdzeń tworzą cztery sygnały:

• Opóźnienie, end-to-end i na rundę wywołań narzędzi. Między regionami Azure Germany West Central (Frankfurt) i East US Microsoft mierzy medianę 94 ms w obie strony (statystyki opóźnień Azure, stan na lipiec 2026). Agent we Frankfurcie, który wywołuje API we wschodnich USA, płaci ten czas przy każdym wywołaniu. Przy kilku rundach narzędzi czas się sumuje.
• Tokeny (prompt i completion) na każdy span jako podstawa przypisywania kosztów.
• Koszty na żądanie, na zespół i na przypadek użycia.
• Wskaźnik powodzenia, czyli odsetek poprawnie ukończonych zadań.

Logi: ustrukturyzowany kontekst

Ustrukturyzowane logi uzupełniają spany o szczegółowy kontekst: surowe odpowiedzi narzędzi, ponowne próby, aktywacje guardraili, obcięte konteksty. Kluczowa jest korelacja: każdy wpis w logu powinien dać się przypisać do konkretnego spanu przez trace ID, inaczej znów powstaje martwe pole.

Ewaluacje: jakość jako część obserwowalności

Ewaluacje to sygnał, którego sam tracing nie dostarcza: systematyczna ocena jakości wyników. Ocenia się zwykle wskaźnik powodzenia, poprawność wywołań narzędzi (czy wywołano właściwe narzędzie z właściwymi argumentami?) i jakość odpowiedzi, za pomocą heurystyk, referencyjnego zbioru danych albo podejścia „LLM-as-a-Judge”. W kontekstach regulowanych kluczowe jest to, że ewaluacje i wersje promptów są tagowane w bramce lub na platformie obserwowalności względem zamrożonych wersji modelu. Dzięki temu każdą ocenę jakości można przypisać do konkretnej wersji modelu i promptu. Jeśli agent został zaklasyfikowany jako system wysokiego ryzyka w rozumieniu AI Act, takie przypisanie ułatwia przedstawienie wymaganych dowodów, np. w zakresie dokładności i solidności zgodnie z art. 15 oraz procedur walidacji i testowania, które musi zawierać dokumentacja techniczna zgodnie z art. 11 i załącznikiem IV.

Macierz sygnałów i narzędzi

Poniższa tabela przypisuje każdemu sygnałowi obserwowalności mierzoną wielkość i typowe narzędzie (stan na 2026).

Stos obserwowalności LLM: przegląd narzędzi

W warstwie obserwowalności w grę wchodzą przede wszystkim te narzędzia (stan na 2026):

• LangSmith, platforma do tracingu i ewaluacji z ekosystemu LangChain/LangGraph, dostępna jako usługa zarządzana. Dobry wybór, jeśli agent i tak bazuje na tym frameworku. Przy usłudze zarządzanej sprawdź wcześniej, gdzie przechowywane są ślady.
• Langfuse, open source i według dokumentacji self-hostingu możliwy do uruchomienia na własnej infrastrukturze, a więc z możliwością self-hostingu w UE (własne centrum danych lub region UE). Pasuje zarówno do regulowanych architektur z obserwowalnością kontrolowaną przez klienta, jak i do lekkich konfiguracji chmurowych, które utrzymują ślady w UE zgodnie z RODO.
• Arize Phoenix, narzędzie do obserwowalności i ewaluacji na licencji Elastic License 2.0, które można bezpłatnie hostować samodzielnie, a więc alternatywa dla Langfuse.
• OpenTelemetry dla LLM / OpenInference, niezależny od dostawców standard śladów. Gdy instrumentujesz przez GenAI Semantic Conventions, backend pozostaje wymienny: to ważny argument przeciwko vendor lock-in. TGI od Hugging Face eksportował na przykład ślady OpenTelemetry i metryki Prometheusa już przed przejściem projektu w tryb utrzymania.
• Datadog EU / Honeycomb EU, sprawdzone backendy APM z regionem w UE: Datadog prowadzi lokalizację EU1 w Niemczech, a Honeycomb przechowuje dane w zależności od wybranego regionu USA lub UE. Oba to opcja zarządzana, gdy dane mają pozostać w UE.

Ważna kwestia architektoniczna: bramka AI (LiteLLM, Portkey, Kong) często już przejmuje część obserwowalności. Bramki zwykle odpowiadają za failover między wieloma dostawcami, zarządzanie wirtualnymi kluczami, budżety zespołów, obserwowalność, guardraile i maskowanie PII. W praktyce bramka przypisuje tokeny i koszty, a platforma tracingu przechowuje ścieżkę rozumowania i ewaluacje: razem dają pełny obraz.

Przykładowy ślad: przebieg agenta krok po kroku

Poniższy pseudoprzykład pokazuje, jak wygląda pojedynczy przebieg agenta obsługi klienta w postaci drzewa spanów. Liczby są poglądowe.

```
TRACE id=ag-7f3c "Zgłoszenie klienta: anulowanie faktury" łącznie: 4210 ms | 3320 tokenów | 0,041 USD
├─ SPAN llm.reason model=gpt-4.x 620 ms | in 540 / out 80 Tok "Plan: sprawdzić klienta+fakturę"
├─ SPAN tool.crm_lookup mTLS, in-VPC 180 ms | status=200 args={klient_id:8842}
├─ SPAN retrieval.vector qdrant-eu 95 ms | 4 trafienia query="zasady anulowania B2B"

├─ SPAN llm.reason model=gpt-4.x 710 ms | in 1980 / out 130 Tok "Anulowanie dozwolone, wywołać narzędzie"
├─ SPAN tool.invoice_void in-VPC 240 ms | status=200 args={faktura:RE-2026-0317}
├─ SPAN guardrail.pii redaction 40 ms | 0 trafień
└─ SPAN llm.compose model=gpt-4.x 2325 ms | in 380 / out 210 Tok treść odpowiedzi dla klienta
EVAL tool_call_correct=PASS | answer_quality=0,92 | otagowano: model=gpt-4.x, prompt=v7
```

Co daje ten ślad, czego nie da log wyjściowy: gdyby anulowanie się nie powiodło, drzewo od razu pokazuje, czy tool.invoice_void zwrócił status błędu, czy retrieval.vector pobrał niewłaściwe zasady, czy też drugi span llm.reason podjął złą decyzję. Największy składnik opóźnienia (llm.compose, 2325 ms) od razu rzuca się w oczy jako kandydat do optymalizacji. A wiersz ewaluacji wiąże ocenę jakości z wersją modelu i promptu: to podstawa rollbacku i audytu.

Związek z monitoringiem w artykule filarowym o bezpieczeństwie

Tracing jest sygnałem debugowania, a także sygnałem bezpieczeństwa. Agenci mają nietypowo duży „promień rażenia”: przejęty agent może wywołać wiele narzędzi. Spójny ślad dostarcza właśnie ten log audytowy, dzięki któremu tę powierzchnię ataku da się prześledzić: który agent, kiedy i z jaką tożsamością wywołał które narzędzie. Jeśli agent jest systemem wysokiego ryzyka w rozumieniu AI Act, ten ślad stanowi zarazem techniczną podstawę automatycznego rejestrowania zdarzeń, którego wymaga art. 12. Ślad uzupełnia mechanizmy kontrolne z obszaru bezpieczeństwa i tożsamości: ruch wychodzący domyślnie blokowany, z allowlistą i logowaniem na bramce, jedno konto usługowe na każdą parę agent-narzędzie zamiast współdzielonych kont oraz powiązanie każdego wywołania z tożsamością użytkownika przez łańcuch token exchange. Obserwowalność na poziomie sieci dzięki service mesh (mTLS, workload identity, traffic shaping) domyka całość. Szczegółowe wzorce pomiaru i kontroli dotyczące ruchu wychodzącego, tożsamości i monitoringu omawia artykuł filarowy o bezpieczeństwie; warstwa obserwowalności dostarcza do tego bazę telemetryczną. Konkretna ekonomia tokenów i modelowanie kosztów to z kolei temat artykułu filarowego o FinOps.

Dla agencji i decydentów B2B

Dla agencji marketingowych, które budują dla klientów przepływy pracy oparte na agentach, obserwowalność jest elementem dostawy, który odróżnia pilotaż od audytowalnego systemu produkcyjnego: dopiero ślad, ewaluacje i backend zgodny z wymogami UE sprawiają, że agenta można eksploatować, rozliczać i obronić pod kątem ochrony danych klienta. Dla decydentów B2B w Europie: wybierz backend obserwowalności równie świadomie jak region chmury. Samodzielnie hostowany Langfuse, Datadog EU lub Honeycomb EU utrzymują prompty i odpowiedzi w obrębie UE, a niezależny od dostawców tracing oparty na OpenTelemetry chroni przed vendor lock-in. Blck Alpaca z Wiednia projektuje i utrzymuje infrastrukturę agentów z tą warstwą obserwowalności od samego początku, łącznie z tracingiem, środowiskiem ewaluacyjnym i backendem zgodnym z RODO. Odezwij się, jeśli chcesz przenieść agenta z fazy pilotażu do audytowalnego środowiska produkcyjnego.