Jak czytać benchmarki LLM (i dlaczego MMLU kłamie)

Gdy porównujecie dwa modele, pierwszym odruchem jest otworzyć leaderboard i spojrzeć na wyniki. MMLU, HumanEval, GSM8K — liczby wyglądają obiektywnie i porównywalnie. Problem polega na tym, że modele frontier osiągają dziś na MMLU 88–94 %, a w tym przedziale różnice między nimi są bardziej prawdopodobnie szumem pomiarowym niż realną różnicą w wydajności. Benchmark, który nie potrafi wiarygodnie rozróżniać modeli, zasłużył na miano „nasycony" — a nasycony benchmark o Państwa konkretnym use-case nie powie prawie nic.

Ten artykuł wyjaśnia, dlaczego benchmarki kłamią (albo przynajmniej wprowadzają w błąd), jakie konkretne mechanizmy za tym stoją i co robić zamiast ślepego czytania leaderboardów. Na końcu znajdziecie praktyczne ramy, których używamy przy doborze modeli dla klientów.

Dlaczego MMLU jest nasycony i co to oznacza

MMLU (Massive Multitask Language Understanding) był w chwili powstania naprawdę użytecznym narzędziem — obejmował 57 dziedzin od matematyki po prawo i medycynę, a pierwsze modele osiągały na nim wyniki rzędu 50–60 %. To miało sens: benchmark był trudniejszy niż losowe zgadywanie, ale nie nie do pokonania.

Dziś sytuacja jest inna. Gdy wszystkie porównywane modele mieszczą się w przedziale 88–94 %, pojawia się kilka problemów naraz:

• Różnice mieszczą się w granicach niepewności statystycznej. Różnica 1–2 punktów procentowych przy typowym zestawie testowym może być artefaktem promptowania, kolejności opcji w pytaniach albo po prostu zmiennością generowania.
• Sformułowanie promptu zmienia wynik. Badania wielokrotnie pokazują, że ten sam model może osiągnąć o ±5–10 punktów procentowych inny wynik tylko przez zmianę sposobu, w jaki pytanie zostało postawione. To nie jest błąd konkretnego modelu — to właściwość wszystkich modeli językowych.
• Benchmark nie mierzy tego, czego potrzebujecie. MMLU testuje wiedzę w formacie wielokrotnego wyboru. Wasza aplikacja prawdopodobnie generuje dłuższy tekst, wywołuje narzędzia, pracuje z kontekstem lub operuje w konkretnym języku. To są zupełnie inne zadania.

Kontaminacja danych treningowych — cichy źródło zawyżonych wyników

Jednym z najmniej otwarcie dyskutowanych problemów benchmarkowania jest kontaminacja (data contamination). Gdy dane testowe benchmarku pojawiają się w danych treningowych modelu — co przy modelach trenowanych na dużej części internetu jest realnym ryzykiem — model efektywnie „pamięta" poprawne odpowiedzi zamiast rozumieć daną materię.

Wykrywanie kontaminacji jest trudne. Większość dostawców modeli nie prowadzi publicznie dostępnego audytu danych treningowych. Niektórzy publikują wewnętrzne wyniki testów decontamination, inni nie. W efekcie porównując dwa modele na MMLU, nie macie pewności, czy patrzycie na realną różnicę w zdolnościach, czy na różnicę w tym, ile pytań testowych pojawiło się w danych treningowych.

Praktyczna konsekwencja: przy wyborze modelu zawsze preferujcie benchmarki z dynamicznie generowanymi lub niepublicznie dostępnymi zestawami testowymi. Niektóre nowsze zestawy — na przykład LiveBench lub MMLU-Pro — starają się ten problem adresować regularnymi aktualizacjami i większym naciskiem na rozumowanie, nie zapamiętywanie.

Overfitting na leaderboard jako kluczowy problem

Istnieje też mniej niewinna wersja tego samego problemu: celowa optymalizacja pod konkretne benchmarki. Gdy dostawcy modeli wiedzą, że rynek porównuje na MMLU, HumanEval i GSM8K, powstaje silna presja ekonomiczna, by trenować (lub dostrajać) modele z naciskiem właśnie na te zestawy.

