Umí agenti česky? Část 1: Porozumění textu

Jsme na českém serveru o otevřených AI modelech, řada z vás bude chtít nasazovat tyto modely v českém kontextu. Přitom jsme se zatím vůbec nebavili o tom, jak dobře – nebo jestli vůbec – umí současné otevřené jazykové modely česky.

Rozhodl jsem se to proto napravit. Tato série článků bude mít rovnou tři části, ve kterých postupně prozkoumáme vztah mezi jazykovými modely a češtinou:

• Část 1: V této části zjistíme, jak modely rozumí českému textu. Dáme si také obecný úvod do tématu a vysvětlíme si, proč by otevřené modely vůbec měly (či neměly) umět česky.
• Část 2: V příští části se podíváme na generování textu. Jak dobře modely zvládají plnit instrukce v češtině? A jak zní české texty od otevřených modelů?
• Část 3: V poslední části to posuneme ještě o kousek dál a podíváme se na agenty v českém kontextu. Zvládnou modely provádět akce v angličtině a zároveň s uživatelem komunikovat česky?

Obsah této série budeme stavět na existujících veřejných benchmarcích, doplníme to ale i vlastními experimenty. Chci dát proto kredit výzkumné infrastruktuře, kterou jsem k experimentům pro tuto sérii článků využil: LRC clusteru na ÚFAL MFF UK, přes který mám přístup ke špičkové výpočetní kapacitě, a výzkumné infrastruktuře od e-INFRA, kde se v poslední době objevují frontier modely hned po vydání. Oběma tímto moc děkuji a doufám, že výsledky budou užitečné i v této – poněkud “neakademické” – podobě.

Proč by modely (ne)měly umět česky?

Zvykli jsme si, že komerční modely česky víceméně umí. Začlo to tím, že už první verze ChatGPT uměla česky obstojně. I díky tomu ji v našich končinách začla ihned používat široká veřejnost.

Není to úplně samozřejmost. Například slovenština v ChatGPT ze začátku drhnula: prompt ve slovenštině v prvních verzích ChatGPT spustil odpověď v jakémsi zvláštním mixu slovanských jazyků.¹ Doufám, že už tomu tak není – budu rád, když to slovenští kolegové upřesní. Claude Sonnet zase do českého textu občas ještě nedávno přimíchával azbuku nebo alfabetu.

Čeština z velkých jazykových modelů ale i dnes zní trochu prkenně. Je to dáno tím, že modely si interně připravují odpovědi v angličtině. To se občas odráží i ve struktuře vět, které zní, jako by je někdo přeložil z anglického originálu bez velkého rozmýšlení. Sám používám i komerční modely v češtině jen minimálně, protože tuším, že anglický výsledek bude vždycky aspoň o kapku lepší.² Většinou jen ve chvíli, kdy je potřebuji v lokálním kontextu (například řešení daňové byrokracie), a to hlavně proto, abych se vyhnul překládání termínů.

Proč je na tom angličtina líp než čeština, a ta zase o něco líp než slovenština? Všechno je to funkcí trénovacích dat. Angličtina není výjimečná ničím jiným, než tím, že na internetu (a v dalších zdrojích, jako třeba knihách) zanechala zdaleka největší stopu. Zároveň data v angličtině mají i nejširší záběr: pro nějaké domény, jako třeba programování, data v jiných jazycích téměř neexistují.

Česky tedy modely umí obstojně díky tomu, že i čeština má poměrně slušnou digitální stopu. V kategorizaci jazyků od Joshi et al. (2020) podle množství dostupných anotovaných (“labeled”) a neanotovaných (“unlabeled”) dat patří do clusteru č. 4, tedy druhého nejlepšího – společně například s polštinou, ruštinou, hindštinou a vietnamštinou:

Je tedy nějaký důvod, proč by otevřené modely neměly umět česky stejně dobře, jako ty komerční? Hlavním důvodem je velikost těchto modelů – respektive její “nedostatek”.

Otevřené modely často chceme provozovat právě proto, že můžou být i malé – tedy v řádech jednotek až desítek miliard parametrů. Takovýto model musí při trénování prioritizovat, co si uloží do parametrů. A protože anglická data vidí nejčastěji, většinu parametrů se silou optimalizace rozhodne věnovat právě angličtině.³ Dochází při tom k něčemu, čemu se říká “curse of multilinguality”: při pevné kapacitě modelu další jazyky zhoršují výkon na těch stávajících, protože jazyky spolu soupeří o parametry (viz například Conneau et al. (2020), Longpre et al. (2025)). To je i důvod, proč pokusy trénovat modely na vyvážených datových sadách, kde je každý jazyk zastoupený zhruba podobně (jako např. BLOOM model od BigScience Workshop (2022)), příliš nevyšly.

