Přepis v reálném čase versus dávkové zpracování: kdy co použít

Reálný čas zní lákavě — přepis se zobrazuje téměř ve chvíli, kdy mluvíte. Ale za tuto okamžitost platíte nižší přesností, složitější architekturou a vyššími náklady na zpracování. Dávkové zpracování čeká na hotový soubor, ale vrátí přesnější výsledek. Jak se tyto dva přístupy liší ve čtyřech zásadních dimenzích a jak vybrat ten správný.

Dvě různé technické architektury

Real-time a dávkový přepis nejsou jen různé rychlosti téhož procesu — jsou to odlišné technické přístupy se zásadně různými kompromisy.

Dávkové zpracování funguje na principu kompletního vstupu. Nahrajete hotový soubor nebo zadáte URL existující nahrávky. API soubor zpracuje jako celek — nebo v chuncích, které ale zná kompletní ještě před přepisem. Model tak při přepisu každého slova „vidí" celou větu dopředu i dozadu. Tento obousměrný kontext je zdrojem jeho přesnosti: nejednoznačné slovo uprostřed věty může správně přepsat podle toho, co přišlo za ním.

Přepis v reálném čase přijímá audio jako nepřetržitý datový proud. Model dostává malé segmenty — typicky 100 až 500 milisekund — a musí je okamžitě přepsat bez znalosti toho, co přijde za chvíli. Rozhoduje s kontextem minulosti, ale bez budoucnosti. Výsledek se vrací do 200 až 500 ms od pronesení slova — uživatel vidí text téměř v reálném čase. Přesnost je ale systematicky nižší, zejména u konců vět, odborné terminologie a homofonních slov, kde budoucí kontext pomáhá rozlišit správnou variantu.

Implementační složitost je třetí rozdíl. Dávkové zpracování je HTTP POST request — soubor dovnitř, JSON odpověď ven. Implementace za hodiny. Real-time vyžaduje WebSocket připojení, správu audio bufferu, zpracování průběžných odpovědí, re-connect logiku při výpadku a state management mezi segmenty. Implementace za dny až týdny.

Čtyři dimenze srovnání

Přesnost

Dávkové zpracování systematicky dosahuje nižší chybovosti. Obousměrný kontext pomáhá opravit nejednoznačnosti, které model v reálném čase přepisuje jinak.

Příklad: lékař diktuje „Po podání furosemidu se stav pacienta stabilizoval." Real-time model na slově „furosemidu" ještě neví, co přijde za ním — váhá a může vybrat foneticky podobný lék. Dávkový model vidí celou větu a kontext „stav pacienta stabilizoval" pomáhá potvrdit farmakologický termín.

Relativní rozdíl WER: v závislosti na podmínkách 10 až 30 % nižší chybovost u dávkového přístupu. Na tisíci slovech záznamu to může znamenat desítky rozdílných slov.

Latence

Real-time: výsledek do půl sekundy od pronesení. Pro živé titulky nebo hlas jako vstup do aplikace je toto podmínka, ne výhoda.

Dávkové: čekání závisí na délce nahrávky a výkonu zpracovávajícího systému. Orientační hodnota: 10 až 30 % délky nahrávky. Pětiminutová nahrávka → výsledek za 30 až 90 sekund. Hodinový záznam → výsledek za 6 až 18 minut.

Cena

Real-time API udržuje otevřené WebSocket připojení po celou dobu nahrávání — včetně tichých pauz a přestávek. Platíte za čas připojení, ne jen za aktivní řeč. Výsledek: real-time zpracování je typicky 2 až 5× dražší na zpracovanou minutu řeči než dávkové.

U dávkového zpracování platíte za skutečné minuty audio obsahu. Ticho, pauzy a přestávky se do ceny nepočítají.

Technická složitost

Dávkové zpracování: HTTP POST → čekat → JSON. Každý vývojář, který kdy volal REST API, to zvládne.

Real-time: WebSocket je jiný protokol než HTTP. Zvuk musí přicházet ve správném formátu a tempu. Dílčí výsledky (partials) se průběžně aktualizují — aplikace musí zobrazovat neúplné texty a nahrazovat je finálními verzemi. Při výpadku spojení je nutný re-connect bez ztráty kontextu. Toto je implementačně náročná disciplína.

Srovnávací přehled

Kdy který přístup zvolit

Real-time přepis dává smysl tehdy, když:

• Výsledek je nutný v průběhu nahrávání, ne po skončení — živé titulky na konferenci, simultánní přepis pro neslyšící
• Hlas je vstupem do interaktivní aplikace — hlasový asistent, diktování textu, přepis telefonního hovoru
• Orientační přesnost je akceptovatelná — výsledek slouží pro orientaci, ne jako archivní dokument nebo podkladový materiál

Dávkové zpracování dává smysl tehdy, když:

• Přesnost má přednost — lékařský, právní nebo akademický přepis, kde každé slovo může mít dopad
• Zpracováváte existující nahrávky, ne živý zvuk v průběhu vzniku
• Chcete ensemble přístup — přepis přes více modelů paralelně se slučováním výsledků (v real-time to prakticky není realizovatelné)
• Objem zpracování nebo cena jsou relevantní kritéria

Hybridní přístup

Meetingové nástroje jako Otter.ai nebo Microsoft Teams používají kombinaci obou: live captions jsou real-time pro orientaci v průběhu schůzky, post-meeting transcript je dávkový pro přesnější archivní záznam. Každý přístup slouží jinému účelu — a v kombinaci se vzájemně doplňují.

Czech Transcription System pracuje v dávkovém režimu. Nahráváte soubor a dostanete hotový přepis zpracovaný přes více přepisových enginů paralelně, jejichž výsledky se sloučí do jedné finální verze. Tento ensemble přístup — který je jedním z důvodů vyšší přesnosti oproti jednotlivým modelům — není v real-time zpracování prakticky realizovatelný. Výsledkem je přesnější přepis za cenu čekání. Pro živé titulky by bylo potřeba jiné, real-time řešení.

Technická stránka dávkového zpracování — jak se záznamy dělí na části pro API — je popsána v článku o chunkingu A14. Jak funguje ensemble přístup a slučování více variant přepisu, vysvětluje A13.

Zdroje:

• Deepgram dokumentace — streaming vs. pre-recorded přepis
• AssemblyAI dokumentace — real-time vs. async