Nie jest to koniecznie oszustwo — może być konsekwencją doboru danych treningowych, sposobu instruction-tuningu lub modeli nagród RLHF. Wynik jest jednak taki sam: model, który wygląda świetnie na leaderboardzie, może być wyraźnie gorszy w rzeczywistych zadaniach, których benchmark nie obejmuje.

Widzieliśmy to w praktyce przy projektach z dokumentacją przemysłową: model, który wygrał w benchmarku kodowania, nie potrafił wiarygodnie wyodrębniać ustrukturyzowanych danych z technicznych plików PDF. Inny model, z niższym ogólnym wynikiem, okazał się na tym samym zadaniu wyraźnie lepszy — bo jego dane treningowe prawdopodobnie zawierały więcej tekstu technicznego w odpowiednim formacie.

Dlaczego pozycja na leaderboardzie nie koreluje z zachowaniem produkcyjnym

Zagregowany wynik na leaderboardzie jest jak średnia temperatura w mieście: informatywna na bardzo grubym poziomie, ale bezużyteczna przy wyborze stroju na konkretny dzień. Kilka powodów, dla których pozycja modelu na leaderboardzie może nie korelować z wydajnością produkcyjną:

Specyfika domenowa. Ogólne benchmarki testują średnią w dziesiątkach dziedzin. Wasz use-case to jedna konkretna domena — dokumentacja produkcyjna, umowy prawne, obsługa klienta po polsku. Model, który jest silny średnio, może być słaby właśnie w waszej dziedzinie.

Degradacja językowa. Większość benchmarków jest po angielsku. Język polski jest językiem low-resource — modele degradują na nim wyraźnie bardziej niż na angielskim, ale ta degradacja w angielskim leaderboardzie w ogóle się nie ujawnia. Zawsze testujcie osobno w docelowym języku. Doświadczenie z praktyki: model, który w angielskim wygrał porównanie, mógł być w polskim trzeci lub czwarty w tym samym teście.

Format wejścia i wyjścia. Benchmarki typowo testują krótkie pytania z krótką odpowiedzią. Aplikacje produkcyjne pracują z długim kontekstem, wywołaniami narzędzi, generowaniem ustrukturyzowanego JSON lub konwersacjami wieloturowym. To są odmienne zadania z odmiennymi wymaganiami wobec modelu.

Latencja i koszt. Leaderboardy mierzą jakość, nie szybkość ani cenę. Model z najwyższym wynikiem może być 5× droższy i 3× wolniejszy niż model z o 2 % niższym wynikiem — co w wdrożeniu produkcyjnym może być decydujące. Jeśli chcą Państwo głębszego spojrzenia na wybór modeli z uwzględnieniem tych czynników, zapraszamy do artykułu Jak wybrać model LLM w 2026.

Własny eval jest zawsze ważniejszy niż leaderboard

Z powyższego wynika jasny wniosek: nie istnieje zewnętrzny benchmark, który powiedziałby Państwu, który model jest właściwy dla waszego use-case. Jedynym wiarygodnym źródłem prawdy jest własny eval zbudowany na waszych danych, waszych kryteriach i waszym języku.

Jak to zrobić w praktyce:

