Evals a observability agentów AI: co mierzyć i kiedy

Czym różnią się evals od observability?

Observability (obserwowalność) to zbieranie danych, z których da się odtworzyć działanie systemu. U agenta podstawową jednostką jest trace, czyli ślad: zapis jednego uruchomienia z wejściem, wyjściem i każdym wywołaniem modelu i narzędzia. Odpowiada na pytanie, co się stało.

Evals (od evaluations) to oceny jakości. Anthropic opisuje je przez zadanie z kryteriami sukcesu, próbę, czyli jedno podejście do zadania, oraz grader, czyli logikę punktującą wynik. Odpowiadają na pytanie, czy to, co się stało, było dobre.

Evals dzielą się na dwa rodzaje, a dokumentacja LangSmith rozróżnia je tak: offline działają przed wdrożeniem na przygotowanym zbiorze przypadków, często z wzorcową odpowiedzią. Online działają po wdrożeniu na śladach z produkcji, gdzie wzorca nie ma, więc sprawdzają wzorce jakości, bezpieczeństwo i zachowanie w prawdziwym ruchu. Sprawdzenie zgodności z konkretną poprawną odpowiedzią jest więc możliwe tylko offline.

Oba obszary się przenikają, bo ślad jest surowcem dla oceny, a ocena online to automat czytający ślady.

Luka między observability a evals w firmach

Ankieta LangChain State of Agent Engineering (1340 odpowiedzi, 18 listopada do 2 grudnia 2025) pokazuje, że observability agentów ma znacznie więcej firm niż evals. Jakąś formę observability ma 89% organizacji, szczegółowy tracing 62%. Testy offline na zbiorach uruchamia 52,4%, a oceny online 37,3%. Wśród firm z agentami w produkcji rozjazd zostaje: 94% ma observability, 44,8% oceny online.

Dostawca narzędzi do observability pyta tu o własny rynek. Ankieta była publiczna, 63% odpowiedzi pochodzi z branży technologicznej, a 49% z firm poniżej 100 osób. Polskich danych w tej ankiecie nie ma.

VentureBeat w czerwcu 2026 (157 osób, próba dobrana przez respondentów) zapytał, pod jaki rodzaj monitoringu zbudowana jest produkcja. Według raportu 51% monitoruje tylko to, czy agent działa (śledzenie transakcji, ruch przez gateway, czyli bramę pośredniczącą w wywołaniach modelu), a 23% ma automatyczne sprawdzanie jakości odpowiedzi w locie. W sierpniu 2026, wśród 118 firm wdrażających agentów, było to 53% i 29%. Pytanie miało jedną odpowiedź, więc część firm może robić obie rzeczy. Zielony panel z czasem odpowiedzi i liczbą błędów HTTP dobrze pokaże awarię usługi. Przykład ilustracyjny: hipotetyczny agent, który uprzejmie podaje klientowi zły termin zwrotu, zwróci w nim status 200.

Co mierzyć u agenta AI na każdym etapie

Propozycja tego tekstu: podziel pomiar agenta AI według pytania, które dany etap ma rozstrzygnąć:

• Prototyp: czytaj ślady ręcznie. Liczą się tu typowe sposoby, w jakie agent się myli, a automatyczna ocena jeszcze nie ma czego mierzyć.
• Przed pierwszym wdrożeniem: testy offline na zadaniach z prawdziwych przykładów, z oceną stanu systemu po próbie. Anthropic radzi oceniać to, co agent wytworzył, a ścieżkę kroków sprawdzać tylko tam, gdzie ma znaczenie, bo agenci znajdują poprawne drogi, których nikt nie przewidział.
• Przy każdej zmianie promptu, modelu lub narzędzia: te same testy jako regresja, z oczekiwanym wynikiem bliskim 100%.
• Po wdrożeniu: tracing całego ruchu, oceny online na próbce, koszt i czas odpowiedzi na uruchomienie.
• Okresowo: przegląd próbki śladów przez człowieka. W ankiecie LangChain z listopada i grudnia 2025, wśród firm uruchamiających evals, ręczny przegląd jako metodę oceny podało 59,8%, a model jako oceniającego 53,3%.

Co wdrożyć najpierw: tracing czy evals?

Tracing agenta idzie przed evals, bo bez śladów testy pisze się z głowy. LangChain w poradniku z października 2026 radzi zacząć od przeczytania próbki śladów, a z nich budować zbiory testowe.

