Proč benchmarky AI modelů nestačí: co měřit, když vám jde o práci v reálném systému

Nový model „překonává předchůdce na SWE-bench o pět bodů". Vy ho v produkci pustíte na svoje úkoly, a po týdnu má tým pocit, že se nic nezměnilo — nebo se naopak rozbily věci, které dřív fungovaly. Není to chyba měření. Benchmark měřil přesně to, co měřit měl. Problém je v tom, že to, co měří benchmark, není totéž, co potřebujete od modelu v produkci. Tahle mezera není odbočka v interpretaci čísel; je to konstrukční vlastnost veřejných benchmarků, kterou si stojí za to pojmenovat dřív, než na nich postavíte rozhodnutí.

Konkrétní podoba toho zklamání vypadá typicky takhle. Tým používá model na dvě věci: generování PR popisů a první review pass nad cizími změnami. Nový model má v changelogu +5 na SWE-benchi, tak se přepne. Po dvou týdnech se ukáže, že popisy jsou sice košatější, ale review nad nimi paradoxně trvá déle — model začal sebevědomě navrhovat „opravy", které vypadají rozumně a nejsou, a dvě z nich prošly až do mainu. Benchmark přitom neklamal. Jen měřil něco jiného, než na čem tomuhle týmu reálně záleželo.

01Co benchmark vlastně měří (a co nemá šanci)

Benchmark je sada vstupů a očekávaných výstupů (nebo skoringového kritéria) s pravidly, jak na ní porovnávat modely. To je celý jeho účel: dát srovnatelné číslo. Aby to číslo mělo smysl pro hodně různých modelů, musí být úloha uniformní, statická a tisíckrát opakovatelná. Tahle tři slova jsou zároveň ta tři, která žádný reálný produkční úkol nesplňuje.

V produkci nepřicházejí úlohy uniformně — přicházejí v záplavě edge cases a kontextu, který benchmark neumí zachytit. Nejsou statické — váš codebase, vaše data, vaši uživatelé se mění týden co týden, a model, který fungoval minulý měsíc, dnes prochází jiným prostředím. A nejsou opakovatelné — produkce je nutně něco, co se odehrává jednou.

Benchmark tedy neměří „jak dobrý je model v reálné práci", měří „jak dobrý je model v té abstraktně vystřižené, statické úloze, kterou jsme se rozhodli použít jako proxy reálné práce". Tahle distinkce není slovíčkaření — je to celý zdroj následné mezery.

02Tři druhy benchmarků a co umí říct

Než se dostaneme k tomu, co konkrétně benchmarky kazí, je dobré rozlišit, o čem vlastně mluvíme. Smícháváme do jednoho slova několik různých věcí, a pak nás překvapuje, že čísla z různých benchmarků si vzájemně odporují.

Capability benchmark. Měří, jestli model umí konkrétní třídu úloh (MMLU pro znalosti, HumanEval/SWE-bench pro kód, GPQA pro vědu, BEAM/MRCRv2 pro paměť). Když rostou, model se posouvá ve schopnostech v té třídě. Neříkají, že model produkčně funguje — říkají, že má potenciál.

Safety / risk evaluation. METR a podobné týmy měří autonomní schopnosti, schopnost samostatně provést řetězec úloh, nebezpečné capabilities. Tyhle evaluace stojí jinde — jejich účelem není „je model lepší než ten loňský", je to „má model nějakou novou schopnost, která má bezpečnostní implikace". Číslo není leaderboard, je to varovný signál.

Production-proxy. Pokus zachytit, jestli model funguje v realisticky vypadajícím prostředí — víceobratová konverzace, dlouhý kontext, použití nástrojů, multi-step úlohy. Sem patří třeba τ-bench (tool-use agent v simulovaném zákaznickém provozu, který navíc měří konzistenci přes opakované běhy, ne jen jednorázový úspěch) nebo WebArena (agent v prohlížeči). Bližší produkci než klasický capability benchmark, ale pořád synthetic — simulovaný zákazník není váš zákazník a simulované prostředí není váš stack. Lepší signál pro „čeká nás workflow změna", horší pro „nasadit do produkce".

Tři kategorie, tři účely. Pokud na otázku „máme nasadit nový model" odpovídáte čistě capability benchmarkem, použili jste špatný nástroj.

03Klasické problémy veřejných benchmarků

Když benchmark vznikne, je užitečný. Po pár letech existence se na něm stane několik věcí, které jeho užitečnost erodují — a každá z nich bije jiný typ benchmarku jinak.