1. 1.Zbierajcie rzeczywiste wejścia od pierwszego dnia. Każde zapytanie i każdą odpowiedź logujcie (z anonimizacją PII). To jest złoty fundusz waszych przypadków testowych.
2. 2.Zdefiniujcie kryteria jakości dla waszego konkretnego zadania. Co oznacza „dobra odpowiedź" w Państwa przypadku? Poprawność faktyczna? Przestrzeganie formatu? Brak halucynowanych liczb? Każda aplikacja ma inne kryteria.
3. 3.Skompletujcie zestaw evalowy z rzeczywistych przypadków. Przynajmniej 50–100 przykładów, idealnie 200–500. Pokryjcie typowe przypadki i edge cases. Oznaczcie oczekiwane odpowiedzi lub przynajmniej kryteria.
4. 4.Zautomatyzujcie ocenę przez `LLM-as-a-judge`. Silniejszy model (lub specjalizowany prompt evalowy) ocenia wyjścia testowanego modelu według waszych kryteriów. To dziś standardowa praktyka produkcyjna. Tematowi poświęcamy szczegółowo artykuł Jak zmierzyć jakość aplikacji LLM.
5. 5.Uruchamiajcie eval przed każdą większą zmianą. Wymiana modelu, modyfikacja promptu, zmiana strategii retrieval — każde z nich może nieoczekiwanie zdegradować jakość. Bez testów regresyjnych dowiecie się o tym dopiero od klienta.

Narzędzia takie jak Langfuse (open-source, self-hostowalny) lub Promptfoo (open-source, integracja CI/CD) znacząco obniżają barierę wdrożenia procesu evalowego. Nie są to wyłącznie narzędzia enterprise — wdroży je też mały zespół.

Jak czytać benchmarki konstruktywnie

Pomimo wszystkich zastrzeżeń, całkowite ignorowanie benchmarków nie jest właściwe. Mają sens w konkretnych kontekstach:

Zgrubne przesiewanie kandydatów. Jeśli porównujecie dziesiątki modeli i potrzebujecie zawęzić wybór do 3–5 finalistów, leaderboard jest uzasadnionym pierwszym filtrem. Nie używajcie go do decyzji ostatecznej, ale do eliminacji ewidentnie słabych modeli — jak najbardziej.

Wybór benchmarku według zadania. Nie wszystkie benchmarki są jednakowo mylące. Szukajcie tych, które są najbliższe waszemu use-case: - Do generowania kodu: HumanEval, MBPP, SWE-bench - Do rozumowania matematycznego: MATH, GSM8K - Do długiego kontekstu: RULER, HELMET - Do śledzenia instrukcji: IFEval - Do ogólnego rozumowania: MMLU-Pro (trudniejszy wariant, mniej nasycony)

Dynamiczne leaderboardy. Platformy takie jak ArtificialAnalysis agregują więcej wymiarów naraz — jakość, latencję, cenę, context window. To daje o wiele realistyczniejszy obraz niż sam wynik MMLU.

Porównujcie w identycznych warunkach. Jeśli sami oceniacie dwa modele, używajcie identycznych promptów, identycznej temperatury (temperature) i najlepiej tego samego frameworka evalowego. Jakakolwiek różnica w warunkach zaburzy wynik.

Szczególny przypadek: język polski i regulowane domeny

Dla aplikacji w języku polskim obowiązuje jedna prosta zasada: nigdy nie ufajcie anglojęzycznemu benchmarkowi bez weryfikacji w języku docelowym. Polski jest językiem low-resource i modele degradują na nim wyraźnie bardziej niż na angielskim. Ta degradacja w standardowych leaderboardach w ogóle się nie pojawia, bo większość benchmarków jest anglojęzyczna.

Praktyczny tryb postępowania: z 2–3 finałowych kandydatów wybranych na podstawie leaderboardu uruchomcie własny eval po polsku na Państwa rzeczywistych danych. Kolejność może się zmienić.

W przypadku regulowanych domen — prawo, medycyna, farmacja, doradztwo finansowe — ostrzeżenie jest jeszcze silniejsze: wynik benchmarku z ogólnych dziedzin nie mówi Państwu nic o tym, jak dobrze model poradzi sobie z klauzulami prawnymi w języku polskim, skrótami medycznymi czy tekstem regulatoryjnym. Ta luka jest powodem, dla którego w regulowanych obszarach warto rozważyć fine-tuning na danych domenowych — co szczegółowo omawiamy w artykule RAG vs. fine-tuning — jak się zdecydować.

Czerwone flagi przy czytaniu twierdzeń benchmarkowych

Gdy natkniecie się na wyniki benchmarków w prezentacji dostawcy lub w artykule PR, szukajcie tych sygnałów ostrzegawczych:

