Umí agenti česky? Část 3: Zákaznická podpora

Tento článek je třetí v sérii o schopnostech současných otevřených modelů pracovat s českými texty. V prvním díle jsme testovali modely na porozumění textu, v druhém díle jsme navázali plněním instrukcí. Dnes se podíváme na českou konverzaci s uživatelem.

Musím se přiznat: v této sérii článků byli zatím “agenti” v názvu trochu clickbait. Testovali jsme spíš jednotlivosti jako porozumění textu, volání nástrojů, nebo generování textu na základě instrukcí. I tak jsme toho zjistili spoustu: třeba to, že čeština stojí i v malých a středních otevřených modelech na dobrém základu a že jejich schopnosti porozumět jazyku a plnit instrukce jsou jen lehce horší, než jejich schopnosti dělat stejný úkol v angličtině. Často šlo navíc při propadu skóre spíš o chybu evaluace, než modelu samotného.

Pořád jsme ale nevyužili schopnosti současných agentních modelů naplno. Modely možná zvládnou v češtině úkol splnit, ale nedělají chyby v generovaném textu? Není jejich český jazyk moc kostrbatý? A zvládnou modely v češtině vést i dlouhé, vícekolové konverzace?

V tomto článku proto tuto neznalost napravíme a důkladně otestujeme modely v komplexním agentním prostředí.

Články stavím i na vlastních experimentech, chci dát proto opět kredit výzkumné infrastruktuře, kterou jsem k experimentům 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ě.

τ-bench: simulátor zákaznické podpory

Experimenty v tomto díle budeme stavět na jednom konkrétním benchmarku pro vyhodnocení agentních modelů: τ-bench.

Původní verze τ-bench pochází z článku Yao et al. (2024). Autoři zde řeší, že většina existujících benchmarků je statická a netestuje modely na interakcích s uživatelem a nástroji. τ-bench proto navrhnuli jako dynamický simulátor agenta v roli chatbota na uživatelské podpoře.

V benchmarku jsou dvě domény: airline (aerolinky, 50 úloh) a retail (e-shop, 114 úloh). V obou musí agent interagovat s uživatelem a plnit jeho požadavky. Agent zároveň pracuje s databází, ze které čte informace a další do ní zapisuje.

To, že agent pracuje s databází, nám rovnou poskytuje jeden způsob, jak automaticky vyhodnotit úspěšnost interakce: na konci interakce zkontrolujeme její stav. Pokud si například uživatel chtěl koupit letenky, zkontrolujeme, jestli se tato transakce zapsala databáze.

Pokud se ale například uživatel dotazoval na stav svého letu, stav databáze se nezmění. V tomto případě potřebujeme zjistit, jestli je odpověď na dotaz správně zmíněna v odpovědi agenta. Na to využijeme LLM-judge:¹ Můžeme to zapisovat i jako “LLM-as-a-judge” nebo “LLM-as-judge”, tady jsem zvolil tu nejúspornější variantu. jazykový model, který plní roli evaluátora. Tento model dostane záznam konverzace s dotazem “Získal uživatel v této konverzaci požadovanou informaci?” a podle toho vyhodnotí, jestli interakce byla úspěšná.² Protože porozumění textu je obecně jednodušší než jeho generování, počítáme s tím, že LLM-judge nám vyhodnotí úspěšnost správně (obzvlášť pokud bude model stejný nebo schopnější, než model v roli agenta).

Protože se modely nechovají deterministicky, agent v tomto benchmarku každý úkol plní třikrát a jeho úspěšnost měříme pomocí pass^k: kolik úkolů agent splní (=tedy databáze je v požadovaném stavu a agent dal požadovanou odpověď) ve všech k pokusech.

Ještě nám zbývá jeden problém – to, jak nasimulovat uživatele. Pochopitelně nechceme najímat lidské anotátory: nejen, že by to bylo drahé, ale především bychom nemohli spouštět simulátor čistě automaticky. I uživatele tedy nasimulujeme jiným jazykovým modelem. Tento model může být klidně i stejný jako model, který vyhodnocujeme – měl by být ale především dostatečně schopný, aby dokázal věrohodně hrát uživatele v dané situaci.