Kontaminace tréninkových dat. Veřejný benchmark s veřejnými otázkami se dřív nebo později ocitne v tréninkovém korpusu nového modelu. Skóre pak měří částečně paměť, ne schopnost. Učebnicový případ je GSM8K — populární benchmark matematických úloh, na kterém frontier modely dosahují 90+ %. Když výzkumníci z Applu na podzim 2024 publikovali GSM-Symbolic (tytéž úlohy s drobně změněnými čísly, jmény a v některých variantách s irelevantní informací navíc), výkon stejných modelů citelně klesl — u nejtěžší varianty u některých modelů o víc než deset procentních bodů. To je signál, že část skóre na GSM8K nebyla schopnost řešit, ale schopnost rozpoznat. Detekovat to zvenku jde špatně; autoři benchmarků s tím bojují (privátní test sety, dynamicky generované úlohy), ale úplně to nezmizí. Bije primárně capability benchmarky. Odkud se do korpusu vůbec bere obsah, který tohle způsobuje — a jaké riziko z jeho neprůhledné provenience dědíte do vlastního produktu — rozebírá Na čem byl váš model trénovaný.

Overfitting na test set. Když všichni optimalizují na jeden benchmark, dřív nebo později vznikají modely, které jsou „dobré v tom benchmarku" a slabší v drobně jiných úlohách. Není to nutně podvod — je to přirozený důsledek toho, že se na něco zaměřuje výzkum a inženýrská práce. SWE-bench Verified vznikl částečně proto, že u původního SWE-benchu se ukázaly problémy s kvalitou části úloh — nedostatečně specifikovaná zadání, nespolehlivé testy — které deformovaly skóre nezávisle na schopnostech modelu.

Selection bias úloh. Autoři benchmarku vybrali úlohy, které šly rozumně zaskorovat. To, co se těžko skoruje (kreativita, nuance, dlouhodobá konzistence, citlivost na kontext), se do benchmarku skoro nedostává. Měříme tedy to, co se měří snadno, ne to, co se v práci nejvíc počítá. Bije všechny tři kategorie, nejhůř production-proxy benchmarky, které měly přesně tuhle mezeru zaplnit.

Stáří benchmarku. Benchmark starý dva roky byl postavený na schopnostech modelů dvou let zpátky. Dnešní modely ho saturují (90+ %), a saturovaný benchmark přestává rozlišovat. Z čísla zní „skoro vyřešeno", ale to neznamená, že je vyřešená úloha, kterou benchmark měl reprezentovat. MMLU je dnešním učebnicovým příkladem — top modely jsou v pásmu, kde rozdíly nejsou statisticky smysluplné, a leaderboardy se hýbou o desetinky.

Goodhartův zákon. „Když se z metriky stane cíl, přestává být dobrou metrikou." Jakmile celý ekosystém míří na MMLU, HumanEval nebo SWE-bench, ta čísla začínají měřit „kolik úsilí se v tomto kvartále investovalo do tohohle benchmarku", ne „jak schopný je model". Týká se to hlavně capability benchmarků s vysokou viditelností; safety evaluace jsou (zatím) méně zasažené, protože netvoří marketing leaderboard.

04Co opravdu měřit v produkci

Když benchmark neřekne, jestli model funguje u vás, řekne to měření na vašich datech. Disciplinovaný produkční eval obvykle stojí na šesti veličinách. Nejsou stejně důležité: pokud máte kapacitu jen na dvě, měřte workflow success rate na zlaté sadě a regression rate při přechodu — první říká, jestli model pomáhá, druhá, jestli přechod něco nerozbil. Zbylé čtyři přidávejte, jakmile základ stojí.

Workflow success rate. Procento reálných úkolů, které model zvládne tak, že jdou rovnou použít (bez korekce, nebo s malou). Měří se na vašich úkolech, ne na syntetických. Nestačí přitom „bylo to správně" — důležité je, jestli to uživatel/tým přijal (na rozdíl od „bylo to syntakticky správně, ale nezapadlo to do našeho stylu"). Pomáhá rozlišit alespoň tři úrovně: přijato beze změn, přijato po drobné úpravě, zahozeno a předěláno ručně.

Regression rate. Když přepnete na nový model, kolik dříve fungujících workflow přestane fungovat. Toto je metrika, kterou benchmark zachytit nemůže — protože benchmark neví, co u vás fungovalo. Bez ní se přechod na „lepší" model klidně promění v tichý downgrade části workflow, který vyplave týdny po nasazení.

Time saved. Kolik reálného času ušetříte oproti baselinu (předchozí model, žádný model, jiný workflow). Neukazuje to jen jedno volání, ukazuje to celý cyklus včetně review a oprav. Model, který dělá výstup o 30 % rychleji, ale review trvá dvakrát déle, je čistá ztráta.

