7.  rész

Az eredmény: magyar nyelven működő navigációs alkalmazás megvalósítása

Cikksorozatunk utolsó részében röviden áttekintjük a megvalósított NLI keretrendszer-prototípus elemeit, majd a megoldás működőképességét igazoló mintarendszert mutatjuk be.

Első cikkünkben bemutattuk a természetes nyelvi intefészek általános felépítését, moduljait. Itt részletesen kitértünk az egyes modulok főbb feladataira, célkitűzéseire, alapvető követelményeire. Ezen cikk célja az volt, hogy átfogó képet nyújtson az NLI felületekről. A cikk konklúziójában összegzésre kerültek a fejlesztés alatt követendő főbb szempontok.

Második cikkünkben az NLI rendszerek követelményeit, funkcióit vizsgáltuk részletesebben. Itt kitértünk az alkalmazásra kerülő algoritmusok ismertetésére, felsorolására. A cikk során meghatározásra került a megvalósítandó NLI keretrendszer struktúrája, illetve logikai felépítése. Ez alapján jól elkülöníthető modulokra tudtuk bontani a teljes rendszert, amelyek jól körülírt interfészen kommunkálnak egymással. A cikk célja az NLI keretrendszer funkcionális specifikációjának összefoglalása volt, utána az egyes modulok tervezése, abban rejlő kihívások kerülhetnek tárgyalásra.

Harmadik cikkünk a beviteli eszközökről szólt, amelyek elengedhetetlen elemei a természetes nyelven kommunkáló rendszereknek. Legegyszerűbb esetben ez az eszköz egy billentyűzet, amelyen keresztül a természetes nyelvi szöveges mondatokat adhatjuk meg. Természetesen jóval kényelmesebb megoldást biztosít pl. egy beszédfelismerő illesztése, amely az emberi beszédet képes írott szöveges formára átalakítani. Ebben a cikkben megvizsgáltuk az alkalmazható beszédfelismerési módszereket és azokat az eszközöket, amelyekkel a beszédfelismerő működhet. A vizsgálat eredményeként döntés született az alkalmazandó beszédfelismerő motorról és a futtató hardverről. A cikkben kitérünk még a különböző forrásból eredő elírási vagy konverziós hibák miatti hibajavítás szükségességére is. Ezek ugyanis a későbbi feldolgozást vihetik - előre nem jósolható módon, illetve mértékben - félre.

Negyedik cikkünkben a morfológia kihívásairól, feladatairól írtunk. A természetes nyelvi szöveg értelmezésekor nagyon fontos szereppel bír a pontos morfológiai elemzés. Kiváltképp egy olyan nyelv esetén, mint a magyar, ez még fokozottabban érezhető, ugyanis a ragozó nyelvcsaládba tartozó nyelvek esetén egy adott szó mondatbeli szerepét a szóhoz kapcsolódó toldalékok határozzák meg. Fontos funkció tehát a szavak szótövének és toldalékláncolatának pontos meghatározása. Emellett a természetes nyelven történő válaszgenerálásnál az előbbi “inverz”-folyamatára, a ragozásra is szükség lehet, amikor is a szótőt és a ragozási szabályokat adhatjuk meg és a toldalékolt formát kapjuk eredményképpen. Ezen folyamatok során használt modelleket, adatbázis struktúrát, szabályokat ismerteti részetesen a negyedik cikk.

Ötödik cikkünk a szemantikai feldolgozásról szól. Manapság igen divatos fogalom az ontológia, amely a szemantikai modellezésnek, jelentéskinyerésnek alapvető iránya lett. A szemantika alapelemeinek a fogalmakat és azok közti kapcsolatokat tekintjük a cikkünkben. A cikk továbbá ismerteti a domain ontológiai almodulok szerkezetét, illetve a modulok legfontosabb folyamatainak lépéseit. A fogalmi leírások XML nyelven történnek, ezen adatok mappelése a Java osztályokhoz jól definiált módon történik. Ennek ereményeképpen igen sok modell osztályt kell a modulban kezelni, amelyhez a cikk végén találhatunk egyfajta ajánlást.

Hatodik cikkünkben a parancsfeldolgozás folyamatait, modelljeit foglaltuk össze. A fogalmak észlelése után az utolsó lépés az, hogy az NLI felülettel kiterjesztendő alkalmazásunk funkcióit számba vegyük és meghatározzuk az egyes fogalmak funkciókhoz való rendelését. Ez többnyire nem egyszerű feladat, sok tényezőt kell figyelmbe venni ahhoz, hogy a mappelés a lehető legpontosabb legyen. Az utolsó előtti cikkünkben kitértünk arra röviden, hogy milyen típusú alklamazásokat lehet kiterjeszteni NLI felületekkel, milyen jellegű parancsokat, kéréseket lehet természetes nyelven megfogalmazni. Ezek után pedig egy összefoglalást olvashattunk a modul leíró adatairól, amelyeket a fogalmak parancsokhoz, paraméterekhez való társítása során használunk.

