Strona główna / Rozdział 6 · Jakość i bezpieczeństwo
Ostatnia zmiana · 7 min czytania
Ewaluacje
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 ludzkuTesty 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.
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
Dane poglądowe: klasyfikator zgłoszeń do działu obsługi, osiem przypadków. Czerwone wiersze to przypadki, które v2 psuje, wyszarzone to te bez istotnej zmiany.
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ę
Jak sprawdzasz, czy system z LLM-em działa i czy zmiana go nie zepsuła?
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.
In English
Build a fixed set of cases from real failures: read traces, name the error types and turn each into a test. Grade with the cheapest method that suffices: exact match, code checks, an LLM judge validated against expert labels, humans. Run every case several times because outputs are random, and compare versions pairwise. The regression set gates every prompt, model and tool change in CI. In production, grade a sample of traffic with a reference-free judge and watch user signals, and feed failures back into the set.
Pytania pogłębiające (5)
- 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.