Provozní cena a latence. Kolik stojí jedno dokončení úkolu a jak rychle přijde odpověď. Tahle veličina nemá s kvalitou nic společného, a přesto rozhoduje o nasazení stejně tvrdě jako úspěšnost — zvlášť u interaktivních workflow, kde latence přímo určuje použitelnost. Model o pět bodů úspěšnější, ale třikrát dražší na úkol a dvakrát pomalejší v odezvě, je často horší volba, i když v tabulce vyhrává. Počítejte cenu na dokončený úkol, ne na token: model, který potřebuje tři pokusy a delší kontext, může vyjít dráž než nominálně dvakrát dražší model, který to dá napoprvé.

Cost of error. Kolik vás stojí chyba modelu — od „přečtu výstup znova" přes „rozbil PR" po „rozjel problém v produkci". Tady má smysl rozlišovat dva typy: viditelné chyby (model napíše blbost, kterou poznáte na první pohled, opravíte ji a jedete dál) a chyby s falešnou jistotou (model napíše blbost, která vypadá správně, projde review a praskne až později). Druhé jsou řádově dražší. Model s vyšší úspěšností, ale dražšími chybami, může reálně škodit víc než model s nižší úspěšností a snadnou opravou.

Drift v čase. Tentýž model na tomtéž vstupu se v čase může chovat mírně jinak. Část driftu je doložená i pod stejným označením verze — změny v serving infrastruktuře, kvantizaci nebo routingu posunou chování, aniž se sáhlo na váhy (viz studie o měnícím se chování GPT-4 v čase). K tomu se přidává riziko aliasů typu latest, pod kterými se reálně střídají různé verze, a občasné neohlášené aktualizace. Bez vlastního měření tohle nemáte šanci zachytit jinak než stížnostmi uživatelů — a v tom okamžiku už jste reaktivní. Praktická obrana je dvojí: kde to jde, pinujte konkrétní verze modelu (ne latest), a tu samou zlatou sadu pouštějte pravidelně i bez change releasu — třeba jednou za měsíc. Pinování má vlastní trade-off: pinnutá verze časem zmizí z nabídky (deprecation) a tým, který nikdy neupgraduje, si jen odkládá větší skok — pin je nástroj kontroly nad okamžikem přechodu, ne způsob, jak se přechodu vyhnout. Drift, který neměříte, vás dohoní.

Žádná z těchto šesti veličin neexistuje ve veřejných tabulkách. Všechny jdou změřit u vás. Tým, který si je měří, dělá rozhodnutí v jiné kvalitě než tým, který se dívá na leaderboard.

05Jak postavit minimální produkční eval

Nemusíte mít evaluation framework jako Anthropic. První iterace ale není zadarmo — sběr zlaté sady, definice „dobrého" výstupu a kalibrace lidí, aby skórovali konzistentně, vás stojí pár dní soustředěné práce, ne pár hodin. Jakmile to jednou stojí, údržba je opravdu nízkonákladová: řádově pár hodin za půl roku. To je fér přiznat dopředu — důvod, proč to většina týmů nedělá, není lenost, ale reálná vstupní cena, kterou nikdo nevidí v tabulce.

Zlatá sada úloh. 20–50 reálných úkolů z vaší produkce, u kterých víte, jaký výstup je dobrý. Ne syntetické příklady, ne ukázky z dokumentace. Sada se mění pomalu, ale občas se obohatí o úkol, kde jste byli překvapeni výsledkem (pozitivně i negativně). Na rovinu: na 20–50 úkolech nedostanete statisticky přesné číslo — rozdíl dvou tří procent je na téhle velikosti šum, úplně stejně jako desetinky na MMLU. A to je v pořádku. Smyslem zlaté sady není přesné skóre, ale směr na vašich úkolech a zachycení regresí, které leaderboard z principu nevidí. Když potřebujete jemnější rozlišení (například mezi dvěma blízkými kandidáty), sadu spíš zvětšete a opakujte běhy, než abyste věřili jednomu číslu z jednoho průchodu.

Pravidelný re-run. Při každé změně modelu, providera nebo systémového promptu sada projde znovu. A — důležité — i bez změny, periodicky, kvůli driftu. Skóre se loguje. Posun nahoru i dolů má svůj záznam. Verzování evalu i jeho výsledků patří do gitu vedle kódu, ne do sdílené tabulky, na kterou si za půl roku nikdo nevzpomene.

