http://maltparser.org/

Rychlý úvod do práce s Malt parserem, který tu dřív byl, už neplatí, protože se týkal starého Malt parseru 0.4 (céčková implementace). Nyní už máme 1.3 (javová implementace). Až se to usadí, budou k ní spouštěcí skripty v repozitáři Parsing v SVN.

Malt 1.3. Podle Joakima trénování na celém PDT trvá 3 až 5 dní, a to ještě jen při použití splitting triku (bez něj několik týdnů). Trénování SVM má kvadratickou složitost vzhledem k počtu trénovacích příkladů; těch z PDT vypadnou asi 3 milióny.

Trénování bez “splitting tricku” na celých trénovacích datech.

Trénování na části trénovacích dat (prvních N vět). Testování je vždy na celém dtestu, tedy 9270 vět.

Podívat se na LEMMA místo FORM?

Na jakých strojích to běží (LRC):
(poznámky typu “ale proces zabírá jen” se týkají prosincových trénování se splitting trickem a s Danovým nastavením).

procesor 64bit Intel Xeon 2 GHz
paměť 32 GB, ale proces zabírá jen 2,2 GB
Je to náročné na diskové operace?

procesor 64bit dual core AMD Opteron 2 GHz
paměť 16 GB, ale proces zabírá jen 4,1 GB

26.3.2010 po měsíci další pokus pustit to na datech upravených stejným způsobem a se stejnými rysy jako Joakim a Marco. Zpočátku trénink pouze na 1000 větách. Na cosmosu běží paralelně dvě úlohy, které se liší pouze přidělenou pamětí. První úloha dostala 30 GB (na clusteru rezervováno 50) a využila je. Druhá úloha dostala 180 GB, využila zatím 69, ale už dlouho se na nich drží.

28.3.2010: Zjistil jsem, že při převodu dat do formátu, který měl být shodný s Marcovým, jsem omylem vypustil všechna zalomení vět, tj. soubor obsahoval jednu větu o 16001 slovech, navíc nejednoznačně číslovaných. Tak to už se ani nedivím, že to parseru nedělalo dobře.

foreach i (1000 2000 5000 10000 20000 50000)
  $PARSINGROOT/malt-parser/marco-kuhlmann-czech-settings/conll-pdttags2conll.pl < dtrain-$i.conll > dtrain-$i.conll2009tags.conll
end
foreach i (dtrain dtest)
  $PARSINGROOT/malt-parser/marco-kuhlmann-czech-settings/conll-pdttags2conll.pl < $i.conll > $i.conll2009tags.conll
end
foreach i (25000 30000 35000 40000 45000 55000 60000 65000)
  split_conll.pl < dtrain.conll2009tags.conll -head $i dtrain-$i.conll2009tags.conll /dev/null
end

Učení:

qsub.csh mf=31g $PARSINGROOT/malt-parser/scripts/train.pl '<' dtrain-1000.conll2009tags.conll1 '>' d.pokus1000-30g-clibsvm.mco

Rozbor:

qsub.csh mf=31g $PARSINGROOT/malt-parser/scripts/parse.pl -g d.pokus1000-30g-clibsvm.mco '<' dtest.conll2009tags.conll '>' dtest.malt-pokus1000-30g-clibsvm.conll

Vyhodnocení:

$PARSINGROOT/tools/conll-eval07.pl -g dtest.conll2009tags.conll -s dtest.malt-pokus1000-30g-clibsvm.conll > dtest.malt-pokus1000-30g-clibsvm.eval.txt

Trénování na části trénovacích dat (prvních N vět). Testování je vždy na celém dtestu, tedy 9270 vět.

sdm0.004.libsvm.mod je dílčí model pro hodnotu CPOSTAG číslo 4. Značky jsou číslovány podle pořadí, v jakém se v trénovacích datech objevily. Pokud tedy všechny podmnožiny trénovacích dat, které zkouším, začínají na začátku trénovacích dat, mají číslování značek stejné. Číslování je také možné ověřit tak, že rozbalíme model, vznikne stejnojmenná složka, v ní se pak podíváme do souboru symboltables.sym na část CPOSTAG:

java -jar ~/nastroje/parsery/malt-1.3/malt.jar -c model -m unpack
cd model
less symboltables.sym

Až na jednu výjimku trénování spadlo vždy při budování sdm0.004.libsvm.mod a vždy na větších trénovacích datech. Tento model patří podstatným jménům (přesněji: situacím, kdy na vrcholu zásobníku leží podstatné jméno). Tento model, resp. jeho vstupní data, jsou také zřejmě vždy největší. Není sice asi problém s dostupností operační paměti (svm-train spotřebovává řádově stovky megabajtů, přitom má k dispozici desítky gigabajtů), ale vnitřní struktury libsvm asi na tak velká data nejsou připraveny.

Joakim navrhuje, abychom zkusili dělení zjemnit, např. místo CPOSTAGu dělit modely podle slovního poddruhu (druhá pozice české značky). Pak by dílčí modely byly menší a libsvm by třeba nespadlo. Ve skutečnosti budu asi muset zjemňovat jiným způsobem, protože právě u podstatných jmen žádné zvláštní dělení na poddruhy neexistuje. Mohly by ale pomoct pády.

Předpokládá se, že vyžaduje více času a paměti. Podle dokumentace může dojít i k drobným odchylkám v úspěšnosti způsobeným odlišným zpracováním racionálních čísel.

Všechny díly se nakonec podařilo použít, čímž jsme definitivně vyvrátili, že by v trénovacích datech byla jedna nebo více vět, na kterých parser padá. Padání bylo asi opravdu způsobeno velikostí dílčích modelů v konkrétních případech.

Zarážející je ale úspěšnost. Přinejmenším pro první pětitisícový úsek měla být s céčkovým libsvm 80 %, tak jaktože jsme teď vždy naměřili pod 77 %?

Předcházející pokusy s javovou implementací byly omylem spuštěny s výchozí, nikoli s Marcovou definicí rysů, což by mohlo vysvětlovat tu nižší úspěšnost. Nyní tedy druhý pokus:

• Ještě pustit javovské libsvm a uppsalské dělení (CPOSTAG) na celý treebank. Zatím jsem to udělal nejvýše pro prvních 65000 vět, ale treebank jich má přes 68000.
• Navrhnout jemnější dělení modelů libsvm, aby modely 003 a 004 nebyly tak velké. Např. přidat slovní poddruh a pád.
• Rozsekat trénovací data na 14 pětitisícových kusů a s každým z nich pustit trénink a parsing zvlášť. Spadnou některé? A mimochodem, jakou úspěšnost by dalo hlasování takto natrénovaných kusů?
• Zkusit liblinear místo libsvm.
• Odladit train.pl, aby se výsledný soubor .mco dal rozbalovat. Možná mu vadí pouze “.mco” u volby -c.
• Jestli nakonec nějak prorazím, bude potřeba opět učesat obalovací skripty. Mj. jsem přišel na to, že ve většině svých skriptů používám jako dočasný adresář /tmp místo Milanem důrazně doporučeného /mnt/h/tmp. Např. na tauri10 jsem tak počmáral 4 GB a proces skončil, protože příslušný svazek byl plný. Tohle by se mj. mělo opravit i u skriptů pro Joshuu a dalších. Jinak jsem taky mohutně čachroval s žádostí o příděl paměti na clusteru (týká se i skriptu qsub.csh), s konfigurací Maltu atd.
• Vyhodnotit to ještě i na e-testu a připsat to na stránku o českém parsingu.