Nyelvtechnológiai alkalmazások integrálása keresőmotor(ok)ba

Eötvös Loránd Tudományegyetem Informatikai Kar Nyelvtechnológiai alkalmazások integrálása keresőmotor(ok)ba Dr. Prószéky Gábor egyetemi docens PPKE ITK Orosz György nappali tagozat programtervező matematikus Budapest, 2010.

A diplomamunka bekötve kell, hogy tartalmazza a kitöltött és jóváhagyott diplomamunka témabejelentőt. Ennek a lapnak a helyére kell bekötni. * * *

3

Tartalomjegyzék 1. Bevezetés 7 2. Természetes nyelv és keresők kapcsolata 8 2.1. Nyelvi szöveg számítógépes reprezentációja................ 8 2.1.1. ASCII................................ 9 2.1.2. ISO 8859.............................. 9 2.1.3. Windows kódlapok......................... 10 2.1.4. Unicode............................... 10 2.2. Természetes-nyelvi feldolgozás....................... 11 2.2.1. Történet............................... 12 2.2.2. Alkalmazások............................ 13 2.3. Keresőrendszerek.............................. 13 2.3.1. Internetes keresők története.................... 15 2.3.2. Vertikális keresés.......................... 17 2.4. Nyelvi eszközök keresőrendszerekben................... 18 3. A megfelelő keresőrendszer választása 21 3.1. Szempontok................................. 21 3.2. Vizsgált keresőrendszerek......................... 22 3.2.1. OpenFTS.............................. 23 3.2.2. Terrier................................ 23 3.2.3. Lucene............................... 23 3.2.4. Datapark Search Engine...................... 23 3.2.5. Egothor............................... 24 3.2.6. Xapian............................... 24 3.2.7. ht://dig............................... 24 3.2.8. Lemur/Indri............................. 24 4

3.3. A Lemur és az Indri működése....................... 25 3.3.1. Indexelés.............................. 26 3.3.2. Lekérdezés............................. 29 3.3.3. Egyéb alprogramok......................... 30 4. Nyelvi kereső létrehozása 33 4.1. Szótövező modul.............................. 33 4.1.1. Lemur, Indri............................ 34 4.1.2. Tövező integrációja......................... 34 4.2. Tiltólistás szavak.............................. 35 4.2.1. Stopword szűrés az Indriben.................... 36 4.2.2. Szavak választása, megvalósítás.................. 36 4.3. Dátumok használata............................. 36 4.3.1. Motiváció.............................. 36 4.3.2. Dátumok kategorizálása...................... 36 4.3.3. Dátumkezelés az Indriben..................... 37 4.3.4. Magyar nyelvű dátumok kezelése................. 39 4.3.5. A megoldás korlátai........................ 41 4.4. Mennyiségek használata.......................... 41 4.4.1. Motiváció.............................. 41 4.4.2. Mennyiségek indexelése, keresése az Indriben........... 42 4.4.3. Általános megoldás mennyiségek használatára.......... 43 4.4.4. Megoldatlan problémák...................... 44 4.5. Szinonimák használata........................... 45 4.5.1. Motiváció.............................. 45 4.5.2. Rokon értelmű szavak használata az Indrivel........... 45 4.5.3. Automatikus szinonimahasználat.................. 46 4.5.4. A megoldás korlátai........................ 46 5. Az elkészült rendszer értékelése 47 5.1. Teljesítmény................................. 47 5.1.1. Indexelési idő............................ 47 5.1.2. Index mérete............................ 48 5.1.3. Lekérdezési idő........................... 49 5.2. Relevancia.................................. 50 5.2.1. Módszer............................... 50 5

5.2.2. Mérési eredmények......................... 52 5.3. Összefoglalás................................ 53 Köszönetnyilvánítás 54 Függelék 55 Tiltólistás szavak................................. 55 Konfigurációs fájl................................. 58 Felhasználói dokumentáció............................ 60 Fejlesztői dokumentáció............................. 63 Irodalomjegyzék 87 6

1. fejezet Bevezetés Az elmúlt két évtizedben az internet elterjedésével a keresőrendszerek népszerűsége hatalmas mértékben növekedett. A világhálón található mérhetetlen információmennyiség használata, mára aligha lehetséges keresők nélkül. Erre az igényre éreztek rá a múlt század végén olyan nemzetközi nagyvállalatok, mint a Google, Yahoo, Microsoft. Az is igaz, hogy a keresők használata a mai ember számára már-már alapvető szükségűvé vált, így a fejlesztő cégek nagy energiát fektetnek ezek használhatóbbá tételére. Az utóbbi néhány évben azt a tendenciát figyelhetjük meg, hogy mind gyakrabban találkozhatunk intelligens eszközökkel a keresések során. Ezen eszközökkel a vállalatok célja az, hogy minél közelebb vigyék a keresőrendszert a felhasználókhoz. Magyarországon is egyre több cég érez potenciális üzleti lehetőséget intelligens keresők fejlesztésében. Ilyen hazai próbálkozás például a PolyMeta, mely a világcégek keresőinek eredményeit aggregálva dolgozik. A fentebb intelligensnek nevezett modulok legtöbbször olyan szoftvert takarnak, melyek a természetes nyelvi megértést segítik. Nyilván az emberi kommunikáció számítógéppel való teljes megértése csak egy távolban lebegő cél a kutatók előtt, de ezek szoftverek jó tulajdonságokkal rendelkezhetnek információ keresési alkalmazásokban. A dolgozattal és a hozzá tartozó programmal a témakiíráshoz kapcsolódó következő feladatot oldottam meg: Vizsgáljuk meg a keresőrendszerek működését, majd azt, hogy általában milyen lehetőségek kínálkoznak a rendszer teljesítményének javítására magyar nyelvű környezetben! Egy választott keresőrendszert egészítsünk ki a Morpho- Logic által rendelkezésre bocsátott szótövezővel és szinonima szótárral, majd vizsgáljuk meg milyen további lehetőségek vannak még a kereső fejlődését tekintve! Készítsük el a rendszer fejlődését segítő eszközöket, majd mérjük meg az így kapott magyar nyelvű kereső eredményességét, teljesítményét! A fenti méréshez szolgáljon alapul az 1994 és 2008 között született parlamenti naplók adatbázisa! 7

2. fejezet Természetes nyelv és keresők kapcsolata Ebben a fejezetben áttekintem a nyelvtechnológiával, keresőrendszerekkel, szövegek tárolásával kapcsolatos alapfogalmakat és ezek kapcsolatát.[6] 2.1. Nyelvi szöveg számítógépes reprezentációja A ma használatos számítógépeken futó szoftverek egy dokumentumot karakterek halmazaként kezelik, így egy szöveg reprezentálása is egymást követő karakterek reprezentálásával valósul meg. Nyilván egy természetes nyelven íródott szöveg szerkezete ettől az egyszerű leképezéstől jóval összetettebb, de ezek a struktúrák is kifejezhetőek megfelelően választott karaktersorozatokkal. Ha picit elidőzünk azon, hogy miért éppen egy karakter a tárolás alapegysége, elgondolkodhatunk azon, hogy más reprezentáció is létezhetne (pl.: a nyelv szavainak tárolásával), de ezek nem illeszkednének a digitális számítógép működési elvéhez oly mértékben, mint a jelenlegi. Folytatva a gondolatmenetet: egy dokumentum tárolásának feladata helyett, elegendő egy karakter tárolásának feladatát megoldani. Számítógépeink alapvetően számokkal végzett műveletek végrehajtására képesek, ezért a karakterek is számokként kerülnek tárolásra. Most a karakter alapú dokumentum tárolással kapcsolatos alapfogalmakat fogom áttekinteni.[6, 15]. Karakter A számítógép alapú kommunikáció alapegysége. Egy karakter lehet betű, szám, írásjel vagy egyéb nem látható vezérlőkarakter. A Unicode szabvány definíciója szerint az adat szervezésére, ellenőrzésére vagy megjelenítésére használt elemek halmazának egy tagja. Karakterkészlet Karakterek rendezetlen halmaza. Egy karakterkészlet a gyakorlatban 8

úgy szokás megadni, hogy a karakterek nevei mellett annak képi ábrázolását 1, is megjelenítjük. Az is előfordulhat, hogy több különböző karakternek azonos a megjelenése. Karakterkód Minden karakterhez a karakterkészletből hozzárendelünk egy nem negatív egészet, így kapjuk annak kódját. Fontos megjegyezni, hogy ez a leképezés nem feltétlenül monoton. Karakterkódolás Olyan algoritmus, mely karakterkódokhoz oktettek 2 sorozatát rendeli. Az alábbiakban egy szabványt teljesnek fogok nevezni, ha definiál karakterkészletet, karakterkódokat és karakterkódolást is. Az idők során számos módszer alakult ki és terjedt el karakterek reprezentálására. Most áttekinteném a ma legszélesebb körben használatosakat. 2.1.1. ASCII Ebben a teljes szabványban a használható karakterek halmaza az angol ábécé betűin kívül csak néhány speciális szimbólumból és vezérlőkarakterekből áll. A karakterkészlet összesen 128 jelet tartalmaz, melyekhez a kódolás pontosan egy oktettet rendel. A szabványt a digitális kommunikáció hőskorában fejlesztették ki, amikor az adatátviteli technológiák még korántsem voltak tökéletesek, így az oktettek tárolásakor fennmaradó 1 bitet adatátvitel-ellenőrzési célokra tartották fent. Legnagyobb hiányossága, hogy nem támogatja az angol ábécén kívül eső nemzeti írásjelek használatát. Előnye ugyanakkor, hogy e nyelv használatára hatékony eszközt ad. 2.1.2. ISO 8859 Az ASCII kódolás gyengeségeinek kiküszöbölését megcélozva jött létre az ISO 8859 szabvány. Ez tekinthető elődje egy bővítésének, mely a korábban ellenőrzésre fenntartott 8. bitet is tárolásra használja, így lehetővé téve 256 karakter tárolását. A nemzeti írásjelek sokfélesége miatt a szabvány 15 variánssal rendelkezik, attól függően, hogy a fennmaradt 128 helyre mely nemzet(ek) különleges szimbólumai kerülnek. Néhány példa: 8859-1 (Latin-1) - nyugat-európai nyelvek támogatása 1 más néven glifa 2 0 és 255 közötti egész szám - használata bájt alapú számítógépek esetén kényelmes, ekkor ugyanis minden oktet egy bájton tárolódhat 9

8859-2 (Latin-2) - közép-európai nyelvek támogatása (magyar is) 8859-3 (Latin-3) - dél-európai nyelvek támogatása A szabvány teljes és kompatibilis elődjével, ami ebben az eseteben azt jelenti, hogy az első 128 egészhez rendelt karakterek megegyeznek mindkét karakterkódolási eljárásban. Hátrányai között említendő egyrészt, hogy használata többnyelvű környezetben nehézkes, másrészről több karakterkódolást is tartalmaz egyes nemzetek karaktereihez (8869-4 / 8859-13). 2.1.3. Windows kódlapok Látva az ASCII hiányosságait a Microsoft is elkészítette saját kiterjesztését. Ez a módszer is teljes, és felülről kompatibilis elődjével. Az előzőekhez hasonlóan csak korlátozott mennyiségű karakter használatát teszi lehetővé. Az eljárás úgynevezett kódlapokból áll, amik arra szolgálnak hogy az ASCII-t egy vagy több nemzet karaktereivel kiegészítve karakterkészletet, karakterkódokat és kódolást definiáljanak. Ezek közül a magyar ábécét teljesen egészében tartalmazó kódlap a CP-1250, a nyugat európai pedig a CP-1252. Legnagyobb különbség a 8859 szériához képest, hogy míg az ISO szabvány a 128-159 értékekhez csak vezérlő karaktereket rendel, addig a kódlapok ezen értékeken nyomtatható karaktereket is tárolnak. Ezzel sajnos elveszti az ISO 8859 szabvánnyal való kompatibilitását. A kódlapok bár széles körben használtak különösen Windows operációs rendszerekben nem képezik egyetlen nemzetközi szabvány részét sem. 2.1.4. Unicode Az internet megjelenésével, előretörésével szükségessé vált, hogy többnyelvű szövegeket is tudjunk kezelni. Erre az igényre nem adott kielégítő választ egyik korábbi eljárás sem, hiszen lehetőségeik csak néhány nemzet ábécéjének tárolására korlátozódtak. Válaszolva a kor kihívásaira jött létre a Universal Character Set 3, ami a karakterkészlet minden eleméhez karakterkódot rendel. A szabvány 4 folyamatosan bővül és mára már több tízezer jelet tartalmaz. A Unicode szabvány az UCS egy olyan kiterjesztése, mely karakterkódolást is definiál. Ez a kódolás eredetileg az ún. UCS-2 volt, ami fix 2 bájton tárolja a karaktereket. Később a karakterkészlet bővülése során ezt elvetették, és helyette 3 UCS - Általános Karakterkészlet 4 ISO 10646 10

