Benchmark w AI to rodzaj egzaminu dla sztucznej inteligencji. Ideę benchmarku można na przykład porównać do matury. Tak jak matura sprawdza uczniów na tym samym zestawie zadań, tak benchmark porównuje modele językowe na identycznych testach. Dzięki temu da się obiektywnie ocenić, który model lepiej rozumie tekst, rozumuje, liczy lub programuje, oczywiście w zakresie tego, co mierzy dany test.

Co to są benchmarki LLM – po ludzku

Benchmark LLM to standaryzowany test dla modeli językowych, z gotowym zbiorem zadań, kluczem odpowiedzi i sposobem liczenia wyniku. Każdy model dostaje te same pytania, więc wynik można uczciwie porównywać między producentami, wersjami i rozmiarami modeli. Dla biznesu to rodzaj rankingu: pozwala szybko zobaczyć, który model lepiej nadaje się do konkretnych zastosowań, np. konwersacji, analizy danych czy generowania kodu. Ważny element benchmarków to tzw. ukryte pytania (hidden test set), czyli część zadań, które nie są publicznie dostępne i nie powinny trafiać do danych treningowych modeli. Chodzi o to, żeby model musiał faktycznie rozwiązywać problemy, a nie odtwarzać zapamiętane odpowiedzi, co byłoby odpowiednikiem uczenia się całej puli pytań maturalnych na pamięć zamiast rozwijania realnych kompetencji.

Jakie są popularne benchmarki dla LLM?

Większość współczesnych benchmarków sprawdza jedną umiejętność, zamiast wszystkiego naraz. Producenci modeli często chwalą się wynikami w kilku takich benchmarkach naraz, żeby pokazać zarówno wiedzę encyklopedyczną, jak i rozumowanie, kodowanie czy odporność na halucynacje.

BenchmarkUmiejętność testowana w modelu LLMTyp zadań / forma testu
MMLUOgólna wiedza i rozumienie języka w wielu dziedzinach (humanistyka, STEM, prawo itd.)Pytania wielokrotnego wyboru z 57 przedmiotów, podobne do egzaminów i testów akademickich
SWE-benchPraktyczne umiejętności programistyczne w realnych projektach open sourceModele dostają opisy błędów i zadań w repozytoriach, a ich kod jest oceniany po tym, czy naprawia testy w prawdziwych projektach
Humanity’s Last ExamEksperckie, akademickie rozumowanie na granicy ludzkiej wiedzy, w dziesiątkach dziedzinOkoło 2,5-3 tys. bardzo trudnych, zamkniętych pytań, z ukrytym zbiorem pytań do ochrony przed „nauczeniem się testu”
GPQA (np. Diamond)Zaawansowana wiedza naukowa i rozumowanie na poziomie eksperckim w naukach ścisłychBardzo trudne pytania z fizyki, chemii, biologii i pokrewnych dziedzin, projektowane tak, by wymagały głębokiego rozumienia
BIG-Bench Hard (BBH)Niekonwencjonalne, trudne zadania wymagające kreatywnego rozumowania i łączenia wielu krokówZbiór wymagających tasków z różnych dziedzin, często z małą liczbą przykładów
Math / AIMERozwiązywanie złożonych zadań matematycznych krok po kroku, często na poziomie konkursowymTekstowe zadania i problemy olimpijskie, gdzie liczy się poprawne rozumowanie, a nie tylko podanie wyniku

Kto tworzy benchmarki?

Benchmarki w idealnym świecie nie są pisane przez tych samych ludzi, którzy sprzedają model, tylko przez możliwie niezależne zespoły. Najczęściej stoją za nimi grupy badawcze na uczelniach, zespoły R&D w dużych firmach technologicznych oraz społeczności open source, które współpracują przy definiowaniu celów i kryteriów oceny. Dzięki temu łatwiej zachować neutralność, a sam benchmark staje się standardem dla całej branży, a nie prywatnym testem jednego dostawcy.

Proces tworzenia benchmarku

Zaczyna się od jasnej definicji tego, co chcemy zmierzyć: na przykład kompetencje prawnicze, odporność na halucynacje czy jakość generowanego kodu w konkretnym języku. Następnie zbiera się zadania, częściowo z istniejących źródeł, takich jak arkusze egzaminacyjne, konkursy, bazy pytań, a częściowo tworzy się je ręcznie, często z udziałem ekspertów domenowych. Dane przechodzą etap czyszczenia: usuwa się duplikaty, oczywiste podpowiedzi i elementy, które mogłyby pozwolić modelowi zgadnąć odpowiedź bez realnego zrozumienia. Na koniec definiuje się klucz odpowiedzi i metryki, po czym benchmark jest zazwyczaj publikowany razem z kodem potrzebnym do jego uruchomienia.

Jak działa testowanie modeli?

Gdy benchmark już istnieje, testowanie kolejnych LLM-ów jest mocno zautomatyzowane. W dużym uproszczeniu wygląda to tak:

  1. Model dostaje wejście z benchmarku – np. pytanie wielokrotnego wyboru, opis zadania programistycznego albo fragment tekstu z pytaniem.
  2. Odpowiedź modelu jest zapisywana i porównywana z referencją – w zadaniach zamkniętych wystarczy sprawdzić, czy litera odpowiedzi się zgadza, w otwartych używa się bardziej złożonych metryk lub testów jednostkowych.
  3. Zliczany jest wynik – np. procent poprawnych odpowiedzi albo odsetek programów, które przechodzą testy.
  4. Wynik trafia na leaderboard – czyli publiczną listę modeli z wynikami w różnych benchmarkach, co pozwala szybko porównać ich poziom.

Istnieją narzędzia, które spinają różne benchmarki w jedno środowisko testowe, jak EleutherAI Language Model Evaluation Harness, żeby łatwo uruchamiać kilkanaście testów na raz.

Jakie ograniczenia mają benchmarki?

Benchmarki porządkują rynek, ale nie są wyrocznią, mają swoje słabości. Modele można trenować pod test i zawyżać wynik bez realnej poprawy w praktycznych zastosowaniach, szczególnie wtedy, gdy pytania z benchmarku wyciekają do danych treningowych. Z tego powodu w wielu nowoczesnych benchmarkach dąży się do tego, żeby zasadnicza część pytań była ukryta, tak jak w Humanity’s Last Exam, gdzie publiczna jest tylko część zestawu, a osobny, niejawny zbiór służy do realnego mierzenia postępów modeli.

W praktyce jednak nie zawsze tak jest: przykładem może być Polish Medical Benchmark, zbudowany na bazie polskich egzaminów lekarskich, których pytania, podobnie jak w przypadku LEK, są publikowane i dostępne w otwartych bazach, więc modele mogą się na nich „uczyć do testu”. Statyczne zbiory danych szybko się starzeją, szczególnie w obszarach wymagających aktualnej wiedzy, a wysoki wynik w benchmarku nie gwarantuje, że model sprawdzi się w twoim konkretnym use case, bo realne dane i zadania są zwykle bardziej chaotyczne.

Coraz popularniejsze staje się podejście mieszane: publiczne benchmarki służą jako punkt startowy i „język porównania” między modelami, ale kluczowe decyzje podejmuje się na podstawie wewnętrznych testów zaprojektowanych pod konkretną firmę. Oznacza to tworzenie własnych mini-benchmarków złożonych z realnych maili, ticketów supportowych, fragmentów dokumentów czy przykładowych promptów od użytkowników i ocenianie modeli właśnie na takim materiale.