Jak budować ewaluacje AI krok po kroku – notatki z webinaru Amana Khana #EN258

TL;DR

• Cztery typy ewaluacji AI: code-based (binary), oceny ludzkie, LLM as judge, opinie użytkowników
• PM musi być osobiście zaangażowany – głównym zadaniem PM-a w erze AI jest posiadanie i egzekwowanie osądu co do idealnego doświadczenia użytkownika
• Skalowanie stopniowe: 5-10 przykładów na start → 100+ przed produkcją → test na 1% ruchu
• Iteracyjny proces: około 20 cykli prompt-test-improve przed zadowalającymi rezultatami
• Wzorcowy zbiór danych w arkuszach to podstawa – bez tego reszta ewaluacji będzie kiepska
• LLM as judge wymaga weryfikacji przez ludzkie oceny, by sprawdzić współczynnik zgodności
• Konkretne narzędzia: Anthropic console do promptów, arkusze do ewaluacji, platformy do skalowania

Dlaczego ewaluacje AI to kluczowa umiejętność dla PM-ów

Khan zauważa, że CPOs największych firm AI wprost zalecają stosowanie ewaluacji. Powód jest prosty – modele językowe halucynują, co wszyscy obserwują w codziennym użytkowaniu.

Autor webinaru podkreśla ironię tej sytuacji, wskazując, że ludzie sprzedający technologię LLM jednocześnie ostrzegają przed koniecznością sprawdzania jej odpowiedzi. Problem nie ma charakteru teoretycznego – bez odpowiednich ewaluacji halucynacje mogą negatywnie wpłynąć na reputację firmy i jej wyniki biznesowe.

Khan idzie jednak o krok dalej, twierdząc, że głównym zadaniem PM-a w erze AI jest posiadanie i egzekwowanie osądu co do tego, jak powinno wyglądać idealne doświadczenie użytkownika. Właśnie dlatego ewaluacja stanowi kluczowe narzędzie do realizacji tej wizji.

Cztery filary ewaluacji AI w praktyce

Khan wyróżnia cztery główne typy ewaluacji, które regularnie spotyka w pracy z firmami:

Code-based evaluations stanowią binarne testy typu pass/fail. Najprostszym przykładem jest sprawdzanie, czy agent United Airlines nie poleca rezerwacji lotów konkurencyjnej linii Delta.

Oceny ludzkie wymagają bezpośredniego zaangażowania PM-ów lub ekspertów merytorycznych. „Product manager musi być w arkuszach kalkulacyjnych i osobiście przeprowadzać te oceny” – podkreśla Khan.

LLM as judge to obecnie najbardziej popularna metoda skalowania ewaluacji. Model trenuje się w ten sposób, aby oceniał odpowiedzi podobnie jak człowiek.

Opinie użytkowników reprezentują metryki biznesowe z rzeczywistego świata. Są to informacje zwrotne od prawdziwych użytkowników i klientów końcowych.

Praktyczny przewodnik: customer support bot dla On running shoes

Khan i Peter demonstrują konkretny przepływ pracy na przykładzie bota obsługi klienta dla marki On. Proces obejmuje kilka kluczowych etapów, które systematycznie prowadzą od pierwszego promptu do gotowego rozwiązania.

Etap 1: Tworzenie skutecznego promptu

Narzędzie Anthropic oferuje funkcję „generate”, która wspiera tworzenie promptów zgodnych z najlepszymi praktykami. Khan wprowadza trzy podstawowe zmienne:

• User question – pytanie od użytkownika
• Product information – katalog produktów On
• Policy information – zasady zwrotów i polityki firmy

System automatycznie generuje strukturę z symbolami zastępczymi w nawiasach klamrowych. Dodatkowo dodaje przykładowe interakcje pokazujące oczekiwany sposób odpowiadania bota.

Etap 2: Definiowanie kryteriów oceny

Khan proponuje trzy główne wymiary oceny dla systemu obsługi klienta:

• Product knowledge – znajomość produktów firmy przez bota
• Policy compliance – przestrzeganie zasad i polityk
• Tone – ton odpowiedzi (formalny vs przyjazny)