az alábbi négy UTF 5 kódolási algoritmus valamelyike használandó. Itt fontos még megjegyezni, hogy az egyszerűbb implementáció miatt, létezik egy jól körülhatárolt részhalmaza az UCS-nek, amit BMP 6 -nek nevezünk és a 0..FFFF hexadecimális tartományban vannak a kódjai. UTF-32 Minden karakterkód 4 byte-os egészként reprezentálódik, így a jelenleg a szabványba tartozó összes jelet egyszerűen tudjuk kezelni. Hatékonysága viszont messze nem kielégítő, hiszen ha csak egyszerű angol nyelvű szövegekkel dolgozunk, akkor a tárigénye négyszeres az ASCII-hoz képest. UTF-16 A korábban említett UCS-2 kódolás szuperhalmaza, ami azt jelenti, hogy csak a BMP-re korlátozva az UCS-2 kódolást, az UTF-16 ot kapjuk. Az UTF-32 től eltérően ez egy változó hosszúságú kódolás: BMP-beli elemeket 2 byte-on míg a többieket 4 byte-on tárolja. UTF-8 Ez a kódolási eljárás kompatibilis az ASCII-val, tehát a 0..128 tartományba eső kódokat ugyanúgy tárolja mint elődje, viszont az e fölöttiekre egy kissé bonyolult, de tárolási értelemben hatékony változó hosszúságú leképezést alkalmaz. UTF-7 Olyan változó hosszúságú karakterkódolás, melyben minden karakterkód legalább egy, legfeljebb négy 0..128 tartományba tartozó oktettel van reprezentálva. Nem kompatibilis az ASCII-val. 2.2. Természetes-nyelvi feldolgozás A természetes-nyelvi feldolgozás 7, az informatika olyan résztudománya, mely természetes nyelvi jelenségeket, problémákat az informatikai oldaláról közelíti meg. 8 A tudományág a mesterséges intelligencia kutatások és nyelvészet határterületén van. A kutatások alapvetően négy területre bonthatóak. Egyrészt beszélhetünk nyelvi elemzésről és generálásról, másrészt pedig a feldolgozás tárgya lehet írott szöveg, vagy maga a beszéd. Egy ettől részletesebb kategorizálást találhatunk a Számítógépes Nyelvészet[5] c. könyvben. 5 Universal Transformation Format 6 Basic Multilingual Plane - Alapvető Többnyelvű Karakterkészlet 7 szakirodalomban NLP - Natural Language Processing 8 http://www.aclweb.org/archive/misc/what.html 11

2.2.1. Történet A tudományág gyökerei a második világháború végéhez nyúlnak vissza, amikor is tudósok az akkori számítógépeket a kódtörésen kívül automatikus fordításra is megpróbálták felhasználni. A korai lelkesedésre jellemző, hogy ez időben számos kutatás indult a gépi fordítás témakörében. Ekkoriban sokan még azt az egyszerű nézetet vallották, hogy a nyelvek közötti egyetlen különbség a szókincsük és a mondatok szavainak sorrendje. Így az akkor született megoldások is csak valamiféle automatikus szótározó rendszerek lettek. Mint azt ma már tudjuk, ez az út hamarosan zsákutca lett. Az ezt követő években a korai sikertelenség miatt visszaesett a számítógépes nyelvészet iránti érdeklődés. Ezt a negatív folyamatot erősítette az ALPAC 9 1966 os éves jelentése, mely a gépi fordítás ideájának akkori megvalósulását kétségbevonta. Mindeközben 1957 ben megjelent Chomsky cikke a generatív nyelvtanokról, ami új megvilágításba helyezte a számítástudomány és a nyelvészet viszonyát. Mint említettem a 70 években bár jelentősen csökkent az érdeklődés a téma iránt, de a kutatások teljes egészében nem álltak le. Az ekkoriban folyó tudományos munkák elsősorban jelentés reprezentációra és a számítástudomány világába a korábbiaktól jobban illeszkedő elméletek kidolgozására összpontosult. Az elméleti kutatások mellet számos kézzel fogható eredmény is született, úgymint az ELIZA - az első mesterséges beszélgetőrobot, SHRDLU - egy olyan szerkezet, ami képes volt angol nyelvű utasítások megértésére (persze csak korlátozott módon). Az évtized végére és a 80 évek derekára előtérbe került a természetes nyelvi generálás problémaköre is, mint például a nyelvi feldolgozás statisztikai oldalról való megközelítése is. Az elmúlt két évtizedben eddig soha nem látott növekedésnek indult a tudományterület. Ez valószínűleg a megnövekedett számítási kapacitásoknak, az Internet előretörésének és a növekvő mennyiségű elektronikus dokumentumhalmaznak köszönhető. A ma használt szoftverek nagy részének már szerves alkotóját képezik nyelvi megoldások. Úgymint pl.: Google kereső automatikus szótövezés, szinonima keresés, 9 Automated Language Processing Advisory Committee of the National Academy of Science - National Research Council 12

Microsoft Office irodai programcsalád nyelvhelyesség ellenörző, szinonima szótár, Mozilla Firefox böngésző helyesírás ellenőrző, Webforditás.hu online, többnyelvű gépi fordító rendszer, A Magyarországon folyó kutatások a 90 évek elején kaptak nagy lendület, amikor is Dr. Prószéky Gábor vezetésével megalakult a MorphoLogic. A cég a kezdetektől fogva nyelvészet kutatásokat és azok gyakorlati alkalmazásait tűzte ki célul. Azóta számos, nap mint nap használt szoftver nyelvi modulját készítették el, továbbá jelentős eredményeket értek el a gépi fordítás és a nyelvi elemzés területen. 2.2.2. Alkalmazások Ma az informatika területén gyakorlatilag minden olyan feladatnak, problémának, mely szövegekkel dolgozik, célja lehet valamilyen NLP eszköz alkalmazása. A leggyakoribbak ezek közül: Információ visszakeresési alkalmazások Adatbányászati feladatok Kérdés-válasz rendszerek Szöveg kivonatolás Gépi fordítás Párbeszédes rendszerek 2.3. Keresőrendszerek Napjainkban mind többször találkozunk olyan rendszerekkel, programokkal, melyek dokumentumok halmazához férnek hozzá, és ezekhez biztosítanak keresési szolgáltatást. Ilyen esetekben a felhasználótól a rendszer egy keresőkifejezést vár, melyet értelmezve létrehozza az eredmények listáját. Ez a lista dokumentumhivatkozásokat tartalmaz, melyek tartalma a felhasználó szempontjából relevánsnak mondhatóak. Egy keresőrendszer vázlatos felépítése látható a 2.1 ábrán. A vázolt feladat megoldására a legegyszerűbb módszer 13

Keresőkifejezés Dokumentumtár és keresőgép Dokumentumlista 2.1. ábra. Keresőrendszer egyszerűsített felépítése az, hogy ha a lekérdezést a rendszer egyszerű string kereső algoritmussal próbálja megoldani végigpásztázva a dokumentumtárat. Ennek időigénye nyilván arányos a tár méretével, ami hatékonyság szempontjából nagyon rossz. Ehelyett az adathalmazt célszerű elő-feldolgozni Indexelésnek hívjuk azt a folyamatot, amikor a keresőrendszer a rendelkezésére álló dokumentumok halmazából létrehoz egy ún. indexet, mely tartalmaz kulcsszavakat és dokumentumhivatkozásokat is. Alapvetően kétféle indexet különböztetünk meg: Kulcsszóindexet, mely létrehozásakor a dokumentumokhoz párosított kulcsszavakat tároljuk az adatbázisban. Tartalomindexet, melyet úgy készítünk, hogy az összes feldolgozandó fájlt végigolvassuk, eközben minden egyes dokumentumnál összegyűjtjük a rá jellemző szavak, kifejezések halmazát, majd ezeket tároljuk az adatbázisban. A gyakorlatban az a jellemző, hogy a két módszert együttesen alkalmazzák. A feldolgozandó dokumentumok halmazát megkaphatjuk a felhasználótól, de gyakori az is, hogy a keresőrendszer egy modulja végzi ennek létrehozását. Ez az alrendszer egy kezdeti dokumentumhalmazban található hivatkozásokat rekurzívan végigjárva igyekszik bővíteni azt. Az ilyen alprogramokat, (web)crawler-nek, spider-nek vagy robot-nak hívjuk. Mint azt korábban említettem egy keresőrendszeren lekérdezéseket futtatni keresőkifejezésekkel lehet. Egy ilyen kifejezés általában nyelvi szavak és speciális karaktersorozatok kombinációja. Az hogy a rendszer milyen típusú kifejezéseket támogat jól jellemzi működését, használhatóságát: Használhatunk-e reguláris kifejezéseket? Szótövezést használ-e? Korlátozhatjuk-e a keresést valamilyen előre megadott típusú adatokra? (mezők használata) 14

Szűkíthetjük-e a keresést dátumra, nyelvre, területre? Használhatunk-e logikai műveleteket? (Pl.:AND,OR,NOT... ) Milyen egyéb műveleteket használhatunk még? (Pl.:NEAR) Ezektől kicsit elrugaszkodva, feltehetjük még a kérdést, hogy a lekérdezőnyelv támogatja-e természetes nyelvi kérdések használatát. Használat alatt itt azt értem, hogy a program megpróbálja értelmezni a kérdést, és arra választ találva létrehozni a találati listát. Egy lekérdezés futtatása után a találatok általában rendezett listában jelennek meg. Sok esetben az alkalmazás kigyűjti a keresőkifejezéshez legszorosabban kötődő 10 szavakat is, így tovább finomíthatjuk a találati listánkat. Keresők teljesítményét, hasznosságát több szempont szerint szokás mérni: 1. számítási teljesítmény szerint: (a) indexelési időben óránként feldolgozott adatmennyiség illetve az ehhez szükséges memória mérésével, (b) index mérete a tárolt adat mennyiségének viszonyában. (c) lekérdezés során az eredménylista elkészítéséhez szükséges átlagos idő alapján, 2. indexelt oldalak mennyisége alapján, 3. találati lista alkalmassága alapján. A találati lista értékeléséről a 5. fejezetben írok részletesebben. Újragondolva a keresőrendszer működését, tovább finomíthatjuk a keresőrendszer működését bemutató ábrát. Ezt láthatjuk a 2.2 ábrán. 2.3.1. Internetes keresők története Az internet hőskorában[13] még csak néhány számítógép volt hálózatba kapcsolva, így ezek nyilvántartása nem okozott különösebb nehézséget. Ezt a feladatot akkoriban Tim Berners-Lee látta el a CERNS szerverét használva. Aztán 1992 ben érkezett el az az időszak, amikor a hálózaton lévő gépeket már nehézkessé vált nyilvántartani. 10 a találatokban a kifejezések egy környezetében leggyakrabban előforduló szavak 15

Robot keresőkifejezés dokumentumlista új dokumentum Keresőgép Indexkészítő gép Index Dokumentumtár 2.2. ábra. Keresőrendszer felépítése A következő mérföldkő a történetben Matthew Gray alkalmazása 1993 ból, ami a világ első mai értelemben vett, webrobot-a. Ezzel célja a Web méretének meghatározása volt, amit 1995 ig sikeresen el is látott Az első keresőrendszernek az Aliweb-et nevezhetjük, mely 1993 novemberében tűnt fel. Ez az alkalmazás még csak azt tette lehetővé, hogy a weboldalak gazdái metainformációkat töltsenek fel honlapjukkal kapcsolatban a rendszerbe, amin utána a felhasználók kereséseket futtathattak. Ugyanezen év decemberében jelent meg a JumpStation nevű alkalmazás, aminek a működési elve a mai napig is meghatározó (robot-indexelés-keresés). Sajnos ez még nem volt képes a dokumentumokban való keresésre, csak annak címében tárolt információkkal tudott dolgozni. Az egyik első teljes tudású 11 kereső a WebCrawler volt. Ezzel egy időben jelent meg 11 a szó azon értelmében, hogy a rendszer rendelkezik robottal, indexszel, formon keresztül végezhetünk lekéréseket és a dokumentumok teljes szövegében is képes keresni 16

a Lycos, mely már üzleti sikereket is elért. Az ezt követő években számos kereső jelent meg a piacon és tett nagy népszerűségre szert: Magellan, Excite, Infoseek, Inktomi, Altavista... Mindezek között mégis a Yahoo! volt a legnépszerűbb, melynek működése alapvetően különbözött a többitől. A Yahoo! a saját ún. web directory-jában végezte a kereséseket, ugyanakkor lehetőséget biztosított ennek böngészésére is. Az igazi áttörést a versenyben a Google hozta 2000 tájékán, az új eddigiektől különböző relevancia meghatározási algoritmusával, a Pagerankkal. Ez a módszer azon alapszik, hogy a weboldalra mutató külső hivatkozások számával iteratív módon próbáljuk becsülni a felhasználó oldalra jutásának valószínűségét, majd ezt felhasználva rendezzük a találati oldalakat. Ebben az időben a Yahoo! az Inktomi technológiáját használta, majd csak 2003 ban váltott a Google-éra. 2004 től pedig saját fejlesztésű keresőmotorral működött a Yahoo! Search, egészen a 2009 es Microsofttal kötött szerződésig. 1998 ban indult útnak a Microsoft első keresője az MSN Search, amely akkor még szintén az Inktomi technológiáját használta. Később a redmondi vállalat az Altavista-ét liszenszelte, majd 2004 ben állt elő sajátjával. Az óriásvállalat 2009 ben indította útjára megújított keresőjét a Bing-et. 2.3.2. Vertikális keresés A történeti áttekintésben sorra vett keresőrendszerek többsége abból a célból született, hogy az interneten teljes tartalmán biztosítson hatékony keresést. Egy ilyen általános célú kereső sok esetben nem működik hatékonyan, nem ad releváns találatokat. Például, ha csak valamely tudományterület anyagai között szeretnénk keresést végezni, akkor egy általános felhasználású kereső, sok olyan találatot adhat, melyek nem relevánsak. Erre a problémára adott válasza a kor informatikusainak a vertikális keresés módszerének bevezetése. Vertikális keresésről beszélünk akkor, ha a keresés az internet egy szeletén, vagy valamilyen kritérium mentén szűkített dokumentumhalmazon történik. Ez a kritérium leggyakrabban egy témakör, de lehet fájlformátum, dokumentumtípus, stb. is. Napjainkban egyre több vertikális kereső szolgáltatás jelenik meg a weben: Google Books - digitalizált könyvek tartalmában való keresés Google Scholar - tudományos cikkek közötti keresés Árukereső - kereskedelmi termékek közti kereső Budapest Explorer - szórakozóhely kereső 17

