Poniższy artykuł stanowi szczegółowe notatki z prezentacji Hamela Husaina, eksperta od ewaluacji AI, który przeszkolił ponad 2000 inżynierów z firm takich jak OpenAI, Anthropic czy Google. Wszystkie przedstawione przemyślenia, obserwacje i strategie pochodzą bezpośrednio od prelegenta.

TL;DR

Manual review 100 traces to najcenniejsza praktyka ewaluacyjna – przewyższa wszystkie automatyczne metryki
„Data accounting” daje ogromną wartość i jest tym, co wszyscy pomijają – to fundament każdej dobrej ewaluacji
Agreement jako metryka jest mylący – 90% agreement może oznaczać kompletną porażkę systemu
Binarne oceny (true/false) są lepsze niż skale 1-5 – redukują złożoność i wymuszają jasne kryteria
Ogólne metryki jak „helpfulness” prowadzą na manowce – skupiaj się na konkretnych problemach produktu
True positive rate i true negative rate to właściwe miary – pokazują rzeczywistą skuteczność ewaluacji
Jeśli ludzie nie ufają evalsom, „skończyłeś” – zaufanie jest fundamentem całego procesu

Co to jest trace i dlaczego stanowi punkt startowy

Trace to kompletny log wszystkich interakcji użytkownika z AI, włączając wewnętrzne operacje niewidoczne dla użytkownika. Zawiera system message, zapytania użytkownika, wywołania narzędzi, odpowiedzi API oraz finalne wyniki.

Husain rozpoczyna swoją analizę od przypadku Nurture Boss – asystenta AI do zarządzania nieruchomościami. Kiedy Jacob, założyciel firmy, zwrócił się do niego o pomoc z ewaluacją, odpowiedź była zaskakująca. Zamiast zaawansowanych narzędzi, Husain zaproponował przeglądanie surowych danych konwersacyjnych.

W przykładowym trace widać: system prompt definiujący rolę AI, użytkownik pytający o lokalizację budynku, wywołanie narzędzia get_communities_information, zwracaną informację i odpowiedź AI. Następnie użytkownik pyta o dostępność dwupokojowego mieszkania, jednak rozmowa nagle się urywa. To błąd, który nie został wyświetlony użytkownikowi.

Proces analizy okazał się rewolucyjny w swojej prostocie. Do dziesiątego trace zespół był już bardzo szybki. Cały proces zajął godzinę, ale dał więcej wglądu niż jakiekolwiek automatyczne rozwiązanie.

Data accounting: ta część, którą wszyscy pomijają

Według Husaina, „data accounting” to kluczowe pojęcie w ewaluacji AI. Najbardziej wartościową częścią procesu ewaluacji jest właśnie ręczna analiza danych i liczenie realnych problemów – to element, który zbyt wiele zespołów pomija.

Proces polega na systematycznym przeglądaniu danych i dokumentowaniu obserwacji. Nie chodzi o dogłębną analizę przyczyn, lecz o dokumentowanie problemów w sposób metodyczny.

Podstawowy proces manual review

Wyeksportuj 100 traces z systemu (minimum dla theoretical saturation)
Zarezerwuj 1-2 godziny nieprzerwanych prac
Nie rób pełnej analizy przyczyn – tylko obserwuj i dokumentuj
Zapisz krótką notatkę o każdym problemie
Kontynuuj aż przestaniesz odkrywać nowe typy problemów

Drugi przykład z prezentacji pokazuje frustrującą interakcję: użytkownik mówi tylko „preview program”, AI próbuje zaproponować wizytę, użytkownik odpowiada odmownie, jednak AI dalej pyta o wizytę. Gdy użytkownik chce rozmawiać z człowiekiem, AI zadaje serię pytań: „Czy chcesz, żebym Cię połączył? Czy jesteś pewien? Czy jesteś pewien?” Ta sytuacja przypomina klasyczną frustrację każdego, kto dzwonił do call center.

Od open codes do axial codes: systematyzacja chaosu

Husain wykorzystuje terminologię z nauk społecznych, która ma dziesięciolecia zastosowań w machine learning. Open codes to surowe notatki o problemach, natomiast axial codes to kategorie grupujące podobne zagadnienia.

Po zebraniu notatek o błędach powstaje pozornie chaotyczny zbiór danych. Husain pokazuje jednak, jak go uporządkować przy użyciu prostych narzędzi:

