← wszystkie wpisy
2026.06.30 2 min

Benchmarki: metodologia czystego pomiaru

Jak mierzymy, żeby wynik znaczył. Publiczne zbiory, deterministycznie, przez lm-eval-harness. Bez inspekcji itemów, bez benchmaxxingu.

W poprzednich wpisach opisaliśmy wyniki i leaderboard. Teraz pokażemy, jak dokładnie mierzymy — metodologia, która gwarantuje, że wyniki są porównywalne i wiarygodne.

Jak mierzymy
Publiczne zbiory, deterministycznie, przez lm-eval-harness. „Wyżej = lepiej". Wszystko liczone czysto: bez inspekcji itemów, bez benchmaxxingu.

Pełna tablica na żywo: /leaderboard.

Piątka startowa
LLMzSzŁ — egzaminy zawodowe i państwowe
PES (medyczny) — polski egzamin standardowy
PoQuAD — pytania i odpowiedzi
Belebele (PL) — rozumienie tekstu
FLORES-200 (PL) — tłumaczenia
Pełna lista 10 benchmarków (z kontrolą regresji EN): /leaderboard · zamknięte: /closed-benchmarks

Zasady pomiaru
Ten sam harness
Identyczny tryb, few-shot, szablon promptu i seed dla wszystkich modeli.

Likelihood vs generacja
NLI/MCQ scoringujemy likelihood (log-prob etykiet), binarne i sentyment generacją. Zła metoda daje fałszywą regresję: CDSC-E to −22.5 w generacji, ale tylko −6.0 w likelihood.

Decyzje na n≥400
Mały n potrafi skłamać (kalibracja, która na n=200 dawała +3, na n=400 = 0). n=100 tylko jako szybki screen, nigdy do release.

Tylko agregaty
Bez inspekcji itemów, zero benchmaxxingu. Dane treningowe ze źródeł rozłącznych od evala — skill-transfer, nie zapamiętywanie pytań.

vs train+dev+test
Każdy shard sprawdzany n-gramowo i atom-overlapem przeciw wszystkim splitom — także train. Train-split jako paliwo = kontaminacja.

Bramki + Pareto
Per-zadanie progi (CDSC-E ≤−3pp, parser=0), EN-retencja (ARC/MMLU/GSM8K) pilnuje angielskiego. Release wybiera Pareto-front, nie jeden score.

Best-of per zadanie: dla każdego zadania jedna, właściwa metoda — ta sama dla wszystkich modeli, żeby Δ było porównywalne.

Pełna macierz base vs v3 vs v4 × benchmarki (kolor = Δ): /eksperymenty.

Projektowanie danych bez regresji

skill → eval_proxy → źródło → waga → regression_guard
To jest jawny manifest, jak projektujemy dane, żeby nie powodować regresji:

Określamy umiejętność (skill)
Wybieramy ewaluację proxy (eval_proxy)
Dobieramy źródło danych
Przypisujemy wagę
Ustawiamy bramki regresji
Dlaczego to ważne
Większość zespołów mierzy nieuczciwie:

Dostosowuje metody do modelu
Inspekcjonuje itemy i usuwa „trudne"
Używa train splitu do treningu
Decyduje na małych próbkach
My mierzymy czysto. Dzięki temu nasze wyniki są porównywalne i wiarygodne.

Nawigacja
Poprzedni: Leaderboard: wyniki na żywo i natywność polszczyzny

Więcej: Pełna metodologia · Leaderboard · GitHub