Każdy, kto wdrożył aplikację LLM na produkcji, zna ten widok: demo działa świetnie, stakeholderzy są zachwyceni, pierwsze odpowiedzi wyglądają przekonująco. A potem przychodzi klient z pytaniem, którego nie testowaliście, i model odpowiada z pewnością eksperta coś, co jest po prostu nieprawdą. Albo po aktualizacji promptu odkrywacie, że edge case, który wcześniej działał, przestał działać. Nie wiadomo kiedy. Nie wiadomo dlaczego.
Problem nie tkwi w modelu. Problem tkwi w braku pomiaru. Ten artykuł jest o tym, jak zbudować infrastrukturę eval, która powie wam — z liczbami, nie z odczuciem — czy wasza aplikacja LLM jest lepsza czy gorsza niż wczoraj.
Dlaczego „wygląda dobrze" to nie metrika
W tradycyjnym oprogramowaniu macie testy jednostkowe, testy integracyjne, CI pipeline. Przed każdym merge wiecie, czy coś przestało działać. Wyniki LLM są probabilistyczne — ten sam input może dać nieco inny output, a błędna odpowiedź nie wywoła wyjątku. Awaria jest cicha.
Zespoły bez procesu eval polegają na trzech osobach, które raz na jakiś czas klikają przez aplikację i mówią „wydaje się OK". To działa do pierwszych 200 użytkowników. Potem przestrzeń use-case'ów rozrasta się, modele się zmieniają, prompty się modyfikują — i nikt nie wie, co właśnie się zepsuło.
Eval (ewaluacja) to systematyczny pomiar jakości wyników LLM w odniesieniu do zdefiniowanych kryteriów. Nie jednorazowo, lecz jako ciągły proces: przed deploymentem, po każdej zmianie promptu, po każdym upgrade'ie modelu, regularnie na produkcji.
Trzy typy evalów — gdzie każdy należy
Zanim przejdziemy do narzędzi, ważne jest rozróżnienie trzech różnych kontekstów, w których eval przebiega:
Offline eval — uruchamiacie przed deploymentem na stałym datasecie. Odpowiedź otrzymujecie szybko i reprodukowalnie. Odpowiedni do testów regresyjnych w CI/CD.
Online eval — działa na produkcji na realnych zapytaniach, zazwyczaj na próbce. Wykrywa dryft dystrybucyjny: realni użytkownicy zachowują się inaczej niż scenariusze testowe.
Fine-tuning eval — specyficzny przypadek, gdzie mierzycie, czy douczony model jest lepszy niż model bazowy na docelowych zadaniach. Opisuje go osobny artykuł (Jak mierzyć, czy fine-tuning pomógł). Tutaj nie należy.
RAG eval — mierzy faithfulness (czy model odpowiadał zgodnie z tym, co miał do dyspozycji?), answer relevancy i context recall. Standardem jest framework RAGAS, opisany w artykule Jak ewaluować RAG (RAGAS). Tutaj również nie należy.
Ten artykuł koncentruje się na offline i online eval dla produkcyjnej aplikacji LLM — chatbota, copilota, agenta.
Jak zbudować eval set z realnych przypadków
Najczęstszy błąd: eval set tworzy inżynier AI podczas weekendowego burzy mózgów. Wynik pokrywa to, co jego zdaniem są edge case'y — nie to, o co realni użytkownicy faktycznie pytają.
Właściwy sposób postępowania:
- 1.Zbierajcie realne logi od pierwszego dnia. Każde zapytanie i każdą odpowiedź logujcie (z anonimizacją PII). To jest wasz złoty fundusz.
- 2.Identyfikujcie awarie. Pierwsze 200–500 realnych interakcji przejrzyjcie ręcznie. Gdzie model odpowiedział źle? Gdzie odmówił odpowiedzi, choć powinien był jej udzielić? Gdzie był niepotrzebnie niejasny?
- 3.Kategoryzujcie awarie według typu. Przykłady kategorii: halucynacja faktu, błędna odmowa, nieprawidłowy format odpowiedzi, odpowiedź trafna lecz niekompletna, obejście zabezpieczeń.
- 4.Z każdej kategorii wybierajcie reprezentatywne przypadki. Minimalna złota próbka (golden set): 100–300 przykładów z poprawną odpowiedzią lub kryterium oceny. Dla systemu produkcyjnego: 500–1 000+ przypadków.
- 5.Każdy przykład opatrzcie ground truth lub rubryką. Dla prostych przypadków: odpowiedź referencyjna lub oczekiwany wynik. Dla złożonych przypadków: rubryka (zestaw kryteriów, które odpowiedź musi spełniać).
Złoty set nie jest statyczny. Co miesiąc dodawajcie nowe awarie z produkcji. Stary set, którego nie aktualizujecie, przestaje odzwierciedlać realne zachowania użytkowników.
Metryki — precyzyjne, gdy macie referencję
Dla jednoznacznych zadań (ekstrakcja, klasyfikacja, ustrukturyzowany wynik) sprawdzają się deterministyczne metryki:
- Exact match — wynik albo pasuje do referencji, albo nie. Odpowiedni dla ekstrakcji encji, klasyfikacji klas, schematu JSON.
- F1 score — mierzy pokrycie tokenów między wynikiem a referencją. Odpowiedni tam, gdzie istnieje wiele poprawnych sformułowań.
- BLEU / ROUGE — standardowe dla tłumaczenia i sumaryzacji. W praktyce rzadko stosowane dla ogólnych aplikacji LLM, lepsze dla konkretnych zadań NLP.
Te metryki są szybkie, tanie, deterministyczne. Ale zawodzą dla większości produkcyjnych use-case'ów, gdzie „poprawna odpowiedź" może mieć dziesiątki sformułowań.
LLM-as-judge — siła i ograniczenia
Dla otwartych zadań — gdzie odpowiedź referencyjna nie istnieje lub jest zbyt zmienna — wkracza LLM-as-judge: inny LLM (większy lub równie silny) ocenia wynik według rubryki.
Dlaczego to działa? Modele klasy GPT-4 osiągają około 85 % zgodności z ludzkimi recenzentami, co jest wyższą spójnością niż typowa zgodność człowiek–człowiek (około 81 %) na tych samych zadaniach. Przy 500–5 000× niższych kosztach niż ludzka anotacja.
Ale LLM-as-judge ma pięć udokumentowanych biasów, które musicie aktywnie kompensować:
1. Position bias — judge preferuje odpowiedź, która jest pierwsza (lub ostatnia) w kolejności. Rozwiązanie: zawsze porównujcie z odwróconą kolejnością (A vs B → następnie B vs A) i używajcie głosowania większościowego.
2. Verbosity bias — dłuższa odpowiedź wydaje się bardziej przekonująca, nawet jeśli jest mniej precyzyjna. Bezpośrednia konsekwencja tego, jak modele były trenowane na human feedback. Rozwiązanie: w rubryce wyraźnie penalizujcie niepotrzebną długość.
3. Self-preference bias — model preferuje własne wyniki. Claude v1 wykazywał około 25 % wyższy win rate dla własnych odpowiedzi przy self-ocenie; GPT-4 około 10 %. Rozwiązanie: nigdy nie używajcie tego samego modelu zarówno jako producenta, jak i judge'a.
4. Format bias — odpowiedzi z markdown, punktami lub ładną strukturą dostają wyższe wyniki. Rozwiązanie: rubryka ocenia treść, nie prezentację.
5. Calibration drift — podczas długich ocen wsadowych judge staje się albo zbyt pobłażliwy, albo zbyt surowy. Rozwiązanie: do batcha zawsze wstawiajcie kilka przykładów kalibracyjnych ze znanym wynikiem i śledźcie dryft.
Praktyczna zalecana struktura wywołania LLM-as-judge:
- Prompt systemowy: rola judge'a, lista wymiarów oceny, skala numeryczna (np. 1–5 na wymiar)
- Prompt użytkownika: kontekst pytania, odpowiedź do oceny, rubryka z definicjami każdego wyniku
- Przykłady few-shot: 3–5 dobrze ocenionych i 3–5 źle ocenionych przykładów (zwiększają spójność z około 65 % do około 77 %)
Zgodność judge'a z ludzkimi recenzentami: jeśli mierzycie i osiągacie 75 %+, macie użyteczny sygnał. Poniżej 65 % judge produkuje więcej szumu niż informacji — czas przebudować rubrykę.
G-Eval i ocenianie DAG
Nowoczesne frameworki eval, takie jak DeepEval, implementują podejścia wykraczające poza proste „daj ocenę 1-5":
G-Eval — judge najpierw generuje procedurę oceniającą (kroki chain-of-thought), a następnie według niej przyznaje punkty. Zmniejsza arbitralność oceniania.
DAG scoring — rozkłada ocenianie w drzewo warunków. Zamiast „czy to dobre?" przechodzi przez: „czy jest faktycznie poprawne?" → jeśli tak: „czy jest kompletne?" → jeśli tak: „czy jest bezpieczne?". Każdy węzeł może być inną metryką lub wywołaniem LLM-as-judge.
Dla systemów produkcyjnych zalecamy kombinację: deterministyczne metryki dla tego, co można mierzyć obiektywnie, plus LLM-as-judge dla wymiarów takich jak koherencja, ton, kompletność.
Testy regresyjne w CI przed każdym release'em
Oto praktyczny workflow, który polecamy klientom:
- 1.Golden set w repozytorium — eval dataset jest częścią kodu, wersjonowany w gicie razem z promptami.
- 2.Krok eval w CI — przed każdym merge do main uruchamiacie eval pipeline. Jeśli łączny wynik spadnie o więcej niż zdefiniowany próg (np. 3 punkty procentowe), merge jest blokowany.
- 3.Testy specyficzne dla regresji — do każdej wykrytej awarii z produkcji dodajcie test case. Raz wykryty błąd nie może cicho powrócić.
- 4.Oddzielne środowisko eval — eval pipeline nie wywołuje tego samego modelu/endpointu co produkcja. Izolacja zapobiega temu, by eval wpływał na logi produkcyjne.
- 5.Wyniki widoczne — nie tylko pass/fail. Każdy PR zawiera eval diff: które metryki się poprawiły, które spadły, o ile.
DeepEval jest de facto standardem dla CI/CD gating — integruje się jako plugin pytest, eksport do JUnit XML dla CI, gating oparty na progach. Dla dashboardów stakeholderów i traceability produkcyjnej uzupełnia go Braintrust.
Online eval — co umyka testom offline
Offline eval powie wam, czy wasza aplikacja działa na znanych przykładach. Nie powie wam, czy realni użytkownicy napotkają coś nowego.
Online eval typowo działa na 5–10 % produkcyjnych zapytań (sampling ze względu na koszty). Szukacie:
- Dryft dystrybucyjny — użytkownicy pytają o rzeczy, których nie ma w golden secie. Śledźcie kategorie, gdzie judge konsekwentnie punktuje nisko.
- Anomalie — odpowiedzi, które są nieoczekiwanie krótkie lub długie, mają niską spójność przy powtórzonym uruchomieniu lub zawierają wzorce bezpieczeństwa.
- Trade-off latencja vs. jakość — szybszy model może być gorszy w konkretnych kategoriach.
Dane online eval regularnie spływają z powrotem do golden setu. Cykl: produkcja → awarie → golden set → testy CI → deployment.
Odróżnienie od fine-tuning eval i RAG eval
Ludzie często mieszają te trzy typy evalów:
Fine-tuning eval — mierzy, czy douczony model wykonuje to, do czego był douczany. Porównuje model bazowy z fine-tuned na task-specific datasecie. Nie należy do CI pipeline aplikacji produkcyjnej — to jednorazowy (lub per-run) eksperyment przed rejestracją modelu. Więcej w artykule Jak mierzyć, czy fine-tuning pomógł.
RAG eval (RAGAS) — mierzy pipeline RAG: faithfulness (czy model cytuje tylko to, co miał w kontekście?), answer relevancy, context precision i recall. Narzędzie RAGAS dostarcza 8 specyficznych metryk. To dodatkowa warstwa — oceniacie retrieval i generation oddzielnie. Więcej w Jak ewaluować RAG (RAGAS).
Produkcyjny LLM eval (ten artykuł) — mierzy jakość end-to-end z perspektywy użytkownika. Nie interesuje was, czy model poprawnie zacytował dokument; interesuje was, czy odpowiedź była użyteczna, bezpieczna i zgodna z kryteriami biznesowymi.
EU AI Act i eval jako obowiązek prawny
Od 2 sierpnia 2026 obowiązuje pełna stosowalność EU AI Act. Dla firm wdrażających systemy LLM w kategoriach wysokiego ryzyka (ochrona zdrowia, infrastruktura krytyczna, HR, edukacja) dokumentacja eval staje się obowiązkiem prawnym.
Konkretnie: dla systemów wysokiego ryzyka AI Act wymaga udokumentowanego i ciągłego zarządzania ryzykiem, w tym testowania i walidacji, monitorowania wskaźników halucynacji, wzorców bias i ryzyka prompt injection. Kary za najpoważniejsze naruszenia sięgają 35 milionów euro lub 7 % globalnego rocznego obrotu.
Praktyczna implikacja: jeśli eval robicie ad hoc w dokumencie Notion, nie spełniacie wymagania. Potrzebujecie audit trail — wersja promptu, wersja modelu, data uruchomienia eval, wyniki, kto zatwierdził deployment. Precyzyjne techniczne wymagania dotyczące formatu dokumentacji nie są jeszcze ustandaryzowane na poziomie aktów wykonawczych, ale kierunek jest jasny: bez traceability nie ma compliance.
Najczęstsze pytania
Jak duży golden set potrzebuję na początku?
Na pierwsze wdrożenie wystarczy 100–200 przykładów z realnych interakcji. Ważniejsza od wielkości jest reprezentatywność — pokrycie głównych kategorii awarii, nie tylko „typowych" zapytań. Wraz z rosnącym wolumenem produkcji golden set rośnie organicznie: co miesiąc dodajecie dziesiątki nowych przypadków z awarii.
Czy mogę używać tego samego modelu jako producenta i LLM judge'a?
Nie. Self-preference bias jest dobrze udokumentowany — modele konsekwentnie oceniają własne wyniki lepiej niż alternatywy. Jeśli produkujecie wyniki Claudem, oceniajcie je klasą GPT-4 i odwrotnie. Dla stacku open-weight: produkcja na Llama, judge na Qwen lub DeepSeek.
Ile kosztuje LLM-as-judge na produkcji?
Zależy od modelu i wolumenu. Orientacyjnie: przy 1 000 zapytaniach dziennie i sampling rate 10 % wykonujecie 100 wywołań judge'a na dzień. Z modelem frontier (input 2–5 USD, output 12–25 USD za milion tokenów) koszty przy typowym krótkim prompcie judge'a są rzędu kilku dolarów dziennie. Znacznie mniej niż równoważna ludzka anotacja.
Co robić, gdy LLM judge nie jest spójny?
Pierwszy krok: dodajcie przykłady few-shot do promptu judge'a — 3–5 dobrze i 3–5 źle ocenionych przypadków z wyjaśnieniem. Spójność powinna wzrosnąć. Jeśli nie, problem tkwi w rubryce: kryteria są zbyt niejasne lub wzajemnie się nakładają. Przepiszcie je na konkretne, mierzalne warunki. Cel: zgodność judge'a z ludzkimi recenzentami powyżej 75 %.
Czy mogę w pełni zautomatyzować eval bez ludzkiej kontroli?
Dla większości use-case'ów tak, ale z wyjątkiem. Dla systemów high-stakes (medycyna, prawo, finanse) powinien być co najmniej miesięczny ręczny przegląd próbki wyników. LLM judge ma martwe punkty — przede wszystkim dla subtelnych błędów faktycznych w dziedzinach specjalistycznych, gdzie brakuje mu wiedzy domenowej. Automatyzacja redukuje wolumen pracy, ale nie zastąpi eksperckiej oceny przy krytycznych decyzjach.
*Jeśli nie jesteście pewni, gdzie wasza aplikacja LLM faktycznie zawodzi — a większość zespołów nie jest tego pewna — pierwszy krok jest prosty: zajrzyjcie do logów i znajdźcie pięć najgorszych odpowiedzi z ostatniego miesiąca. Od tego zaczyna się każdy dobry program eval. Chętnie pomożemy wam skonfigurować cały proces — od golden setu przez CI gating aż po monitoring produkcyjny.*