Voice agentek építése: realtime speech-to-speech vagy STT, LLM és TTS?

A voice az a felület, ahol egy MI-ügynököt két másodperc alatt megítélnek. Egy csevegőablakban a lassú válasz kellemetlen; telefonon az egy másodperces szünet megszakadt vonalnak hat, és a hívók beszélni kezdenek az ügynök fölött, vagy leteszik. Ezért az architekturális kérdések másként festenek, mint egy szöveges ügynöknél: időkeretet költesz, nem tokenkeretet.

Az első döntés két forma között van. A speech-to-speech modell, például az OpenAI Realtime API vagy a Gemini Live API, hangot fogyaszt és hangot állít elő egyetlen modellen belül. A kaszkádolt pipeline speech-to-textet, szöveges LLM-et és text-to-speechet láncol, a darabokat pedig olyan orkesztrációs keretrendszerek kötik össze, mint a Pipecat és a LiveKit Agents. Mindkettő működik élesben, és a választást aszerint hozom meg, hol van szükségem kontrollra.

Ez a cikk a gyártók dokumentációjának számaival megy végig a döntésen: a késleltetési keret fázisonként, turn-taking és barge-in, tool hívások beszéd közben, telefónia, német és magyar minőség, és mit kér tőled az EU AI Act. A végén az a checklist áll, amelyből kiindulnék. Az árak és modellnevek ezen a területen pár havonta változnak, ezért a részleteket a 2026. október 2-i pillanatképnek tekintsd.

Speech-to-speech vagy kaszkádolt pipeline?

Az OpenAI saját voice agent útmutatója tisztán fogalmazza meg a választást. A Realtime API a „beszéd, következtetés és tool-használat egy munkamenetben” esetére való: egy modell értelmezi a hangot, eldönti, mit tegyen, és beszéddel válaszol. A láncolt út akkor kell, ha „kontrollra van szükséged minden beszéd- és szövegfázis felett”: eltárolod az átiratot, szabályellenőrzést futtatsz, mielőtt a szöveges ügynök válaszol, és minden komponenst külön cserélsz. Az útmutató egyik útra sem közöl késleltetési számot, csak azt javasolja, hogy hasonló hívásoknál a mediánt és a 95. percentilist hasonlítsd.

Ez egybevág azzal, amit a projektekben látok. A speech-to-speech akkor nyer, ha maga a beszélgetés a termék, és a logika könnyű. A kaszkádolt pipeline akkor, ha a választ kimondás előtt ellenőrizni, naplózni vagy megalapozni kell, ami a legtöbb B2B esetben így van: rendelésállapot, időpont-módosítás, support-triázs tudásbázissal. Így hasonlít össze a kettő:

A dokumentációból két részlet érdemes megjegyezni. A gpt-realtime modell oldala 32 000 tokenes kontextusablakot és legfeljebb 4096 kimeneti tokent említ, és támogatja a WebRTC-t, a WebSocketet és a SIP-et. A Google Live API állapottartó WebSocket-kapcsolat, és az útmutatója a csak hangos munkameneteket 15 percre, a hang és videó munkameneteket 2 percre korlátozza, hacsak nem használsz munkamenet-kezelési technikákat. Mindkettő munkamenet-alapú, nem kérés-alapú, ami megváltoztatja, hogyan kezeled az újracsatlakozást és a hosszú hívásokat.

A késleltetési keret fázisonként

A kaszkádolt kör váltófutás, és a hívó csak az összidőt hallja. Egy gyakorlati playbook minden szakaszra számot ad, a legjobb esettől addig, amit a telepítések jellemzően mutatnak. Tervezési értéknek tekintem, nem garanciának, de a minta egyezik az általam olvasott források között:

Három következtetés adódik. Először: az LLM a keret. Az első tokenje legjobb esetben 400 ms, jellemzően 600–1200 ms, ezért a modellválasztás, a prompt mérete és a cache többet számít bármilyen audio-finomhangolásnál. A támpontokat az LLM költség és késleltetés: prompt caching és routing cikkben írtam le. Az egyszerű köröket küldd kicsi, gyors modellre, az erőset tartsd a nehezekre.

