Monitoring i KPI agenta AI: jak mierzyć skuteczność

Firma wdraża agenta AI, pierwsze tygodnie wyglądają świetnie — liczba zgłoszeń do konsultantów spada. Potem pojawia się reklamacja: agent udzielił błędnej informacji o cenie. Potem kolejna: zaproponował termin, który był niedostępny. Nikt nie zauważył, bo nikt nie mierzył niczego poza faktem, że agent „odpowiada". To jest standard dla większości pierwszych wdrożeń w Polsce i Europie Środkowej.

Monitoring agenta AI to nie opcja na późniejszy etap. To fundament, bez którego wdrożenie jest loterią. Poniżej opisuję, jak zbudować ten fundament od zera i jakie liczby faktycznie mówią prawdę.

Skuteczny monitoring agenta AI składa się z czterech warstw, które odpowiadają na różne pytania. Każda z nich jest konieczna, żadna nie zastępuje pozostałych.

Warstwa operacyjna jest najłatwiejsza technicznie (logi HTTP, Prometheus). Warstwa jakości odpowiedzi jest najtrudniejsza, bo wymaga oceny, czy odpowiedź była merytorycznie dobra, nie tylko „dostarczona". Warstwy nie można skracać do jednej liczby. Firma, która mierzy tylko CSAT, nie zobaczy rosnącego wskaźnika halucynacji do czasu, gdy klienci przestaną pytać.

Halucynacje to odpowiedzi poprawne składniowo, ale błędne merytorycznie. W systemach RAG ich główną przyczyną jest niska trafność wyszukiwania: model dostaje zły fragment i na nim buduje odpowiedź. Dlatego pierwszym KPI jakości jest retrieval precision — procent zapytań, dla których top-3 fragmenty z bazy wektorowej są merytorycznie trafne.

Sposoby pomiaru retrieval precision:

• Sampling z oceną ludzką — co tydzień losowo 50-100 par (zapytanie, odpowiedź RAG) jest ocenianych przez experta domenowego. Trafność powyżej 85% to dobry wynik dla pierwszego zakresu.
• LLM-as-judge — drugi model ocenia parę (fragment, pytanie) bez generowania odpowiedzi. Skuteczne do szybkiego skanowania dużych wolumenów, wymaga kalibracji na próbie ludzkiej.
• Ocena końcowa użytkownika — thumbs up/down lub krótka ankieta po obsłużonej sprawie. Najprostsze, ale mierzy wrażenie, nie merytorykę.

Drugi KPI jakości to wskaźnik eskalacji — procent konwersacji, które agent przekazał do człowieka. Zdrowy zakres to 15–35% dla pierwszego wąskiego wdrożenia. Poniżej 10% warto sprawdzić, czy guardrails działają poprawnie — agent może odpowiadać tam, gdzie powinien eskalować. Powyżej 50% baza wiedzy jest zbyt uboga na pokrycie zapytań.

Warstwa biznesowa tłumaczy jakość techniczną na wynik organizacyjny. Trzy liczby, które warto mieć na dashboardzie od pierwszego dnia:

Containment rate to procent spraw zamkniętych przez agenta bez eskalacji do człowieka. Dla wąskiego zakresu (np. tylko FAQ i status) 50–70% to realny cel po 8 tygodniach. Rosnący containment rate przy stabilnym lub rosnącym CSAT to dowód, że system dojrzewa. Rosnący containment rate przy spadającym CSAT to sygnał, że agent zamyka sprawy, których nie powinien.

Koszt na obsłużoną sprawę (cost-per-case) łączy koszty tokenów (inference), infrastruktury i nadzoru ludzkiego. Wylicza się go z telemetrii routera LLM: ile tokenów zużyło każde zapytanie pomnożone przez stawkę modelu plus ułamek kosztu infrastruktury. Porównaj z kosztem obsługi tej samej sprawy przez konsultanta. Różnica to Twój realny wynik finansowy, nie szacowany.

