Ranní výběr praktických novinek pro stavbu a provoz AI chatbotů a voicebotů (se zaměřením na telco a provozní realitu: latence, spolehlivost, integrace, audit).
OpenAI API changelog (březen 2026): nové „mini/nano“ modely a nástroje pro agentní workflow
OpenAI v březnu 2026 doplnilo do API nové modely GPT‑5.4 mini a GPT‑5.4 nano a zároveň zdůraznilo směr: rychlé, levné varianty pro vysoké objemy plus agentní funkce v Responses API (tool search, computer use, compaction a 1M kontext pro vybrané modely). Pro voice/IVR scénáře v telcu je to důležité hlavně kvůli ekonomice a latenci: u inbound linek se počítá každý token i každá stovka milisekund, a „mini/nano“ třída dává reálnou šanci obsloužit velký provoz bez dramatického nárůstu nákladů. Praktický dopad: pro rutinní kroky (ověření, sběr parametrů, routing, FAQ) se vyplatí rozdělit dialog na „thin“ model a jen eskalovat na větší model, když je potřeba hlubší reasoning nebo práce s delším kontextem. Tool search a compaction jsou navíc přímo zaměřené na snižování tokenů/latence u agentů – to je přesně bolest produkčních botů (RAG, CRM konektory, znalostní báze). Takeaway: udělejte si A/B testy „model tiering“ (nano/mini vs. flagship) a metriku time‑to‑first‑token / time‑to‑first‑audio, protože teprve z nich poznáte, kde dává smysl platit za „inteligenci“.
https://developers.openai.com/api/docs/changelog
Microsoft .NET blog: RT.Assistant – realtime multi‑agent voice bot přes WebRTC (telco use‑case)
Na .NET blogu vyšel detailní „production‑style“ příklad voice bota RT.Assistant od autora z telco prostředí, který kombinuje OpenAI Realtime API přes WebRTC, multi‑agent architekturu (Voice/Query/CodeGen/App agent) a deterministický „Flow“ state machine, aby držel na uzdě nedeterminismus LLM. Důležité je, že článek neřeší jen „demíčko“, ale konkrétní provozní vlastnosti: WebRTC (OPUS) jako kanál s nižší latencí a lepší odolností vůči krátkým výpadkům než WebSocket; oddělený audio/data kanál; a typově bezpečné zpracování eventů. V telcu je to přesně to, co často chybí: většina botů má hezké NLU, ale rozpadá se na síti, v integracích nebo v řízení dialogu – tady je návrh postavený tak, aby byl predikovatelný (state machine) a škálovatelný (agent bus). Zajímavý je i „RAG bez vektorů“: převod dotazu do Prologu a exekuce nad logickou bází faktů, což snižuje halucinace u domén typu tarifů, balíčků a podmínek (typický telco pain). Takeaway: pokud chcete spolehlivý voicebot, zkuste v kritických doménách nahradit volné generování odpovědí deterministickým dotazováním nad „source of truth“ (pravidla, graf, Prolog/SQL) a LLM použijte hlavně jako překladač z přirozeného jazyka na dotaz + jako NLG.
arXiv (v2 z 17. 3. 2026): praktický tutorial k enterprise realtime voice agentům + měření latence
Na arXiv vyšla aktualizovaná verze technického tutorialu, který krok‑za‑krokem staví enterprise realtime voice agent a hlavně tvrdě měří latence a popisuje, co dnes (2026) reálně funguje pro self‑host. Autoři testují kandidáta na „end‑to‑end speech‑to‑speech“ (Qwen3‑Omni) a dochází k tomu, že pro plně self‑hostované nasazení zatím není praktický: cloud realtime je rychlý, ale ne self‑host; lokální varianty mají buď jen část pipeline, nebo jsou řádově pomalé. Proto doporučují „cascaded streaming“ architekturu (STT → LLM → TTS) a ukazují referenční implementaci s funkčním callingem a změřeným time‑to‑first‑audio kolem ~755 ms. Pro telco voiceboty je to velmi užitečné, protože dává konkrétní rozpočet: pokud jste nad ~1 s do prvního zvuku, už to uživatel v hovoru vnímá jako „zasekávání“, a musíte řešit optimalizace (streaming všude, kratší odpovědi, pre‑warm, rychlejší TTS, menší model). Takeaway: začněte návrh voicebota od měřitelných SLA (TTFA, WER, jitter, dropout) a až potom vybírejte modely – jinak snadno skončíte s „chytrým“ botem, který je pro telefonní kanál nepoužitelný.
https://arxiv.org/abs/2603.05413
LocalAI: kompatibilní implementace OpenAI Realtime API (WebSocket/WebRTC) pro self‑host
LocalAI přidalo/zdokumentovalo podporu OpenAI Realtime API jako rozhraní, které si můžete nasadit on‑prem a poskládat z vlastních komponent (VAD, STT, LLM, TTS). Text je praktický: ukazuje „pipeline model“ konfiguraci a hlavně dva transporty – WebSocket a WebRTC – a u WebRTC upozorňuje na potřebu Opus backendu, bez kterého RTP audio neprojde. Pro telco to znamená dvě věci: (1) můžete oddělit protokol/klienta (Realtime API) od konkrétních modelů a dodavatelů a (2) můžete si postavit hybrid, kde citlivá data a audio běží lokálně, ale některé schopnosti (např. specializované TTS) případně zůstávají v cloudu. Provozní dopad je i v debugovatelnosti: když máte pipeline rozdělenou, umíte separátně měřit a ladit VAD/STT/LLM/TTS a rychle najít bottleneck. Takeaway: pokud řešíte compliance nebo náklady, vyplatí se standardizovat na jedno realtime rozhraní (např. „OpenAI Realtime protokol“) a měnit pod tím jen komponenty – zkracuje to migrace i incident response.
https://localai.io/features/openai-realtime/
AWS: Amazon Connect Health a „evidence mapping“ (auditovatelné shrnutí hovoru)
AWS představilo Amazon Connect Health jako „agentic AI“ řešení pro call‑heavy prostředí se silnou regulací, kde je potřeba ověřování, scheduling, shrnutí, zápisy a kódování – a klíčový prvek je tzv. evidence mapping: každé AI‑generované tvrzení má být dohledatelně navázané na konkrétní část transkriptu nebo záznamu. I když je to primárně healthcare, pro telco voiceboty je to přenositelné: reklamace, souhlasy, změny tarifů, výpovědi a citlivé operace potřebují auditní stopu „kdo/ kdy/ co řekl“ a rychlou možnost zpětné verifikace. Provozní dopad: bez evidence mappingu se vám LLM shrnutí může stát právním rizikem; s evidence mappingem můžete zavést kontrolní workflow (agent review) a omezit halucinace na „přesně tam, kde to bolí“. Praktický takeaway: u všech kritických kroků bota (souhlasy, závazné změny) logujte zdrojové věty + časové značky a v UI operátorům/QA zobrazujte „citace“ z hovoru, ne jen generované shrnutí.
https://www.aboutamazon.com/news/aws/amazon-connect-health-ai-healthcare
3 takeaways pro telco/voice provoz:
- Optimalizujte na latenci a cenu: tierujte modely (nano/mini pro rutinu, větší jen pro eskalace) a měřte TTFA (time‑to‑first‑audio).
- Stavte deterministické „kostry“ dialogu (state machine, pravidla, dotazy nad source‑of‑truth) a LLM používejte jako překladač + NLG, ne jako jediný mozek.
- Zaveďte auditovatelnost: evidence‑linked shrnutí, citace z transkriptu a jasné logy pro incidenty i compliance.