Hangminőség — 280ms medián latencia
Egy AI hangügynök sikere vagy bukása a latencián múlik. Ha a beszélgetés "laggos" — vagyis az ügynök kétharmad másodperccel azután válaszol, hogy az ügyfél befejezte a mondatát — a beszélgetés természetellenes, és az ügyfél leteszi. Az iparági benchmark a természetes válaszidőre 200-400 milliszekundum. Mi 280ms medián end-to-end latenciára optimalizáltunk, és ezt fél év éles forgalom után tartjuk.
A pipeline, ahol a millimásodpercek vesznek el
Egy beszélgetési forduló öt szakaszon halad át:
- SIP ingress (Telnyx) — az ügyfél hangja a Telnyx SIP trunkon keresztül érkezik. Telnyx EU-régió átlag: 18ms.
- STT — OpenAI Realtime (vagy fallback ElevenLabs / Web Speech) — a hang szöveggé alakul. Streaming módban folyamatosan, nem batch. Részleges hipotézis 80-120ms után.
- LLM — OpenAI Realtime (vagy fallback) — a szöveg alapján válasz generálódik. Streaming token-szintű. Első token 90-140ms.
- TTS — a válasz hanggá alakul. Pre-warmed cache-elt voice profile. 60-100ms az első chunk.
- SIP egress (Telnyx) — a hang visszatér az ügyfélhez. 18ms.
Összesítve a medián: 280ms. A 95. percentilis 410ms. A 99. percentilis 680ms (ezeket aktívan vadásszuk).
A legtöbb idő nem a hálózaton, hanem az LLM első tokenjéig tart. Ennek megnyirbálása volt a legnagyobb optimalizálási feladat.
A három fő optimalizálási nyereség
1. Streaming STT, nem batch. Az első iterációban a STT a teljes mondatra várt a transzkripció előtt. Ez ~600ms-ot adott a pipeline-hez. Áttértünk streaming módra, ahol az STT részleges hipotéziseket küld 80ms-onként. Az LLM már a részleges szöveget megkapja, és előre megkezdi a választervezést. Nyereség: ~400ms.
2. Half-duplex barge-in. Ha az ügyfél elkezd beszélni az ügynök közben, az ügynök azonnal elhallgat, és figyel. Az első iterációban a barge-in 800ms-os késéssel működött (a TTS buffer drainelése miatt). Áttértünk azonnali abort + chunk-discard logikára. Nyereség: 600ms gyorsabb reakcióidő.
3. Pre-warmed TTS cache. A leggyakoribb 30 frázis ("egy pillanat", "köszönöm a türelmét", "értem") előre szintetizált hangként tárolva. Ezekre 0ms TTS-latencia. Nyereség: ~80ms a hívások 60%-án.
Az empty response.done bug — a 30 másodperces hang
Fél éves futás közben volt egy ronda éles incidens, amit megosztunk, mert hasznos lehet másnak.
Két hét alatt elszórt panaszok jöttek: "néha 30 másodpercig nem szólal meg az ügynök". Reprodukálni nem tudtuk. A log-okban semmi rendkívüli — sem hibakód, sem timeout. Az OpenAI Realtime API simán visszaadta a response.done eseményt — csak benne nem volt egyetlen text vagy audio chunk sem.
A fix: detektálni az üres response.done-t, és azonnal újraindítani a generálást fallback prompttal ("egy pillanat, megnézem"). Az újraindítás 1-1.5 másodpercet vesz igénybe — a 30 másodperces hang helyett. A bug az OpenAI oldalán létezik, de a workaround mindig a mi oldalunk.
A fix után az átlagos "silent gap" incidens megszűnt. A monitoring alarmot is élesítettük: ha 5 másodpercnél hosszabb a gap két forduló között, automatikus log + alert.
A 99. percentilis vadászata
A medián szép szám, de a felhasználói tapasztalat a worst-case-en múlik. Ha a hívásaid 1%-a 2 másodperces késéssel csörgedezik, az 1000 hívásból 10 elégedetlen ügyfél. Az alábbi három forrás okozza a 99. percentilis spike-okat:
- Garbage collection a STT workerben — Java GC pause, megoldva G1GC tuninggal
- Cold start TTS voice profile — ritkán használt voice-ok cache-en kívül, fix: nightly pre-warm
- OpenAI rate-limit közeli throttling — burst-traffic esetén, fix: load-balancer egyik kulcsról másikra rugalmasan vált
A három fix után a 99. percentilis 1100ms-ról 680ms-ra esett.
Provider failover
A Nortinia mindenkor három voice providert tart kéznél: elsődleges OpenAI Realtime, secondary ElevenLabs, tertiary Web Speech (browser-side). Ha az OpenAI 3 másodpercig nem válaszol, automatikusan ElevenLabs-re vált — még futó hívás közben is, az ügyfél nem veszi észre. A kapcsoló circuit-breaker logikán alapul (5 hiba 60 másodperc alatt → blackout 5 percre).
Fél év alatt 14 alkalommal kapcsoltunk át fallback providerre. Egyszer sem volt teljes szolgáltatáskiesés.
Amit a hangminőség nem old meg
A latencia és a hangminőség önmagában nem teszi jobbá az ügynököt, ha a tartalom rossz. Egy gyors válasz, ami félreérti az ügyfelet, rosszabb, mint egy lassú válasz, ami pontos. A latencia-optimalizálás eljutott a természetes szintre; innentől a prompt-engineering és az intent-klasszifikáció finomhangolása hozza a CSAT-javulást.