Keď porovnávate dva modely, prvý inštinkt je otvoriť leaderboard a pozrieť sa na skóre. MMLU, HumanEval, GSM8K — čísla vyzerajú objektívne a porovnateľné. Problém je, že frontier modely dnes dosahujú na MMLU 88–94 %, a v tomto rozsahu sú rozdiely medzi nimi pravdepodobnejšie šum merania než skutočný výkonnostný rozdiel. Benchmark, ktorý nedokáže spoľahlivo rozlíšiť modely, si vyslúžil titul "saturovaný" — a saturovaný benchmark vám o vašom konkrétnom use-case nepovie skoro nič.
Tento článok vysvetľuje, prečo benchmarky klamú (alebo aspoň zavádzajú), aké konkrétne mechanizmy za tým stoja, a čo robiť namiesto slepého čítania leaderboardov. Na konci dostanete praktický rámec, ktorý používame pri výbere modelov pre klientov.
Prečo je MMLU saturovaný a čo to znamená
MMLU (Massive Multitask Language Understanding) bol pri vzniku skutočne užitočný nástroj — pokrýval 57 oblastí od matematiky po právo a medicínu, a prvé modely naň dosahovali výsledky pohybujúce sa okolo 50–60 %. To dávalo zmysel: benchmark bol ťažší než náhodný odhad, ale nie neprekonateľný.
Dnes je situácia iná. Keď sa všetky porovnávané modely zmestia do pásma 88–94 %, nastáva niekoľko problémov naraz:
- Rozdiely sú v miere štatistickej neistoty. Rozdiel 1–2 percentuálnych bodov pri bežnom testovacom sete môže byť artefakt promptovania, poradie možností v otázkach alebo jednoducho variabilita generovania.
- Formulácia promptu mení výsledok. Výskum opakovane ukazuje, že rovnaký model môže dosiahnuť o rádovo ±5–10 percentuálnych bodov iný výsledok len tým, že sa zmení spôsob, akým je otázka položená. To nie je chyba konkrétneho modelu — je to vlastnosť všetkých jazykových modelov.
- Benchmark nemeraj to, čo potrebujete. MMLU testuje znalosti v multiple-choice formáte. Vaša aplikácia pravdepodobne generuje dlhší text, volá nástroje, pracuje s kontextom alebo operuje v špecifickom jazyku. Toto sú úplne iné tasky.
Kontaminácia tréningových dát — tichý zdroj nafúknutých skóre
Jedným z najmenej otvorene diskutovaných problémov benchmarkovania je kontaminácia (data contamination). Keď sa testovacie dáta benchmarku objavia v tréningových dátach modelu — čo je pri modeloch trénovaných na väčšej časti internetu reálne riziko — model si efektívne "pamätá" správne odpovede, nie rozumie danej látke.
Detekcia kontaminácie je ťažká. Väčšina poskytovateľov modelov nevedie verejne dostupný audit tréningových dát. Niektorí zverejňujú interné výsledky decontamination testov, iní nie. Výsledkom je, že pri porovnávaní dvoch modelov na MMLU nemáte istotu, či sa pozeráte na skutočný rozdiel v schopnostiach, alebo na rozdiel v tom, koľko testovacích otázok sa objavilo v tréningových dátach.
Praktický dôsledok: pri výbere modelu vždy preferujte benchmarky s dynamicky generovanými alebo neverejne dostupnými testovacími sadami. Niektoré novšie sady — napríklad LiveBench alebo MMLU-Pro — sa tento problém snažia adresovať pravidelnými aktualizáciami a vyšším dôrazom na uvažovanie, nie memorovanie.
Overfitting na leaderboard ako jadrový problém
Existuje aj menej nevinná verzia toho istého problému: cielená optimalizácia na konkrétne benchmarky. Keď poskytovatelia modelov vedia, že trh porovnáva na MMLU, HumanEval a GSM8K, vzniká silný ekonomický tlak trénovať (alebo ladiť) modely s dôrazom práve na tieto sady.
Toto nie je nevyhnutne podvod — môže to byť dôsledok výberu tréningových dát, spôsobu instruction-tuningu alebo RLHF reward modelov. Výsledok je však rovnaký: model, ktorý vyzerá skvelo na leaderboarde, môže byť výrazne horší na reálnych taskoch, ktoré benchmark nepokrýva.
Videli sme to v praxi pri projektoch s priemyselnou dokumentáciou: model, ktorý vyhral v kódingovom benchmarku, nedokázal spoľahlivo extrahovať štruktúrované dáta z technických PDF. Iný model, s nižším celkovým skóre, sa na tom istom tasku ukázal výrazne lepší — lebo jeho tréningové dáta pravdepodobne obsahovali viac technického textu v relevantnom formáte.
Prečo poradie na leaderboarde nekorreluje s produkčným správaním
Leaderboard agregatívne skóre je ako priemerná teplota v meste: informatívna na veľmi hrubej úrovni, ale nepoužiteľná pri výbere oblečenia na konkrétny deň. Niekoľko dôvodov, prečo poradie modelu na leaderboarde nemusí korelovať s produkčným výkonom:
Domenálna špecifickosť. Všeobecné benchmarky testujú priemer cez desiatky oblastí. Váš use-case je jedna konkrétna doména — výrobná dokumentácia, právne zmluvy, zákaznícka podpora v slovenčine. Model, ktorý je silný v priemere, môže byť slabý práve v tej vašej oblasti.
Jazyková degradácia. Väčšina benchmarkov je po anglicky. Slovenčina je low-resource jazyk — modely na nej degradujú výrazne viac než na angličtine, ale táto degradácia sa v anglickom leaderboarde vôbec neprejaví. Vždy testujte separátne v cieľovom jazyku. Skúsenosť z praxe: model, ktorý v angličtine vyhral porovnanie, mohol byť v slovenčine tretí alebo štvrtý v tom istom teste.
Formát vstupu a výstupu. Benchmarky typicky testujú krátke otázky s krátkou odpoveďou. Produkčné aplikácie pracujú s dlhým kontextom, volaním nástrojov, generovaním štruktúrovaného JSON, alebo multiturnovými konverzáciami. Toto sú odlišné tasky s odlišnými požiadavkami na model.
Latencia a cost. Leaderboardy merujú kvalitu, nie rýchlosť ani cenu. Model s najvyšším skóre môže byť 5× drahší a 3× pomalší než model s o 2 % nižším skóre — čo v produkčnom nasadení môže byť rozhodujúce. Ak chcete hlbší pohľad na výber modelov s ohľadom na tieto faktory, pozrite si Ako vybrať LLM model v 2026.
Vlastný eval je vždy dôležitejší než leaderboard
Z vyššie uvedeného plynie jasný záver: neexistuje externý benchmark, ktorý by vám povedal, ktorý model je správny pre váš use-case. Jediný spoľahlivý zdroj pravdy je vlastný eval postavený na vašich dátach, vašich kritériách a vašom jazyku.
Ako na to v praxi:
- 1.Zbierajte reálne vstupy od prvého dňa. Každý dopyt a každú odpoveď logujte (s anonymizáciou PII). Toto je zlatý fond vašich testovacích prípadov.
- 2.Definujte kritériá kvality pre váš konkrétny task. Čo znamená "dobrá odpoveď" vo vašom prípade? Faktická správnosť? Dodržanie formátu? Neprítomnosť halucinovaných čísel? Každá aplikácia má iné kritériá.
- 3.Zostavte eval set z reálnych prípadov. Aspoň 50–100 príkladov, ideálne 200–500. Pokryte bežné prípady aj edge cases. Označte expected odpovede alebo aspoň kritériá.
- 4.Automatizujte hodnotenie cez `LLM-as-a-judge`. Silnejší model (alebo špecializovaný eval prompt) hodnotí výstupy testovaného modelu podľa vašich kritérií. Toto je dnes bežná produkčná prax. Detailnejšie sa téme venuje článok Ako zmerať kvalitu LLM aplikácie.
- 5.Spúšťajte eval pred každou väčšou zmenou. Výmena modelu, úprava promptu, zmena retrieval stratégie — každé z toho môže neočakávane degradovať kvalitu. Bez regresných testov to zistíte až od zákazníka.
Nástroje ako Langfuse (open-source, self-hostovateľný) alebo Promptfoo (open-source, CI/CD integrácia) výrazne znižujú bariéru pre zavedenie eval procesu. Nie sú to výhradne enterprise nástroje — nasadíte ich aj v malých tímoch.
Ako čítať benchmarky konštruktívne
Napriek všetkým výhradám benchmarky úplne ignorovať nie je správne. Dávajú zmysel v konkrétnych kontextoch:
Hrubé preosievanie kandidátov. Ak porovnávate desiatky modelov a potrebujete zúžiť výber na 3–5 finalistov, leaderboard je legitímny prvý filter. Nepoužívajte ho na finálne rozhodnutie, ale na elimináciu evidentne slabých modelov áno.
Výber benchmarku podľa tasku. Nie všetky benchmarky sú rovnako zavádzajúce. Hľadajte tie, ktoré sú najbližšie vášmu use-casu:
- Pre generovanie kódu: HumanEval, MBPP, SWE-bench
- Pre matematické uvažovanie: MATH, GSM8K
- Pre dlhý kontext: RULER, HELMET
- Pre inštrukčné sledovanie: IFEval
- Pre všeobecné uvažovanie: MMLU-Pro (ťažší variant, menej saturovaný)
Dynamické leaderboardy. Platformy ako ArtificialAnalysis agregujú viac dimenzií naraz — kvalitu, latenciu, cenu, context window. To dáva oveľa realistickejší obraz než samotné MMLU skóre.
Porovnávajte za rovnakých podmienok. Ak hodnotíte dva modely sami, používajte identické prompty, identickú teplotu (temperature) a ideálne rovnaký eval framework. Akýkoľvek rozdiel v podmienkach znečistí výsledok.
Špeciálny prípad: slovenčina a regulované domény
Pre aplikácie v slovenčine platí jedno prosté pravidlo: nikdy neverťe anglickému benchmarku bez overenia v cieľovom jazyku. Slovenčina je low-resource jazyk a modely na nej degradujú výrazne viac než na angličtine. Táto degradácia sa v bežných leaderboardoch vôbec neobjaví, lebo väčšina benchmarkov je anglická.
Praktický postup: z finálnych 2–3 kandidátov vybratých na základe leaderboardu spustite vlastný eval v slovenčine na vašich reálnych dátach. Poradie sa môže zmeniť.
Pre regulované domény — právo, medicína, farmácia, finančné poradenstvo — platí ešte silnejšie varovanie: benchmark skóre z všeobecných domén vám nehovorí nič o tom, ako dobre model zvládne právne klauzuly v slovenčine, lekárske skratky alebo regulatórny text. Táto medzera je dôvod, prečo sa v regulovaných oblastiach oplatí uvažovať o fine-tuningu na doménových dátach — čo podrobnejšie rozoberáme v článku RAG vs fine-tuning — ako sa rozhodnúť.
Červené vlajky pri čítaní benchmark tvrdení
Keď narazíte na benchmark výsledky v prezentácii poskytovateľa alebo v PR článku, hľadajte tieto varovné signály:
- Benchmark bez dátumu merania. Modely sa aktualizujú, benchmarky sa menia — číslo bez dátumu môže byť zastaralé o mesiace.
- Selektívny výber benchmarkov. Ak poskytovateľ uvádza 5 benchmarkov, kde vyhrá, a nespomína tie ostatné, to je selekčné skreslenie.
- Chýbajúca informácia o promptovaní. "Few-shot" vs. "zero-shot", chain-of-thought vs. priama odpoveď — každé z toho môže zmeniť výsledok o jednotky percent. Bez tejto informácie čísla nie sú porovnateľné.
- Porovnanie s benchmarkmi iného veku. Porovnávanie nového modelu s dvoj-ročnými konkurentmi je legitímny marketing, ale nie objektívne porovnanie.
- Benchmark, ktorý model pravdepodobne videl v tréningu. Čím je benchmark staršia a populárnejšia (ako MMLU), tým vyššia pravdepodobnosť kontaminácie.
Časté otázky
Znamená vyššie MMLU skóre lepší model pre moju firmu?
Nie nevyhnutne. MMLU je saturovaný benchmark — rozdiely medzi frontier modelmi v pásme 88–94 % sú na hranici štatistickej neistoty. Pre váš konkrétny use-case je relevantné iba skóre na taskoch podobných tomu vášmu, v jazyku vášho nasadenia. Vlastný eval na reálnych dátach je spoľahlivejší ukazovateľ než akýkoľvek všeobecný leaderboard.
Môžem veriť benchmarku, ak ho publikoval samotný poskytovateľ modelu?
S rezervou. Poskytovatelia majú legitímny záujem prezentovať model v čo najlepšom svetle, čo môže viesť k selektívnemu výberu benchmarkov alebo priaznivejším podmienkam testovania. To neznamená, že čísla sú vymyslené — ale vždy hľadajte nezávislé reprodukcie, napríklad na platformách ako ArtificialAnalysis, alebo si spustite vlastné porovnanie.
Čo je kontaminácia tréningových dát a prečo je problém?
Kontaminácia nastáva, keď sa testovacie otázky benchmarku objavia v tréningových dátach modelu. Model si potom "pamätá" správne odpovede namiesto toho, aby ich odvodzoval z pochopenia. Výsledkom je nafúknuté benchmark skóre, ktoré nezodpovedá skutočným schopnostiam. Detekcia je ťažká, lebo väčšina poskytovateľov nezverejňuje presné zloženie tréningových dát.
Ako rýchlo viem postaviť vlastný základný eval?
Pre prvý eval stačí 50–100 reálnych príkladov zo vašej aplikácie s annotovanými expected výstupmi alebo kritériami kvality. Nástroje ako Promptfoo alebo Langfuse umožňujú spustiť prvé automatizované hodnotenie v priebehu dní, nie týždňov. Kľúčové je začať malý a iterovať — nie čakať na "dokonalú" sadu.
Mení sa poradie modelov medzi verziami?
Áno, výrazne a nepredvídateľne. Aktualizácia modelu (aj pri zachovaní toho istého názvu) môže zmeniť výkon na rôznych taskoch rôznymi smermi. Preto je eval nastavený ako regresný test — nie jednorazové porovnanie — kritický pre produkčné nasadenia. Každú väčšiu zmenu (nová verzia modelu, nový prompt, nový retrieval systém) treba overiť na rovnakom eval sete.
*Pomáhame firmám nastaviť eval proces, ktorý funguje v produkcii — od výberu testovacích prípadov cez automatizované hodnotenie až po integráciu do CI/CD pipeline. Ak neviete, kde začať, radi sa pozrieme na váš konkrétny use-case.*