Egy pszicholingvisztikai indíttatású elemző programhoz kapcsolódó munkák

Egy pszicholingvisztikai indíttatású elemző programhoz kapcsolódó munkák A nyelvtechnológia eszközei 10. Indig Balázs 2016. április 28. Pázmány Péter Katolikus Egyetem Információs Technológiai és Bionikai Kar

Tartalom Kötegelt helyesírás-ellenőrzés YAX (Yet Another XML parser) (Móréh Tamás munkája) Mozaikgramok ami a múltkori előadásból kimaradt VerbIndex (a.k.a. linked resources) GIT (reprezentáció) + GraphViz (vizualizáció) 2/64

Kötegelt helyesírás-ellenőrzés

Tipikus helyesírás-ellenőrző 4/64

A jelenlegi helyesírás-ellenőrző rendszerek Szó alapon működnek (lokális döntések) egybeírást lehet javítani, különírást nem Fix lexikon alapján szólista + morfológia nyílt szóosztályok az ismeretlen szavak hibásnak vannak jelölve Perspektívák az összeakadt ujjakon túl doménre adaptálhatóság nyelvhelyesség-ellenőrzés Cél: az egész szöveg egységként kezelése 5/64

Mi az ami... van? Nagy korpuszok Hagyományos helyesírás-ellenőrző program Szófaji egyértelműsítő (POS-tagger) Lemmatizáló Guesser szükséges? Globális információk alapján döntő eszköz Gépi tanuló algoritmus Jellemzők, amiket figyelnünk kell 6/64

Ötlet Fogunk sok szöveget (pl. könyvet, szakdolgozatot) Leelemezzük a meglevő eszközökkel Többször átolvassuk, kiemeljük az eltérő részeket megjelöljük a hibákat javítjuk automatikusan, amit tudunk Kérdés: honnan tudja a gép, hogy mi a helyes? 7/64

Hogyan javítunk? Az a posteriori információk alapján! a legtöbb ismeretlen szó alanyesetű a többi formájukat egyértelműsíteni kell Így csoportosíthatók lemma alapján és így... kitalálható a ragozási paradigma javítható a szótövesítés javíthatók az elgépelt variánsok a ritka, helyes alakok helyesnek minősíthetők (kevesebb zavaró elem) És ezek csak az ismeretlen szavak! 8/64

Példa Szóalak Frek. stem Obama 40 Obama Obamaáról 1 Obamaá Obamáék 1 Obamá Obamának 3 Obam Obamáról 3 Obam Obamáról 3 Obamá Obamát 5 Obam Obamát 5 Obamát Obamával 1 Obamával Obamához 3 Obamá 9/64

Készen vagyunk? Nem oldjuk meg továbbra sem... az egybeírást pl. az anyagnevekhez finomabb kategóriarendszer kellene a jóra változott alakokat (mellett mellet) a központozási hibákat a nyelvhelyességi hibákat 10/64

Más próbálkozások Szabály alapú nyelvhelyesség-ellenőrzés ritkán alkalmazható (a szabályok merevek) A magyar emberevés közben nem beszél. Tévesztési minták a gyakori elírásokból eddig nem volt hozzá erőforrás A string-távolság súlyozása túl sok hibás ajánlatot hoz be 11/64

Hogy csinálják az emberek? Hatalmas a priori tudással (tapasztalat) Ezt szimuláljuk statisztikával és szabályokkal Sokszori elolvasással Adaptálódnak (pl. új szavak, névelemek) ennek a szimulációját mutattam be Elemzik a szöveget az új ismeretek tükrében Dolgozunk az elemzőn És így is sok hiba marad! 12/64

Helyesírás-ellenőrző-elemző Minden tudásunkat felhasználva Gyakori struktúrák korpuszból kibányászva mozaikgramok Igei vonzatkeretek egyeztetése (MetaMorpho) Szavanként haladva előre próbálunk mintát illeszteni Jelentjük, ha nem találtunk értelmes struktúrát a statisztikai és a szimbolikus elemzés sem ment 13/64

YAX: hatékony, rekordorientált XML-elemzés

Yet Another XML parser Adott az XML mint metanyelv Javából jövő API-val, Pythonban A klasszikus DOM vs. SAX problémát tovább kellene gondolni Megoldás: ElementTree Xpath-ban lehet megszólítani, nem jól illeszkedik a Pythonba Példa: /users/user[login= user1 and (prof= admin or prof= op )] Problémák: futás közben nehéz szerkeszteni a kérést (SQL-re van megoldás) nehezen olvasható (regkif-jellegű, de nincs hibaellenőrzés) sok a hibalehetőség (pár elütéssel mást csinál, vagy hibát ad) (szubjektív álláspont:) nem intuitív 15/64