Dá se proto například čekat, že pár dní nazpět vydaný frontier model Kimi K3 s 2,8 bilionu parametrů, případně Qwen 3.8 Max s 2,4 bilionu parametrů, které konkurují komerčním modelům v podstatě ve všech ohledech, budou umět i česky na úrovni těchto modelů.

V poslední době ale vyšla i řada “hvězdných” otevřených modelů malé a střední velikosti: především řada modelů Qwen 3.6 a Gemma 4, které se pohybují v jednotkách až desítkách miliard parametrů a dají se tedy rozběhat i na výkonnějších laptopech. Z dostupných benchmarků to vypadá, že tyto modely jsou v zásadě pareto-optimální: při své velikosti poráží libovolný starší model stejné velikosti (a často i ty větší).

S tím, co jsme si právě řekli, je ale otázkou, jestli toto platí i na češtinu. Není tomu náhodou tak, že menší modely “overfitují” (tedy se při trénování soustředí) na angličtinu a další jazyky zanedbávají? A neprojeví se na češtině – jako na jazyku, který má narozdíl od angličtiny bohatou morfologii a flexibilní strukturu vět – trochu víc “prkennost” vyjadřování modelu?

V tomto článku se tyto otázky pokusíme rozplést. Bude to náročnější, protože jsme ještě vůbec nenakousli zásadní otázky evaluace modelů jako takové. Například: Jak se vlastně vyhodnocuje vygenerovaný text? Co je to kontaminace dat? Co všechno může při evaluaci hrát roli? Co ji může pokazit?

I přes to se do toho ale pustíme a pokusím se tu odpovědi aspoň nastínit. V budoucnu se pak podíváme na evaluaci jako takovou víc do detailu.

Vybíráme modely

Rozhodl jsem se v této sérii článků soustředit na pět konkrétních otevřených jazykových modelů:

Proč zrovna tyhle? Jde o velmi nedávné modely, které mají i přes malou/střední velikost velmi nadstandardní výkon na benchmarcích. I za krátkou dobu si proto stihly získat významnou popularitu v komunitě otevřených modelů (viz heuristika z článku Jak vybrat jazykový model).

Zároveň jsem jejich konkrétní velikosti vybíral tak, abychom mohli zodpovědět následující:

• Je na češtinu lepší špičkový Qwen 3.6 (Qwen3.6-27B), nebo srovnatelně velká špičková Gemma 4 (gemma-4-31B-it)?
• Je lepší dense model Qwen3.6-27B, nebo srovnatelný MoE model Qwen3.6-35B-A3B?⁴ Vztah mezi MoE architekturou a multilingualitou je zajímavý a zatím ne příliš prozkoumaný. Blevins et al. (2024) ukazují, že specializace expertů na jazyky může pomoct “curse of multinguality” prolomit. Tématem se zabývá i Bandarkar et al. (2025), podle kterých MoE modely routují tokeny na základě jazyků v prvních a posledních vrstvách, zatímco ve středních vrstvách se routing napříč jazyky do velké míry sjednocuje.
• Pokud máme k dispozici větší kapacitu, vyplatí se nasadit větší model, jako je DeepSeek-V4-Flash-0731?
• Má na češtině šanci i velmi malý model jako gemma-4-E4B-it?

Je samozřejmě řada dalších modelů, které by stály za vyzkoušení, jako například modely Mistral Medium (které jsou ale při srovnatelném výkonu trochu moc velké), frontier modely jako Kimi K3 (které jsou až příliš velké), nebo jiné varianty zkoušených modelů jako Gemma 4-26B-A4B (která se už do srovnání jednoduše nevešla).

Pokud ale máte pocit, že bychom měli nějaký další model vyzkoušet, dejte vědět!

Slasti a strasti evaluace

Jak tedy zjistíme, jak jsou modely dobré na češtinu?

Můžeme třeba udělat to první, co napadne každého: nastartovat je a začít si s nima povídat. To je pro začátek dobrý nápad. Může nám například o modelu odhalit, že model “přemýšlí” interně v angličtině a že česky nějak umí:

Pokud ale model odpoví rozumně, co řešit dál? Může mít slabiny někde jinde?

Co ale řešit dál? Kde má největší slabiny, kde naopak vyniká?

Pokud máme v hlavě konkrétní typ úlohy, nejlepším dalším krokem je udělat si vlastní, malou testovací sadu. Prohlížení výstupů modelu na pár takových příkladech nám často dá zcela nejlepší vhled do schopností modelů – alespoň těch, které nás zajímají.

