Dobré ráno — krátký briefing k novinkám kolem AI chatbotů a voice/voicebotů (se zřetelem na telco provoz a nasazování v produkci).
Microsoft VibeVoice ASR: 60 minut přepisu v jednom průchodu + strukturovaný výstup (kdo/kdy/co)
Microsoft představil model VibeVoice ASR určený pro dlouhé nahrávky (až ~60 minut) a „strukturované“ přepisy, kde je v jednom kroku řešený přepis, diarizace (kdo mluví) i timestampy. Důležité je, že nejde o klasickou pipeline „nařež audio na chunk-y + slep výsledky“, ale o holistické zpracování s dlouhým kontextem, což typicky zlepšuje konzistenci mluvčích a snižuje post-processing. Pro telco prostředí to míří na reálné scénáře jako dlouhé hovory na lince, eskalace mezi agentem a zákazníkem nebo interní incidentní bridge, kde se běžné ASR často rozpadá na přeskakující speaker labely a nekonzistentní časování. Prakticky zajímavá je i podpora hotwords (doménové termíny, názvy tarifů, produktů), protože v telcu se bez toho chybovost na entitách rychle propisuje do špatných workflow a špatného routingu. Takeaway: pokud stavíte voiceboty nebo analytiku hovorů, má smysl otestovat „single-pass longform + diarizace“ variantu na vašich reálných datech — často vám to sníží komplexitu celé ETL vrstvy (méně chunkování, méně heuristik na slučování). Zdroj
RT.Assistant (.NET): praktický blueprint pro multi-agent voice aplikaci nad OpenAI Realtime API (WebRTC)
Na .NET blogu vyšel detailní „production-style“ příklad, jak poskládat multi-agent voice aplikaci v .NETu: hlasový agent drží realtime spojení (WebRTC), další agenti řeší dotazy/akce a celé to drží na uzdě deterministický stavový automat. Z telco pohledu je cenné, že autor volí realistický use-case (výběr tarifů) a ukazuje, jak zkombinovat generativní část s „symbolickou“ bází znalostí (Prolog fakta) tak, aby odpovědi byly ověřitelné a méně halucinační. V provozu botů je to přesně ten pattern, který obvykle snižuje incidenty: LLM může generovat dotazy do striktního modelu, ale finální rozhodnutí (co je v tarifu, kolik stojí, kdy platí promo) vychází z deterministického zdroje pravdy. Článek zároveň dobře vysvětluje trade-off WebRTC vs WebSocket a připomíná, že WebRTC přináší odolnost a oddělení audio/data kanálů, ale i tak potřebujete disciplinovanou orchestraci a monitoring eventů. Takeaway: pokud chcete „enterprise voicebot“ v telcu, berte to jako referenční architekturu — multi-agent rozdělení rolí + deterministická kontrolní vrstva + striktní KB je často robustnější než jeden velký prompt. Zdroj
WebRTC vs WebSocket v PSTN voicebotech: bottleneck je model a telefonní síť, ne transport
Praktický postmortem z enterprise voice systému (PSTN hovory přes Twilio) porovnal současnou WebSocket pipeline (G.711 μ-law 8 kHz) s variantou přes WebRTC (LiveKit + SIP trunk). Překvapení: mediánová latence „konec řeči → start odpovědi“ vyšla skoro stejně (~1.9 s vs ~2.1 s), protože dominantní část je inference LLM (řádově stovky ms až sekundy) a transport dělá jednotky procent. Druhá lekce je o kvalitě: dokud zákazník volá z telefonu, PSTN je tvrdý strop kvality (úzkopásmo), takže Opus/48 kHz uvnitř vašeho systému nezlepší to, co se do sítě nikdy nedostalo. Autor taky popisuje reálný provozní problém: WebRTC „znělo hůř“, dokud nedoplnili vlastní audio pacer — jitter buffer řeší síťové kolísání, ne to, že AI audio přijde v nerovnoměrných dávkách. Takeaway pro telco: optimalizace, které nejvíc pohnou zákaznickým zážitkem, jsou často jinde (rychlejší model, lepší turn-taking/VAD, lepší pacing a buffering, a správná metrika latency), a migrace WebSocket→WebRTC se vyplatí hlavně u VoIP/app klientů mimo PSTN. Zdroj
(Menší postřeh) Bug/kompatibilita: v Chrome se u realtime voice výstupu objevují zaseky a „stutter“
V komunitním fóru se objevila čerstvá reportovaná chyba, kdy audio výstup z realtime voice (WebRTC demo) v Chrome výrazně stutteruje, zatímco v Safari se problém neprojevuje. I když jde zatím o jeden report bez definitivního RCA, v telco nasazení je to připomínka, že klientská platforma (Chrome/Chromium vs Safari/WebKit) může zásadně ovlivnit perceived quality, i když serverová část je stejná. Pro voiceboty v self-care aplikacích to znamená: testovat napříč prohlížeči a mít fallback (např. přepnutí transportu, jiný jitter/pacing režim, degradace kvality) — hlavně u „native audio“ a realtime režimů. Z provozního pohledu je dobré logovat metriky jako underrun/overrun, jitter buffer stats a reálné tempo feedování audio framů, protože „stutter“ může být jen symptom špatného pacingu. Takeaway: před plošným rolloutem voice režimu si udělejte canary testy per browser a přidejte automatické detekce degradace (např. vysoký packet loss/jitter/late frames) + bezpečný fallback. Zdroj
Závěr — 3 takeaways pro telco/voice:
- U dlouhých hovorů může „single-pass longform ASR + diarizace“ snížit složitost a chybovost oproti chunkování a lepení segmentů.
- Pro enterprise voiceboty funguje kombinace LLM + deterministická knowledge base + stavový automat lépe než „jeden prompt na všechno“.
- Transport (WebRTC/WebSocket) často není hlavní bottleneck; klíčové jsou inference, turn-taking a audio pacing/buffering — a testy napříč prohlížeči.