Használtautó.hu - használt autók keresője Kayak.com - utazás kereső HealthMash - egészségügyi kereső 2.4. Nyelvi eszközök keresőrendszerekben Ahogy azt a 2.2.2 részben is írtam, nyelvi eszközök informatikai alkalmazások számos területén jól használhatók. Most szeretnék rövid áttekintést adni arról, hogy melyek azok a módszerek, amelyek leggyakrabban megjelennek egy-egy keresőrendszerben. Mint azt láthattuk az internet hőskorában a keresők sokszor csak a fájlok címében, esetleg a hozzájuk kapcsolt metaadatok között tudtak keresni. A WebCrawler óta már a fájlok tartalmát is látjuk. Ez a korábbiakhoz képest nagy előrelépés, de egy átlagos felhasználónak még mindig nehéz dolga akad, egy olyan csekély tudású rendszerben, ami esetleg csak string-egyezőség alapján ad találatokat. Gondoljunk bele, sokszor mennyire nehéz jó keresőkifejezést találni, hogy az eredmények közt szerepeljen a kívánt információ. Ráadásul számos agglutináló 12 nyelv esetén a feladat még nehezebb, mert ekkor nem elég megtalálni a használandó kulcsszavakat, de a keresést úgy érdemes futtatni, hogy azok toldalékolt alakjaira is rábukkanhassunk. Ezt feladatot szokás szótövezéssel megoldani, mégpedig a következő módon: indexeléskor a rendszer a szavakat, kifejezéseket tövezett alakban tárolja, majd kereséskor a kifejezésben is megkeresi a szavak tövét, végül az így kapott kulcsszavakkal történik a keresés az új indexen. Hasznos funkció még, hogy ha a keresőrendszer - a felhasználó kérésére - lehetőséget biztosít szinonimák keresésére is. Ez a gyakorlatban azt jelenti, hogy a lekérdezés futtatásakor megadott keresőkifejezésben, a megjelölt szavak szinonimáit tartalmazó dokumentumok is megjelenhetnek a találati listában. Angol nyelvterületeken jelentős eredményeket[2] értek még el szókapcsolatok statisztikai felismerésének használatával. A módszer általában a következő: a dokumentumtár dokumentumait megvizsgálva kigyűjtjük azon szó-párakat, melyek nem tartalmaznak tiltólistás szót, majd a leggyakoribbakat felhasználjuk indexelésre is. Így tároljuk azokat a kifejezéseket, melyekről azt feltételezhetjük, hogy kereséskor gyakran előfordulnak, ezzel segítve a nagyobb találati pontosságot. Ezen módszernél az igazi nehézség az, hogy tudnunk kell kezelni, megkülönböztetni olyan keresőkifejezéseket, melyek a szóösszetétel egészére vonatkoznak, csak egy elemére, vagy egyikre sem. Például a Nobel-díj 12 toldalékokat halmozó 18

kifejezés esetén, mind a Nobel, mind a díj, mind pedig a Nobel-díj keresőkifejezéseket jónak gondoljuk, míg a New York városnév esetén, csak a New York -ot egyben tartalmazó kifejezésekre szeretnék, ha megjelenne a találatok között az eredeti összetételt tartalmazó dokumentum. Számos nyelv, köztük a magyar is, képes összetett szavak képzésére. Ezeket megfigyelve felmerülhet a kérdés, hogy vajon az összetételek szétválasztásával és egyenkénti tárolásával lehetséges-e növelni a találati pontosságot. A válasz itt sem egyértelmű, hiszen szétválasztással az eredeti szó értelme elveszhet, jelentősen módosulhat. Egyszerű és nem is kifejezetten NLP technika, de gyakran alkalmazott módszer, hogy betűszavak és rövidítések felismerésére tesznek kísérletet. Ezt általában szótárakkal valósítják meg. Nyilván nehéz általános, teljes szótárakat készíteni, viszont vertikális keresőrendszereknél, ahol szűkebb témájú dokumentumokkal dolgozunk, érhetünk el jobb eredményeket. Jelentés egyértelműsítési módszerek célja, hogy a többértelmű szavak szövegkörnyezetbeni jelentését meghatározzuk, és tároljuk. Keresésnél pedig lehetőséget biztosítsunk az ezek közti választásra. Ezekhez általában ún WordNet 13 -et használnak. Gyakori az is, hogy a lekérdezés elindítás után a rendszer további kapcsolódó kulcsszavakat ajánl fel, melyekkel a találati lista mérete csökkenthető. Ezt általában úgy valósítják meg, hogy az indexelt dokumentumokban leggyakrabban előforduló szókapcsolatokat tárolják, majd kereséskor ezt használják fel a javaslatokhoz. Manapság egyre inkább előtérbe kerülnek, olyan technológiák, melyek az indexelt dokumentumokhoz, automatikusan metainformációkat rendelnek. Leggyakrabban a következő tulajdonságokat használják: helyszín, időpont, valamilyen mennyiség (ár, súly mérték, hossz mérték). Ezen mezők tárolásával kereshetővé válnak az említett tulajdonságok, ami ismét csak egy pontosabb találati listához vezethet. Mostanában előtérbe kerültek olyan szolgáltatások, melyek nyelvfüggetlenül tudnak keresést végezni. Ekkor szükséges, hogy a rendszer többféle nyelvű dokumentumokat is indexeljen. Egy ilyen alkalmazás a következő módon működhet: 1. indexeléskor minden fájlhoz tárolják annak nyelvét (nyelveit) 2. keresőkifejezés fordítása több nyelvre 3. keresés futtatása az összes dokumentumon 4. találati lista dokumentumainak forrásnyelvre való fordítása 13 Főneveket, igéket, mellékneveket és határozószókat szervez kognitív szinonima halmazokba (synsetek), amelyeknek mindegyike eltérő fogalmat fejez ki. 19

Ilyen például a Google valamint a Webfordítás. Talán a legösszetettebb szolgáltatást azok a keresők nyújtják, melyek a felhasználó áltat megfogalmazott kérdésekre próbálnak választ találni az eredményhalmaz generálásakor. Ez a feladat igen bonyolult, hiszen nem elég a kérdésben megtalálni a kulcsszavakat, a kérdést meg kell érteni a gépnek, hogy válaszolni tudjon rá. Erre tett kísérletet például a Powerset kereső, mely tudásbázisként az angol nyelvű Wikipédia anyagát használja. 20

3. fejezet A megfelelő keresőrendszer választása A dolgozat megírásával, célom annak megvizsgálása volt, hogy milyen lehetőségek vannak nyelvi eszközök használatára keresőrendszerekben. Ennek gyakorlati aspektusait is szerettem volna megtapasztalni, ezért munkám végén tervem, hogy egy kész rendszeren méréseket végezzek az eszközök hatékonyságát illetően. A gyakorlati oldalt illetően alapvetően három út állt előttem: Közismert keresőrendszer felhasználása, kiegészítése. Pl.: Google, Bing... Nyílt forráskódú keresőrendszer kiegészítése. Saját rendszer fejlesztése az alapoktól. Egy teljesen új rendszer fejlesztése túlmutatna e dolgozat céljain, lehetőségein. Közismert kereső választása és felhasználása nehéz feladat, mert ezek a rendszerek a legtöbb esetben zárt forráskódúak és alkalmazás-programozási felületük is nagyon korlátozott. Így úgy döntöttem, hogy a nyílt forráskódú rendszerek felé fordulok. 3.1. Szempontok Mielőtt elkezdtem a volna a keresők közötti böngészést és azok tanulmányozását, megfogalmaztam néhány olyan szempontot, melyekről azt gondolom, szükségesek ahhoz, hogy munkámban bármiféle sikert is érjek el. A használandó alkalmazás C++ vagy JAVA nyelven íródjon mivel ezekben szereztem az elmúlt években jártasságot, és a dolgozat készítése során sokkal inkább a 21

feladatra, mint egy új nyelv elsajátítására szerettem volna koncentrálni. Ezt a szempontot erősítette az is, hogy a MorphoLogictól kapott nyelvi eszközök is C nyelvű API 1 -val rendelkeznek. Szerettem volna, ha a keresőrendszernek van egy jól meghatározott alkalmazásprogramozási felülete, hogy a fejlesztés során megjelenő esetleges új verziók ne akadályozzák a munkámat. Azért is tartom lényegesnek ezt a kérdést, mert ennek hiánya esetén a kód bővítése nehézkes, a vártnál sokkal több időt igényelhet. Elvártam a programtól, hogy létezzen stabil verziója, és legyen mögötte egy olyan fejlesztői csoport, akik folyamatosan karbantartják. Előnyt élveztek a kiválasztás során azok a programok, melyek már rendelkeztek valamilyen természetes nyelvi feldolgozó eszközzel. Úgy gondolom, hogyha egy keresőben például már van szótövező, akkor egy új tövező integrálásához a létező rendszer implementációja alapján találok útmutatást. A fejlesztéshez szükséges, hogy a projekt jól dokumentált legyen. Fontos, hogy a kiválasztott rendszer jól kezelje a magyar nyelven írott szövegeket, ehhez pedig az szükséges, hogy tudjon kezelni az alábbi karakterkódolások közül legalább egyet: UTF valamelyik típusa, elsősorban UTF-8 ISO 8859-2 WINDOWS CP-1250 3.2. Vizsgált keresőrendszerek Munkám során igyekeztem a lehető legtöbb rendszert górcső alá vetni. Ezek felkutatásához elsősorban az alábbi dokumentumokat vettem alapul: Emmanuel Eckard és Jean-Cédric Chappelierés - Free Software for research in Information Retrieval and Textual Clustering[4] Christian Middleton és Ricardo Baeza-Yates - A Comparison of Open Source Search Engines[9] 1 Application Programming Interface - Alkalmazás-programozási felület 22

3.2.1. OpenFTS Az OpenFTS 2 fejlesztését már 5 éve leállították, továbbá a felhasználói fórumon kívül nem sok dokumentációt találtam. Egységes programozói felületet sem találtam az eszközhöz, így mindezek tekintetében nem is folytattam a vizsgálatot. 3.2.2. Terrier Ez az keresőrendszer JAVA nyelven íródott, bővíthetőségét biztosíték a jól dokumentált API. A programozási nyelv garantálja az UTF-8 támogatást, tehát a magyar nyelvi szövegek kezelésével sincs probléma. Indexelés folyamán a rendszer egy ún. pipeline 3 -on keresztül dolgozza fel az indexelendő kifejezéseket. Fejlesztése folyamatos, a támogatás biztosított. Szótövező használatára - az említett csővezeték kialakítás miatt - ad lehetőséget, de más nyelvi modulokat nem használ. 3.2.3. Lucene Lucene egy teljes értékű kereső, mely JAVA nyelven íródott. A Terrierhez hasonlóan a magyar nyelv írásjeleit is tökéletesen kezeli. Jól dokumentált alkalmazás-programozási felülettel rendelkezik. Legfőbb erőssége, hogy jól skálázható és nagy teljesítményű indexelő program biztosítja az adatok gyors feldolgozását. Képes dátumok szerinti keresésre, mezők kezelésére, egyszerre több indexben való keresésre. Többféle lekérdezés típust támogat. A projekt rendkívül jól támogatott, dokumentált. Nyelvi eszközök kapcsán az mondható el róla, hogy többféle szótövezőt és azok integrálását támogatja. 3.2.4. Datapark Search Engine A Datapark Search egy C nyelven íródott kereső, melynek API-ja csak kis mértékben enged beavatkozni a rendszer működésébe. Ezt is elsősorban olyan esetekben használják, amikor a szoftvert egy komplex programba, vagy weboldalba építik be. Némi dokumentáció is fellelhető a világhálón, de ez korántsem teljes. Több karakterkészletet is támogat, viszont nyelvi eszközökkel csak nehézkesen gyarapítható. Szótövezés csak Aspell illetve 2 Open Source Full Text Search engine 3 csővezeték - mint fogalmat metaforikusan használják a számítástechnikában akkor, amikor több program láncba való összekapcsolása történik. Ilyenkor az egyik elem kimenete a másik elem bemenetére kerül. 23