Proces kategoryzacji w trzech krokach:

Eksport danych: Przenieś wszystkie swoje notatki do arkusza kalkulacyjnego.

Kategoryzacja z AI: Użyj narzędzia AI (np. w Google Sheets) lub wklej notatki do ChatGPT z poleceniem pogrupowania ich w 5-6 głównych kategorii.

Zliczanie i priorytetyzacja: Stwórz tabelę przestawną, aby zliczyć, ile razy wystąpił problem z każdej kategorii. W rezultacie w kilka minut zobaczysz, co jest największym problemem.

Analiza automatycznie sortuje notatki w kategorie takie jak:

Tour scheduling issues – problemy z umawianiem wizyt
Human handoff problems – nieudane przekazania do człowieka
Formatting errors – błędy formatowania w wiadomościach tekstowych
Conversational flow issues – przerywane lub chaotyczne rozmowy
Promises not kept – niespełnione obietnice

Najczęstszy problem okazał się trywialny: obsługa dat. LLM nie wiedział, jaki jest dzisiejszy dzień. Problem został rozwiązany bez żadnego evala – wystarczyło dodać datę do promptu.

Analiza kosztów i korzyści: kiedy LLM judge, a kiedy kod

Husain wyróżnia dwa typy ewaluacji z różnymi kosztami utrzymania:

Code-based eval charakteryzuje się niskimi kosztami i stosuje się go dla jasnych kryteriów pass/fail. Przykład stanowi sprawdzanie, czy zwrócona data równa się oczekiwanej dacie. Jest oparty na asercjach i nie wymaga LLM judge, co minimalizuje koszty utrzymania.

LLM judge jest droższy, jednak stosuje się go dla subiektywnych ocen. Przykładem może być ocena, czy nastąpiło właściwe przekazanie do człowieka. Wymaga human labeling do walidacji, generuje wyższe koszty utrzymania, ale daje większą wartość przy iterowaniu.

Dla problemu z datami zespół zastosował code-based eval. Z kolei dla problemu z przekazywaniem do człowieka potrzebowali LLM judge, ponieważ była to kwestia subiektywna i wymagała licznych iteracji.

Pułapka agreement: dlaczego 90% to może być katastrofa

Husain ostrzega przed stosowaniem agreement jako głównej metryki. Problem matematyczny polega na tym, że jeśli błędy występują w 10% przypadków, można osiągnąć 90% agreement zawsze odpowiadając „nie ma błędu”. Na papierze wygląda to świetnie, jednak w rzeczywistości oznacza kompletną porażkę.

Właściwe metryki to:

True positive rate – zdolność identyfikacji rzeczywistych błędów
True negative rate – zdolność identyfikacji prawidłowych przypadków

Confusion matrix z przykładu pokazuje:

70 przypadków: zgoda human/LLM (brak błędu)
18 przypadków: LLM false positive (widzi błąd gdzie go nie ma)
3 przypadki: LLM false negative (przegapia rzeczywisty błąd)

Różne rodzaje błędów mają różną wagę biznesową. Czasem false positives są tańsze niż false negatives, dlatego trzeba analizować każdy przypadek indywidualnie.

LLM judge: structured output i validation

Husain demonstruje konkretny prompt dla human handoff judge w systemie Nurture Boss. Kluczowe elementy skutecznego LLM judge obejmują:

Binary output (true/false) zamiast wyników liczbowych
Structured output z polem wyjaśnienia dla debugowania
Przykłady w prompt – jednak z uwagą na nadmierne dopasowanie
Podział train/test – nie używaj wszystkich danych w prompt

Włożenie wszystkich traces do promptu daje 100% dokładności, ponieważ judge zna odpowiedzi. To forma oszukiwania, której należy unikać.

Dlaczego skale 1-5 stanowią problem

Kiedy widzisz średnią 3.2 vs 3.7, nikt nie wie, co to oznacza. To nie jest actionable – podkreśla Husain.

Problemy ze skalami obejmują:

LLM nie są dobre w continuous scores
„False precision” – udawana dokładność
Ludzie nie potrafią rozróżnić 3 od 4
Ukrywają prawdziwą decyzję: czy to wystarczająco dobre do publikacji?

