This is an old revision of the document!
Table of Contents
Malt parser: pokusy s PDT 2.0
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.
Aktualizace květen 2012: Malt Parser 1.7.1 jsem právě rozbalil do /home/zeman/nastroje/parsery/maltparser-1.7.1. Moje staré pokusy s Malt Parserem a PDT 2.0 jsou v /net/work/people/zeman/parsing/projects/maltpdt/uppsala-features.
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.
Celá trénovací data mají 68563 vět. Testování je vždy na celém dtestu, tedy 9270 vět.
Co dál?
- Zjistit úspěšnost na e-testu a publikovat ji na stránce o českém parsingu. A možná tam publikovat i LAS, nejenom UAS.
- Upravit švédskou definici rysů, aby fungovala i s algoritmy
nivrestandard,nivreeager,covprojacovnonproj. Vše vyzkoušet opět na různě velkých trénovacích datech. Nikde není dáno, že právěstacklazymusí být nejúspěšnější algoritmus na PDT. - Odladit
train.pl, aby se výsledný soubor.mcodal 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ář
/tmpmí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.
- Zkusit hlasování pětitisícových kusů.
BEST: Javová implementace libsvm, splitting trick
Vyžaduje více času a paměti než céčková implementace, ale nepadá. 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.
| N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum |
| 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 | 1040063 | 48:07 min | 3956 s = 1:06 h | 1 věta / 0,43 s | 80,18 % | 12.4.2010 |
| 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 | 1035249 | 2 dny 11:08 h | 21468 s = 5:58 h | 1 věta / 2,32 s | 84,89 % | 9.-12.4.2010 |
| 40000 | 1035250 | 3 dny 10 min | 24582 s = 6:50 h | 1 věta / 2,65 s | 85,08 % | 9.-12.4.2010 |
| 45000 | 1035251 | 4 dny 10:53 h | 33744 s = 9:22 h | 1 věta / 3,64 s | 85,35 % | 9.-14.4.2010 |
| 50000 | 1035252 | 5 dní 19:32 h | 37140 s = 10:19 h | 1 věta / 4,01 s | 85,47 % | 9.-15.4.2010 |
| 55000 | 1035258 | 7 dní 8:37 h | 40518 s = 11:15 h | 1 věta / 4,37 s | 85,65 % | 9.-17.4.2010 |
| 60000 | 1035254 | 7 dní 4:55 h | 34374 s = 9:33 h | 1 věta / 3,71 s | 85,80 % | 9.-17.4.2010 |
| 65000 | 1035255 | 5 dní 21:01 h | 31378 s = 8:43 h | 1 věta / 3,38 s | 85,96 % | 9.-15.4.2010 |
| 68563 | 1177906, 1305554 | 10 dní 4:40 h | 46999 s = 13:03 h | 1 věta / 5,07 s | 86,08 % | 27.4.-14.5.2010 |
Tohle je nejlepší výsledek, jaký jsem zatím s Malt parserem dosáhl, ale se splitting trickem (viz níže) je to téměř stejné a ušetří se dva dny času.
Bez splitting tricku
Trénování bez “splitting tricku” na celých trénovacích datech. Testování je vždy na celém dtestu, tedy 9270 vět.
| 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 % |
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.
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í větších modelů s céčkovou implementací libsvm padá
Chybu hlásí sdm0.004.libsvm.mod, což 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.
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 | 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 % |
Splitting trick podle slovního poddruhu, jlibsvm
Snižuje časovou náročnost, zanedbatelně snižuje i úspěšnost.
| N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum | |
| 1000 | 1177862 | 3:00 min | 1304 s = 21:43 min | 1 věta / 0,14 s | 73,81 % | 27.4.2010 | |
| 2000 | 1177863 | 7:32 min | 1715 s = 28:35 min | 1 věta / 0,19 s | 76,98 % | 27.4.2010 | |
| 5000 | 1177864 | 42:28 min | 3282 s = 54:42 min | 1 věta / 0,35 s | 79,86 % | 27.4.2010 | |
| 10000 | 1177866 | 2:50 h | 5863 s = 1:38 h | 1 věta / 0,63 s | 81,63 % | 27.4.2010 | |
| 20000 | 1177867 | 15:52 h | 13877 s = 3:51 h | 1 věta / 1,50 s | 83,28 % | 27.-28.4.2010 | |
| 25000 | 1177868 | 21:02 h | 13345 s = 3:42 h | 1 věta / 1,44 s | 83,97 % | 27.-28.4.2010 | |
| 30000 | 1177870 | 30:36 h | 15689 s = 4:21 h | 1 věta / 1,69 s | 84,23 % | 27.-28.4.2010 | |
| 35000 | 1177871 | 39:04 h | 27.4.2010 | Parsing selhal. | |||
| 40000 | 1177872 | 2 dny 8 h | 19298 s = 5:22 h | 1 věta / 2,08 s | 84,92 % | 27.-30.4.2010 | |
| 45000 | 1177873 | 2 dny 20 h | 21907 s = 6:05 h | 1 věta / 2,36 s | 85,18 % | 27.-30.4.2010 | |
| 50000 | 1177875 | 3 dny 14 h | 22805 s = 6:20 h | 1 věta / 2,46 s | 85,37 % | 27.4.-1.5.2010 | |
| 55000 | 1177876 | 5 dní | 32512 s = 9:02 h | 1 věta / 3,51 s | 85,57 % | 27.4.-2.5.2010 | |
| 60000 | 1177877 | 5 dní 20 h | 27429 s = 7:37 h | 1 věta / 2,96 s | 85,70 % | 27.4.-3.5.2010 | |
| 65000 | 1177878 | 6 dní 4 h | 28112 s = 7:48 h | 1 věta / 3,03 s | 85,91 % | 27.4.-3.5.2010 | |
| full | 1177879 | 8 dní 7 h | 38957 s = 10:49 h | 1 věta / 4,20 s | 86,02 % | 27.4.-6.5.2010 |
Stackeager, java libsvm, švédské rysy
job-ID prior name user state submit/start at queue slots ja-task-ID ----------------------------------------------------------------------------------------------------------------- 1473932 0.55500 malt02000. zeman r 06/02/2010 10:15:02 all.q@tauri5.ufal.hide.ms.mff. 1 1473933 0.55500 malt05000. zeman r 06/02/2010 10:16:17 all.q@tauri9.ufal.hide.ms.mff. 1 1473934 0.55500 malt10000. zeman r 06/02/2010 10:18:17 all.q@tauri2.ufal.hide.ms.mff. 1 1473935 0.55500 mert.31733 zeman r 06/02/2010 10:19:32 all.q@sol3.ufal.hide.ms.mff.cu 1 1473956 0.55500 malt20000. zeman r 06/02/2010 10:20:17 all.q@fireball4.ufal.hide.ms.m 1 1473957 0.55500 malt25000. zeman r 06/02/2010 10:22:17 all.q@tauri10.ufal.hide.ms.mff 1 1473958 0.55500 malt30000. zeman r 06/02/2010 10:24:17 all.q@orion9.ufal.hide.ms.mff. 1 1473982 0.55500 malt35000. zeman r 06/02/2010 10:26:17 all.q@tauri3.ufal.hide.ms.mff. 1 1473983 0.55500 malt40000. zeman r 06/02/2010 10:28:17 all.q@orion8.ufal.hide.ms.mff. 1 1473984 0.55500 malt45000. zeman r 06/02/2010 10:30:17 all.q@orion3.ufal.hide.ms.mff. 1 1474005 0.55500 malt50000. zeman r 06/02/2010 10:32:17 all.q@fireball8.ufal.hide.ms.m 1 1474009 0.55500 malt55000. zeman r 06/02/2010 10:34:17 all.q@orion1.ufal.hide.ms.mff. 1 1474010 0.55500 malt60000. zeman r 06/02/2010 10:36:17 all.q@orion4.ufal.hide.ms.mff. 1 1474011 0.55500 malt65000. zeman r 06/02/2010 10:38:17 all.q@fireball3.ufal.hide.ms.m 1 1474032 0.55500 malt-full. zeman r 06/02/2010 10:40:17 all.q@fireball2.ufal.hide.ms.m 1 1474041 0.45734 pardec.03. zeman r 06/02/2010 10:41:47 all.q@tauri1.ufal.hide.ms.mff. 1 10:42 lrc-two:/ha/work/people/zeman/parsing/projects/maltpdt/uppsala-features/stackeager>
| N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum | Poznámka |
| 1000 | 1473892 | 2:38 min | 1283 s = 21 min | 1 věta / 0,14 s | 74,50 % | 2.6.2010 | |
| 2000 | 1473932 | 7:45 min | 1891 s = 32 min | 1 věta / 0,20 s | 77,47 % | 2.6.2010 | |
| 5000 | 1473933 | 49:08 min | 4178 s = 1:10 h | 1 věta / 0,45 s | 79,98 % | 2.6.2010 | |
| 10000 | 1473934 | 3:33 h | 7534 s = 2:06 h | 1 věta / 0,81 s | 81,93 % | 2.6.2010 | |
| 20000 | 1473956 | 18:09 h | 14095 s = 3:55 h | 1 věta / 1,52 s | 83,47 % | 2.-3.6.2010 | |
| 25000 | 1473957 | 26:12 h | 17299 s = 4:48 h | 1 věta / 1,87 s | 84,01 % | 2.-3.6.2010 | |
| 30000 | 1473958 | 2 dny | 25161 s = 6:59 h | 1 věta / 2,71 s | 84,43 % | 2.-4.6.2010 | |
| 35000 | 1473982 | 42:40 h | 18856 s = 5:14 h | 1 věta / 2,03 s | 84,74 % | 2.-4.6.2010 | |
| 40000 | 1473983 | 3 dny 18 h | 32172 s = 8:56 h | 1 věta / 3,47 s | 85,08 % | 2.-6.6.2010 | |
| 50000 | 1474005 | 4 dny 19 h | 29638 s = 8:14 h | 1 věta / 3,20 s | 85,26 % | 2.-7.6.2010 | |
| 55000 | 1474009 | 7 dní 17 h | 41959 s = 11:39 h | 1 věta / 4,53 s | 85,51 % | 2.-10.6.2010 | |
| 60000 | 1474010 | 9 dní 8 h | 43088 s = 11:58 h | 1 věta / 4,65 s | 85,65 % | 2.-12.6.2010 | |
| 65000 | 1474011 | 7 dní 14 h | 37991 s = 10:33 h | 1 věta / 4,10 s | 85,81 % | 2.-10.6.2010 | |
| full | 1474032 | 8 dní 6 h | 40110 s = 11:09 h | 1 věta / 4,33 s | 85,94 % | 2.-11.6.2010 |
Stackproj, java libsvm, švédské rysy
Log *.o1474105 má 74 malt01000.9528.csh.o1474105 řádků, takže snad úloha doběhla úspěšně. Všechny úlohy se úspěšně rozeběhly. job-ID prior name user state submit/start at queue slots ja-task-ID ----------------------------------------------------------------------------------------------------------------- 1474106 0.55500 malt02000. zeman r 06/07/2010 10:39:08 all.q@tauri6.ufal.hide.ms.mff. 1 1474107 0.55500 malt05000. zeman r 06/07/2010 10:41:08 all.q@tauri4.ufal.hide.ms.mff. 1 1474108 0.55500 malt10000. zeman r 06/07/2010 10:43:08 all.q@tauri8.ufal.hide.ms.mff. 1 1474109 0.55500 malt20000. zeman r 06/07/2010 10:45:08 all.q@tauri7.ufal.hide.ms.mff. 1 1474110 0.55500 malt25000. zeman r 06/07/2010 10:47:08 all.q@tauri1.ufal.hide.ms.mff. 1 1474111 0.55500 malt30000. zeman r 06/07/2010 10:49:08 all.q@fireball6.ufal.hide.ms.m 1 1474112 0.55500 malt35000. zeman r 06/07/2010 10:51:08 all.q@fireball1.ufal.hide.ms.m 1 1474113 0.55500 malt40000. zeman r 06/07/2010 10:53:08 all.q@orion6.ufal.hide.ms.mff. 1 1474114 0.55500 malt45000. zeman r 06/07/2010 10:55:08 all.q@orion2.ufal.hide.ms.mff. 1 1474115 0.55500 malt50000. zeman r 06/07/2010 10:57:08 all.q@orion10.ufal.hide.ms.mff 1 1474116 0.55500 malt55000. zeman r 06/07/2010 10:59:08 all.q@fireball10.ufal.hide.ms. 1 1474117 0.55500 malt60000. zeman r 06/07/2010 11:01:08 all.q@fireball7.ufal.hide.ms.m 1 1474118 0.55500 malt65000. zeman r 06/07/2010 11:03:08 all.q@orion7.ufal.hide.ms.mff. 1 1474119 0.55500 malt-full. zeman r 06/07/2010 11:05:08 all.q@fireball9.ufal.hide.ms.m 1
| N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum | Poznámka |
| 1000 | 1474105 | 2:46 min | 7.6.2010 | Parsing nedoběhl (“The symbol code '-1' cannot be found in the symbol table.”) | |||
| 2000 | 1474106 | 6:53 min | 1810 s = 30 min | 1 věta / 0,19 s | 74,74 % | 7.6.2010 | |
| 5000 | 1474107 | 51:45 min | 3723 s = 1:02 h | 1 věta / 0,40 s | 76,84 % | 7.6.2010 | |
| 10000 | 1474108 | 3:38 h | 6934 s = 1:55 h | 1 věta / 0,75 s | 78,50 % | 7.6.2010 | |
| 20000 | 1474109 | 17:03 h | 13256 s = 3:41 h | 1 věta / 1,43 s | 79,57 % | 7.-8.6.2010 | |
| 25000 | 1474110 | 29:14 h | 15764 s = 4:23 h | 1 věta / 1,70 s | 80,23 % | 7.-8.6.2010 | |
| 30000 | 1474111 | 36:55 h | 18845 s = 5:14 h | 1 věta / 2,03 s | 80,50 % | 7.-9.6.2010 | |
| 35000 | 1474112 | 2 dny 4 h | 20638 s = 5:44 h | 1 věta / 2,23 s | 80,80 % | 7.-9.6.2010 | |
| 40000 | 1474113 | 3 dny 11 h | 30127 s = 8:22 h | 1 věta / 3,25 s | 81,01 % | 7.-11.6.2010 | |
| 45000 | 1474114 | 4 dny 17 h | 33036 s = 9:10 h | 1 věta / 3,56 s | 81,04 % | 7.-12.6.2010 | |
| 50000 | 1474115 | 5 dní 4 h | 35954 s = 9:59 h | 1 věta / 3,88 s | 81,35 % | 7.-13.6.2010 | |
| 55000 | 1474116 | 4 dny 23 h | 30700 s = 8:32 h | 1 věta / 3,31 s | 81,48 % | 7.-12.6.2010 | |
| 60000 | 1474117 | 6 dní 9 h | 32758 s = 9:06 h | 1 věta / 3,53 s | 81,58 % | 7.-14.6.2010 | |
| 65000 | 1474118 | 9 dní 20 h | 44870 s = 12:28 h | 1 věta / 4,84 s | 81,70 % | 7.-17.6.2010 | |
| full | 1474119 | 7 dní 11 h | 36260 s = 10:04 h | 1 věta / 3,91 s | 81,88 % | 7.-15.6.2010 |
Covproj / covnonproj / nivrestandard / nivreeager, java libsvm, švédské rysy
Všechny trénovací procesy hlásí “The function cannot be initialized.” Mohlo by to být tím, že Marcova definice rysů, kterou se pokouším použít, byla původně určena pro algoritmus stacklazy. Takže se třeba snaží dívat na zásobník, se kterým Covingtonův algoritmus vůbec nepracuje? Žádnou změnou na clusteru ta chyba totiž není, trénink stacklazy se rozeběhne bez problémů stejně jako dřív.