## Ewaluacje

*Jakość i bezpieczeństwo*

*Ostatnia zmiana: 28 września 2026*

Wynik LLM-a jest losowy i czuły na drobne zmiany promptu, więc „sprawdziłem na trzech przykładach” nic nie znaczy. Ewaluacja to stały zestaw przypadków z automatyczną oceną, puszczany po każdej zmianie promptu, modelu i narzędzi, plus pomiar jakości na ruchu produkcyjnym.

**Po ludzku:** Testy w CI dla kodu, który za każdym razem odpowiada trochę inaczej. Zamiast „przeszedł albo nie” liczysz, ile razy na pięć przeszedł, a części asercji nie da się zapisać jako porównania napisów, więc sprawdza je drugi model, którego najpierw sam sprawdzasz.

*Interaktywny widżet na stronie: Poprawiony prompt v2 podnosi wynik z 5 do 7 na 8. Sprawdź w tabeli, co ta liczba ukrywa, potem włącz pięć powtórzeń każdego przypadku i zobacz, która zmiana była szumem.*

### Zestaw testowy i metody oceny

- Zaczynasz od analizy błędów, nie od metryk: czytasz 50–100 trace’ów, notujesz każdy problem, grupujesz notatki w typy pomyłek i liczysz je. Najczęstsze typy mówią, co naprawić i co testować. Husain i Shankar przeznaczają na analizę błędów i ewaluację 60–80% czasu pracy, głównie na czytanie danych, a nie na automatyczne testy.
- Zestaw, czyli golden set, budujesz z tych błędów, nie z wyobraźni: każdy typ zamieniasz w kilka przypadków z oczekiwanym wynikiem albo kryterium oceny. Anthropic radzi zacząć od 20–50 zadań. Każdy błąd z produkcji dopisujesz jako nowy przypadek, a do tego przypadki brzegowe i pytania bez odpowiedzi.
- Dopóki nie masz ruchu, zasilasz zestaw przypadkami syntetycznymi: wypisujesz wymiary zapytania (typ użytkownika, intencja, trudność), kilka kombinacji piszesz ręcznie, model je rozmnaża i zamienia każdą w realistyczne wejście, a ty czytasz trace’y, które z nich powstały. Syntetyczne przypadki nie powiedzą, jak częsty jest błąd, wychodzą czystsze niż zapytania prawdziwych użytkowników i gubią niuanse wąskich dziedzin i rzadkich języków, więc zastępujesz je prawdziwymi trace’ami, gdy pojawi się ruch.
- Nie każdy błąd potrzebuje automatycznej oceny. Najpierw naprawiasz oczywiste luki, na przykład brakującą instrukcję w prompcie, a automatyczną ocenę dodajesz tylko dla błędów, które zostają: sędzia-LLM kosztuje czas na zbudowanie i walidację oraz pieniądze przy każdym uruchomieniu.
- Red-teaming to celowy zestaw ataków: ludzie albo model-atakujący próbują złamać system przez prompt injection, jailbreaki, prośby niezgodne z zasadami i wyciąganie danych. Trzymasz go osobno od ewaluacji jakości, raportujesz odsetek udanych ataków i puszczasz przy każdym wydaniu (temat „Prompt injection”).
- Oceniasz najtańszą metodą, która wystarczy do sprawdzenia kryterium: dokładne dopasowanie, schemat albo regex, test w kodzie (uruchom, sprawdź stan), model jako sędzia, człowiek. Jedno kryterium na ocenę i wynik tak/nie zamiast skali 1–10, bo skalę każdy oceniający, także model, stosuje inaczej. Gotowe metryki, jak „helpfulness”, BERTScore czy ROUGE, pomijasz: mierzą coś innego niż twoje błędy i dają fałszywe poczucie jakości.
- Sędziego-LLM sprawdzasz na ludzkich ocenach, zanim zaufasz jego liczbom. Sama zgodność myli: gdy 90% odpowiedzi jest dobrych, sędzia, który wszystko przepuszcza, zgadza się w 90% przypadków i nie łapie żadnego błędu. Dlatego ekspert ocenia 100–200 przykładów, a ty mierzysz osobno, jaką część błędów sędzia łapie (TPR) i jaką część dobrych odpowiedzi przepuszcza (TNR), prompt sędziego poprawiasz na jednej części ocen, a sprawdzasz na drugiej. Znane skrzywienia: sędzia woli odpowiedź pokazaną jako pierwszą, dłuższą i we własnym stylu (Zheng i in., 2023). Wersję sędziego przypinasz, a po jej zmianie kalibrujesz od nowa.
- System oceniasz po kawałkach i w całości. W RAG osobno wyszukiwanie (recall@k, czyli jaka część właściwych fragmentów jest w pierwszych k wynikach) i generowanie (wierność fragmentom, temat „RAG”). W agencie oceniasz stan końcowy, a nie sztywną sekwencję kroków, plus twarde ograniczenia na trace’ie: żadnych zakazanych wywołań narzędzi ani naruszeń zasad, limity tur i kosztu. W długiej rozmowie albo przebiegu agenta szukasz pierwszego błędu, bo późniejsze zwykle z niego wynikają.