Sestavit dobrou testovací sadu je ale náročnější, než se zdá. Ještě náročnější je pak vyhodnotit výstupy modelů tak, abychom je mohli mezi sebou porovnat. Na malé testovací sadě mohou být čísla zkreslená konkrétní podobou vybraných příkladů, navíc se na pár příkladech dá ledacos přehlédnout nebo podcenit.

Proto se v této sérii článků budeme soustředit na větší benchmarky. To jsou datové sady, které obsahují sadu úkolů pro model a které na nich zároveň umožňují kvantitativně výkon modelů vyhodnocovat. Budeme se zároveň i dívat do samotných výstupů, protože to může vést k poměrně překvapivým zjištěním.

Testuje někdo modely na češtině?

První věc, kterou zjistí člověk, který se rozhodne si prohlédnout výsledky modelů na českých benchmarcích, je to, že českých benchmarků moc není. Základem všech reportovaných čísel, na které narazíte ve zprávách při vydání modelu, je angličtina.

Například tato tabulka z oficiálního blogu představujícího modely Gemini, která model srovnává i s dalšími komerčními modely, neobsahuje jediný neanglický benchmark:

Co náš obvyklý podezřelý, Artificial Analysis Intelligence Index?

Ten sice nabízí multilinguální track, ale je tam jen 17 jazyků a čeština mezi nimi chybí:

Tohle je problém multilinguálních benchmarků. Jazyků je na světě hodně (přes sedm tisíc) a tvořit evaluační data je náročná a drahá záležitost, a tak tyto benchmarky většinou pokrývají jen malou podmnožinu všech jazyků.

Přesto se ale několik českých benchmarků najít dá – a nebo si k nim můžeme dopomoct.

Benchmarky porozumění českému textu

V tomto díle začneme tím, co je z mnoha úhlů pohledu tím nejjednodušším: porozuměním českému textu. Podívám se konkrétně na dva velké benchmarky: EuroEval a BenCzechMark.

Oba tyto benchmarky jsou spíš “meta-benchmarky”, aneb kolekce řady existujících menších benchmarků pro jednotlivé problémy. Mezi těmito benchmarky je zároveň částečný překryv, což vyplývá z omezeného počtu zdrojů pro náš jazyk.

Jak se dá konkrétně testovat porozumění českému textu? Pro představu to mohou být třeba následující typy úloh:

Určujícím znakem těhle úloh je, že u většiny z nich stačí vybrat správnou možnost – text se tedy generuje jen minimálně.⁵ Generativní modely tedy neumí bohužel odpovídat jinak, než nějaký text vygenerovat (například “Odpověď je A”), takže se trochu zapotíme při parsování jeho odpovědi. Jakmile to ale podchytíme – například pomocí kombinace správného promptování a regulárních výrazů – tak máme (narozdíl od otevřených generativních úloh) vyřešeno. To zároveň znamená, že se tyto úlohy dobře vyhodnocují a jejich vyhodnocování se dobře škáluje. Ne nadarmo byl donedávna nejoblíbenějším benchmarkem frontier modelů MMLU (Massive Multitask Language Understanding), tedy obrovská sada otázek s výběrem z možností.⁶ A ne nadarmo je tento typ testů nejoblíbenější součástí arzenálu každého učitele.

Vyhodnocování

Jak se tyto testy vyhodnocují? Záleží na tom, jak se na ně odpovídá.

Úplně nejjednodušší (ačkoliv pro outsidery možná ne zrovna intuitivní) jsou úlohy na jazykové modelování. Tam se hodnotí perplexita – tedy to, jak moc “překvapený” je model konkrétním textem. Skóre vyplývá přímo z pravděpodobností, které model jednotlivým tokenům v textu přiřazuje, a stačí nám na ni text samotný. Je to stejná metrika, kterou optimalizujeme při trénování. Chování modelu z ní ale příliš nevyčteme – zvlášť proto, že text mohl být přítomný v trénovacích datech (o tom si ještě povíme něco víc).

Základem většiny úloh na porozumění textu je ale spíš výběr z možností. Tam už nám nestačí jen text (respektive otázka), ale i správná odpověď. Pokud je máme, tak můžeme výkon modelu vyhodnotit celkem jednoduše jako procento správných odpovědí (accuracy, česky “přesnost”).

Pokud nám záleží na detailech, můžeme využít nějakou chytřejší metriku, jako je:

• F1 skóre, které bere v úvahu, že ne každá odpověď je stejně častá,
• Matthewsův korelační koeficient, který bere v úvahu, jak moc je model lepší oproti náhodnému hádání,
• AUROC, kdy bereme v úvahu, jak moc je si model při odpovídání jistý.

