Ranní briefing (AI chatboti & voice/voiceboti) — dnes jsou hlavními tématy hlavně nízkolatenční voice stack (telephony ↔ real‑time streaming) a další posun v open‑source/edge STT pro streaming scénáře.
Moonshine Voice v2: streaming STT a edge nasazení jako reálná alternativa k Whisperu
Moonshine AI podle článku představilo druhou generaci open‑weights STT modelů optimalizovaných pro streaming (inkrementální zpracování) a běh na edge/koncových zařízeních. Klíčové je, že na rozdíl od Whisperu nejsou modely „přilepené“ na fixní 30s okno a umí cacheovat stav, takže při průběžném přidávání audia nevypočítávají stále dokola to samé — to se přímo promítá do latence. Publikované metriky v textu ukazují řádový rozdíl v odezvě (desítky až stovky ms pro Moonshine vs. sekundy až desítky sekund u některých Whisper variant), což je přesně hranice, kde voicebot přestává působit „roboticky“. Pro telco provoz je to zajímavé zejména v případech, kdy chcete mít STT on‑prem/edge (privacy, regulace, náklady, výpadky konektivity) a zároveň udržet sub‑sekundový dialog. Praktický takeaway: pokud stavíte voicebota s průběžným přepisem/„barge‑in“, hledejte STT s nativní streaming architekturou + caching a měřte P95/P99 TTFT/latenci v reálné síti (ne jen WER v benchmarku).
Zdroj (odkazuje i na GitHub, PyPI a arXiv v textu)
IBM + Deepgram: hlasové schopnosti (STT/TTS) jako „první voice partner“ pro watsonx Orchestrate
IBM a Deepgram oznámily spolupráci, ve které má být Deepgram integrován do IBM watsonx Orchestrate jako první oficiální partner pro voice technologie. Smysl je dodat enterprise „voice layer“ pro agenty a workflow: přepis (včetně real‑time captioning), hlasové interakce a nasazení v use‑casech typu customer support, analýza hovorů nebo voice‑driven data entry. Pro telco je důležité, že podobné integrace posouvají voice do standardní enterprise orchestrátorské vrstvy — a tím roste tlak na provozní vlastnosti (latence, spolehlivost, akcenty/hluk, auditovatelnost) a na možnost volby mezi cloudem a self‑hosted variantou. Článek zmiňuje ambice na <300 ms latenci a vysokou přesnost v produkci a také podporu vícejazyčnosti (včetně variant arabštiny a indických jazyků), což je prakticky relevantní pro multijazyčné telco trhy. Praktický takeaway: když vybíráte ASR/TTS pro voicebota, neřešte jen „model“, ale i způsob integrace do agent orchestrace (API kontrakty, metriky, governance) a předem definujte SLO pro TTFT/latency + fallback na DTMF nebo přepojení na operátora.
Referenční architektura: Exotel + LiveKit pro produkční voice agenty se sub‑800 ms latencí
Exotel publikoval referenční architekturu pro nasazení real‑time voice asistenta, který spojuje telco vrstvu (PSTN, SIP trunk) s LiveKit SIP bridge a agentem běžícím přes WebRTC (LiveKit Agents SDK). Text rozepisuje „latency budget“ a explicitně ukazuje, že cílová konverzační latence pod ~800 ms vyžaduje streaming API a paralelizaci (ASR/LLM/TTS pipeline), včetně doporučení „overlapovat“ generování řeči ještě před dokončením celé LLM odpovědi. Pro telco provoz je cenné i to, že architektura řeší praktické věci: dispatch rules (routing hovorů na instanci), horizontální škálování, metriky (P95/P99, jitter, drop rate), regionální umístění a hlavně fallback/transfer na živého operátora při překročení prahu (např. 1 s bez odpovědi). Z pohledu stavby botů je to konkrétní návod, jak propojit SIP svět s real‑time agentem bez toho, aby se z toho stal „REST bot“ s vteřinovými pauzami. Praktický takeaway: zaveďte end‑to‑end tracing po fázích (media in → ASR start/TTFT → LLM start/TTFT → TTS start/first audio) a držte se lat. rozpočtu; bez toho budete ladit pocitovou „pomalost“ týdny.
(Menší postřeh) Praktický rámec pro SIP/telephony detaily u voice agent frameworků (LiveKit/Pipecat)
V posledních dnech se objevují i praktičtěji laděné přehledy/framework notes, které připomínají „neviditelné“ věci, na kterých voiceboty v telco reálně padají: G.711/PCMU kompatibilita, realtime transcoding, jitter buffery a práce s paketovým pořadím. I když podobné texty nejsou release notes, pro provoz jsou užitečné, protože shrnují, proč je lepší stavět na hotové real‑time infrastruktuře (SFU/WebRTC vrstva) než si psát vlastní audio transport. Pro telco týmy to typicky znamená zrychlení time‑to‑prod a méně incidentů typu „robot voice“ nebo dropy při síťových špičkách. Praktický takeaway: v designu voicebota explicitně počítejte s jitterem a transcodingem jako s first‑class požadavkem; pokud to framework skrývá, chtějte metriky a možnost ladění (buffer size, packet loss concealment, VAD tuning).
Závěr – 3 takeaways pro telco/voice
- Streaming + caching v ASR je dnes zásadní: bez toho těžko dosáhnete přirozeného dialogu (sub‑sekundová latence).
- Voice stack je systémový problém (telephony/SIP ↔ transport ↔ ASR/LLM/TTS): měřte P95/P99 a držte „latency budget“ po fázích.
- V produkci vždy navrhujte fallback (DTMF / přepojení na člověka) a governance (SLO, monitoring, regionální umístění) stejně vážně jako prompt.