Utolsó cikkünkben az előzőekben kialakított NLI keretrendszert használjuk fel egy konkrét alkalmazás magyar nyelven történő vezérléséhez.

A mintarendszer

Az NLI keretrendszer használatát egy olyan alkalmazáson mutatjuk be, amelyik útvonaltervezésnél, címek, nevezetes helyek keresésénél nyújthat segítséget használója számára. Az alkalmazás a Google Maps szolgáltatásaival kommunikál és a következő funkciókat képes “megérteni” természetes nyelven írt magyar szövegből:

• legközelebbi nevezetes hely keresése (iskola, étterem, bolt, benzinkút, szálloda, stb…)
• közeli nevezetes helyek keresése
• nevezetes helyeken végezhető cselekvés által történő helykeresés (“Hol lehet a közelben enni?”)
• távolság meghatározása két magyar város között
• távolság meghatározása a legközelebbi keresendő nevezetes helyig
• távolság meghatározása egy adott címig vagy két cím között
• útvonal meghatározása két magyar város között
• útvonal meghatározása az aktuális poziciónktól a keresett városig vagy nevezetes helyig
• útvonal meghatározása egy adott címig vagy két cím között
• nevezetes helyek adatainak lekérdezése (név, cím, weboldal, telefonszám)
• nevezetes hely weboldalának megnyitása az alapértelmezett böngészőben
• nevezetes hely felhívása előre beállított VoIP alkalmazással vagy kitárcsázása a csatlakoztatott Windows Phone 7 telefonra
• funkciómemória, amely a legutolsó kérdéseket, kéréseket tartalmazza, így a szövegben ezekre történő utalás is értelmezhető (“Hogy jutok oda?”, stb…)

A mintarendszer teljes architektúrája a következő ábrán látható:

1. ábra : A mintarendszer felépítése

Beszédfelismerő

A Nuance Recognizer beszédfelismerőjével lehetővé válik a mintaalkalmazás beszéddel történő vezérlése. Ez a magyar nyelv esetén koránt sem egyszerű, éppen ezért némi korlátozás van a rendszerben. A beszédfelismerő azokat a mondatokat (szószekvenciákat) képes felismerni, amelyeket előzőleg egy XML nyelvtani fájlban megadtunk neki. A következő ábra egy rövid mintát mutat be arról, hogyan lehetséges a beszédfelismerő nyelvtanát megadni:

<?xml version="1.0"?>

<grammar xml:lang="hu-hu" version="1.0" xmlns="http://www.w3.org/2001/06/grammar">

<rule id="hol_van_group" scope="public">

<item>

<one-of>

<item><rulerefuri="#hol_van" /></item>

<item><rulerefuri="#hol_talalhato" /></item>

<item><rulerefuri="#hol_tudok" /></item>

<item><rulerefuri="#hol_lehet" /></item>

</one-of>

</item>

</rule>

<rule id="hol_van" scope="public">

<item>hol van</item>

<item repeat="0-1">egy</item>

<item repeat="0-1">

<one-of>

<item>közeli</item>

<item>a legközelebbi</item>

</one-of>

</item>

<item>

<rulerefuri="poi.xml#objektum"/>

</item>

<item repeat="0-1">a közelben</item>

</rule>

<rule id="hol_talalhato" scope="public">

<item>holtalálható</item>

<item repeat="0-1">egy</item>

<item repeat="0-1">

<one-of>

<item>közeli</item>

<item>a legközelebbi</item>

</one-of>

</item>

<item>

<rulerefuri="poi.xml#objektum"/>

</item>

<item repeat="0-1">a közelben</item>

</rule>

<rule id="hol_tudok" scope="public">

<item>holtudok</item>

<item>

<rulerefuri="poi.xml#tevekenyseg"/>

</item>

<item repeat="0-1">a közelben</item>

</rule>

<rule id="hol_lehet" scope="public">

<item>hollehet</item>

<item>

<rulerefuri="poi.xml#tevekenyseg"/>

</item>

<item repeat="0-1">a közelben</item>

</rule>

</grammar>

A felismerő a észlelt mondatokat TCP socket kommunikáció során elküldi az NLI motornak, amely elvégzi rajta az elemzéseket és esetleges javításokat.

NLI motor

