V této sekci budou postupně přibývat doporučení pro generování umělých dat a pro práci s modulem ReverseMiner.

Pro získání základní představy o chování evolučního algoritmu je vhodné nejprve projít ukázkové RM případy, zkusit udělat drobné změny a teprve následně zkoušet zadávat vlastní – nejprve jednoduché, a potom složitější s více omezeními.

Zejména u složitějších úloh generování dat bude postupně vznikat velké množství RM případů a ještě více DZD úloh, které budou představovat požadavky na data. Množství úloh bude o to větší, že pro jeden požadavek může být nutné zadat více úloh (např. samostatně pro míru zajímavosti, pro BASE a následně i negativní vztah).

Proto je důležité si zavést systém v pojmenování RM případů i DZD úloh. Je vhodné si jednotlivé požadavky na data očíslovat (případně i hierarchicky podle jejich typů a atributů, kterých se týkají) a toto číslování používat při pojmenování jak DZD úloh, tak i RM případů představujících dílčí evoluci. DZD úlohy mohou být zároveň umísťovány do skupin.

Řešení úloh pomocí evolučních algoritmů má svá specifika. Evoluce potřebuje (stejně jako v přírodě) čas, aby se dobrala k vhodnému řešení. Není možné očekávat, že náhodné změny budou hned a vždy přesně takové, jak bychom potřebovali.

Směrem ke konci evoluce (a zejména těsně před dosažením přesně požadovaných dat) bude klesat četnost nalezení ještě lepšího jedince. Vidíme-li, že evoluce „zamrzla“, můžeme zkusit výpočet pozastavit (Pause) a na záložce RM Case zkusit změnit parametry evoluce (v takovém případě obvykle pomáhá zvýšit pravděpodobnost mutací). Alternativně můžeme na záložce DM Tasks zkusit změnit váhu některých požadavků (zejména, pokud se ukáže, že v evoluci dva navzájem protichůdné).

Pro lepší pochopení, co během evoluce děje, je možné zaškrtnout volbu Save each iteration EA State. Potom v pracovní složce RM případu nalezneme pro každou iteraci detailní rozpis jedinců aktuálně v populace. Z iterace na iteraci můžeme sledovat změny a zjišťovat, proč se například neuplatnil jedinec s vhodnou mutací pro danou DZD úlohu (obvykle zjistíme, že tou samou mutací byla naopak výrazně poškozena fitness pro úlohu jinou – jde tedy o dva protichůdné požadavky).

Zároveň však neexistuje žádné všeobecně platné pravidlo, jak by měly být parametry pro ta či jiná generovaná data nastaveny. Je třeba zkoušet různé možnosti, sledovat průběh evoluce a zkoumat EA report pro získání co nejlepší představy. Ani pak však není jistota, že nastavené parametry jsou ty nejlepší nebo že budou dobré pro jiný RM případ.

I když jsou všechny parametry nastavené zdánlivě dobrým způsobem, tak se evoluce může chovat nepředpokládaně a doba řešení může být velmi dlouhá (dny i více). I drobná změna parametrů může vést k naprosto odlišnému průběhu evoluce, době řešení i podobě nalezených dat.

Počáteční distribuci hodnot ve sloupcích volit tak, aby co nejvíce odpovídala požadované cílovému stavu. Budeme-li například požadovat v celé datové matici nahromadění výskytů klientů s nízkým platem, je nevhodné zadat uniformní rozdělení výše platu (nebo dokonce takové, které vygeneruje převážně vysoké hodnoty platu). Přestože evoluce pravděpodobně nakonec pomocí velkého množství mutací změní frekvence nízkých a vysokých platů, aby odpovídaly zadané DZD úloze, tak jí to bude trvat dlouho. Dokonce může „uvíznout“ v lokálním minimu a řešení nebude nalezeno vůbec!

V tomto ohledu zejména pozor na použití kvantifikátoru Fundovaná implikace s vysokými hodnotami parametru p pro obecné (krátké) antecedenty – např.:

Pohlaví( žena) ⇒_0,9 Vzdělání( vysokoškolské)

Jsou-li hodnoty na počátku vygenerovány přibližně rovnoměrně, bude evolučním operacím trvat dlouhou dobu, než zajistí u velké většiny objektů opravu hodnoty na ty, které vyhovují zadané implikaci.

Frekvence hodnot lze udržet v tolerovaném rozpětí od počátečního nastavení pomocí tzv. Frequency guiding rules. Ta se zobrazují v dialogovém okně vyvolaném z okna definice sloupce a nová se přidávají pomocí tlačítka Add.

Při zadání každé DZD úlohy definující požadavky na data je třeba pečlivě zkontrolovat, že taková data mohou teoreticky vůbec existovat. Tuto kontrolu je třeba provést znovu po přidání každé další DZD úlohy, a to jak pro úlohu samotnou (nevyžaduje-li v datech závislosti, které není možné vygenerovat), tak zároveň v souvislosti s již dříve zadanými úlohami (že nemají navzájem protikladné požadavky na data).