U některých úloh – například při odpovídání na základě odstavce textu – model text i generuje. Zde potřebujeme porovnat odpověď se správnou odpovědí. Můžeme porovnávat “exact match”, tedy texty vůči sobě jedna-ku-jedné. To je ale obecně moc hrubé, protože se modely málokdy trefí na písmenko přesně. Proto se nám hodí metriky hodnotící lexikální podobnost: například chrF, která spočítá překryv na úrovni znaků a jejich skupin (a tedy například odpověď “na pražském hradě” získá vysoké skóre, i když je správnou odpovědí “Pražský hrad”).

Pojďme se teď podívat na samotné benchmarky.

EuroEval

Jak už název EuroEval naznačuje, tento benchmark se zaměřuje nejen na češtinu, ale i na ostatní evropské jazyky. Původně se jmenoval ScandEval a zaměřoval se jen na dánštinu, švédštinu a norštinu. Máme ale dvojí štěstí: jednak se tento benchmark rozrostl a čeština se do něj dostala po boku dalších evropských jazyků, jednak je tento benchmark pořád živý a udržovaný (na čemž má zásluhu především jeden z jeho autorů Dan Saattrup Smart z dánského Alexandra Instituttet).

Než se dostaneme k jeho detailům, pojďme se podívat na to, co nás zajímá – na leaderboard pro češtinu:

Na první pohled vidíme, že leaderboard je stále živý (to je dobrá zpráva – u podobných leaderboardů to bohužel často nebývá pravdou). Vidíme to z toho, že tu najdeme řadu relativně aktuálních komerčních modelů (GPT-5.4-mini, Claude Sonnet 4.6, Gemini 3 Pro, …) a až na několik dní starý DeepSeek-V4-Flash-0731 tu najdeme všechny modely, které nás zajímají.

Seřazené podle ranků, kde modely se statisticky ekvivalentními výsledky sdílejí stejný rank, vypadá jejich umístění takto:

Díky tomu, že je v benchmarku řada dalších modelů, s nimiž máme nejspíš zkušenost (minimálně Gemini Flash modely teď zná každý, kdo používá Google a jeho AI overviews), můžeme si udělat poměrně dobrý obrázek.

Tedy Qwen3.6-27B by měl zvládat porozumění češtině podobně jako Gemini 3 Pro Preview a o trochu lépe než třeba Claude Sonnet 4.5. Obdobná gemma-4-31B-it je pak zhruba na úrovni GPT-4.1.

Menší gemma-4-E4B-it je podle očekávání pozadu, ale stále zhruba na úrovni dalších, o něco starších modelů kolem 8B parametrů – zatímco má pouze 4,5B parametrů efektivních a větší šířku schopností (zvládá agentní tasky, multimodální vstupy a tak dále).

To jsou povzbudivé výsledky! Samozřejmě je ale potřeba brát v úvahu, co přesně nám tyto výsledky říkají.

Z čeho konkrétně tato čísla vycházejí? Dobrý obrázek si můžeme udělat na stránce věnované českým datasetům. Zde je přehled datasetů v českém EuroEval (těch s validační sadou):

Výsledky je tedy potřeba brát trochu s nadhledem: netestují všechno, co bychom na češtině testovat mohli. Část problémů závisí i na faktických znalostech modelu, se kterými mohou mít modely problémy i v anglickém originále.⁷ Otázky na faktické znalosti v těchto benchmarcích většinou nejsou lokalizované, pouze přeložené. Benchmark s opravdu “lokálními” faktickými otázkami zde vytvořili mí kolegové. Navíc většina modelů v přední části leaderboardu je označená sufixem val, což podle dokumentace znamená, že tyto modely byly vyhodnocené jen na validačních sadách: tyto modely tedy vyhodnocujeme na zhruba 2 000 příkladů. To není úplně málo, ale ani mnoho.

Na aktuálním leaderboardu chyběl z vybraných modelů DeepSeek-V4-Flash-0731. Ve chvíli, kdy toto čtete, už to možná není pravda, protože byl zařazen do vyhodnocovací fronty. Já jsem byl ale zvědavý, a tak jsem si model vyhodnotil rovnou sám alespoň na validačním datasetu. Využil jsem oficiální balíček euroeval a přístup na e-INFRA API, kde model už během těch pár dní tým e-INFRA zvládl nasadit (💪). Skóre DeepSeeku stačilo na rank 4–5 (13. místo v tabulce), do těsného sousedství Claude Sonnet 4.6 a GPT-5.4-mini.⁸ Aby toho nebylo málo meta, zkusil jsem si zároveň tento model napojit do OpenCode a využít ho jako agenta na přípravu experimentů na vyhodnocování sebe sama. Přípravu zvládl celkem dobře a popostrkování vyžadoval jen málo – pocitově na úrovni modelu jako Gemini Flash nebo Claude Sonnet. Akorát si při interpretaci výsledků spletl rank s pořadím v tabulce, takže tvrdil, že rank modelu je 13, ačkoliv byl jen 13. ze všech modelů podle skóre (což vycházelo na rank 4–5). Navíc jeho webová vizualizace, kterou jsem použil pro kontrolu výsledků, vypadala trochu moc jako AI slop. Pro zbytek experimentů jsem proto radši používal osvědčený Claude Opus 5.