Az NLI motor feladatai a kapott szöveg elemzésével, esetleges javításával kezdődnek. Elsődlegesen a bejövő szöveget mondatokra, ezeket pedig szavakra kell bontani. Ezt követi a hibajavítás. Itt egy egyszerű kis helyesíráselemzőre kell gondolni, amely a hibás szóra, szavakra a hozzá leghasonlóbb, helyes megoldást adja. A hasonlóság mértéke, illetve az, hogy milyen algoritmusokat használunk, erősen függhet a bemeneti eszköz típusától, így a bemeneti modul inicializálásnál a forrás típusát is ki kell választanunk. Jelenleg az NLI motor a billentyűzetet és a beszédfelismerőt ismeri, mint bemeneti forrást, de fel van készítve arra, hogy későbbiekben akár OCR vagy kézírás felismerő bemenetet is tudjon fogadni.

Az esetleges hibajavítások után még egy fontos feladata van a modulnak, mégpedig a “speciális elemek” detektálása, címkézése. Speciális elem lehet sokféle: dátum, cím, szám, nevek, helységnevek, stb. Ezekben az a közös, hogy a morfológiai elemzőnek ezekkel nem kell foglalkoznia, illetve csak annyiban, hogy a ragokról megállapítsa, hogy milyen kategóriába tartozik. A speciális elem felismerése opcionális, nincs szükség rá mindig, minden domain esetében, így tetszőlegesen bekapcsolhatóak, illetve kikapcsolhatóak a detektorok. Sőt újabb detektor implementálására is lehetőség nyílik. A mintaalkalmazásban szám és cím detektorokat alkalmazunk. A cím detektor képes felismerni egy címet a lehető legtöbb formában.

A morfológiai modul megkapja a szövegtiszító modul eredményét XML formában és ezen dolgozik tovább. Egyetlen, ámde meglehetősen bonyolult feladatot kell elvégeznie, a szavak morfológiai elemzését. Ehhez a magyar nyelvi morfológiai adatbázist használja, amely az NLI motor belpített nyelve, tehát annak fejlesztése során feltöltésre került.

A morfológiailag elemzett szavakat a domain ontológiai modul kapja meg, amely első körben elvégzi a lehetséges fogalmak detektálását a mondatból. Ehhez szükség van a domain fogalmait leíró XML fájlokra, amelyeket, minthogy domain-enként más és mások lehetnek, mindig a kiterjesztendő alkalmazással együtt kell implementálni. A mintaalkalmazásban a következő domain ontológiai leírók szerepelnek:

• ApplicationOntology.xml: az alkalmazás funkcióinak fogalmait írja le
• BaseOntology.xml: az alkalmazás alap, illetve közös, más leíróban is használatos fogalmakat, illetve kapcsolatait írja le
• CityOntology.xml: a városok fogalmait írja le
• DataOntology.xml: a nevezetes helyek adatainak fogalmi leírását tartalmazza
• GasStationOntology.xml: benzinkúttal kapcsolatos fogalmak és kapcsolatok
• HospitalOntology.xml: kórházzal kapcsolatos fogalmak és kapcsolatok
• HotelOntology.xml: szállodával kapcsolatos fogalmak és kapcsolatok
• IskolaOntology: iskolával kapcsolatos fogalmak és kapcsolatok
• LibraryOntology: könyvtárral kapcsolatos fogalmak és kapcsolatok
• MuseumOntology: múzeummal kapcsolatos fogalmak és kapcsolatok
• NumbersOntology: számokkal kapcsolatos fogalmak és kapcsolatok
• RestaurantOntology: étteremmel kapcsolatos fogalmak és kapcsolatok
• ShopOntology: bolttal kapcsolatos fogalmak és kapcsolatok
• SwimmingPoolOntology: uszodával kapcsolatos fogalmak és kapcsolatok
• TheaterOntology: színházzal kapcsolatos fogalmak és kapcsolatok.

Ezen ontológialeíró fájlok betöltése után már elvégezhető a fogalmak és a köztük lévő kapcsolatok detektálása. A modul eredményeképpen egy olyan XML-t kap a parancsfeldolgozó modul, amely a bejövő mondat mondattani elemzését tartalmazza, természetesen a fogalmak hozzárendelésével együtt.

Az NLI motor  utolsó modulja végzi a fogalmak hozzárendelését a parancsokhoz, illetve azok paramétereihez. Ehhez szintén szükség van olyan leíró fájlokra, amelyek megmondják, hogy:

• Milyen parancsok érhetőek el a rendszerben?
• Milyen paraméterekkel rendelkeznek?
• Mely paraméterek kötelezőek, melyek nem?
• Milyen az egyes paraméterek típusa?
• Milyen fogalmak, illetve mondatbeli szereppel köthetőek a paraméterhez?

Az alábbiakban egy parancs leírásának rövid mintaimplementációját láthatjuk:

<?xml version="1.0" encoding="UTF-8"?>

<Function class="com.minervasoft.nli.demo.gps.functions.GPSFunctions"

method="callPlace" name="Call"

xmlns=http://minerva-soft.com/nli/com/ApplicationFunctionSchema

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:schemaLocation="http://minerva-soft.com/nli/com/ApplicationFunctionSchema