Każdy wymiar można oceniać w skali: dobry, średni lub zły. Definicje poszczególnych kategorii zespół ustala wspólnie poprzez dyskusję.

Etap 3: Wzorcowy zbiór danych – fundament procesu

Khan jednoznacznie stwierdza: „Jeśli wzorcowy zbiór danych jest słaby, reszta ewaluacji będzie kiepska.” Arkusze kalkulacyjne stanowią podstawę całego procesu.

W prezentowanym przykładzie testują pytanie: „Kupiłem CloudMonster 2 miesiące temu, ale teraz chcę je zwrócić.”

Bot odpowiada poprawnie pod względem polityki firmy (przekroczony 30-dniowy okres zwrotów), jednak odpowiedź okazuje się za długa i zbyt formalna. W rezultacie powstaje debata w zespole dotycząca tego, co faktycznie oznacza „dobra” odpowiedź.

Ten etap to nie tylko etykietowanie, ale przede wszystkim zdrowa debata w zespole. Dyskusje dotyczące niejednoznacznych przypadków realnie kształtują produkt, podobnie jak Khan wspomina ze swoich doświadczeń z autonomicznymi pojazdami, gdzie zespół cotygodniowo analizował dane i decydował „czy samochód powinien był to zrobić”.

Problem z matematyką LLM-ów – konkretny case study

Podczas testów ujawnia się błąd pokazujący realne ograniczenia AI. Na pytanie o zmianę adresu dostawy po 45 minutach od złożenia zamówienia bot odpowiada: „Niestety przekroczyłeś 60-minutowe okno na anulowanie zamówień.”

Khan komentuje ten przypadek: „Modele językowe są bardzo słabe w matematyce. 45 minut to nie więcej niż 60 minut. To rzeczywiste dane z realnego świata.”

Ten przykład demonstruje, dlaczego ludzka ocena pozostaje tak istotna – zautomatyzowane systemy mogą przegapić oczywiste błędy logiczne.

Skalowanie: konkretne liczby przykładów na każdym etapie

Khan przedstawia szczegółowe wytyczne dla różnych faz rozwoju produktu:

Testy wewnętrzne (PoC)

5-10 przykładów wystarczy na początek. Cel stanowi sprawdzenie, czy warto dalej inwestować w rozwój rozwiązania. Priorytetem jest szybka iteracja, a nie pewność wyników.

Faza przed produkcją

Około 100 przykładów zapewnia większą pewność przed wdrożeniem. W branżach regulowanych może być potrzeba większej ilości danych ze względu na podwyższone ryzyko.

Produkcja

1% ruchu na start, następnie stopniowe skalowanie w oparciu o uzyskane rezultaty. Khan zaleca również testowanie własnego produktu przez zespół (dog-fooding).

LLM as judge – automatyzacja z weryfikacją przez człowieka

Khan demonstruje sposób wykorzystania LLM do automatycznej oceny odpowiedzi. Tworzy prompty ewaluacyjne dla każdego kryterium oceny.

Problem ujawnia się jednak szybko: AI oceniło wszystkie odpowiedzi jako „dobre”, mimo że Peter zauważa, iż są za długie i zbyt formalne.

Khan formułuje kluczową obserwację: „Chcesz, żeby LLM as judge było zgodne z twoim ludzkim osądem.”

Współczynnik zgodności jako kluczowa metryka

Rozwiązaniem jest współczynnik zgodności – porównywanie ludzkich ocen z ocenami AI:

• Ludzkie oceny na próbce (np. 10 przykładów)
• AI evaluation na tych samych przykładach
• Obliczanie procentu zgodności
• W przypadku wyników poniżej 80% – poprawianie promptów ewaluacyjnych
• Ponowne testowanie aż do osiągnięcia zadowalającego dopasowania

W przedstawianym demo Khan pokazuje, że ocena tonu wykazała tylko jeden match z pięciu przypadków, podczas gdy znajomość produktów osiągnęła 100%. To wskazuje na potrzebę poprawy kryteriów dla oceny tonu komunikacji.

Kompromis szybkość vs pewność – kluczowa decyzja dla PM-ów

