Dá se věřit AI benchmarkům?

Jak se benchmarky měnily s růstem schopností modelů

Starší benchmarky často fungovaly jako školní test. Model dostal otázku, vybral odpověď, případně napsal krátký text. Hodnocení bylo relativně přímočaré: správně, špatně, částečně správně.

Jenže dnešní modely už nejsou jen textové doplňovače. Umí psát kód, číst dokumentaci, používat nástroje, pracovat se soubory, volat API, spouštět testy a iterovat nad výsledkem. Tím se změnila i otázka, kterou benchmark pokládá.

Dřív jsme se ptali: „Zná model správnou odpověď?“

Dnes se častěji ptáme: „Dokáže model dokončit zadanou práci?“

A to je mnohem těžší změřit. U programování nestačí, že model vyplivne funkci, která vypadá rozumně. Musí pochopit existující codebase, najít správné místo změny, neporušit jiné části systému, projít testy a ideálně za sebou nenechat kód, který bude za tři měsíce někdo opatrně obcházet jako starý integrační skript s názvem final_final2_new.ps1.

Pro tyto případy vznikly benchmarky jako SWE-bench. Místo umělých úloh typu „napiš funkci na součet pole“ pracují s reálnými GitHub issues a opravami v existujících projektech. To byl důležitý krok směrem k realitě.

Ale i takový benchmark stárne. Už proto, že modely začali v tomto testu podvádět a místo řešení úloh začali hledat na GitHubu existující výsledky.

Proč řada benchmarků neodráží skutečné schopnosti modelů

Benchmark může být dobře navržený a zároveň přestat být dobrým vodítkem. U AI se to děje rychleji, než jsme byli zvyklí u klasického softwaru.

První problém je saturace. Jakmile se většina silných modelů dostane blízko stropu, benchmark přestane rozlišovat. Rozdíl jednoho nebo dvou procentních bodů pak vypadá důležitěji, než ve skutečnosti je. Na grafu je to hezké. V praxi často nepoznáte rozdíl.

Druhý problém je zastarání zadání. U benchmarků pro kód se mění knihovny, frameworky, zavislosti, testovací prostředí i běžné vývojářské workflow. Prompt, který před dvěma lety vypadal jako realistické zadání, může dnes měřit spíš to, jak dobře model rozumí starému kontextu a konkrétnímu testovacímu harnessu.

Třetí problém je kontaminace dat. Pokud je benchmark veřejný, může se jeho zadání, řešení nebo podobné diskuze dostat do trénovacích dat. Model pak nemusí úlohu řešit úplně od nuly. Může si pamatovat vzor, patch, strukturu problému nebo styl odpovědi.

Čtvrtý problém je validita. To je suché slovo pro jednoduchou otázku: měří test opravdu to, co tvrdí, že měří? Když benchmark říká, že měří programátorské schopnosti, měří schopnost opravit software, nebo schopnost projít konkrétní sadou unit testů? Když měří kreativitu, měří kreativitu, nebo schopnost napsat odpověď, která se lidem líbí v krátkém srovnání?

Právě proto je zajímavé, že OpenAI v roce 2026 zveřejnilo text proč už nepoužívá SWE-bench Verified pro měření frontier coding schopností. Důvodem nebylo, že by programátorské benchmarky ztratily smysl. Problém byl v tom, že konkrétní benchmark už podle OpenAI příliš často měřil špatné věci: kontaminaci, slabé testy, okrajové případy a rozdíly v prostředí.

To je dobrá lekce. I slavný benchmark může přestat být dobrým kompasem.

Jak AI „podvádí“ v benchmarcích

Slovo „podvádí“ je v případě AI trochu zkratka. Model většinou nemá úmysl obejít pravidla tak, jak by to udělal člověk. Nemá vlastní marketingové oddělení, netiskne tiskové zprávy a nevybírá si metriky do prezentace. Není to politik ani Youtuber prodávájící Athletic Greens. Model dělá hlavně to, k čemu byl veden: k řešení zadání. Hledá vzorce, maximalizuje úspěch a optimalizuje odpověď podle signálu, který dostane.