Potem działa pętla opisana w dokumentacji LangSmith: ocena online oznacza problem, problem staje się przypadkiem offline, test offline potwierdza poprawkę, a ocena online sprawdza efekt na produkcji. Podobną pętlę NIST przywołuje za pracą Weidingera i współautorów: porównanie wyników sprzed wdrożenia z wynikami po nim.

Anthropic zestawia metody oceny w tabeli i każdej przypisuje wadę. Automatyczne testy mogą dawać fałszywą pewność, monitoring jest reaktywny, opinie użytkowników są rzadkie i przechylone ku poważnym problemom, a ręczny przegląd się nie skaluje. Anthropic pisze, że najskuteczniejsze zespoły łączą te metody.

Przykład evals i observability: agent obsługujący zwroty

Evals i observability najłatwiej pokazać na hipotetycznym agencie, który odpowiada klientom sklepu i zakłada zwroty w systemie zamówień. Ślad pojedynczej rozmowy zawiera pytanie klienta, odczyt zamówienia, sprawdzenie regulaminu, decyzję i zapis zwrotu. Bez niego po skardze zostaje tylko treść czatu.

Test offline to na przykład hipotetyczne zamówienie złożone już po upływie terminu zwrotu. Grader sprawdza dwie rzeczy: czy w systemie nie powstał zwrot i czy klient dostał powód odmowy. Pierwszy warunek da się ocenić kodem, drugi modelem albo człowiekiem. Taki przypadek ma poprawną odpowiedź, więc pasuje do zbioru.

W produkcji wzorca już nie ma, więc ocena online szuka objawów: rozmów zakończonych zwrotem bez odczytu zamówienia, odpowiedzi cytujących termin inny niż w regulaminie, klientów wracających z tą samą sprawą. Każdy taki ślad trafia do przeglądu, a potwierdzony błąd do zbioru offline. Panel z dostępnością usługi nie pokaże żadnej z tych rzeczy, a tracing bez ocen pokaże je dopiero temu, kto akurat przeczyta właściwą rozmowę.

Kiedy evals online są przesadą i co w observability jest niedojrzałe

Propozycja tego tekstu: pomiń oceny online przy wewnętrznym asystencie, którego każdą odpowiedź i tak czyta pracownik przed użyciem. Ślady i okresowy przegląd próbki wystarczą, dopóki agent niczego sam nie wykonuje. Podobnie testy A/B: Anthropic zaznacza, że trwają dni lub tygodnie i wymagają wystarczającego ruchu.

Ślady agenta zawierają treść rozmów i dane z narzędzi. NIST wymienia ryzyko naruszenia bezpieczeństwa i prywatności wśród zgłaszanych przeszkód w monitorowaniu. Zanim włączysz pełne logowanie promptów, ustal retencję, dostęp i to, czy ślady trafiają do chmury dostawcy narzędzia. Log z danymi klientów sam staje się zasobem do ochrony.

Standardy dopiero powstają. Uczestnicy warsztatów opisanych w NIST AI 800-4 zgłaszali brak zaufanych wytycznych dla monitoringu. Konwencje OpenTelemetry dla generatywnej AI przeniesiono do osobnego repozytorium, a jego strona statusu stabilnego nie podaje. Rynek też jest ruchomy: w sierpniowej fali VentureBeat z 2026 roku 62% badanych planowało w ciągu roku dodać albo wymienić platformę. Propozycja tego tekstu: trzymaj zbiory testowe i ślady w formacie, który da się wyeksportować.

Powiązane materiały

• Dlaczego agent AI przechodzi testy, a psuje się u klienta
• Agent wyłączył monitoring: wnioski z incydentu OpenAI dla firm
• Model dojrzałości agentów AI w firmie: od pilotażu do produkcji

Źródła

• LangChain: State of Agent Engineering
• LangSmith: Evaluation concepts
• LangChain: Common questions about agent evals (Divya Santhanam, 15.10.2026)
• Anthropic Engineering: Demystifying evals for AI agents
• VentureBeat Research: The agent evaluation gap (raport VB Pulse z czerwca 2026)
• VentureBeat Intelligence: Agentic reliability and evaluations (fala sierpniowa, 05.10.2026)
• NIST AI 800-4: Challenges to the Monitoring of Deployed AI Systems (marzec 2026)
• OpenTelemetry: Semantic Conventions for GenAI, repozytorium
• OpenTelemetry: GenAI semantic conventions, strona o przeniesieniu