Dobré ráno. Níže je rychlý briefing k AI chatbotům a voice/voicebotům (se zaměřením na provozní a architektonické dopady pro telco).
MiniMax spouští Realtime API (HTTP + WebSocket) pro nízkolatenční hlasové konverzace
MiniMax oznámil spuštění Realtime API s rozhraními přes HTTP a WebSocket a akcentem na „ultra-low latency“ multimodální zpracování pro přirozenější hlasové dialogy. Prakticky to znamená dalšího poskytovatele, který se snaží konkurovat v end-to-end latenci a nabízí výběr vstupu (text/hlas) i výstupu (text/hlas). I když je oznámení zatím spíš vysokonapěťové (méně detailů o metrikách, kodecích a limitech), pro telco je důležité sledovat, jak se standardizují realtime protokoly a jaké SLA/kvóty jsou realistické pro 24/7 provoz. V kontaktních centrech se totiž rychle ukáže, že „pocitová latence“ je kombinace transportu, STT, LLM a TTS – a každá platforma ji řeší jinak. Takeaway: pokud stavíte voicebota přes streaming, připravte si abstrakci transportu (WebSocket/WebRTC/telephony) a měřte TTFT a end-to-end latenci jako první-class metriky, aby šlo rychle porovnat providery.
Zdroj: minimax.io/news/realtime-api
AWS: nasazování voice agentů s Pipecat na Bedrock AgentCore Runtime (WebSockets vs WebRTC vs telephony)
AWS publikoval praktický návod, jak provozovat voice agenty (Pipecat pipelines) na Bedrock AgentCore Runtime a srovnává přístup přes WebSockets, WebRTC (TURN-assisted i „managed“) a telephony integrace. Hodně užitečné je, že článek explicitně rozebírá „první hop“ latence (klient → agent), chování UDP vs TCP, a roli ICE/TURN (a proč je ve firemních sítích běžné skončit u TURN relaye). Pro telco provoz je zásadní i provozní rovina: session izolace (microVM), autoscaling a dlouhé sessions (až 8 hodin) – to jsou přesně parametry, které ovlivní robustnost při špičkách a u dlouhých hovorů. Text taky dává konkrétní vodítka pro bezpečný přístup (presigned URL/SigV4), což je relevantní při integraci do B2C aplikací bez úniku klíčů. Takeaway: pokud dnes provozujete voicebota „jen“ přes WebSocket, je čas udělat pilotní větev s WebRTC+TURN a porovnat nejen průměrnou latenci, ale hlavně stabilitu pod ztrátovostí/jitterem a chování při reconnectu.
Zdroj: AWS Machine Learning Blog
Cohere vydává open-weights ASR model „Cohere Transcribe“ (Conformer 2B) a cílí na produkční nasazení
Cohere oznámil open-source/open-weights model pro automatický přepis řeči (ASR) „cohere-transcribe-03-2026“ (Conformer encoder-decoder, ~2B parametrů, 14 jazyků, licence Apache 2.0) a tvrdí #1 pozici na HuggingFace Open ASR Leaderboardu (avg WER 5,42). Pro voiceboty v telco je to důležité ze dvou důvodů: (1) možnost držet ASR on‑prem / ve vlastním cloudu (data, compliance, call recordings) a (2) lepší kontrola nad latencí i náklady, pokud máte vysoké objemy hovorů. Zajímavá je i kombinace „accuracy + throughput“ (RTFx), protože v provozu často prohrává i velmi přesný model, pokud je drahý nebo pomalý pro realtime. Model je navržen „pro everyday use“, takže se dá brát jako kandidát pro interní baseline a A/B testy proti komerčním STT. Takeaway: zvažte oddělené A/B měření WER na vašich telco doménových datech (akcenty, šum, overlap mluvčích) a současně měřte RTF/latenci – bez toho je výběr STT provideru často jen dojem.
Zdroj: cohere.com/blog/transcribe
WebRTC.ventures: QA rámec pro testování AI voice agentů (latence, jitter, observability, load)
WebRTC.ventures publikovali praktický rámec pro QA testování AI voice agentů jako „real-time distributed system“, kde se musí validovat audio transport (WebRTC), STT, LLM, TTS i infrastruktura – a kde i 400ms spike dokáže zničit konverzační flow. Text zdůrazňuje, že klasické QA nestačí: je potřeba hybrid (automatizace pro regresní/perf testy + manuální testy pro „pocit“ konverzace) a hlavně observability napříč vrstvami včetně WebRTC metrik (packet loss, jitter, session latency). Nabízí i 5-fázový plán: controlled testing → multi-user → environment (síť/hluk/zařízení) → load → production monitoring. Pro telco (contact center) je to extrémně relevantní, protože reálné problémy se objevují na hranách: handoff mezi telephony a agentem, špičky, NAT/firewally, a limity STT/TTS providerů. Takeaway: definujte „voice SLO“ (např. p95 end-to-end latence, p95 jitter, dropout rate) a udělejte z něj gate do produkce – bez toho se z voicebota stane náhodný generátor špatné UX.
Zdroj: webrtc.ventures
DEV: migrace voice agenta z WebSocket na WebRTC – co se rozbilo (session affinity, AZ limity, TURN)
Praktická zkušenost z migrace browser ↔ agent transportu z WebSocket (TCP) na WebRTC (typicky UDP) ukazuje, že největší zisky jsou v plynulosti a zjednodušení frontendu (Opus/RTCPeerConnection řeší prohlížeč), ale největší bolesti v „distributed handshake“ a infrastruktuře. Autor popisuje reálné pasti: potřeba session affinity (signaling je vícekrokový a nesmí se rozpadnout přes více instancí), kompatibilita availability zón u runtime prostředí a práce s TURN (např. KVS TURN) pro provoz za NAT/ve VPC. Pro telco je to cenné, protože voiceboty často běží v privátních sítích a integrují nástroje/KB – takže bez TURN a správného routingu se to v produkci rozsype, i když to lokálně funguje. Článek taky připomíná, že WebRTC není jen „lepší transport“, ale jiný provozní model: signaling, ICE candidates, lifecycle peer connection a logování metrik. Takeaway: pokud jdete do WebRTC, plánujte dopředu statefulness signální vrstvy (sticky sessions / externí state store) a přidejte tracing, který spojuje signaling události s media statistikami a latencí STT/LLM/TTS.
Zdroj: dev.to
3 rychlé takeaways pro telco/voice:
- WebRTC (s TURN) typicky vyhrává v konzistenci a „pocitové“ latenci, ale přináší nároky na signaling, observability a session affinity.
- Open-weights ASR (např. Cohere Transcribe) může zásadně změnit cost/perf a compliance, ale musí projít A/B na doménových telco datech + měření RTF/latence.
- Bez QA rámce a jasných SLO metrik (p95 E2E latence, jitter, dropout) se voicebot v produkci rychle zhorší – testujte jako real-time systém, ne jako webovou appku.