Másodszor: korán indíts és mindent streamelj. A Deepgram Flux speech-to-text modellje maga ismeri fel a kör végét, kb. 260 ms alatt, és EagerEndOfTurn eseményt küld, amellyel elindíthatod az LLM-et, mielőtt a felhasználó biztosan befejezte, így több száz milliszekundumot nyersz. Az ár a felesleges hívások, ha a felhasználó folytatja, ezért egy spekulatív generálást tisztán meg kell tudnod szakítani. A streaming TTS-re ugyanez igaz: az első mondatnál kezdj beszélni, ne az utolsónál.

Harmadszor: a telefonhálózat extra költség. Ugyanez a playbook 80–150 ms-ot számol a nyilvános telefonhálózatra a WebRTC-n felül. És úgy mérj, ahogy az OpenAI javasolja: a hívó által egy használható kimondott válaszra várt idő mediánja és 95. percentilise, valódi hívásokon, mert a farokra emlékeznek az emberek.

Turn-taking és barge-in

A voice agent legnehezebb része nem a beszéd, hanem tudni, mikor kell beszélni. Az egyszerű hangaktivitás-felismerés (VAD) rögzített csend után zár le egy kört. Ez kétszeresen hibás: belevág az emberek szavába, amikor gondolkodva szünetet tartanak, és túl sokat vár, amikor végeztek. Az OpenAI turn detection útmutatója mindkét módot leírja. A Server VAD „csendszakaszokat használ a hang automatikus darabolásához”, küszöbbel, csendidővel és prefix paddinggel állítható. A Semantic VAD „szemantikus osztályozót használ, hogy a kimondott szavak alapján felismerje, mikor végzett a felhasználó”, és egy eagerness beállítás alacsonytól magasig szabályozza, milyen gyorsan válaszol.

A kaszkádolt keretrendszereknek saját válaszaik vannak. A LiveKit audio turn detectora „szemantikus megértést kombinál akusztikai jelekkel, mint az intonáció, a hangmagasság és a ritmus”, és bekapcsolva az alapértelmezett endpointing-ablakot 0,3–2,5 másodpercre tolja. A Pipecat nyílt forráskódú Smart Turn modellje (3.2-es verzió, BSD 2-clause) a teljes felhasználói kört elemzi, ha egy könnyű VAD, például a Silero csendet jelez, „egyes CPU-kon akár 10 ms”, a legtöbb felhőpéldányon 100 ms alatti inferenciával. A Google Live API kezdő és záró érzékenységet és csendidőt kínál, és figyelmeztet, hogy a nagyon alacsony, 100–200 ms-os csendértékek töredékekre szabdalják a megszólalásokat.

A barge-in a másik fele. Amikor a hívó rábeszél az ügynökre, három dolognak kell gyorsan megtörténnie: leállítani a lejátszott hangot (a playbook kb. 150 ms alatt kéri), kiüríteni a kliensen a pufferelt hangdarabokat, és megmondani a modellnek, mit hallott valójában a hívó. Az OpenAI Realtime API-ban a kliens conversation.item.truncate eseményt küld a hangpozícióval, így a le nem játszott rész kikerül a beszélgetésből. A Gemini Live API-ban a szerver jelzi a megszakítást, és az alkalmazásnak le kell állítania a lejátszást és ki kell ürítenie a hangsort. Ha ezt kihagyod, a modell azt hiszi, hogy olyat mondott, amit a hívó sosem hallott, és a következő válasz erre hivatkozik.

Két hibamódot érdemes külön tesztelni. Téves barge-in: vonalzaj, köhögés vagy a hívó saját visszhangja kihangosításon megszakítja az ügynököt mondat közben. Emeld a VAD küszöbét, használj visszhangszűrést, és követelj meg minimális beszédet a megszakításhoz. Backchannelek: ha a hívó azt mondja „aha”, az nem új kör. Nem engedném, hogy ezek elvágják az ügynököt.