Yet Another XML parser Megoldás2: BeautifulSoup (TagSoup parser) Nem teljesen erre való: régi hibás XHTML-eket kezel Tagsoup (nem érvényes xml): <p>tag <em> soup </p></em> Manapság ilyenek nincsenek, de az API jó XML-re is Python-közelibb, mint az Xpath Problémák: DOM-alapú! Adott többféle házi formátum, amik között konvertálni kell Az XML jó köztes nyelv, kiterjedt eszközkészlettel rendelkezik Csináljunk olyan elemzőt, ami XML-en keresztül elemez! 16/64

Yet Another XML parser Specifikáció: Adott egy nem igazán konvencionális XML-fájl minden szó egy sor, elemzések TAB-bal vananak elválasztva mondatok, paragrafusok XML-taggel vannak jelölve metainformációk úgyszintén ja, és kb. 10 GB a mérete... Szeretnénk nem Xpath-szal dolgozni, hanem Pythonosan Lineáris feldolgozás után vissza akarjuk generálni az eredményt Lapos XML fájlról van szó, ami sok rekordot tartalmaz Egy rekord legyen egyszerre a memóriában, a többi eldobható A szülőket azért szeretnénk ismerni 17/64

Yet Another XML parser Megoldás (Önlab keretében): ElementTree, kis kiegészítéssel wrapper Pythonba jobban illő interfésszel XMLPullParser alapvetően SAX stratégiával chunkokat olvas be ami nem kell, törölhető a memóriából efölé kellett egy rendes API, ami megkímél a címkéktől... a részfa már legyen fában (DOM)! rekordokat és mezőket akarunk látni, nem címkéket Szép lekérdező nyelv, jól integrálódik a Pythonba Megeszi a nagy fájlokat is alapból... 18/64

Yet Another XML parser Példák: minden PLANT TAG, ha a text Rose reader.find_as_str("plant",, "Rose") minden TAG, ami "first" NAME-ű CATALOG-ban van reader.find_as_str(parent=("catalog", { NAME : "first"})) minden PLANT TAG, ha a PRICE gyermeke kisebb, mint 5.1 reader.find_as_str("plant", children=cond("price", text=lambda x: float(x[1:]) <5.1)) 19/64

Yet Another XML parser További érdekes kihívások: Tetszőleges XML-ből megállapítani, hogy... hány igazi rekordot tartalmaz? [1, 2] honnan érdemes DOM-szerűen kezelni (rekord szint)? hogyan néz ki egy rekord? A rekordok feldolgozása legyen áttetsző, függetlenül a fájl formátumától (XML-, vagy más formátum-előkonvertálással) méretétől (Big Data, vagy hagyományos módszerek) Dinamikusan fejlődő formátumok esetén is! nyelvtannal leírható (funkcionális) módon... 20/64

Mozaikgramok

Nyelvmodell a.k.a. korpuszminták A nyelvmodell válaszol arra a kérdésre, hogy... mi jöhet az adott (n darab) szó után? (n-gram modell) Ritka adattal van dolgunk... (nagy az állapottér) főleg ragozó és szabad szórendű nyelvek esetén A tradicionális nyelvmodellek homogének csak címkét vagy csak szóalakokat alkalmaznak faktoros nyelvmodellek erre több faktort használnak kis n-re csinálnak csak n-gramokat... Korpuszminták elég speciális esetekben léteznek rájuk algoritmusok (Mazsola) 22/64

Nyelvmodell a.k.a. korpuszminták Nekünk gyakori szókapcsolatok/korpuszminták kellenek n-gram, elemei állhatnak szóalakból, szótőből és címkéből később legyen bővíthető! Kombinatorikus robbanást eredményezhet! (Big data) Amit keresünk, az nemcsak az igei szerkezetek (Mazsola) félig kompozícionális szerkezetek nem-kompozícionális szerkezetek, többszavas kifejezések névelemek mintái... hanem minden egyszerre, ami gyakran előfordul! 23/64

Példák Többszavas kifejezések: A kisebbik kormánypárt, Ördög ügyvédje, Éjnek évadján, Hűlt helye volt Szólás-mondás: Hamarabb utolérik..., Itt van a kutya... Udvariassági formulák: Jó [napszak][acc]!, Szia [keresztnév]! Merev szerkezetek: Az országgyűlés a javaslatot [SZN DIGIT][NOM] igennel... elfogadta. Igei szerkezetek: lemma:esik szó [*][DEL] Név + titulus: Orbán Viktor magyar miniszterelnök Névelemek: Petőfi Sándor utcai Általános Iskola 24/64

