Horváth Andor – Maróthy Szilvia – Simon Eszter

A históriás énekek számítógépes elemzésének módszertani kérdései

A régi magyar költészet egyik legfontosabb műfaja a históriás ének.¹ Ez az aránylag nagy szövegkorpusz – az összes 16. századi magyar versnek több mint 12%-a ide tartozik, a versek sorokban mért terjedelmét nézve pedig több mint a fele – a kevés kortárs irodalomelméleti és esztétikai reflexió szerint is a magyar kora újkor legfontosabb, reprezentatív műfaját képviseli. Kutatásunkban a históriás énekekre jellemző monoton, banálisnak, túl egyszerűnek tekintett verselés pontos jellemzőit keressük, és megvizsgáljuk, egy bő évszázad alatt mennyiben változott, hogyan alakult át a verselés logikája, jellege. Azt vizsgáljuk többet között, mennyire volt elterjedt az önrím, a ragrím, mennyire tiszták a rímek – vagy például a szótagszámok és a sormetszetek szabályosságára milyen mértékben ügyeltek a költők.

Ez az írás a históriás énekkorpusz összeállítására és nyelvi elemzésére fókuszál. A kutatócsoport további tanulmányai a kötetben pedig azt mutatják be, milyen előzetes eredményekkel járt az összeállított korpusz számítógépes metrikai elemzése.

A históriás énekkorpusz összeállítása

A históriás ének elsősorban 16. századi műfaj, a 15. század második feléből 4 ének, a 16. századból 180 ének ismert, a 17. századból mintegy 23 éneket tekinthetünk a műfajhoz tartozónak. Jelenleg a 16. század végéig teljes a kutatócsoportunk által létrehozott énekkorpusz. A kutatási projekt keretében a 17. századi anyagot is fel fogjuk dolgozni.

A 15–16. századi anyagot az RPHA műfaji besorolása szerint gyűjtöttük (azaz: 002 vallásos>história vagy 049 világi>história).² A 17. századi anyag összegyűjtése a releváns szakirodalom alapján történik, elsősorban az RMKT 17. századi sorozatában kiadott históriákat tekinti kiindulásnak.³ Zrínyi Miklós vagy Gyöngyösi István epikus verseit nem vesszük a vizsgált alkotások közé, csak a 16. századi hagyományt tükröző, jórészt profán történelmi témájú verseket. Az OTKA projekt keretében a 17. századi históriás énekek RPHA-szerkezetű leírása is elkészül, így a korpusz szöveg és metaadatok szintjén is együtt elemezhető lesz.

Az így létrejött korpusz számokban: 24 909 strófa, 98 503 sor, 525 695 szó. Összehasonlításként néhány további magyar történeti korpusz adatai (a tanulmány írásának időpontjában):

• Ómagyar Korpusz, http://omagyarkorpusz.nytud.hu, 3,2 millió szövegszó, ebből normalizált 1,3 millió, ebből morfológiailag elemzett 285 ezer szövegszó.

• Történeti Magánéleti Korpusz, http://tmk.nytud.hu/, 1 millió 112 ezer elemzett szövegszó.

• Magyar Történeti Szövegtár, http://clara.nytud.hu/mtsz/, 3 millió szövegszó.

A szövegdigitalizálástól a nyelvi elemzésig

A szövegek forrásául elsősorban a 16. századi RMKT sorozat vonatkozó köteteinek⁴ korábban beszkennelt és online elérhető,⁵ illetve általunk újraszkennelt kötetei szolgáltak, emellett használtunk digitális nyomdai fájlokat (PDF), internetes tudományos igényű szövegkiadásokat, például a Tankönyvtár már nem elérhető Régi magyar irodalmi szöveggyűjteményét⁶ (HTML), kutatói digitális kéziratban lévő modernizált szövegátiratokat⁷ (DOC, DOCX), valamint egyéb forrásokat, pl. folyóiratbeli szövegközléseket.

A szkennelt állomány esetében szövegkinyerésre az Abbyy Finereader 14-es és 15-ös verzióját használtuk. Mivel az online elérhető OCR-ezett PDF-ek minősége igen alacsony volt, az OCR-ezést minden esetben újra elvégeztük (értelemszerűen a nyomdai PDF-eken erre nem volt szükség).

A következő lépés a szövegek gépi és kézi javítása volt. Az automatikus javításokat, szegmentálást (pl. sorszámozás, fejlécek törlése) reguláris kifejezésekkel végeztük. A kézi javítás minden esetben a digitalizált forrással való összeolvasást jelentette, melynek célja elsősorban az értelemzavaró hibák kiszűrése volt. A folyamat kimenete egy egyszerű szöveg (TXT), minimális, Markdown-szerű jelölési eszköztárral, mely tartalmazza a sor és a strófahatár, a fejezethatárok és a hiányok jelölését, valamint a paratextusok elkülönítését a verses szövegrészektől.

