Vissza a bloghoz

ProCat Solutions

Elérhető az Abigel.ai: AI-telefonasszisztens és AI-nyelvtanár

Lezárult a DIMOP Plusz projektünk: az abigel.ai címen elérhető a telefonasszisztens és az AI-nyelvtanár. Tanulságok késleltetésről, streamingről, telefóniáról.

ProCat Solutions abigelvoice-aidimop-pluszsaastelefónianyelvtanulás
Elérhető az Abigel.ai: AI-telefonasszisztens és AI-nyelvtanár

Tegnap, 2026. szeptember 14-én lezárult a DIMOP_PLUSZ-1.1.2/A-24-2025-00236 azonosítójú projektünk, és a fejlesztés eredménye a https://abigel.ai címen élesben elérhető. Ez a bejegyzés két dologról szól: mi készült el, és mit tanultunk a több mint egy év alatt, amíg egy telefonhívást valós időben feldolgozó rendszert építettünk.

Az Európai Unió társfinanszírozásával.

Mi az Abigel.ai?

Az Abigel.ai két terméket foglal magában, közös infrastruktúrán.

Virtuális asszisztens. Egy AI-telefonasszisztens, amely a vállalkozás telefonszámán a nap 24 órájában fogadja a hívásokat. Beszélget a hívóval, időpontot foglal, üzenetet vesz fel, egyszerű kérdésekre válaszol, és minden hívásról átiratot és összefoglalót készít. A hívás menetét az ügyfél no-code folyamatszerkesztőben állítja össze, programozás nélkül. Az asszisztens több mint 25 nyelven beszél, és a hívó nyelvét felismeri.

Tanár. Egy beszélgetős AI-nyelvtanár, amely 26 nyelven tart társalgási órát, A1-től B2 szintig. A tanuló beszél, a rendszer valós időben válaszol, javít és visszajelez. A telefonasszisztenshez épített hangfeldolgozási lánc itt más célt szolgál, de ugyanaz a technológia.

Mindkét termék többbérlős SaaS: használatalapú árazás, bérlőnként elkülönített adatok, EU-n belüli, GDPR-megfelelő üzemeltetés, hívásnapló és CSV-export. A projekt a pályázatban vállalt tartalommal valósult meg.

A késleltetés az egyetlen mérőszám, ami igazán számít

A projekt legfontosabb műszaki tanulsága egyetlen mondatban: egy telefonbeszélgetésben minden, ami néhány száz ezredmásodpercnél tovább tart, hallható. Az ember a beszélgetőpartner válaszát nagyjából fél másodpercen belül várja; ha ez másfél másodpercre nő, a hívó közbeszól, elbizonytalanodik, vagy leteszi.

A beszédfelismerés, a nyelvi modell és a beszédszintézis egymás után futtatva könnyen több másodpercet ad ki. Amit ez ellen tettünk:

  • Streaming minden lépésben. A beszédfelismerés részeredményeket ad, mielőtt a mondat véget ér; a nyelvi modell válasza tokenenként érkezik; a beszédszintézis az első mondatot már mondja, amíg a többi generálódik. A lánc nem lépésekben, hanem csővezetékként működik.
  • Beszédvég-felismerés. Annak eldöntése, hogy a hívó befejezte-e a mondandóját, nehezebb, mint gondoltuk. A túl rövid csend-küszöb félbeszakítja az embert, a túl hosszú lassít. A küszöböt a beszéd tartalma alapján is hangoljuk, nem csak a csend hossza szerint.
  • Közbevágás kezelése. Ha a hívó beszélni kezd, amíg az asszisztens mond valamit, a lejátszást azonnal megszakítjuk, és az addig elhangzott részt tekintjük a kontextusnak. E nélkül a beszélgetés természetellenes.
  • Földrajzi közelség. A hang- és nyelvi modellek szolgáltatóit az EU-n belüli végpontokon használjuk, a saját komponensek pedig ugyanabban az adatközpontban futnak. Minden hálózati ugrás tíz-húsz ezredmásodperc, és ezek összeadódnak.

A késleltetést hívásonként, lépésenként mérjük és percentilisként követjük. Ez volt az a metrika, amely alapján a legtöbb architektúra-döntést meghoztuk.

Telefónia: a régi problémák nem tűntek el

A SIP és PSTN világáról korábban írt tapasztalataink mind előkerültek, néhány újjal kiegészülve:

  • a telefonhálózat 8 kHz-es, G.711-kódolású hangja lényegesen kevesebb információt hordoz, mint amin a beszédfelismerő modellek tanultak; a felismerési pontosság telefonhangon rosszabb, és ezt a folyamatszerkesztőben megerősítő kérdésekkel kell ellensúlyozni,
  • a hang továbbítása a SIP-oldal és a feldolgozási lánc között pufferelés nélkül, kis keretekben történik; minden puffer késleltetés,
  • a szolgáltatói SIP-trunkök viselkedése eltér a hívásátadásnál és a DTMF-kezelésnél, ezért a bridge-réteg szolgáltatónként konfigurálható,
  • a hívás közben a hálózat ingadozhat; a jitter és a csomagvesztés a felismerés minőségét rontja, ezért az RTCP-adatokat a hívásnaplóba is írjuk.

A tesztelést nem lehetett kézi hívásokra alapozni. Automatizált hívásokat indítunk, amelyek előre felvett vagy szintetizált beszéddel végigjárják a folyamatokat, és az átiratot az elvárttal vetik össze. Ez lassú, de e nélkül minden módosítás után kézzel kellett volna telefonálni.

A nyelvi modell egy telefonhívásban

A nagy nyelvi modell a beszélgetés motorja, de a telefonhívás sajátos környezet. Rövid, szóbeli válaszokat várunk, nem bekezdéseket; a folyamatszerkesztőben megadott lépéseket követnie kell, nem improvizálnia; és ha a felismerés hibázott, kérdeznie kell, nem találgatnia. A folyamat leírását a modell strukturált utasításként kapja, a szabad szöveg csak a megfogalmazásban van.

Az időpontfoglalás és hasonló műveletek eszközhívásként (tool call) mennek a backend felé, amely az eredményt visszaadja a modellnek. Itt is az idempotens feldolgozás a kulcs: egy újrapróbált hívás nem foglalhat két időpontot.

Hogyan tovább?

A projekt lezárult, a termék él, és a következő hónapok az üzemeltetésről és a finomhangolásról szólnak. A blogon folytatjuk a tapasztalatok megosztását; a hangalapú rendszerek terheléses tesztelése és a hívásminőség-alapú riasztás lesz a következő téma.

Köszönjük a Magyar Kormány és az Európai Unió támogatását, és köszönjük mindenkinek, aki a projekt során tesztelt, visszajelzett és türelmes volt az első, még akadozó hívásoknál.

Kapcsolódó cikkek

QR Code