This is an old revision of the document!
Table of Contents
Malt parser
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 | 6:23 h | 5602 s = 1:33 h | 1 věta / 0,60 s | 79,90 % | |
25000 | 1011455 | 10:59 h | 6964 s = 1:56 h | 1 věta / 0,75 s | 80,32 % | |
30000 | 1011456 | Nerozeběhlo se. | ||||
35000 | 1011457 | 22:33 h | 9230 s = 2:34 h | 1 věta / 1,00 s | 81,03 % | |
40000 | 1011458 | 36:36 h | 12484 s = 3:28 h | 1 věta / 1,35 s | 81,17 % | |
45000 | 1011459 | 46:26 h | 13889 s = 3:51 h | 1 věta / 1,50 s | 81,51 % | |
50000 | 1011460 | 58:13 h | 15711 s = 4:22 h | 1 věta / 1,69 s | 81,72 % | |
55000 | 1011461 | 65:48 h | 17031 s = 4:44 h | 1 věta / 1,84 s | 81,83 % | |
60000 | 1011462 | 90:10 h | 18145 s = 5:02 h | 1 věta / 1,96 s | 82,11 % | |
65000 | 1011463 | 89:29 h | 15808 s = 4:23 h | 1 věta / 1,71 s | 82,31 % |
Oprava 6.4.2010
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:
N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Poznámka |
1000 | 1032117 | 2:38 min | 1252 s = 20:52 min | 1 věta / 0,14 s | 74,63 % | 6.4.2010 |
2000 | 1032118 | 8:44 min | 2344 s = 39:03 min | 1 věta / 0,25 s | 77,73 % | 6.4.2010 |
5000 | 1032131, 1032132 | 1631 s = 27:10 min | 1 věta / 0,18 s | 76,65 % | 6.4.2010. Nějak se pustilo dvakrát přes sebe, takže trénink bohužel nemohl zapisovat do souboru s modelem. Nevím, co se stalo. Úspěšnost je tím pádem nesmyslná, protože parsing použil starý model, vyrobený s výchozím popisem rysů. | |
10000 | 1032120 | 3:57 h | 7235 s = 2:01 h | 1 věta / 0,78 s | 82,11 % | 6.4.2010 |
20000 | 1032121 | 16:45 h | 12979 s = 3:36 h | 1 věta / 1,40 s | 83,65 % | 6.-7.4.2010 |
25000 | 1032122 | 27:43 h | 16500 s = 4:35 h | 1 věta / 1,78 s | 84,24 % | 6.-8.4.2010 |
30000 | 1032123 | 47:21 h | 24255 s = 6:44 h | 1 věta / 2,62 s | 84,54 % | 6.-8.4.2010 |
35000 | 1032124 | 6.4.2010 | ||||
40000 | 1032125 | 6.4.2010 | ||||
45000 | 1032126 | 6.4.2010 | ||||
50000 | 1032127 | 6.4.2010 | ||||
55000 | 1032128 | 6.4.2010 | ||||
60000 | 1032129 | 6.4.2010 | ||||
65000 | 1032130 | 6.4.2010 |
Trénovací data rozsekaná na pětitisícové úseky
N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Poznámka |
00000-04999 | 1021425 | 76,65 % | ||||
05000-09999 | 1021426 | 76,99 % | ||||
10000-14999 | 1021427 | 76,47 % | ||||
15000-19999 | 1021428 | 76,72 % | ||||
20000-24999 | 1021429 | 76,72 % | ||||
25000-29999 | 1021430 | 76,80 % | ||||
30000-34999 | 1021431 | 76,87 % | ||||
35000-39999 | 1021432 | 76,94 % | ||||
40000-44999 | 1021433 | 76,72 % | ||||
45000-49999 | 1021434 | 76,98 % | ||||
50000-54999 | 1021435 | 76,69 % | ||||
55000-59999 | 1021436 | 76,96 % | ||||
60000-64999 | 1021437 | 76,81 % | ||||
65000-68562 | 1021438 | 75,86 % |
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 %?
Oprava 6.4.2010
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:
N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Poznámka |
00000-04999 | 1032102 | Nevysvětlitelná náhlá smrt během trénování. | ||||
05000-09999 | 1032103 | 24:24 min | 80,59 % | |||
10000-14999 | 1032104 | 31:56 min | 80,23 % | |||
15000-19999 | 1032116 | 30:27 min | 80,52 % | |||
20000-24999 | 1032106 | 21:35 min | 80,45 % | |||
25000-29999 | 1032107 | Nevysvětlitelná náhlá smrt během trénování. | ||||
30000-34999 | 1032108 | 28:30 min | 80,48 % | |||
35000-39999 | 1032109 | Nevysvětlitelná náhlá smrt během trénování. | ||||
40000-44999 | 1032110 | 19:17 min | 80,51 % | |||
45000-49999 | 1032111 | 22:54 min | 80,62 % | |||
50000-54999 | 1032112 | 22:31 min | 80,58 % | |||
55000-59999 | 1032113 | Nevysvětlitelná náhlá smrt během trénování. | ||||
60000-64999 | 1032114 | Nevysvětlitelná náhlá smrt během trénování. | ||||
65000-68562 | 1032115 | 12:43 min | 79,69 % |
Co dál?
- Pokusy, na kterých céčková verze
libsvm
havarovala, zkusit ještě s javovou verzí. (Již běží.) - 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ístolibsvm
. - 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 skriptuqsub.csh
), s konfigurací Maltu atd. - Vyhodnotit to ještě i na e-testu a připsat to na stránku o českém parsingu.