Ranní výběr novinek z AI chatbotů a voice/voicebotů se dnes točí hlavně kolem latence (reálný dialog), kvality syntézy řeči a toho, jak velcí enterprise hráči skládají hlasový stack do produkčního provozu.
MiniMax Speech 2.6: TTS pro voice agenty s latencí pod 250 ms a lepší prací s „divným“ textem
MiniMax vydal Speech 2.6, který cílí přímo na scénáře „voice agent“ a deklaruje end-to-end latenci generování audia pod 250 ms, tedy v pásmu, kde už TTS přestává být hlavní brzdou plynulého rozhovoru. Prakticky zajímavá je i nová schopnost číst specializované formáty bez ručního pre-processingu: URL, e-maily, telefonní čísla, částky, data nebo IP adresy (to jsou přesně entity, které se v telco a call-centrech vyskytují pořád). To snižuje riziko, že bot v hovoru „zakoktá“ nebo špatně přečte identifikátor účtu či částku, a zároveň to zjednodušuje orchestrace (méně regexů a transformací před TTS). Další funkce „Fluent LoRA“ míří na voice cloning: i když je zdrojová nahrávka neplynulá nebo s akcentem, model má zachovat timbre, ale vygenerovat plynulý projev podle cílového textu – v praxi to může zlepšit konzistenci značkového hlasu napříč jazyky. Takeaway pro telco provoz: pokud řešíte barge‑in a přirozené turn-taking, hlídejte si celkovou latenci pipeline (ASR→LLM→TTS) a zvažte TTS, které umí entity „číst správně“ bez křehkých pravidel.
Zdroj: MiniMax – MiniMax Speech 2.6: The Ultimate Voice Agent Has Arrived
VoiceAgentRAG (arXiv): dual-agent architektura, která schovává RAG latenci do backgroundu
Na arXivu vyšel paper VoiceAgentRAG, který řeší klasický problém reálných voice agentů: RAG (retrieval) často přidá stovky ms až sekundy a tím rozbije přirozený dialog. Autoři navrhují „dual-agent“ přístup: background „Slow Thinker“ průběžně sleduje konverzaci, predikuje pravděpodobná další témata a dopředu přednačítá relevantní chunk-y do semantické cache (FAISS). Foreground „Fast Talker“ pak při odpovědi čte jen z této cache s (deklarovaně) sub-milisekundovým přístupem a při cache hitu úplně obchází vektorovou DB. Pro telco voiceboty je to zajímavé hlavně tam, kde máte velké knowledge base (tarify, roaming, postupy, incidenty) a zároveň tvrdý SLA na „time-to-first-audio“ – prefetch může zlepšit plynulost bez toho, abyste rezignovali na fakta. Praktický takeaway: pokud dnes bojujete s tím, že bot „mlčí“, zkuste oddělit retrieval od generování a přemýšlejte o predikci dalších kroků (ať už heuristikou, nebo LLM) + agresivní caching na úrovni session.
Zdroj: arXiv – VoiceAgentRAG: Solving the RAG Latency Bottleneck in Real-Time Voice Agents
IBM × Deepgram: voice stack jako „first‑class“ součást enterprise orchestrace agentů
IBM oznámilo spolupráci s Deepgramem: Deepgram STT/TTS má být integrován do watsonx Orchestrate, včetně Agent Builderu, a Deepgram se tím stává prvním „dedicated voice partner“ IBM. Signál pro trh je jasný: hlas se přesouvá z experimentu do jádra enterprise automatizace a velcí hráči skládají best‑of‑breed komponenty kvůli latenci, přesnosti a multilingvální podpoře ve škále. Z pohledu telco provozu je důležitá zmínka o odolnosti v hlučném prostředí, práci s akcenty a konverzační řečí – typické call-center podmínky, kde tradiční ASR často padá na WER i na stabilitě diarizace a endpointingu. V článku zaznívá i compliance/accessible motiv (real‑time captioning), který může být relevantní pro interní procesy, QA i regulatorní požadavky. Praktický takeaway: při stavbě voicebotů do produkce se vyplatí hodnotit „celý balík“ (latence, jazykové varianty, tuning, monitoring) a ne jen cenu za minutu – a enterprise integrace naznačují, že zákazníci budou chtít hlasové schopnosti jako standardní součást agentních workflow.
Zdroj: eeNews Europe – IBM and Deepgram target enterprise automation with voice AI partnership
3 takeaway pro telco/voice provoz:
- Latence je produktový parametr: optimalizujte pipeline (streaming ASR/TTS, barge‑in, caching) na „čas do prvního zvuku“, ne jen na WER.
- Entity v řeči jsou křehké: TTS, které umí nativně číst čísla, částky, IP/URL a e-maily, výrazně snižuje množství pravidel a incidentů.
- RAG bez „prefetch“ často zabije plynulost: oddělte retrieval do backgroundu a používejte session cache pro nejpravděpodobnější follow‑upy.