====== Poznámky k článku ======
[[http://www.isi.edu/natural-language/people/bayes-with-tears.pdf|Kevin Knight: Bayesian Inference with Tears. September 2009.]]

===== 1. část (26. října) =====

Čtení Kevina Knighta nedopadlo podle mého nijak slavně, ale věřím, že repete příští týden to napraví a vše se v dobré obrátí.

Co jsme se dozvěděli (prosím opravte mne, pokud něco píšu špatně):

  * dosavadní pstní modely pro EM "vyprávějí pohádku", jak něco vzniká, ovšem neberou v úvahu už odvyprávěný začátek pohádky.
  * takové modely jsou proto nevhodné pro jazyková data, nereflektují skutečnost, že je v našich datech většina jevů rozdělena zipfovsky, tj. že lidé preferují opakovat už vyslovené
  * nová "bayesovská inference" je vybudována na pravděpodobnosti podmíněné právě historií vyprodukovaných jevů

  * Pavel Pecina je přesvědčen, že metoda učení (kterou jsme vlastně pořád neprobrali) je schopná se naučit jakékoli rozdělení, ne jen zipfovské. Ostatní jsme nevěděli a dokonce jsme se domnívali, že je metoda doslova postavena na tom, že se má naučit zipfovské rozdělení

  * prošli jsme si klíčový vzoreček definující P(rule | root(rule), cache) a uvědomili si, že cache se má užívat nezávislá pro různé root(rule), (aby platilo zjednodušení vzorečku na str. 11 uprostřed) čili se dá stejně dobře mluvit o P(rule | cache) pro pevně daný kořen

  * prošli jsme si otázky v bodu 15 a nyní např. víme, když máme už naplněnou cache, jak pomocí cache spočítat pst dané derivace, všech derivací vedoucích k danému stromu, všech derivací všech stromů v treebanku ap.
  * zabývali jsme se i tím, k čemu jsou odpovědi na tyhle otázky dobré, např. k výběru nejlepší derivace

  * Pavel Pecina nás upozornil, že pořád mluvíme o generování treebanku, a že ale v praxi vůbec takhle generovat nebudeme. Že si jen "v rámci trénování vyladíme parametry" (je cache parametr??) tak, aby nám z generování s vysokou pstí vypadl právě náš trénovací treebank, kdybychom omylem generovat začali. Jak ale tedy napíšu např. parser pro novou větu založený na gramatice strojově vykoukané z treebanku (a co je vůbec gramatika v tomto pojetí?? P_0 a vyplněná cache??), to nevíme.

Příště velmi stručně tohle zopakujeme na konkrétním příkladu z bodu 17. Pak
doufám, že se dobrodíme až do slibované sekce 26.

O.

===== 2. část (2. listopadu) =====
  * Vytyčený cíl jsme zvládli! Došli jsme do sekce 26!

  * Srovnávali jsme dva typy modelů (**EM model** a **cache model**) na příkladech segmentace a tagování.

  * Oba typy modelů se používají v unsupervised metodách. Když mám náhodou už anotovaný korpus, můžu ho použít jako startovní bod EM nebo jako P_0 v cache modelu, jinak je k ničemu.

  * Oba typy modelů definují vzoreček, jak se vypočítává pst dané konkrétní derivace (tj. otagované sekvence slov či nasegmentovaného čínského slova):
    * EM model potřebuje tabulky podmíněných pstí (podle toho, jak mám model postaven, např. P(w_i | t_i)), které nastřelím uniformně a během "trénování" dokonverguju k takovým hodnotám, které maximalizují pst mých dat.
    * Cache model žádné takové tabulky nepotřebuje. Jediným vstupem (krom konstant) je vzoreček pro apriorní pst P_0, který danému stavebnímu dílku (např. čínské slovo) dává jeho pst. Žádoucí je jedině, aby P_0 dávala nenulovou pst všemu. Základním rysem cache modelu je, že v derivacích zohledňuje historii a preferuje často užívané stavební dílky.


  * Pod označením "trénování modelu" se v obou případech rozumí zjištění těch tabulek, které EM potřebuje a cache model ne. Ty tabulky jsou totiž užitečné i pro finální uplatnění natrénovaného na nová data -- např. tagování Viterbim.

  * "Trénování" v cache modelu (ano, pořád si myslím, že je to protimluv, viz nápad na konci mailu) se tedy dělá např. tak, že:
    - (v ideálním světě) projdu všechny derivace a nasbírám fractional counts, z nich vyplním a normalizuju tabulky
    - (pro hrubou představu reálného světa) si najdu nějakou dost pravděpodobnou derivaci a nasbírám fractional counts z ní  (díky Janě Strakové)
    - (asi v praxi) kumuluju počty přes vícero derivací navštívených během GS, viz níže, které na závěr jednou znormalizuju

  * Cyklus se používá:
    - v EM během trénování
      * cyklí se přes //modely// (tj. konkrétní hodnoty v tabulkách)
      * v každé iteraci projdu všechny derivace celého korpusu (průchod přes všechny iterace je implicitní, užívá se dynamické programování, v daném bodě každé iterace totiž pst následujícího kroku v derivaci nezávisí na tom, jak vypadá začátek derivace. Dyn. prog. toho využije a počítá během průchodu všechny derivace najednou.)
    - v cache modelu při Gibbsově samplingu (GS):
      * cyklí se přes //derivace// (tj. konkrétní otagování korpusu)
      * vzhledem k tomu, že každý krok derivace ovlivňuje ty následující, nelze počítat se všemi derivacemi najednou, proto se užívá GS:
      * v aktuální derivaci (začnu náhodnou) navrhnu místo změny
      * prozkoumám //všechny možné// derivace, které se od té aktuální liší v daném místě
      * přesunu se do souseda vybraného náhodně s pstí odpovídající těm sousedům

  * Probrali jsme si trik, který stojí za inkrementálním výpočtem psti souseda dané derivace. Kromě samotné psti aktuální derivace potřebuju ještě udržovat počty dílků použitých v derivaci, tj. cache.

  * Eda Bejček docela srozumitelně vysvětlil tu exchangeabilitu (vytrhnu čitatel, tím se ostatní čitatelé musí o jedna posunout, aby zabrali jeho místo, ale ten čitatel nakonec zase vrátím, takže výsledek součinu bude stejný; a stejně se jmenovateli, nikoli však se zlomky jako celky), takže tomu věříme.

  * Teď dodatečně mne napadla ještě jiná varianta, jak splnit úlohu "otaguj mi tuto sekvenci" pomocí cache modelu, a přitom tabulky //neextrahovat//: danou sekvenci připojím na konec "trénovacích" dat, nechám Gibbse bloumat derivacemi. Až si budu myslet, že sedí na pěkné derivaci, uříznu její konec a prohlásím ji za otagování mého vstupu.

Uff.

Díky za pomoc,
O.