Ilu przypadków testowych potrzebuje ewaluacja LLM, żeby uzasadnić decyzję

Dlaczego 80% wobec 83% na 100 przypadkach niczego nie dowodzi

Załóżmy, że nowy prompt podnosi wynik ewaluacji z 80 do 83 zaliczonych przypadków na 100. Wygląda to na postęp i ktoś będzie chciał go wdrożyć. Zanim zacznie się ta rozmowa, otocz każdą z tych liczb przedziałem.

Policzyliśmy 95-procentowy przedział dla 80 na 100 na dwa sposoby. Przybliżenie normalne daje błąd standardowy 4 punktów i przedział od 72,2% do 87,8%. Przedział Wilsona, który lepiej sprawdza się przy małych próbach i odsetkach bliskich 0% lub 100%, daje od 71,1% do 86,7%. Dla 83 na 100 Wilson daje od 74,5% do 89,1%. Oba zakresy w dużej mierze się pokrywają. Ta ewaluacja nie odróżnia tych promptów, a na nowych przypadkach kolejność mogłaby się równie dobrze odwrócić.

Zestaw 100 przypadków i tak warto mieć. Husain i Shankar opisują zestawy testowe do CI jako małe i budowane pod konkretny cel, w wielu przypadkach liczące 100 przykładów lub więcej, a zestaw tej wielkości może wyłapać zmianę, która wyraźnie coś psuje. Nie uszereguje jednak dwóch wersji różniących się o kilka punktów, a właśnie tego zwykle się od niego oczekuje przy zmianie promptu albo modelu.

Błędy standardowe i dlaczego pogrupowane pytania je powiększają

Artykuł Evana Millera o słupkach błędów w ewaluacjach, napisany w Anthropic, traktuje ewaluację jak eksperyment i zaczyna od podstaw: błąd standardowy średniej liczysz z centralnego twierdzenia granicznego. Dla ocen binarnych, czyli zaliczone albo nie, jest to pierwiastek z p × (1 - p) / n, a 95-procentowy przedział to średnia plus minus 1,96 błędu standardowego. To dokładnie powyższe obliczenie normalne i zakłada ono, że każdy przypadek jest niezależnym losowaniem.

Prawdziwe zestawy testowe często łamią to założenie. Jeśli dziesięć pytań dotyczy tej samej umowy albo czterdzieści przypadków pochodzi z jednego tematu obsługi klienta, model zwykle trafia albo myli się w nich razem. Zestaw zawiera wtedy mniej niezależnych dowodów, niż sugeruje liczba wierszy. Miller zaleca klastrowane błędy standardowe zawsze, gdy pytania tworzą powiązane grupy, i podaje, że mogą być ponad trzy razy większe od naiwnych. W benchmarku DROP jego klastrowany błąd standardowy wyniósł 1,34 wobec naiwnego 0,44.

W praktyce już przy budowie zestawu nadaj każdemu przypadkowi klucz grupy, na przykład dokument źródłowy, klienta, temat albo rozmowę, i klastruj przedziały według niego. Jeśli przedział wyraźnie się poszerzy, zestaw potrzebuje więcej grup, a nie więcej pytań w każdej grupie.

Porównuj obie wersje na tych samych przypadkach

Gdy dwa prompty albo modele działają na tych samych przypadkach, porównywanie dwóch średnich marnuje informację. Miller zaleca zamiast tego wnioskowanie na sparowanych różnicach dla każdego pytania: czy w tym przypadku wersja B wypadła lepiej, gorzej czy tak samo jak wersja A? O różnicy mówią coś tylko te przypadki, które zmieniły wynik.

Pokażmy to na hipotetycznym asystencie obsługi klienta. Na 100 przypadkach testowych prompt A zalicza 80, a prompt B 83. W tabeli krzyżowej wyniki wyglądają tak.

B nowo zalicza 8 przypadków, a 5 przestaje zaliczać, co daje zysk netto 3. Sparowany 95-procentowy przedział dla różnicy policzyliśmy jako od -4,1 do +10,1 punktu, wobec od -7,8 do +13,8, jeśli potraktować oba przebiegi jak niezależne próby. Sparowany bootstrap, który losuje przypadki ze zwracaniem, daje prawie ten sam zakres. Dokładny test McNemara na 13 zmienionych przypadkach daje p = 0,58.

Przy tej wielkości nawet najczystszy wynik nie rozstrzygnąłby sprawy. Gdyby B naprawił 3 przypadki i nie zepsuł żadnego, dokładne p McNemara wyniosłoby 0,25, czyli tyle, ile szansa, że trzy rzuty monetą wypadną tak samo. Weź teraz hipotetyczny zestaw 400 przypadków, w którym A zalicza 81%, a B 84%, przy 16 przypadkach nowo zaliczonych i 4 nowo niezaliczonych. Ten sam zysk 3 punktów ma wtedy sparowany przedział od 0,8 do 5,2 punktu i p około 0,01. O wyniku decyduje to, ile przypadków się zmieniło i jak jednostronne były te zmiany.