A szövegkorpusz modernizált szövegátiratokat tartalmaz. Modernizálásra két okból van szükség: egyrészt a korpusz jelentős része eleve modernizált kiadásban jelent meg az RMKT köteteiben, így a homogén korpusz előállításához mindenhol modernizálni kellett. Másrészt a nyelvi elemző programok a különféle ortográfiájú szövegeket jelentős hibaszázalékkal ismerik csak fel, ill. sok esetben téves eredményeket hoznak. A projektben elsősorban nem olyan jellegű kutatásokat végzünk, ahol az ortográfiai jellegzetességeknek jelentősége lenne (mint pl. egyes stilometriai kutatások esetében). Fontos azonban hangsúlyozni, hogy a munkafolyamat során létrejött különféle szövegátiratokat megtartjuk, azokra a munkafolyamat különböző állomásain szükség van. Az eredeti, kritikai kiadáshoz közel álló szöveg például az RPHA felületén, a versadatlapon jelenik meg, a számítógépes elemzésre szánt szöveg részint nyelvi, részint metrikai annotációt kap.

Automatikus nyelvi elemzés

A nyelvi elemzés minden lépése teljes egészében automatikusan zajlott. Ezek a normalizálás, a morfológiai elemzés és a morfológiai egyértelműsítés voltak.

A helyesírás a források létrejöttének korában távolról sem volt egységes. Ezért van szükség egy ún. normalizálási lépésre, amelynek során az eredeti betűhű szóalakokat mai magyar helyesírású szavakra alakítjuk át. A többféle, különböző nyelvtörténeti szakmai érvekkel alátámasztható lehetséges feldolgozási forgatókönyvek egyik gyakori közös átalakító lépése ez a fajta normalizálás.⁸ A szövegfeldolgozásnak ez a lépése kritikus fontosságú, enélkül ugyanis az automatikus annotáció hatékonysága a következő lépésekben drámaian visszaesik.⁹

Mivel a normalizálás nyelvtörténeti szakértelmet kívánó, rendkívül időigényes manuális munka, megpróbáltuk kiváltani gépi eljárással. A normalizálás nyelvtechnológiai szempontú kutatásának igen gazdag eszköztára van, ám a normalizálási munkák nagy része kézzel írott vagy korpuszból kigyűjtött megfeleltetési szabályok¹⁰ alkalmazásán alapul.

Jelen projektben a Normo eszközt¹¹ használtuk, amely ugyan eredetileg középmagyar bibliafordításokra lett optimalizálva, de egy olyan keretet nyújt, amely további szótárak és szabályok hozzáadásával alkalmassá tehető más történeti szövegek normalizálására is. A Normo eredetileg két modulból áll: egy memóriaalapú modulból és egy szabályalapúból, amely karakter- és tokenszintű környezetfüggő újraíró szabályokat tartalmaz. A nyelvi elemzés fejlesztése és finomítása több fordulóban zajlott, melynek során a memóriaalapú modult végül kikapcsoltuk, és csak szabályokat alkalmaztunk. A szabályokat a korpusz alapján, gyakorisági alapon, kézzel írtuk. A fejlesztés és finomhangolás végén 323 szabály szerepelt a normalizálóban.

A szabályok megfogalmazása során több problémába ütköztünk, melyek a nyelvi feldolgozó láncok, illetve a szabályalapú rendszerek természetéből fakadnak. Az egyik az úgynevezett hólabda effektus, amelynek lényege, hogy az elemzőlánc valamely pontján ejtett hiba továbbgörög, és egyre több és több hibát okoz a lánc későbbi pontjain. Ezért igyekeztünk minden szabályszerű hibázási mintázatot már a normalizálási lépésnél elkapni – így sikerült elérnünk azt, hogy a szövegszavak több mint 95%-ához a rendszer tud morfológiai elemzést rendelni. Egy másik tipikus jelenség, amivel meg kellett küzdenünk, minden nyelvfeldolgozó rendszer tipikus kihívása: a pontosság és a fedés közötti egyensúlyozás. Ezt különösen megnehezítette az a tény, hogy a szövegek különböző forrásokból származnak, amelyek különféle szinten lettek előnormalizálva – a szövegközlő egyéni megközelítése szerint. További súlyosbító tényező, hogy maguk a históriás énekek is különböző területekről származó, gyakran eltérő dialektust beszélő szerzők művei, akiknek szövegei tükrözték a maguk nyelvjárási sajátosságait. A gépi normalizálás során pedig arra kellett törekednünk, hogy az egyes szavakat úgy hozzuk a morfológiai elemző számára értelmezhető formára, hogy közben semmilyen fontos nyelvi vagy metrikai információt ne rontsunk vagy veszítsünk el.