BenCzechMark

Tento benchmark – na který je opět lépe pohlížet jako na meta-benchmark – je společnou iniciativou lidí z VUT v Brně, Masarykovy univerzity v Brně, CIIRC ČVUT, Ostravské univerzity a Hugging Face. Je to pravděpodobně to nejlepší, co se dá pro testování porozumění textu na češtinu v současnosti získat. Podrobnosti se o něm můžete dočíst v článku, který loni vyšel v žurnálu TACL.

Pojďme se opět nejdřív podívat na veřejně dostupný leaderboard:

Na benchmarku tentokrát chybí komerční modely. Oficiálně kvůli úlohám, které vyžadují přístup k pravděpodobnostem jednotlivých tokenů, což komerční modely často neumožňují. Zároveň ale tipuji, že vyhodnocování komerčních modelů by se příliš prodražilo. Samotný benchmark se totiž skládá z velkého počtu pod-datasetů – zde jich je konkrétně 50 v osmi kategoriích, z toho 14 nově nasbíraných. Z rozsahu benchmarku tedy vyplývá, že vyhodnocení modelů je poněkud výpočetně náročnější.

Je zde částečný překryv s datasety z EuroEval (konkrétně 6 datasetů z EuroEval pochází ze stejného zdroje), BenCzechMark ale svým rozsahem EuroEval zásadně převyšuje.

BenCzechMark rozlišuje čtyři formáty úloh: výběr ze zadaných možností, klasifikace do stejné sady tříd napříč všemi příklady (tedy např. ano/ne), volně generovaná odpověď a jazykové modelování.

Také se nám lehce rozšířily kategorie úloh, které vyhodnocujeme:

Do benchmarku přispívají s vyhodnocováním nových modelů i v současnosti jeho autoři. Leaderboard je ale otevřený všem: pokud vyhodnotíte model podle oficiálních instrukcí, můžete do něj zaslat výsledky.

Toho jsem se rozhodl využít. V benchmarku byly totiž z našich modelů pouze gemma-4-31B-it a gemma-4-E4B-it. Nažhavil jsem tedy grafické karty a spustil na nich zbývající tři modely.⁹ I DeepSeek jsem tentokrát rozjel lokálně, protože benchmark je opravdu velký a nechtěl jsem přetěžovat infrastrukturu e-INFRA. Zároveň Qwen3.6-35B-A3B jsem narozdíl od ostatních modelů spustil (kvůli dostupné kapacitě) v FP8, čehož zpětně trochu lituji, protože to může hrát roli při interpretaci výsledků. Počítám ale, že pouze minimální, protože FP8 se ukazuje být oproti 16-bitovým formátům v podstatě bezztrátovým formátem.

Výsledky jsem následně oficiální cestou přidal do benchmarku, takže v současnosti už je tam najdete. Finální pořadí (k 7. 8. 2026) dopadlo následovně:

Výsledky vypadají obdobně, jako u EuroEval. DeepSeek-V4-Flash-0731 ale tentokrát potvrdil pozici největšího modelu a umístil se nejlépe, a gemma-4-31B-it předběhla Qwen3.6-27B.

Důležité je podívat se i na srovnání s ostatními modely. Na leaderboardu je v současnosti celkem 72 modelů. Modely, které sebraly zlatou a stříbrnou medaili, jsou Llama-3.1-405B-Instruct (405B parametrů) a DeepSeek-V3-0324 (685B parametrů). Pro nasazení bych si ale tyto modely z roku 2024 nevybral: náš bronzový DeepSeek-V4-Flash-0731 má sice celkový počet parametrů řádově podobný (304B), ale aktivních má pouze 13B a bude proto při nasazení mnohonásobně rychlejší. (Navíc se dá opět počítat s tím, že bude mnohem schopnější v agentních úlohách.)

Všechny modely, které předběhly gemma-4-31B-it, pak mají alespoň dvojnásobný počet parametrů, někdy i mnohem větší. To všechno potvrzuje, že se otevřené modely – alespoň ty s velikostí v řádu desítek a stovek miliard parametrů – zlepšují i v češtině.

Co si z toho vzít?

