Dnešní ranní briefing shrnuje několik praktických novinek kolem ASR/TTS a infrastruktury pro real‑time voice agenty – s důrazem na to, co má přímý dopad na stavbu a provoz voicebotů v telco.
Voxtral Transcribe 2 od Mistralu: sub‑200 ms streaming ASR + open‑weights pro edge
Mistral vydal rodinu modelů Voxtral Transcribe 2: „Mini Transcribe V2“ pro dávkové přepisy a Voxtral Realtime pro živé aplikace se streamovací architekturou a konfigurovatelnou latencí až pod 200 ms. Důležitý detail pro telco: Realtime varianta je open‑weights (Apache 2.0), takže ji lze nasadit on‑prem/na edge (např. poblíž SBC/mediálních uzlů), kde se typicky bojuje s latencí a s ochranou dat. Modely explicitně míří na typické kontaktní scénáře (call centra), podporují diarizaci, timestampy a „context biasing“ (praktické pro jména, tarifní názvy, brandy, zkratky apod.). Pro provoz botů to znamená možnost poskládat pipeline ASR → LLM → TTS s menší závislostí na vzdálených regionech a s lepší kontrolou nad SLO (turn latency) i nad incidenty dodavatelů. Praktický takeaway: pokud dnes používáte cloudové ASR a řešíte jitter/queueing, stojí za to udělat POC s edge nasazením (alespoň pro nejkritičtější use‑casy) a změřit end‑to‑end latenci po jednotlivých krocích (VAD/endpointing, ASR, LLM, TTS, transport).
Zdroj: mistral.ai/news/voxtral-transcribe-2 (doporučené praktické doplnění: simonwillison.net – rychlý hands‑on a API ukázka)
LiveKit Series C: „voice AI stack“ jako samostatná disciplína (testování, observabilita, PSTN napojení)
LiveKit v článku k Series C popisuje, proč se voice agent v produkci chová jinak než webová aplikace: je real‑time a stavový (session trvá minuty až hodiny) a typicky řetězí několik modelů na každý „turn“ (ASR, detekce konce řeči/interruptions, LLM, TTS). Pro telco je podstatné, že důraz dávají na telephony/PSTN napojení a na minimalizaci latence – zmiňují partnerství s operátory a globální síť pro routování hlasu. Z provozního pohledu je nejcennější část o lifecycle: build → test/eval (statistické testy, simulace) → deploy/run (serverless agents, škálování) → observe (měření turn latency, session replays, time‑aligned transkripty). To je přesně oblast, kde v telco často chybí „Datadog pro voicebota“: bez metrik na úrovni turnů a bez time‑aligned stop se těžko vysvětluje, jestli problém způsobila ASR, LLM, TTS nebo transport. Praktický takeaway: zaveďte minimálně jednotný tracing/telemetrii pro každou konverzační otočku (časové značky: audio‑in → ASR partial/final → LLM start/stop → TTS start/first‑byte → audio‑out) a definujte SLO pro p95 turn latency; bez toho se incidenty a degradace kvality budou pořád řešit „pocitově“.
Zdroj: blog.livekit.io/livekit-series-c/
Google Cloud Text‑to‑Speech: streaming syntéza a širší regionální dostupnost Gemini TTS
V release notes Google Cloud TTS je pro voiceboty zásadní trend: vedle „klasických“ hlasů se stále víc prosazuje streaming TTS a regionální dostupnost modelů (nižší RTT = nižší end‑to‑end latence). Google uvádí, že Gemini TTS podporuje streaming a že se postupně rozšiřuje regionální dostupnost (global/us/eu atd.), což je pro telco provozní realita: často máte zákazníky a call centra v EU a potřebujete data i inference držet v EU. Dále je zajímavé, že Chirp 3 HD přidává jazykovou podporu včetně cs‑CZ (historicky), což snižuje bariéru pro kvalitní „brand voice“ i v češtině (a v dalších jazycích CEE). Dopad na stavbu botů: streaming TTS umožní začít přehrávat odpověď dřív (first‑audio/first‑byte), takže i při delších odpovědích se subjektivní latence výrazně zlepší. Praktický takeaway: pokud dnes TTS děláte „non‑streaming“, přepněte architekturu na stream (a ve vašem IVR/telephony stacku řešte buffering tak, aby první audio šlo ven v řádu stovek ms, ne sekund).
Zdroj: Google Cloud TTS release notes
Google Cloud Speech‑to‑Text: Chirp 3 (v2) a telephony modely jako cesta k lepší přesnosti na 8 kHz
Google ve svých release notes připomíná evoluci řady Chirp (v2/v3) a zejména důležitý detail pro telco: existují modely cílené na telephony audio (8 kHz), které typicky přinášejí znatelný skok v přesnosti oproti „general“ modelům. U Chirp 3 (API v2) zmiňují podporu více způsobů rozpoznávání (streaming/sync/batch), diarizaci a další funkce relevantní pro provoz (adaptace slovníku, denoiser). Pro voiceboty to znamená: pokud řešíte vysoký WER v PSTN hovorech, první krok není „lepší prompt“, ale správná volba ASR modelu a správné nastavení (telephony model, endpointing/VAD, adaptace na doménové termíny). Dopad na telco provoz: lepší stabilita transkripce zvedá úspěšnost NLU/LLM a zároveň snižuje potřebu opakování („můžete to říct znovu?“), což přímo zkracuje AHT. Praktický takeaway: udělejte A/B test (general vs. telephony model) na reálných nahrávkách a měřte WER i downstream metriky (task success, handover rate, containment), protože i malé zlepšení WER často přinese velké zlepšení v konverzačním toku.
Zdroj: Google Cloud Speech‑to‑Text release notes
Takeaways pro telco/voice (prakticky):
- Edge/On‑prem ASR (open‑weights) začíná dávat ekonomicky i provozně smysl: snižuje RTT a riziko výpadků poskytovatele.
- Streaming (ASR i TTS) je nejrychlejší „latency win“ – měřte p95 turn latency a optimalizujte first‑audio.
- Bez observability na úrovni turnů (časové značky přes ASR/LLM/TTS/transport) budete pořád ladit naslepo.