Dnešní ranní briefing shrnuje praktické novinky a postupy pro stavbu a provoz AI chatbotů a zejména voice/voicebotů v produkci (telco/call centra) – s důrazem na testování, observabilitu a realtime audio pipeline.
Testing LiveKit voice agentů: proč textové testy nestačí
Hamming AI vydalo (aktualizace: leden 2026) ucelený průvodce testováním voice agentů postavených na LiveKitu, který jasně rozlišuje „text-only“ testování logiky od plnohodnotného testování přes reálný audio/WebRTC stack. Pointa je, že jednotkové testy nad transkriptem sice ověří konverzační logiku, tool-cally a regresní scénáře, ale neodhalí typické produkční problémy: turn-taking, přerušování, jitter, dead-air a latenci v reálném hovoru. Doporučený postup je mít rychlé textové testy na každý commit a těžší full-stack testy (včetně latence a přerušení) pro kandidáty k nasazení. Pro telco provoz je to důležité, protože zákaznický dojem je extrémně citlivý na stovky ms a špatné přerušování – a to v textu „vypadá dobře“, ale v hovoru je to nepoužitelné. Praktický takeaway: zaveďte metriky typu time-to-first-word / time-to-first-token, scénářové regresní testy z reálných incidentů a separujte CI pipeline na „levnou deterministickou“ a „drahá realistická“ testovací kola.
Zdroj: hamming.ai – Testing LiveKit Voice Agents (2026)
Observabilita voice AI: bez end-to-end trace na úrovni audio rámců budete jen hádat
TrueFoundry popisuje, proč klasické APM (CPU/mem/requesty) často nepomůže při debugování voice AI: hlasový stack je řetěz (gateway → ASR → NLU → agentic RAG → TTS) a selhání se projeví jako dead air, useknutí řeči nebo robotické koktání. Klíč je sledovat celou konverzaci jako jednotku (conversation ID) a měřit latenci i kvalitu napříč kroky – zejména když se latence kumuluje a 200 ms v ASR + 400 ms v RAG může zabít UX. Z pohledu telco je prakticky důležitá schopnost rychle určit, zda problém je ve špatné transkripci (doménový šum, nízká confidence), v pomalém retrievalu (vektor DB/reranking), nebo v TTS/streamingu – a to při špičkách s tisíci paralelních hovorů. Článek navíc zmiňuje auditovatelnost a řízení přístupů (ACL) a potřebu bezpečného „inter-agent“ provozu (např. přes standardy typu MCP), což v telco/fintech režimech často rozhoduje o tom, co lze pustit do produkce. Takeaway: definujte latency budget po krocích (waterfall), logujte „reasoning/tool“ stopy u agentic RAG a zaveďte kvalitativní metriky (WER/ASR confidence, turn interruption rate) jako first-class signály vedle infra metrik.
Zdroj: truefoundry.com – Specialized Observability for Production Voice AI
OpenAI Realtime API kompatibilita v praxi: LocalAI skládá VAD+STT+LLM+TTS jako pipeline
LocalAI publikovalo stručnou, ale praktickou stránku k podpoře OpenAI Realtime API (WebSocket protokol pro nízkou latenci hlasu i textu) a hlavně k tomu, jak to implementují jako konfigurovatelnou pipeline. Model (resp. „pipeline model“) se skládá z komponent pro VAD (detekce řeči), STT, LLM a TTS – a každou část můžete vyměnit (např. silero VAD + Whisper pro transkripci + menší lokální LLM + TTS). Pro telco je to důležité jako architektonický pattern: Realtime „spec“ není jen jeden model, ale orchestrace více kroků; tím pádem se dá optimalizovat latence, cena i compliance (např. lokální STT/LLM on‑prem a jen TTS v cloudu, nebo naopak). Praktický dopad na provoz botů: potřebujete jasné SLA pro každý krok, možnost fallbacků (když STT degraduje) a testování na reálném audio streamu, protože VAD a bufferování rozhodují o turn-takingu. Takeaway: přemýšlejte o voice agentu jako o pipeline s explicitními rozhraními a metrikami – a už při návrhu si nakreslete, kde chcete mít „swap points“ (výměna STT/LLM/TTS bez přepisu celé aplikace).
Zdroj: localai.io – Realtime API (OpenAI Realtime protocol)
ElevenLabs changelog: nižší latence, WAV výstupy a jemnější kontrola turn-takingu i debugování
V aktuálním changelogu ElevenLabs je několik změn, které jsou pro voiceboty v telco praktické: v3 „out of alpha“ s deklarovanou nižší latencí a vyšší stabilitou, plus rozšíření výstupních formátů (WAV v různých samplovacích frekvencích) pro Text-to-Dialogue. Pro telefony je klíčové mít snadnou cestu k 8 kHz (PSTN) i 16 kHz (wideband) bez dodatečného transcodingu, protože ten zvyšuje latenci a může kazit kvalitu. Zajímavé jsou i „speculative_turn“ a další nastavení turn configu: to je přesně oblast, kde se rozhoduje, jestli agent skáče do řeči, nebo naopak nechává dlouhé pauzy. Pro provoz je užitečné i přidání raw_error_message v event modelech a webhook response filtering – zlepšuje to debugging a snižuje objem citlivých dat, která vám tečou do logů/webhooků. Takeaway: projděte si formáty a turn konfigurace u TTS/agent platformy, sjednoťte to s vaším telephony stackem (kodeky/sampling) a nastavte si standardní diagnostické události pro rychlé RCA při incidentech.
Zdroj: elevenlabs.io – Changelog
3 takeaways pro telco/voice
- Testování: kombinujte text-only regresní testy s plnohodnotnými audio/WebRTC testy (latence, přerušování, jitter).
- Observabilita: měřte end-to-end konverzaci (waterfall po krocích) a kvalitu signálu (ASR confidence/WER, interruption rate), ne jen infra metriky.
- Architektura: navrhujte voice agenty jako explicitní pipeline (VAD→STT→LLM→TTS) se „swap points“ a fallbacky kvůli ceně, SLA a compliance.