Ranní briefing: vybrané novinky a praktické postřehy z AI chat/voice světa, tentokrát hlavně kolem latence, orchestrací a „real‑time“ audio pipeline.
Amazon Connect: více generativních TTS hlasů + nové regiony (London/Seoul/Sydney)
AWS rozšířilo generativní text‑to‑speech v Amazon Connectu do tří dalších regionů (Europe London, AP Seoul, AP Sydney) a zároveň přidalo devět nových generativních hlasů pro en‑US, en‑GB, fr‑FR, de‑DE a it‑IT. Pro telco provoz voicebotů je to důležité hlavně kvůli data residency a latenci: regionální dostupnost často rozhoduje, jestli lze hlasovou AI nasadit do produkce bez výjimek v compliance a bez „audio lag“ v hovorech. Prakticky to také zvyšuje šanci držet celý hlasový řetězec (IVR/agentic self‑service → TTS) v jednom cloudu a jedné oblasti, což zjednodušuje incident management i SLA (méně mezi‑regionálních závislostí). V neposlední řadě je to signál, že „generativní TTS“ se přesouvá z pilotů do standardní výbavy kontaktních center – tedy i očekávání zákazníků na přirozenost a tempo konverzace půjde nahoru. Takeaway pro stavbu botů: počítejte s tím, že výběr hlasu/regionu bude konfigurace, kterou budete chtít řídit jako kód (IaC) a validovat v pre‑prod (latence, výpadky, fallback na standardní TTS).
OpenAI: GPT‑5.4 mini/nano – tlak na „performance-per-latency“ pro subagenty a multimodal
OpenAI oznámilo malé varianty GPT‑5.4 (mini a nano) a rámuje to explicitně jako modely pro prostředí, kde latence přímo formuje UX (rychlé iterace, tool‑use, subagentní architektury, práce se screenshoty). I když to není „voice“ novinka v užším smyslu, pro voiceboty a telco orchestraci to sedí: typický produkční hlasový agent dnes dělá víc kroků (detekce záměru, retrieval, kontrola politiky, sumarizace, logování, rozhodnutí o eskalaci) a každý krok přidává stovky ms – výsledkem je nepřirozené ticho v hovoru. Mini/nano modely jsou zajímavé právě jako „pracovní koně“ pro podpůrné sub‑úlohy paralelně (např. klasifikace, extrakce entit, validace formulářových dat, rychlé RAG dotazy), zatímco větší model řeší jen plán a finální odpověď. Praktický takeaway: pokud už máte agentní pipeline, stojí za to udělat „latency budget“ pro hlasový kanál a zkusit stratifikaci modelů (větší model jen tam, kde to mění kvalitu; zbytek mini/nano), plus měřit celkovou dobu včetně tool callů (nejen tokens/s). To je přesně typ optimalizace, která v telcu rozhoduje o tom, jestli zákazník přeruší bota po 2 vteřinách ticha.
Zdroj (souhrn release notes + link na originál)
OpenAI Realtime (praktika): „po speech_stopped už je často pozdě“ na poslední injekci kontextu
V komunitním vlákně k Realtime audio se řeší očekávání, že po události input_audio_buffer.speech_stopped lze ještě rychle poslat nový system message (např. conversation.item.create) a model ho použije pro odpověď – v praxi ale tazatel pozoruje, že odpověď kontext nebere v potaz. Pro telco voicebota je to kritické: „poslední milisekunda“ je lákavá (chcete mít co nejčerstvější data: stav účtu, poslední ticket, síťové události), jenže realtime pipeline si může už v okamžiku stop eventu připravovat inference/decoding a nově vložené instrukce se nemusí promítnout do právě běžící odpovědi. Dopad na návrh: místo spoléhat na pozdní system message je bezpečnější buď (a) udržovat kontext průběžně aktualizovaný dřív během dialogu, nebo (b) použít explicitní tool/function call („fetch_latest_customer_state“) jako krok, který si agent vyžádá před odpovědí. Praktický takeaway: pro hlasový kanál navrhujte „kontextový handshake“ – tj. jasné místo v toku, kde se data načítají a validují, a kde máte deterministicky pod kontrolou, že model pracuje s aktuální verzí. V telcu to zároveň pomáhá auditovatelnosti (víte, s jakými daty model odpověděl).
OpenAI Agents/WebRTC: stutter výstupního audia v Chrome vs. Safari (produkční riziko pro voice UX)
Další čerstvý report z praxe: při použití oficiálních WebRTC příkladů a modelu gpt-realtime-mini autor pozoruje výrazné „stuttering“ (trhání) výstupního audia v Chrome, zatímco v Safari problém mizí. To je přesně typ incidentu, který v telco provozu zničí perceived quality – zákazník často viní „bota“, ne prohlížeč/endpoint. Důležitý je i diagnostický vzor: stejné backendové audio, ale rozdílný klient → podezření na rozdíly v implementaci playout bufferu, audio resamplingu, echo cancelleru nebo timing v JS audio stacku. Praktický takeaway pro stavbu voice agentů: testujte minimálně na dvou prohlížečích a dvou OS, logujte RTCP stats (jitter, packetsLost, audioLevel) a mějte připravený fallback mód (např. přepnutí na jinou playout strategii / restart peer connection / degradace kvality). Pro call‑center web softphony je to zároveň argument držet „known good“ kombinace (Chrome verze + audio config) a řídit update politikou, jinak si problém přinesete do produkce automatickou aktualizací prohlížeče.
Závěr – 3 rychlé takeaways pro telco/voice
- Latence je produktová funkce: dělejte latency budget a vrstvěte modely (velký jen tam, kde to mění kvalitu).
- Kontext v realtime audio neřešte „na poslední chvíli“: raději deterministický tool‑call nebo průběžné aktualizace.
- Audio klient je součást SLA: cross‑browser testy + RTCP telemetry + jasný fallback pro stuttering.