Problém vzniká ve chvíli, kdy se z benchmarku stane cíl sám o sobě. Když celý trh sleduje jedno číslo, firmy i vývojové týmy mají silnou motivaci zlepšit právě toto číslo. Někdy poctivě lepším modelem. Někdy ale také úpravou testovacího nastavení, výběrem vhodné metriky nebo optimalizací na konkrétní typ úloh. Výsledkem může být model, který vypadá skvěle na žebříčku benchmarků, ale v běžné práci tak přesvědčivý není.

Je proto užitečné rozlišovat dvě roviny: co může zkreslit výkon samotného modelu a co může zkreslit způsob, jakým firma výsledek naměří nebo odprezentuje.

Na straně modelu může jít například o:

• Tréninkovou kontaminaci. Model mohl během trénování vidět zadání benchmarku, jeho řešení nebo velmi podobné diskuze. Pak nejde nutně o schopnost vyřešit nový problém, ale o schopnost vybavit si něco, co už bylo v datech.
• Optimalizaci na styl testu. Model se může naučit typický formát benchmarkových úloh, jejich jazyk, strukturu a očekávaný způsob odpovědi. V testu pak působí velmi silně, ale mimo tento formát už nemusí být stejně spolehlivý.
• Hledání zkratek místo řešení. U agentních benchmarků se může stát, že model najde způsob, jak projít kontrolou, aniž by skutečně splnil původní úkol. Neznamená to, že „ví, že podvádí“. Spíš využije slabinu prostředí, validace nebo zadání.
• Přehnanou citlivost na prompt. Některé výsledky vzniknou jen při velmi specifickém zadání, přesném systémovém promptu, vhodném pořadí instrukcí nebo několika pokusech. Běžný uživatel pak při běžném použití nemusí dostat podobný výkon.

Na straně firem (tvůrců modelů) a prezentace výsledků může jít například o:

• Speciální testovací nastavení. Výsledek může být naměřen s nástroji, přístupem k internetu, delším časem na odpověď, větším počtem pokusů nebo konfigurací, kterou běžný uživatel v produktu nemá.
• Cherry-picking metrik. Firma zvýrazní benchmark, ve kterém model vychází dobře, zatímco méně lichotivé výsledky zůstanou v poznámce pod čarou — nebo se neukážou vůbec. Firmy také často ve svých článcích porovnávají svůj model oproti předchozím generacím, ale vynechávají konkurenční modely.
• Nejasnou metodiku. Někdy není zřejmé, jak přesně test probíhal: kolikrát se úloha spustila, zda se počítal nejlepší nebo průměrný výsledek, jaké byly povolené nástroje, zda výsledek ověřoval nezávislý subjekt a kolik celý běh stál.
• Srovnávání nestejných podmínek. Jeden model může být testován jako čistý jazykový model, druhý jako agent s nástroji a třetí s ručně připraveným promptem. Na grafu pak stojí vedle sebe, ale ve skutečnosti nesoutěží ve stejné disciplíně.

To neznamená, že každé vysoké skóre je podezřelé. Znamená to jen, že samotné skóre nestačí. U AI benchmarků je potřeba číst i drobný text okolo: jaký model se testoval, s jakým nastavením, s jakými nástroji, kolikrát, za jakou cenu, v jakém prostředí a kdo výsledek ověřoval.

Dobré benchmarky nejsou zbytečné. Jen je potřeba brát je jako orientační mapu, ne jako pravdu vytesanou do kamene. Ukazují, kde model může být silný. Neříkají automaticky, jak se bude chovat ve vaší práci, s vašimi daty, vašimi procesy a vašimi chybami v zadání.

Alternativní benchmarky: když si lidé dělají vlastní testy

Vedle velkých akademických a firemních benchmarků vznikla zajímavá protiváha: osobní a komunitní testy.