Aby używać skal poprawnie, trzeba być wyjątkowo zdyscyplinowanym. Potrzeba jasnych kryteriów oraz skalibrowanego zespołu. W większości przypadków to się nie udaje.

Ogólne metryki: dlaczego pulpity nawigacyjne oszukują

Problem z helpfulness czy toxicity scores polega na tym, że ogólne prompty nie pasują do najważniejszych problemów konkretnej aplikacji. W rezultacie zespoły marnują energię umysłową na analizowanie ogólnych pulpitów zamiast rozwiązywać rzeczywiste problemy.

Husain proponuje „sztuczkę Jedi” dla generycznych metryk: nie należy ich raportować jako głównych wskaźników. Można ich jednak użyć jako narzędzia do „inteligentnego próbkowania” – posortuj logi według wskaźnika halucynacji, a następnie ręcznie przeanalizuj te z najwyższymi i najniższymi wynikami. To świetny sposób na szybkie znalezienie interesujących przypadków do analizy.

Production: utrzymanie i monitoring

Husain utrzymuje poniżej tuzina ewaluacji – jest oszczędny, ponieważ kosztują one utrzymanie. Regularny harmonogram obejmuje cotygodniowe lub comiesięczne human labeling, szczególnie po większych zmianach w systemie oraz gdy pojawiają się nowe przypadki użycia.

Próbkowanie w produkcji zależy od skali:

Miliardy użytkowników dziennie = próbkuj podzbiór
Tysiące użytkowników dziennie = oceniaj wszystko

Można zbudować pakiet ewaluacji z czasem, ale nie należy maksymalizować ich liczby. Celem jest lepszy produkt, nie idealne metryki.

Synthetic data: wymiary zamiast ogólnego promptowania

Jeśli nie masz jeszcze danych produkcyjnych, musisz je wygenerować. Husain ostrzega jednak przed prostym proszeniem LLM o „prawdopodobne pytania”. Znacznie skuteczniejsza metoda to:

Zdefiniuj wymiary i persony: Określ kluczowe zmienne (np. typ klienta: mieszkaniec apartamentu premium, typ zapytania: utrzymanie).

Stwórz kombinacje: Połącz te wymiary, tworząc konkretne scenariusze (np. „pytanie o utrzymanie od mieszkańca apartamentu premium”).

Wygeneruj dane: Poproś LLM o stworzenie zapytań dla każdej z tych precyzyjnych kombinacji.

Taki proces zapewni różnorodność i pomoże znaleźć przypadki brzegowe. Takie podejście jest o wiele lepsze niż ogólne promptowanie, ponieważ przemyślanie eksploruje przestrzeń możliwości.

N=1 user i dog fooding

Jeśli budujesz narzędzie dla siebie, N równa się jeden użytkownik. Używanie go samodzielnie oznacza robienie error analysis przez samo życie i używanie narzędzia. Dopiero gdy skala wykracza poza nasze zrozumienie, potrzebujemy formalnych ewaluacji.

Podejście czasowe obejmuje:

Pre-launch: dog food, friendly customers, synthetic data
Post-launch: prawdziwe dane przebijają wszystko

Annotation jako najważniejsza część

Zawsze rób human labels. To najbardziej wartościowa część całego procesu, nawet jeśli nic więcej nie zbudujesz – podkreśla Husain.

Nurture Boss zbudował niestandardowe narzędzie do adnotacji w mniej niż 4 godziny. AI świetnie pomaga budować takie narzędzia. Narzędzie oferowało trace view, dodawanie notatek, automatyczne axial coding oraz liczenie w czasie rzeczywistym.

Jacob przeszedł transformację od skeptyka do entuzjasty, co widać w filmie zamieszczonym w poście na blogu. Warto zainwestować w budowę prostego, wewnętrznego narzędzia do adnotacji, aby ten proces był jak najprostszy.

Final wisdom: zaufanie jest wszystkim

Jeśli ludzie nie ufają evalsom, nie będą ufać nawet osobie je prowadzącej. Dlatego trzeba zmierzyć sędziego przed zaufaniem metryce. Confusion matrix pokazuje, gdzie sędzia zawodzi, natomiast decyzja biznesowa określa, czy wydajność jest akceptowalna.

Nie należy maksymalizować evals. Trzeba uziemić się w analizie danych i manual review. Jest to ściśle powiązane z evalami – nie można robić evals bez tego podstawowego procesu.