4ft-Miner

• pro specifické vztahy týkající se menší podmnožiny dat
• obvykle nutné zadat více vztahů (pro IM, pro BASE a negativní vztah)
• BASE nemusí být potřeba, když máme zadaná Frequency Guiding Rules

CF-Miner

• jedna úloha zajišťuje kompletní rozložení frekvencí, tzn. pozitivní i negativní vztah. Navíc není třeba řešit dostatečné BASE.
  • př. rekreační pobyty začínají obvykle v pátek a v sobotu (pozitivní vztah), málokdy v jiný den (negativní vztah) zadáme jako jednu DZD úlohu:
    • CF: HDenTydne_{SUM(Pá+So)≥70 %} / HTypPobytu( rekreační)

Při generování dat je zejména pro požadavky založené na úlohách pro 4ft-Miner nutné zadat i DZD úlohy, které zajistí, že v datech nebude příliš mnoho (jiných) vztahů/vzorů kromě těch, které v nich mít chceme. Takové úlohy se zadávají s požadavkem na počet nalezených hypotéz menší než X nebo obrácením intervalu pro normalizaci.

Ukazuje se však, že ve většině případů je vhodné u takových úloh snížit váhu (např. na 0,5 nebo na 0,3), aby v evoluci nejprve dostávali přednost jedinci směřující k vytvoření vztahů, které mít v datech chceme. Teprve až po nalezení takové podoby dat se má evoluce soustředit na „zničení“ případných jiných náhodou vzniklých závislostí v datech (to je totiž obvykle snazší).

Z dosavadních zkušeností vyplývá, že jsou dva typy vztahů, které způsobují evoluci problémy, resp. prodlužují dobu hledání výsledku. Jde o vztahy týkající se velkého množství dat a o velmi silné vztahy. Velmi silné vztahy obvykle navíc popisují velmi řídké jevy, což může působit další problémy.

Obvykle jde o vztahy založené na KL-Mineru, CF-Mineru nebo Fundované implikaci ve 4ft-Mineru. Příkladem prvního typu problematických vztahů může být požadavek na začátek rekreačních pobytů převážně v pátek nebo v sobotu, za současného požadavku na 70 % podíl rekreačních pobytů v datech. Jsou-li na počátku začátky pobytů rozdělené přibližně rovnoměrně, dá evoluci velkou práci, než pomocí křížení a mutací dosáhne kýženého stavu. Zde se jako nejlepší pro zrychlení doby řešení ukazuje nastavení vhodnějšího počátečního rozdělení dat na záložce Columns ještě před samotným spuštěním evoluce.

Příkladem druhého typu problematických vztahů může být požadavek, že pobyty na 28 nocí musí být vždy služební cesty začínající v pondělí. Zároveň těchto pobytů má být mezi 1,5 až 2,5 %. Tady se jako řešení nabízí využití šlechtění (breeding – zvláštního typu křížení popsaného výše). Podaří-li se nalézt řešení této dílčí úlohy samostatně ve zvláštním RM případu, můžeme jej následně přidat jako Data Preset. Pak budeme doufat, že křížení s odpovídajícím jedincem se podaří do aktuálně nejlepšího jedince zanést požadované řídké vztahy.

U opravdu řídkých jevů je však úspěšnost i v případě šlechtění malá. Potom pomůže vytvoření RM případu pracovně nazvaného jako mutant.

Alternativně lze silnou vazbu mezi dvěma sloupci zajistit zadáním matematického vztahu, kterým budou hodnoty ve druhém sloupci inicializovány přesně podle hodnot ve sloupci prvním. Protože však bude matematický vztah využit pouze pro inicializaci, budou se hodnoty ve druhém sloupci v průběhu evoluce měnit a vazba mezi hodnotami v obou se sloupcích se bude narušovat. Aby neklesla pod námi stanovenou mez, zadáme požadavek ve formě implikačního asociačního pravidla.

Výhoda je v tom, že nyní bude pravidlo „pouze“ bránit poklesu míry platnosti vztahu. To je méně časově náročné, než když se náhodným evolučním procesem vhodná kombinace hodnot hledala.

Alternativně lze místo matematického vztahu použít funkci Lookup pro dohledání hodnoty odkazem z jiné tabulky a přidat náhodný rozptyl pomocí funkce lm.rnd.

Zadání libovolného druhého kritéria (nejčastěji BASE) v zadání úlohy pro požadovaný vztah v datech může způsobit problém v evoluci, když pro většinu jedinců nebude nalezen vůbec žádný vztah právě z důvodu nedostatečného BASE.

V tom případě je třeba udělat klon úlohy DZD a v něm ponechat pouze kritérium BASE a nastavit jej jako Primary IM. V původní úloze DZD naopak BASE vymazat. Obě úlohy pak vložit jako požadavky do RM případu.