Khan wyjaśnia fundamentalny dylemat: „Jako product managerowie myślimy o tym w dwóch wymiarach – szybkość iteracji versus pewność rezultatu. To są ortogonalne wymiary.”

Więcej danych oznacza większą pewność, ale jednocześnie wolniejszą iterację. Z kolei mniej danych umożliwia szybszą iterację, ale zmniejsza pewność wyników. Dlatego zespół musi określić optymalny punkt dla swojego konkretnego zastosowania.

Khan podkreśla, że jest to pytanie statystyczne – ile danych potrzebujesz, żeby czuć się pewnie w ocenie dla swojego specific use case.

Lista kontrolna: Kluczowe kroki procesu

Faza startowa (5-10 przykładów)

• Zbuduj podstawowy prompt z 3 zmiennymi
• Ustal 3 główne kryteria oceny
• Stwórz arkusz do ewaluacji
• Osobiście oceń każdą odpowiedź
• Iteruj prompt około 20 razy na podstawie zidentyfikowanych problemów

Przed produkcją (100+ przykładów)

• Rozszerz zbiór danych
• Zbuduj LLM as judge system z funkcją wyjaśnień
• Sprawdź współczynnik zgodności z ludzkimi ocenami
• Uruchom wewnętrzne testowanie z zespołem

Produkcja

• Deploy na 1% ruchu
• Monitoruj metryki biznesowe vs wyniki ocen
• Regularnie weryfikuj przez próbkowanie ludzkie

Iteracyjny proces doskonalenia

Khan podkreśla, że proces wymaga około 20 cykli iteracji w układzie prompt-test-improve. To zdecydowanie nie jest jednorazowa akcja.

Mimo że Anthropic console oferuje funkcję optymalizacji promptów przez AI, Khan wyraża sceptycyzm wobec tych wyników. Często system dodaje więcej zasad, zamiast faktycznie poprawiać jakość odpowiedzi. To kluczowa lekcja: nie można ślepo ufać automatyzacji, nawet w przypadku zaawansowanych narzędzi AI.

Prawdziwa poprawa wynika z analizy danych ocenionych przez ludzi oraz systematycznych poprawek opartych na konkretnych problemach znalezionych podczas testów.

Pro-tip od Khan: „Lubię pisać małe notatki obok złych przykładów, a następnie używam LLM do podsumowania wszystkich moich notatek i system mówi mi: oto 3 najważniejsze rzeczy, które musisz naprawić w produkcie.”

Pułapki w opiniach użytkowników i sposoby ich unikania

Peter pyta o wykorzystanie reakcji thumbs up/down od użytkowników jako źródła ocen. Khan ostrzega przed nadmiernym uproszczeniem:

„Co oznacza thumbs down, gdy bot informuje, że nie kwalifikujesz się do zwrotu? Czy to błąd bota, czy frustracja użytkownika?”

Kluczowe pytanie dla PM-ów: Co robić, gdy ewaluacja jest dobra, ale metryki biznesowe spadają? Khan radzi powrót do danych oraz analizę przypadków, gdzie wyniki ocen nie pasują do zadowolenia użytkowników.

Samodoskonalące się agenty w praktyce

Khan wskazuje na możliwość wykorzystania danych z ocenami: „Fakt, że dodajesz notatki i oceny do swoich danych oznacza, że możesz wziąć te dane i użyć ich ponownie w Anthropic console do ulepszania promptu. To są samodoskonalące się agenty w pewnym sensie.”

W rezultacie powstaje pętla sprzężenia zwrotnego między ludzką oceną a zautomatyzowanym ulepszaniem systemu.

Kolekcja praktycznych promptów z webinaru

1. Prompt do tworzenia customer support bota

Zaprojektuj prompt dla bota obsługi klienta, który obsługuje interakcje z klientami On running shoes. 

Wykorzystasz zmienne wejściowe:
- Pytanie użytkownika
- Informacje o produktach  
- Informacje o polityce (wytyczne dotyczące zwrotów)

Powinien odpowiadać pomocną odpowiedzią.

Kiedy stosować: Na początku budowania agenta AI. Zapewnia dobry punkt startowy zgodny z najlepszymi praktykami.

2. Prompt ewaluacyjny – LLM as judge (struktura)

