Dnešní ranní výběr je zaměřený na praktiku: jak měřit a ladit latenci/accuracy u STT, jak skládat low-latency voice agenty ze streamovaných komponent a jak se v praxi promítají novinky v cloud contact center pricingu do provozu botů.
Amazon Connect pricing: „unlimited AI“, 3P STT/TTS konfigurace a náklady na propojení externí voice infrastruktury
AWS na pricing stránce Amazon Connect detailně rozepisuje, co je (a není) zahrnuto v „unlimited AI“ a kde začínají dodatečné náklady v reálných voice use-casech. Z pohledu voicebotů je důležité, že v rámci voice service charge zmiňují zahrnutí funkcí jako generative TTS v Amazon Polly, „Amazon Nova Sonic“ a také možnost konfigurace modelů třetích stran pro STT/TTS – s tím, že náklady poskytovatelů třetích stran se účtují mimo Connect. Pro telco provoz je podstatná i část o integraci s externími voice systémy pro realtime a post-call analytiku: pokud chcete do Connectu „přivést“ hlas z jiné platformy, počítejte s poplatkem za externí voice ($0.032/min) a fixním poplatkem za konektor ($100 za konektor/den), což umí v některých architekturách výrazně změnit TCO. Prakticky to znamená, že architektura (kde končí telco/IVR vrstva a kde začíná CCaaS/agent assist) je dnes stejně důležitá jako volba modelu – špatně zvolený bod integrace může být dražší než samotné AI inference. Takeaway: při návrhu voicebota do contact centra si udělej explicitní „bill of materials“ pro minuty, konektory, 3P STT/TTS a provozní módy (telephony vs web/in-app), a otestuj, zda ti latence/feature set stojí za konkrétní integrační model.
ArXiv: technický tutorial, proč „realtime“ dělá hlavně streaming + pipelining (ne „jeden zázračně rychlý model“)
Nový arXiv tutorial „Building Enterprise Realtime Voice Agents from Scratch“ shrnuje, jak poskládat enterprise-grade voice agenta od základů včetně function calling a streamování mezi komponentami. Autoři explicitně porovnávají „native speech-to-speech“ přístup (např. Qwen2.5-Omni) a uvádí, že může mít velmi dlouhé time-to-first-audio (~13 s), což je pro telefonní konverzace prakticky nepoužitelné. Jako průmyslový standard naopak popisují kaskádovanou streamovanou pipeline STT → LLM → TTS, kde každá část průběžně posílá výstup další části, a klíčem je paralelizace (pipelining) napříč komponentami. V jejich měření dosahují P50 time-to-first-audio ~947 ms (best case 729 ms) s cloud LLM API a srovnatelné latence se self-hosted vLLM na NVIDIA A10G, což je už v „telco pocitu“ hranice, kdy hlasový bot nepůsobí jako pomalý IVR. Pro telco/voicebot provoz je to cenné hlavně jako blueprint: kde typicky vznikají fronty, jaké metriky sbírat (TTFA, stream jitter, barge-in), a proč se vyplatí investovat do streamování i když jednotlivé modely nejsou „nejrychlejší na papíře“. Takeaway: pokud chceš výrazně snížit latenci, nezačínej výměnou LLM; začni tím, že celou cestu (STT partials → LLM tokens → TTS audio chunks) uděláš skutečně streamovanou a měřenou od prvního bajtu po první audio.
Gladia: jak benchmarkovat STT pro produkci (WER nestačí; měř TTFB vs „latency to final“ a sleduj bias + formátování)
Gladia publikovala praktický návod, jak týmově a opakovaně benchmarkovat STT API tak, aby výsledky odpovídaly produkci – ne demu na čistém audiu. Důraz dávají na to, že WER je sice standardní metrika, ale často klame: všechny chyby váží stejně, ignoruje „kritická slova“ (jména, čísla, identifikátory) a výsledky se výrazně mění podle normalizace (např. „25“ vs „twenty-five“, kontrakce, filler words). Pro voiceboty je zásadní část o realtime omezeních: streaming STT pracuje s menším kontextem a proto je potřeba porovnávat modely férově v režimu, ve kterém je skutečně použiješ. Z hlediska telco provozu je užitečné rozdělení latence na Time To First Byte (jak rychle začne systém vracet slova) a „latency to final“ (kdy máš finální transcript) – pro automatizace a decisioning v call flow často rozhoduje právě druhá metrika. Text také připomíná bias/demografické rozdíly (často horší přesnost pro ženy, non-native speakers, děti) a praktický dopad formátování (telefonní čísla, jména, kapitalizace) na downstream workflow. Takeaway: nastav si vlastní STT test set z reálných hovorů (hluk, akcenty, code-switching), měř odděleně TTFB i final latency, a vyhodnocuj přesnost na „high-value entitách“ – ne jen průměrnou WER.
Zdroj: Gladia – STT API benchmarks
Závěr – 3 takeaways pro telco/voice:
- Latence se vyhrává architekturou (streaming + pipelining), ne jen výměnou modelu.
- STT benchmarkuj na produkčním audiu a metrikách, které odpovídají rozhodování v call flow (TTFB vs final).
- U cloud CCaaS si předem spočítej integrační „skryté“ náklady (konektory, externí voice minuty, 3P STT/TTS).