A morfológiai elemzés során minden egyes szövegszóhoz hozzárendelődik a lemmája, a szófajkódja, illetve a szóalkotó szegmentumok listája és a hozzájuk tartozó kódok. Ezekből a kódokból a szónak minden lényeges morfológiai tulajdonsága kiderül. Az automatikus elemzéshez az emMorph¹² elemző ó- és középmagyar nyelvre optimalizált verzióját¹³ használtuk. Az Ómagyar Korpusz¹⁴ építése során fejlesztett változatot vettük alapul, és annak a szótárát és szabályfájljait bővítettük. A morfológiai elemző szótárába 2260 új szó került be, ebből 2226 tulajdonnév.

A morfológiai elemző minden szövegszóhoz megadja az összes lehetséges elemzését. Azt a feladatot, ami során ezek közül kiválasztódik az egyetlen olyan elemzés, ami az adott kontextusban megfelelő, a morfológiai egyértelműsítő végzi. Jelen projektben a PurePos¹⁵ morfológiai egyértelműsítőt használtuk, annak is a Pythonba csomagolt verzióját.¹⁶ A PurePos egy statisztikai alapú rendszer, vagyis azt, hogy a vizsgált szövegszó milyen szófajú, a mögöttes nyelvmodell alapján jósolja meg. A nyelvmodell ebben az esetben az Ómagyar Korpusz morfológiailag elemzett részén lett tanítva, amivel sokkal jobb eredményeket értünk el, mintha egy mai magyar nyelven tanított modellt használtunk volna. A PurePosnak van egy guesser funkciója is, aminek segítségével még az olyan szavakhoz is tudunk tövet és elemzést rendelni, amiket az elemző nem ismer.

Az elemzőlánc egésze

A folyamatábrán látható, hogy az elemzési feladatok egymásra épülnek, de nem láncba, hanem hálózatba szerveződnek. A kutatás elején merült fel a kérdés, hogyan is lehetne megoldani, hogy minden elemzési lépés a szövegek megfelelően feldolgozott változatán fusson le, és az eredménye utólag összefésülhető legyen a hálózat párhuzamos ágainak eredményeivel is. A morfológiai elemzés például szavankénti eredményt ad, s ha a kimenetet akár versenként egy fájlba mentenénk, körülményes feladat volna utólag hibátlanul azonosítani a verssor- és versszak-határokat, majd az információt más információkkal együtt például rímelemzésre felhasználni. A sok külön lépés, sok külön fájl, sok különféle verzió kombinálása helyett érdemesebb minden elemzés eredményét közös struktúrában tárolni.

Erre a feladatra egy összetett verselemző-program készült. Ennek belső neve a munka első fázisában RPHA-emagyar volt, mivel az elemzés elsősorban A régi magyar vers leltárára (RPHA) és az e-magyar¹⁷ elemzőrendszerre támaszkodott. A végleges névadástól eltekintettünk, mert a program jelenlegi változata nem általános elemzési céllal készült, ehelyett kifejezetten a régi magyar históriás énekek vizsgálatához finomítja az elérhető módszereket.

A közös struktúra a POSTDATA projekt JSON-formátumából indult ki.¹⁷ A POSTDATA kutatói azzal a céllal fejlesztették ki ezt a szabványt, hogy az egyre nagyobb számban publikált TEI XML versgyűjteményeket közös, számítógéppel könnyen elemezhető szerkezetre lehessen alakítani. A JSON-formátum nagy előnye, hogy kiválóan megfeleltethető az elterjedt interpreteres programnyelvek, például a Python adatstruktúráinak. Egy JSON-fájl beolvasva hibátlanul átalakítható egyetlen, mélyen strukturált Python-változóvá, és innentől kezdve az adatokat rendkívül egyszerűen el lehet érni.

Átalakítás

Az RPHA-emagyar legelső feladata természetesen, hogy elemzésre alkalmas JSON-formátumra alakítsa a versek szövegét. A versek egyszerű szövegfájlokban vannak. Minden fájl neve a megfelelő RPHA-azonosító. Az RPHA-emagyar, mivel az RPHA adatbázisát is le tudja kérdezni, a könnyebb azonosítás érdekében már átalakításkor letölti a vers címét és a szerző nevét. A JSON-szerkezet létrehozása viszonylag egyszerű, az egyetlen bonyodalmat az okozza, hogy némelyik vers részekre van osztva, és ezeknél a JSON-szerkezet egy szinttel mélyebben tagolt lesz.

