LLM jako sędzia: jak sprawdzić go na ocenach wystawionych ręcznie przez ludzi

Każdy sędzia szuka jednego rodzaju błędu

Husain i Shankar zalecają używać sędziego LLM jako klasyfikatora, który dla konkretnego błędu zwraca Pass albo Fail, a nie jako ogólnej oceny jakości. W praktyce oznacza to jednego sędziego na każdy typ błędu znaleziony w analizie błędów. Dla hipotetycznego asystenta obsługi klienta byłby to na przykład sędzia dla zwrotów obiecanych wbrew polityce i drugi dla odpowiedzi, które mijają się z faktycznym pytaniem klienta.

Werdykt binarny sprawia też, że ludzkie etykiety są bardziej wiarygodne. Ich FAQ zauważa, że ludzie oceniający na skali chętnie wybierają środkowe wartości, żeby uniknąć trudnych decyzji, a wytyczne OpenAI dotyczące ewaluacji również zalecają ocenę pass/fail albo porównania parami.

Poproś sędziego o krótką pisemną krytykę przed werdyktem. Dokumentacja Claude od Anthropic radzi, żeby oceniający model najpierw rozumował, a dopiero potem wystawiał ocenę. Gdy sędzia i ekspert się nie zgadzają, krytyka pomaga ustalić, czy niejasne są kryteria oceny, czy sędzia źle odczytał rozmowę. Prompt sędziego dla jednego błędu potrzebuje czterech rzeczy:

• Definicji błędu słowami eksperta, razem z tym, co się do niego nie zalicza
• Kilku oznaczonych przykładów zaliczeń i błędów z zestawu treningowego
• Tylko tych fragmentów rozmowy, które są potrzebne do decyzji
• Kolejności odpowiedzi: najpierw krytyka, potem Pass albo Fail

Oznacz ręcznie, potem podziel na trzy części

Punktem odniesienia jest zestaw przykładów, które ekspert dziedzinowy oznaczył jako Pass albo Fail dla tego samego błędu, każdy z jednym zdaniem uzasadnienia. Przewodnik Anthropic o ewaluacji agentów stawia ten sam wymóg modelom oceniającym: muszą być ściśle skalibrowane względem ekspertów. Husain i Shankar proponują podzielić oznaczone przykłady na trzy części.

1. 1

   Train: 10 do 20%

   Przykłady, które mogą trafić do promptu sędziego jako przykłady few-shot. Wybierz jednoznaczne przypadki z obu stron.

2. 2

   Dev: 40 do 45%

   Do pracy nad promptem. Uruchom sędziego, przeczytaj, gdzie nie zgadza się z ekspertem, popraw i uruchom go ponownie.

3. 3

   Test: 40 do 45%

   Oceniany raz, na końcu, i to z niego pochodzą raportowane liczby. Podczas strojenia nikt nie zagląda do tych przykładów.

FAQ ostrzega, że wielokrotne strojenie na zestawie dev prowadzi do przeuczenia. Jeśli wynik testowy jest wyraźnie gorszy od ostatniego wyniku na dev, prompt prawdopodobnie nauczył się przykładów z dev, a nie samego błędu.

Przy 5% błędów losowy zestaw testowy z 80 przykładami zawiera około czterech błędów, a wskaźnik policzony na czterech przypadkach nie mówi prawie nic. Dodawaj błędy znalezione w analizie błędów, aż zestaw testowy będzie miał około 30 przykładów każdej klasy. TPR i TNR liczy się w obrębie jednej klasy, więc takie wzbogacenie ich nie zniekształca, o ile dodane błędy przypominają te z produkcji, ale udział błędów w oznaczonym zestawie przestaje wtedy mówić cokolwiek o produkcji.

Raportuj TPR i TNR, a nie trafność

Husain i Shankar definiują odsetek prawdziwie pozytywnych (TPR) jako udział rzeczywistych błędów, które sędzia wychwytuje, a odsetek prawdziwie negatywnych (TNR) jako udział dobrych odpowiedzi, które słusznie przepuszcza. Klasą pozytywną jest tu więc błąd. Trafność (accuracy), czyli udział wszystkich werdyktów zgodnych z ekspertem, miesza oba wskaźniki i zależy głównie od liczniejszej klasy.

Poniższy przykład to nasze własne rozumowanie na zmyślonych liczbach. Weź 1000 rozmów hipotetycznego asystenta obsługi klienta, z których 50 zawiera błąd. Sędzia A przepuszcza wszystko. Sędzia B wychwytuje 40 z 50 błędów i niesłusznie oznacza 95 z 950 dobrych rozmów.

Sędzia A wygrywa pod względem trafności i nie znajduje ani jednego błędu. Z sędzią B da się pracować, ale jego TNR na poziomie 90% ma swoją cenę: 95 z jego 135 oznaczeń to fałszywe alarmy. Przed tym właśnie ostrzegają Husain i Shankar: przy rzadkich błędach nawet niewielki odsetek fałszywych alarmów generuje mnóstwo niepotrzebnych przeglądów. Nie podają uniwersalnych progów i radzą dobierać akceptowalne poziomy do konsekwencji w twojej aplikacji. Przeoczona obietnica zwrotu sprzeczna z polityką kosztuje więcej niż ponowne przeczytanie uprzejmej odpowiedzi.

Skoryguj odsetek zaliczeń, zanim go zaraportujesz

Sędzia o znanych wskaźnikach błędów podaje zniekształcony odsetek zaliczeń. Biblioteka judgy Shreyi Shankar szacuje rzeczywisty odsetek sukcesów, korygując to zniekształcenie. W zapisie użytym wyżej, z błędem jako klasą pozytywną, oszacowanie wygląda tak: (zaobserwowany odsetek zaliczeń + TPR - 1) / (TPR + TNR - 1).