Ispell programokon keresztül valósítható meg, illetve szinonimák és mozaikszavak felismeréséhez csak szótárfájlok használatával van lehetőség. 3.2.5. Egothor Az Egothor egy 2006 ban készült nagy teljesítményű keresőrendszer. A rendszer motorját újratervezik és újraírják. A projekt dokumentáltsága olyannyira nem kielégítő, hogy nyelvi eszközökről csakúgy mint API-ról említést sem találtam. Így ezt a rendszert is idejekorán elvetettem. 3.2.6. Xapian A Xapian egy olyan eszközkészlet, melyet teljes egészében C++-ban írtak, de használható több más népszerű programozási nyelvvel, úgymint PERL, Python, PHP, JAVA, C#... Egy ráépülő népszerű keresőrendszer az Omega, mellyel együtt számos fájlformátum indexelésére képesek. Továbbá jó néhány integrált nyelvi eszközzel rendelkezik, úgymint pl. szótövező (magyar nyelvű is!), szinonima használat keresés közben. Képes még több adatbázis egyidejű indexként való használatára. A projekt jól dokumentált és folyamatosan karbantartott. Sajnos ennek az API-ját is úgy tervezték, készítették, hogy elsősorban a program beágyazását tegye lehetővé, nem pedig a bővítését. 3.2.7. ht://dig A kereső több alprojektből áll, melyek fejlesztése 2002 ben abbamaradt. A rendszer amúgy angol nyelvű szavak szótövezését és szinonimák használatát is támogatja. Elsősorban Internet oldalak keresésére készítették. Alkalmazás-programozási felületről nem találtam információt. 3.2.8. Lemur/Indri A Lemur eszközkészlet a Carnegie Mellon University és a University of Massachusetts támogatásával készült. Céljuk egy olyan keretrendszer létrehozása volt, mely nyelvmodellezési és adatbányászati kutatásokhoz jól használható. A program C++ nyelven íródott, de rendelkezik JAVA, PHP, és C# API-val is. A projekt több éves múltra tekint vissza, és félévente új kiadásokkal jelentkezik. A Lemur többféle dokumentum típus indexelését támogatja: HTML, XML, PDF, Szöveges fájl, Microsoft Word, Microsoft PowerPoint. Az angol nyelvi szövegeken kívül kínait és arabot is támogat, továbbá beépített angol 24

szótövezővel és mozaikszó felismerővel is rendelkezik. A rendszer a dokumentumok feldolgozását pipeline-szerűen végzi, képes több indexfájl egyidejű használatára. Beépített nyelvi eszközei: angol nyelvű szótövező (2 db), arab nyelvű tövező, betűszó felismerés és stopword 4 támogatás. Az Indri egy olyan keresőrendszer, mely a Lemur eszközkészletére épül. A fentieken kívül fontos tulajdonsága, hogy támogatja az UTF-8 kódolású dokumentumokat is. A kereső rendelkezik még több fajta grafikus felhasználói felülettel. A projekt példákkal illusztrált, jól használható dokumentációval van ellátva. A fentebb részletezett szempontok alapján az Indri keresőrendszer tűnt a legjobb választásnak, így a továbbikban ennek részletes működését vizsgálom meg. 3.3. A Lemur és az Indri működése A fejlesztés fázisa alatt a programcsomag 4.8-as verziója volt elérhető, ezért ezzel foglalkozom 5. A Lemur eszközkészletet abból a célból hozták létre, hogy elősegítse információ visszakeresési (IR 6 ) és nyelvmodellezési feladatok kutatását. A rendszer[7] alapja egy olyan architektúra, mely támogatja a következő technológiákat: ad-hoc és elosztott lekérdezések futtatása nyelvek közötti lekérdezések futtatása strukturált lekérdezések futtatása mező szerinti szűrések használata dokumentum kategorizálás összefoglalás készítés Az Indri eredetileg önálló keresőrendszerként indult, majd az évek során a fejlesztők beolvasztották a Lemur projektbe. Jelenleg az Indri nagy részben a Lemurra épül, bár 4 tiltólistás szavak - olyan szavak halmaza, melyek az indexelés és keresés szempontjából nem rendelkeznek releváns információ tartalommal 5 A dolgozat írása során jelentek meg újabb verziók is. 6 Infomration Retrival 25

nem támogatja, nem használja annak minden funkcióját, de számos új eszközzel egészíti ki. Ezek közül is talán a legfontosabb, hogy képes mezőket és metainformációkat 7 kezelni és UTF-8 kódolással készült dokumentumokat használni. Mint a legtöbb keresőrendszer, az Indri is tartalmaz indexelő, lekérdező és robot alkalmazást. Ezeken kívül számos egyéb kisebb alprogram is a fejlesztők, felhasználók rendelkezésére áll. Az alábbiakban részletesen ismertetem ezek működését, használatukat és ott ahol szükséges az alkalmazás-programozási felületet is. Általánosságban elmondható az Indri alprogramokról, hogy a felhasználóval való kommunikációra paraméter 8 fájlokat használatnak, melyből kinyerik a futáshoz szükséges technikai információkat: mennyi memóriát használhat, dokumentumtár helye, szótövező típusa stb. 3.3.1. Indexelés A Lemur projekt alprogramjai alapvetően két féle index készítésére, használatára képesek. Ezek a következők: KeyFile Index, Indri Index. A két index típus közötti alapvető különbségeket az 3.1 táblázatba gyűjtöttem össze. A projekt több alkalmazást is tartalmaz, melyek az indexelés fázisához kapcsolódnak. BuildIndex A Lemur alapértelmezett indexelő alkalmazása. Egyszerű szöveges fájlok feldolgozására alkalmas. Mezők és metaadatok indexelését nem támogatja. IndriBuildIndex Az Indri alapértelmezett indexkészítő alkalmazása. Az Indri alkalmazás többi alprogramja, csak az ez által készített indexel dolgozik. Az alprogram képes feldolgozni többek közt PDF, DOC, PPT kiterjesztésű fájlokat is. Mezők és metaadatok feldolgozására is fel van készítve. BuildPropIndex Az alprogram egy olyan indexet készít a rendelkezésre álló dokumentumok halmazából, melyben a szavakhoz, termekhez tulajdonságokat, metainformációt is rendelhetünk. BuildDocMgr Dokumentumkezelőt készítő alkalmazás. A gyakorlatban ez azt jelenti, hogy az indexelt dokumentumokat későbbiekben az így készített adatbázison keresztül lehet elérni. 7 A fejlesztők terminológiája szerint a mezők a szövegben fellelhető kiemelt információk, melyeket akár lekérdezések futtatásakor is igénybe vehetünk. Pl.:dátumok, nevek, helyszínek... Míg a metainformációkat tartalmazó mezők, nem biztos, hogy láthatóak a szövegben, nem lehet az indexben tárolni őket mint kereshető adatelemeket, de lekérdezéskor kinyerhetőek az adatbázisból. Pl.: URL, dokumentumsorszám... 8 A paramétere fájlok használatáról bővebb információ: http://www.lemurproject.org/ doxygen/lemur/html/indriparameters.html 26

3.1. táblázat. A Lemur index típusainak összehasonlítása Tulajdonság Keyfile Index Indri Index Tárolható dokumentumformák Az index tárhely használata a dokumentumtár méretéhez képest TREC Text, TREC Web, HTML, Szöveges fájl 1,2x 2x Metaadatok használata igen igen Mezők használata nem igen Létező index bővítése igen, de csak offline, azaz ha éppen nincs használatban TREC Text, TREC Web, HTML, Szöveges fájl, XML, PDF, MBox, Microsoft Word és PowerPoint igen, használat közben is Használható lekérdezőnyelvek InQuery Indri Query Language Helyettesítő karakterek nem igen használata (Pl.: *,?) Indexelő alprogramok BuildIndex IndriBuildIndex, Build- Index Lekérdező alprogramok RetEval IndriRunQuery, RetEval A keresőrendszer bővítése során nyilván szükségem lesz egy indexelő alkalmazásra, és mivel ezt a munkát sem célom az alapoktól kezdeni, ezért közelebbről megvizsgálom a IndriBuildIndex alprogramot. Először vegyük szemügyre, az alprogram API-ját, azt hogy milyen lehetőségeket kínál a fejlesztőknek. Az indexek kezelésére az API-ban az indri::api::indexenvironment osztály szolgál. Ennek műveletei: open(std::string &repositorypath) egy létező index megnyitása create(std::string &repositorypath, IndexStatus *callback) új index készítése addfile(std::string &filename) egy fájl hozzáadása az indexhez (ez a fájl a függvény hívását követően feldolgozásra kerül) addstring(std::string &documentstring, std::string &fileclass, std::vector<indri::parse::metadatapair> &metadata) egy 27

string-ként tárolt dokumentum hozzáadása az indexhez (a dokumentum a függvény hívását követően feldolgozásra kerül) addparseddocument(indri::api::parseddocument *document) egy már feldolgozott dokumentum hozzáadása az indexhez setindexedfields(std::vector<std::string> &fieldnames) az indexelendő mezők beállítását szolgáló függvény Látható, hogy az alkalmazásprogramozási felület nem sok hozzáférést enged az indexelés folyamatának belső történéseihez. Így szükségesnek láttam, hogy a program egyes elemeit módosítva, nagyobb teret kapjak a nyelvi eszközök integrációjához. Ehhez jobban meg kellett ismernem a modul működését. Az IndriBuildIndex alkalmazást futtatva a következő műveletsor fut le: 1. A paraméter fájl beolvasása, feldolgozása. 2. Az index létrehozása, vagy ha már létezik, akkor megnyitása. 3. A dokumentumhalmaz állományainak egyenkénti, pipeline-szerű feldolgozása. (a) Fájl beolvasása. (b) Tokenizer 9 meghívása a beolvasott dokumentumon. (c) Parser 10 meghívása, a tokenekre bontott dokumentumon. (d) Transformation típusú objektumok meghívása az elemzett dokumentumon. Ebben a fázisban hajtódik végre például a szótövezés, dátumfeldolgozás, mezők feldolgozása, tiltólistás szavak elhagyása, stb. 4. A teljesen feldolgozott adathalmaz tárolása az indexben. 5. Index bezárása. A fenitekből az látszik számomra, hogy ha egy új eszközt szeretnék a feldolgozási láncba beilleszteni, akkor, ahhoz a Transformation interfészt kell megvalósítanom, majd beillesztenem az indexelési pipelineba. 9 a bemeneti dokumentumot elemi egységekre ún. tokenekre bontja 10 szintaktikai elemző 28

3.3.2. Lekérdezés Már láttuk az indextípusok összehasonlításánál, hogy több lekérdező alkalmazásunk is van, melyekhez más-más lekérdezőnyelvet használhatunk. Az InQuery nyelvet használó alprogramok a ParseInQueryOp és a StructQueryEval, míg a RetEval és a IndriRun- Query az Indri Query Language-el dolgoznak. Ezeken az alkalmazásokon kívül lekérdezéseket futtathatunk még az alkalmazásprogramozási felületen keresztül és egy démon segítségével is. Mivel az Indri Query Language az InQuery nyelv egy kiterjesztése, így a továbbiakban ezt fogom használni. Most pedig megvizsgálom, milyen képességekkel rendelkezik. Az Indri Query Language egyik előnyös tulajdonsága, hogy automatikusan tövezi a keresőkifejezés szavait, a választott indexnek megfelelően. Ez azt jelenti, hogy ha egy saját szótövezést beépítettem az indexelés folyamatába, akkor az így létrehozott indexen futtatott lekérdezéseket is ez szótövező fogja feldolgozni. Ezzel együtt a lekérdezőnyelv, többféle operátort támogat, melyekkel pontosítható a találati lista. Először is léteznek úgynevezett közelségi operátorok, melyekkel a kifejezésben megadott szavak egymástól számított távolságára 11 adhatunk feltételeket. Pl.: #1(általános célú) a két szó szomszédságára és sorrendjére adott feltétel. Használhatunk olyan kifejezéseket is, mellyel arra utasíthatjuk a lekérdezőprogramot, hogy a paraméterben kapott szavakat, tekintse rokon értelmű szavaknak, továbbá ezek között súlyozást is definiálhatunk.(#syn(...), {...}, <...>, #wsyn(...)) Lekérdezésekben helyettesítő karakterként *-ot használhatunk, melynek operátor párja a #wildcard(...). Mezőkre szűrési lehetőséget is biztosít a nyelv. Ha például indexeléskor használtunk weight típusú mezőt, akkor az olyan dokumentumokat, melyekhez tárolt a rendszer ilyen típusú tulajdonságot, az #any(weight) operátorral tudjuk lekérdezni. Ha a mező értékére is akarunk feltételt adni, arra a. operátort használjuk. Például ha a Erdős Pál dokumentumaira szűrnénk, és indexeléskor az author mezőt is használtuk akkor a #uw1(erdős Pál).author feltétellel tehetjük ezt meg. Úgynevezett számszerű 12 mezőknél még több lehetőségünk van, ekkor ugyanis az értékre nemcsak egyenlőségi feltételt adhatunk, hanem relációs feltételekkel is élhetünk. A numeric típusú mezők egy speciális fajtája használható dátum szűrésére is. Ezeken kívül használhatunk még logikai és súlyozható egyesítő 13 operátorokat, és a dokumentumok közötti szűrésre, prioritások kezelésére is lehetőségünk van. Most pedig nézzük, hogyan történik egy a nyelvben meg- 11 két szó távolsága, úgy kapjuk, hogy ha a köztük lévő szavak számából levonunk egyet 12 az alkotók terminológiájában numeric 13 két keresőkifejezés összeolvasztására szolgál 29