A munka során többször is le kellett futtatni az elemzést, esetenként a szövegeken is történtek javítások. Fontos volt, hogy minél kevesebb feladatot kelljen újra meg újra elvégezni, ezért az RPHA-emagyar ilyen egyszerű szövegfájlokból, az RPHA adatbázisban tárolt szövegekből, valamint már elkészült JSON-fájlokból is tud dolgozni. Az elemzés kezdetén mindenesetre szükséges egy vagy több, az alábbi részlethez hasonló JSON-formátumra konvertált versszöveg.

Elemzőmodulok

Az RPHA-emagyar minden elemzési feladat esetében sorban végigmegy a versszakokon. Minden versszak esetében végigmegy az összes verssoron. Minden verssor esetében az összes szón. Minden szinten elvégzi az éppen ott szükséges elemzési lépéseket, majd az eredményeket a megfelelő helyre menti el. Az egyik elemzési modul például a szótagok számát, hosszúságát, hangsúlyát vizsgálja. A hangsúly- és szótaghosszúság-mintákat, valamint az egyes sorok szótagszámát és hangsúlyszámát a verssoroknál tárolja, de a versszak szótagszám-képletét a versszakoknál. A következő példa egy versszak utolsó sorának néhány adatát és a versszak szótagszámát mutatja.

Morfológiai elemzés

Előfordul olyan elemzés, amelynél többször is végig kell menni a versen. A legbonyolultabb modul mindenképpen a morfológiai elemzésé. Először össze kell állítani az elemzendő szavak listáját. A verset alkotó szavak egyesével átfutnak a korábban ismertetett normalizálási lépésen. Amennyiben a normalizált alak eltér a versben rögzítettől, az előbbi bekerül a JSON-struktúrába. A hibajavítást nagyon megkönnyíti, hogy téves elemzés esetén meg lehet vizsgálni, mi történt a szóval az elemzés belső lépései során. A szavak listájába különleges jelölők is bekerülnek a sorok és a versszakok végén.

Az eredményként kapott hosszú listán lefut az emMorph. A program kimenete pontosan ugyanannyi tételből áll, amennyi szó a listán volt. Ezt az adattömeget át kell alakítani a morfológiai egyértelműsítő számára. Ha a morfológiai elemző nem tudta értelmezni valamelyik szót, a program külön listába írja ezt a szóalakot, és számolja az előfordulások számát. Egy másik listában az elemezhetetlen szóalakok sorszámait gyűjti, melyre később lesz szükség.

Az egyértelműsítő a szavak mondatbeli szerepét vizsgálja, és ezért nem szavanként, hanem mondatonként várja az adatokat. Mivel a központozás nyelvi értelmezés nélkül nem jelöli egyértelműen a nyelvtani mondatok határát, az elemzőháló programja egyelőre a versszakhatárt tekinti mondathatárnak. Ezt a funkciót később lehet bizonyos szabályok segítségével finomítani, de az elemzőrendszer így is jó arányban képes volt elemezni a szavakat. A versszakhatárok megállapításánál lényegesek a korábban a listába illesztett jelölők.

Az egyértelműsítő ismét szavanként adja meg a legvalószínűbb elemzést. Azoknál a szóalakoknál, melyeket a morfológiai elemző nem ismert föl, a beépített guesser ad elemzési javaslatot. Az eredményként kapott lista adatait a program eltárolja a JSON-struktúrában. Amikor a lista adott elemének sorszáma rajta van az elemezhetetlen szavak listáján, a program a JSON-struktúrába beírja a guessing tényét is. Egy több szempontból elemzett vers részlete következik:

Fonetikai elemzés és egyebek

Vannak egyszerűbb elemzőmodulok is. A fonetikai átírásra az RPHA-emagyar az Espeak programot használja. Ehhez egyszer pásztázza végig az összes versszak összes sorának összes szavát, mindegyiket átadja az Espeak-nek, és az eredményt a megfelelő mezőben tárolja. Még egyszerűbb a hosszmérő modul, mely a pásztázás során egyszerűen méri a versszakok, sorok, szavak számát, és ezeket az adatokat a JSON-struktúra felső szintjén, tehát a teljes vershez kapcsolódóan menti. A jelenleg automatizált modulok felsorolása az alábbi táblázatban látható. A szempontok felsorolása mellett × jelzi, hogy a fájlszerkezet mely szintjén tárolja a program az elemzési eredményeket. A táblázat alatt a még nem említett három szempont rövid bemutatása következik.