A to je všechno! Tady je ukázka, jak to celé funguje, převzatá z článku Yao et al. (2024). Nalevo vidíme (a) nástroje, které agent využívá, (b) agenta s instrukcemi, jak se má chovat, (c) a uživatele, který dostal konkrétní identitu a cíl. Napravo pak vidíme, jak může taková konverzace vypadat:

Jen pro úplnost: od vydání původního benchmarku byly vydány další verze, v současnosti označované jako τ^2-bench a τ^3-bench. τ^2-bench opravuje některé chyby v původním benchmarku a přidává novou doménu telecom, ve které může využívat nástroje i uživatel. τ^3-bench pak přidává doménu banking, ve které se musí agent poprat nejen s databází, ale i s rozsáhlou dokumentací. My budeme stavět především na opravených verzích původních domén z τ-bench (což vyplývá z našich snah o lokalizaci, jak se dočtete dál).

CzTauBench aneb testujeme agenty v češtině

Zásadní věc jsem totiž zatím ještě nezmínil: τ-bench je vymyšlený pro angličtinu, ale my chceme vyhodnotit agenty v češtině.

τ-bench oficiálně v češtině sice není, ale jeho lokalizace je poměrně přímočará. Dokonce pro ni máme i vhodný precedens v článku Nguyen et al. (2026), kde autoři představili benchmark SEATauBench. V něm τ^2-bench lokalizují do jazyků jihovýchodní Asie (odtud “SEA” = south-east Asia): čínštiny, vietnamštiny, thajštiny, indonéštiny a filipínštiny.

Česká verze τ-bench: CzTauBench

V SEATauBench autoři představují tři možnosti, jak τ-bench lokalizovat:

1. pouze konverzace,
2. pouze schémata nástrojů,
3. celé lokalizované prostředí: konverzace, schémata nástrojů, popisky, databáze.

V našem případě jsem se rozhodl pouze pro tu první, nejjednodušší možnost: nepřekládat žádné zdroje ani nástroje a mít v češtině pouze konverzace. Toto hybridní prostředí je za mě nejzajímavější, protože je nejvíc realistické: nástroje a databáze na pozadí bývají většinou v angličtině i v případě, že uživatelská část aplikace má české rozhraní.

“Lokalizace” (zde opravdu v uvozovkách) je díky tomu navíc přímočará: jednoduše zainstruujeme jak agenta, tak uživatele, aby spolu mluvili česky, a zbytek benchmarku (rozhraní nástrojů, výsledky z databáze) používáme v originále.³ Možnost, kde je schéma databáze a konkrétní reálie (jména atd.) v češtině, by mohla být také zajímavá. Udělat to správně už by ale bylo náročnější. Abychom mohli opět oddělit schopnosti modelu jako takového od jeho jazykových schopností, spustíme agenty zároveň i na původní, anglické verzi, a napočítáme si na ní “baseline” výsledky.

SEATauBench oproti původnímu benchmarku vyhodnocuje jednu věc navíc: snaží se detekovat, jestli agent opravdu mluví (resp. píše) jazykem, který má používat. Využívá k tomu knihovnu fastText, která dokáže pomocí jednoduchého klasifikátoru určit jazyk zadaného úseku textu. To samé budeme dělat i pro češtinu.