fogalmazott kérés feldolgozása, kiértékelése. A lekérdezés folyamata 8 lépésből áll, melyet a 3.1 ábra[7] szemléltet. 1. Parser 14 objektum létrehozása, mely megkezdni a felhasználó kérésének feldolgozását. Ez a lépés 3 részből áll: lexikális elemző(k) létrehozása, szintaktikus elemző(k) létrehozása, majd ezek egy objektumba zárása. 2. Szintaktikus elemzés: melynek során létrejön a szintaktikus fa. 3. Megszorítás a mezőkre: ha a lekérdezésben valamilyen mező(k)re van hivatkozás, akkor a szintaktikus fa felcímkéződik, így a későbbiekben a kiértékelés folyamán ezek megfelelő pontszámokat 15 kapnak. 4. Azon ún. nyers 16 csúcsok meghatározása a szintaktikus fában, melyek pontozhatóak. 5. Feldolgozatlan csúcsokhoz tartozó kifejezésekből statisztika készítése. 6. Csillapító paraméterek alkalmazása a fára. 7. A már feldolgozott kérés kiértékelés úgy történik, hogy az újonnan kapott fa leveleit átvizsgálva: az ún. Stopwords halmaz elemeit elhagyva, a fa leveleiben található szavakat tövezett formájával történik az indexben található dokumentumokkal való összevetés, majd pedig az eredményhalmaz létrehozása. 8. A találati lista szűkítése és rendezése a pontok alapján. 3.3.3. Egyéb alprogramok Az eszközkészlet számos egyéb alprogramot is tartalmaz. Ezek közül számomra a következők fontosak: Daemon megnyit egy Indri index fájlt, és lekérdezéseket futtató alkalmazások kéréseit szolgálja ki socketen keresztül. JAVA GUI SWING alapú grafikus felület a lekérdező és indexelő alkalmazásokhoz. PHP webes felület PHP4 nyelven íródott grafikus felület, melyen keresztül lekérdezéseket hajthatunk végre. 14 szintaktikai elemző 15 ugyanis a találati lista elemeinek sorrendje a ún. pontok alapján kerül meghatározásra 16 feldolgozatlan 30

JSP webes felület az előzőhöz hasonló JSP technológiát használó webes interfész. 31

3.1. ábra. Indri Query Language egy kifejezésének feldolgozása 32

4. fejezet Nyelvi kereső létrehozása Ebben a részben áttekintem, hogy milyen új funkcionalitásokkal láttam el az Indrit, részletezem megvalósításukat és ezek korlátait. A fejlesztés során, sok esetben olyan döntéshelyzetbe kerültem, amikor több megoldás is jónak látszott, attól függően, hogy milyen korpusszal használjuk az alkalmazást. Ezért úgy döntöttem, hogy egy jól körülhatárolt témakörű szövegeken fogom futtatni az alkalmazást, így tudom majd ahhoz igazítani kiegészítő moduljaim egyes funkcionalitásait. Ezzel egy időben konzulensemtől, Dr. Prószéky Gábortól kaptam egy adatbázist, mely az Országgyűléseken elhangzott beszédeket tartalmazta. További munkáim alapját ez az anyag képezte. 4.1. Szótövező modul Mielőtt részletezném munkám technikai oldalát, kitérnék arra, hogy pontosan mit is jelent egy szó tövét meghatározni[6]. A szótő-előállítás vagy lemmatizálás olyan művelet, mely adott természetes nyelv (lehetőleg) minden szóalakjából előállítja annak egyetlen tövét (szótári alakját, lemmáját). Ily módon a lemmatizálás a nyelv szóalakjait ekvivalenciaosztályokba sorolja, ahol az azonos tőre visszavezető szóalakok tartoznak egy osztályba. Sajnos ez az osztályokba sorolás mégsem tökéletes, különösen a magyar nyelvben, ahol a képzők használata megsokszorozhatja a lehetséges tövek számát. Például az adósság szónál az első szótő a adós lehetne, de fel kell ismernünk, hogy ez is egy képzett alak, így akár az adó vagy az ad is egy-egy szótő lehet. Másrészről az is előfordulhat, hogy egy szó tövei egymástól nagyon eltérő jelentést hordoznak. Ilyenkor az ideális választás igazodik a szövegkörnyezethez. A modern keresőrendszerek szerves részét képezik szótövező algoritmusok, ez ért- 33

hető, hiszen jobban belegondolva, ezek nélkül rengeteg potenciálisan jónak mondható dokumentum kiesne a találati listából. Egy ilyen program létrehozása időigényes, nehéz és mélyebb nyelvészeti ismereteket feltételező feladat. Diplomamunkám célja alapvetően keresőrendszer fejlesztésére irányul, ezért egy nyelvészeti eszközöket tartalmazó modult kértem és kaptam a MorphoLogic Kft.-től. A továbbiakban ennek integrációjának részleteit írom le. 4.1.1. Lemur, Indri Első ötletem az integrációval és a fejlesztéssel kapcsolatban az volt, hogy a Lemur eszközkészletet veszem munkám alapjául, és azt bővítve haladok. Sajnos közelebbről vizsgálva a Lemurt rá kellet ébrednem, hogy bár többnyelvű környezethez fejlesztették mégsem támogatja a magyar nyelv egyes ékezetes magánhangzóinak használatát. Ez abból az egyszerű okból fakad, hogy a program indexelő részének Parser moduljai közt nincs olyan, ami a magyar nyelvvel kompatibilis karakterkódolást támogatna. Így újra kellett gondolnom a tervemet, és végül is az Indri kiegészítése mellett döntöttem. Szerencsére az említett kereső a dokumentumok belső reprezentáláskor az UTF-8 karakter kódolási szabványt használja. 4.1.2. Tövező integrációja A cégtől kapott szótövező az elemezendő karaktersorozatokat mindig valamely Windows kódlap karakterkódolása szerint értelmezik. Ezek közül a magyar írásjeleket tartalmazó a 852-es és 1250-es sorszámú. A 1250-es kódlap használata mellett döntöttem, mivel ez egy modernebb variánsa az 852-esnek. Az integrációhoz szükséges volt, hogy alkalmazzak egy karakterkonverziós lépést, mely az UTF-8 kódolással reprezentált stringeket CP-1250-es reprezentációra alakítja és vissza. Ehhez a konverzióhoz az iconv 1 programkönyvtárat használtam. Mint korábban említettem, az Indri az indexelés folyamatában, a feldolgozandó dokumentumokat egy pipeline szerűen dolgozza fel. Ebben a folyamatban minden feldolgozó objektum a Transformation absztrakt osztály egy példánya. Így elég a 4.1 ábrán látható interfészt megvalósítani. A felsorolt műveletekből egyedül a transform az ami igazán fontos, mert a többi művelet a pipeline elemeinek összekapcsolásáért felelős. Ennek a függvénynek az implementálásval lehet a paraméterként kapott dokumentum szavait egyenként feldolgozni. Az 1 http://www.gnu.org/software/libiconv/ 34

indri::api::transformation +handle(document:parseddocument*): void +sethandler(handler:objecthandler<parseddocument>&): void +-Transformation() +transform(document:parseddocument*): ParsedDocument* 4.1. ábra. A Transformation típus általam megvalósított integráció a következőképen működik: 1. üres 2 term vagy szám esetén továbblép, hiszen ezek nem szavak 2. Humor tövező meghívása az aktuális szóra 3. a szótövezőtől kapott tövek közül az első tárolása(ha létezik) Az Indri és ezzel együtt az általam készített továbbfejlesztése is alkalmas arra, hogy egy szóhoz, több tövet is tároljon. A megfelelő szótő megtalálása, mint korábban írtam, egyáltalán nem egyszerű feladat, és nem is képezi dolgozatom vizsgálódásának tárgyát, ezért szelekció nélkül a lemmatizáló modul által visszaadott első tövet eltároltatom. A másik lehetőségem az lett volna, hogy minden szóhoz az összes szótövet tárolom, ezt viszont azért nem találtam praktikusnak (és vetettem el), mert lekérdezéskor túl nagy zajt okozhat a sok szótő. 4.2. Tiltólistás szavak A legtöbb keresőrendszer az indexelés és lekérdezés folyamán bizonyos szavakat nem indexel, nem vesz figyelembe. Róluk azt mondjuk, hogy a Stopwords halmazba, más néven tiltólistás szavak halmazába tartoznak. Ezek egy adott nyelvben azon leggyakoribb szavak, melyek nem hordoznak jelentős információtartalmat és tipikusan: kötőszavak, névelők, igekötők, határozószavak, névmások. Sok esetben ez a halmaz nem határozható meg egyértelműen, így fontos, hogy az adott célra - különösen vertikális keresés esetén - testreszabjuk, átgondoljuk, hogy mely szavakat szeretnék kihagyni az indexelés, lekérdezés folyamatából. 2 nulla hosszú string 35

4.2.1. Stopword szűrés az Indriben A használt kereső két opciót is kínál a tiltólistás szavak szűrésére. Egyrészt lehetőségünk van az indexeléskor megadott paraméter fájl kiegészítésére, másrészt a feldolgozási lácba fűzhetünk egy saját készítésű Stopper típusú objektumot. Nyilvánvalóan a második opció szabadabb kezet ad a szavak szűrésében, de a legtöbb esetben elég a listás megoldás használata is. 4.2.2. Szavak választása, megvalósítás Mivel adatbázisom témái és nyelvezete elég jellegzetesek, úgy döntöttem, hogy a szövegekben található szavakból gyakorisági statisztikát készítek. Tehát megvizsgáltam, mik a legtöbbször előforduló szavak, és ezek közül kiválasztottam azokat, amik megfelelnek a fent adott definíciónak. Ezekhez még hozzávettem egy az interneten fellelhető 3 általános magyar nyelvű stopword halmazt. Az így kapott szóhalmazt hozzáfűztem az paraméterfájl megfelelő szekciójához. A kiválasztott szavak jegyzéke a függelékben található. 4.3. Dátumok használata 4.3.1. Motiváció Országgyűlési naplókban gyakoriak az utalások különböző eseményekre, dátumokra. Másrészről minden lejegyzés egy adott nap felszólalásait tartalmazza. Látható hogy az egyes dokumentumok több időhöz kapcsolódó információt is hordoznak. Így arra gondoltam, hogy nagy könnyebbség lenne a végfelhasználóknak, ha tudnának a dokumentumok között dátum szerinti kereséseket is végezni. Ugyanakkor tudom azt, hogy dátumokat a magyar nyelvben és különösen írásos szövegekben nagyon sokféleképpen lehet kifejezni. Így célom az volt, hogy készítendő modul működése testreszabható legyen, és a lehető legtöbbféle formában megjelenő egységeket legyen képes felismerni, kereshetővé tenni. 4.3.2. Dátumok kategorizálása Ehhez először megvizsgáltam, hogy milyen típusú dátumok léteznek nyelvi szövegekben. 3 http://snowball.tartarus.org/algorithms/hungarian/stop.txt 36

Pontosság szerint: évszázad pontos, pl.: XX. század, Kr.e. 3. sz. évtized szerint pontos, pl.: kilencvenes évek évre pontos, pl.: 1986 hónap vagy évszak pontos, pl.: 1956 ősze, 1848 márciusa napra pontos, pl.: 2009. szeptember 1. órára, percre, napszakra stb.-re pontos, pl.: 1986. április 30. reggele, 2009.09.01. 12:00 Környezetfüggőség szerint: környezetfüggőnek nevezek olyan dátumokat, melyek csak a szövegkörnyezetükben értelmezhetőek pl.: tegnap, előző héten környezetfüggetlennek nevezek minden olyan dátumot, mely önmagában is egy időpontot jelöl, pl.: 1989, 1986.04.30. 4.3.3. Dátumkezelés az Indriben Az általam használt keresőrendszer rendelkezik dátumok kezelésének képességével. Ez a funkció nem csak az index létrehozásakor elérhető, hanem ahogy arról a 3.3.2 részben is kitértem lekérdezésekkor is kitűnően használható. Indexeléskor a rendszer olyan dátumokat képes tárolni az adatbázisban, amiket a felhasználó a feldolgozandó dokumentumban dátummezőként előre jelzett. Ezek közül is csak azokat dolgozza fel, amik a következő formában vannak megadva: dd month yyyy dd-mon-yy dd-mon-yyyy Month dd yyyy mm/dd/yy mm/dd/yyyy 37

Ahol a(z) dd hónap egy napját jelöli, mely lehet egy vagy két számjegyű. month kisbetűs angolul írt hónapnév. Month nagybetűvel kezdődő angolul írt hónapnév. MON egy hónap angol nevévenk első három betűje. mm egy hónap sorszámát jelöli. yy két jegyű év jelölés, mely 1900-tól kezdődően értelmeződik. yyyy évet jelöl. Ezeket a speciális date típusú fieldeket, a feldolgozási láncban egy Transformation típusú objektum dolgozza fel, mégpedig úgy, hogy minden felismert dátumhoz hozzárendel egy egész számot. Ennek a megfeleltetésnek az alapja 1600 január elseje, aminek az indexben tárolt értéke 0. Minden ettől eltérő dátum az azóta eltelt napok számával kerül tárolásra (negatív értékek is). Dokumentumok közti keresésnél úgy tudunk dátumokra szűrni, hogy ha a lekérdezésbe beillesztjük az alábbi operátorok egyikét: #dateafter(d) D utáni dátumokra illeszkedik #datebefore(d) D előtti dátumokra illeszkedik #datebetween(da DF) DA és DF közé eső (szigorú értelemben) dátumokra illeszkedik #dateequals(d) D dátumra illeszkedik A D, DA és DF paraméterek az indexelésnél említett formában használhatóak. Ezekből látható, hogy a rendszer csak az előre beégetett (angol nyelvterületen használt) dátumformákat képes kezelni. Ezért úgy döntöttem, hogy továbbfejlesztem a rendszert úgy, hogy az a lehető legtöbb formájú dátumot tudja kezelni. 38

