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)

szükséges? • Globális információk alapján döntő eszköz • Gépi tanuló algoritmus • Jellemzők, amiket figyelnünk kell

• Lemmatizáló • Guesser

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 Obama Obamaáról Obamáék Obamának Obamáról Obamáról Obamát Obamát Obamával Obamához

Frek. 40 1 1 3 3 3 5 5 1 3

stem Obama Obamaá Obamá Obam Obam Obamá Obam Obamát Obamával 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


• Megoldás2: BeautifulSoup (TagSoup parser) • Nem teljesen erre való: régi hibás XHTML-eket kezel • Tagsoup (nem érvényes xml):
Tag <em> soup
• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


56/64


57/64


58/64


59/64


• 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

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

Recommend Documents