Pokud jde o model pro roli uživatele a LLM-judge, rozhodl jsem se pro ně využít Kimi K3, jeden z nejschopnějších otevřených modelů současnosti. Tento model v řadě benchmarků dorovnává nebo překonává i modely jako Claude Opus 4.6, a je tedy pravděpodobně lepší volbou, než původní modely v benchmarcích.⁴ Autoři SEATauBench využili pro roli uživatele model Qwen/Qwen3-235B-A22B-Instruct a pro roli LLM-judge gpt-4.1. Qwen už ale není moc aktuální a jak autoři podotýkají, jeho horší schopnosti simulovat uživatele nejspíš mohly částečně kompromitovat výsledky. Podobně je to s gpt-4.1, což je navíc placený model. Náš benchmark navíc kvůli české lokalizaci stejně není s touto verzí srovnatelný – radši to tedy uděláme lépe. Kimi K3 navíc díky e-INFRA mohu využívat v rámci výzkumné infrastruktury přes API, za což jim děkuji.

Jak měříme kvalitu jazyka

Je tu jedna věc, která mi přijde dost zásadní a kterou ani lokalizovaná verze τ-bench netestuje: kvalitu jazyka. Rozhodl jsem se proto přidat vyhodnocení chyb na úrovni textových spanů.⁵ Tímto typem evaluace jsem se zabýval nějakou dobu výzkumně. (1, 2, 3). Konkrétně jsem využil našeho LLM-judge, aby v českých výstupech agenta označil konkrétní chybné úseky textu jako “major” nebo “minor” chybu:

• Major chyby jsou definované jako klasické mluvnické chyby, tedy chyby, které by odhalila i běžná kontrola pravopisu a gramatiky.
• Minor chyby jsou definované jako nepřirozené fráze: tedy výrazy, které jsou sice gramaticky správně, ale rodilý mluvčí by je takto nepoužil.

Protože LLM-judge má v těchto případech tendenci dlouho přemýšlet a vyhodnocení je kvůli tomu poměrně pomalé, rozhodl jsem se vyhodnotit pouze jediný ze tří pokusů pro každou úlohu.

Jaké modely testujeme?

Stejně jako v předchozích dílech budeme testovat následující pětici modelů:

Všechny Qwen a Gemma modely byly spuštěné v původní kvalitě (tedy bf16) lokálně, pro DeepSeek jsem využil e-INFRA API. U všech modelů máme tentokrát zapnutý reasoning.

Shrnutí

Abychom si to shrnuli. Náš benchmark má následující obsazení:

A měříme následující metriky:

• pass^k – kolik úkolů model vyřeší (=konzistentní DB + správná odpověď) ve všech k pokusech.
• správnost jazyka – kolik agentových replik fastText označí za správný jazyk,
• major / minor jazykové chyby – kolik jazykových chyb se objeví ve výstupech agenta (pouze pro češtinu).

Připomínám, že Kimi K3 zde netestujeme: používáme ho pouze k tomu, aby nám nasimuloval věrohodné testovací prostředí.

Úspěšnost agentů

Pojďme se nejdřív podívat na celkové výsledky a následně na konkrétní ukázky (ty jsem se tentokrát rozhodl pro přehlednost až na konec článku, protože jsou celkem objemné).

airline: zákaznická podpora aerolinek

Modely se se svojí rolí zákaznické podpory aerolinek popraly poměrně úspěšně. Výsledky z metriky pass^1 (tedy jak často model úlohu splnil, průměrováno přes jednotlivé pokusy) pro airline doménu vypadají následovně:

Vypadá to, že propad na češtinu oproti angličtině je podobný nehledě na schopnosti modelů, a to 4 až 10 procentních bodů. Nejslibnější model je deepseek-v4-flash-0731, který má nejlepší výsledky jak na angličtině (88,0 %), tak na češtině (80,7 %). Největší propad tu nastává u modelu qwen3.6-35b-a3b, který má jinak výsledky na angličtině velmi silné (88,0 %, tedy na úrovni DeepSeeku), ale v češtině se propadne na 78,0 %. Nejmenší propad pro češtinu má pak gemma-4-e4b, ale tento malý model má špatné výsledky obecně (60,7 % v angličtině, 56,7 % v češtině).

Zajímavé je se podívat na výsledky metriky pass^3, tedy jestli model dokázal úlohu splnit při všech třech pokusech:

Zde překvapí svoji konzistencí gemma-4-31b, která má na češtině dokonce o něco lepší výsledky než na angličtině (72,0 % v angličtině, 74,0 % v češtině). Toto u jiných modelů nenastává, například qwen3.6-35b-a3b se naopak propadne ještě více (78 % v angličtině, 62 % v češtině).

retail: zákaznická podpora e-shopu

Výsledky pro zákaznickou podporu e-shopu vypadají obdobně jako pro aerolinky:

Nejlepší výsledky má opět deepseek-v4-flash-0731: 89,5 % na angličtině a 86,5 % na češtině. Jediný model, který se na češtině nepropadl, ale drobně zlepšil, je gemma-4-31b. Naopak malá varianta Gemmy, gemma-4-e4b, se v češtině propadne velmi výrazně: ze 71,1 % na 55,3 %. Na češtině se lehce propadají i Qwen modely, tentokrát to ale platí více pro dense variantu qwen3.6-27b.

Obdobné trendy můžeme pozorovat i na metrice pass^3:

Rozdíly mezi modely zde začínají být výraznější a u většiny z nich se propad na češtinu oproti pass^1 prohlubuje. Zdá se tedy, že konzistence v češtině trpí o něco víc – s výjimkou gemma-4-31b, která si drží stejné skóre v obou jazycích.

Kvalita jazyka

Pojďme se ještě podívat na souhrnná čísla ohledně kvality jazyka.

Nejprve ta jednodušší část, konzistence jazyka – tedy jestli model opravdu mluví česky, když má mluvit česky. Vypadá to, že modely zvládají nepřepínat do angličtiny, případně do jiného jazyka, poměrně robustně. FastText skóre (které si můžete v detailu prohlédnout na stránce s výsledky, sloupec LANG OK) se u všech modelů pohybuje blízko 100 % (na konkrétní problémy se podíváme v následující sekci).

Zajímavější je analýza jazykových chyb. Zde se nám v číslech ukazuje něco, co nám neodhalila žádná předchozí analýza – jak přirozeně budou znít výstupy z modelů:

Podrobnější výsledky:

Vítězem je zde deepseek-v4-flash-0731, jehož výstupy obsahují naprosté minimum závažných chyb (0,21 na úlohu). Méně závažných chyb (tedy neobratných formulací) ale již obsahuje poměrně dost (2,13 na úlohu), což je zhruba na úrovni modelů qwen3.6-27b (2,96 na úlohu) a gemma-4-31b-it (2,32 na úlohu). Tyto dva modely tvoří pár s velmi podobnými výsledky.

O úroveň horší je qwen3.6-35b-a3b, v jehož výstupech je sice podobně major chyb jako u 27B verze, ale dvojnásobek minor chyb. Zcela se pak podle očekávání propadá gemma-4-e4b-it, která má oproti větším modelům více než dvojnásobek zásadních, pravopisných chyb.

Jazykových chyb dělají modely obecně poměrně dost. Pro lepší představu si doporučuji projít vizualizaci výstupů modelů s anotacemi chyb: po najetí na chybu se zobrazí i zdůvodnění od LLM-judge. Na konkrétní příklady se podíváme i v následující sekci.

Ukázky

Všechny výstupy modelů můžete najít v této vizualizaci výsledků pod linkem trajectories.

Úspěšná interakce

Pojďme si dát pro začátek ukázku typického případu, ve kterém model uspěl v obou jazycích. Vybral jsem krátký příklad z airline domény, ve kterém deepseek-v4-flash-0731 pomáhá zákazníkovi zjistit celkový počet zavazadel, na který má u letu nárok. Zákazník se zároveň na základě instrukcí hádá o tom, jestli je Gold nebo Silver member – kvůli tomuto nesouladu je nakonec přepojen na lidského asistenta:

Můžete si všimnout, že konverzace probíhají lehce jinak – v češtině dokonce došlo k jedné výměně názorů navíc. Výsledek je ale správný v obou případech. Máme zde navíc znázorněno pár neobratných výrazů od agenta (“Děkuji za čekání”, “Jako silver člen”). Připomínám, že jazyk uživatele (kterého “hraje” Kimi K3) nehodnotíme.

Neúspěšná interakce v češtině

Zde je příklad interakce z retail domény, ve které hrál roli agenta qwen3.6-35b-a3b. Agent zde v češtině udělal chyby v uvažování, které v angličtině neudělal: jednak špatně identifikoval nejlevnější položku, jednak špatně pochopil chybovou hlášku a vyměnil všech pět položek místo tří:

Stejnou chybu agent udělal ve všech třech českých interakcích, ale ani v jedné anglické interakci. Není zcela zřejmé, co ho k tomu vedlo, protože se nejedná o vysloveně jazykový problém. Je ale možné, že jde o odraz toho, že uvažování o anglických instrukcích nebo výsledcích nástrojů a současné interakci v češtině je pro modely obecně o něco náročnější.

Jazyková konzistence

Ve výsledcích se objevilo několik specifických případů, ve kterých byla odpověď modelu podle fastText klasifikátoru v jiném jazyce. Celkem závažný případ u gemma-4-31b-it je tento, kde proniklo uvažování modelu do výstupu (“The user wants to return an air purifier and a vacuum cleaner from a recent order. […]”):

Toto chování je nepříjemné, ale poměrně ojedinělé.

Další závažný problém se objevil u stejného modelu (gemma-4-31b-it) v následující ukázce. Odpovědi modelu se zde poměrně neočekávaně rozbily. Model nejdřív přepne do angličtiny (“Moj deepest condolences for your loss. […]”) a následně začne míchat do českého textu azbuku (“Upřímně vám співčuji v této těžké situaci.”):

Pro tento model jde o velmi nestandardní chování – ve většině ostatních případů jsou výstupy konzistentnější a kvalitnější. Tipuji, že model zde vyvedlo “z míry”⁶ Respektive z trénovací distribuce. chování zákazníka v podání Kimi K3, který pojal instrukci k vysoké míře expresivity až moc doslova: začal vkládat své “emoce” přímo do textu: “Dobrý den… *hlas se mi chvěje* Potřeboval bych změnit datum letu”.

Za řadu dalších problémů v identifikaci jazyka ale mohl samotný fastText. Ten pochopitelně není perfektní a problémy má obzvlášť s identifikací krátkých frází. A protože měl klasifikátor k dispozici pouze každou promluvu zvlášť, tak například vytrvale označoval fráze “Na shledanou”, “Nashle!” nebo “Sbohem!” za maďarštinu, němčinu nebo estonštinu.

Ukázky jazykových chyb

Výsledky ohledně kvality jazyka najdete ve vizualizaci na samostatné stránce, kde můžete procházet jednotlivé chyby.

Několik major (tedy mluvnických) chyb na ukázku, jednu od každého modelu (jde o náhodně vybrané ukázky, ne typické případy):

• deepseek-v4-flash-0731: “Podívám se na vaše objednávky, abych našel ten s fotoaparátem” (špatná shoda s předmětem “objednávky”)
• qwen3.6-35b-a3b: “Rád vám pomohu s zrušením rezervace.” (místo “se zrušením”)
• qwen3.6-27b: “Nyní ohledně výměny hodinky:” (nevyskloňované “hodinek”)
• gemma-4-31b-it: “let byl zrušen aerinkou” (místo “aerolinkou”)
• gemma-4-e4b-it: “Jakmile mi poskytnete všechny tyto informace, předstihně vám shrnu všechny změny” (špatné slovo, pravděpodobně mělo být “předem”)

A podobně ukázky minor chyb (tedy neobratného jazyka), které většinou vycházejí z přílišné inspirace angličtinou:

• deepseek-v4-flash-0731: “což je více než 24 hodin zpět” (“24 hours ago”, lepší by bylo “před více než 24 hodinami”)
• qwen3.6-35b-a3b: “budete mít vráceno 13,46 USD” (“You will be refunded”, lepší by bylo “bude vám vráceno” nebo “vrátíme vám”)
• qwen3.6-27b: “jak to politika vyžaduje” (neobratný překlad “policy”, lepší by bylo např. “zásady”)
• gemma-4-31b-it: “K doplatě:” (místo “k doplacení”)
• gemma-4-e4b-it: “Také, pro zrušení rezervace potřebuji vědět” (začátek ve stylu “Also, …”, lepší by bylo zařadit slovo “také” do pozdější části věty)

Tyto problémy jsou ve výstupech modelů poměrně časté a stojí za úvahu, jestli nejsou rozhodujícím faktorem proti nasazení modelů.

Závěrem

V této sérii postů jsme otestovali pět současných otevřených jazykových modelů na češtině. Sám jsem neměl o výkonu současných modelů v našem mateřském jazyce dobrou představu, takže to bylo zajímavé cvičení.

Z experimentů bych vypíchl následující:

• Malé a střední modely už jsou na češtinu použitelné. Ještě tak před dvěma lety by modely podobné velikosti pravděpodobně pohořely na většině úloh, teď už tomu tak ale rozhodně není. Modely na první pohled umí česky poměrně plynule a je potřeba jít do mnohem větší hloubky, abychom nějaké chyby odhalili.
• Rozdíl mezi češtinou a angličtinou tu ale stále je. V úlohách, kde na jazyce nezáleží, bych si vždy vybral pro provoz modelu angličtinu – modely byly v češtině v podstatě vždy lehce horší. Do nějaké míry mohla za rozdíl ve skóre nedokonalá lokalizace benchmarku, případně nedokonalé evaluační metriky, jsou zde ale i případy, kdy modely zaškobrtly v češtině tam, kde v angličtině ne.
• Pro seriózní použití v češtině volte model s >10B aktivními parametry. Náš jediný model, který měl méně než 10B parametrů celkově, byla gemma-4-e4b. Tento model se oproti ostatním modelům celkem zásadně propadal na všech testovaných úlohách. Problematický ale byl i MoE model qwen3.6-35b-a3b s 3B aktivními parametry.
• Volte model s co nejvíce parametry celkem. Mezi ostatními modely už tak velké rozdíly nebyly, z našeho srovnání ale obecně vyšel nejlépe deepseek-v4-flash-0731, který má přitom méně aktivních parametrů (13B) než qwen3.6-27b nebo gemma-4-31b. Zmíněná Gemma 4 s 31B parametry se mu ale často vyrovnala. Rozhodování mezi těmito typově rozdílnými modely proto stojí především na vašem hardwaru. (Doporučení samozřejmě stojí na tom, že volíte mezi modely s podobným datem vydání.)
• Dávejte pozor na evaluaci. V řadě případů nemohl za propad ve skóre model jako takový, ale chybný způsob, kterým jsme ho vyhodnotili. Tento problém navíc často nastal právě kvůli lokalizaci benchmarku: proto se může stát, že model vyjde v české verzi původně anglického benchmarku jako horší, než ve skutečnosti je.
• Čtěte výstupy, často tam čekají překvapení. Poučení na závěr, které se nedá zopakovat dostatečně často: vždy se dívejte na konkrétní výstupy modelů, nejlépe na co nejnáročnějších úlohách. Největší slabiny modelů se v naší, poměrně dlouhé sérii experimentů objevily až v posledním srovnání kvality jazyka, kde jsme objevili, že modely – i přes to, že samotnou úlohu vyřešit zvládají – se v češtině poměrně hodně drží nepřirozené, “anglické” struktury vět. Dokážu si představit, že v případě psaní dokumentů, které budou číst lidé, to může být rozhodující faktor. Uvidíme, jestli se i v tomhle další generace modelů zlepší.

Připomínky, dotazy? Pište na Discord!