Biblioteka promptów z prezentacji Hamela Husaina

1. Prompt do kategoryzacji notatek z analizy

Przeanalizuj poniższy plik CSV. Zawiera on zagnieżdżone pole metadanych o nazwie 'Z-note', które zawiera 'otwarte kody' (open codes). Są to notatki do analizy logów LLM, którą przeprowadzamy. 

Wyodrębnij wszystkie różne 'otwarte kody' z pola 'Z-note'. Zaproponuj pięć do sześciu kategorii, z których możemy stworzyć 'kody osiowe' (axial codes).

Kiedy używać: Po zebraniu 100+ notatek z manual review traces. Pomaga przekształcić chaotyczne obserwacje w uporządkowane kategorie problemów.

Dlaczego działa: Używa terminologii z nauk społecznych, którą LLM rozumie jako konkretną technikę, nie ogólną kategoryzację.

2. Prompt do klasyfikacji pojedynczej notatki

Sklasyfikuj następującą notatkę: [notatka] do jednej z następujących kategorii: [kategorie].

Kiedy używać: Do szybkiego sortowania notatek po utworzeniu kategorii. Idealne do zastosowania w formule AI w Google Sheets.

3. Prompt definiujący kryteria dla „Sędziego AI”

Oceniasz asystenta wynajmu, aby ustalić, czy wystąpił błąd przekazania rozmowy. 

Błąd przekazania występuje, jeśli zdarzy się którakolwiek z tych rzeczy:
- Użytkownik poprosił o przekazanie, ale został zignorowany
- Zapętliłeś się w tych samych pytaniach zbyt wiele razy
- [lista innych kryteriów błędu]

Błąd NIE występuje, jeśli:
- [lista warunków braku błędu]

Zwróć dokładnie 'prawda' lub 'fałsz'. Nie dołączaj wyjaśnień.

Kiedy używać: Do oceny subiektywnych aspektów, które nie dają się sprawdzić kodem. Wymaga wcześniejszego human labeling do walidacji.

4. Generowanie synthetic data z wymiarami

Biorąc pod uwagę te wymiary dla [twoja domena]:
- Wymiar 1: [kategoria A, kategoria B]  
- Wymiar 2: [typ X, typ Y]
- Wymiar 3: [intencja M, intencja N]

Dla każdej kombinacji wymiarów wygeneruj 3-5 prawdopodobnych zapytań użytkowników, które testowałyby różne aspekty systemu.

Kiedy używać: Przed uruchomieniem gdy potrzebujesz przypadków testowych, ale nie masz danych rzeczywistych użytkowników.

Kluczowy insight

Paradoks Powolnej Analizy

Standardowo myślimy: Musimy jak najszybciej zautomatyzować ewaluacje i stworzyć dashboard z metrykami, aby podejmować decyzje w oparciu o twarde dane.

W praktyce okazuje się, że: Najważniejsze problemy i najbardziej trafne metryki odkrywamy dopiero po powolnej, manualnej analizie jakościowej około 100 prawdziwych rozmów. Zatem automatyzacja ma sens dopiero wtedy, gdy wiemy, co dokładnie chcemy mierzyć.

Dlaczego to jest istotne: Budowanie dashboardów przed dogłębną analizą prowadzi do mierzenia nieistotnych wskaźników i daje fałszywe poczucie bezpieczeństwa, podczas gdy prawdziwe problemy pozostają nierozwiązane.

Test na jutro: Następnym razem, gdy Twój zespół będzie chciał zdefiniować metryki dla nowego produktu AI, zamiast organizować burzę mózgów na temat „co powinniśmy mierzyć?”, zablokujcie dwie godziny w kalendarzu na wspólną, cichą analizę 50 logów z rozmów. Sprawdźcie, jakie wzorce problemów wyłonią się naturalnie i dopiero na ich podstawie zdefiniujcie wskaźniki.

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ć. Materiał pochodzi z prezentacji „AI Evaluations Crash Course in 50 Minutes (2025) ｜ Hamel Husain”, którą można obejrzeć tutaj: https://www.youtube.com/watch?v=uiza7wp1KrE

Tag: Ocena Modeli Jezykowych

Dlaczego większość zespołów źle robi ewaluację AI – praktyczny przewodnik Hamela Husaina #EN301