Mix automatického, modelového a lidského skoringu. Pro úkoly se zřejmým výsledkem (test prošel / neprošel, výstup obsahuje X) stačí automat. Pro úkoly s kvalitativním výstupem se nabízí dvě cesty: druhý LLM jako soudce (LLM-as-judge) nebo člověk. LLM-as-judge je levný a škálovatelný, ale má dokumentované pasti — position bias (preferuje první z dvojice), self-preference (preferuje výstupy modelů z téže rodiny) a verbosity bias (preferuje delší odpovědi). Shoda s lidským hodnocením je u jasných úloh slušná, ale klesá tam, kde záleží na nuanci a kde se málo shodnou i sami lidští hodnotitelé — což je přesně typ úlohy, kvůli které člověka nasazujete. V praxi rozumný kompromis: LLM-as-judge na celou sadu, člověk na 10–20% vzorek pro kalibraci, že judge nelže. Pro úkoly, kde rozhodnutí stojí hodně peněz, žádný judge nenahradí dvacet minut lidské pozornosti.

Adversarial vzorky. Pár úkolů, na kterých dřívější verze padaly. Drží vás na zemi, když nový model „všechno zlepšil" o pět procent — adversarial sada vám prozradí, jestli zlepšil i to, co reálně bolelo. Tahle sekce zlaté sady je v praxi nejcennější: cokoliv, co vás v posledním roce kouslo, by tady mělo být.

Kalibrace náročnosti. Zlatou sadu rozdělte na tři: snadné, střední, těžké. Když „snadné" začne padat, je to alarm. Když „těžké" začne procházet, je to signál, že se otevírá nová zóna použití.

Tahle disciplína je nudná. Je to ale jediný měřitelný způsob, jak vědět, jestli vám model reálně pomáhá.

06Co dělat s veřejnými benchmarky

Veřejné benchmarky nemají skončit v koši. Mají dvě role, ve kterých jsou užiteční, a dvě, ve kterých škodí.

Hodí se na: kandidátní filtr (model, který je o řád horší ve své kategorii, asi nestojí za hodinu testování) a dlouhodobý trend (kam se posouvá frontier, kolik úloh už je saturovaných, co se otevírá). LMArena (dříve Chatbot Arena, vzešlá z akademického projektu LMSYS) je tu užitečná zvlášť proto, že místo statického test setu měří preference na živých uživatelských dotazech — má vlastní pasti (kdo hlasuje, jak se počítá), ale jako proxy „obecné použitelnosti" je informativnější než MMLU.

Neřeší: výběr produkčního modelu (to musí být váš eval) a rozhodnutí, kdy přepnout (to musí být regression). „Chase the leaderboard" je antipattern popsaný v Jak sledovat nové AI modely bez hypu.

Praktická heuristika: čísla benchmarků si zapisujte do logu změn (Jak sledovat nové AI modely bez hypu) jako kontext, ne jako rozhodnutí. Skutečné rozhodnutí má sloupec vedle nich a vychází z vašeho evalu.

07Souvislosti

Článek dotahuje téma, které několik předchozích jen otevřelo. Jak sledovat nové AI modely bez hypu popisuje disciplínu na úrovni „co reagovat na release"; tento článek dává konkrétní nástroj jak to měřit u sebe. Codex vs Claude Code v sekci „jak hodnotit" naznačil, že benchmark není dostačující — tady je vysvětlení proč a co místo. Paměť AI agentů zase ukázal, že čísla z BEAM/MRCRv2 jsou skóre v konkrétní úloze paměti, ne univerzální vlastnost — tady to platí pro benchmarky obecně. A pro pochopení, jak vůbec posuzovat výzkumný papír, ze kterého benchmark vznikl, je Jak číst AI papery. Tatáž disciplína platí i pro hodnotový náklon modelu, který v leaderboardu není vůbec — na to navazuje Žádný AI model není apolitický.

08Závěr

Benchmark je užitečný nástroj, ne odpověď. Měří, co se měřit dá, na úkolu, který je proxy něčeho většího — a ta proxy se s časem opotřebovává kontaminací, overfitem a saturací. Tým, který staví rozhodnutí o produkčním modelu na leaderboardu, vyhrává ve sportu, který se hraje jinde. Tým, který si vede vlastní zlatou sadu, regression a měření driftu, ví o svém systému to, co tabulky říct nemůžou — ne proto, že by tabulky byly špatně, ale proto, že měří jinou věc. Vstupní cena je pár dní soustředěné práce; provozní cena pár hodin za půl roku. Inženýrská kázeň místo tabulkového sportu.

Tým, který staví rozhodnutí o produkčním modelu na leaderboardu, vyhrává ve sportu, který se hraje jinde.