Zadáme-li požadovaný vztah jako úlohu pro 4ft-Miner a kvantifikátor AAD, je potřeba zaručit, že evoluce bude schopna rozpoznat lepšího jedince i v případě, že všichni budou Below Average. To zajistíme přidáním klonu úlohy, změnou kvantifikátoru na „BAD“ a požadavkem na nenalezení žádného vztahu.

V navržených vztazích musí být i takové, které zamezí vzniku jiných nechtěných závislostí – tzv. „negativní vztahy“.

Ve fázi evoluce držet počet řádků v generovaných datech co nejnižší. Teprve po nalezení varianty dat, která splňuje všechny požadavky, znásobit počet řádků a přidat náhodný „šum“ pomocí randomizace.

V datech Hotel postačilo pro zachycení všech vztahů i četností kategorií pouhých 200 řádků. To výrazně zkrátilo čas, který evoluce potřebovala k nalezení přijatleného řešení. Následně byla tabulka zvětšena na 2000 řádků a ponechán prostor pro randomizaci.

U velmi složitých úloh generování dat (s mnoha omezeními a požadavky na data) není vhodné zadat evoluci hned napoprvé jako jeden běh. Nejprve generovat data pro každý ze zamýšlených vztahů samostatně. Z toho poznáme, jak obtížné je pro evoluci dojít od počátečních rozložení hodnot k takovým, která daný vztah splňují. Můžete i experimentovat s různou požadovanou sílou vztahu, aby se evoluce zrychlila. Zkoušet můžeme i různá nastavení parametrů evoluce. Zároveň můžeme dobu řešení značně zkrátit tím, že v dílčím požadavku generujeme pouze ty sloupce, kterou jsou pro něj relevantní (vyskytují se v nějaké DZD úloze).

Teprve po vyřešení dílčích požadavků na data přistoupíme ke generování dat splňujících více požadavků najednou. Opět je vhodné postupovat v malých krocích a nejprve třeba kombinovat dva požadavky, následně tři atd. Při tomto postupu daleko snáze zjistíme, které požadavky jsou navzájem v rozporu a že musíme jeden bud oslabit nebo úplně z evoluce vyřadit.

Máme-li výsledky pro dílčí běhy, nemusí kombinovaná evoluce začínat vždy úplně odznovu. Do počáteční populace můžeme přidat jedince představující již nalezená řešení dílčích evolucí jako Data Presets.

Jako první dílčí evoluci se ukazuje se jako vhodné vytvořit RM případ pouze s požadavky na rozpětí frekvencí hodnot (Frequency Guiding Rules) a nechat evoluci taková data nalézt. Výsledek pak přidáváme do každého dalšího RM případu jako jednu z možné výchozí podoby dat, do které jsou následně zakomponovány další požadované vztahy.

Aby mohla evoluce pro „rozmnožování“ vybírat skutečně nejlepší jedince, musí být schopna mezi nimi rozlišovat. Bude-li požadavek pomocí DZD úlohy zadán s vysokou hodnotou prahu kvantifikátoru, nebude pro většinu jedinců nalezen žádný vztah a z pohledu evoluce budou všichni stejně špatní.

Proto je důležité nastavovat hodnoty prahů co nejnižší (resp. na 0), kvantifikátor označit v zadání úlohy jako Primary IM a cílovou hodnotu míry zajímavosti uvádět v druhém z polí pro normalizaci tamtéž. Potom může evoluce dávat přednost jedincům, pro které požadovaný vztah platí na 0,3, oproti jedincům, kde platí pouze na 0,3.

Zároveň je třeba opatrně pracovat s hodnotou parametru BASE – viz Problém s BASE

Nedochází-li hned na počátku evoluce k alespoň nějakému zlepšování fitness aktuálně nejlepšího jedince (modrá čára v grafu), je patrně něco v zadání špatně a nemá cenu ztrácet čas čekáním na případné zlepšení. Příčinou mohou být například nereálné požadavky na data nebo požadavky, které jsou navzájem v rozporu.

Na počátku má totiž populace velkou diverzitu, a proto by se mělo hodně uplatnit křížení, které povede k rychlému nalezení daleko lepších jedinců. Když se toto neděje, tak k nalezení lepších jedinců dochází pouze mutacemi, které jsou však spíše lokálního významu a nelze od nich očekávat radikální vylepšení. Mutace by se měly výrazněji uplatňovat až v další fázi evoluce při „dolaďování“ dat.

Na základě průběhu grafu evoluce je třeba zvážit možné změny v parametrech evoluce.

Dochází-li ke snížení diverzity populace, je možné zkusit:

• zvýšit procento mutací, počet opakování a maximální počty řádků, kterých se týkají;
• zvýšit velikost populace a/nebo zvýšit velikost turnaje (viz výše);
• přidat výsledek jiného běhu evoluce jako Data Preset a vynutit jeho stálou přítomnost v populaci.

Zůstává-li dlouhodobě stejná hodnota fitness aktuálně nejlepšího jedince, je možné:

• snížit velikost turnaje.