Krátký ranní briefing k věcem, které v posledních dnech hýbou světem AI chatbotů a hlavně voice/voicebotů – se zaměřením na to, co má reálný dopad na stavbu a provoz v telco.
OpenAI: nové „audio“ snapshoty pro Realtime/ASR/TTS – míň halucinací, lepší tool-calling
OpenAI vydalo nové snapshoty audio modelů (včetně gpt-realtime-mini-2025-12-15, gpt-4o-mini-transcribe-2025-12-15 a gpt-4o-mini-tts-2025-12-15) s cílem zlepšit spolehlivost produkčních voice workflow – od transkripce přes TTS až po nativní speech-to-speech agenty v Realtime API. Klíčový praktický posun je v robustnosti na „špinavém“ audio vstupu: méně halucinací při tichu/šumu a nižší WER v reálných podmínkách, což je přesně to, co telco call-centra typicky trápí (šum, přeslechy, krátké repliky, přerušování). U speech-to-speech modelů navíc zmiňují lepší instruction following a tool calling, tedy menší riziko, že voice agent „ukecá“ flow, ale správně zavolá funkci (např. ověření zákazníka, lookup tarifu, vytvoření ticketu) i během živé konverzace. Pro telco provoz to znamená méně fallbacků na operátora kvůli edge casům, lepší konzistenci v multi-step scénářích (identifikace → autorizace → změna služby) a možnost snižovat náklady přes „mini“ varianty, aniž by se dramaticky propadla spolehlivost. Takeaway: pokud už běžíte na starších snapshot verzích, dává smysl udělat A/B regresní test na vašich skutečných hovorech (zvlášť ticho/šum, barge-in, krátké odpovědi) a přepnout na nové snapshoty bez změny promptů, pak teprve ladit instrukce.
Zdroj: Updates for developers building with voice (OpenAI Developers Blog)
Microsoft Azure Speech SDK 1.48.1 (Feb 2026): metriky latence rozpoznávání + stop timeout (JS)
V únorovém releasu Azure Speech SDK 1.48.1 přibyla pro JavaScript explicitní metrika rozpoznávací latence (SpeechServiceResponse_RecognitionLatencyMs), která měří end-to-end čas od přijetí audia SDK až po doručení výsledku ze služby. Pro voiceboty je to důležité, protože už nejde jen „pocitově“ odhadovat zpoždění – můžete jej logovat po turnech, korelovat se špičkami, regiony, typem připojení a konkrétními dialplan scénáři (např. DTMF vs. řeč). Současně přidali ochranu Recognizer_StopTimeoutMs pro stopContinuousRecognitionAsync(), což v praxi snižuje riziko „zaseknutých“ session při nestabilní síti nebo při chybách na straně služby – typický telco problém v long-running hovorech. Když to dobře zapojíte, získáte jasnější SLO (např. P95 latence ASR v ms) a budete schopni automaticky eskalovat (přepnout na fallback STT, zkrátit timeouty, nabídnout callback) dřív, než se uživatel začne rozčilovat. Praktický takeaway: zaveďte standardní observability balíček pro voice (ASR latency, VAD/endpointing, time-to-first-token u TTS, a „turn duration“) a nastavte alerty na degradaci – výrazně to zkrátí debug incidentů.
Zdroj: What’s new – Speech service (Azure Speech SDK release notes)
OpenAI API: blížící se „shutdown“ snapshotů – plánujte migrace (a zamezte tichým výpadkům)
Na stránce OpenAI API deprecations je důležitá informace pro provoz: některé snapshot modely mají pevné datum vypnutí (např. chatgpt-4o-latest 17. 2. 2026, a další v následujících měsících). V telco voicebotech to bývá zrádné, protože integrace často běží dlouho „bez doteku“ a výpadek se projeví až v produkci – typicky v noci nebo o víkendu, kdy je nejhorší to řešit. Z pohledu architektury je to argument pro řízené „model pinning“ (verze v konfiguraci), pro canary rollout, a pro automatizované testy kompatibility (smoke testy na nejdůležitějších customer journeys) běžící pravidelně. Důležité je také oddělit modely pro text/LLM (dialog, NLU, tool orchestration) od audio vrstvy (ASR/TTS) tak, aby výměna jedné komponenty neznamenala rizikový „big bang“ release. Praktický takeaway: zaveďte do CI/CD kontrolu, která pravidelně porovná používané modely s deprecation listem a vytvoří ticket s termínem migrace + odhadovaným dopadem (prompt re-tuning, evaluace, compliance). To je levnější než incident v provozu a zároveň to pomáhá udržet konzistentní kvalitu konverzace.
Zdroj: Deprecations (OpenAI API)
Menší poznámka: i „mini“ modely už jsou použitelnější pro telco, ale jen s měřením kvality
Napříč releasy je vidět trend: poskytovatelé tlačí na to, aby levnější/rychlejší varianty („mini“) zvládaly stabilněji instrukce i náročnější multi-step scénáře. To je pro telco zajímavé, protože nejdražší část bývá dlouhý čas hovoru a velké objemy turnů, takže každé zlevnění tokenů/sekundy bez zhoršení UX má přímý dopad na unit economics. Současně to ale znamená, že se nevyplatí spoléhat na „feeling“ – mini model může vypadat OK v demo, ale selhá v reálných hovorech (šum, přerušování, dialekty, kódovaná jména/čísla). Reálný dopad proto přináší až evaluace na vašich datech: WER pro ASR, chybovost tool-callů, míra opakování otázky, a „handover rate“ na operátora. Praktický takeaway: nastavte si minimální sadu offline testů + produkční guardrails (např. confidence threshold, explicitní confirm na citlivé akce), a teprve pak škálujte mini variantu.
3 takeaways pro telco/voice:
- Bez observability (latence ASR/TTS, tool-calls, handover) se voiceboty v produkci špatně řídí – měřte P95/P99 a korelujte s incidenty.
- Stabilita při tichu/šumu a přesnost tool-callů jsou v call-centru důležitější než „nejchytřejší“ odpověď – vybírejte modely podle těchto metrik.
- Deprecations nejsou „papír“: mějte proces a automatické hlídání shutdown dat, ať se vyhnete tichým výpadkům v provozu.