Monte Carlo következtetési módszerek beállítása, monitorozása, eredményeinek megjelenítése Nagy méretű Bayes-hálók esetén az egzakt következtető eljárások - még ha az eredeti hálót a hatékonyság növelése érdekében át is alakítjuk egy másodlagos struktúrába és abban következtetünk, mint a PPTC algoritmus esetében - exponenciális számítási igényük miatt nem alkalmazhatóak. Ehelyett közelítő módszereket vethetünk be a prediktív következtetés elvégzésére. Ilyen közelítő következetési módszereket kínál a Monte Carlo Markov Chain eljárások családja, amelybe tartozó algoritmusoknak közös jellemzője, hogy egy Markov-láncot generálnak, amely a többdimenziós-eloszlás mintavételezése során konvergál az egyensúlyi eloszláshoz. A Markov-folyamat minden egyes állapotában minden változóra meghatároz egy értéket. A következő állapot generálása egy Xi nem bizonyítékváltozóhoz tartozó érték véletlenszerű mintavételezésével történik, az Xi Markov-takarójába tartozó változók jelenlegi értékeinek feltétele mellett. Az MCMC így véletlen bolyongást végez az állapottérben - a lehetséges teljes érték hozzárendelések terében -, egyszerre egy változót billentve át, de rögzítetten tartva a bizonyítékváltozókat. A módszer elmélete szerint a céleloszláshoz való konvergencia megtörténik, ha a lépésszám tart a végtelenhez. Praktikusan a pontosság a generált minták számától függ. Evidenciák bevitele A felhasználói felület lehetőséget ad a következtetés egyik alapfeladatának, célváltozó-értékek valószínűségének a kiszámítására, a bizonyíték-ismeretek mint feltétel mellett. A felhasználó az "Inference Specification" nézet használatával a betöltött Bayes-háló változócsomópontjaira biztos evidenciákat (hard evidence) állíthat be. Lehetőség van a beállított evidencia törlésére is. Az evidenciával rendelkező csomópontok nevei a szerkesztővásznon félkövérrel szedve láthatók, a név alatt a felvett értékkel. Változóértékek, többváltozós értékkonfigurációk monitorozása Az MCMC szimuláció során egyidejűen monitorozható több változóérték valószínűségének vagy akár többváltozós értékkonfiguráció együttes valószínűségének alakulása is. A vizsgált változókra a program tárolja a mintavételezés során kapott értékeket, így számolható egy konkrét változóérték
valószínűsége. A figyelendő változóértékek vagy értékkonfigurációk megadhatók az "Inference Specification" nézet kontextus menüjén keresztül vagy az erre a célra kifejlesztett dialógusablak segítségével. MCMC szimuláció indítása Az MCMC szimuláció a menüsor megfelelő menüpontjának kiválasztásával indítható. A megjelenő dialógus ablakban beállíthatók a szimuláció paraméterei. Az MCMC szimuláció paraméterei Num. of iterations: Teljes iterációszám beleértve a burn-in lépéseket is. Length of burn-in: Mekkora iterációszámtól tárolódjanak a figyelt változókhoz generált minták. Ennek beállításával válnak a "burn-in" minták eldobhatókká. Thinning rate: Mekkora iterációszámonként kerüljenek felhasználásra a figyelt változókhoz generált minták. Az egymást követő minták közötti autokorreláció nagy lehet és ha emiatt
úgyis nagy iterációszámot kell alkalmaznunk, ezzel csökkenthetjük a tárolt adatok mennyiségét, így a program memóriaigényét. Refresh rate: Mekkora iterációszámonként történjen meg a diagramok frissítése. A konvergencia-diagnosztikára, vagyis annak megállapítására hogy a futtatott szimuláció esetén a konvergencia megtörtént e, hány kezdeti lépés (ún. burn-in szakasz) után közelíti a lánc állapotainak eloszlása a céleloszlást megfelelően, a "MCMC inference" nézeten megjelenített vonaldiagramok szolgálnak. Egyetlen lánc futtatása esetén a konvergencia ellenőrzése a legegyszerűbben informális módon, a diagram vizsgálatával történhet, nevezetesen: ha a burn-in utáni különböző diagramszakaszok megkülönböztethetetlenek, a lánc konvergensnek tekinthető. Ezen kívül a konvergencia ténye formális módon is megállapítható lehetne különböző mutatószámok segítségével, mint pl. Geweke. Gibbs mintavételi eljárás megvalósítása A szoftver következtetési motorjában a közelítő következtetésre alkalmazható Gibbs mintavételező eljárás C++ nyelven került implementálásra a Java nyelv memóriakezelési és teljesítménybeli korlátain való túllépés érdekében. A Java és az alacsonyabb szintű, rendszerközelibb C++ nyelv közti együttműködés a Java Native Interface (JNI) technológia segítségével valósult meg. A JNI keretrendszer
használatával lehetőségünk van Java-ban létrehozott natív metódusokat C++ nyelven implementálni és meghívni. A natív metódusok implementációját tartalmazó C kódból és a legenerált header fájlokból összeállított könyvtár lefordítása után (linking) egy.dll kiterjesztésű fájl keletkezik. Az így létrehozott ún. osztott programkönyvtár (shared library) függvényeinek Java programban való használatához a könyvtárat futási időben kell betöltenünk. A Gibbs mintavételező egy vagy több Markov-láncot futtat a valószínűségi változók halmazán és a következő lépéseket követi: 1. Rögzítjük az evidenciaváltozók értékét. 2. Kisorsolunk egy kezdeti valószínűségi változóérték konfigurációt, amely kompatibilis az evidenciákkal. 3. Minden iterációban az összes szabad változóra (amelyekre nincsen evidencia beálltva) kisorsolunk egy aktuális értéket a háló által leírt feltételes valószínűségi eloszlásból a változó Markov-takarója mint feltétel szerint. A változó egy felvehető értékének valószínűsége a Markov-takarója, mint feltétel mellett a következő képlettel számolható ki: A változókon való végiglépdelés és értékadás után kapott változóérték konfiguráció jelent egy mintát. Legyen N az MCMC frissítések száma, T mintavételi ráta (pl. 10 esetén minden 10-edik mintát kapjuk vissza), B a burn-in minták száma, S a visszakapott minták száma. A minták teljes száma az MCMC frissítések száma megszorozva mintavételi rátával, vagyis N*T. Ez az az ismétlésszám, ahányszor a Gibbs mintavételező fő lépését, a bizonyítékokkal kompatibilis érték-konfigurációk újrasorsolását végrehajtjuk. A visszakapott minták számának meghatározásához ebből ki kell vonnunk a burn-in minták számát, hiszen azokra nem tartunk igényt, majd az eredményt el kell osztanunk a mintavételi rátával: S = (N*T-B)/T. Forward sampling A kezdeti értékek generálásához a Forward Sampling algoritmus használt az egyenletes eloszlás szerinti mintavétel helyett, mivel ez a megoldás a Gibbs algoritmus gyorsabb konvergenciáját eredményezi. A Forward Sampling algoritmus minden változóhoz egy felvehető értéket rendel a következő lépések végrehajtása után: 1. Rendezzük a Bayes-háló csomópontjait topologikus sorrendbe. 2. Rögzítjük az evidenciaváltozók értékét. 3. Minden egyes szabad változóra: Mintavételezzük a xi változót a változó szülőinek beállított értékek, mint feltételek által kijelölt CPD-beli eloszlásból. Gibbs mintavételezés indítása A grafikus felhasználói felületen a Bayes-háló modell betöltése után a szerkesztő módról a Gibbs mintavételező módra az Operations menü "Gibbs sampling mode" menüpontjára kattintva válthatunk át. Ebben a módban a kialakított háló szerkesztése nem engedélyezett, kivéve a csomópontok áthelyezése és a változócsoportok kezelése. Miután a megnyitott Bayes-háló módellben az "Inference Specifications" nézet segítségével felvettük az evidenciáinkat és beállítottuk azokat a változóértékek, többváltozós értékkonfigurációkat, amiket figyelni szeretnénk, a Gibbs mintavételezés a menüsor "Gibbs sampling" menüjének "Start simulation"
menüpontjának kiválasztásával indítható. A kattintásra megjelenő ablakban beállíthatók a szimuláció paraméterei. A Gibbs mintavételezés paraméterei Num. of chains: Egyszerre különböző végrehajtási szálakon (thread) futtatott Markov-láncok száma Num. of updates: MCMC frissítések száma Length of burn-in: A burn-in szakasz hossza, vagyis mekkora iterációszámtól szeretnénk visszakapni a figyelt változókhoz generált mintákat. Thinning rate: Mekkora iterációszámonként kerüljenek felhasználásra a figyelt változókhoz generált minták. Az egymást követő minták közötti autokorreláció nagy lehet és ha emiatt úgyis nagy iterációszámot kell alkalmaznunk, ezzel csökkenthetjük a tárolt adatok mennyiségét, így a program memóriaigényét. Refresh rate: Mennyi visszakapott mintánként történjen a diagramok frissítése.
A szimuláció addig fut, amíg az MCMC frissítések száma el nem éri a fenti dialógusablakban megválasztott "Num. of updates" értéket. Ekkor a futtatás szünetelt (paused) állapotba kerül. Amíg az algoritmust nem állítjuk le véglegesen ("Stop sampling"), lehetőségünk van újabb minták generálására ("Resume sampling").
Konvergencia-diagnosztika A konvergencia-diagnosztikára, vagyis annak megállapítására hogy a futtatott szimuláció esetén a konvergencia megtörtént e, hány kezdeti lépés (ún. burn-in szakasz) után közelíti a lánc állapotainak eloszlása a céleloszlást megfelelően, a "MCMC Inference" nézeten megjelenített vonaldiagramok szolgálnak.
A nézeten minden egyes monitorozott változóértékhez vagy többváltozós értékkonfigurációhoz egy vonaldiagram jelenik meg vízszintes elrendezésben. A diagram vízszintes tengelyén az iterációszám, függőleges tengelyén a valószínűség szerepel. A grafikonon az utolsó 1000 beérkezett mintához láthatjuk a vizsgált változóérték vagy többváltozós értékkonfiguráció előfordulásának addig a pontig kalkulált valószínűségét. Amennyiben kiváncsiak vagyunk a valószínűségek alakulásának teljes történetére, a diagramon való jobbkanttintás után megjelenő kontextus menüből válasszuk a "Show full chart" opciót. A megjelenő dialógusablak bal oldalán egy grafikon található, amely az összes beérkezett minta alapján számolt pontot tartalmazza. Az ablak jobb oldalán elhelyezkedő táblázatban a lánconkénti valószínűségek olvashatók, a táblázat alján pedig ezen érték átlaga.
A konvergencia ellenőrzésére léteznek informális/empirikus és formális/statisztikai módszerek is. A legtöbb egyszerű modell esetében a konvergencia gyorsan megtörténik, sokszor az első néhány ezer iteráción belül. Komplexebb modelleknél, a konvergencia jelentősen hosszabb burn-in periódust igényel és gyakori, hogy nagyságrendekkel több mintavételre van szükségünk. Egyetlen lánc futtatása esetén a konvergencia ellenőrzése a legegyszerűbben informális módon, a diagram vizsgálatával történhet, nevezetesen: ha a burn-in utáni különböző diagramszakaszok megkülönböztethetetlenek, a lánc konvergensnek tekinthető. Ha több, egymástól független láncot futtatunk és az egyes futásokhoz tartozó diagramok "ránézésre" nem különböztethetők meg egymástól, elfogadhatjuk a konvergencia tényét. Az ad hoc, informális technikákon kívül a konvergencia ténye formális módon is megállapítható különböző statisztikai módszereken alapuló mutatószámok segítségével. Ilyen mutatószámok a következőkben bemutatott Geweke és a Gelman-Rubin statisztikák. Geweke diagnosztika A Geweke diagnosztika egy idősor analízisen alapuló formális konvergencia diagnosztikai módszer, amely a lánc elejéről és végéről vett szegmensek átlagának és varianciájának összehasonlításával operál. Legyen "a" a lánc elejéről, "b" a lánc végéről vett intervallumok. Ha az ezekre a szegmensekre számolt ún. Z-score hasonló, az bizonyíthatja a konvergencia elértét. Legyen és az a és b "ablakból" vett minták átlaga. A megvalósított algoritmus a lánc változó kezdőpontú 10% nagyságú szegmenseinek és a maradék lánc utolsó 50%-ának Z-score-jából számol. Ha a diagramon ábrázolt pontok nagy része a nulla vonal körüli [-1.96, 1.96] intervallumon belül szóródik, az valószínűsíti a konvergenciát, míg a kilógó pontok azt
jelzik, hogy esetleg több mintára lesz szükségünk a konvergencia eléréséhez (az 1.96-os választás indoka, hogy ez az N(0,1) normális eloszlás 95%-os konfidencia-intervalluma. A Z-score-t a grafikonon a szegmensen belüli első mintához tartozó iteráció számának függvényében szeretnénk ábrázolni meghatározott pontokban. Legyen LENGTH a lánc teljes hossza, BINWIDTH a grafikonon megjelenített egymást követő pontok közti távolság, NUMOFBINS pedig a pontok száma. Legyen MINBINWIDTH a legkisebb távolság, amit a szóban forgó pontok között megengedünk, MAXNUMOFBINS pedig a pontok maximális száma. A teljes láncot úgy szeretnénk szegmensekre osztani, hogy az utolsó szegmens legalább 50 mintát tartalmazzon. Ennek megfelelően a BINWIDTH-t határozzuk meg úgy hogy az utolsó két pont között legyen legalább 50, a többi egymást követő pont között pedig az 500 iterációjú vagy rövidebb láncok esetén legyen a MINBINWIDTH értéke hosszabb láncokra úgy kapjuk, hogy a láncot az utolsó 50 minta számításba vétele nélkül egyenletesen MAXNUMOFBINS szakaszra osztjuk Az így meghatározott szakaszok kezdőpontjai a szegmensek kezdőpontjait jelölik majd ki. A MINBINWIDTH értéke alapértelmezésben 10, a MAXNUMOFBINS értéke alapértelmezésben 50, de ezek a beállítások testreszabhatók a Window/Preferences menüpontja alatt elérhető "MCMC" oldalon.
Az algoritmus a következőképpen működik: 1. Felosztjuk a teljes LENGTH hosszú láncot szegmensekre: minden i=0-tól i<numofbins-ig vegyük a lánc i*binwidth-edik iterációtól induló az utolsó eleméig tartó LENGTH-i*BINWIDTH hosszú szegmensét és számoljuk ki rajta a Z-score-t. 2. Ábrázoljuk a kapott Z-score-t a grafikonon, ahol a vízszintes tengelyen a szegmensen belüli első mintához tartozó iteráció száma, a függőleges tengelyen maga a Z-score van feltüntetve. Gelman-Rubin diagnosztika A Gelman-Rubin diagnosztika több párhuzamosan futó lánc által szolgáltatott értékek alapján próbálja vizsgálni a konvergenciát. Alapja az az elgondolás, hogy ha a láncok konvergálnak, akkor egymáshoz nagyon hasonlóan kell hogy kinézzenek. Ha nem hasonlítanak, egy vagy több lánc esetén a konvergencia kudarcba fulladt. Az algoritmus a láncok közti variancia (B) és a láncon belüli variancia (W) vizsgálatán alapul. Legyen m darab n hosszú láncunk. Ekkor az említett mennyiségek a következőképpen számolhatók: A Gelman-Rubin statisztika a konvergencia értékelésére az ún. "Shrink factor" (hívják még "Scale reduction factornak" is) arányt használja, amely a következőképpen határozható meg:
A Shrink factort a grafikonon az szegmensen belüli utolsó mintához tartozó iteráció számának függvényében szeretnénk ábrázolni meghatározott pontokban. Legyen LENGTH a lánc teljes hossza, BINWIDTH az egymást követő grafikonon megjelenített pontok közti távolság, NUMOFBINS pedig a pontok száma. Legyen MINBINWIDTH a legkisebb távolság, amit a szóban forgó pontok között megengedünk, MAXNUMOFBINS pedig a pontok maximális száma. A teljes láncot úgy szeretnénk szegmensekre osztani, az első szegmens pontosan 50 mintát tartalmazzon. Ennek megfelelően a BINWIDTH-t határozzuk meg úgy hogy a 0 és az első pont között legyen pontosan 50, a többi egymást követő pont között pedig az 500 iterációjú vagy rövidebb láncok esetén legyen a MINBINWIDTH értéke hosszabb láncokra úgy kapjuk, hogy a láncot az első 50 minta számításba vétele nélkül egyenletesen MAXNUMOFBINS szakaszra osztjuk Az így meghatározott szakaszok végpontjai a szegmensek végpontját jelölik majd ki. Az implementált algoritmus lépései: 1. Felosztjuk a teljes LENGTH hosszú láncot szegmensekre: minden i=0-tól i<numofbins-ig vegyük a lánc elejétől induló az 50+i*BINWIDTH-dik eleméig tartó szegmensét és számoljuk ki rajta a Shrink factor-t. 2. Ábrázoljuk a kapott Shrink factort a grafikonon, ahol a vízszintes tengelyen a szegmensen belüli utolsó mintához tartozó iteráció száma, a függőleges tengelyen maga a Shrink factor van feltüntetve. Amennyiben a kapott értékek közel esnek az 1.0-ához és kb. 1.1 alatt vannak, biztonsággal állíthatjuk, hogy a láncaink konvergálnak, a mintáink az egyensúlyi eloszlásból származnak.