Ranní přehled shrnuje čerstvé technické postřehy ze světa AI voice agentů a chatbotů – hlavně tam, kde to má dopad na provoz v telco (PSTN/SIP, latence, testování a governance).
Sub-200ms voice agent přes Twilio Media Streams + OpenAI Realtime (praktická architektura)
Autor popisuje jednoduchý, ale produkčně relevantní pattern: most mezi Twilio Media Streams (G.711 μ-law 8 kHz přes WebSocket) a OpenAI Realtime API (audio-in/audio-out přes WebSocket). Klíčová pointa je, že se vyhnete klasickému řetězci STT → LLM → TTS a tím dramaticky snížíte vnímanou prodlevu; v článku uvádí zhruba ~200 ms od konce řeči volajícího do startu odpovědi agenta. Prakticky užitečné jsou detaily typu „append“ do input_audio_buffer a posílání response.audio.delta zpět do Twilia bez mezizpracování, plus doporučení doplnit asynchronní transkripci (např. whisper-1) jen pro logy a audit bez dopadu na latenci. Pro telco provoz je důležité i upozornění na robustnost: výpadek jedné strany (Twilio/OpenAI) musí být řešen reconnectem tak, aby volající neslyšel ticho nebo rozpad audia. Takeaway: pokud stavíte voicebota na PSTN, zvažte „bridge“ architekturu a řešte hlavně stabilitu WebSocketů, barge‑in a metriky latence (p95), ne jen demo kvalitu.
WebRTC vs WebSocket pro PSTN voice AI: transport není bottleneck (dokud je LLM pomalý)
Tenhle post je dobrý „reality check“ pro týmy, které chtějí přepsat media vrstvu, protože „WebRTC musí být rychlejší“. Autor udělal PoC na produkčním systému a porovnal WebSocket cestu (Twilio Programmable Voice Media Streams) proti WebRTC cestě přes LiveKit + SIP trunking. Výsledek: medián latence odpovědi byl velmi podobný (~1,92 s vs ~2,06 s) – u PSTN scénářů dominuje inference/LLM, ne transportní overhead. Důležitý je i závěr ke kvalitě zvuku: pokud zákazník volá z PSTN, kvalitu omezuje G.711/8 kHz; přechod na Opus 48 kHz „uvnitř“ infrastruktury to sám o sobě nezachrání. Praktický telco takeaway: investujte do audio paceru (frame timing 20 ms), bufferů, detekce underrunů a do optimalizace modelu/turn-taking; WebRTC dává smysl hlavně pro web/app volání mimo PSTN nebo když inference spadne o řád dolů.
Amazon Connect: Testing & Simulation pro voice/chat scénáře + logy před nasazením
No Jitter shrnuje novinky kolem Amazon Connect, přičemž pro stavbu botů je nejzajímavější část „Testing and Simulation“. Pointa: můžete simulovat end‑to‑end zákaznické interakce pro voice i chat a definovat parametry (atributy zákazníka, očekávané odpovědi, stavové podmínky jako after‑hours nebo plné fronty) ještě před ostrým provozem. To je přesně to, co v telco často chybí – opakovatelné testy na úrovni celého call-flow, nejen unit testy intentů. Důležité je i to, že výstupem mají být detailní logy, které pomáhají rychleji diagnostikovat, proč se scénář rozpadl (např. špatné routování, queue logic, edge cases ve slot‑fillingu). Praktický takeaway pro provoz: zaveďte „release gate“ pro voicebota (smoke testy klíčových scénářů + failure paths) a sbírejte standardizované logy per run; výrazně to sníží incidenty po změnách promptů/flows/integrací.
Full‑stack voice platform vs „middleware“ orchestrace (latence, náklady, governance)
ElevenLabs porovnává svůj full‑stack přístup s „middleware“ platformou (Retell) a i když jde o vendor článek, obsahuje užitečné architektonické rozlišování. Klíčové tvrzení: vertikální integrace (STT+TTS+agent layer) snižuje latenci a variabilitu, protože odpadnou síťové „hops“ mezi poskytovateli; u orchestrace je naopak potřeba pečlivě ladit každý článek pipeline a počítat s kumulací nákladů i SLA rizik. Pro telco provoz je zajímavé praktické vyjmenování systémových funkcí, které bývají „must have“ (transfer na člověka, DTMF, voicemail detection, guardrails, PII redakce) – a že rozdíly často nejsou v LLM, ale v provozních funkcích okolo. Dobrý takeaway je i governance: čím víc vendorů skládáte, tím víc incidentních tříd přibývá (latence, výpadky, změny API, kompatibilita kodeků/streamingu). Prakticky: i když preferujete best‑of‑breed, stanovte si měřitelné SLO (latence p95, WER/intent accuracy, dropout rate) a mějte fallback režimy (např. degradace na „3‑step“ pipeline nebo na DTMF IVR) pro výpadky jednotlivých komponent.
Závěr: 3 rychlé takeaways pro telco/voice
- Neřeš jen transport (WebRTC vs WS) – u PSTN typicky vyhrává optimalizace inference, turn‑takingu a audio paceru.
- Zaveď „pre‑prod“ simulace a end‑to‑end testy voice/chat flow (včetně failure pathů) jako release gate.
- Měř a řiď SLO (latence p95, stabilita streamu, dropout) a navrhuj fallbacky pro výpadky providerů.