Dnešní ranní briefing shrnuje čerstvé technické novinky kolem voice agentů, speech-to-text a nástrojů pro provoz hlasových botů. Zaměřuji se na dopad na telco provoz (IVR, call-centra, monitoring a škálování).
Azure OpenAI: dostupné nové modely gpt-realtime-1.5 a gpt-audio-1.5 (verze 2026-02-23)
Microsoft v přehledu „What’s new“ uvádí, že jsou nově dostupné modely gpt-realtime-1.5-2026-02-23 a gpt-audio-1.5-2026-02-23. Změna míří přímo na voice‑first aplikace: zmiňované jsou cílené zlepšení v instruction following, vícejazyčné podpoře a tool callingu při zachování nízké latence pro realtime interakce. Pro telco je důležité, že to typicky zvyšuje stabilitu dialogu v „telefonním“ režimu (přesnější dodržení tónu, eskalačních pravidel a konzistence při předávání do nástrojů/CRM). Prakticky to znamená méně „nečekaných“ odboček modelu u dlouhých hovorů a lepší použitelnost pro scénáře typu autentizace, triage a live assist. Takeaway: pokud provozujete voice agenta přes Azure Foundry, naplánujte A/B test na malém procentu provozu (latence, WER u přepisů, úspěšnost tool-callů) a připravte rollback na předchozí snapshot, pokud máte přísné SLA.
Zdroj: Microsoft Learn – What’s new in Azure OpenAI
OpenAI: model gpt-realtime-1.5 – flagship pro audio in/out (endpointy + ceny + modality)
OpenAI na stránce modelu gpt-realtime-1.5 explicitně pozicuje tento model jako „flagship audio model“ pro voice agenty a customer support, s podporou vstupů text/audio/image a výstupů text/audio. Pro telco integrace je podstatné, že model je dostupný napříč endpointy (Chat Completions, Responses i Realtime), takže se dá nasadit jak do WebRTC/SIP bridgingu, tak do klasických back‑endových flow s postupným zpracováním. Dokumentace uvádí kontextové okno 32k a také pricing za text i audio tokeny, což je praktické pro odhad nákladů u „dlouhých“ hovorů a pro rozhodování, kdy přepnout na levnější režim (např. sumarizace po hovoru vs. plný realtime). V provozu voicebotů je dobré vnímat, že „audio tokens“ mohou nákladově dominovat, pokud posíláte do modelu surové audio bez optimalizace (kodek, sample rate, VAD/turn detection). Takeaway: u call‑center scénářů si nastavte guardrails (max délka realtime sezení, VAD prahy, komprese/PCM parametry) a přidejte metriky „cost per resolved call“ + „tool-call success rate“ do observability.
Zdroj: OpenAI API – model gpt-realtime-1.5
Deepgram Self-Hosted (Feb 2026): 3× vyšší default concurrency limity + update Nova-3 multilingual (lepší code-switching)
Deepgram v changelogu pro Self‑Hosted February 2026 release (260212) zmiňuje navýšení defaultních concurrency limitů až o 3× pro Streaming STT, TTS a Voice Agent (dle plánu). Pro telco provoz je to přímo o škálování: vyšší „default“ limity mohou snížit potřebu rychlých eskalací na support při špičkách a zjednodušit capacity planning pro inbound kampaně a incidenty. Zároveň Deepgram uvádí update Nova‑3 Multilingual s nižším WER a výrazně lepším zvládáním code‑switchingu (míchání jazyků v jedné promluvě), což je v telco reálu časté (anglicismy, jména produktů, roaming, adresy, e-maily). Dopad: méně „word drops“ a tím pádem lepší NLU/slot filling, zejména pokud LLM stojí až nad přepisem a spoléhá na přesná entity. Praktický takeaway: pokud máte vícejazyčné linky (CZ/SK/EN) nebo firemní zákazníky, vyplatí se udělat regresní test na vlastních datech s code‑switchingem a porovnat nejen WER, ale i downstream KPI (intent accuracy, průměrný počet repromptů, úspěšnost ověření identity).
Zdroj: Deepgram Docs – Changelog
Deepgram Self-Hosted (Jan 2026): upozornění na breaking change pro TTS – pořadí rollout (Engine před API)
V témže changelogu Deepgram upozorňuje, že January 2026 self‑hosted release (release‑260115) přinesl změnu pro zrychlení TTS, která je nekompatibilní zpětně při servování TTS trafficu. Klíčová provozní informace: při upgrade je nutné nasadit nejdřív nový Engine (3.107.0-1) a až potom API (1.176.0), jinak riskujete výpadek TTS. Pro telco voiceboty to je typický „gotcha“ moment: i když STT část běží, TTS výpadek vám zlomí celé IVR flow (ticho na lince, nedokončené hovory, compliance riziko). Deepgram navrhuje blue‑green strategii, ale pointa je obecná: hlídat pořadí a kompatibilitu mezi komponentami (API/engine/license proxy). Takeaway: pokud jste na self‑hosted TTS, zaveďte do runbooku explicitní upgrade sekvenci + healthchecky na TTS latenci a „first audio byte“ před přepnutím trafficu.
Zdroj: Deepgram Docs – Changelog
Twilio Voice TwiML: volitelný Google Speech-to-Text V2 jako default a podpora Deepgram provider_model v <Gather>
Twilio v TwiML changelogu uvádí možnost zapnout Google Speech-to-Text (STT) V2 jako výchozí STT provider pro <Gather> na úrovni účtu a současně možnost specifikovat provider_model (včetně Deepgram jako nově podporovaného provideru). Pro telco je důležité, že to posouvá STT z „black box“ k explicitně řízené komponentě: můžete cíleně vybrat vendor/model podle jazyka, latency, ceny nebo compliance. V praxi to umožňuje hybridní strategii: kritické flow (ověření identity, čísla smluv) jet na nejspolehlivějším STT modelu, zatímco zbytek (open‑ended dotazy) optimalizovat na cenu. Taky to zjednodušuje incident management – když STT degraduje, máte jasný „switch“ na jiný provider/model bez redesignu celé aplikace. Takeaway: pokud jedete Twilio IVR/voicebot, zvažte zavedení canary routingu podle ANI/DNIS nebo podle jazyka, a logujte „STT provider/model“ do traceů, ať umíte korelovat chyby s konkrétním backendem.
Zdroj: Twilio Docs – TwiML Changelog
Závěr – 3 rychlé takeaways pro telco/voice:
- Upgrade voice stacku dělejte jako řízený rollout: A/B testy, rollback, a metriky (latence, WER, tool-call success).
- Vícejazyčný provoz a code-switching už není edge-case – testujte na vlastních hovorech a měřte dopad na intent/slot KPI.
- STT/TTS providery berte jako konfigurovatelnou vrstvu: přepínatelnost a observability jsou dnes stejně důležité jako samotná přesnost.