Porozumění je (celkem) jednoduché

Úlohy porozumění textu jsou pro nejnovější modely obecně celkem jednoduché. Tyto benchmarky proto začínají být saturované, což znamená, že se výkon modelů blíží horní hranici, které je v benchmarku možné dosáhnout. Například v BenCzechMarku mají modely na předních příčkách celkové skóre kolem 70–80 %.

Celkově je proto pouze na testech porozumění textu postupně těžší a těžší odlišit, který model je lepší. Dává to smysl: pokud nějaký jazyk znáte aspoň trochu, je dost možné, že jednoduchý test s výběrem z možností zvládnete poměrně dobře – narozdíl například od psaní eseje v tomtéž jazyce.

Pro menší modely je tento typ benchmarků ale stále relevantní: gemma-4-E4B-it má cca 46 % a například model csmpt7b (představený přímo v paperu BenCzechMark a natrénovaný čistě na českých datech) má výsledek lehce přes 5 %.

Modely můžou být chytřejší, než se zdá

Důvodem, proč modely ještě nemají na všech testech 100 %, je často “šum” – tedy chyby v konstrukci datasetu. Otázky v benchmarcích bývají extrahované automaticky nebo jen s minimální ruční kontrolou. Tyto problémy se ztratí v celkových číslech, ale vyplují na povrch, jakmile se zadíváme do dat.

Například mě zajímalo, proč DeepSeek získal na EuroEval poměrně nízké skóre v testech gramatické přijatelnosti. Podíval jsem se proto na konkrétní výstupy a u některých příkladů tzv. “správné” odpovědi jednoduše nedávají smysl:

Věta: Táta mi nikdy nekupuje věci 
Určete, zda je věta gramaticky správná nebo ne. Odpovězte 'ano' nebo 'ne', a nic jiné.

- odpověď modelu: ano
- správná odpověď: ne

Jeden by mohl argumentovat “na konci věty chybí tečka”. To ale naráží na mnohem zásadnější problém, a to je to, že zdrojový dataset prošel klasickou tokenizací, která odděluje slova od interpunkce. A tak většina příkladů v datasetu vypadá nějak následovně:

Věta: Protože v mém rodišti je teplo v zimě , nemohl jsem moc hrát zimní sport . 

Určete, zda je věta gramaticky správná nebo ne. Odpovězte 'ano' nebo 'ne', a nic jiné.

- odpověď modelu: ne
- správná odpověď: ano

Mohlo se tedy stát, že si model často myslel, že věta není správně, protože se před čárkou ani tečkou v češtině nepíšou mezery. Kdo ví?

Takovýchto artefaktů bývá ve vyhodnocovacích datasetech celá řada. Jakékoliv konkrétní číslo může tedy být mimo jednoduše proto, že jsme ho “špatně spočítali”.

Například při hledání jmenných entit v datasetu cs_ner v BenCzechMarku žádný z pěti promptů nespecifikuje, jak přesně má být nalezená entita prezentovaná. BenCzechMark navíc hodnotí generativní úlohy pomocí “exact match”. Takže se například stalo, že Qwen modely nalezenou entitu daly do prvního pádu (“Bayern”), což bylo vyhodnoceno jako špatná odpověď, oproti DeepSeeku, který entitu zkopíroval z textu v původní podobě (“Bayernu”):

(Divím se, že modely entitu vůbec našly, protože se prompt dotazoval “Jaká kulturní/vzdělávací/vědecká instituce je v tomto textu” a nejsem si úplně jistý, pod co spadá fotbalový klub.)

Dalším fenoménem je strojový překlad některých datasetů z angličtiny do češtiny. Tato praktika není ideální, ale občas je to ta nejschůdnější možnost, jak benchmark pro konkrétní jazyk vytvořit. A tak se v datasetu cs_naturalquestions (další ze součástí BenCzechMarku) například modelů ptáme:

• “kdy vyšla první kniha her o hladu?” (uznávané odpovědi: “14. září 2008” a “2008” – všimněte si, že ne například “září 2008” nebo “09/2008”)
• “kdo je první manželka na sesterských manželkách?” (odpověď: “Meri”)
• a nebo také “kdy vyhráli bojovníci zlatého státu finále?” (odpověď: “1947”).

Otázky z propaganda_ datasetů jsou pak částečně subjektivní: například “Obsahuje článek jasný osobní názor autora článku?” nebo “Relativizuje se v textu negativní konání Ruska nebo pozitivní zásluha Západu?” Je to typ otázek, u kterých by proti oficiálním odpovědím nejspíš přišla řada protiargumentů, kdyby se vyskytly jako maturitní úlohy.

