Dobré ráno — krátký přehled toho, co se za poslední dny pohnulo kolem AI chatbotů a hlavně voice/voicebotů (se zaměřením na provozní realitu v telcu).
Deepgram: dynamická konfigurace STT uprostřed streamu + nové ovládání rychlosti TTS
Deepgram v changelogu popsal několik praktických novinek pro stavbu voice agentů. Z pohledu telco provozu je nejzajímavější možnost měnit chování rozpoznávání řeči „za běhu“ u streaming STT (Flux) pomocí kontrolní zprávy Configure — bez odpojení a znovupřipojení streamu. To řeší typický problém call-flow: jiná tolerance ticha a jiná přísnost detekce konce repliky (EoT) při autentizaci/OTP než v běžné konverzaci, a také potřebu rychle přidat klíčová slova (jména tarifů, názvy služeb) právě ve chvíli, kdy na ně dojde. Současně přibylo řízení rychlosti u Deepgram TTS ve Voice Agent API (parametr agent.speak.provider.speed), což je často podceňovaná páka na srozumitelnost a UX v IVR/voicebot scénářích (a zkrácení AHT bez „přepálení“ tempa). Pro inženýry je důležité upozornění, že keyterms se při Configure nahrazují (ne mergeují) — v praxi to znamená, že si musíte držet aktuální seznam termů na aplikační vrstvě, jinak si snadno „smažete“ předchozí kontext. Takeaway: berte STT streaming jako adaptivní komponentu a přepínejte režimy podle fáze hovoru (identita/platby vs. troubleshooting), místo aby jeden globální set parametrů řídil celý hovor.
Speechmatics × Cekura: QA/monitoring pipeline pro STT s realistickými podmínkami a head‑to‑head srovnáním providerů
Speechmatics a Cekura oznámily integraci, která má přenést testování STT z „čistých benchmarků“ do reálných podmínek produkčního audia (akcenty, šum, code‑switching, více mluvčích). V telcu je tohle přesně místo, kde voiceboty padají: demo na studiovém mikrofonu funguje, ale reálné hovory mají kompresi, přerušování, hluk ulice a rychlé střídání řeči. Důležitý je důraz na propojení s QA lifecycle (pre‑prod simulace, CI/CD integrace, až po monitoring živých konverzací) — tj. stejná metrika a stejné testovací persony napříč vývojem i provozem, ne ad‑hoc kontroly po incidentech. Prakticky zajímavé je i „controlled, head‑to‑head“ porovnání více STT providerů (zmiňují Azure, Gemini, Deepgram) v konzistentním prostředí: to zjednodušuje vendor due‑diligence a hlavně umožní vybírat model podle vašeho skutečného call mixu, ne podle marketingových claimů. Takeaway: pokud provozujete voicebota, investujte do kontinuálního testování na vlastních audio datech a dělejte regresní testy po každé změně promptů, VAD/turn‑taking nastavení nebo routingu — STT je systémová závislost, ne „černá krabička“.
Zdroj: Speechmatics × Cekura (GlobeNewswire)
WebSocket → WebRTC u voice agenta: co se rozbije (latence, session affinity, TURN) a co to přinese
Praktický článek na DEV popisuje migraci browser‑to‑agent audio transportu z WebSocketu na WebRTC a nasazení do AWS Bedrock AgentCore Runtime. Klíčový motiv je latence a robustnost: WebSocket běží nad TCP, takže ztracený paket umí „zaseknout“ stream kvůli retransmisi; WebRTC používá UDP (Opus) a pro real‑time dialog snese malé výpadky lépe než znatelné pauzy. Pro telco/voiceboty je to relevantní i mimo AWS: pokud chcete přirozené přerušování (barge‑in) a rychlé turn‑taking, transportní vrstva často rozhoduje víc než samotný model. Autor popisuje dvě architektury (P2P vs. SFU) a v produkci naráží na typické provozní pasti: NAT/privátní VPC znamená potřebu TURN relaye a signaling handshake vyžaduje session affinity (když se jednotlivé signaling kroky rozloží na různé instance, spojení se nedokončí). Zmiňuje i „neviditelné“ deployment constrainty (např. kompatibilita availability zón) a to, že u managed runtimů je část detailů schovaná v méně viditelných chybových hláškách. Takeaway: pokud stavíte voicebota do cloudu, počítejte s tím, že WebRTC není jen „jiný protokol“, ale sada požadavků na statefulness, routing a NAT traversal — a otestujte to dřív, než začnete ladit modely a prompty.
Závěr — 3 takeaways pro telco/voice
- Streaming STT nastavujte adaptivně podle fáze hovoru (turn‑taking, EoT, keyterms), ne jedním statickým profilem.
- QA pro voice agenty dělejte na vlastních „špinavých“ datech a jako součást CI/CD + provozního monitoringu.
- Transport (WebRTC/TURN/session affinity) je často největší zdroj latence a incidentů — řešte ho dřív než prompty.