# Evals dla agentów AI: jak mierzyć jakość przed i po produkcji
Wiele organizacji uruchamia agentów AI po udanym demie i kilku ręcznych testach. Na początku wszystko wygląda dobrze: zespół widzi szybkie odpowiedzi, użytkownicy są zainteresowani, a liczba interakcji rośnie. Po kilku tygodniach pojawiają się jednak znane problemy: niespójność odpowiedzi, trudne do odtworzenia błędy, wzrost kosztu korekt oraz konflikty między zespołami o to, kto ma rację, gdy agent działa "czasem dobrze".
Źródło tych problemów jest zwykle to samo: brak systemu ewaluacji, który łączy etap przedprodukcyjny z rzeczywistą jakością po wdrożeniu. Organizacja mierzy aktywność, ale nie mierzy niezawodności decyzji.
Centralna teza tego playbooka brzmi: evals dla agentów AI muszą być zaprojektowane jako ciągły system zarządzania jakością, a nie jednorazowy test release'u. Tylko wtedy da się skalować agentów bez skalowania reworku, ryzyka i kosztów ukrytych.
Dlaczego klasyczne QA nie wystarcza dla agentów
Agenci AI różnią się od klasycznych aplikacji tym, że ich zachowanie zależy od zmiennego kontekstu: zapytań użytkownika, narzędzi, danych zewnętrznych, polityk bezpieczeństwa i wersji modelu. Ta zmienność oznacza, że test "pass/fail" na statycznych przypadkach nie oddaje realnej jakości.
NIST AI RMF 1.0 (2023) wskazuje, że zarządzanie ryzykiem AI wymaga ciągłej obserwacji i adaptacji kontroli. organizacja powinna łączyć: - ewaluacje offline przed produkcją, - testy w warunkach zbliżonych do rzeczywistych, - monitoring online po wdrożeniu, - procedury szybkiej korekty i ponownej walidacji.
Bez tej pętli agent może być "dobry na benchmarku", ale słaby w procesie, który ma obsługiwać.
Architektura evals: cztery warstwy jakości
Skuteczny system evals dla agentów warto budować warstwowo. Każda warstwa odpowiada na inne pytanie i redukuje inny typ ryzyka.
### Warstwa 1: Correctness evals
Sprawdza, czy agent dostarcza poprawny rezultat merytoryczny dla jasno zdefiniowanych zadań. Tu używa się zestawu przypadków referencyjnych i kryteriów akceptacji.
Przykładowe metryki: - odsetek poprawnych odpowiedzi, - precision/recall dla zadań klasyfikacyjnych, - odsetek odpowiedzi wymagających pełnej poprawki człowieka.
Ta warstwa minimalizuje ryzyko oczywistych błędów rzeczowych.
### Warstwa 2: Robustness evals
Sprawdza, jak agent zachowuje się przy nietypowych lub trudnych wejściach: niejednoznacznych instrukcjach, sprzecznych danych, próbach obejścia polityk.
Inspiracje z OWASP Top 10 for LLM Applications (2023) i praktyk red teamingu pomagają projektować scenariusze typu prompt injection, nieautoryzowane ujawnienie danych czy naruszenie instrukcji systemowych.
Ta warstwa minimalizuje ryzyko degradacji w warunkach niestandardowych.
### Warstwa 3: Process-quality evals
Sprawdza, czy agent poprawia proces biznesowy, a nie tylko "ładnie odpowiada". Tu ocenia się m.in. czas realizacji zadania, odsetek reworku, zgodność z procedurą i wpływ na SLA.
To krytyczne, bo wartość biznesowa agentów powstaje w workflow, nie w izolowanym oknie czatu.
### Warstwa 4: Safety and governance evals
Sprawdza zgodność działania z politykami bezpieczeństwa, prywatności i odpowiedzialności. Wysokie znaczenie mają przypadki graniczne: kiedy agent powinien odmówić, eskalować do człowieka lub poprosić o dodatkową autoryzację.
Ta warstwa ogranicza ryzyko prawne i reputacyjne oraz wspiera model human-in-the-loop.
Jak budować zestaw testów, który nie starzeje się po tygodniu
Najczęstszy błąd to statyczny zestaw testów tworzony na start projektu i nieaktualizowany po zmianach produktu. Agenci uczą się z nowych danych, integrują nowe narzędzia i obsługują nowe intencje użytkowników, więc testy też muszą ewoluować.
Praktyczna zasada: utrzymuj trzy koszyki przypadków.
- **Golden set**: reprezentatywne przypadki krytyczne dla jakości i bezpieczeństwa; stabilny rdzeń do porównań trendu. - **Recent failures set**: przypadki z realnych incydentów i reklamacji; aktualizowane cyklicznie. - **Change-impact set**: przypadki dotknięte najnowszą zmianą modelu, promptu lub integracji.
Takie podejście łączy porównywalność z aktualnością i zapobiega sytuacji, w której evals "zaliczają", ale użytkownik nadal widzi regres.
Bramka produkcyjna: kiedy agent jest gotowy do wdrożenia
Playbook evals powinien definiować formalną bramkę go/no-go. Bez niej decyzje wdrożeniowe są podatne na presję terminu i intuicję sponsorów.
Minimalna bramka produkcyjna dla agenta: 1. Spełnione progi correctness na golden secie. 2. Brak krytycznych naruszeń w robustness i safety evals. 3. Potwierdzony wpływ na metryki procesu w środowisku pre-production. 4. Zdefiniowany plan monitoringu online i reakcja na incydenty. 5. Jasno określone warunki human override.
Wdrożenie warunkowe jest dopuszczalne, ale warunki muszą być mierzalne i mieć właściciela.
Monitoring po wdrożeniu: evals online jako system wczesnego ostrzegania
Po uruchomieniu agenta jakość zaczyna żyć własnym życiem. Zmieniają się profile zapytań, sezonowość, zachowania użytkowników i dane źródłowe. Dlatego evals online nie mogą być "ładnym dashboardem", tylko systemem wykrywania odchyleń.
Warto monitorować równolegle: - jakość odpowiedzi: acceptance rate, rework rate, complaint rate, - niezawodność operacyjną: latency, timeouty, błędy narzędzi, - bezpieczeństwo: liczba blokad polityk, eskalacje, wykryte próby nadużyć, - ekonomikę: koszt na zakończone zadanie i koszt na poprawne zakończenie.
Kluczowe jest sprzężenie tych metryk z alarmami i procedurą decyzji: ograniczenie zakresu, rollback konfiguracji, dodatkowy review, czasowe zatrzymanie funkcji.
Jak połączyć evals z human-in-the-loop
System evals nie zastępuje człowieka, tylko mówi, gdzie obecność człowieka jest najbardziej potrzebna. Wysoka dojrzałość operacyjna polega na dynamicznym sterowaniu poziomem nadzoru.
Przykładowy model: - niski poziom ryzyka i wysoka jakość historyczna: automatyzacja z monitoringiem, - średnie ryzyko lub pogorszenie trendu: obowiązkowy sampling review, - wysokie ryzyko lub krytyczny drift: pełna walidacja człowieka przed wykonaniem akcji.
To podejście ogranicza zarówno ryzyko nadmiernej automatyzacji, jak i koszt ręcznej kontroli wszystkiego.
Antywzorce, które psują program evals
powtarza się kilka błędów: - benchmark-driven theater: optymalizacja pod test, a nie pod proces biznesowy, - metryki bez decyzji: dashboard jest pełny, ale nie ma progów i właścicieli reakcji, - brak segmentacji ryzyka: ten sam standard dla zadań niskiego i wysokiego wpływu, - oddzielenie ewaluacji od operacji: zespół jakości nie ma wpływu na release i rollback, - pomijanie kosztu jakości: mierzy się poprawność, ale nie mierzy kosztu osiągnięcia tej poprawności.
Jeśli te antywzorce się utrwalą, organizacja skaluje liczbę agentów szybciej niż zdolność utrzymania jakości.
Model operating cadence dla zespołu i leadershipu
Aby evals nie były jednorazowym projektem, potrzebny jest rytm operacyjny: - codziennie: przegląd sygnałów krytycznych i incydentów, - co tydzień: analiza trendów jakości i kosztu dla kluczowych agentów, - co miesiąc: decyzje o zmianie progów, zakresu automatyzacji i planu remediacji, - kwartalnie: przegląd portfela agentów na poziomie leadershipu.
Ten rytm łączy technikę z zarządzaniem. Zespół widzi, co naprawiać, a leadership widzi, czy organizacja naprawdę zyskuje na agentach AI.
Model kosztu jakości dla agentów AI
W tradycyjnym IT koszt jakości rozumie się często jako koszt testów i kontroli. W przypadku agentów AI obraz jest szerszy, bo koszt błędnej odpowiedzi bywa rozproszony po procesie: dodatkowy kontakt z klientem, ręczne poprawki, opóźnienie decyzji, eskalacja prawna, utrata zaufania.
Dlatego przy projektowaniu evals warto mierzyć co najmniej cztery kategorie: - **cost of prevention**: koszt przygotowania danych testowych, scenariuszy i automatyzacji ewaluacji, - **cost of appraisal**: koszt ciągłego monitoringu, przeglądów jakości i audytów, - **cost of internal failure**: koszt błędów wykrytych przed wpływem na klienta lub proces krytyczny, - **cost of external failure**: koszt błędów, które dotarły do klienta, partnera lub regulatora.
Ten model pozwala pokazać leadershipowi, że inwestycja w evals obniża koszt całkowity jakości, nawet jeśli podnosi krótkoterminowy koszt operacyjny zespołu.
Projektowanie progów decyzyjnych dla różnych klas ryzyka
Jednym z powodów sporów między biznesem a technologią jest brak wspólnego języka progów jakości. Ten sam wynik może być akceptowalny w zadaniu niskiego wpływu i nieakceptowalny w zadaniu regulowanym.
Praktycznie warto stosować macierz progów: - **Klasa A (wysoki wpływ)**: niski tolerowany poziom błędu, obowiązkowy human approval, szybka eskalacja przy regresie. - **Klasa B (średni wpływ)**: umiarkowana tolerancja błędu, sampling review i warunkowa automatyzacja. - **Klasa C (niski wpływ)**: większa automatyzacja, monitoring trendów i cykliczne przeglądy.
Taka segmentacja upraszcza decyzje go/no-go, bo z góry wiadomo, jakie standardy muszą być spełnione przed zwiększeniem skali.
Jak przygotować organizację do audytu jakości agentów
Coraz więcej organizacji musi odpowiadać na pytanie audytora: "jak udowadniacie, że agent działa zgodnie z deklarowanym przeznaczeniem?". Odpowiedź nie może opierać się na pojedynczym raporcie testowym.
Minimalny pakiet audytowy powinien obejmować: - wersjonowany katalog evals i kryteriów akceptacji, - historię zmian modelu, promptów i narzędzi wraz z wynikiem walidacji, - rejestr incydentów jakościowych i działań naprawczych, - dowody działania human-in-the-loop dla klas zadań wysokiego ryzyka.
Taki pakiet zwiększa nie tylko gotowość regulacyjną, ale również wewnętrzną dyscyplinę jakości. Zespół szybciej widzi, które zmiany poprawiają produkt, a które tylko przesuwają problem.
Executive Takeaway
Co się zmieniło? Evals dla agentów AI przechodzą od testu przedwdrożeniowego do ciągłego systemu kontroli jakości, bezpieczeństwa i ekonomiki działania po uruchomieniu. Dlaczego to ważne? Bez połączenia evals offline i online firmy często wdrażają agentów, którzy dobrze wypadają na demie, ale generują rework, ryzyko i niestabilny koszt w produkcji. Co liderzy powinni zrobić? Wdrożyć czterowarstwowy model ewaluacji, formalną bramkę go/no-go oraz operacyjny rytm decyzji oparty na trendach jakości, ryzyka i kosztu.