Nyelvmodell a.k.a. korpuszminták Anélkül, hogy lelőném a poént... Számoljunk... kb. 40.000 szótő minden szótőhöz kb. 100 szóalak (főnév: kb. 1000): 40.000 x 100 a címkék száma: kb. 200 egy elem: kb. 100 bájt = max(len(szóalak), len(szótő),len(címke)) 1-gram: 40.000 x 100 x 200 x 100 = 8 x 10ˆ10 bájt = 80 GB 5-gram: túl sok a világ összes gépének És minket egyszerre érdekel a 2-5-gramig minden... 25/64

Nyelvmodell a.k.a. korpuszminták Anélkül, hogy lelőném a poént... Számoljunk... Hány elemet kellene tárolni az asszociatív tömbben? (8 x 10ˆ10)ˆn darab elemet az n-gram modelhez... Minden elem előfordulhat? Természetesen nem: ezt méri a perplexitás. Mit lehet tudni a görbéről? például érvényes rá a Zipf-eloszlás tehát a gyakori elemek kevesen lesznek! 26/64

Nyelvmodell a.k.a. korpuszminták Anélkül, hogy lelőném a poént..., néhány gondolat: Ha valaki megnézte a Zipf-görbét közelről, akkor láthatja, hogy az nem egy folytonos görbe, és nem lehet könnyen folytonossá tenni... Az asszociatív tömb O(1) elérési idejű, de mennyi a konstans? az elemek számával növekszik... átbukhat az O(n*log(n)) korláton is, amit a szófa ad, sőt még több memóriát is foglal... rosszul skálázódó, globális optimalizálás (lokális növekedéssel) tipikus többet ésszel, mint erővel feladat... (pl. állásinterjú) 27/64

Nyelvmodell a.k.a. korpuszminták Mi a cél? Már elhangzott előadáson... Olyan mondatvázakat keresünk, amik gyakoriak... Elemzéskor egészleges feldolgozás végezhető Olyan szerkezeteket keresünk, amik jól cache -elhetők Egy igeközpontú nyelvtanban ilyenek például az NP-k... Az igék argumentumai nem helyhez kötöttek, de az NP-k belseje igen! 28/64

Zipf-görbe 29/64

Zipf-görbe 30/64

Eszközök Gyors prototípus-építés + Big Data Memóriába nem fér bele, lemezre kell dolgozni Hátha van egy hatékony, használható adatbázis-kezelő Létező nagy n-gram-modell-építő programok Saját program Szempontok: UTF-8, RE, szótártípus, feladatorientált Scriptnyelvek: Perl, Python, Linux Coreutils + AWK Végül: MAWK (egy AWK variáns) a leggyorsabb GNU AWK-nál is, bár kevesebb dolgot tud... Később: C++ és OpenMP 31/64

Sketch Engine 32/64

Módszer Egyszerű generálás: gyors, sok a redundancia Az azonos frekvenciájú esetekből a legkonkrétabbat tartjuk csak meg (zajérzékeny) Manuálisan előszűrjük az unigramokat: a PUNCT címke törlése (különben túl gyakori lesz) ritka szóalakok, szótövek és címkék törlése Minden f frekvenciájú n-gram... legalább f frekvenciájú n k gramokból állhatnak inkrementálisan építhető n=1-től... 33/64

Előzetes eredmények (MNSZ2) Durva minőségbecslés: n-gram alapú nyelvfelismerő érzékeny a túl rövid mondatokra (nem kellenek) érzékeny az idegen szavakra (ritka névelemek) érzékeny a tokenizálási hibákra (erre van szükségünk) eszközök (langid.py, textcat): kb. 30%-on egyeztek meg A korpuszok összetétele nem megfelelő a hosszú, ismétlődő mondatok javarésze: Parlamenti Napló kicsi a korpusz a méréshez A címkézési hibákat felerősítjük Zajérzékeny a rendszerünk 34/64

Példák 35/64

Triviális vs. nem triviális minták Nagyon sok kimenet keletkezik, szűrni kell ezek nagy része érdektelen az ember számára a gépnek viszont minden információ új! Osztályozni kell a mintákat! ehhez szükséges a maximális mintákat megtalálni a részminták nem fontosak, eldobhatók... létező metrikák felhasználásával Nyelvészetileg érdekes ritka minták nincsenek. Talán még nagyobb korpuszban... 36/64

