Ranní výběr ze zahraničních zdrojů k AI chatbotům a voice/voicebotům se zaměřením na provozní realitu (latence, turn-taking, STT/TTS volby) v telco prostředí.
Voice agent infrastruktura: kde se ztrácí latence a jak ji stáhnout pod 500 ms
Článek detailně rozebírá, proč i při rychlých komponentách (STT/TTS) často končí end-to-end latence voice agenta na 800 ms až 2 s: sčítají se zpoždění v ASR, LLM, TTS, síti i orchestraci. Důležité je, že „rychlá STT“ sama o sobě neznamená rychlého agenta – pro pocit přirozené konverzace je cílem držet reakci typicky v okně 300–500 ms, jinak uživatelé začnou skákat do řeči nebo ukončí hovor. Autor doporučuje architektury založené na streamingu a paralelizaci (např. začít generovat/číst odpověď dřív, než je hotový celý výstup LLM, a průběžně posílat audio), plus důraz na endpointing/VAD jako často přehlížený zdroj „ticha“. Pro telco voiceboty to znamená měřit latenci po krocích (TTFT/TTFA), zavést routing na rychlejší modely pro jednoduché dotazy a agresivně optimalizovat turn-taking (endpointing policy, barge‑in, buffer). Praktický takeaway: bez systematické telemetrie (per-stage latency, jitter, počet falešných přerušení) budete ladit naslepo – první krok je instrumentace a cílené SLO pro „time-to-first-audio“.
Zdroj: introl.com – Voice AI Infrastructure: Building Real-Time Speech Agents
STT provider jako budoucí konkurent? Porovnání směřování AssemblyAI vs Deepgram (vs Gladia)
Analýza porovnává nejen parametry STT (latence, jazyková podpora, code-switching), ale hlavně strategický posun dodavatelů směrem k „full voice AI stacku“ (STT+TTS+LLM orchestrace). Pro stavbu a provoz telco botů je to důležité z pohledu vendor lock‑inu a budoucí vyjednávací pozice: pokud váš STT dodavatel nabízí vlastní agent platformu, může se z partnera stát přímý konkurent. Text zmiňuje typické třecí plochy v praxi: real‑time endpointing a stabilita streamingu vs přesnost; a také GDPR/data residency (kam tečou audio data, co znamená US routing). Dopad na telco: u více jazyků a code‑switchingu (typicky CZ/SK/EN) je často cennější robustní multilinguál a „no training on customer audio“ politika než nejnižší cena za minutu, protože compliance incident je dražší než pár centů na hovoru. Praktický takeaway: oddělte rozhraní (abstrakce STT/TTS), mějte připravený druhý provider a pravidelně benchmarkujte na vlastních call‑nahrávkách (hluk, přerušování, akcenty), ne na laboratorních samplech.
Zdroj: gladia.io – AssemblyAI vs Deepgram (vs Gladia): Which Speech-to-Text API…
Bug z praxe: falešná přerušení (false interruption) a zpožděné přehrávání řeči v LiveKit Agents při turn detection přes STT
V GitHub issue z prostředí LiveKit Agents se řeší konkrétní provozní problém: při konfiguraci turn detection „stt“ (např. s Deepgram STT) dochází k „phantom“ událostem resumed=false interrupted speech, které pak výrazně zpožďují playback odpovědi. Důležité je, že to není teoretický detail – ve voicebotovi se to projeví jako nepřirozené pauzy, zadrhávání a pocit „agent je pomalý“, i když samotná STT vrací transcript rychle (v logu jsou vidět transcript delay stovky až desítky ms). Pro telco provoz to ukazuje, že turn-taking a detekce konce repliky jsou stejně kritické jako výběr LLM; navíc to může být závislé na tichu po replice, endpointingu a specifikách telephony noise cancellation. Praktický takeaway: logujte a alertujte „agent_false_interruption“/barge‑in metriky, testujte scénáře s dlouhým tichem po větě, a mějte fallback na VAD‑based turn detection nebo konzervativnější timeouty, pokud STT endpointing generuje falešné signály. Pokud nasazujete LiveKit/SIP integraci ve velkém, je to dobrý kandidát na canary rollout a regresní testy před upgradem verzí agent frameworku či STT pluginu.
Zdroj: github.com – livekit/agents Issue #4615
Zajímavost k provozu: latence je „součet drobností“ – proto se vyplatí standardizovat měření a SLO pro voice
Z výše uvedených zdrojů je společný motiv jasný: v reálném provozu voice agentů rozhodují milisekundy a stabilita turn-takingu, ne jen „jak chytrý“ je model. Jakmile přidáte PSTN/SIP, noise cancellation, regionální routování a špičkové zatížení, začnou se objevovat jevy jako jitter, buffer bloat, a hlavně falešné přerušení/endpointing chyby, které dramaticky zhorší UX. Pro telco týmy to znamená posunout se od ad‑hoc ladění k „voice SRE“ přístupu: definovat měřitelné cíle (TTFT, TTFA, end-to-end latency, barge‑in success rate), sbírat distribuované trace a dělat A/B konfigurací endpointingu. Praktický takeaway: i bez změny modelu často získáte největší zlepšení tím, že zkrátíte ticho (endpointing), zavedete streaming TTS a omezíte payloady/prompt prefixy (cache/prompt caching), protože každých 100–200 ms je už na telefonu slyšet.
3 telco/voice takeaways
- Bez telemetrie po krocích (STT/LLM/TTS/network) je optimalizace latence loterie – nastavte SLO pro TTFA a false interruptions.
- Turn-taking (endpointing, VAD, barge‑in) má na UX často větší dopad než volba „nejlepšího“ LLM.
- Vendor strategie (STT → full stack) je riziko: držte abstrakční vrstvu a pravidelně benchmarkujte na vlastních telco nahrávkách.