Event-driven architektura: proč Request-Response ve hlasovém AI nestačí
Většina vývojářů kteří poprvé staví Voice AI systém přistoupí k problému jako k Request-Response architektuře: zákazník promluví → server zpracuje → odpoví. Tento model funguje na webu. Ve hlasovém AI selže.
Proč? Protože přirozená konverzace není série HTTP požadavků. Je to kontinuální, obousměrný proud signálů kde oba účastníci naslouchají i mluví zároveň — a kde zpoždění větší než 700 milisekund zákazník okamžitě identifikuje jako anomálii.
Správně postavený Voice AI systém je event-driven systém který zpracovává čtyři typy událostí souběžně: audio events (příchozí zvuk v chunkcích 20–50 ms), speech events (detekce začátku a konce řeči), transcription events (průběžné přepisy slov v reálném čase) a state events (přechody mezi stavy listening → processing → speaking). Každý proud událostí běží na jiném vlákně s jinou prioritní frontou.
Moderní produkční systémy implementují tzv. pipeline parallelism: ASR stream zpracovává audio, LLM dostává přepis průběžně — ne celou větu najednou — a TTS začne syntetizovat první větu odpovědi ještě dříve než LLM vygeneroval druhou. Tato architektura není optionální optimalizace. Je to předpoklad pro funkční produkt.
ASR vrstva: co se opravdu děje při přepisu řeči v reálném čase
ASR vrstva má jeden úkol: převést zvukový signál na text. Způsob jakým to dělá v reálném čase je výrazně složitější než dávkový přepis. Moderní realtime ASR systémy pracují na principu streaming decoding s CTC (Connectionist Temporal Classification) nebo attention-based architekturou. Základní výzva ASR není přepis jednoho slova, ale kontinuální segmentace akustického signálu do fonémů bez explicitního vyznačení hranic — a to v přítomnosti šumu, přízvuku a telefonní komprese. (Jurafsky & Martin, Speech and Language Processing, 3. vydání, kap. 16)
Klíčová funkce produkčních ASR systémů jsou word-level confidence scores: každé slovo v přepisu dostane pravděpodobnostní skóre 0.0–1.0. Systém může na základě těchto skóre detekovat nejistá slova a požádat o potvrzení, nebo použít confidence jako vstup pro endpointovací rozhodnutí. Pokud poslední tři slova partial transkriptu mají confidence pod 0.7, systém čeká — protože pravděpodobně přichází oprava nebo pokračování věty.
V produkčním realtime systému ASR nevydává výstup po větách ale po tokenech nebo slovech jako partial transcript. LLM tak může začít zpracovávat zákazníkovu větu ještě dříve než ji zákazník dokončí. Při typické české větě LLM zpracovává první 3 slova zatímco zákazník ještě říká poslední 2 — a to je základ nízké vnímané latency.
LLM vrstva: tři věci které se liší od chatbotu
LLM vrstva v kontextu Voice AI funguje fundamentálně jinak než v chatbotu. Za prvé, délka odpovědi je nepřítel latence. Každý dodatečný token v odpovědi LLM přidává desítky milisekund do TTS pipeline. Dobře nakonfigurovaný Voice AI prompt explicitně limituje délku odpovědí — ne přes max_tokens parametr (ten ořízne odpověď uprostřed), ale přes system prompt instrukce: Odpovídej vždy jednou nebo dvěma větami. Nikdy neuvádíš více než jednu informaci najednou.
Za druhé, konverzační kontext roste s každou výměnou. Při 20minutovém hovoru může kontext dosáhnout 8 000–15 000 tokenů. To zvyšuje LLM latenci kvadraticky — attention mechanismus v transformerech má O(n²) složitost vůči délce kontextu. Produkční systémy proto implementují rolling context window nebo hierarchickou sumarizaci starších částí hovoru.
Za třetí a nejdůležitější — system prompt je dynamický, ne statický. Generuje se per-call na základě dat z CRM, předchozí historie zákazníka a aktuálního kontextu. Zákazník který volá popáté dostane jiný systémový kontext než zákazník který volá poprvé. Právě toto odlišuje produkční Voice AI od demo asistenta.
Endpointing: nejtěžší nerealizovaný problém v hlasovém AI
Endpointing — detekce okamžiku kdy zákazník přestal mluvit — je technicky nejtěžší problém v celé Voice AI pipeline. Přirozená řeč obsahuje ticho: mluvčí dělají pauzy uprostřed věty protože hledají slovo, nadechují se, formulují myšlenku nebo čekají na potvrzení. Systém musí rozlišit mezi pause-within-turn (mluvčí ještě nemluví) a end-of-turn (mluvčí skončil). Tato hranice neexistuje v akustickém signálu — musí se inferovat.
Moderní endpointing kombinuje tři techniky. VAD (Voice Activity Detection) detekuje přítomnost lidské řeči na úrovni 10–20 ms framů. Prosodický model analyzuje intonaci, tempo a energii řeči — klesající intonace na konci věty je silný signál ukončení výpovědi, a tento model je kulturně specifický: český mluvčí má jiné prozodické vzory než anglický. Sémantický endpointing pak použije lehký klasifikační model který analyzuje obsah partial transkriptu a odhaduje, zda věta sémanticky dává smysl jako kompletní výpověď.
Špatně nakalibrovaný endpointing má přímý obchodní dopad: příliš agresivní systém skáče zákazníkovi do řeči, příliš opatrný přidává 300–800 ms ke každé odpovědi. Vždy testujte endpointing v reálných podmínkách — z mobilního telefonu, z prostředí s hlukem, s různými mluvčími.
Pre-call webhook v n8n: AI ví kdo volá ještě před prvním pozdravem
Toto je funkce která odděluje demo produkt od produkčního systému. Když zákazník vytočí číslo, telefonní vrstva Voice AI systému zachytí příchozí hovor a ještě před přijetím odešle HTTP POST webhook na n8n s dostupnými metadaty: call_id, caller_number, called_number a timestamp. n8n workflow zpracuje tento webhook synchronně — musí odpovědět typicky do 2–5 sekund než zákazník uslyší první slovo.
n8n workflow provede CRM lookup podle telefonního čísla. Výsledek rozhoduje o fundamentálně odlišném chování AI asistenta: pokud zákazník existuje, načte se jeho jméno, historie hovorů, otevřené objednávky a preference a sestaví se personalizovaný system prompt. Pokud zákazník neexistuje, aktivuje se flow pro sběr základních údajů. n8n pak vrátí do Voice AI platformy JSON s konfigurací hovoru včetně dynamického system promptu a personalizovaného first_message.
Dopad na konverzi je dramatický. Zákazník který volá Autoservisu uslyší Dobrý den, pane Kováři místo Dobrý den, jak vám mohu pomoci. Výzkum v oblasti zákaznické zkušenosti konzistentně ukazuje, že personalizace v prvních 5 sekundách interakce zvyšuje úspěšnost hovoru o 15–35 %. (Peppers & Rogers, Managing Customer Experience and Relationships, 3. vydání) Celková latence pre-call webhooku musí být pod 3 000 ms — jinak se musí aktivovat fallback se generickým system promptem.
ASR: Scribe v2.2 Realtime — proč ne Deepgram nebo Whisper
Scribe v2.2 Realtime je streaming ASR model optimalizovaný pro produkční realtime aplikace. Klíčovou vlastností jsou word-level timestamps s jistotou: každé slovo dostane přesný timestamp a confidence skóre, což umožňuje endpointovacímu systému dělat rozhodnutí na základě statistické jistoty místo jen délky ticha.
Scribe v2.2 je explicitně trénován na narrowband telefonním audu (8 kHz), zatímco telefonní linky typicky přenášejí audio právě v této frekvenci oproti standardnímu broadband audu (44.1 kHz). To snižuje Word Error Rate v reálném telefonním provozu o 15–25 % oproti modelům trénovaným na broadband audu. Streaming partial transcripts pak umožňují LLM zpracovávat zákazníkovu větu průběžně.
Deepgram Nova-3 je excelentní pro angličtinu ale jeho výkon pro češtinu zaostává. OpenAI Whisper large-v3 má nižší WER pro češtinu ale není nativně optimalizovaný pro streaming — jde původně o batch model — a jeho latence pro partial transcripts je vyšší. Scribe v2.2 v kombinaci s česky jazykovou optimalizací nabízí lepší poměr WER/latence pro český produkční provoz.
LLM: Gemini 2.5 Flash — a proč je thinking mode nepřítel latency
Gemini 2.5 Flash splňuje klíčová kritéria pro Voice AI neobvykle dobře pro svoji cenovou kategorii. TTFT se pohybuje kolem 200–450 ms pro typické voice AI prompty s kontextem do 4 000 tokenů. Output rychlost přesahuje 150 tokenů za sekundu, což při průměrné odpovědi 30–50 tokenů znamená generaci do 300 ms. Celková latence od vstupu textu po první token TTS vstupu je tak realisticky 400–700 ms.
Kritický detail: Gemini 2.5 Flash defaultně aktivuje thinking funkci, která před generací odpovědi provede chain-of-thought reasoning. Pro složité úlohy jako kódování nebo matematiku je to přínos. Pro Voice AI je to latence killer — thinking přidává 500–2 000 ms ke každé odpovědi. V produkčním Voice AI nastavení se thinking explicitně vypíná přes parametr thinking_budget nastaven na hodnotu 0.
Instrukce-following — schopnost dodržovat systémová pravidla jako odpovídej vždy jednou větou nebo nikdy nezmiňuj cenu bez potvrzení dostupnosti — je u Gemini 2.5 Flash výrazně lepší než u srovnatelně rychlých modelů. Kontextové okno 1M tokenů pak prakticky eliminuje potřebu rolling window pro hovory běžné délky — i 60minutový hovor se nepřiblíží limitu a to zjednodušuje implementaci a odstraňuje celou třídu chyb.
TTS: ElevenLabs Flash streaming — sémantická fragmentace a interrupt handling
ElevenLabs Flash model je optimalizovaný pro realtime streaming s TTFA (Time To First Audio Chunk) kolem 75–120 ms, což je o 30–40 % rychlejší než standardní Multilingual v2 model. ElevenLabs TTS přijímá text přes WebSocket a vrací audio chunky v binárním formátu ihned po jejich syntéze.
Klíčová technika pro nízkou vnímanou latenci je sémantická fragmentace: systém nepošle celou odpověď LLM najednou, ale detekuje hranice vět a sémanticky uzavřených frází (tečka, vykřičník, otazník, čárka s dostatečnou délkou předchozí fráze) a okamžitě spustí syntézu. Zákazník slyší první větu odpovědi zatímco LLM ještě generuje druhou. Výsledná vnímaná latence (TTFW) je kombinací: endpointing latence + první tokeny LLM + TTFA prvního TTS chunku — v optimalizovaném systému 400 až 700 ms.
Interrupt handling — schopnost AI přestat mluvit ve chvíli kdy zákazník promluví uprostřed jeho promluvy — je vrstva nad VAD která nepřetržitě monitoruje příchozí audio i ve chvíli kdy AI mluví. Jakmile je interrupt potvrzen, systém musí v kaskádě do 100–200 ms: zastavit TTS playback, zrušit bufferedované TTS chunky, přejít do listening stavu a zpracovat zákazníkovu výpověď. ElevenLabs workflow engine umožňuje propojit TTS s post-processing kroky včetně normalizace hlasitosti a komprese pro telefonní přenos.
Post-call webhook v n8n: proč 60 % hodnoty vzniká až po zavěšení
Post-call webhook je moment který odděluje Voice AI jako telefonní záznamník od Voice AI jako obchodní systém. Okamžitě po ukončení hovoru Voice AI platforma odešle n8n webhook s plnými daty: celý transkript s timestampy, URL nahrávky, výsledek hovoru, extrahovaná data a metadata zákazníka. n8n workflow zpracuje tato data asynchronně — zákazník již zavěsil, časový tlak odpadl.
n8n post-call workflow provede v pořadí: strukturovanou extrakci dat z transkriptu přes LLM analýzu (potvrzená rezervace, zákazníkovy preference, otevřené dotazy, sentiment), aktualizaci záznamu v CRM s výsledkem hovoru a novými preferencemi, zápis události do Google Kalendáře pokud hovor skončil rezervací, odeslání SMS nebo emailu zákazníkovi s potvrzením a linkem na změnu termínu, interní notifikaci zodpovědnému členovi týmu přes Slack nebo email pokud hovor skončil eskalací, a nakonec analytiku do dashboardu.
Firma která systematicky zpracovává post-call data obvykle zjistí v prvním měsíci: zákazníci nejčastěji volají v časech X, nejčastěji se ptají na Y, AI nejčastěji selhává při Z. Každé z těchto zjištění je vstup pro optimalizaci system promptu a znalostní báze. Bez post-call webhooku je Voice AI systém uzavřená smyčka — hovor proběhne, výsledek zmizí.
Architektonický diagram: celý tok dat od příchozího hovoru po CRM zápis
Zákazník vytočí číslo → telefonní vrstva (SIP/PSTN) přijme hovor a převede audio na PCM 16kHz → odešle se synchronní pre-call webhook do n8n (max 3 s) → n8n provede CRM lookup, sestaví dynamický system prompt a personalizovaný první pozdrav → odpověď se vrátí do Voice AI platformy.
Hovor probíhá ve smyčce: příchozí audio jde do Scribe v2.2 Realtime (streaming partial transcripts s word-level confidence) → partial transcript jde průběžně do Gemini 2.5 Flash (thinking_budget: 0, instrukce-following, konverzační kontext) → token stream jde přes sémantickou fragmentaci do ElevenLabs Flash (WebSocket streaming, TTFA 75–120 ms) → audio chunky jdou zpět do telefonu zákazníka. Paralelně běží interrupt detection vlákno.
Po zavěšení odejde asynchronní post-call webhook do n8n → LLM extrakce strukturovaných dat z transkriptu → CRM aktualizace → Google Calendar zápis → SMS/email zákazníkovi → Slack/email notifikace týmu → analytika. N8n tak funguje jako čistá orchestrační vrstva která odděluje Voice AI konverzační logiku od business procesů — výměna jedné komponenty neovlivní druhou.
Limity stacku a co se mění při škálování
Scribe v2.2 + Gemini 2.5 Flash + ElevenLabs tvoří stack optimalizovaný pro nízkou end-to-end latenci, dobrou kvalitu češtiny napříč všemi třemi vrstvami a flexibilní integraci přes standardní API. n8n jako orchestrační vrstva je strategicky správná volba pro firmu bez dedikovaného backend týmu — nabízí vizuální workflow editor, nativní integraci se stovkami služeb a deployment který nevyžaduje DevOps specializaci.
Při škálování nad 500 hovorů měsíčně narážíte na první limit: konkurenční hovory na sdílené infrastruktuře mohou zdražovat latenci ve špičce. Řešením je vyhrazená kapacita — ale za výrazně vyšší cenu. Druhý limit je n8n SLA při pre-call webhooku: pokud n8n cloud má výpadek, zákazník dostane generický neosobní hovor. Pro produkci je vhodné implementovat fallback — lokální cache naposledy přístupných zákazníků v paměti Voice AI platformy.
Největší budoucí optimalizace: přímý audio vstup do Gemini eliminuje ASR jako samostatnou vrstvu. Gemini 2.5 Flash nativně rozumí audu, takže při migraci na přímý audio vstup ušetříte 200–400 ms ASR latence a navíc získáte přístup k paralingvistickým signálům — tón, rychlost řeči, váhání — které ASR text nezachycuje. n8n orchestrace a post-call logika při této migraci zůstanou nedotčeny.
Zdroje a doporučená literatura
Akademická literatura: Jurafsky, D. & Martin, J.H. (2024). Speech and Language Processing, 3. vydání. Stanford University Press — zejména kapitoly 16 (ASR architektura) a 26 (Dialogue systems). Volně dostupné na web.stanford.edu. Goodfellow, I., Bengio, Y. & Courville, A. (2016). Deep Learning. MIT Press — kapitola 10 (Sequence Modeling) pro pochopení attention mechanismů v TTS. Rabiner, L. & Juang, B.H. (1993). Fundamentals of Speech Recognition. Prentice Hall — klasický základ pro pochopení endpointingu a VAD.
Business a zákaznická zkušenost: Peppers, D. & Rogers, M. (2016). Managing Customer Experience and Relationships, 3. vydání. Wiley — data o dopadu personalizace na konverzní míry v prvních sekundách interakce.
Výzkumné papers: Radford, A. et al. (2022). Robust Speech Recognition via Large-Scale Weak Supervision (Whisper paper). OpenAI. arXiv:2212.04356 — pro pochopení moderní ASR architektury. Wang, C. et al. (2023). Neural Codec Language Models are Zero-Shot Text to Speech Synthesizers (VALL-E). Microsoft Research. arXiv:2301.02111 — základ pro pochopení moderní neural TTS architektury.