4.3.4. Magyar nyelvű dátumok kezelése Úgy gondolom, hogy a dátumok kereshetővé tétele akkor használható egyszerűen, ha nem a felhasználónak kell az indexelendő dokumentumokban egyesével bejelölnie az általa dátumnak gondolt szövegrészeket. Ezért mindenképpen szerettem volna egy olyan eszközt is biztosítani, beépíteni a keresőbe, ami a felhasználó helyett elvégzi ezt a feladatot. Mindezzel együtt, az alábbi két megoldási utat láttam: 1. A szövegfeldolgozási láncba beavatkozva, a szöveg tokenekre bontása előtt feldolgozni és felülírni a dokumentumot reprezentáló objektumot úgy, hogy az összes dátum kerüljön megjelölésre. A dátumok feldolgozását ezután egy általam készített modul végezné, ami az eredetit helyettesíti. 2. A feladat két részre (külön alkalmazásra) bontása. Először a szöveges fájlokat tartalmát módosítanám, majd az előzőekhez hasonlóan a dátumfeldolgozó modult cserélném le. Azt tapasztaltam, hogy az első megoldási út, nem szerencsés, mivel módosítani egy fájl tartalmát, csak a szintaktikus elemző után tudnám. Ez viszont azért problémás, mert az elemző a beolvasás során az egyes termekhez, pozíciókat is rendel, és felülírva a tartalmat, a hivatkozások érvénytelenné válnának. A második út már nehézségek nélkül megvalósítható, viszont itt azzal a kényelmetlenséggel kell számolni, hogy a felhasználónak az indexelés előtt futtatnia kell egy előfeldolgozó programot. Így a második út mellett döntöttem, tehát egy előfeldolgozó programot, és egy dátumfeldolgozó modult készítettem. Figyelembe véve az Indri dátumfeldolgozását a dátumtípusok közül is csak azokkal tudtam foglalkozni, melyek legalább napra pontosak. Azzal a könnyítéssel is éltem még, hogy csak a környezetfüggetlen dátumokkal foglalkoztam, hiszen a környezetfüggőek értelmezése a szöveg mélyebb elemzését igényli. Ez pedig, indexelési időben az Indrivel nem kivitelezhető. A két részfeladatból az első tehát az, hogy az annotáló program a felismert dátumokat a szövegben dátum mezőkké alakítsa. Így például egy elvárt működés, hogy a 2009.10.01.-ből <date>2009.10.01.</date>-t készítsen. Az alkalmazás a dátumformákat egy konfigurációs fájlból 4 olvassa. A megadható dátumformák halmaza, megegyezik az alábbi nyelv elemeivel. (Ahol a Σ ábécé a Unicode karakterkészletnek felel meg.) 4 A konfigurációs fájlról bővebben a függelék megfelelő fejezetében írok. 39

Date Form1 Form2 Form3 Form4 Form5 Form6 Form1 Seps Year Seps Month Seps Day Seps Form2 Seps Year Seps Day Seps Month Seps Form3 Seps Month Seps Year Seps Day Seps Form4 Seps Month Seps Day Seps Year Seps Form5 Seps Day Seps Month Seps Year Seps Form6 Seps Day Seps Year Seps Month Seps Year yyyy yy Month mm m month mon Day ddd Seps Seps Sep Sep Sep Available ε Available Σ \ Reserved Reserved y d m o n t h A program úgy dolgoz fel egy dátumformát, hogy reguláris kifejezéssé alakítja. Az így kapott új kifejezést, pedig már könnyűszerrel használhatjuk a Boost Regex függvénykönyvtárral[1], melynek replace műveletét felhasználva megtörténik a dokumentumszöveg módosítása. Jól látható, hogy a program lényegi része egy leképezés, mely a dátumnyelvből reguláris kifejezést készít. Ez a következőképpen történik. yyyy \d{4} yy \d{2} mm (01;02;03;04;05;06;07;08;09;10;11;12) m (1;2;3;4;5;6;7;8;9;10;11;12) month (január;...;december) mon jan;...;dec dd ((0[1-9]) [12][0-9] 30 31) d (([1-9]) [12][0-9] 30 31) A második program, beépülve az Indri mezőket-feldolgozó folyamatába, dátum fieldeket dolgoz fel. Első lépésként a kapott dátumban megpróbálja meghatározni az év, hónap, nap mezők sorrendjét, ezek után 1600.01.01.-től számított egész számmá alakítja azt. 40

Fontos megjegyezni, hogy nem javasolt az olyan dátumformák megadása a konfigurációs fájlban, melyek a ütközhetnek. Két dátumformát ütközőnek nevezek, ha létezik olyan dátum, mely mindkét formának megfelel. Például: mm/dd/yy, dd/mm/yy és a hozzájuk tartozó dátum: 01/10/09. Ekkor ugyanis nem dönthető el egyértelműen, hogy pontosan milyen időpontot is jelöl a dátum. 4.3.5. A megoldás korlátai Ahogy korábban is írtam környezetfüggő és nem legalább napra pontos dátumokkal nem foglalkoztam. Ezeken kívül a dátumformák toldalékos alakjaival adódhat még problémája a programnak. Ha a megadott forma yyyy. month d. és a dátum 2009. január 11. de a szövegben úgy szerepel mint 2009. január 11-én, akkor a ez indexelő nem dolgozza fel. Ennek kiküszöbölésére két út lehetséges. Az első, hogy a szótövezést előbb használjuk, mint a dátumfelismerést, így minden dátumnak csak az eredeti alakjával kellene foglalkoznunk. Sajnos ez az Indri esetében ez kivitelezhetetlen, ugyanis a feldolgozási láncban a a mezők feldolgozása, megelőzi a szótövezést. A másik járható út az, hogy a felhasználóban tudatosítjuk a rendszer korlátait, és ebben az esetben arra buzdítjuk, hogy egészítse ki a konfigurációs fájlt a példának megfelelő yyyy. month d- formával is. 4.4. Mennyiségek használata A mennyiség egy mérés eredményére vonatkozó kifejezés, mely a dolgok számát, irányát, számosságát határozza meg, vagy dolgok csoportjának, gyűjteményének megnevezést ad a számossága alapján (például tucat). Többnyire a mennyiséget számmal jelöljük (mérőszám), amelyet egy mértékegység követ (ha szükséges), majd ezután megemlítjük magát a dolgot, aminek mennyiségét meghatározzuk. A pontos fogalmazáshoz mindkét részre szükség van. 4.4.1. Motiváció Írásos dokumentumainkban gyakran használunk sokféle mennyiséget, melyek különleges információtartalommal bírnak. Sajnos a legtöbb keresőrendszerben nincs lehetőségünk mennyiségek mentén szűkíteni a találatainkat, mivel az indexelőprogramok gyakran csak egy-egy szó tárolásával foglalkoznak, szókapcsolatok, kifejezések elemzésével már 41

nem. Így fordulhat elő, hogy egy olyan kifejezésnek mint pl.: 1000 euró-nak a valódi jelentése elveszhet, és az indexbe csak mint egy szám és egy szó tárolódik. Ha a dolgozatom témáját tekintem, azaz az országgyűlési naplókat, akkor az figyelhető meg, hogy ezekben a szövegekben gyakran esik szó pénz mennyiségről. Ezen kívül csak elvétve találunk más mennyiséget, úgy mint a hosszmérték. Adódott az ötlet, hogy megvizsgáljam miként lehetséges mennyiségeket kezelni az Indri keresőrendszerben. A vizsgálódásomat az alábbi szempontok mentén végeztem: Lehetséges-e több féle mennyiség kezelése? Ha igen, hogyan? Lehetséges-e a felhasználó által megadott mértékegységek használata, kereshetővé tétele? Használhatunk-e negatív értékeket? Használhatunk-e nem egész értékeket is? Hogyan végezhetünk kereséseket? Lehet-e valamilyen módon mennyiségi összehasonlításokat használni? Azonos mennyiséget jelölő, különböző formában adott mennyiségek kezelhetőek-e egységesen? Pl.: 1000 g = 1 kg? Lehetséges-e betűvel írt mennyiség értékének indexelése? És ha igen, hogyan? Ezek után pedig úgy bővítettem a rendszert, hogy az említett két mennyiségi információt indexelés és keresés során a lehető legjobban kezelje a rendszer. 4.4.2. Mennyiségek indexelése, keresése az Indriben Első megközelítésben azt állapítottam meg, hogy az Indrivel maximum arra van lehetőségem, hogy az összertozó mennyiségi kifejezéseket együtt tároljam. Aztán közelebbről megvizsgálva a rendszert azt láttam, hogy keresővel használhatóak számszerű mezők. Ez pedig a következő módon működik: Az indexeléskor használt paraméterfájlban megadhatjuk, hogy mely mezőket kezelje, ezek számszerűek-e, illetve mely elemző dolgozza fel őket. A dátumokhoz hasonlóan ezek a mezők is előjel nélküli egészként tárolódnak. Így az indexelés folyamán, a már korábban látottakhoz hasonlóan, beiktatható egy újabb saját modul, ami a jelölt mennyiségeket feldolgozza. Kereséshez az alábbi kulcsszavakkal állnak rendelkezésünkre: 42

#less(fieldname value) fieldname mezők értékei közül azokat választja ki, melyek kisebbek value-nál #greater(fieldname value) fieldname mezők értékei közül azokat választja ki, melyek nagyobbak value-nál #between(fieldname value1 value2) fieldname mezők értékei közül azokat választja ki, melyek value1 és value2 között vannak #equals(fieldname value) fieldname mezők értékei közül azokat választja ki, melyek értéke pontosan value 4.4.3. Általános megoldás mennyiségek használatára A numerikus mezők előnyös tulajdonságaira alapozva az alábbi megoldást dolgoztam ki. A megvalósított kiegészítő modul a dátumfelismeréshez hasonlóan, két részből áll. Az első rész, a korábban leírtakhoz nagyon hasonlóan azt hivatott szolgálni, hogy a forrásfájlokban mezőket hozzunk létre, melyek mennyiségeket jelölnek. A fentiekhez képest itt annyival nehezebb a feladat, hogy tudnunk kell különbséget tennünk mértékek között. Ezt úgy sikerült elérnem, hogy a fieldek létrehozásakor, minden mértékhez más-más címkét rendelek. Pl.: súlymérték esetén a konfigurációs fájlban megadott weight címkét rendelek a kg,g,dkg,stb. mértékeggel rendelkező mennyiségekhez, pénzösszegek esetében pedig a deviza kulcsszót használom. A magyar nyelvben a jelzős szerkezeteknek kötött a formája: a jelző megelőzi a jelzett szót. Mivel így tekinthetünk egy mennyiségi kifejezésre is, ezért joggal feltétezhettem, hogy egy mértékegység láttán, az azt megelőző szóval vagy számmal biztosan összetartoznak. Ezeket tudva, az első modul működése odáig egyszerűsödött, hogy elég megtalálni egy mértékegységet jelző szót, és az azt megelőzővel/megelőzőekkel létrehozni egy mezőt. A gyakorlatban azonban ez a módszer messze nem tökéletes, mert előfordulhat - és elő is fordul - olyan szövegkörnyezet, ami például magáról a mértékegységről szól. Ekkor az előtte álló szóval ritkán alkot mennyiségi kifejezést. Pl.: A gramm a súlymérték alapegysége.... az euró bevezetése... Ilyen esetekben a modulom, a mezőhöz extremális értéket rendel, hogy kereséskor minél inkább elkerüljem a rossz találatokat. Egy másik olyan hiba, amivel a program fejlesztése során találkoztam, az hogy az országgyűlési naplókban gyakoriak az olyan pénzösszegeket kifejező mennyiségek, melyekben vegyesen használnak betűvel és számmal írt mennyiséget, pl.: 70 milliárd forint. Felfedezve 43

ezeket a kivételeket javítottam az alprogram működésén, hogy az ilyen kifejezéseket is megtalálja, tárolja. A második modul, mely beépül a szövegfeldolgozási láncba, a mezők feldolgozásáért, reprezentálásáért felelős. Ez mikor végigjárja az indexelendő dokumentum összes mezőjét, csak azokat dolgozza fel, melyek mértékegységet tartalmaznak. Ezeket pedig úgy, hogy a mennyiségeket átváltjuk az SI megfelelőjükre. Nem egészek tárolása - az Indri korlátaiból fakadóan - csak egészként valósíthatóak meg, mégpedig úgy, hogy a tárolható számok mennyiségét csökkentve, helyet nyerve a tizedes jegyeknek. A készített modul egy gyakorlatban is sokat alkalmazható funkcionalitása, hogy képes betűvel írt 5 számok felismerésére, átváltására. Ezt úgy sikerült elérnem, hogy amikor elemzésre kerül a mennyiségi érték, és a modul felismeri hogy nem numerikus alakról van szó, meghív egy szövegfelismerő függvényt. Ez a magyar nyelv sajátosságait kihasználva a számot milliárdos, milliós, ezres, százas illetve tízes egységekre bontja, majd ezeket egyenként kiértékeli és összeadja. 4.4.4. Megoldatlan problémák A modul nem kezel olyan tört számokat, melyek hagyományos tehát nem tizedes alakban fordulnak elő. Ezek indexeléskor kimaradnak az adatbázisból így nem lesznek kereshetőek. Az intervallumként megadott értékeknél a program a várttól eltérően működik. Pl.: 10-20 millárd forintnyi tartozás. A felhasználó jogosan azt várná, hogy pl.: "kevesebb, mint 15 milliárd forint"-szerű lekérdezések esetén a fenti szöveget tartalmazó dokumentum is szerepeljen a találati listában. Ez sajnos nem fog megtörténni, mivel a modul csak az intervallum felső korlátját tekinti, mint értéket és ezt teszi kereshetővé. Egyébként a használt keresőrendszer ettől sokkal többet nem is enged meg, hiszen egy numerikus mezőhöz pontosan egy értéket lehet hozzárendelni. Országgyűlési naplók használata során sok olyan mondatba botlottam, mikor egy-egy felszólaló az euróról vagy más pénznemekről beszél mennyiségi környezet nélkül. Ekkor, a felismerő modul az ilyen környezeteket is megjelöli, viszont feldolgozás során ez a megjelölt környezete értelmezhetetlen lesz. Pl.: az euró. 5 csak magyar nyelven megfogalmazott 44