Alkalmazási lehetőségek Elemzőhöz: a szemantikai reprezentáció leírása Hogy dolgozná fel az ember az adott mintát? Nyelvmodellként, deformált szöveg zajszűrésére NP-k belsejének elemzésére Pontosan ismert, hogy mi az NP része és mi nem Egymás melleti NP-k határainak vizsgálatára Szófaji címkék finomításához Sketch Engine alapú keresésekhez ötletek 37/64

Hasonlósági metrikák: a frekvencián túl Tolerancia frekvenciaeltérések esetén (ablak) az alacsony gyakoriságú elemek sokan vannak! C-value: mennyire fontos a minta? a nagyobb egység fontosabb, vagy a részei külön? az eredeti ötletnek minden adatra szüksége van nem alkalmazható közvetlenül A metrikák nem ilyen esetekre lettek kitalálva Nem lehet közvetlenül felhasználni őket 38/64

Hasonlósági metrikák: a frekvencián túl Nagyobb, tisztább korpusz alkalmazása minőségbecsléssel kiszűrni a haszontalan mondatokat hamaraosan teljesen kész a Pázmány korpusz (1,2 milliárd token) Metrikák adaptálása a nagy állapottérhez Peter Hanks: Corpus Pattern Analysis kézzel generált szemantikai, nem lexikalizált minták géppel generálás az ismertetett módszerrel Integrálás az AnaGramma elemzőbe 39/64

VerbIndex a.k.a. Linked Data

VerbIndex a.k.a. Linked Data Adott egy egynyelvű erőforrás (VerbIndex), ami leírja az igéket... osztályhierarchiákba rendezve vonzatkeretek példákkal, szemantikai viszonyok bejelölve kézileg több erőforrással összekötve (FrameNet, PropBank, WordNet) Adott továbbá egy szabály-alapú fordítóprogram (MetaMorpho) amiben le vannak kódolva az igék vonzatkeretei kézzel a szabályoknak van forrásoldala (magyar) és céloldala (angol) Akkor miért ne kapcsoljuk össze őket szó szinten? így átemelhető az összes szemantikai információ magyarra! 41/64

Pattern Dictionary of English Verbs 42/64

MetaMorpho Egy tisztán szabály-alapú fordítórendszer(magyar-angol) a legalaposabb fordítórendszer magyarra több mint 30,000 igei vonzatkeret több mint 17,000 magyar ige Újraíró szabályokkal leírva (két oldaluk van) egy a forrás és egy a cél nyelven Különféle megszorításokkal morfológia, POS szemantika lexikálisan kötött 43/64

Példa: MetaMorpho Minden fiatal tudós ábrándozik a nagy tudományos áttörésről. HU.VP = SUBJ(human=YES) + TV(lex="ábrándozik") + COMPL#1(pos=N, case=del) EN.VP =SUBJ +TV(lex="dream") +COMPL#1(prep="about") Every young scientist dreams about the big scientific breakthrough. 27 bináris szemantikai tulajdonság További 54 morfológiai és egyéb nyelvtani jellemző 44/64

Verb Index 45/64

Módszer 1. Vettük egy egyszerű részhalmaz maximális leképezését Intranzitív, mono- és di-tranzitív igék (98%-os korpuszfedés) Minden lehetséges kombinációban (csak az igéknek kellett egyezni) Minden lehetséges jó leképezést tartalmaz, és jó sok rosszat is... 2. Egymást követő szűrők segítségével tartjuk meg a jó mintákat Leképezés a Magyar WordNet Princeton WordNet irányban A szelekciós megszorításokat ontológiával harmonizáltuk 3. Kézzel ellenőriztük az eredményt Véletlenül választott 200 mintán Három független annotátor segítségével 46/64

Ontológia: konkrét 47/64

VerbIndex a.k.a. Linked Data Problémák A MetaMorpho (MMO) szabályok oldalai aszimmetrikusak Forrásoldalon elemző, céloldalon generáló szabályok A céloldalon kicsi a fedés, mert nem volt cél... A szavak megszorításai eltérnek az erőforrásokban Más jellemzőkészlet írja le a világot: Harmonizálni kell őket! Teljesen más struktúra: VerbIndex-hierarchikus MMO-lista Eltérő jelentések tartozhatnak egy szóhoz (az angolban is) 10000 $ buys a house vs. Andy buys a house walk the dog v.s walk the forest 48/64