Przeanalizuj poniższą odpowiedź z systemu AI:

Odpowiedź: [AI_RESPONSE]
Pytanie użytkownika: [USER_QUESTION]  
Informacje o produkcie: [PRODUCT_INFO]
Polityki firmy: [POLICIES]

Na podstawie kryteriów dla [ZNAJOMOŚĆ_PRODUKTÓW/ZGODNOŚĆ_Z_POLITYKĄ/TON], 
nadaj ocenę: dobra, zła lub średnia.

Podaj wyjaśnienie swojej oceny.

Kiedy stosować: Do automatycznej oceny jakości odpowiedzi. Khan podkreśla: „Zdecydowanie polecam, żeby LLM tworzyło wyjaśnienie – to jak posiadanie człowieka, który daje notatki, dlaczego przyznaje taką ocenę.”

3. Prompt do analizy problemów

Oto moje notatki z oceny odpowiedzi AI:

[WKLEJ_WSZYSTKIE_NOTATKI_Z_ZŁYCH_PRZYKŁADÓW]

Przeanalizuj te notatki i powiedz mi: jakie są 3 najważniejsze rzeczy, 
które musimy naprawić w naszym systemie AI?

Kiedy stosować: Po zakończeniu sesji ludzkiej oceny z wieloma przykładami. Pozwala efektywnie zidentyfikować najczęstsze problemy wymagające naprawy.

4. Prompt weryfikacji współczynnika zgodności

Porównaj te dwie oceny tej samej odpowiedzi AI:

Ocena ludzka: [HUMAN_LABEL]
Ocena AI: [AI_LABEL]
Oryginalna odpowiedź: [AI_RESPONSE]

Czy się zgadzają? Podaj: Zgodne/Niezgodne i wyjaśnij różnice.

Kiedy stosować: Do weryfikacji, czy LLM as judge jest zgodny z ludzkim osądem.

Kluczowe wnioski dla PM-ów

Khan kończy webinar praktycznym przesłaniem: „Product managerowie rozumiejący ten proces będą kluczowi dla tworzenia produktów AI, które faktycznie działają w realnym świecie.”

Proces nie ma efektownego charakteru – to praca w arkuszach kalkulacyjnych oraz iteracyjne testowanie. Jednak właśnie to stanowi różnicę między produktem, który działa, a tym który zawodzi użytkowników.

Magicznego rozwiązania nie istnieje. Sukces zależy od:

• Systematycznego podejścia do każdego etapu
• Osobistego zaangażowania PM-a w ludzką ocenę
• Cierpliwości w iteracyjnym doskonaleniu
• Kombinacji ludzkiego osądu z odpowiednimi narzędziami

Kluczowy insight

Paradoks działającego systemu

Standardowo myślimy: Negatywna ocena od użytkownika, jak „kciuk w dół”, to bezpośredni sygnał, że nasz system AI zawiódł i wymaga natychmiastowej poprawy.

W praktyce okazuje się, że: Negatywna ocena często nie dotyczy jakości odpowiedzi AI, ale frustracji użytkownika związanej z polityką firmy, którą AI poprawnie i zgodnie z prawdą zakomunikowało. System może działać idealnie, a mimo to otrzymywać negatywne oceny.

Dlaczego to jest istotne: Optymalizując system AI w oparciu o takie opinie, ryzykujemy „naprawianie” poprawnie działającego produktu. Prowadzi to do marnowania zasobów i potencjalnego osłabienia zgodności z polityką firmy tylko po to, by zadowolić użytkownika.

Test na jutro: Następnym razem gdy otrzymasz negatywną ocenę odpowiedzi bota, zamiast od razu zakładać błąd i modyfikować prompt, zadaj pytanie: „Czy użytkownik jest zły na bota, czy na politykę, o której bot go poinformował?”. Sprawdź, czy problem leży w wykonaniu zadania przez AI, czy w samej treści zadania, które mu powierzono.

Ten wpis stanowi część kolekcji notatek z wartościowych podcastów, webinarów i innych treści. Oryginalne źródło: Complete Beginner’s Course on AI Evaluations: Step by Step (2025) – Aman Khan