Czas do pierwszej odpowiedzi mierzony na percentylach p50 i p95. Median p50 poniżej 3 sekund jest osiągalny dla większości architektur RAG + LLM. P95 powyżej 15 sekund sygnalizuje bottleneck (timeout embedding, przeciążony llm-router, brak cache). Klienci akceptują 3-4 sekundy, nie akceptują 20.

Dobry monitoring agenta AI wymaga trzech komponentów: zbierania danych w czasie rzeczywistym, przechowywania z odpowiednim TTL i widoku agregującego.

Zbieranie danych wbudowujesz w router LLM. Każde wywołanie loguje: timestamp, model, liczba tokenów (input/output), latencja, wynik guardrails (pass/block/escalate), identyfikator sesji (zanonimizowany), źródła RAG (identyfikatory fragmentów, nie treść). Ten log jest fundamentem wszystkich późniejszych metryk.

Przechowywanie musi mieć TTL dopasowany do polityki RODO — zwykle 30–90 dni dla logów operacyjnych, dłużej tylko dla zagregowanych metryk bez PII. Treść rozmów jest osobna i ma własny krótszy TTL (zob. RODO i AI Act).

Warstwa agregacji to Prometheus + Grafana lub własny skrypt analityczny, zależnie od skali. Dla organizacji z wolumenem do 10 000 zapytań miesięcznie prosty dashboard w arkuszu z danymi z API routera jest wystarczający na start. Powyżej tego wolumenu Prometheus z alertami na anomalie jest standardem.

Pasywny dashboard to za mało. Potrzebujesz alertów, które reagują, zanim problem dotrze do klientów. Cztery alerty, które powinny działać od pierwszego dnia produkcyjnego:

1. Wskaźnik eskalacji powyżej progu — jeśli w ciągu godziny eskalacja przekroczy np. 60%, coś poszło nie tak z bazą wiedzy lub modelem. Natychmiastowe powiadomienie.
2. Latencja p95 powyżej 10 s — sygnał bottlenecku infrastrukturowego, nie jakościowego. Wymaga zbadania stacku, nie danych.
3. Guardrails block rate wzrósł o 3× w ciągu 1 godziny — sygnał próby ataku promptowego lub anomalii w danych wejściowych. Wymaga przejrzenia logów guardrails.
4. Koszt tokenów wzrósł o 50% przy stałym wolumenie — sygnał zmiany zachowania modelu (dłuższe odpowiedzi, więcej retrieval fragmentów) lub błędu konfiguracji.

Alerty nie powinny wszystkie trafiać do tej samej osoby. Latencja to DevOps, guardrails block rate to bezpieczeństwo, wskaźnik eskalacji to właściciel produktu. Human-oversight musi być zaprojektowane w architekturze od początku, nie dołączone po fakcie.

Dryft to zjawisko, w którym agent działał poprawnie w tygodniu pierwszym, ale po trzech miesiącach jego odpowiedzi są gorsze — bez żadnej zmiany w kodzie. Przyczyny:

• Dryft bazy wiedzy — dokumenty się przedawniły (nowe ceny, zmienione procedury), ale baza wektorowa nie była reindeksowana.
• Dryft dystrybucji zapytań — klienci zaczęli pytać o nowe rzeczy, których baza wiedzy nie pokrywa.
• Dryft modelu — dostawca zaktualizował model bez powiadomienia, zachowanie się zmieniło.

Detekcja dryftu wymaga regularnego testu regresyjnego. Utrzymuj zestaw 50–100 pytań z oczekiwanymi odpowiedziami (golden set) i uruchamiaj go co tydzień lub przy każdej zmianie bazy wiedzy. Spadek retrieval precision o więcej niż 5 punktów procentowych to sygnał do audytu. Artykuł o RAG i fine-tuningu opisuje, kiedy pogorszenie jakości wymaga doszkolenia modelu, a kiedy wystarczy aktualizacja bazy.

