[ Skip to the content ]

Institute of Formal and Applied Linguistics Wiki

[ Back to the navigation ]

You are here: start » user » zeman » malt-parser

This is an old revision of the document!

Table of Contents

Malt parser

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.

Pokusy s PDT 2.0

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.

Algoritmus Délka trénování Délka parsingu Rychlost parsingu Úspěšnost
nivreeager 24 dní 17 hodin 13 minut (2135575 s) 180062 s (50:01 hodin) 1 věta / 19,4 s 80,73 %
nivrestandard 32 dní 16 hodin 47 minut (2825227 s) 225021 s (62:30 hodin) 1 věta / 24,3 s 79,98 %
covproj 60 dní 15 hodin 28 minut (5239706 s) 348001 s (96:40 hodin) 1 věta / 37,5 s 79,69 %
covnonproj Skončilo restartem fireball6 někdy v lednu nebo únoru 2010. V /tmp bohužel nezůstala po výpočtu žádná stopa.
stackproj 42 dní 12 hodin 55 minut (3675303 s) 183676 s (51:01 hodin) 1 věta / 19,8 s 78,49 %
stacklazy Skončilo chybou Java VM (memcpy) po 36 dnech 14 hodinách 21 minutách
stackeager 39 dní 11 hodin 38 minut (3375472 s) 227927 s (63:19 hodin) 1 věta / 24,6 s 82,93 %

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.

N Délka trénování Délka parsingu Rychlost parsingu Úspěšnost
1000 5 minut 1 hodina 2,5 věty / s 71,49 %
2000 24 minut 5522 s (1,5 hodiny) 1,7 věty / s 75,02 %
5000 4 hod 40 min 9914 s (2 3/4 hod) 0,9 věty / s 77,72 %
10000 22 hod 05 min 21865 s (6 hodin) 0,4 věty / s 79,28 %
20000 53 hod 33 min 47822 s (13 1/4 hodin) 1 věta / 5,2 s 80,71 %
50000 19 dní 1 hod 27 min 76428 s (21 1/4 hodin) 1 věta / 8,2 s 82,76 %
68563 Skončilo restartem sol5 po 36 dnech. V /tmp bohužel nezůstala po výpočtu žádná stopa.

Podívat se na LEMMA místo FORM?

Výpočetní náročnost

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).

orion7

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?

sol5

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

Nastavení od Švédů

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.

N TÚloha Délka trénování PÚloha Délka parsingu Rychlost parsingu Úspěšnost
1000 1 minuta 1248 s = 20:48 min 1 věta / 0,13 s 74,63 %
2000 4 minuty 1885 s = 31:25 min 1 věta / 0,20 s 77,73 %
5000 30 minut 5534 s = 1:32 hod 1 věta / 0,60 s 80,18 %
10000 1:30 hod 7171 s = 2:00 hod 1 věta / 0,77 s 82,11 %
20000 10:09 hod 17139 s = 4:45 hod 1 věta / 1,85 s 83,65 %
25000 984089 12:12 hod 984241 16031 s = 4:27 hod 1 věta / 1,73 s 84,24 %
30000 984090 21:54 hod 984266 19280 s = 5:21 hod 1 věta / 2,08 s 84,54 %
35000 984091 21:09 hod 984242 22018 s = 6:07 hod 1 věta / 2,38 s 84,89 %
40000 984092 spadlo na sdm0.003.libsvm.mod
45000 984093 38:18 hod 1008955 26853 s = 7:28 hod 1 věta / 2,90 s 85,35 %
50000 984030 49:55 hod 984336 37224 s = 10:20 hod 1 věta / 4,02 s 85,47 %
55000 984094 spadlo na sdm0.004.libsvm.mod
60000 984095 spadlo na sdm0.004.libsvm.mod
65000 984096 spadlo na sdm0.004.libsvm.mod
68563 spadlo na sdm0.004.libsvm.mod

Proč trénování větších modelů padá?

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.

Javová implementace libsvm

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. Mně se zatím zdá, že odchylky budou spíše značné, a to v neprospěch javové implementace.

N Úloha Délka trénování Délka parsingu Rychlost parsingu Úspěšnost Poznámka
1000 1011450 37 s Spadlo, kód -1 není v tabulce symbolů.
2000 1011451 2:46 min 661 s = 11 min 1 věta / 0,07 s 74,10 %
5000 1011452 17:45 min 1527 s = 25 min 1 věta / 0,16 s 76,65 %
10000 1011453 Nerozeběhlo se.
20000 1011454
25000 1011455
30000 1011456 Nerozeběhlo se.
35000 1011457
40000 1011458
45000 1011459
50000 1011460
55000 1011461
60000 1011462
65000 1011463

Co dál?

[ Back to the navigation ] [ Back to the content ]