Dnešní ranní briefing shrnuje pár praktických novinek z oblasti voice agentů a komponent (TTS/STT/streaming), které mají přímý dopad na stavbu a provoz botů v telco prostředí.
Mistral: otevřené TTS „Voxtral TTS“ cílí na real‑time a edge
Mistral uvedl otevřený text‑to‑speech model Voxtral TTS, který má být použitelný pro voice asistenty i enterprise kontaktní centra a zároveň běžet i na menších zařízeních (telefon/laptop/edge). Důležitý je důraz na nízkou latenci: firma uvádí time‑to‑first‑audio kolem 90 ms (pro 500 znaků) a vysoký „real‑time factor“, což je přesně typ metriky, která rozhoduje o tom, jestli hlasový bot působí „živě“ nebo „rozbitě“. Z provozního pohledu v telco je zajímavé i rychlé klonování hlasu z krátkého vzorku a vícejazyčnost bez ztráty charakteru hlasu – to otevírá scénáře typu jednotný brand voice napříč trhy a kanály (IVR, appka, web). Pro stavbu botů to znamená: přibývá reálně nasaditelná open‑weights alternativa k uzavřeným TTS providerům, takže se zlepšuje vyjednávací pozice (cost, SLA) a zároveň compliance (možnost on‑prem/privátního hostingu). Praktický takeaway: pokud dnes optimalizujete E2E latenci, začněte měřit TTFA/RTF u TTS stejně tvrdě jako WER u STT, a uvažujte o A/B testu open‑weights TTS v kritických flow (ověření kódu, přenos hovoru, upsell) s auditovatelným logováním.
Odkaz: https://techcrunch.com/2026/03/26/mistral-releases-a-new-open-source-model-for-speech-generation/
EVA (ServiceNow): framework na end‑to‑end evaluaci voice agentů (Accuracy + Experience)
ServiceNow představilo EVA – end‑to‑end evaluační framework pro voice agenty, který netestuje jen „splněno/nesplněno“, ale kombinuje dvě osy: EVA‑A (Accuracy) a EVA‑X (Experience). Klíčová pointa pro praxi: u voice botů často selže produkce ne kvůli „špatnému LLM“, ale kvůli turn‑takingu, latenci, příliš dlouhým odpovědím nebo chybám v přednesu kritických entit (kódy, čísla letu/účtu, částky) – a EVA na to míří přímo včetně metrik typu Speech Fidelity a Turn‑Taking. Framework navíc používá realistickou bot‑to‑bot audio architekturu (simulovaný uživatel v audio, agent v audio, deterministické nástroje, validátory), takže testuje celé potrubí STT→LLM→TTS i audio‑native varianty. V telco provozu to je přesně to, co potřebujete pro řízení kvality: oddělit „agent umí“ vs. „agent je poslouchatelný“ a zavést regress testy pro release cykly (model upgrade, prompt change, změna VAD). Praktický takeaway: zaveďte dvojí KPI (task success + experience), přidejte automatické scénáře s entitami (PIN/OTP, čísla smluv) a měřte i konzistenci napříč opakováními (pass@k), protože produkční problém často není průměr, ale tail‑risk.
Odkaz: https://huggingface.co/blog/ServiceNow-AI/eva
LiveKit: „sequential pipeline“ a proč streaming + barge‑in rozhodují o UX
LiveKit detailně rozebírá základní architekturu pro voice agenty (Audio In → VAD → STT → LLM → TTS → Audio Out) a hlavně vysvětluje, proč se „naivní“ blokující pipeline v praxi rozpadá na latenci (1–2 s+) a proč streaming (partial STT, token streaming, streaming TTS) umí stáhnout E2E do ~400–800 ms. Pro telco voiceboty je to důležité, protože i perfektní odpověď je k ničemu, když se klient během ticha začne překřikovat, opakuje dotaz nebo zavěsí – a to je čistě systémová vlastnost pipeline. Článek jde i do provozních detailů jako barge‑in (přerušení uživatelem) a edge cases: filler zvuky, falešné přerušení kvůli echu, a zejména „mid‑tool‑call“ přerušení, kde musíte rozhodnout, zda akci zrušit nebo dokončit (u nevratných operací je potřeba blokovat interrupce). Pro stavbu botů v telco to znamená: architektura není jen „vyber model“, ale hlavně správné řízení stavů, interrupcí, a auditovatelnost (cascaded pipeline má výhodu textového trailu pro compliance). Praktický takeaway: explicitně navrhněte politiku přerušení (co je přerušitelné vs. ne), přidejte echo‑cancellation a guardrails pro tool calls (idempotence, transactional design), a měřte time‑to‑first‑audio + time‑to‑first‑token jako primární SLO.
Odkaz: https://livekit.com/blog/sequential-pipeline-architecture-voice-agents
AWS: nasazení Pipecat voice agentů na Bedrock AgentCore Runtime (WebSockets/WebRTC/telephony)
AWS publikovalo praktický návod, jak nasazovat Pipecat voice agenty na Bedrock AgentCore Runtime se zaměřením na transportní vrstvy (WebSockets, WebRTC včetně TURN, a telephony integrace). Pro telco je cenné, že nejde jen o „modely“, ale o produkční reality: izolace session (microVM), autoscaling pro špičky, dlouhé konverzace až hodiny a účtování za skutečné použití místo idle kapacity – přesně to, co řeší kontaktní centra. Článek popisuje bezpečný pattern pro WebSocket přístup přes SigV4 pre‑signed URL (credential management odděleně od agent logiky), což je dobrá inspirace pro enterprise security model. Zároveň vysvětluje, proč na AgentCore v praxi vychází WebRTC často lépe než WebSockets (UDP, odolnost na jitter), a realisticky přiznává, že přímé P2P STUN cesty nemusí fungovat (symetrický NAT), takže je potřeba TURN / managed relay. Praktický takeaway: pokud stavíte voice v telco, berte transport jako „první míli“ latency budgetu – a připravte si varianty (WS pro prototyp, WebRTC pro produkci, telephony/SIP pro hlas), včetně plánů na TURN a observability end‑to‑end.
Odkaz: https://aws.amazon.com/blogs/machine-learning/deploy-voice-agents-with-pipecat-and-amazon-bedrock-agentcore-runtime-part-1/
Takeaways pro telco/voice (rychle):
- Měřte a řiďte latenci jako produktovou metriku (TTFA/TTFT/E2E) – streaming pipeline je rozdíl mezi „wow“ a „zavěšeno“.
- Zaveďte end‑to‑end evaluační scénáře, které hodnotí i „experience“ (turn‑taking, stručnost, speech fidelity), ne jen task completion.
- Navrhněte politiku přerušení + idempotentní tool calls a počítejte s realitou transportu (WebRTC/TURN/telephony).