Ranní briefing: tři čerstvé signály z oblasti voice AI a chatbotů, které mají praktický dopad na stavbu a provoz hlasových botů (zejména v telco provozu a kontaktních centrech).
AssemblyAI: nové streaming endpointy pro nižší latenci a EU/US data residency
AssemblyAI přidalo nové WebSocket endpointy pro streaming speech-to-text: edge routing (automaticky směruje do nejbližšího regionu) a separátní data zone endpointy pro USA a EU, kde data „nez opustí“ daný region. Pro voiceboty je to důležité hlavně kvůli dvěma věcem: (1) měřitelně lepší latenci u real‑time přepisů, a tím plynulejší turn‑taking a méně „mluvíme přes sebe“, a (2) jednodušší compliance u zákaznických hovorů (GDPR, interní governance, požadavky na lokalitu zpracování). V telco to typicky znamená, že můžete bezpečněji poslat streaming audio do ASR bez komplikovaných výjimek a zároveň držet SLA na odezvě i při mezinárodním provozu. Praktický takeaway: udělejte si v architektuře „endpoint abstraction“ (konfigurovatelný WS URL per tenant/region) a měřte end‑to‑end latency (RTP→ASR→LLM→TTS) – edge routing má smysl jen pokud se promítne do celého řetězce. Zdroj (AssemblyAI Changelog).
AssemblyAI: lepší diarizace pro krátké audio + multikanálové štítkování speakerů
V changelogu zároveň přibylo zlepšení diarizace pro audio kratší než 2 minuty (lepší odhad počtu mluvčích a zlepšení cpWER) a také podpora multikanálové diarizace u předem nahraného audia. Pro kontaktní centra a telco nahrávky (split‑channel: agent vs. zákazník) je to zásadní: kvalitnější přiřazení replik ke speakerovi zvyšuje použitelnost sumarizací, QA analýz, detekce eskalací i „agent assist“ funkcí. V praxi to snižuje množství ručních oprav a hlavně eliminuje tiché chyby, kdy LLM dostane špatně označené repliky a začne dávat špatná doporučení (např. zamění slib agenta za požadavek zákazníka). Takeaway pro voiceboty: pokud máte k dispozici multikanálový záznam, posílejte ho do ASR jako multichannel a udržujte speaker labels end‑to‑end až do analytiky/RAG indexace; rozdíl ve stabilitě downstream pipeline bývá výrazný. Zdroj (AssemblyAI Changelog).
OpenAI Realtime API (WebSocket): nejasné rozlišení „idle timeout“ vs. konec řeči ve VAD eventech
Na OpenAI Developer Community se objevil praktický problém při stavbě voicebota přes Realtime API po WebSocketu: událost input_audio_buffer.speech_stopped přichází jak při reálném ukončení řeči uživatelem, tak při vypršení idle_timeout_ms (server‑side VAD), a chybí samostatný event typu „timeout_triggered“, který je dle dokumentace dostupný spíš pro WebRTC/SIP scénáře. Pro provoz voicebotů je to důležité, protože „ticho“ a „konec repliky“ nejsou totéž: v telco hovorech máte jitter, šum, hold music, DTMF pauzy i krátké odmlky – a pokud je nerozlišíte, bot může začít odpovídat v nevhodný moment (nebo naopak zbytečně čekat). Dopad je přímo do UX i nákladů: špatně nastavené timeouty zvedají počet tokenů/sekund TTS i množství „barge‑in“ přerušení. Takeaway: pokud jedete WebSocket variantu, doporučuju si idle logiku měřit a řídit aplikací (vlastní timer nad audio frame streamem + heuristiky) a eventy z API brát jako „best effort“ signál, ne jako jediný zdroj pravdy; zároveň logujte audio_start_ms/audio_end_ms a korelujte s telephony metrikami. Zdroj (OpenAI Developer Community).
Deepgram: $130M funding a důraz na ultra‑low latency a „reálný hluk“ (drive‑thru jako stres test)
Deepgram oznámil financování $130M při valuaci $1.3B a akvizici startupu OfOne zaměřeného na drive‑thru voice ordering. I když jde primárně o byznysovou zprávu, v textu je důležitý technický podtext: u real‑time voice AI se „laťka“ odezvy pohybuje kolem stovek milisekund a největší problém často není LLM, ale akustika a infrastruktura (noisy prostředí, přerušování, správný okamžik pro vstup do řeči). Pro telco voiceboty je to analogie k hovorům z auta, z ulice nebo z továrny – tedy typické situace zákaznických center, kde se kvalita signálu mění během hovoru. Dopad do stavby botů: investice do robustního VAD/turn‑takingu, adaptivních thresholdů a „barge‑in“ podpory mívá větší návratnost než hon za větším LLM; podobně je klíčové mít observabilitu latence po segmentech a fallback strategie (např. degradovat na kratší odpovědi při přetížení). Praktický takeaway: berte „drive‑thru“ jako inspiraci pro testovací sadu – pusťte si vlastní voicebot load testy s reálným šumem, překryvem hlasů a proměnlivým packet loss; teprve pak nastavujte timeouty a SLA. Zdroj (SiliconANGLE).
3 rychlé takeaways pro telco/voice:
- Latence a data‑residency jsou teď „feature“, ne jen infrastruktura – konfigurovatelné endpointy a měření E2E latency se vyplatí.
- Diarizace (ideálně multikanál) je základ pro spolehlivou analytiku a agent‑assist; špatné speaker labels kazí downstream LLM rozhodování.
- U real‑time voice botů neberte VAD/timeout eventy jako absolutní pravdu – logujte, korelujte s telephony metrikami a mějte vlastní kontrolní logiku.