TL;DR

Evals to nie tradycyjne zapewnienie jakości – wymagają zupełnie innego podejścia niż standardowe testowanie według scenariuszy
Złote zbiory danych mają ograniczenia – działają tylko dla znanych przypadków użycia, nie przewidują nieoczekiwanych danych wejściowych
Problem zimnego startu – na początku stoisz przed dylematem: czekać na prawdziwych użytkowników czy testować na danych syntetycznych
Prawdziwe dane przewyższają dane syntetyczne – najlepsze evals powstają z analizy rzeczywistych interakcji użytkowników
Analiza błędów jest kluczowa – identyfikacja wzorców błędów prowadzi do skutecznych automatycznych testów
Dryfowanie kryteriów wymaga ciągłej uwagi – kryteria oceny ewoluują, więc evals wymagają stałego monitorowania
Discovery wspiera lepsze evals – głębokie zrozumienie klientów stanowi fundament skutecznego testowania AI

Poniższe notatki pochodzą z rozmowy między Teresą Torres a Petrą z podcastu „All Things Product”. Torres, ekspert od customer discovery, dzieli się praktycznymi doświadczeniami z budowy swojego interview coach. Wszystkie przemyślenia, obserwacje i wnioski przedstawione w artykule należą do rozmówców podcastu.

Czym są evals i dlaczego tradycyjne QA nie wystarcza

Torres wyjaśnia, że evals wykraczają daleko poza standardowe zapewnienie jakości. W przeciwieństwie do tradycyjnego QA, gdzie testerzy pracują według przygotowanych scenariuszy, evals muszą jednak radzić sobie z nieprzewidywalnością sztucznej inteligencji.

Problem ujawnia się szybko w praktycznym zastosowaniu. Kiedy Torres budowała swój interview coach, zaczęła wysyłać sobie kopie każdego feedbacku dla studentów. Szybko zauważyła niepokojące wzorce – narzędzie identyfikowało problemy, ale następnie sugerowało rozwiązania, które same w sobie były błędne.

„Czasami coach podkreślał, że student zadał bardzo ogólne pytanie, co było dobre. Potem sugerował, co mogliby zapytać zamiast tego. Czasami te sugerowane pytania były naprowadzające lub ogólne” – opisuje Torres swoje obserwacje.

Problem zimnego startu: jak zacząć bez prawdziwych danych

Pierwszym wyzwaniem, na jakie natrafiają zespoły, jest paradoks zimnego startu. Torres formułuje go dosadnie: „Czy mam czekać na 200 pierwszych użytkowników, żeby zebrać dane do oceny, nie wiedząc, czy dla tych 200 użytkowników mój produkt jest w ogóle dobry?”

Rozwiązaniem tego problemu staje się generowanie danych syntetycznych. Nie chodzi jednak o proste polecenie dla LLM-a. Torres podkreśla, że tworzenie użytecznych danych syntetycznych wymaga głębokiej wiedzy dziedzinowej oraz zdefiniowania kluczowych wymiarów, takich jak:

Różne typy interakcji (np. wywiad ustrukturyzowany vs. luźna rozmowa)
Zmienna długość i złożoność
Różne persony użytkowników (np. rozmowni vs. małomówni)

Dopiero tak przygotowany zbiór danych pozwala na przeprowadzenie pierwszych, sensownych testów przed wdrożeniem produktu do szerszego użytku.

Od złotych zbiorów danych do prawdziwych danych produkcyjnych

Tradycyjne podejście do testowania AI opiera się na złotych zbiorach danych – kolekcjach z określonymi danymi wejściowymi i oczekiwanymi wyjściowymi. Torres wyjaśnia, że pochodzą one ze świata ML, gdzie definiuje się jasne pary input-output.

Prawdziwy problem pojawia się jednak szczególnie z chatbotami. Użytkownik może wpisać dosłownie cokolwiek, więc nawet najdokładniejsze wywiady z klientami ujawnią tylko znane niewiadome. Torres podkreśla fundamentalną słabość tego podejścia.

