Ranní briefing přináší rychlý přehled novinek a praktických poznatků pro stavbu a provoz AI chatbotů a voicebotů (se zaměřením na telco a contact center).
1) One‑Second Voice‑to‑Voice latence: Modal + Pipecat + open‑weights modely
Modal popisuje, jak postavili voicebota, který se dokáže dostat k přibližně „jednosekundové“ voice‑to‑voice latenci (čas od konce řeči uživatele do prvního zvuku odpovědi). Důležitý je praktický návrh architektury: udržet stavový orchestrátor (Pipecat) na CPU a těžké modely (STT/LLM/TTS) provozovat jako separátní autoskalované služby, čímž se dá lépe řídit náklad i cold‑start. V článku je vidět, že „streaming za každou cenu“ není vždy nejlepší – autoři zvolili lokální VAD/turn‑taking a posílali do STT segmenty, protože jim to ve výsledku zkrátilo finální čas do hotového přepisu. Pro telco provoz je to relevantní hlavně kvůli citlivosti na jitter a síťové hop-y: latency budget se rychle sečte (transport + STT + LLM TTFT + TTS TTFB) a musí se měřit end‑to‑end, ne jen na jednotlivých službách. Praktický takeaway: uvažujte „latency budget“ jako SLO, separujte stateful orchestraci od stateless inference, a testujte reálné scénáře (barge‑in, krátké pauzy, šum, přerušení) – ne jen laboratorní demo.
Zdroj: modal.com/blog/low-latency-voice-bot
2) Voice AI stack pro agenty v roce 2026: kde vzniká latence a co s tím
AssemblyAI shrnuje „voice agent stack“ do čtyř pilířů: STT jako uši, LLM jako mozek, TTS jako hlas a orchestrace jako dirigent, který v reálném čase řídí tok dat a turn‑taking. Klíčové sdělení je, že kaskádní (sekvenční) pipeline je sice jednoduchá, ale v praxi vede k nepřijatelné kumulované latenci – a proto se v produkci prosazují streaming architektury, kde STT/LLM/TTS běží paralelně a uživatel slyší „první byte“ dřív, než je dokončen celý text. Pro telco/voiceboty je důležitá i disciplína kolem endpointingu: špatná detekce konce promluvy dělá bota buď agresivně přerušujícího, nebo naopak „zamrzlého“. Článek zároveň připomíná, že metriky jako WER samy o sobě nestačí – pro call centra jsou kritické alfanumerika (čísla, adresy, jména), formátování a stabilita v hlučném kanálu. Praktický takeaway: zaveďte metriky TTFT/TTFB, endpointing accuracy a „barge‑in success rate“ do monitoringu, a vybírejte komponenty podle toho, jak se chovají na telefonních datech (PSTN, komprese, šum), ne na čistých nahrávkách.
Zdroj: assemblyai.com/blog/the-voice-ai-stack-for-building-agents
3) OpenAI Realtime API po roce: GA, nové voice schopnosti a (hlavně) SIP
Heise rekapituluje, co se změnilo od preview po general availability Realtime API: přímá audio↔model komunikace s nízkou latencí, mini varianta pro rychlejší/levnější nasazení a zlepšení kvality generované řeči (nové hlasy a výraznější prosodie). Z pohledu provozu voicebotů je zásadní posun v „konverzačním“ chování: lepší práce s pauzami a dynamikou dialogu, včetně idle timeoutů („jste ještě na lince?“) a průběžných hlášek během dlouhých tool callů, což snižuje subjektivní pocit čekání. Pro telco integrace je nejdůležitější zmínka o podpoře SIP vedle WebSocket/WebRTC – to zjednodušuje napojení do stávajících telephony/contact center stacků a omezuje potřebu vlastních gateway vrstev. Heise také zmiňuje EU data residency, což je praktické téma pro evropské operátory a regulované prostředí. Praktický takeaway: pokud řešíte enterprise voice, vyplatí se udělat POC se SIP integrací a zároveň si pohlídat cost model (audio tokeny + cache) a fallback strategii (např. degradace na klasickou STT→LLM→TTS pipeline při špičkách nebo incidentu).
Zdroj: heise.de (OpenAI Realtime API přehled)
4) Frameworky pro voice agenty: RoomKit vs Pipecat vs TEN vs LiveKit (optika „co bude bolet v produkci“)
RoomKit (autor článku je jeho tvůrce) porovnává čtyři open‑source přístupy k voice agentům: „rooms & channels“, „pipelines & frames“, „graph v JSON“ a „agent jako participant ve WebRTC room“. I když je text částečně „srovnávací“, je užitečný jako rychlý checklist toho, co v produkci typicky rozhoduje: transport (WebRTC vs RTP/SIP), barge‑in a interruption logika, VAD/turn detection, AEC/denoise, nahrávání a integrace se službami (Deepgram, OpenAI, Cartesia…). Pro telco je praktické vidět, že telephony integrace není jen „připojit SIP“ – často je to i otázka audia (AEC, noise), eventů (DTMF), nahrávání pro QA a observability, a schopnosti kombinovat voice se „side channel“ (SMS/WhatsApp) ve stejném case. Článek zároveň naznačuje trade‑off: jednoduchost (LiveKit Agents) vs explicitní kontrola nad pipeline (Pipecat) vs multi‑channel orchestrace (RoomKit) vs graph konfigurace (TEN). Praktický takeaway: před výběrem frameworku sepište nefunkční požadavky (SIP/RTP, nahrávání, audit, monitoring, multi‑tenant, barge‑in) a udělejte 1–2 dny „spike“ na integraci do vašeho telephony stacku – ne jen demo v prohlížeči.
Zdroj: roomkit.live/blog/choosing-the-right-conversational-ai-framework
Závěr – 3 takeaways pro telco/voice
- Měřte end‑to‑end latenci (voice‑to‑voice) a rozpadněte ji na budget: transport + endpointing + STT + LLM TTFT + TTS TTFB.
- Telephony je víc než „napojit SIP“: v produkci vyhraje řešení s barge‑in, AEC/denoise, nahráváním, DTMF a dobrou observability.
- Modularita vs end‑to‑end: i když audio‑native modely rostou, modulární stack často dává lepší kontrolu nad cenou, compliance a fallbacky.