Jak hodnotit kvalitu automatického rozpoznávání řeči tak, aby výsledky odpovídaly reálnému použití? Místo samotné chybovosti přepisu jsme se zaměřili na to, zda systém správně rozpozná klíčové entity. V článku představujeme nový evaluační framework i způsob, jak jsme s využitím LLM modelů automatizovali anotaci dat a ladění promptů.
Automatické rozpoznávání řeči (ASR) je dnes klíčovou součástí hlasových asistentů, vyhledávání i e-commerce systémů. V Seznamu se ASR systém používá v klíčové službě Seznam Asistent, kde uživatelům umožňuje přirozeně komunikovat s AI službami také pomocí hlasu.
Jeho kvalita se tradičně hodnotí pomocí metriky WER (Word Error Rate), která měří chybovost slov v přepisu. Například hodnota WER = 0,01 znamená, že 1 % slov bylo v přepisu rozpoznáno nesprávně. Tato metrika je v ASR komunitě velmi rozšířená díky své jednoduchosti a snadné interpretaci.
U pokročilých systémů však naráží na zásadní limit: nezohledňuje význam ani důležitost jednotlivých slov. Na příkladech z e-commerce je dobře vidět, že WER postrádá potřebnou citlivost.
Porovnání referenčního textu (označen jako REF) s přepisem modelu (označen jako HYP) pomocí knihovny JiWER. Písmeno S označuje chybu záměny (Substitution), písmeno D chybu smazání slova (Deletion). První věta dosahuje hodnoty WER = 10.00 %, druhá věta WER = 33.33 %.
Na prvním příkladu je WER relativně nízká (10 %), přesto dochází k zásadnímu neporozumění. Systém sice správně rozpoznal většinu slov, ale selhal v identifikaci klíčové informace – konkrétního produktu. Právě tato informace je pro uživatele zásadní. Navazující nástroje, zejména postprocessing pomocí LLM, jsou sice schopné opravit různé artefakty vzniklé chybným přepisem, nedisponují však dostatečným kontextem pro opravu nesprávně identifikovaného produktu. Taková entita se totiž z pohledu jazykového modelu jeví jako validní a významově konzistentní, a model proto nemá důvod ji považovat za chybu.
Naopak druhý příklad vykazuje výrazně vyšší WER (33,33 %), avšak všechny klíčové informace potřebné pro správné pochopení uživatelského záměru zůstaly zachovány. Následný postprocessing pomocí LLM modelu je navíc schopen většinu těchto chyb opravit, protože nedochází ke ztrátě zásadního významu ani klíčových entit. Z pohledu reálného nasazení je proto takový výstup výrazně hodnotnější, přestože tradiční metrika WER naznačuje horší kvalitu přepisu.
Oblíbenou variantou metriky WER je CER (Character Error Rate), která se – jak název napovídá – nezaměřuje na chybovost celých slov, ale na chybovost jednotlivých znaků. CER vykazuje podobné vlastnosti jako WER, poskytuje však jemnější granularitu hodnocení. Díky tomu je citlivější na drobné rozdíly v přepisu a umožňuje detailnější analýzu konkrétních částí textu.
Tato vlastnost je užitečná zejména při vyhodnocování krátkých textových úseků, kde i nepatrná změna může vést ke změně významu nebo ovlivnit správnou identifikaci klíčové informace. Na dříve uvedeném příkladu však CER vykazuje obdobné limity jako metrika WER. Přestože dokáže přesněji zachytit míru odchylky mezi referenčním textem a přepisem, stále nerozlišuje informační důležitost jednotlivých částí textu.
Současné SOTA poznatky ukazují, že vhodnější metriky se stále aktivně hledají. Mezi kandidáty patří přístupy založené na porovnávání významu textů pomocí LLM modelů nebo pomocí kosinové podobnosti embeddingů. Tyto metriky však trpí horší interpretovatelností a v případě LLM i vyšší cenou evaluace.
Další směr kombinuje WER s metrikami z oblasti NER (Named Entity Recognition), například NE-WER nebo přístupy využívající LLM, které se zaměřují na extrakci klíčových entit. Tento přístup umožňuje lépe zachytit, jak dobře systém rozpoznává důležité informace, a zároveň si zachovává dobrou interpretovatelnost.
Navrhované řešení spočívá v přechodu od hodnocení celého textu k hodnocení klíčových entit. Místo otázky „Kolik slov bylo rozpoznáno správně?“ si klademe otázku „Zachytil systém to, co je skutečně důležité?“.
Na základě uživatelských potřeb jsme definovali následující kategorie entit, které jsou klíčové pro naši službu Seznam Asistent:
Aktuálně používáme pro vyhodnocení ASR systému pro službu Seznam Asistent dataset založený na reálných uživatelských situacích a záměrech, které musí asistent běžně řešit. Tento dataset obsahuje pouze audio nahrávky a jejich správné přepisy vytvořené lidskými anotátory. Pro evaluaci ASR systému pomocí metriky WER je takový dataset dostatečný, avšak pro přechod k evaluaci založené na extrakci klíčových entit je nutné tyto entity v datech explicitně anotovat – ideálně včetně jejich kategorie a přesného word spanu v textu.
Cílem bylo vytvořit řešení, které umožní rychlou anotaci dat a zároveň snadné rozšiřování o nové kategorie entit s minimálními náklady, a také možnost efektivně generovat entity pro další datasety. Z tohoto důvodu jsme zvolili přístup strojového učení s využitím LLM modelů jako automatizovaných anotátorů.
Úlohy typu NER jsou v prostředí strojového učení standardní úlohou a obecné modely, jako jsou LLM, se ji nebo velmi podobné úlohy učí již během pre-training fáze. Současný výzkum i naše zkušenosti ukazují, že LLM modely dokážou kvalitativně konkurovat lidským anotátorům, přičemž výrazně vynikají zejména v rychlosti a škálovatelnosti. Pro konkrétní využití LLM jako anotátoru je však nutné provést jeho alignment s definicí úlohy pomocí promptu. Postup tohoto alignmentu je následující:
Nejprve jsme si v týmu potřebovali přesně vymezit předem definované entity – jejich význam i rozsah. Na základě toho jsme vytvořili základní anotační pravidla, která posloužila jako úvodní prompt pro LLM model GPT-5. Ten jsme následně použili k extrakci entit z reálných přepisů v rámci našeho „asistentního“ datasetu. Tento prvotní průchod LLM modelem nám poskytl základní data, díky nimž jsme mohli dále zpřesňovat anotační pravidla pro jednotlivé entity.
Zároveň jsme na základě takto získaných entit provedli samplování datasetu pro anotace tak, aby výsledné rozložení co nejvíce odpovídalo rovnoměrnému zastoupení jednotlivých kategorií. Samplování probíhalo náhodně s cílem zachytit co nejširší variabilitu příkladů a zároveň omezit množství případů bez výskytu entit. U některých kategorií jsme zahrnuli všechny dostupné příklady, zatímco u jiných (např. lokality) bylo nutné jejich výskyt pod-samplovat.
Po samplování následovala deduplikace, protože v rámci jedné audio nahrávky se může vyskytovat více pojmenovaných entit. Tímto postupem jsme připravili stovky příkladů. Dataset jsme následně doplnili o přibližně 20 % negativních ukázek, tedy záznamů bez detekovaných entit, abychom mohli lépe monitorovat i výskyt false positives. Distribuci kategorií před a po samplování ilustruje následující obrázek.
Ilustrace procesu vytváření evaluačního datasetu včetně samplování a deduplikace jednotlivých kategorií entit.
Samotné anotace jsme vytvářeli přímo v týmu, abychom si prakticky ověřili podobu jednotlivých příkladů v datasetu. Proces byl rozdělen do dvou kol. V prvním kole jsme se zaměřili především na doladění anotačních pravidel a jejich sjednocení mezi anotátory.
Druhé kolo pak představovalo kompletní reanotaci všech příkladů podle nově upřesněných pravidel. Klíčovým cílem bylo zajistit vysokou přesnost a konzistenci napříč anotátory, protože tyto faktory zásadně ovlivňují následnou evaluaci modelu. Celý proces probíhal v prostředí Label Studia, které nám umožnilo rychle vytvořit anotační rozhraní a efektivně realizovat samotné anotace. Následující obrázek ukazuje, jak vypadalo anotování příkladů v Label Studiu.
Použité anotační rozhraní v prostředí Label Studio.
Evaluační dataset jsme rozdělili na dvě nepřekrývající se části – development a test – abychom předešli tzv. label leakage. Na development části jsme ladili prompt, protože dle literatury přináší few-shot prompting výrazně lepší výsledky. Dataset jsme rozdělili v poměru 1:3, přičemž jsme se snažili zachovat co největší část dat pro vyhodnocení experimentu.
Ladění promptu probíhalo iterativně v několika krocích:
Jak vidíme na obrázku níže, optimalizaci promptu je možné do značné míry automatizovat pomocí generativních modelů. V našem případě jsme iterativně generovali nové verze promptu na základě chyb z předchozí iterace na development datasetu (1, 2), čímž jsme postupně vytvářeli robustnější few-shot prompty s lepšími výsledky. Postupnou iterací se nám podařilo zlepšit výsledky promptu z hodnoty 0.47 až na 0.71 (popis metriky viz níže) pro nejlepší nalezený prompt (5, 6).
Nejlepších výsledků jsme dosáhli při automatickém generování nového promptu z dosud nejlepší varianty a chyb identifikovaných na development setu. Výsledný prompt byl následně dále upraven pomocí specializovaných instrukcí pro LLM (3, 4).
Ilustrace procesu optimalizace promptu.
Podobně kvalitní výsledky přinesla také automatická optimalizace pomocí knihovny DSPy, kde jsme využili genetický algoritmus GEPA. Nevýhodou tohoto přístupu je však vysoký počet nutných evaluací, a tím i vyšší náklady na celý proces.
Při tvorbě promptu jsme se snažili co nejpřesněji specifikovat zadání úlohy tak, aby model měl co nejmenší prostor pro vlastní interpretaci. Prompt proto obsahuje nejen detailní definice jednotlivých entit, ale také explicitní popisy případů, které naopak za pojmenované entity nepovažujeme. Tyto negativní příklady vycházely z chyb identifikovaných na development datasetu.
Ukázka promptu pro kategorie jména.
Na předchozí ukázce části promptu je vidět, že samotný prompt je psán v anglickém jazyce, zatímco příklady uvnitř promptu jsou uvedeny v češtině. Dlouhodobě pozorujeme na různých úlohách, tak se tato vlastnost LLM projevuje i na této úloze, že pro LLM modely bývá výhodnější formulovat instrukce a popis zadání v angličtině, zatímco konkrétní příklady ponechat v jazyce samotné úlohy.
Tento přístup vede k konzistentnějším a kvalitnějším výsledkům, pravděpodobně díky tomu, že jsou modely primárně optimalizovány na anglické instrukční datasety, zatímco jazykově specifické příklady pomáhají lépe zachytit lokální lingvistické vlastnosti daného jazyka.
Zároveň jsme usilovali o co nejkratší a nejstručnější formulaci promptu, aby model neměl problémy s prací v delším kontextu. Důležitým požadavkem bylo také to, aby model extrahoval entity přesně v podobě, v jaké se nacházejí v textu, nikoliv jejich normalizované nebo jazykově upravené varianty. Model tedy nesměl měnit skloňování ani generovat lingvisticky korektnější přepisy entit.
Pro zvýšení robustnosti řešení jsme využili i standardizovaný mechanismus strukturovaného výstupu, který moderní LLM modely podporují, konkrétně definici výstupního JSON formátu pomocí schématu pydantic.BaseModel. Tím jsme minimalizovali problémy s parsováním odpovědí a zároveň omezili prostor pro halucinace modelu. Celkově se všechny tyto kroky zaměřovaly na maximalizaci konzistence a determinističnosti výstupu modelu.
Tato část promptu obsahuje explicitní instrukce, že je pro nás podstatnější precision extrahovaných entit než jejich recall.
Celý prompt je psán ve formátu Markdown, na který jsou moderní LLM modely velmi dobře adaptované. Tento formát je zároveň přehledný i pro člověka, což usnadňuje jeho údržbu, úpravy i další rozšiřování. Díky jasné struktuře lze efektivně oddělovat jednotlivé části promptu, jako jsou definice entit, pravidla, negativní příklady nebo instrukce pro výstupní formát, což přispívá jak ke kvalitě modelových odpovědí, tak k jednodušší správě promptu během experimentování.
Závěr promptu rekapitulující klíčová pravidla pro generování odpovědi.
Pro evaluaci jednotlivých experimentu sledujeme metriky Exact Match (přesná shoda mezi anotovanou a extrahovanou entitou) a CER (Character Error Rate). Tyto metriky počítáme jak pro jednotlivé kategorie entit (deskriptivní metriky), tak i jako průměr přes všechny entity (optimalizační metrika). Kategorie přitom nijak nevážíme, protože každá z nich je pro nás stejně důležitá.
Při výpočtu těchto metrik ve skutečnosti hodnotíme dvě schopnosti modelu zároveň: jednak jeho schopnost entitu vůbec najít (extrakce), a zároveň správně určit její kategorii (klasifikace). Na základě tohoto zjištění jsme do evaluace doplnili ještě samostatnou metriku zaměřenou čistě na extrakční schopnosti modelu, která abstrahuje od následné klasifikace. Tabulka níže ukazuje rozdíl mezi extrakcí a kombinovanou metrikou extrakcí s klasifikací.
| Model | Extrakce + Klasifikace | Extrakce | CER |
| SeLLMa | 0,71 | 0,72 | 0,24 |
Výsledky nejlepšího promptu na testovacím datasetu.
Z výsledků je patrné, že model dosahuje vyšší úspěšnosti při samotné extrakci entit (0,72) než při jejich současné klasifikaci (0,71), což odpovídá rozdílu jednoho procentního bodu.
Jeden z našich hlavních požadavků byl důraz na precision extrahovaných entit. Bylo pro nás zásadní, aby každá entita označená modelem byla skutečně správná, zatímco neodhalení některých entit bylo do určité míry akceptovatelné – tedy menší důraz na recall. Tomu jsme přizpůsobili i evaluaci: model byl penalizován za extrakci neexistujících entit (false positives), zatímco opomenuté entity (false negatives) penalizovány nebyly. Navzdory této prioritizaci se nám podařilo dosáhnout relativně vysokého recallu, přibližně 79 % pro samotnou extrakční část úlohy (bez ohledu na správnost klasifikace).
Na závěr je vhodné zmínit drobnou nekonzistenci v některých výsledcích (např. v hodnotách metriky Extrakce napříč experimenty). Ta je způsobena samotnou povahou LLM modelů – i při nastavení temperature = 0, které má zajistit deterministické chování, může docházet k mírným odchylkám ve výstupech. Tyto rozdíly jsou pravděpodobně důsledkem nasazení modelu napříč více datovými centry a různými hardwarovými konfiguracemi, což se v konečném důsledku promítá do jemných variací ve výsledcích evaluace.
Po vytvoření promptu pro LLM model alignovaného na danou úlohu jsme byli schopni extrahovat definované entity z libovolného datasetu. Stále nám však chyběla vhodná metrika, která by dokázala srozumitelně vyjádřit kvalitu modelu nad těmito entitami.
Z důvodu transparentnosti a dobré interpretovatelnosti jsme zvažovali využití metrik WER (Word Error Rate) a CER (Character Error Rate), aplikovaných pouze na text vymezený spanem entity. Při vyhodnocování modelů jsme zjistili, že obě metriky spolu do značné míry korelují. Detailnější analýza však ukázala, že metrika CER poskytuje jemnější rozlišení a pro výzkumné účely nabízí lepší granularitu při odhalování menších rozdílů mezi jednotlivými modely.
Po zvážení jsme se proto rozhodli používat CER jako hlavní metriku pro evaluaci výzkumných experimentů. Současně však sledujeme i metriku WER, která poskytuje intuitivnější pohled na správnost rozpoznání entit jako celků. To je důležité zejména proto, že typická pojmenovaná entita obsahuje pouze 1–3 slova a i drobná změna v přepisu může vést k významné změně jejího významu. Kombinace obou metrik nám tak umožňuje hodnotit jak jemné rozdíly na úrovni znaků, tak celkovou správnost rozpoznání jednotlivých entit.
Posledním krokem bylo vyřešit správné zarovnání mezi ground truth textem a predikcí modelu, abychom byli schopni spolehlivě identifikovat odpovídající části entity v predikci. K tomu jsme využili knihovnu JiWER, která kromě výpočtu zmíněných metrik poskytuje i nástroje pro zarovnání dvou textů, což je pro tento typ evaluace klíčové.
Výsledky open-source modelů a interního modelu na interním testovacím datasetu. Metrika CER představuje standardní výpočet Character Error Rate. CER NER Mean je metrika CER počítaná pouze nad textovými úseky vymezenými pojmenovanými entitami, přičemž výsledná hodnota představuje průměr přes všechny definované kategorie entit. CER NER Mean [Alpha Lower] využívá stejný výpočet jako CER NER Mean, avšak před samotným vyhodnocením je na vstupní text aplikován preprocesing zahrnující převod na malá písmena a odstranění speciálních znaků.
Výsledky open-source modelů a interního modelu na interním testovacím datasetu. Metrika CER NER představuje hodnotu Character Error Rate počítanou pouze nad textovými úseky vymezenými NER entitami. Metrika je vyhodnocována samostatně pro každou kategorii entit.
Na výsledcích můžeme vidět, že nová metrika CER NER aktuálně poměrně dobře koreluje s klasickou metrikou CER, zároveň nám však poskytuje výrazně detailnější pohled na kvalitu modelu. Díky rozdělení podle jednotlivých kategorií entit dokážeme lépe identifikovat konkrétní silné i slabé stránky modelů.
Velmi dobrých výsledků dosahuje například kategorie commands and intents, což je dáno především tím, že se skládá z běžně používaných slov a formulací, které se často vyskytují v trénovacích datech i přirozené řeči. Naopak nejhorších výsledků napříč modely dosahuje kategorie exact product name, protože často obsahuje neobvyklé názvy, kombinace znaků nebo sekvence písmen, které nejsou pro běžný jazyk typické a modely je obtížněji rozpoznávají.
Naše interní modely naopak dosahují velmi dobrých výsledků v kategoriích lokality a čísla ve srovnání s veřejně dostupnými modely. Důvodem je mimo jiné i to, že se těmto kategoriím dlouhodobě cíleně věnujeme při přípravě trénovacích dat a optimalizaci modelů.
Na základě těchto výsledků se nyní chceme více zaměřit právě na problematické entity, zejména konkrétní názvy produktů a dalších specifických pojmenovaných entit.
Přešli jsme od tradiční metriky WER k evaluaci založené na extrakci klíčových entit, což nám umožnilo lépe zachytit skutečnou užitečnost přepsaného textu a lépe reflektovat potřeby interních zákazníků ve firmě. Využili jsme současné state-of-the-art přístupy v oblasti LLM-based anotace dat i optimalizace promptů, díky čemuž jsme získali jemnější a prakticky relevantnější pohled na kvalitu ASR systémů.
Tento přístup nám umožňuje lépe porozumět silným i slabým stránkám jednotlivých systémů a zároveň poskytuje cennou zpětnou vazbu pro další vývoj a optimalizaci ASR systémů. Nové vyhodnocení jasně ukazuje slabší místa produkčního systému zejména v porozumění specifickým produktům a vlastním jménům, ať už jde o osoby nebo instituce.
Naopak metriky potvrzují velmi dobrou výkonnost v rozpoznávání čísel, lokalit a příkazů, které jsou pro naše použití klíčové. V budoucnu plánujeme tento evaluační framework dále rozšiřovat o nové kategorie entit a další produktově specifické požadavky, aby vyhodnocení i nadále odpovídalo reálným scénářům použití.
Za tým výzkumu řečových technologií Martin Dvořák
7. listopadu jsme uspořádali už třetí ročník Seznam Meetupu. Akce se konala pod záštitou Dnů AI 2025 a na půdu Fakulty informačních technologií VUT v Brně přilákala 180 nadšenců do umělé inteligence (AI).
Vybraní uživatelé se mohou v Seznam Asistentovi nově setkat s inzeráty z Skliku. Ty rozšiřují odpovědi o relevantní doporučení na firmy, které lidem pomohou s řešením jejich potřeb. Reklamy se navíc zobrazují pouze tehdy, když mohou být skutečně přínosné. Co to znamená pro uživatele i inzerenty a jak přesně reklamy v Asistentovi fungují?
Vyhledávání od Seznamu se díky AI posouvá do nové éry. Spuštěním Seznam Asistenta vzniká nová vstupní vrstva, ve které uživatelé řeší své potřeby prostřednictvím konverzace. Zároveň se tu pro firmy otevírá prostor, jak zasáhnout zákazníka ve chvíli, kdy se rozhoduje. V přednášce Davida Bajera a Ondřeje Víchy se dozvíte, jak Asistent mění akviziční logiku a proč se z něj stává silný nástroj pro získávání nových zákazníků.