Nawet generowanie różnorodnych scenariuszy – różne długości wywiadów, różne typy rozmówców – wciąż nie oddawało pełnej rzeczywistości produkcyjnej. W rezultacie dane syntetyczne mogą pomóc na początku, ale mają poważne ograniczenia.

Praktyczne podejście: od analizy błędów do automatycznych testów

Torres opisuje przełomowy moment w swoim podejściu do evals. Zamiast polegać tylko na syntetycznych danych, zaczęła logować prawdziwe interakcje i ręcznie je analizować.

Eksperci ML, jak wyjaśnia Torres, dosłownie patrzą na swoje dane. Logują każde dane wejściowe użytkownika do bazy danych jako przyszły punkt danych do evals. Następnie przeprowadzają szczegółową analizę.

Proces składa się z następujących kroków:

Zbieranie ponad 100 prawdziwych przypadków użycia z produkcji
Ręczna analiza przez ekspertów domenowych (Torres podkreśla konieczność uzyskania zgody na przechowywanie danych)
Identyfikacja najczęstszych wzorców błędów
Budowa automatycznych testów dla każdego typu błędu

Torres zidentyfikowała konkretne wzorce błędów w swoim interview coach, który składał się z ośmiu orchestrowanych wywołań LLM zwracających structured JSON:

Sugerowanie naprowadzających pytań – coach rozumiał koncept, ale popełniał błąd w implementacji
Sugerowanie ogólnych pytań – podobny problem z niewłaściwymi rekomendacjami
Sugerowanie pytań już zadanych – brak świadomości kontekstu rozmowy
Problem orkiestracji – każdy moduł myślał, że cały wywiad powinien dotyczyć jego wymiaru

Dwa typy evals: code-based vs LLM-as-judge

Torres przedstawia praktyczne przykłady implementacji, rozróżniając dwa główne podejścia do automatycznych evals.

LLM-as-judge eval dla naprowadzających pytań działa wieloetapowo. Najpierw system wyciąga wszystkie pytania z odpowiedzi coach. Następnie drugi LLM sprawdza, czy któreś z nich to pytanie naprowadzające. Jeśli tak – test nie przechodzi.

Code-based eval dla ogólnych pytań stanowi znacznie prostsze rozwiązanie. W tej samej liście pytań kod szuka słów takich jak „typically”, „usually”, „generally”. Jeśli je znajdzie – test nie przechodzi.

Torres podkreśla różnicę między podejściami: drugie rozwiązanie to po prostu kod, nie LLM jako sędzia.

Kluczowa obserwacja Torres dotyczy praktycznego zastosowania. Jako product manager może przeprowadzić eksperymenty – zmienić opis naprowadzających pytań w promptach. Decyzja o wypuszczeniu do produkcji zależy jednak od wyników wszystkich evals we wszystkich wzorcach błędów.

Praktyczne techniki promptingu z doświadczeń Torres

Na podstawie swojej pracy Torres dzieli się konkretnymi technikami promptingu, które sprawdzają się w systemach ewaluacji.

Prompt do generowania danych syntetycznych

Zamiast ogólnego polecenia Torres dostarcza modelowi LLM konkretne wymiary, które mają być uwzględnione w generowanych danych. Przy tworzeniu syntetycznych transkrypcji wywiadów instruowała model, by tworzył dane uwzględniające długość wywiadu, styl rozmówcy oraz typ wywiadu.

Kiedy stosować: Na początku projektu, aby stworzyć początkowy złoty zbiór danych do testowania systemu, gdy brakuje jeszcze prawdziwych danych od użytkowników.

Prompt dla LLM-as-judge

Torres wykorzystuje drugi model LLM do oceny wyniku wygenerowanego przez pierwszy model. Prompt musi zawierać jasne kryterium oceny. Po wyodrębnieniu listy pytań z odpowiedzi coacha AI, drugi LLM otrzymywał polecenie: „Oceń poniższą listę pytań. Czy którekolwiek z nich jest pytaniem naprowadzającym? Odpowiedz TAK lub NIE.”

Kiedy stosować: Do automatycznej oceny złożonych, subiektywnych kryteriów, których nie da się łatwo sprawdzić za pomocą prostego kodu.

Technika pre-pending (rozwiązanie problemu JSON/markdown)