Agent AI obsługujący klientów to system z AI Act na radarze. Nie każdy agent jest systemem wysokiego ryzyka, ale każdy system konwersacyjny musi spełniać wymóg przejrzystości: klient musi wiedzieć, że rozmawia z AI. Log tej informacji jest częścią śladu audytowego.

Ślad audytowy dla agenta AI zawiera minimum:

• Identyfikator sesji (zanonimizowany lub pseudonimizowany)
• Wersję modelu i konfiguracji guardrails użytą w danej sesji
• Wynik każdego guardrails check (pass/block/escalate) z timestampem
• Identyfikatory źródeł RAG (nie treść, tylko referencja do dokumentu)
• Zdarzenia handoff do człowieka z kontekstem

Ten log pozwala odpowiedzieć na pytanie inspektora: „Dlaczego agent udzielił tej odpowiedzi 15 marca?" bez odtwarzania całego stanu systemu. Dla sektorów podlegających DPIA (finanse, zdrowie, HR) wymagania są surowsze — przegląd szczegółów w artykule o AI Act i RODO 2026.

Opisz swój obecny lub planowany system agentowy, a model wskaże, które KPI wdrożyć w pierwszej kolejności i jakie alerty są krytyczne dla Twojego zakresu (playground: PII maskowane, zero retencji):

Trzy liczby, które rozumie każdy zarząd: containment rate (procent spraw obsłużonych bez człowieka), CSAT po obsłudze AI w porównaniu do kanału ludzkiego i koszt na obsłużoną sprawę. Techniczne metryki jak latencja p95 czy retrieval precision trafiają do właściciela produktu lub inżynierów, nie do raportu zarządczego. Zarząd potrzebuje trendu tych trzech liczb miesięcznie, nie dziennej granulacji.

Minimalny rytm to co dwa tygodnie dla wdrożeń poniżej 1 000 zapytań dziennie i co tydzień powyżej tego progu. Kluczowe jest utrzymanie stałego golden setu pytań z oczekiwanymi odpowiedziami i automatyczne uruchamianie go przy każdej zmianie bazy wiedzy lub wersji modelu. Jednorazowy audyt wdrożeniowy bez rytmicznych testów regresyjnych nie chroni przed dryftem. Wzorce pracy z bazą wiedzy opisuje artykuł o firmowym GPT.

Wskaźnik eskalacji powyżej 40–50% przy wąskim zakresie zazwyczaj wskazuje na zbyt małą bazę wiedzy: agent nie znajduje wystarczająco trafnych odpowiedzi i ostrożnie przekazuje sprawę człowiekowi. To zachowanie pożądane z punktu widzenia bezpieczeństwa, ale kosztowne operacyjnie. Naprawa polega na rozszerzeniu i poprawie jakości dokumentów w bazie, nie na obniżaniu progu eskalacji. Ocenę luk w bazie wiedzy ułatwia narzędzie finder automatyzacji.

AI Act wymaga przejrzystości (ujawnienie, że rozmówca to AI), możliwości wyjaśnienia decyzji i pełnego human-oversight dla systemów wysokiego ryzyka. Monitoring jest instrumentem spełnienia tych wymogów: ślad audytowy pozwala odtworzyć, dlaczego agent zachował się w konkretny sposób, a alerty na guardrails i eskalacje dokumentują, że nadzór ludzki działa. Brak monitoringu to nie tylko ryzyko jakościowe — to luka w dokumentacji wymaganej przez regulatora. Szczegóły obowiązków firm w 2026 opisuje artykuł AI Act i RODO.

Zależy od skali i tego, co już macie. Przy istniejącym stacku (Prometheus, Grafana) koszt implementacji to głównie czas inżynierski. Przy wdrożeniu od zera dla małego wolumenu podstawowy monitoring (logi JSON, golden set test, prosty dashboard) można zbudować jako część projektu pilotażowego bez osobnej pozycji budżetowej. Koszty rosną przy high-availability, złożonych structured output pipeline'ach i audycie LLM-as-judge na dużych wolumenach. Realny kosztorys dla Waszego zakresu wygeneruje kalkulator ROI.