Například SkateBench od Theo.gg testuje, jak dobře modely rozpoznávají technické skateboardové triky. Zní to jako vtip, ale právě v tom je pointa. Když je oblast dost specifická, veřejné modely v ní často ukážou slabiny, které se v obecných benchmarcích schovají.

Podobně Simon Willison dlouhodobě používá test, ve kterém model musí vygenerovat SVG obrázek pelikána jedoucího na kole. Je to zvláštní úloha: model musí psát kód, rozumět tvarům, prostoru, objektům a zároveň vytvořit něco vizuálně rozpoznatelného. Willison k tomu později napsal i text o tom, co se stane, když se laboratoře začnou připravovat i na takové meme testy.

Tyto benchmarky nejsou vědecky čisté. Nemají vždy pevnou metodiku, statistiku ani přesně definovanou metriku. Ale mají jednu velkou výhodu: jsou blízko lidskému úsudku. Člověk, který dané oblasti rozumí, často během pár sekund pozná, jestli model opravdu chápe zadání, nebo jen skládá hezky vypadající věty.

Podobnou roli mají uživatelské arény, například LMArena / Arena. Uživatel zadá prompt, dostane anonymní odpovědi dvou modelů a vybere lepší. Takové hodnocení zachycuje lidskou preferenci, což je užitečné hlavně u chatu, psaní, kreativity nebo obrázků. Má to ale limit: lidé často vybírají odpověď, která působí přesvědčivě, ne nutně odpověď, která je správná.

Arény jsou proto dobrý signál pro použitelnost. Nejsou automaticky důkazem pravdivosti.

Nové benchmarky se snaží měřit skutečnou práci

Další generace benchmarků se snaží přiblížit tomu, jak lidé používají AI v praxi. Nestačí dát modelu otázku. Test musí sledovat celý proces.

U coding agentů to znamená například:

• práci v reálném repozitáři,
• delší kontext než jeden soubor,
• běh testů a opravu chyb,
• použití nástrojů, terminálu nebo editoru,
• hodnocení výsledku podle chování softwaru, ne jen podle podobnosti s referenčním patchem,
• měření času, ceny a počtu zásahů člověka.

Příkladem takového směru je DeepSWE, který se snaží testovat coding agenty na úlohách psaných od nuly, napříč více repozitáři a jazyky. Zajímavý je hlavně princip: snížit riziko, že model už viděl řešení, a zároveň hodnotit práci blíž skutečnému vývoji. Benchmarky, jejich kombinace, použití a prezentaci začíná postupně přepracovávat i největší AI benchmarkový zdroj, Artificial Analysis.

Podobně se mění i pohled na hodnocení agentů. Anthropic ve svém textu Demystifying evals for AI agents doporučuje stavět testy z reálných selhání a začít klidně menší sadou úloh. To je praktické. Firmy často nepotřebují tisíc akademických testů. Potřebují vědět, jestli model zvládne jejich supportní tiket, jejich migration script, jejich dokumentaci nebo jejich právní formulaci.

Jinými slovy: dobrý benchmark pro agentickou AI není jen otázka a odpověď. Je to reálná pracovní situace.

Kde veřejné benchmarky sledovat

Pokud chcete sledovat veřejné srovnání modelů, je dobré nekoukat jen na jeden žebříček.

Artificial Analysis je užitečný rozcestník pro srovnání modelů a poskytovatelů. Neřeší jen „inteligenci“, ale také cenu, rychlost, latenci, kontextové okno a výkon API providerů. To je důležité, protože nejlepší model na papíře nemusí být nejlepší pro provoz. Pokud stojí moc, odpovídá pomalu nebo má horší dostupnost, ve firemním workflow to bude mít negativní efekt.

Ukázka benchmarku z Artificial Analysis

SWE-bench a jeho varianty jsou relevantní hlavně pro vývojáře a coding agenty. Je ale potřeba sledovat, která verze benchmarku se používá a jaký agentický harness výsledek vytvořil. SWE-Bench je zastaralý, problematický a neodráží dnešní dobu, je lepší sledovat moderní náhrady nako například DeepSWE.