• Benchmark bez daty pomiaru. Modele są aktualizowane, benchmarki się zmieniają — liczba bez daty może być nieaktualna o wiele miesięcy.
• Selektywny dobór benchmarków. Jeśli dostawca podaje 5 benchmarków, w których wygrywa, i nie wspomina o pozostałych, to jest selektywne zniekształcenie.
• Brak informacji o promptowaniu. „Few-shot" vs. „zero-shot", chain-of-thought vs. bezpośrednia odpowiedź — każde z nich może zmienić wynik o kilka punktów procentowych. Bez tej informacji liczby nie są porównywalne.
• Porównanie z benchmarkami innej epoki. Porównywanie nowego modelu z dwuletnimi konkurentami to legalny marketing, ale nie obiektywne zestawienie.
• Benchmark, który model prawdopodobnie widział w treningu. Im starszy i bardziej popularny benchmark (jak MMLU), tym wyższe prawdopodobieństwo kontaminacji.

Najczęstsze pytania

Czy wyższy wynik MMLU oznacza lepszy model dla mojej firmy?

Niekoniecznie. MMLU jest nasyconym benchmarkiem — różnice między modelami frontier w przedziale 88–94 % mieszczą się na granicy niepewności statystycznej. Dla waszego konkretnego use-case istotny jest tylko wynik na zadaniach podobnych do waszych, w języku Państwa wdrożenia. Własny eval na rzeczywistych danych jest wiarygodniejszym wskaźnikiem niż jakikolwiek ogólny leaderboard.

Czy mogę ufać benchmarkowi, jeśli opublikował go sam dostawca modelu?

Z rezerwą. Dostawcy mają uzasadniony interes, by prezentować model w jak najlepszym świetle, co może prowadzić do selektywnego doboru benchmarków lub korzystniejszych warunków testowania. Nie oznacza to, że liczby są zmyślone — ale zawsze szukajcie niezależnych reprodukcji, na przykład na platformach takich jak ArtificialAnalysis, lub przeprowadźcie własne porównanie.

Czym jest kontaminacja danych treningowych i dlaczego jest problemem?

Kontaminacja zachodzi, gdy pytania testowe benchmarku pojawiają się w danych treningowych modelu. Model „pamięta" wtedy poprawne odpowiedzi zamiast wywodzić je ze zrozumienia. Efektem jest zawyżony wynik benchmarkowy, który nie odpowiada rzeczywistym zdolnościom. Wykrywanie jest trudne, bo większość dostawców nie ujawnia dokładnego składu danych treningowych.

Jak szybko mogę zbudować własny podstawowy eval?

Do pierwszego evalu wystarczy 50–100 rzeczywistych przykładów z Państwa aplikacji z opatrzonymi adnotacjami oczekiwanymi wyjściami lub kryteriami jakości. Narzędzia takie jak Promptfoo lub Langfuse pozwalają uruchomić pierwsze zautomatyzowane ocenianie w ciągu dni, nie tygodni. Kluczowe jest zacząć od małego i iterować — nie czekać na „doskonały" zestaw.

Czy kolejność modeli zmienia się między wersjami?

Tak, znacząco i nieprzewidywalnie. Aktualizacja modelu (nawet przy zachowaniu tej samej nazwy) może zmieniać wydajność w różnych zadaniach w różnych kierunkach. Dlatego eval ustawiony jako test regresyjny — nie jednorazowe porównanie — jest krytyczny dla wdrożeń produkcyjnych. Każdą większą zmianę (nowa wersja modelu, nowy prompt, nowy system retrieval) trzeba zweryfikować na tym samym zestawie evalowym.

*Pomagamy firmom wdrożyć proces evalowy, który działa w produkcji — od doboru przypadków testowych przez zautomatyzowaną ocenę aż po integrację z pipelinem CI/CD. Jeśli nie wiedzą Państwo, od czego zacząć, chętnie przyjrzymy się Państwa konkretnemu use-case.*