### Szum i powtórzenia

- Ten sam przypadek raz przechodzi, raz nie, nawet przy temperaturze 0: obliczenia na serwerze dają nieco inne liczby zależnie od rozmiaru batcha, a ten zmienia się z obciążeniem. Każdy przypadek puszczasz kilka razy i liczysz odsetek.
- Mała próbka to duży szum. Przy 50 przypadkach i wyniku ok. 80% przedział ufności 95% ma ok. ±11 punktów procentowych, więc różnica 3 punktów między promptami nic nie znaczy. Pomaga porównanie w parach, na tych samych przypadkach, i patrzenie na przypadki, które zmieniły wynik, a nie tylko na średnią (Miller, „Adding Error Bars to Evals”, 2024).
- Agenta opisują dwie miary. pass@k: czy zrobi zadanie choć raz na k prób, co ma sens, gdy wynik da się sprawdzić i wybrać, np. kod z testami. pass^k: czy zrobi je we wszystkich k próbach, czyli niezawodność, której oczekuje użytkownik. Przy 90% sukcesu w pojedynczej próbie pass@3 to 99,9%, a pass^3 tylko 73%. W τ-bench (2024) GPT-4o miał pass^8 poniżej 25% w obsłudze klienta sklepu.

### Ewaluacje offline, bramka w CI i pomiar na produkcji

- Offline trzymasz dwa rodzaje zestawów. Ewaluacje możliwości zaczynają od niskiego wyniku i pokazują, czy zmiana przybliża cel. Ewaluacje regresji trzymają ok. 100% i łapią to, że coś, co działało, przestało. Zestaw, który zawsze daje 100%, nie mówi nic o postępie, więc dokładasz trudniejsze przypadki.
- Zestaw regresji to bramka w CI. Uruchamiasz go przy każdej zmianie promptu, modelu, definicji narzędzi i konfiguracji wyszukiwania, bo każda zmienia zachowanie. W pull requeście szybki podzbiór z ocenami w kodzie, pełny zestaw z sędzią-LLM co noc albo przed wydaniem. Bramka blokuje, gdy przypadek krytyczny zaczyna padać albo wynik spada poniżej progu z marginesem na szum, i pilnuje też kosztu i opóźnienia.
- Na produkcji guardrail blokuje albo poprawia odpowiedź, zanim zobaczy ją użytkownik, więc musi być szybki i precyzyjny; oceniający mierzy jakość po fakcie. Oczekiwanych odpowiedzi nie ma, więc mierzysz inaczej: sędzia bez wzorca na próbce ruchu (wierność źródłom, format, bezpieczeństwo), sygnały z zachowania (poprawki użytkownika, ponowienia, eskalacje do człowieka, oceny kciukiem) i testy A/B albo canary przy zmianie modelu. Stały zestaw puszczany cyklicznie na przypiętej wersji wykrywa zmiany po stronie dostawcy (temat „Czy model głupieje?”). Nieudane trace’y z produkcji wracają do zestawu offline.
- Publiczne rankingi mówią, który model warto sprawdzić, a nie czy zadziała u ciebie: mierzą cudze zadanie, ich pytania często wyciekły do danych treningowych, a wyniki szybko dochodzą do sufitu.