VerbIndex a.k.a. Linked Data Problémák (MMO) Változatos argumentumszerkezetek nem azonos az argumentumszám, szórend a két oldal között lexikálisan kötött argumentumok, amiknek nincs megfelelőjük legegyszerűbb: SUBJ V [OBJ] típus, a minták nagy részét fedi ezek könnyen megtalálhatók Néhány jellemző az angol, néhány a magyar oldalon van csak a default értékek nincsenek jelölve A prepozíciók jellemzőként vannak felvéve az elemek alá az angol erőforrásban külön elemet képeznek 49/64

Következtetések MetaMorpho Gépi fordítórendszer, nem általános erőforrás Angol oldalon kicsi a fedés (magyarra optimalizálták) Sok az idiomatikus keret, aminek nincs fordítása A jellemzők nem szigorúan formális alapon születtek Verbnet Rekurzív megszorírások valószínűleg CNF-ben Nincs dokumentáció (főleg a jellemzők leírásánál hiányzik) MetaMorpho WordNet leképezés Kevés a jó kapcsolat Nem elég precíz 50/64

Jövőbeli tervek Mindkét erőforrásban a megtalált hibák javítása További Gold Standard gyártása Új erőforrás készítése magyarra mindkettő jó tulajdonságainak felhasználásával ML-algoritmusok a Gold Standard alapján [3, 4] Párhuzamos korpuszokon keresztüli leképezés elemzők segítségével példa alapú leképezések 51/64

Vizualizáció

Hogyan elemezzünk? Függőségi viszonyokat keresünk (tér1) Balról jobbra egyesével haladva (mindenre emlékezve) (idő) Ige központú elemzés az ige előhozza a vonzatkereteit, és megpróbálja illeszteni őket A főnévi csoportok átláthatósága miatt, nem bináris fa (tér2) pedig egyesével jönnek az elemek! Igazából NP-ket keresünk, az igék argumentumainak Több elemzési ágat is szeretnénk egyszerre fejben tartani (tér3) Hogyan rajzoljuk le az közbülső és a végső eredményeket? 53/64

Vizualizáció Minden dimenziót szigorúan el kell különíteni Meg kell határozni, hogy... miket akarunk látni egyszerre? (és mit nem?) mi számít egy lépésnek? (elemzési lépés, változás a fában) mely objektumok változnak egy lépés során? milyen legyen a végső állapot formátuma? ( színes fák ) Oda-vissza lehessen lépegetni (a visszalépés miatt is!) Memória szempontjából hatékonynak kell maradni! Mély betekintés kell, de a szükségtelen részletek elrejtendők! 54/64

GIT mint adatstruktúra Objektumok Blob (token/frázis) Tree (szülő gyerek irányított kapcsolat) Commit (tranzakció a fában, ami visszaállítható) Tag (elemzési lépés) (Branch elemzési ág) Helytakarékos, irányított fa, mélységi kereséssel bejárható Ismerős lehet még: a Unix fájlrendszer struktúrájaként 55/64

GIT mint adatstruktúra 56/64

GIT mint adatstruktúra Az elv már többszörösen bizonyított A GIT nem csak egy verziókezelő rendszer számtalan alkalmazási területe van, például adatbázisokban az ötlet fájlrendszerekből jön (lásd: Unix fájlrendszer) Ennek ellenére nincs funkcionális adattípus formája Implementálni kell, néhány kiegészítéssel együtt (önlab) A megjelenítés független komponens (GraphViz) A GUI szintén független komponens (Qt: fülekben a nézetek) 60/64

Függőségi változat Akár web alapú megjelenítés CSS-ben 61/64

Fizető-vendéglátás? 62/64

Kérdés, megjegyzés? 63/64

Választható cikkek V. Le and S. Gulwani, Flashextract: A framework for data extraction by examples, SIGPLAN Not., vol. 49, pp. 542 553, June 2014. R. C. Miller and B. A. Myers, Outlier finding: Focusing user attention on possible errors, in Proceedings of the 14th Annual ACM Symposium on User Interface Software and Technology, UIST 01, (New York, NY, USA), pp. 81 90, ACM, 2001. C. Bonial, O. Hargraves, and M. Palmer, Expanding verbnet with sketch engine, in 6th International Conference on Generative Approaches to the Lexicon, p. 44, 2013. J. Utt, A. Lenci, S. Padó, A. Zarcone, et al., The curious case of metonymic verbs: A distributional characterization, in Proceedings of the International Conference on Computational Semantics, 2013. 64/64