LMArena / Arena je dobrá pro lidské preference a naslepo porovnávané odpovědi. Hodí se pro chat, psaní, kreativní úlohy, multimodalitu nebo obrázky. Jen pozor: preference není totéž co správnost.

U akademických benchmarků je dobré dívat se i na původní paper, dataset a metodiku. Samotná tabulka výsledků je často až poslední vrstva. Důležitější je vědět, co se vlastně měřilo.

Jak si vytvořit vlastní benchmark

Nejužitečnější benchmark často nevznikne v laboratoři. Vznikne ve chvíli, kdy vám AI selže na reálném problému.

Model nezvládl opravit bug. Špatně pochopil zadání. Vymyslel si knihovnu, která neexistuje. Napsal právní odstavec, který zní hezky, ale mění význam. Při analýze dat přehlédl filtr. Vygeneroval obrázek, kde je sice všechno lesklé, ale produkt má jiný počet tlačítek než ve skutečnosti.

Tohle jsou cenné úlohy. Nevyhazujte je.

Stačí jednoduchý systém:

1. Uložte původní zadání. Ideálně přesně tak, jak jste ho dali modelu.
2. Přidejte potřebný kontext. Soubory, odkazy, omezení, očekávaný formát výstupu.
3. Popište správný výsledek. Nemusí to být vždy jedna odpověď. Někdy stačí kritéria.
4. Zapište, proč AI selhala. Halucinace, špatný závěr, nedodržení instrukcí, rozbitý kód, pomalost, příliš mnoho zásahů člověka.
5. Určete metriku. Prošlo/neprošlo, škála 1-5, čas do dokončení, cena, počet oprav, počet lidských zásahů.
6. Nechte část úloh skrytou. Pokud budete modely stále ladit na stejných příkladech, vytvoříte si vlastní malý leaderboardový problém.
7. Test opakujte při novém modelu. Uvidíte, jestli se zlepšení týká vašich úloh, ne jen veřejných grafů.

Po měsíci běžného používání můžete mít 20 až 50 úloh. To už je dost na interní srovnání. Nemusí to být vědecká práce, musí to být fér vůči realitě vaší práce.

Pro firmu může takový benchmark obsahovat například:

• typické supportní tikety ze service desku,
• reálné části dokumentace,
• starší skripty a konfigurace,
• ukázky zákaznické komunikace,
• interní bezpečnostní pravidla,
• analytické úlohy nad daty,
• příklady, kde model dříve halucinoval.

Tady se ukáže rozdíl mezi modelem, který je dobrý v tabulce, a modelem, který vám opravdu šetří práci.

Co si z benchmarků odnést

Benchmarky nejsou lež, jsou zkratka. A jako každá zkratka fungují jen tehdy, když víte, kam vede.

Veřejné benchmarky používejte jako první filtr. Pomohou vám zjistit, které modely stojí za pozornost, jak se trh hýbe a kde jsou silné nebo slabé stránky konkrétních nástrojů. Neberte je ale jako finální rozhodnutí.

U každého skóre se ptejte:

• Co přesně benchmark měří? (nemyslíme tím deklarovanou cenu za milion tokenů, ale cenu za úlohu, protože spotřeba tokenů se napříč modely rapidně liší)
• Jak staré jsou úlohy?
• Mohl model vidět data během trénování?
• Jaký prompt, nástroje a počet pokusů byly použity?
• Měří se jen správnost, nebo i čas, cena a lidské opravy?
• Podobá se test práci, kterou od AI opravdu chcete?

Nejlepší přístup je kombinace tří vrstev: veřejné benchmarky pro orientaci, uživatelské arény pro pocit z používání a vlastní interní benchmark pro rozhodnutí.

Protože otázka nezní: „Který model je nejlepší?“

Správná otázka zní: „Který model nejlépe zvládne naše konkrétní úlohy, za přijatelnou cenu, s přijatelným rizikem a bez toho, aby po něm člověk musel všechno opravovat?“

A na to vám žádný globální žebříček sám o sobě neodpoví.