Jsou zde ale i lepší příklady. Například datasety z oficiálních testů od CERMATu, které do BenCzechMarku převedli z PDF verzí jeho autoři ručně. Příklad:

Kontext: Tak zásadní krizi, v níž se ocitla Česká republika, jsme nezažili několik posledních desetiletích. Restaurace i obchody jsou zavřené, chybí nám kulturní a sportovní vyžití, prezenční výuka je zrušena na všech typech škol. Rozšiřují se řady těch, kteří nemají prostředky na zabezpečení základních životních potřeb. Zdravotníci jsou na pokraji sil. Je přirozené, že jsme leckdy naštvaní a že už nechceme být nikým a v ničem omezováni. Důsledné dodržování všech opatření vyhlášená vládou je mnohdy skutečně vyčerpávající. Všem, kteří nám pomáhají zvládnout nelehkou situaci, i všem, kteří se chovají zodpovědně, patří velký dík. (CZVV)

Dotaz: Najděte ve výchozím textu přídavné jméno, které se zde vyskytuje v chybně užitém tvaru, a napište ho v takovém tvaru, v němž má být v textu užito. Akceptovány budou pouze spisovné tvary slov.

Odpověď: vyhlášených

To mi celkem dává smysl. V agregovaných skóre na leaderboardu se ale signál z těchto rozumnějších datasetů ztratí – proto je důležité se dívat i na detailnější výsledky.

Nikdy nevíme, co se modely “našprtaly”

Na závěr se musíme pozastavit nad kontaminací dat.

U statických datasetů dostupných veřejně na webu je dnes automaticky potřeba předpokládat, že se tento dataset vyskytl v trénovacích datech modelů. Ano, první pravidlo strojového učení – netestovat na trénovacích datech – je v případě jazykových modelů rutinně porušováno.

Není to tak, že by se autoři benchmarků nesnažili proti tomu bránit. Například autoři BenCzechMarku v textu důrazně prosí:

We request that you do not reveal examples from this dataset in plain text or images online, to reduce the risk of leakage into model training corpora.

Tímto se omlouvám za publikování několika příkladů v tomto článku. Moje jednání je snad částečně ospravedlněno tím, že jsem paper dočetl až do sekce 7, kde autoři uvádějí následující:

[W]e checked all 50 submissions for the presence of a canary string. We acknowledge that Qwen2.5-32B model predicted canary string correctly, strongly indicating the model was trained on benchmark data. Hence we exclude Qwen2.5 models (Qwen Team, 2024) from the evaluation.

Tzv. “canary string” je unikátní textový řetězec, kterým autoři benchmarků doprovází svoje benchmarky a snaží se tím detekovat jejich memorizaci. Protože se tento textový řetězec nevyskytuje nikde jinde, pokud ho model umí vygenerovat, je zřejmé, že musel tento dataset vidět při trénování. A pokud ho tedy Qwen2.5 (model z roku 2024) uměl vygenerovat, znamená to velmi pravděpodobně, že se v obřích trénovacích sadách na trénování velkých jazykových modelů BenCzechMark už dávno vyskytuje.

Na kontaminaci dat se snažili vědci reagovat různě: upozorňováním na ni, zmíněnými canary stringy, přísným filtrováním trénovacích korpusů nebo dynamickými benchmarky. U statických datasetů to každopádně dospělo do bodu, kdy nad tím všichni tak trochu mávli rukou. Jakmile je jednou dataset vydaný, je prostě s kontaminací potřeba počítat. Modely ze série Qwen2.5 – i přes výše zmíněný disclaimer autorů – v současnosti na leaderboardu BenCzechMarku jsou.

Jak se tedy na kontaminaci dat dívat? Je to asi jako kdyby vám někdo zkoušku na následující den ukázal večer před tím na pár minut. To, že model daný příklad viděl při trénování, ještě neznamená, že dokáže dokonale zreplikovat všechny správné odpovědi. Modely mají omezenou kapacitu: model s 1B parametry si jednoduše nezapamatuje všechna trénovací data, ať se snaží jak chce. Přesto ale mohou být výsledky modelů, které testovací dataset viděly v trénovacích datech, lehce nafouknuté. Tento fenomén se dá těžko kvantifikovat – už jen proto, že za “kontaminaci” se dají považovat i problémy podobného typu.

Dá se ale nad tím zamýšlet na základě obtížnosti úlohy a jejího vztahu k trénování na této úloze. Například výše zmíněné testy jazykového modelování jsou kontaminací ovlivněné hodně. Pokud model text viděl v trénovacích datech, tak na něm bude mít zásadně nižší perplexitu, i kdyby to měl být jediný text, který v daném jazyce viděl.