judgy wstawia do licznika TNR, bo w przykładach biblioteki Pass ma wartość 1 i to zaliczenie jest tam klasą pozytywną. Rachunek jest ten sam, zamienione są tylko nazwy. Zanim podstawisz liczby, sprawdź konwencję w swoim kodzie: pomylenie obu wskaźników w liczniku daje zły wynik zawsze, gdy się one różnią.

Kontynuując hipotetyczny przykład: ekspert oznacza 200 rozmów, wzbogaconych o błędy, i dzieli je na 40, 80 i 80. Spośród 80 przykładów testowych 30 zawiera błąd. Gotowy sędzia wychwytuje 27 z 30 (TPR 90%) i przepuszcza 46 z 50 dobrych (TNR 92%). Na produkcji przepuszcza 1700 z 2000 rozmów, co daje zaobserwowany odsetek zaliczeń 85%.

Skorygowane oszacowanie to (0,85 + 0,90 - 1) / (0,90 + 0,92 - 1) = 0,75 / 0,82, czyli około 91,5%. Ten sędzia jest surowszy od eksperta, więc nieskorygowany wynik zaniża ocenę asystenta o ponad sześć punktów procentowych. Jeśli zaraportujesz teraz 85%, a później przejdziesz na łagodniejszego sędziego, pozorna poprawa weźmie się z sędziego, a nie z asystenta.

Korekta zakłada, że TPR + TNR jest większe od 1, czyli sędzia radzi sobie lepiej niż losowo; judgy podaje to założenie. Poza tym TPR i TNR same są oszacowaniami z 30 i 50 przykładów: gdyby prawdziwe TPR wynosiło 80%, ten sam zaobserwowany odsetek po korekcie dałby około 90,3%. judgy wyznacza wokół oszacowania przedział metodą bootstrap i ten przedział powinien trafić do raportu.

Sprawdź sędziego pod kątem znanych skrzywień

Zheng i współautorzy zbadali w 2023 roku sędziów LLM na MT-Bench i Chatbot Arena. Mocni sędziowie osiągali ponad 80% zgodności z preferencjami ludzi, mniej więcej tyle, ile ludzie zgadzają się między sobą, ale praca opisuje też systematyczne skrzywienia. Testowane modele (GPT-4, GPT-3.5 i Claude-v1) są dziś stare, więc traktuj te liczby jako powód, żeby przetestować własnego sędziego, a nie jako jego oszacowanie.

• Skrzywienie pozycyjne. Większość sędziów w porównaniu parami faworyzowała pierwszą odpowiedź. Po zamianie kolejności GPT-4 dawał spójny werdykt w 65,0% przypadków, GPT-3.5 w 46,2%, a Claude-v1 w 23,8%. Autorzy proponują wywołać sędziego dwa razy z zamienioną kolejnością i uznawać wygraną tylko wtedy, gdy ta sama odpowiedź wygrywa w obu kolejnościach; wszystko inne liczy się jako remis.
• Skrzywienie na długość. W teście z powtarzającymi się listami, który wydłuża odpowiedzi bez dodawania informacji, Claude-v1 i GPT-3.5 dały się nabrać w 91,3% przypadków, a GPT-4 w 8,7%. Wytyczne OpenAI dotyczące ewaluacji także zalecają kontrolowanie długości odpowiedzi.
• Faworyzowanie siebie. GPT-4 faworyzował własne odpowiedzi z odsetkiem wygranych wyższym o 10%, a Claude-v1 o 25%. Autorzy zastrzegają, że ich dane są zbyt ograniczone, by stwierdzić, czy to rzeczywiste skrzywienie. Mimo to nie pozwalamy ocenianemu modelowi być własnym sędzią.

Dwa pierwsze skrzywienia sprawdzisz tanio na własnym zestawie dev: powtórz porównania parami z zamienioną kolejnością i wydłuż kilka dobrych odpowiedzi powtórzeniami, żeby zobaczyć, czy werdykt się przesuwa.

Licz się z dryfem kryteriów i waliduj ponownie

Shankar i współautorzy opisują zjawisko, które nazywają dryfem kryteriów (criteria drift): ludzie potrzebują kryteriów, żeby oceniać odpowiedzi, ale dopiero ocenianie pokazuje im, jakie te kryteria są. Spodziewaj się, że definicja błędu u twojego eksperta zmieni się w pierwszych rundach oznaczania. Gdy tak się stanie, przepisz kryteria oceny i oznacz wcześniejsze przykłady ponownie według nowej wersji. Inaczej zestaw testowy miesza dwie definicje, a raportowane TPR nie dotyczy żadnej z nich.

Potem przypnij sędziego. Zapisz pełny identyfikator modelu z datą, wersję promptu, wersję kryteriów oraz TPR i TNR zmierzone dokładnie dla tej kombinacji. Powtarzaj walidację na zestawie testowym przy każdej zmianie któregoś z tych elementów. Zestaw testowy, na którym walidujesz raz za razem, powoli staje się zestawem dev, więc uzupełniaj go świeżo oznaczonymi przykładami z bieżącej produkcji.

Sam raport z walidacji jest krótki: sprawdzany błąd, identyfikator modelu, liczba błędów i dobrych odpowiedzi w zestawie testowym, TPR, TNR, skorygowany odsetek zaliczeń z przedziałem i data. Dołącz go do każdego dashboardu i raportu, który pokazuje liczby tego sędziego.

Ewaluacja LLM dla produktów AIAnaliza błędów w aplikacjach LLMIle przypadków testowych potrzebuje ewaluacja LLM