Tool hívások, amíg az ügynök beszél

Az a voice agent, amely csak beszélni tud, játék. Az érték a toolokban van: rendelés lekérése, időpont áthelyezése, ticket létrehozása. Ez az agent loop magyarázata cikkben szereplő ciklus, csak stopperórával. Minden tool hívás rés a beszélgetésben, és egy csendes rés a telefonvonalon hibának tűnik.

A mechanika platformonként eltér. Az OpenAI Realtime API-ban a modell function_call elemet bocsát ki a response.done eseményben; a kódod lefuttatja a függvényt, egy function_call_output elemet ad vissza a call_id-val, és új választ indít. A Google útmutatója a párhuzamosságról explicitebb: a Gemini 3.8 Live alapértelmezésben támogatja az aszinkron (NON_BLOCKING) függvényvégrehajtást, ütemezési opciókkal (SILENT, WHEN_IDLE, INTERRUPTED), amelyek eldöntik, hogy az eredmény azonnal vagy csak a modell tétlenségekor hangzik-e el, míg a 3.1 Flash modell a hívásokat egymás után futtatja, és megvárja a választ. Kaszkádolt pipeline-ban mindezt te vezérled, ami több munka és több rugalmasság.

Amit a gyakorlatban csinálok:

• Beszélj, mielőtt lekérdezel. Indíts el egy rövid töltelékmondatot („egy pillanat, megnézem”), amint a várható várakozás egy másodperc fölé megy. Az előre rögzített hang semmibe sem kerül.
• Tartsd a toolokat gyorsan és kicsin. Adj az ügynöknek néhány szűk, időkorlátos toolt egy általános adatbázis-kliens helyett. Csak azokat a mezőket add vissza, amelyeket a modellnek hangosan ki kell mondania. Lásd a tanulságokat az MCP tool tervezés cikkben.
• Erősítsd meg, mielőtt bármit módosítasz. Olvasd vissza a dátumot, az összeget vagy a címet, és várj egy kimondott igenre írás előtt. Különben a felismerési hibákból valódi műveletek lesznek.
• Az átiratot kezeld megbízhatatlan bemenetként. Bárki mondhatja egy hívásban, hogy „hagyd figyelmen kívül az utasításaidat”. Ugyanezek az injekciós minták érvényesek, és a kimondott bemenetet még nehezebb szűrni.

Telefónia: SIP, WebRTC és a telefonhálózat

A böngészők és az appok WebRTC-t használnak. A telefonok SIP-et és a nyilvános telefonhálózatot, és a legtöbb B2B voice eset telefonhívás. A jó hír, hogy a platformok már a SIP-rétegnél találkoznak veled. Az OpenAI Realtime API-nál webhookot állítasz be a projektedben; amikor hívás érkezik, az OpenAI realtime.call.incoming eseményt küld a hívásazonosítóval és a SIP fejlécekkel, te pedig négy végponton át fogadod, elutasítod, átirányítod (refer) vagy leteszed. A szolgáltató oldalán TLS jelzés kell az 5061-es porton és SRTP média, a fogadás után pedig a hívásazonosítóval WebSocketet csatolsz, hogy az eseményeket streameld és a parancsokat elküldd, a megszokott módon.

Az ElevenLabs SIP trunk integrációt és natív Twilio-integrációt említ az agents platformjához. A LiveKit dokumentációja szerint az agentjei teljes telefónia-támogatással rendelkeznek, így a telefonáló úgy lép be egy szobába, mint bármely más résztvevő. A Pipecat ugyanazt a pipeline-t futtatja telefonos transzport mögött. Bármelyiket választod, számolj a gyakorlati költségekkel: a telefonhang keskeny sávú, a felismerés minősége romlik a stúdiómikrofonhoz képest, és a hálózat minden körhöz késleltetést ad, ahogy a fenti keret mutatja.