../../../NLICommand/resources/xml/ApplicationFunctionSchema.xsd ">

<PredicateConcept>

<Concept base="http://minerva-soft.com/nli/dom/#felhiv" />

</PredicateConcept>

<Parameters>

<Parameter name="tool" number="1" required="false" type="string">

<Concept base="http://minerva-soft.com/nli/dom/#telefon_eszkoz"/>

<Constituents>

<Constituent id="http://minerva-soft.com/nli/dom/#adverbs_of_tool"/>

</Constituents>

</Parameter>

<Parameter name="number" number="2" required="false" type="Integer">

<Concept base="http://minerva-soft.com/nli/dom/#number_concept"/>

<Constituents>

<Constituent id="http://minerva-soft.com/nli/dom/#lifeless_object"/>

<Constituent id="http://minerva-soft.com/nli/dom/#designator_adjective"/>

</Constituents>

</Parameter>

</Parameters>

<Result>

<Concept base="http://minerva-soft.com/nli/dom/#GPSResults"

value="http://minerva-soft.com/nli/dom/#void" />

</Result>

</Function>

Ilyen és ehhez hasonló funkcióleírásokat kell az alkalmazásban létrehozni és betölteni. A parancsfeldolgozó modul ezeket a leírásokat felhasználva a bemenetként kapott mondatelemzésből képes meghatározni a legjobban illeszkedő funkciót. Abban az esetben, ha a parancs valamely kötelező paramétere hiányzik, a rendszer visszakérdez, amelyre a felhasználó szintén természetes nyelvű választ fog adni. Ekkor az elemzés, illetve az illesztés annyiban egyszerűsödik, hogy célzott, előre kijelölt paraméterre kérdezünk rá, tehát azt várjuk a válaszban. Amint a „nyertes” parancs összes szükséges paramétere felismerésre került, végrehajtásra kerül a konkrét funkció, ami szintén a leíróban került meghatározásra. Ebben a lépésben dinamikusan töltődik be a szükséges osztály, futás közben jönnek létre a leíróban definiált osztályok és hívódnak meg azok metódusai. Ebből következően a rendszer viszonylag könnyen bővíthető, nem kell mást tenni, mint a végrehajtandó osztályt leimplementálni, lefordítani és megírni a hozzá tartozó funkcióleíró XML-eket.

A parancsvégrehajtás eredményét a vezérlendő alkalmazás kezeli és képes megjeleníteni:

• helyeket a térképen
• útvonaltervet
• útvonalat térképen
• távolságértéket két hely között
• helyek adatait (név, cím, telefon, weblap).

Ezen felül pedig még a helyet fel lehet hívni telefonon, illetve a weboldalát megjeleníteni az alapértelmezett böngészőben. Azt, hogy az eredményt milyen formában kell kezelni, az eredmény típusa dönti el.

Összefoglalás

A következőkben összefoglaljuk, milyen lépéseket kell ahhoz tenni, hogy egy alkalmazást az NLI keretrendszert használva természetes nyelvi felülettel terjesszünk ki:

1.     Definiálnunk kell a domain ontológia fogalmait, azok kapcsolatait ontológia leíró XML fájlokban.

2.     Definiálnunk kell az alkalmazás NLI-n keresztül elérhető funkcióit a parancsleíró XML fájlokban.

3.     Az interfész modult le kell implementálnunk, hogy összekössük az NLI keretrendszert az alkalmazással. Ez tulajdonképpen egy minimális wrapper.

4.     Az XML fájlokat be kell töltenünk az interfész alkalmazásba, emellett az NLI motor konfgurációjára is lehetőség nyílik ebben a lépésben.

5.     Az interfész alkalmazásban kezelnünk kell a végrehajtott parancsok eredményeit, visszatérési értékét, amennyiben van.

Ebből is látható, hogy túlnyomórészt előre meghatározott XML sémákra illeszkedő XML fájlokat kell írogatnunk és azokhoz egy minimális kis alkalmazást kell írnunk ahhoz, hogy a célalkalmazásunkkal természetes nyelven tudjunk kommunikálni.

Összefoglalásként elmondhatjuk, hogy a kitűzött célokat az NLI keretrendszer megvalósításával sikerült elérni! Ezt mi sem bizonyítja jobban, minthogy három független mintaalkalmazás is készült ennek használatával - ezekből utolsó cikkünkben a legkomplexebb került bemutatásra. További fejlesztések, kutatások természetesen lehetségesek a kialakított rendszeren, így pl. az öntanulás lehetőségének vizsgálata, illetve statisztikai módszerek integrálása a fogalomkialakításba és elemzésbe.

Jelen publikáció eredményei a GOP-1.1.1-09/1-2009-0028 számú, “Domain- és nyelvadaptív természetes nyelvű parancsfelület prototípusának kidolgozása” című projekt keretében születtek.