4.5. Szinonimák használata A szinonímia, azaz rokonértelműség az a jelenség, amikor egy fogalmat több különféle szóval is kifejezhetünk. Szinonimák, vagyis rokon értelműek azok a szavak, amelyek különböző alakúak, de azonos vagy hasonló dolgot jelentenek. 4.5.1. Motiváció Mint azt mindennapi életünkben is tapasztaljuk, mind írásban, mind pedig beszédben igyekszünk elkerülni a szóismétléseket, ehhez pedig a legkézenfekvőbb eszköz a rokon értelmű szavak használata. Parlamenti felszólalások esetén a képviselők talán még nagyobb hangsúlyt fektetnek a szabatos fogalmazásra, így feltételezhetem, hogy ezekben a dokumentumokban az átlagosnál több szinonima használat fordul elő. Dokumentumok közötti keresések esetén, gyakran találkozhatunk azzal a problémával, hogy ha nem tudunk nagyon pontos keresőkifejezést összeállítani, a keresett dokumentumokat nem, vagy csak részben találhatjuk meg. Lássuk hogyan kaphatunk pontosabb találati listát csupán az alaprendszer által biztosított eszközök használatával! 4.5.2. Rokon értelmű szavak használata az Indrivel A használt keresőrendszer lekérdezőnyelve az IndriQuery Language lehetőséget ad, olyan lekérdezések futtatására, melyben megadhatunk szócsoportokat, melyek elemeinek jelentése egyező vagy hasonló. Ennek használatával úgy érhetünk el jobb találati pontosságot, hogy ha keresőkifejezésünkbe a nyelv szintaxisával megadjuk, hogy mely szavak hordoznak hasonló jelentéstartalmat. A következő operátorokat használhatjuk: #syn(...) {...} <...> #wsyn(...) Az első három kifejezés egymással ekvivalens, míg az utolsónál a rokon értelmű szavakhoz súlyokat is rendelhetünk. Pl.: {országgyűlés parlament}, #syn(kutya eb), #wsyn(1.0 országgyűlés 0.8 parlament) 45

4.5.3. Automatikus szinonimahasználat A MorphoLogictól kapott nyelvi eszközök között szerepelt szinonima szótár is, így adva volt a lehetőség hogy ezzel egészítsem ki az Indri funkcionalitását. A szótár alkalmazásprogramozási felülete úgy működik, hogy egy lekérdezéskor, egy szóra az azzal rokonértelmű szavak csoportjával tér vissza. Szerettem volna, hogyha a felhasználónak nem maga kell kitalálnia keresőkifejezésben egy-egy szóhoz a rokonértelmű szavakat, hanem egy speciális karakterrel 6 utasíthatja a keresőt, hogy egy szó szinonimáit is vegye a találatok közé. Ezt úgy valósítottam, meg, hogy beavatkozva a lekérdezési folyamatba, a lekérdezést elő-feldolgozom, és minden egyes jelölt szó helyére beillesztem annak rokon értelmű párjait is. Például a ~parlament kifejezés #syn(parlament országgyűlés országház) alakúra transzformálódik. 4.5.4. A megoldás korlátai Mivel a fenti átalakítás automatikus, így könnyen bekerülhetnek olyan rokon értelmű szavak a keresőkifejezésbe, amik az eredeti jelentéstartalomtól távol állnak, és az így kapott lekérdezésben nagy lesz a zaj. Továbbá az is igaz, hogy bár ezzel a megoldással könnyítünk a felhasználó dolgán, csökkentjük a döntéshelyzetek számát, ugyanakkor egy fontos ponton vonjuk meg tőle a mérlegelés jogát. Egy jól használható megoldás lehetne, hogy ha már a lekérdezőfelületen kiválaszthatná a felhasználó a használandó szinonimákat. Ez funkció nem került megvalósításra a fejlesztés során. 6 ez a karakter a jel lett 46

5. fejezet Az elkészült rendszer értékelése Ebben a fejezetben célom, hogy megvizsgáljam a kiegészített keresőrendszert, és több szempont mentén összehasonlítsam az Indrivel. Nyilvánvalóan nem tudom az összes új modul hatását teljes körűen mérni, mert néhányuk olyan új funkcionalitást ad az eszköznek, melyek nem vagy alig összehasonlíthatóak az eredeti program működésével. 5.1. Teljesítmény Első lépésben azt vizsgáltam meg, hogy a keresőrendszer teljesítménye hogyan változik az általam készített eszközök hatására. Ez három helyen érhető tetten: indexelési idő változása, index méretének változása, keresési idő változása. 5.1.1. Indexelési idő Az indexelési időt úgy mértem, hogy a rendelkezésemre álló dokumentumokat, azok keletkezési éve szerint csoportosítottam, majd ezekre futtattam az alkalmazást. A 5.1 ábrán az látható, hogy egy-egy adathalmaz méretének függvényében, hogyan változott az annak feldolgozásával töltött idő. Ezek alapján megállapítható, hogy a szótövezés jelentősen lassította az indexelés folyamatát. Viszont az is észrevehető, hogy a tiltólistás szavak szűrésével, ez a teljesítménybeli visszaesés mérsékelhető. A fenti tényekre magyarázatot adhat, hogy a szótövezés költséges művelet és a szöveg majdnem minden szavára végrehajtjuk. Azt is meg kell még említeni, hogy az indexelés 47

5.1. ábra. Indexelési idő az adathalmaz méretének függvényében 5.2. ábra. Index mérete az adathalmaz méretének függvényében a keresések előkészítéséül szolgál, és egy dokumentumhalmazra csak egyszer kell lefuttatni. Így az itt vesztett idő a végfelhasználó számára észrevétlen maradhat. 5.1.2. Index mérete Inkrementális indexelést végezve azt vizsgáltam, hogy hogyan változnak a készített indexek méretei, az eszközök használatának, illetve, az adatmennyiség függvényében. Ennek a mérésnek az eredményét szemlélteti a 5.2 ábra. Mint arra számítottam, az index mérete csökkent szótövezés és stopword szűrés esetén. Tiltólistás szavak szűrésének alkalmazásakor, ez annak az egyszerű ténynek a következménye, hogy kevesebb kifejezés kerül az indexbe. Szótövezéskor, pedig egy szó különböző ragozott alakjai ugyanahhoz a kifejezéshez tárolódnak. Az így nyert tárhely- 48

növekedés a program eredeti működéséhez viszonyítva (átlagosan): szótövezéssel 22%, tiltólistás szavak szűrésével 6%, szótövezéssel és tiltólistás szavak szűrésével 28%. Látható, hogy e két egyszerű eszköz használatával érzékelhetően lehet javítani a keresőrendszer tárhely gazdálkodásán. 5.1.3. Lekérdezési idő Azt gondoltam, hogy ahogy csökkent az index mérete, azzal valamilyen arányban csökkenhet egy lekérdezés átlagos ideje. Azzal is számoltam, hogy ez az idő valószínűleg összefüggésben áll a keresőkifejezés hosszával. Ezért az irodalomban leggyakoribb keresőkifejezés hosszakra vizsgáltam azt, hogy hogyan változik a teljesítménye a keresőrendszernek. 5.3. ábra. Lekérdezési idő a keresőkifejezés hosszának függvényében Mérésem eredményei a 5.3 ábrán látható. Amit ezek alapján biztosan állíthatok az az, hogy a szótövezés nem befolyásolta érzékelhetően a lekérdezési időt. Másrészt a két eszköz együttes használata esetén sem mutatható ki egyértelműen javulás vagy romlás. Fontos még megjegyezni, hogy a kapott értékek milliszekundumos nagyságrendűek, így nem zárhatom ki a pontatlanságból fakadó ingadozásokat. 49

5.2. Relevancia 5.2.1. Módszer A relevancia egész általánosan az információ fontossága, jelentősége. Valamivel szűkebb értelemben az adott kérdésre kapott információk meghatározó, lényeges volta. Az adott keresőkérdés vonatkozásában relevánsak a visszakeresett tételek, amelyek objektív értelemben megfelelnek a feltett kérdésnek. [12] Nézzük, hogyan alkalmazhatjuk ezt a fogalmat egy keresőrendszer értékelésénél! A dokumentumtár elemeit, egy lekérdezés eredményére vonatkozóan, négy diszjunkt halmazba oszthatjuk, melyet a 5.1 táblázat szemléltet. 5.1. táblázat. Információ a relevancia szempontjából releváns nem releváns megtalált A B nem megtalált C D Az egyes csoportokat a következőképpen szokás nevezni: A (megtalált releváns elemek) találatok (hits) B (megtalált nem releváns elemek) zaj (noise) C (releváns kihagyott elemek) veszteség (misses, losses) D (nem releváns kihagyott elemek) érdektelen információk 5.1 jelöléseit alkalmazva további fogalmakat definiálhatunk, melyekkel már leírható egy keresés eredményessége. Pontosság 1 Annak számossága, hogy a keresés eredményei között mennyi releváns: Teljesség 2 A / A B A / A C A megtalált és az összes releváns elem mennyiségének hányadosa: Ezekkel a mutatókkal már sok minden kifejezhető, de mivel egymástól nem függetlenek, önmagukban nem adnak egzakt módszert egy keresőrendszer eredményességének 1 angol nyelvű szakirodalomban precision 2 angol nyelvű szakirodalomban recall 50

mérésére. Az is nyilvánvaló, hogy a két mennyiség egymással fordított arányban áll: növelve egy rendszer pontosságát, veszíthetünk a teljességéből, és a teljességet célul tűzve a pontossági érték romolhat. Ezek miatt a két mutató valamilyen kombinációját szokás alkalmazni. A legelterjedtebb mérték az ún. F mérték, mely az alábbi képlettel számolható: F β = (1+β2 ) (P R) (β 2 P +R), ahol P a pontosságot, míg R a teljességet jelöli. A β paraméter a P és az R értékek súlyát határozza meg a súlyozott harmonikus középértékben, és leggyakrabban értékét 1-nek választják. A fentiek jól alkalmazhatóak olyan keresőrendszerekre, amik az eredménylistában nem határoznak meg rangokat 3. Más a helyzet viszont az olyan keresők esetén, ahol az eredménylista az elemekhez rendelt rang alapján rendezett halmaz. Ekkor az F mérték, figyelmen kívül hagyja ezt a rangsorolást. Ennek kiküszöbölésére a kutatók több módszert is javasolnak[16, 8], melyekből az egyik legjobb tulajdonságokkal bíró metrika az ún. Mean Average Precision 4. Ezt a követező módon számolhatjuk: N r=1 (P (r) rel(r)) R, ahol N a találati listában szereplő elemek száma, rel(x) értéke 1, ha az x-edik elem a listában releváns, egyébként 0, P (x) a pontosság a találati lista első x elemére szűkítve, R pedig a tárban található releváns dokumentumok számossága. Már láttuk, hogy egy eredményhalmazt hogyan tudunk értékelni, ha meg tudjuk különböztetni a releváns dokumentumokat a nem relevánsoktól. Arról még nem ejtettem szót, hogy mihez viszonyítva is határozzuk meg egy dokumentum alkalmasságát: a szakirodalomban[8] a relevancia meghatározása mindig az információ igényeknek megfelelően történik. Ez a gyakorlatban azt jelenti, hogy nem a keresőkifejezéshez viszonyítjuk a találatokat, hanem egy előre megfogalmazott kérdéshez (aminek már csak egy reprezentációja a keresőkifejezés). Mindezek alapján a méréshez szükségem van: 1. természetes nyelven megfogalmazott, egzakt információ igényekre, melyek a kereső nyelvén is kifejezhetőek, 2. az igényeknek megfelelő keresőkifejezésekre, 3. jól körülhatárolt dokumentumhalmazra, melyekben az egyes igényeknek megfelelően osztályozva vannak a releváns és nem releváns dokumentumok, 4. metrikára. 3 minden elemet egyformán jónak minősítenek 4 a továbbiakban MAP 51

5.2. táblázat. A továbbfejlesztett rendszer és az Indri eredményességének összehasonlítása a MAP metrika segítségével Indri 54% szótövezéssel 69% szinonimákkal 69% mennyiségfelismeréssel 57% dátumfelismeréssel 59% eszközök együttes 59% használatával 5.2.2. Mérési eredmények A kereső értékelésének vizsgálatához elkészítettem egy jól körülhatárolt dokumentumhalmazt, meghatároztam olyan természetes nyelvi kérdéseket, melyekről azt gondoltam, hogy parlamenti naplókat olvasva választ találok, a kérdéseket többféleképpen kifejeztem az Indri Query Language segítségével (ahol a hozzáadott funkcióktól javulás volt várható javítottam az eredeti kifejezésen), és a kérdéseknek megfelelően osztályoztam a dokumentumokat. A lekérdezésének eredményességét a MAP metrikával vizsgáltam. Lefuttatva és értékelve a kereséseket, majd átlagolva ezek eredményét, a 5.2 táblázatban látható relevancia értékeket kaptam. A mérési eredményeket vizsgálva fontos szem előtt tartani, hogy keresőrendszerek értékelése során különösen a keresőkifejezések létrehozásakor számos olyan döntést hoztam, melyeknél nem állt rendelkezésemre egzakt eszköz a lehetőségek vizsgálatára. Így a mérés eredménye a szubjektivitásból adódóan megfelelő fenntartással kezelendő. Ennek ellenére most megpróbálom ezek mentén értékelni munkámat. A számadatokból első pillantásra az olvasható ki, hogy bár nem sokkal, de mindegyik eszköz képes javítani a találati pontosságon. A mérések során a pontossággal és teljességgel kapcsolatban változó tapasztalatokat szereztem. Sokszor fordult elő az, hogy például szinonimákat használva az eredménylista zaja nőtt, a pontosság helyett. Hasonló tapasztalataim voltak a mennyiség és dátumfelismeréssel, míg a szótövezés szinte mindig növelte az eredményességet. 52