### Sprawdź się

**Pytanie:** Jak sprawdzasz, czy system z LLM-em działa i czy zmiana go nie zepsuła?

**Krótka odpowiedź:** Zbuduj stały zestaw przypadków z prawdziwych błędów: czytaj trace’y, nazwij typy pomyłek i każdy zamień w test. Oceniaj najtańszą wystarczającą metodą: dopasowanie, test w kodzie, sędzia-LLM sprawdzony na ocenach eksperta, człowiek. Każdy przypadek puszczaj kilka razy, bo wynik jest losowy, a wersje porównuj w parach. Zestaw regresji jest w CI bramką dla każdej zmiany promptu, modelu i narzędzi. Na produkcji oceniaj próbkę ruchu sędzią bez wzorca i patrz na sygnały użytkowników, a nieudane przypadki wracają do zestawu.

### Pytania pogłębiające

- **Jak zacząć, gdy nie masz jeszcze zestawu testowego?** Od analizy błędów na 50–100 prawdziwych przykładach: czytasz odpowiedzi, nazywasz typy pomyłek i z nich robisz przypadki testowe. Na start wystarczy 20–50 przypadków, byle z prawdziwych porażek.
- **Kiedy ufać modelowi jako sędziemu?** Gdy jego oceny zgadzają się z oceną eksperta na próbce kontrolnej, liczone osobno dla dobrych i złych odpowiedzi. Sędzia, który wszystko przepuszcza, też ma wysoką trafność, gdy dobrych odpowiedzi jest większość. Daj mu jedno kryterium i ocenę tak/nie, a w porównaniu dwóch odpowiedzi zamieniaj ich kolejność.
- **Jak ustawić bramkę w CI, żeby nie blokowała przez szum?** W bramce trzymasz stabilne przypadki regresji z wynikiem bliskim 100% i puszczasz każdy kilka razy. Blokujesz, gdy przypadek krytyczny wyraźnie spada albo średnia spada o więcej niż margines szumu. Niestabilne przypadki, które bez żadnej zmiany raz przechodzą, a raz nie, przenosisz do kwarantanny i badasz, zamiast luzować próg.
- **Jak ewaluować agenta?** Testem stanu końcowego, a nie podsumowaniem agenta, każde zadanie kilka razy, z pass^k jako miarą niezawodności. Do tego koszt, liczba tur i czas na zadanie. Trace’y pokazują, gdzie agent błądzi. Ścieżki nie oceniasz sztywno, bo do celu prowadzi kilka dróg, ale sprawdzasz w niej zakazane wywołania i naruszenia zasad.
- **Chcesz przejść na tańszy model. Jak podjąć decyzję?** Ten sam zestaw na obu modelach, w parach i z powtórzeniami, z osobnym wynikiem dla każdego typu przypadku, plus koszt i opóźnienie. Potem canary albo shadow na części ruchu i porównanie sygnałów z produkcji. Prompt często trzeba dostroić pod nowy model, więc porównujesz modele, każdy z najlepszym dla niego promptem.

### Źródła

- [Hamel Husain: Your AI Product Needs Evals](https://hamel.dev/blog/posts/evals/)
- [Hamel Husain, Shreya Shankar: AI Evals, Everything You Need to Know (dane syntetyczne, walidacja sędziego)](https://hamel.dev/blog/posts/evals-faq/)
- [Anthropic: Demystifying evals for AI agents (2026)](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
- [Evan Miller: Adding Error Bars to Evals (arXiv, 2024)](https://arxiv.org/abs/2411.00640)
- [Zheng i in.: Judging LLM-as-a-Judge (arXiv, 2023)](https://arxiv.org/abs/2306.05685)

Strona interaktywna: https://howaiworks.dev/pl/evals/