Két tervezési pont később sok fájdalmat spórol meg. Tarts fenn emberi átadási utat az első naptól: SIP átirányítás egy személyhez, ha az ügynök bizonytalan, a hívó kéri, vagy egy tool kétszer elbukik. És minden naplósorban tárold a hívásazonosítót, hogy egy hívásról szóló panaszból olyan trace legyen, amelyet fázisonkénti időkkel visszajátszhatsz.

Német és magyar: tesztelj végig az egész láncon

A nyelvi minőség egy lánc, és a leggyengébb szem határozza meg az élményt. A németet mindenhol jól lefedettnek találtam, ahol megnéztem. A magyarnál szakad a lánc, és nem ott, ahol várnád: a felismerés és a hang létezik, a turn-felismerés gyakran nem. Ezt mondja a dokumentáció:

A magyarnál ennek konkrét következménye van. Egy kaszkádolt stack használhatja a Nova-3-at a felismeréshez és a Flash v2.5-öt a hanghoz, de szemantikus turn-felismerő nélkül csendalapú endpointingra esik vissza, ami hosszabb szüneteket vagy több közbevágást jelent. A Gemini útmutatója hozzáteszi, hogy a natív audio modelljei automatikusan választanak nyelvet, és beszélgetés közben válthatnak, explicit nyelvbeállítás nélkül. Ez kényelmes kétnyelvű hívónál, és kockázatos, ha a magyart garantálnod kell.

A tanácsom: a szállítóválasztás előtt építs egy kis kiértékelő készletet nyelvenként: 30–50 valódi felvétel akcentussal, számokkal, nevekkel és utcacímekkel, kiértékelve a szóhibaarányra a számodra fontos mezőkben, és arra, mennyire természetes az endpointing. Az LLM funkciók kiértékelése cikk megközelítése átvihető. A gyártók nyelvlistái azt mondják meg, mi lehetséges; csak a saját felvételeid mondják meg, mi elég jó.

Hozzájárulás, tájékoztatás és az AI Act

Az emberekkel beszélő szintetikus hang beváltja az átláthatósági szabályokat. Az EU AI Act 50. cikkének (1) bekezdése előírja, hogy a szolgáltatók úgy tervezzék az emberekkel közvetlenül kapcsolatba lépő MI-rendszereket, hogy az érintettek „tájékoztatást kapjanak arról, hogy MI-rendszerrel lépnek kapcsolatba”, kivéve ha ez egy kellően tájékozott, figyelmes és körültekintő személy számára nyilvánvaló. A (2) bekezdés hozzáteszi, hogy a szintetikus hangot géppel olvasható és felismerhető módon jelölni kell, ahol ez technikailag megvalósítható. Egy ügyvédi iroda összefoglalója szerint ezek a kötelezettségek 2026. augusztus 2. óta érvényesek, és a Digital Omnibus nem halasztotta el őket, helyette a nagy kockázatú kötelezettségeket tolta ki. Csak az ezen időpont előtt forgalomba hozott rendszerek szolgáltatóinak van 2026. december 2-ig ideje a technikai jelölésre, a bírság pedig elérheti a 15 millió eurót vagy a világméretű árbevétel 3 százalékát.

A gyakorlatban négy dolgot tennék. Az elején közöld: minden hívás első mondata mondja ki, hogy ez egy MI-asszisztens, és a hang ne tegyen úgy, mintha nem az lenne. Kínálj embert: mondd meg a hívóknak, hogyan érhetnek el egy személyt. Tudatosan rögzíts: ha hangot vagy átiratot tárolsz, jogalap, megőrzési idő és világos tájékoztatás kell, és a hangfelvétel azonosíthat egy személyt, tehát személyes adat. Az LLM API-k GDPR-oldaláról írt jegyzeteim arról szólnak, hol dolgozható fel a hang. Légy óvatos a klónozott hangokkal: az 50. cikk (4) bekezdése kötelezi az üzemeltetőket a deepfake hang közlésére, ezért soha ne utánozd valós személy hangját a hozzájárulása nélkül.

Mit építenék először

Ha egy csapat azt kérné, hogy a jövő héten indítsak el egy voice agentet, ezt a sorrendet követném:

1. Válassz egy szűk, telefonos folyamatot egyértelmű sikerkritériumokkal, például időpont-módosítást vagy rendelésállapotot. Határozd meg a célt: medián kb. egy másodperc alatt az első kimondott szóig, és egy olyan 95. percentilis, amellyel együtt tudsz élni.
2. Kezdj kaszkádolt pipeline-nal Pipecaten vagy LiveKiten, hogy minden fázisnak legyen naplója, időmérése és cserélhető szolgáltatója. Futtass egy realtime modellt második változatként ugyanazokon a hívásokon.
3. Műszerezz minden kört az első naptól: körvég, végleges STT, LLM első token, TTS első bájt és lejátszás kezdete. Ábrázold a mediánt és a 95. percentilist fázisonként.
4. Válassz olyan szemantikus turn-felismerőt, amely támogatja a nyelveidet, és teszteld a téves barge-int zajos vonalakkal és kihangosítással. Ahol a nyelvedhez nincs detektor, hangold a csendküszöböket nyelvenként.
5. Építsd a toolokat szűkre és gyorsra, időkorláttal és kimondott töltelékmondatokkal, és adj visszaolvasásos megerősítést minden írás elé.
6. Add hozzá az MI-tájékoztatást az első mondatban, az emberi átadási utat és egy megőrzési szabályt a hangra és az átiratokra.
7. Építsd meg a nyelvenkénti kiértékelő készletet valódi felvételekből, és futtasd újra minden modell- vagy hangváltáskor.
8. Csak ezután optimalizálj költséget: kisebb modellek az egyszerű körökre, prompt caching és olcsóbb hangok, ahol a minőség megengedi.

A keretrendszer megválasztása kevésbé számít, mint a fegyelem a kerettel. A Pipecat nyílt forráskódú (BSD-2) Python keretrendszer, amely több mint 150 szolgáltatást hangol össze, a LiveKit Agents pedig Apache 2.0 alatt nyílt forráskódú, és az ügynököt résztvevőként teszi egy WebRTC-szobába. Mindkettővel szolgáltatót válthatsz a logikád átírása nélkül, és pontosan ezt akarod egy olyan területen, ahol a legjobb modell negyedévente változik.

A tágabb kép

A speech-to-speech modellek tovább zárkóznak fel a késleltetésben és a minőségben, a kaszkádolt pipeline pedig megtartja a helyét mindenhol, ahol a szöveget ellenőrizni kell. Arra számítok, hogy a legtöbb éles rendszer hibrid lesz: realtime modell a csevegésre és az egyszerű körökre, és szöveges út toolokkal és guardrailekkel mindenre, ami egy rendszer-nyilvántartást érint.

Az állandó a keret. Az a voice agent, amely egy másodperc alatt válaszol, tudja, mikor kell hallgatnia, megmondja, ki ő, és átad egy embernek, amikor kell, legyőz egy okosabbat, amely ezt nem teszi. Ha egyet tervezel, és szeretnél egy második szemet az architektúrán, pontosan ilyen munkát végzek AI engineerként.

Források

1. OpenAI: Voice agents guide
2. OpenAI: gpt-realtime model page
3. OpenAI: Voice activity detection in the Realtime API
4. OpenAI: Realtime API with SIP
5. OpenAI: Realtime conversations (function calling, interruption)
6. Google: Gemini Live API overview
7. Google: Gemini Live API capabilities guide
8. Deepgram: Flux quickstart
9. Deepgram: Models and languages overview
10. ElevenLabs: Agents platform overview
11. ElevenLabs: Text to speech models and languages
12. LiveKit: Agents overview
13. LiveKit: Turn detector
14. Pipecat: Introduction
15. Pipecat: Smart Turn model (GitHub)
16. Fora Soft: Voice AI agents on LiveKit, 2026 engineer playbook
17. EU AI Act: Article 50, transparency obligations
18. Jones Walker: Yes, August 2 still matters (AI Act delay and Article 50)