Úgy gondolom, hogy ezeket a negatív kilengéseket számos tényező okozhatta. Szinonimák használata esetén azt tapasztaltam, hogy az olyan keresőszavak használatánál, melyek amúgy is rontottak a pontosságon, hozzávéve annak rokon értelmű párjait katalizáltam ezt a rossz folyamatot. Másrészről hasznos eszköznek bizonyult akkor, amikor köznapi nyelven megfogalmazott kifejezésre alkalmaztam, ugyanis a parlamenti naplókban gyakran találkoztam hivataloskodó szóhasználattal, amit tartalmazó szövegrészeket így el tudtam érni. A mennyiség és dátumfelismeréskor megélt kudarcokat többségében annak tulajdonítom, hogy egy-egy parlamenti napló a méreténél fogva számos témát ölel fel. A rendszer nem képes elkülöníteni ezeket egymástól, így a bennük található mennyiségekre és dátumformákra keresve sokszor inkább csak a zaj növekszik. Ugyanakkor úgy gondolom az sem véletlen, hogy mégis sikerült kimutatható javulást elérni ezek használatával: dátumokat gyakran használunk, és ha rendelkezünk az információ igényhez kapcsolódó időponthoz köthető kiegészítő adatokkal, akkor jelentős javulást érhetünk el. 5.3. Összefoglalás Összességében elmondható, hogy a készített eszközök mind teljesítményben, mind pedig relevancia szempontjából nem rontottak az eredeti kereső működésén. Mindenképpen sikernek könyvelhető el, hogy új, eddig nem használt funkcionalitásokkal gazdagodott az Indri, melyek javíthatnak a lekérdezések eredményességén. Általánosságban még az is elmondható, hogy a modulok helyes használatához, némi szakértelemre és körültekintésre van szükség. Meggondolatlanul alkalmazva őket, jelentősen romolhat a keresőrendszer átlagos relevanciája. 53

Köszönetnyilvánítás Szeretném megköszönni Dr. Prószéky Gábornak a munkám során nyújtott támogatását, a kapott hasznos ötleteket, javaslatokat; a MorphoLogic tulajdonát képező nyelvi elemzőt és az országgyűlési naplók adatbázisát. Köszönettel tartozom még Endrédy Istvánnak, aki a nyelvi eszközök használata során látott el hasznos technikai információkkal. Sokat köszönhetek még David Fishernek, aki a Lemur projekt egyik gazdája, és a keresőrendszer használatával kapcsolatos kérdéseimre mindig készségesen válaszolt. Hálával tartozom még családomnak a dolgozat elkészítése során tanúsított türelmükért. 54

Függelék Tiltólistás szavak jegyzéke a az abban abból ahhoz ahogy ahol akár aki akik akkor alá alapján alatt által általában amely amelyben amelyek amelyekben amelyeket amelyet amelyik amelynek ami amíg amikor amiről amit amolyan annak arra arról át az azért azok azokat azoknak azon azonban azt aztán azután azzal ban bár be belül ben benne bizony bizonyos biztos csak csupán de e ebben ebből eddig egész egészen egy egyéb egyébként egyértelműen egyes egyet egyetlen egyik egyre 55

egyrészt egységes ehhez ekkor el elé elég ellen ellenére elő előbb először előtt előtti első elsősorban emilyen én ennek ennél éppen erre erről és esetén esetleg ez ezek ezeket ezen ezért ezt ezzel fel felé fog fognak gyakorlatilag ha hanem hát helyett hiszem hiszen hogy hogyan hogyha hozzá ide igen így ill illetőleg illetve ilyen ilyenkor inkább is ismét itt jelenlegi jó jobban jól kapcsán kapcsolatban kapcsolatos kell kellene kellett képest keresztül ki kicsit kíván kívül korábban korábbi köszönöm követően között közül különböző le legalább legyen lehet lehetett lehetséges lenne lenni lesz lett maga magát majd már más másik meg még megfelelő mégis mellett mely 56

melyek mert mi miatt miért míg mikor miközben milyen mind minden mindenképpen mindenki mindent mindig minél mint mintegy mintha mit mivel módon most nagy nagyobb nagyon ne néha néhány nekem neki nekünk nélkül nem nemcsak nincs nyilván oda olyan ott ő ők őket ön öné önök össze pedig például persze pontosan rá s sajnos se sem semmi senki sok sokat sokkal során sőt szerint szét szinte szintén szükséges talán te tehát tekintettel teljes tényleg természetesen ti tisztelt tovább továbbá további több túl tűnik úgy ugyan ugyanakkor ugyancsak ugyanis új újabb újra után utána utolsó ügy vagy vagyis vagyok vagyunk vajon valaki valamennyi valami valamilyen valamint 57

való valóban van vannak végre végül vele viszont vissza volna volt voltak voltam voltunk Konfigurációs fájl A konfigurációs fájl DTD specifikációja a következő: <!-- XML --> <!ELEMENT UDML (separators, units, dates)> <!ELEMENT separators (sep+)> <!ELEMENT sep (#PCDATA)> <!ATTLIST sep isdecimal CDATA #REQUIRED> <!ELEMENT units (unit+)> <!ELEMENT unit (#PCDATA)> <!ATTLIST unit type CDATA #REQUIRED> <!ATTLIST unit multiplier CDATA #REQUIRED> <!ELEMENT dates (date+)> <!ELEMENT date (#PCDATA)> A mezők jelentése: separators elválasztókarakterek, az egyes sep mezők elemei azok a karakterek, melyek elválasztják a mennyiséget jelölő kifejezés részeit. Az isdecimal attribútum true értéke esetén pedig a mező értékére tizedes elválasztó karakterként tekint a feldolgozó program. units felismerendő mennyiségek listája unit egy felismerendő mennyiségi tulajdonság egy mértékegysége, például súlymérték estén kg, g. Attribútumai: type a jelölt mennyiségi tulajdonsághoz létrehozandó field neve. Pl.: weight multiplier a mennyiségi tulajdonság SI mértékegységéhez viszonyított szorzó. Pl.: kg esetén 1000. 58

dates a használandó dátumformák listája. Értékei a 4.3.4-ban leírt dátumnyelv elemei. A mérések futtatásához használt konfigurációs fájl: <?xml version="1.0"?> <!DOCTYPE UDML SYSTEM "conf.dtd"> <UDML> <separators> <sep isdecimal="true">,</sep> <sep isdecimal="false">\s</sep> </separators> <units> <unit type="weight" multiplier="1000">kg</unit> <unit type="length" multiplier="1000">km</unit> <unit type="deviza" multiplier="1">forint</unit> <unit type="deviza" multiplier="270">euro </unit> <unit type="deviza" multiplier="270">euró</unit> <unit type="deviza" multiplier="180">dollár</unit> </units> <dates> <date>yyyy. month d.</date> <date>yyyy. month dd.</date> <date>yyyy. month d-</date> <date>yyyy. month dd-</date> <date>yyyy. mon. d.</date> <date>yyyy. mon. dd.</date> <date>yyyy. mon. d-</date> <date>yyyy. mon. dd-</date> <date>yyyy. month d.</date> <date>yyyy.mm.dd.</date> <date>yyyy.mm.d.</date> <date>yyyy.mm.dd</date> <date>yyyy.mm.d</date> </dates> </UDML> 59

Felhasználói dokumentáció A készített program célja, hogy lehetőséget biztosítson strukturált lekérdezések futtatására, egy tetszőlegesen választott magyar nyelvű dokumentumhalmazon. A felhasználónak az Indri képességein túl lehetősége nyílik: magyar nyelvű szövegben való intelligens szótő szerinti keresésre, magyar nyelvű automatikus szinonima használatra, magyar nyelvterületeken szokásos dátumok használatára a dokumentumhalmazban, ezek felismerésére, keresésére, tetszőleges mennyiségi információk használatára a dokumentumhalmazban olyan módon, hogy az a keresés során elérhető összehasonlító operátorokkal is kereshetővé váljon. A kiegészített keresőrendszer több futtatható alprogramból áll, melyekből a legfontosabbak: dátum és mennyiség jelölő előfeldolgozó program, index készítő alkalmazás, webes felület. Az alábbiakban ezek telepítését és használatát tekintem át. Rendszerkövetelmények A készített alkalmazás futtatásához, az alábbi hardver konfiguráció ajánlott: >1000 MHz processzor, >512 RAM, 300 MB szabad tárhely. A működéshez szükséges szoftverkörnyezet a következő 5 : 32 bites Linux operációs rendszer Boost programkönyvtár Regex komponense (1.38<) Apache Tomcat 6.0.20< Sun Java Runtime Environment 1.6< 5 A készített programhoz mellékeltem a MorphoLogic tulajdonát képező morfológiai elemző modul időkorlátos verzióját, mely 2010. december 31.-ig működik. Ha az olvasó az alkalmazást ettől tovább szeretné használni, kérem vegye fel a kapcsolatot a készítő céggel. 60

Telepítés Az alábbi lépéseket követően használhatjuk a programot: 1. Az alkalmazás könyvtárstruktúrájában lévő lib mappát tegyük elérhetővé a PATH rendszerváltozóban. 2. Telepítsük a Tomcat webszervert. 3. A web mappában található war kiterjesztésű fájlt adjuk hozzá a Tomcat szerver alkalmazásaihoz. 4. A Tomcat alkalmazás META-INF könyvtárának context.xml fájljában állítsuk be az alábbi paraméterek értékét 6 : index.indri.stemmed szótövezést használó index elérési útja, index.indri.plain eszközöket nélkülöző index elérési útja, index.indri.stemmedstopped szótövezést és tiltólistás szavak szűrését használó index elérési útja, index.indri.stopped csak tiltólistás szavak szűrését használó index elérési útja. 5. Helyezzük a conf.xml, conf.dtd fájlt és a lex könyvtárat a Tomcat futtatási könyvtárába! Előfeldolgozó Az előfeldolgozó programot a bin mappa fieldannotator alkalmazásával indíthatjuk el. Használat a következő: fieldannotator <fromfile> <tofile>, ahol a fromfile a feldolgozandó fájlt jelöli a tofile pedig a létrehozandó új fájlt. A program futtatásához szükséges, hogy korábban említett conf.xml elérhető legyen a futtató környezetéből Ebben a konfigurációs fájlban 7 adhatjuk meg, hogy milyen dátumformákkal és mennyiség típusokkal szeretnénk a keresőrendszert használni. Egy minta fájl található az examples mappában. 6 A program mellékleteként az env könyvtárban megtalálhatóak az általam használt indexek is. 7 Használatához lásd a Konfigurációs fájl alrészt 61

Indexelő alkalmazás Indexelő alkalmazásként az Indri BuildIndex alprogramja használandó. Ennek a futtatásához is szükséges a conf.xml fájl elérhetősége, és fontos, hogy az előfeldolgozáskor és az indexeléskor a konfigurációs fájl tartalma megegyezzen. Az indexelés indítása a buildindex <parameterfile> paranccsal történik. A paraméter fájl formátuma az eredeti rendszer leírásának 8 megfelelő. Ahhoz, hogy a magyar nyelvi eszközöket használhassuk, az alábbi sorokkal kell kiegészíteni azt: magyar nyelvű szótövezéshez <stemmer><name>hunstemmer</name></stemmer> dátumfelismeréshez <field> <name>date</name> <numeric>true</numeric> <parsername>hundatefieldannotator</parsername> </field> mennyiségek felismeréshez a lenti kódsorokat annyiszor ahányféle mennyiséget szeretnénk használni. Az M helyére mindig a mennyiséget jelölő conf.xml-ben is megtalálható kulcsszó írandó. Pl.: Weigl, deviza <field> <name>m</name> <numeric>true</numeric> <parsername>unitfieldannotator</parsername> </field> Egy példa paraméter fájl található az examples könyvtárban. Kereső alkalmazás A Tomcat szerver elindítása és az indexek elérési útjának beállítása után, a localhost:8080/indriweb 9 címre navigálva érhetjük el a webes lekérdező felületet. Ennek formája a 6.1 ábrán látható. 8 http://www.lemurproject.org/doxygen/lemur/html/indriparameters.html 9 a 8080 a Tomcat által használt alapértelmezett port, de ez persze módosítható, és ezzel együtt a hivatkozás is változik 62

6.1. ábra. A keresőrendszer lekérdező felülete. A felhasználói interfész négy részből áll: keresőmező szótövezést választó gomb stopword szűrést választó gomb eredmények A keresőmezőbe begépelve, majd Enter-t ütve indíthatjuk el a keresést. Szinonima használatra a ~ operátorral van lehetőség, mégpedig úgy, hogy ezt a kívánt szó elé írjuk. A lekérdezés a választó gombok által meghatározott indexen fog végrehajtódni. A találati lista első tíz eleme a keresőmező alatt jelenik meg. Fejlesztői dokumentáció A keresőrendszer továbbfejlesztéséhez az alábbi eszközöket használtam fel: GCC 4.4.1 fordító SWIG 1.3.36 Boost 1.38 programkönyvtár Sun JAVA 1.6.15 JDK Eclipse 3.4 (CDT modullal) Iconv 2.10.1 programkönyvtár 63