Torres dzieli się praktycznym problemem technicznym. Czasami, gdy poprosi się LLM o zwrócenie structured JSON, system zwraca najpierw tick mark (znacznik markdown), co powoduje błędy parsowania.

Rozwiązanie wykorzystuje specyficzną funkcję API Anthropic, która pozwala „zmusić” model do rozpoczęcia odpowiedzi od konkretnego znaku. Ustawienie, że odpowiedź musi zaczynać się od znaku {, eliminuje błędy formatowania.

Kiedy stosować: Gdy wymagany jest bardzo ścisły, ustrukturyzowany format wyjściowy i chcesz zminimalizować błędy formatowania, które mogą powodować awarię systemu.

Evals vs zabezpieczenia: kluczowe rozróżnienie

Torres wprowadza ważne rozróżnienie praktyczne między evals a guardrails (zabezpieczeniami). Zabezpieczenia to uruchomienie ewaluacji w czasie rzeczywistym, zanim odpowiedź trafi do użytkownika. Jeśli system wykryje błąd, może spróbować go naprawić w locie.

Kluczowe różnice:

Evals = testowanie offline, ocena jakości systemu
Zabezpieczenia = ochrona w czasie rzeczywistym przed złymi odpowiedziami

Torres ostrzega przed nadużywaniem zabezpieczeń. Uruchamianie wszystkich evals jako zabezpieczeń wymaga dużych zasobów obliczeniowych i wpływa na wydajność. Ponadto zwiększa opóźnienia i koszty. Dlatego zazwyczaj evals uruchamia się na próbce śladów produkcyjnych.

Ocenianie samych evals i dryfowanie kryteriów

Torres wyjaśnia metaconcepcję – jak oceniać jakość własnych systemów oceny. Aby wiedzieć, czy evals są dobre i poprawnie identyfikują błędy, potrzebne są ślady ocenione przez ludzi. Porównanie automatycznych evals z ocenami ludzi pozwala ocenić same evals i znaleźć ich współczynnik błędów.

Torres wprowadza także kluczową koncepcję dryfowania kryteriów. Nie można po prostu pozwolić evals działać i uważać to za skończone. Z czasem rozumienie tego, jak wygląda „dobre”, ewoluuje.

To oznacza praktyczne konsekwencje:

Zawsze można odkryć nowe wzorce błędów wymagające nowych evals
Sędziowie LLM mogą „odejść” od standardów ludzkich ocen
Potrzebne jest ciągłe porównywanie automatycznych evals z ludzkimi oznaczeniami

Torres podsumowuje naturę ciągłego utrzymania evals porównaniem do ogrodnictwa – nigdy się nie kończy.

Discovery jako fundament skutecznych evals

Torres łączy swoje doświadczenia z evals ze swoją ekspertyzą w customer discovery. Zauważa fundamentalną prawdę: wszystkie kroki procesu evals są tylko tak dobre, jak rozumienie klienta przez zespół.

Torres stawia kluczowe pytania discovery dla zespołów pracujących z AI:

Czy ludzcy oceniający potrafią określić „dobre” odpowiedzi, nie znając oczekiwań klienta?
Czy można wygenerować właściwe dane syntetyczne bez znajomości potrzeb klientów?
W jaki sposób discovery wspiera pisanie promptów, orkiestrację systemu i analizę błędów?

Zrozumienie potrzeb użytkownika okazuje się niezbędne na każdym etapie: od generowania realistycznych danych syntetycznych, przez prawidłowe definiowanie „dobrych” i „złych” odpowiedzi, aż po skuteczną ocenę jakości jako ludzki ekspert.

Dlaczego produkty AI to nie „szybkie zwycięstwa”

Doświadczenia Torres definitywnie obalają mit o szybkich wdrożeniach AI. Petra trafnie podsumowuje sceptycyzm wobec twierdzeń o tworzeniu produktów w godziny.

Torres potwierdza z własnego doświadczenia. Można znacznie szybciej testować pomysły, bo to prototypy nie wymagające uwzględnienia wszystkich aspektów produkcyjnych. Jednak prawdziwe produkty to zupełnie inna sprawa – Torres nadal pracuje nad swoim narzędziem do oceny product leadership, ale nie planuje go wypuszczać do szerokiego użytku.

Praktyczne konsekwencje dla product managerów:

Produkty AI wymagają infrastruktury porównywalnej do tradycyjnych produktów plus dodatkowa warstwa evaluacji
Konieczność zatrudnienia ludzi do ręcznego oznaczania danych na stałe – to nie jednorazowy koszt konfiguracji
Discovery staje się jeszcze bardziej krytyczne – bez zrozumienia klientów niemożliwe jest zbudowanie skutecznych evals

Lista kontrolna: Implementacja evals w produkcie AI

Faza przygotowania:

Zdefiniuj jasno, czym są „dobre” dane wyjściowe dla Twojego AI
Przeprowadź discovery – zrozum oczekiwania użytkowników
Stwórz początkowy złoty zbiór danych z danymi syntetycznymi
Zaimplementuj logowanie wszystkich interakcji użytkownik-AI

Faza zbierania prawdziwych danych:

Uruchom produkt w ograniczonym zakresie (beta/pilot)
Zbierz minimum 100 prawdziwych przypadków użycia
Przeprowadź ręczną analizę przez ekspertów domenowych
Porównaj oznaczenia w zespole – upewnij się o spójności kryteriów

Faza identyfikacji wzorców błędów:

Zidentyfikuj najczęstsze wzorce błędów (minimum 3-5)
Sklasyfikuj każdy wzorzec według częstości występowania
Zdecyduj, które błędy można naprawić promptami, a które wymagają evals
Udokumentuj każdy wzorzec błędów z konkretnymi przykładami

Faza budowy automatycznych evals:

Dla każdego wzorca błędów zdecyduj: code-based czy LLM-judge
Zaimplementuj automatyczne testy dla każdego typu błędu
Przetestuj evals na oznaczonym zbiorze danych
Zmierz korelację automatycznych evals z ludzkimi ocenami

Faza produkcyjna i monitoring:

Uruchom evals na próbce ruchu produkcyjnego (np. 10%)
Ustaw monitoring i alerty dla spadków jakości
Zaplanuj regularny przegląd nowych wzorców błędów (co miesiąc)
Przewidź budżet na ciągłe oznaczanie nowych przypadków

Ciągłe utrzymanie przeciw dryfowaniu kryteriów:

Co kwartał: sprawdź, czy evals wciąż korelują z ludzkimi ocenami
Co pół roku: przeprowadź pełen audit ewolucji kryteriów
Ciągłe: utrzymuj potok danych do zbierania informacji zwrotnej od użytkowników końcowych
Zawsze: bądź gotowy na odkrycie nowych typów błędów wymagających nowych evals

Kluczowe spostrzeżenie

Przestań naprawiać prompt, zacznij audytować błędy

Standardowo myślimy: Kiedy AI daje złą odpowiedź, musimy natychmiast poprawić główny prompt, żeby rozwiązać problem u źródła. Cała nasza energia skupia się na inżynierii promptów.

W praktyce okazuje się, że: Największą dźwignię daje systematyczne analizowanie błędnych odpowiedzi, identyfikowanie ich powtarzalnych wzorców, a następnie budowanie osobnych systemów (innych LLM-ów lub kodu) do automatycznego wykrywania tych konkretnych błędów.

Dlaczego to jest istotne: Zmienia to pracę z chaotycznej gry w „łapanie kretów” w pojedynczym prompcie na metodyczne budowanie systemu zapewniania jakości, który skaluje się wraz z produktem.

Test na jutro: Następnym razem gdy Twój system AI wygeneruje błędną odpowiedź, zamiast od razu edytować główny prompt, zapisz ten błąd w arkuszu. Kiedy zbierzesz 5-10 podobnych błędów, zadaj sobie pytanie: „Jak mógłbym napisać prosty test, który automatycznie wykryłby tylko ten jeden typ błędu?”.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj All Things Product z Teresą Torres i Petrą.

Tag: Llm As Judge

Dlaczego testowanie produktów AI to nie jest zwykłe QA – lekcje od Teresy Torres #EN289