Dnešní ranní briefing vybírá 3 praktické novinky z oblasti hlasových agentů a chatbotů – se zaměřením na nízkou latenci, streaming a spolehlivý provoz v telco.
Google: Gemini 2.5 Flash (Live API) – nativní audio, barge‑in a „proactive audio“
Google na stránce modelu Gemini 2.5 Flash with Gemini Live API popisuje, že „native audio“ režim je navržen pro obousměrné real‑time interakce a přidává několik funkcí důležitých pro voiceboty: zlepšené barge‑in přerušování, přesnější přepis (ASR) a robustnější function calling (vyšší „triggering rate“ pro volání nástrojů). Z praktického pohledu je zásadní i Proactive Audio (preview), kde model reaguje jen na „device‑directed“ dotazy – to v telco scénářích pomáhá s falešnými aktivacemi a šumem v otevřených linkách. Zmíněná je také Affective Dialog, tedy schopnost vnímat emoce v hlasu a přizpůsobit styl odpovědi; to se hodí pro de‑eskalaci v reklamacích nebo při výpadcích služeb. Pro provoz voicebota v telco je klíčové, že dokument uvádí konkrétní požadované audio formáty (16kHz PCM in / 24kHz PCM out) a limity konverzace/sessions – to přímo ovlivňuje návrh media gateway, jitter bufferů a monitoring SLO. Takeaway: pokud stavíte real‑time agentní vrstvu nad Live API, připravte si testy na barge‑in ve špatných akustických podmínkách a definujte „budžety“ latence po jednotlivých stage (endpointing → STT → LLM → TTS) už v architektuře.
Zdroj: Gemini 2.5 Flash with Gemini Live API (Google Cloud Docs)
AWS: Amazon Polly Bidirectional Streaming – TTS přes HTTP/2 se simultánním vstupem i výstupem
AWS představilo Bidirectional Streaming API pro Amazon Polly (StartSpeechSynthesisStream), které řeší klasický problém „request‑response“ TTS: dříve jste museli čekat na kompletní text, než šlo spustit syntézu. Nové API umožňuje posílat text inkrementálně (typicky jak LLM generuje tokeny/slova) a současně přijímat audio chunky v reálném čase přes jednu persistentní HTTP/2 linku. Důležitý detail pro návrh voice pipeline je možnost řídit, kdy se má „flushnout“ bufferovaný text (trade‑off: rychlejší začátek vs. potenciální dopad na kvalitu prozodie). AWS v článku uvádí i benchmark: proti tradičnímu SynthesizeSpeech to v jejich testu zrychlilo celkové zpracování o ~39 % a snížilo počet API volání z 27 na 1, což je v provozu telco (škálování, rate limits, observabilita) obrovské zjednodušení. Pro telco voiceboty to znamená: můžete maskovat latenci LLM (TTFT/decode) tím, že už během generování pouštíte první zvuk, a zároveň snížit komplexitu middleware (chunking/reassembly). Takeaway: pokud dnes děláte vlastní „sentence chunking“ a slepujete audio, stojí za to porovnat end‑to‑end metriku S2FA (stop‑to‑first‑audio) po přechodu na bidirectional stream; často to zlepší i p95/p99 díky menšímu počtu komponent.
Zdroj: Introducing Amazon Polly Bidirectional Streaming (AWS ML Blog)
Telnyx: kde se ve voice AI „ztrácí“ latence a jak ji měřit (S2FA, p95/p99)
Telnyx publikovalo praktický rozklad latence ve voice AI pipeline a připomíná, že už mezera ~200–300 ms je pro lidské turn‑taking „norma“ – nad 500 ms začínají hovory působit nepřirozeně a nad 1–2 s uživatelé často opakují nebo odchází. Článek rozděluje zpoždění na endpointing/VAD, STT, LLM inference, TTS a síťové round‑tripy; klíčové je, že celkový dojem dělá součet (a špatné p95/p99 je pro důvěru horší než slabší medián). Z pohledu telco provozu je zajímavá část o topologii a „legacy“ infrastruktuře: PBX/SIP trunky a multi‑vendor stacky přidávají 100–300 ms ještě předtím, než vůbec začnete s AI pipeline (transkódování, buffering, routing). Doporučení „streamovat všechno“ (STT, LLM, TTS) a instrumentovat end‑to‑end metriky typu S2FA (stop‑to‑first‑audio) je přesně to, co často chybí v pilotních POC – bez měření se latency regressions maskují. Takeaway: udělejte si pro voicebot v telco „stage budgety“ a dashboardy na p50/p95/p99 pro každou fázi + pro celý hovor; teprve pak dává smysl ladit model, prompt nebo infra (region colocation, snížení hopů, cache/tooling).
Zdroj: Voice AI delay causes: How to reduce latency (Telnyx)
Závěr – 3 takeaways pro telco/voice
- Streaming end‑to‑end (STT → LLM → TTS) je nejrychlejší cesta k nižší „perceived latency“ a lepší konverzaci.
- Měřte S2FA a p95/p99, ne jen průměr: občasné spike-y zabíjí důvěru i containment.
- Zjednodušujte topologii: méně hopů mezi telephony POP, inference a TTS často vyhraje víc než „lepší model“.