ML Atlas

08 · LLM · 4 min czytania · aktualizacja

Jak ocenia się jakość LLM i na ile można ufać benchmarkom?

W skrócie

LLM ocenia się benchmarkami z kluczem odpowiedzi, testami kodu, porównaniami przez ludzi i oceną przez inny model. Każda metoda ma błąd statystyczny i luki.

Co to jest

Ewaluacja LLM to mierzenie, jak dobrze model językowy wykonuje zadania: odpowiada na pytania, rozumuje, pisze kod, streszcza, wykonuje polecenia, odmawia szkodliwych próśb. Stosuje się cztery główne podejścia: benchmarki z kluczem odpowiedzi (np. pytania wielokrotnego wyboru), testy wykonywalne (kod sprawdzany testami jednostkowymi), oceny ludzi (często w formie porównań parami) oraz ocenę przez inny model (LLM-as-a-judge).

W klasycznym uczeniu maszynowym ewaluacja jest stosunkowo prosta: jest zbiór testowy, jedna metryka i jedno zadanie. Model językowy robi tysiące różnych rzeczy, odpowiedzi są otwarte, a „dobra odpowiedź” często nie jest jedna. Dlatego żaden pojedynczy wynik nie mówi, który model jest „najlepszy” — mówi najwyżej, który jest lepszy w konkretnym teście.

Dla praktyka najważniejsza jest ewaluacja na własnym zadaniu: kilkadziesiąt–kilkaset realistycznych przypadków z kryteriami oceny często mówi więcej niż publiczne rankingi.

Mechanizm — dlaczego tak działa

Benchmarki z kluczem. MMLU (Hendrycks i in., 2021) to pytania wielokrotnego wyboru z 57 dziedzin; GSM8K — zadania tekstowe z matematyki z liczbową odpowiedzią. Zaleta: automatyczne, tanie, powtarzalne. Wady: mierzą wąski wycinek umiejętności, są wrażliwe na format promptu, a po kilku latach modele się w nich nasycają — wyniki zbliżają się do sufitu wyznaczonego przez błędy w samych kluczach.

Testy wykonywalne. Przy kodzie odpowiedź można uruchomić. HumanEval (Chen i in., 2021) sprawdza, czy wygenerowana funkcja przechodzi testy, i wprowadza miarę pass@k: prawdopodobieństwo, że spośród k prób przynajmniej jedna jest poprawna. Nieobciążony estymator przy n próbach, z których c przeszło, to 1 − C(n − c, k) / C(n, k).

Ocena przez ludzi i przez modele. Przy odpowiedziach otwartych ludzie porównują dwie odpowiedzi i wskazują lepszą; z wielu porównań wylicza się ranking metodą Elo lub Bradleya–Terry’ego. Zheng i in. (2023) pokazali, że silny model w roli sędziego zgadza się z ludźmi mniej więcej tak często, jak ludzie między sobą, ale ma systematyczne skrzywienia: preferuje dłuższe odpowiedzi, pierwszą pozycję w parze i odpowiedzi w swoim stylu.

Kontaminacja i prawo Goodharta. Pytania z publicznych benchmarków trafiają do danych treningowych, więc model może je pamiętać zamiast rozwiązywać. Do tego gdy wynik w rankingu staje się celem, twórcy optymalizują pod test (dobór promptów, ustawień, danych podobnych do testu) i benchmark przestaje mierzyć ogólną umiejętność. Dlatego powstają zbiory prywatne, odnawiane i tworzone po dacie zakończenia treningu.

Statystyka jest bezlitosna. Benchmark to próbka pytań, więc wynik ma błąd standardowy. Na małych zbiorach różnica kilku punktów procentowych może być czystym szumem — a do tego dochodzi zmienność od losowania przy temperaturze > 0 i od sformułowania promptu.

Na przykładzie

Model odpowiada poprawnie na 80% z 500 pytań. Błąd standardowy trafności to √(0,8 · 0,2 / 500) ≈ 0,018, czyli 95-procentowy przedział ufności wynosi ±3,5 punktu procentowego: od około 76,5% do 83,5%. Drugi model ma 79% na tych samych 500 pytaniach. Różnica 2 punktów przy błędzie standardowym różnicy ≈ 0,025 daje z ≈ 0,79 — daleko od istotności (test dla prób niezależnych; test parowany na tych samych pytaniach bywa czulszy, ale przy takiej różnicy też zwykle nie rozstrzyga). Na całym MMLU (14 042 pytania testowe) przy trafności 70% przedział ma już tylko ±0,76 punktu, więc tam różnice rzędu 2 punktów są wiarygodne statystycznie — co nie znaczy, że są ważne praktycznie.

Teraz pass@k. Model wygenerował 10 rozwiązań zadania programistycznego, 3 przeszły testy. pass@1 = 1 − C(7, 1) / C(10, 1) = 0,3. pass@5 = 1 − C(7, 5) / C(10, 5) = 1 − 21 / 252 ≈ 0,917. Ten sam model ma więc 30% albo 92% zależnie od tego, czy liczymy jedną próbę, czy pięć. Porównując wyniki z różnych źródeł, zawsze sprawdzaj, które k podano.

W praktyce

  • Zbuduj własny zestaw testowy z realnych przypadków użycia (50–500 przykładów) z jasnymi kryteriami; zamroź go i nie używaj do strojenia promptów.
  • Do automatyzacji: biblioteki typu lm-evaluation-harness dla benchmarków publicznych; dla zadań otwartych sędzia-model z rubryką, skalibrowany na próbce ocenionej przez ludzi.
  • Podawaj przedziały ufności (np. scipy.stats.binomtest(k, n).proportion_ci() lub bootstrap) i porównuj modele na tych samych pytaniach.
  • U sędziego-modelu zamieniaj kolejność odpowiedzi w parze i kontroluj długość — to najczęstsze źródła skrzywienia.
  • Typowy błąd: wybór modelu na podstawie jednego rankingu publicznego, bez sprawdzenia na własnych danych, kosztów i opóźnień.

Najczęstsze pytania

Czy wysokie miejsce w rankingu oznacza najlepszy model?
Oznacza dobry wynik w konkretnym teście, z konkretnym promptem i ustawieniami. Ranking może być zawyżony przez kontaminację lub optymalizację pod test i nie musi przekładać się na Twoje zadanie.
Czy LLM może oceniać inne LLM?
Tak, i to tanio, ale ze znanymi skrzywieniami: na korzyść dłuższych odpowiedzi, pierwszej pozycji i własnego stylu. Warto go skalibrować na kilkudziesięciu przypadkach ocenionych przez ludzi i używać rubryk zamiast ogólnego „oceń jakość”.
Ile przykładów potrzeba do wiarygodnej ewaluacji?
Zależy od różnic, które chcesz wykryć. Przy 100 pytaniach i trafności około 80% przedział ufności ma około ±8 punktów, przy 1000 — około ±2,5. Do wykrycia małych różnic potrzeba setek lub tysięcy przypadków.

Źródła

  • Hendrycks D. i in., 2021, „Measuring Massive Multitask Language Understanding”, ICLR 2021.
  • Chen M. i in., 2021, „Evaluating Large Language Models Trained on Code”, arXiv:2107.03374.
  • Zheng L. i in., 2023, „Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”, NeurIPS 2023 (Datasets and Benchmarks).
  • Liang P. i in., 2023, „Holistic Evaluation of Language Models”, Transactions on Machine Learning Research.
  • Cobbe K. i in., 2021, „Training Verifiers to Solve Math Word Problems”, arXiv:2110.14168.

Zobacz też