Naopak pokud jde o složitější generativní úlohy, kdy model musí například označovat úseky v textu, a tedy nemůže pouze zreplikovat “co za textem někde následovalo”, už únik testovací sady do trénovacích dat hraje menší roli. A u úloh, které jsou dynamické (například benchmarky agentních úloh se simulátorem uživatele, ke kterým se dostaneme v posledním díle, nebo úlohy s herní povahou), už hraje roli pouze ta “nepřímá kontaminace” trénováním na úlohách podobného typu.

Co dál?

V tomto článku jsme získali lehkou představu o současném stavu: otevřené modely česky alespoň částečně umí.

Spoustu aspektů jsme ale zanedbali. Například jsme ještě modely nenechali vygenerovat žádný úsek textu delší než několik tokenů (v BenCzechMarku byla původně přítomná sumarizace, ale kvůli značné kontaminaci dat byla odstraněná).

Kromě kvality generovaného textu je to ale třeba i to, že zmíněné benchmarky neberou v úvahu reasoning. Je to dané jednoduše tím, že vznikly v době, kdy modely ještě “přemýšlet” neuměly, a proto se pro férové srovnání nenechávají přemýšlet ani novější modely. Z určitého pohledu to ale moc férové není: novější modely těží zásadně právě z této schopnosti “test-time scalingu”, kdy mohou při inferenci generováním dalšího textu získat lepší pozici pro řešení úloh.

Stejně tak jsme zatím nebrali v úvahu schopnosti modelů, které částečně generalizují skrz jazyky, ale jsou zásadní i pro použití v českém kontextu, jako je volání nástrojů.

Na tyto aspekty se proto podíváme v příštích dílech.

Generované texty jsou bohaté na detaily

Zakončil bych to teaserem na příští díl: srovnáním tří textů.

První text je přímo z paperu BenCzechMark (Figure 7). Vznikl z modelu Llama-3.2-3B (3B model z roku 2024) na základě systémového promptu “Jsi novinář.” a uživatelského promptu: “Ahoj, napiš mi krátký novinový článek o sametové revoluci.”

Ahoj, čteníci!

Smetová revoluce: Zánik monarchie a narození moderního Česka

Praha, 28. listopadu 1918 - Včerej večer se v Praze uskutečnil historicky významný akcí, který zanechal lastingý podpis na české historii. Smetová revoluce, také známá jako Velká revoluce, byla série protivládních protestů a demonstrací, které vedly k zániku monarchie a narození moderního Česka. V noci z 17. na 18. listopadu 1918 se v Praze sešlo stálice protivládního hnutí, které se zástupci ministerstva vnitra a armády sešli, aby se dohodli na rozpuštění monarchie a zavedení republiky. V 5.00 hodině večer se v ulicích Prahy beganovaly protesty a demonstrace, které quickly se rozšly na celostátní hnutí. […].

Zadal jsem stejný¹⁰ (Téměř: nerozlišoval jsem systémový a uživatelský prompt.) prompt dalším dvěma modelům z našeho srovnání.

Nejdřív gemma-4-E4B-it:

Sametová revoluce: Jak pokojný protest změnil tvář Československa

Praha/Brno – Dnes, kdy se na světovýchto poli neustále odehrávají politické bouře, je fascinující přehlídat příběh událostí, které dokázaly změnit celou politickou strukturu bez jediného výstřelu. Sametová revoluce, která se odehrála v Československu na konci roku 1989, zůstává jedním z nejzásadnějších příkladů, jak může civilní opozice a masivní lidská solidarita přemluvit režim k úступkům.

Tečlivé roky pod komunistickou vládou byly povznakem represí, absence svobody a ekonomického stagnování. Systém byl pevně zakotvený v ideologii, která se nechtěla vzdát, i když byla ztracená důvěru veřejnosti. Nicméně, na konci osmdesátých let začalo rostoucí napětí. […]

A na závěr DeepSeek-V4-Flash-0731:

Sametová revoluce: Týden, který změnil tvář Československa

PRAHA – Před pětatřiceti lety se v ulicích pražských měst odehrála událost, na kterou historie nezapomene. Sametová revoluce, jak ji dnes nazýváme, trvala pouhých sedmnáct dní a bez jediného výstřelu smetla komunistický režim, který zemi vládl přes čtyři desetiletí.

Vše začalo 17. listopadu 1989 – studentskou demonstrací u příležitosti výročí uzavření vysokých škol nacisty, která se brutálním zásahem policie změnila v masový protest. Solidarita s bitými studenty se šířila rychlostí blesku. O dva dny později se na Václavském náměstí sešly statisíce lidí. […]

Ti pozorní z vás nejspíš odhalili, že ještě máme na modelech co srovnávat.

Těším se na příště!