1. További RPHA-adatok letöltése

Ez a modul a vers adatbázis szerinti kezdősorát, verselését, műfaját, az akrosztichonban és a kolofonban található információkat, a szereztetés helyét és idejét, valamint a vers forrásait képes letölteni az RPHA adatbázisból. A modul neve, “pdcdata”, a PDC (Poetry Database Connector) adatbázis-összekötő rendszerre utal. Ez a rendszer is a kutatás részeként készült, s a működését leíró cikk megjelenés alatt áll. A PDC célja az, hogy közös felületen lehessen lekérdezni az európai versadatbázisokat. A rendszer jelenleg két adatbázison működik, és igazán csak az RPHA adatain használható, de már így is sokat segített. A versek csoportosításánál, a hálózatelemzésnél, minták vizsgálatánál számos bonyolult adatbázis-lekérdezésre volt szükség, s a PDC a legtöbb esetben szükségtelenné tette, hogy az RPHA összetettebb, belső, SQL lekérdezőrendszerét használjuk. Az RPHA-emagyar részeként a PDC fő feladata az, hogy a fenti mezőket letöltse az adatbázis megfelelő rekordjaiból, hogy ezeket a JSON-fájlba lehessen illeszteni. Az elemzőrendszer elméletileg általánosabb használatra is alkalmassá tehető, de a PDC révén ez a modul már most is alkalmas lenne.

2. Szavak gyakorisága

Ennek a modulnak az eredményeit jelenleg nem használta a kutatás, mert a Petr Plecháč által készített statisztikai elemzések¹⁹ összetettebb módszertannal vizsgálják az ismétlődéseket. A modul összeszámolja a versben található különböző szavakat, és az ismétlődő szavakat a gyakoriságukkal együtt tárolja a JSON-fájlban.

3. Szótagszám, ritmus

Ezt a modult ismét kifejezetten a magyar nyelv jellemzőihez és a kutatás versátiratainak modernizálási tulajdonságaihoz alkalmazkodva fejlesztettük. A szótagszám megegyezik a magánhangzók számával – ezt több más nyelven, például franciául, nem lehetne ilyen egyszerű szabállyal megoldani. A modul a szótagszám megállapítása után magánhangzóval kezdődő, technikai szótagokra bontja a szöveget (pl. “|el|e|inkr|ől”, “p|éld|át”).

Ha az első szódarabkában nincs magánhangzó (mert a szó mássalhangzóval kezdődött), ezt figyelmen kívül hagyja. Ha hosszú magánhangzót talál, akkor a szótag is hosszú; a továbbiak rövid magánhangzós szótagokra vonatkoznak. Ha a szótag több mint 4 karakter hosszú, vagy több mint 3 karakter hosszú és nem tartalmaz “dzs”-t, akkor hosszú. Ha a szótag kevesebb mint 3 karakter hosszú, akkor rövid. Ha a szótag éppen 3 karakter hosszú, és nem tartalmaz kétbetűs mássalhangzót, akkor hosszú – ha pedig tartalmaz kétbetűs mássalhangzót, akkor rövid.

Szükség esetén a jövőben a modul képessé tehető a hangsúlymintázat elemzésére is.

Konklúzió

Hátránya a munkafolyamatnak, hogy folyamatos finomításokra szorul. A számítógép legföljebb észrevenni képes bizonyos triviális módszertani hibákat, de menet közben képtelen ezeket javítani. Így történhetett meg, hogy a 25 lépésben átdolgozott korpuszt összesen 33-szor elemezte végig a számítógép egy bő év alatt. Ugyanakkor előny is az, hogy a gép képtelen alkalmazkodni, így ugyanis az eredmények és a módszer szoros logikai kapcsolatban állnak egymással, nem fordulhat elő, hogy az egyik modul időnként frappáns és inkonzisztens megoldással javít ki egy-egy problémát. A projekt során tároltuk a szövegek, a program és az elemzések minden változatát, abban a reményben, hogy az esetleg felmerülő kínos kérdésekre választ tudunk majd adni.

Az itt említett eszközök és a korpusz kialakítása egyaránt iteratív folyamat eredménye volt. A digitális feldolgozás előnye, hogy a bemenő adatokat és a módszert folyamatosan lehet finomítani, és a számítógép rövid idő alatt kiadja az eredményt új adatok és szabályok alapján. Az, hogy eltérő nyelvtani szabályok szerint újraelemezzünk egy ekkora szövegmennyiséget, elképzelhetetlen lett volna a számítógép nélkül, hiszen a rendelkezésre álló idő egyetlen kézi elemzéshez is szűkös lett volna.