Ilu przypadków wymaga konkretna różnica

Zanim zbudujesz zestaw, odwróć pytanie: jaka jest najmniejsza różnica, na którą warto reagować? Miller podaje do tego analizę mocy testu. W jego przykładzie obliczeniowym wykrycie różnicy 3 punktów przy poziomie istotności 5% i mocy 80% wymaga około 969 pytań, a sam autor sugeruje ewaluacje z mniej więcej 1000 pytań lub więcej. Dwa razy mniejsza różnica wymaga mniej więcej czterech razy więcej przypadków.

Jeśli nie możesz zebrać więcej przypadków, uruchom każdy kilka razy. Miller pokazuje, że przy 198 pytaniach dziesięć odpowiedzi na pytanie zamiast jednej obniżyło minimalny wykrywalny efekt z 13,2% do 7,5%. Powtórzenia pomagają mniej niż nowe przypadki, bo zmniejszają szum w odpowiedziach modelu, ale nie losowość tego, które pytania trafiły do zestawu.

Miller odradza też obniżanie temperatury tylko po to, żeby zmniejszyć wariancję. Nasza interpretacja: jeśli produkcja działa na wyższej temperaturze, ewaluacja przy temperaturze 0 mierzy konfigurację, której twoi użytkownicy nigdy nie zobaczą. Zamiast tego losuj odpowiedzi kilka razy.

Powtarzane przebiegi: pass@k i pass^k

Kilka przebiegów na przypadek pokazuje też coś, co średnia ukrywa: czy system działa powtarzalnie. Dwie metryki podsumowują powtarzane próby w przeciwny sposób. pass@k uznaje przypadek za rozwiązany, jeśli udała się co najmniej jedna z k prób. pass^k, wprowadzona razem z benchmarkiem τ-bench, uznaje go tylko wtedy, gdy udały się wszystkie k prób. Przewodnik Anthropic po ewaluacji agentów używa tej samej pary.

Odpowiadają na różne pytania. pass@k pasuje do zadań, w których ktoś albo coś wybiera udaną próbę, na przykład wygenerowany kod, który musi przejść testy, zanim ktokolwiek go użyje. pass^k pasuje do agenta obsługującego klientów, gdzie każda rozmowa jest kolejną próbą, a każdy błąd trafia do klienta.

τ-bench pokazuje, jak daleko od siebie mogą być te wartości. W domenie retail gpt-4o rozwiązał w pojedynczej próbie około 61% zadań, a pass^8, czyli sukces we wszystkich ośmiu próbach, spadło poniżej 25%. Część tego rozrzutu pochodzi od symulowanego klienta. τ-bench każe modelowi językowemu grać użytkownika i losuje jego odpowiedzi z temperaturą 1,0, a agent działa z temperaturą 0, więc każda próba to inaczej sformułowana rozmowa. pass^k mierzy tam więc także to, jak agent radzi sobie z różnymi sformułowaniami, a nie tylko jego własną losowość.

Przy powtórzeniach jednostką pozostaje przypadek. Pięć przebiegów po 100 przypadków to nie 500 niezależnych przypadków. Zgodnie z logiką Millera klastruj błędy standardowe według przypadku.

Jak raportujemy wyniki ewaluacji

Tych zasad trzymamy się, gdy wynik ewaluacji ma uzasadnić decyzję.

• Każdy odsetek zaliczeń podajemy z 95-procentowym przedziałem i liczbą przypadków, na przykład 80% (od 71% do 87%, n = 100)
• Wersje porównujemy na tych samych przypadkach i pokazujemy zmiany: nowo zaliczone, nowo niezaliczone, bez zmian. Każdy nowo niezaliczony przypadek ktoś czyta
• Wyniki rozbijamy na wycinki, na przykład według języka, produktu albo typu sprawy. W wycinku liczącym 20 przypadków jeden przypadek to 5 punktów, więc wycinki też dostają przedziały
• Każdy przypadek ma klucz grupy, a przedziały klastrujemy według niego
• Najmniejszą różnicę, na którą warto reagować, ustalamy przed przebiegiem i do niej dobieramy wielkość zestawu
• Mały zestaw w CI wyłapuje regresje, a o zmianie decyduje większy sparowany przebieg

Ta sama logika dotyczy próbek ruchu produkcyjnego. Husain i Shankar zalecają śledzenie przedziałów ufności dla metryk produkcyjnych i bliższe przyjrzenie się sprawie, gdy dolna granica przekroczy twój próg.

Ewaluacja LLM dla produktów AIJak przetestować dostrojony model na tle modelu, który ma zastąpićCo pilotaż AI musi wykazać, zanim sfinansujecie kolejny etap