Masarykova univerzita Fakulta informatiky Studijní obor: Informační systémy
IMPLEMENTACE HRY MYSLÍM SI ZVÍŘE Implementation of the 20 Questions Game
Diplomová práce
Vedoucí diplomové práce: Autor: RNDr. Zuzana Nevěřilová Štěpán PŘICHYSTAL
Brno, 2014 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samo- statně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Štěpán Přichystal
Poděkování Rád bych na tomto místě poděkoval vedoucí diplomové práce paní RNDr. Zuzaně Nevěřilové za odborný dohled, cenné rady a dostatek prostoru pro vlastní iniciativu. Rovněž poděkování patří i mým blízkým za podporu a poskytnutí potřebného zázemí během tvoření této práce. Jméno a příjmení autora: Štěpán Přichystal Název diplomové práce: Implementace hry Myslím si zvíře Název práce v angličtině: Implementation of the 20 Questions Game Katedra: Katedra informačních technologií Vedoucí diplomové práce: RNDr. Zuzana Nevěřilová Rok obhajoby: 2014
Anotace Předmětem diplomové práce je implementace počítačové verze hry Myslím si zvíře a zamě- ření se na oblast her s účelem. Myšlenkou her s účelem je využití široké komunity pro řešení konkrétního problému prostřednictvím jednoduché hry. Úkolem implementované hry je budování znalostní báze obsahující znalosti o objektech reálného světa a jejich vlastnostech. Algoritmus hry je založen na hledání podobností objektů pomocí metrik založených na geometrickém modelu dat. Hra využívá lexikální databázi WordNet či sémantickou síť ConceptNet, která je zdrojem common sense faktů. Data z těchto zdrojů jsou využívána například strategií hry nebo pro automatické generování otázek použitých ve hře. Hra je navržená jako internetová aplikace s cílem oslovit co nejvíce hráčů.
Annotation The subject of the thesis is the implementation of the computer version game Twenty Questions and focus on the area of games with a purpose. The idea of games with a purpose is the use of a broad community to address a specific problem through simple games. The aim of the implemented game is to build knowledge base which contains knowledge of real-world objects and their properties. The algorithm of the game is based on finding similarities of objects, by using metrics and all is based on a geometric model. The game uses a lexical database WordNet, or ConceptNet semantic network, which is a source of common sense facts. Data from these sources are used by strategy of game as well as for automatic generation of the questions which are used in the game. The game is designed as a web application in order to reach high number of players.
Klíčová slova GWAP, hry, Myslím si zvíře, sémantická síť, korpus, geometrický model dat, podobnost objektů
Keywords GWAP, games, Twenty Questions, semantic network, corpora, geometric data model, objects similarity Obsah
1 Úvod...... 1
2 Hry s účelem...... 2 2.1 Úvod...... 2 2.2 Obecně o hrách s účelem...... 2 2.3 Typy aplikací...... 3 2.3.1 Shoda na výstupu (output-agreement)...... 3 2.3.2 Problém inverzní shody (inversion-problem)...... 3 2.3.3 Shoda na vstupu (input-agreement)...... 4 2.4 Příklady aplikací...... 4 2.4.1 ESP Game...... 4 2.4.2 Peekaboom...... 5 2.4.3 Verbosity...... 6 2.4.4 20Q ...... 7 2.4.5 Akinator...... 8
3 Analýza a návrh...... 8 3.1 Požadavky na na aplikaci...... 9 3.1.1 Základní notace, poznámky k pojmům ...... 10 3.2 Výběr počátečních dat a iniciálních znalostí ...... 11 3.2.1 Použité zdroje...... 12 3.2.1.1 WordNet...... 12 Struktura...... 12 Rozsah dat a použití v projektu...... 13 3.2.1.2 ConceptNet...... 15 Struktura...... 15 Rozsah dat a použití v projektu...... 16 3.2.1.3 Wikipedia, DBpedia...... 17 Použití v projektu...... 17 3.2.1.4 Doplňující zdroj...... 17 3.2.1.5 Přehled využití zdrojů...... 18 3.3 Reprezentace znalostí...... 19 3.3.1.1 Výpočet váhy relace...... 20 3.4 Generování otázek...... 23 3.4.1 Požadavky...... 23 3.4.2 Možné přístupy...... 24 3.4.3 Princip generování...... 25 3.4.3.1 Gramatika otázek...... 26 3.4.3.2 Možné problémy...... 27 3.5 Strategie hry...... 28 3.5.1 Obecný algoritmus...... 28 3.5.2 Výběr obecných otázek...... 32 3.5.2.1 Přístup 1: náhodný výběr s filtrem...... 32 3.5.2.2 Přístup 2: výběr na základě rozhodovacího stromu...... 33 3.5.3 Klasifikátor objektů...... 35 3.5.3.1 Podobnost objektů...... 36 Vybrané metriky...... 37 3.5.3.2 Konečný výpočet skóre...... 40 3.5.4 Matice otázek...... 41
4 Implementace...... 43 4.1 Architektura...... 43 4.2 Serverová část...... 44 4.2.1 Popis...... 44 4.2.2 Hlavní aplikace...... 44 4.2.2.1 Modul QCore...... 45 4.2.2.2 Modul QGenerator...... 47 4.2.2.3 Modul QConnector...... 47 4.2.2.4 Modul QHelper...... 48 4.2.3 Webové rozhraní...... 48 4.2.3.1 Popis technologie, použití API...... 48 4.2.4 Databáze...... 50 4.2.5 Nastavení, export dat...... 51 4.3 Klient...... 52 4.3.1 Popis...... 52
5 Statistiky hraní hry...... 54 5.1 Srovnání s 20Q...... 56
6 Závěr...... 57
Použité zdroje...... 59 Přílohy...... 63 Elektronické přílohy...... 66 1 Úvod V současnosti je vyžadováno, aby velká část aplikací využívala více či méně umělou inte- ligenci. Součástí této umělé inteligence může být i využití lidských znalostí o objektech reálného světa a jejich vlastnostech. Za takovou znalost můžeme považovat například větu Kočka má ráda mléko. Jsou to tzv. common sense fakta – informace, které si počítače jen těžko dovedou odvodit a získáme je pouze zkušeností nebo ústním podáním. Málokdy je však máme tak formalizované, aby je počítačové programy mohly použít. Jedním z cílů mojí diplomové práce je právě snaha o vytvoření databáze obsahující znalosti lidí o objek- tech reálného světa a jejich vlastnostech s následným poskytnutím těchto dat ostatním aplikacím. Takovou databázi bych mohl tvořit manuálně vlastními silami. Pořízení velkého množství takových dat je však pro jednotlivce téměř nemožné, ale již uskutečnitelné pro komunitu. Příkladem může být celosvětová internetová encyklopedie Wikipedie1, na jejíž tvorbě pracují dobrovolní přispěvatelé z celého světa. Otázkou zůstává jak zařídit, aby lidé byli motivovaní data vytvářet. Za tímto účelem vznikla velice zajímavá myšlenka, motivovat lidi prostřednictvím jednoduchých her. Touto myšlenkou se zabývá oblast GWAP – game with purpose. Volně přeloženo principem GWAP je řešení lehce zpracova- telného úkolu pro člověka zábavnou formou v rámci jednoduché hry. Využití tohoto prin- cipu prostřednictvím implementace hry Myslím si zvíře je hlavním cílem práce. Počítačová verze hry Myslím si zvíře je hra o dvou rolích – hadač a tajnůstkář. Tajnůstkář si myslí tajný objekt a počítač v roli hadače se objekt pomocí kladení otázek, na které lze odpovědět ano či ne, snaží uhodnout. V úvodní části diplomové práce se zabývám samotnou myšlenkou GWAP aplikací. Nejobsáhlejší část věnuji analýze a návrhu hry zahrnující popis postupů při výběru iniciálních dat z existujících zdrojů, automatickému generování otázek pro hru a popisu algoritmů strategie hry. Dále rozebírám problémy zajímavé z hlediska návrhu hry, se kterými jsem se musel během vývoje vypořádat. Jedním z nich je vypořádání se s nedo- statkem dat. Aby hra mohla od počátku své existence smysluplně tipovat hráčovi tajné objekty, musí mít o nich dostatečné množství znalostí, získaných z již existujících zdrojů. Dalším úskalím jsou automaticky generované otázky kladené hrou. Otázky musejí být smysluplné a gramaticky správné. Pro tento účel aplikace používá speciální šablony otázek a gramatická pravidla určující například členy či předložky obsažené v otázce. Neméně důležitý úkol je vypořádání se s nejistotou hráčovy odpovědi. Pod tím si představme, že hráči odpovídají na stejné otázky různě, přesto hra musí objekt uhodnout. Předposlední kapitola je věnována stručnému popisu architektury aplikace a jeho implementaci. Na závěr jsem se pokusil shrnout výsledky hraní her v podobě statistiky a srovnání s podobně zaměřenou hrou.
1 Wikipedia (http://www.wikipedia.org/) 1 2 Hry s účelem
2.1 Úvod
Lidé po celém světě stráví hraním miliony hodin denně [1]. Položme si ale otázku, jestli čas strávený tímto způsobem má kromě hráčova uspokojení nějaký pozitivní efekt? Jak uvádí L.Von Ahn v [2] „...people play the games not because they are interested in solving an instance of a computational problem, but because they wish to be enterta- ined“. Z valné většiny případů hraní her žádný pozitivní efekt nemá a právě za tímto účelem vstupuje do herního světa zajímavý koncept GWAP – game with a purpose. Volně přeloženo – hry s účelem. Tento přístup se snaží přeměnit energii vynaloženou hraním her na něco užitečného. Hraním her sleduje nějaký konkrétní účel. Tím může být počítačem těžko zpracovatelný či nevyřešitelný problém, který je však snadno řešitelný pro člověka zábavnou formou. Dalším případem je velice náročný problém, který není schopen vyřešit jednotlivec či malá skupina lidí. Právě v těchto případech může pomoci hra využívající lidské výpočetní síly a spojující tisíce herních výsledků [3]. Cílem GWAP je tedy využití hry tak, aby směřovala k výpočtu konkrétního úkolu a výstupem bylo správné řešení. Průkopníkem v této oblasti je Luis von Ahn, který tento princip obecně nazývá jako human-based computation – využití lidského výpočet- ního výkonu. Počítač v podstatě zadá lidem úkol a následně zpracovává získaná data, která vznikla na základě lidského úsilí.
2.2 Obecně o hrách s účelem
Můžeme se setkat s nejrůznějšími typy těchto aplikací. V zásadě je lze klasifikovat do tří typů jejichž princip je stručně popsán v následujícím oddílu. Prakticky všechny typy aplikací mají požadavek na dostatečně širokou hráčskou základnu. Jednak za účelem většího sběru dat, ale také aby hráči spolu mohli hrát v reálném čase. Často je totiž potřebné vytvářet náhodné dvojice reálně existujících spoluhráčů. Tento předpoklad je ovšem obtížně splnitelný zejména v samotných počátcích hry, nebo pokud je hra v jazyce, který má málo mluvčích. Nesplnění tohoto předpokladu se může řešit následovně. Během hraní hry se provádí záznam akcí jednotlivých hráčů. Jakmile pak chce hráč hrát a nemá protivníka, spáruje se s virtuálním hráčem chovajícím se právě podle předem získaného záznamu. Další variantou může být, že roli partnera plní počítač a simuluje tak chování protihráče [4].
2 Předpokladem úspěchu hry je její zábavnost a schopnost hráče motivovat hrát opakovaně. Tato skutečnost vede kromě většího sběru dat i k přesnějším výsledkům. Motivaci a hratelnost lze zvýšit pomocí různých prvků zvyšujících hratelnost a soutěživost. Příkladem může být časové ohraničení hry, bonusové body, zlepšování vlastností hráče, zasazení hry do příběhu, týmová hra a další [5].
2.3 Typy aplikací
2.3.1 Shoda na výstupu (output-agreement)
Na začátku jsou z celé množiny hráčů Hráč 1 Hráč 2 náhodně utvořeny dvojice. V každém kole hry je oběma hráčům z dvojice předložen stejný vstup vstup vstup. Na základě tohoto vstupu se hráči snaží vyprodukovat stejný výstup aniž by mohli mezi sebou jakkoliv komunikovat. Úspěch nastává v okamžiku, kdy během určitého časového (t )výstup (t )výstup 1,1 1,1 2,1 2,1 rozpětí hráči vyprodukují stejný výstup. (t )výstup (t )výstup 1,2 1,2 2,2 2,2 Výstupem mohou být například klíčová slova (t )výstup (t )výstup popisující obrázek. Toto je typický vzor pro hru 1,n 1,n 2,n 2,n ESP Game (2.4.1) [4]. Obrázek 1: Ilustrace principu hry typu output-agreement. Hra končí úspěchem pokud výstup1,n = výstup2,n [4].
2.3.2 Problém inverzní shody (inversion-problem)
Jako v předchozím případě jsou na začátku hry vybráni dva hráči z celé množiny hráčů. Hráč 1 Hráč 2 Jeden hráč se ujme role tajnůstkáře druhý role (t )výstup 1,1 1,1 hadače. Tajnůstkář obdrží vstup, na jehož vstup (t )výstup základě produkuje výstupy pomáhající hráčovi 1,n 1,n v roli hadače uhodnout vstupní objekt. Jinými slovy pomocí výstupů od tajnůstkáře se hadač snaží vyprodukovat výstup rovnající (t )výstup (t )výstup 1,1 1,1 2,1 2,1 se vstupnímu objektu tajnůstkáře. Tím hra dojde (t )výstup 2,2 2,2 do úspěšného konce. Vedlejší efekt je sběr dat (t )výstup 1,n 1,n (t )výstup poskytovaných tajnůstkářem o vstupním objektu. 2,n 2,n Do tohoto modelu her spadají např. hry Obrázek 2: Ilustrace principu hry typu Peekaboom (2.4.2), Verbosity (2.4.3), ale i 20Q inversion-problem. Hra končí (2.4.4), kde roli hadače zaujímá počítač [4]. úspěchem, pokud výstup2,n = vstup [4].
3 2.3.3 Shoda na vstupu (input-agreement)
Na začátku jsou opět z celé množiny hráčů Hráč 1 Hráč 2 náhodně vybrány dvojice. V každém kole hry je oběma hráčům předložen jeden vstup. Pouze vstup vstup 1 2 samotná hra ví, zda jsou vstupy stejné či nikoli. Hráči se snaží pomocí přesného popisu jejich vstupu zjistit, jestli mají na vstupu oba totožný objekt nebo ne. Je tedy v zájmu hráčů vstup (t )výstup (t )výstup popisovat co nejpřesněji, aby se navzájem zjis- 1,1 1,1 2,1 2,1 tilo, zda jsou objekty shodné. Vedlejším efektem je sběr dat o vstupních objektech na základě (t )výstup (t )výstup 1,n 1,n 2,n 2,n popisu objektů samotnými hráči. Příkladem hry == nebo <> == nebo <> tohoto typu je například TagATune2, kde jako vstup hráči obdrží písničku a pomocí jejího Obrázek 3: Ilustrace hry typu slovního popisu se snaží navzájem zjistit, zda input-agreement. Úspěch nastává v jejich písně jsou shodné [4]. případě, že vstup1 = vstup2 [4].
2.4 Příklady aplikací
V následujícím oddílu stručně představím principy některých her, které jsou nejtypičtějšími zástupci z oblasti GWAP. Některé zřejmě již neexistují nebo nejsou již veřejně dostupné, proto je nelze dohledat, ale hodí se jako ukázka podstaty a myšlenky GWAP.
2.4.1 ESP Game
Obrázky na webu představují nemalou část jeho obsahu, která je ovšem těžko zpra- covatelná. Abychom mohli s obrazovými daty smysluplně pracovat, je nutné je mít doda- tečně označené například popiskem (štítkem), který většina obrázků na internetu neob- sahuje nebo je stručný popřípadě matoucí. Mít obrazová data obsahující popisky se hodí v mnoha případech. Například u vyhledávání obrázků podle obsahu na obrázku, zajištění dostupnosti webů pro zrakově postižené, pro různou kategorizaci obrázků podle obsahu a v mnoha dalších aplikacích. Cílem tedy je mít obrázky opatřené popisky, aniž by se to muselo provádět ručně z důvodu časové náročnosti. A za tímto účelem vznikla hra ESP Game, jejímž autorem je Luis von Ahn [2].
2 Austrian Computer Society (2007) TagATune: a game for music and sound annotation (http://www.cs.cmu.edu/~elaw/papers/ISMIR2007.pdf) 4 Principem hry je slovní popis obrázku zobrazeného hrou. Ze všech připojených hráčů se náhodně vybírají dvojice. Oběma hráčům z dvojice se po určitou dobu zobrazí stejný obrázek (komunikace mezi hráči není možná). Hráči postupně hádají, jakou věc vidí na obrázku, dokud se neshodnou. Tímto jednoduchým způsobem je zajištěno opatření obrázku popiskem. Jak je zajištěna přesnost a smysluplnost získaných dat? Vzhledem k tomu, že se dva náhodně vybraní hráči zcela nezávisle na sobě shodnou na štítku popisujícím obrázek, je pravděpodobné, že štítky budou dávat smysl. Navíc štítek je obrázku přiřazen po shodě více dvojic. Čím vyšší počet dvojic, tím je teoreticky relevantnost popisku vyšší [2].
Obrázek 4: Ilustrace principu hry ESP Game [2].
2.4.2 Peekaboom
Z předchozího oddílu jsme se dozvěděli, že analyzování obrázku zabere člověku na rozdíl od počítače minimální úsilí a to i pokud se budeme bavit o poloze objektů v obrázku. Některé algoritmy na klasifikaci obrazu jsou založené na učení se z velké množiny trénovacích dat (např. neuronové sítě3). V tomto případě z velké databáze obrázků obsahujících informaci o poloze objektů v obrázku. Získání dostatečného množství trénovacích dat v podobě obrázků obsahujících informace je ale opět velmi nákladné. Právě Peekaboom vznikla za účelem vytvoření velice rozsáhlé databáze dat tohoto typu [2]. Princip je hra dvou hráčů, z nichž jeden je v roli peek a druhý v roli boom. Vstupní data jsou obrázky obsahující popisky o objektech v obrázku (např. ze hry ESP game). Hráčovi v roli boom hra zobrazí náhodný obrázek a popisek říkající, jaký objekt na obrázku je. Hráčovi v roli peek se tento obrázek ani popisek nezobrazí. Účelem je, aby boom postupně odkrýval hráčovi v roli peek tu část obrázku (lokalizace objektu), na které je objekt popisovaný štítkem. Peek se tento odkrývající objekt snaží uhádnout. Pokud tedy například obrázek obsahuje auto a psa a boom odhalí jen psa, hra jako vedlejší efekt získá
3 Kapitola Adaptivní přístupy k dobývání znalostí, Neuronové sítě [13]. 5 informaci o poloze psa na obrázku. Tímto je zajištěna potřebná lokalizace objektů. Tato data jsou poté použitelná jako trénovací data algoritmů strojového učení. Ukázka ze hry je na obr. 5 [2].
Obrázek 5: Ukázka ze hry Peekboom. Vlevo je částečně odkrývající obrázek hráčem napravo [2].
2.4.3 Verbosity
Důležitou roli v oblasti zpracování přirozeného jazyka hrají databáze obsahující tzv. common sense tvrzení. B. Smith popisuje common sense v [6] slovy: „Common sense is on the one hand a certain set of processes of natural cognition – of speaking, reasoning, seeing, and so on. On the other hand common sense is a system of beliefs (of folk physics, folk psychology and so on).“ My data tohoto typu můžeme chápat jako slovní spojení či fakta dávající smysl podle selského rozumu, které většina lidí chápe stejně bez další potřebné diskuze. Příklady některých faktů [7]: • Musíme být vzhůru, abychom mohli jíst. • U lidí obvykle vidíme nos, ale nevidíme srdce. • Nemůžeme si pamatovat události, které se ještě nestaly. • Věci padají směrem dolů a ne nahoru. • Mějme dvě profese. Buď jedna vychází z druhé, nebo jsou na sobě obě nezávislé.
Jedním z důvodů, proč se počítače zdají být hloupější než lidé, je, že nemají zdravý rozum. Že nemají znalost obrovského množství takových faktů o každodenním životě, které by mohly snadno použít. Dlouhodobé snažení je naučit počítače správně používat tento druh znalosti, aby se staly inteligentnějšími. Existují projekty zabývající se sběrem common sense tvrzení. Například od roku 1984 je to projekt CyC založený D. Lenatem nebo ConceptNet (Open Mind Common Sense) od roku 1999, jehož základy položili P. Singh, C. Havasi a další [8]. Vytvoření takové znalostní databáze bylo i cílem hry Verbo- sity.
6 Hra Verbosity je opět pro dva hráče, kdy jeden je v roli vypravěče a druhý v roli hadače. Obě role jsou střídavě zastoupeny počítačem. Na začátku je vypravěčovi přidělené tajné slovo, jež se snaží popsat hadačovi. Ten na základě nápověd tajné slovo hádá. Nápověd je na začátku sedm a každá je jiného typu (sedm typů relací). Popisováním tajného objektu vypravěčem se získávají smysluplná fakta o tajném objektu. Hra je časově omezena a po vypršení časomíry si hráči střídají role. Ukázkový příklad je na obr. 6. Českou alternativou této hry je hra X-Plain [9].
„klávesnice“ Vypravěč (nápověda č.1 – has it) Hadač
„počítač“ Je to mobilní telefon? (tajné slovo) Ne
„hraní“ (nápověda č.2 – is used for)
Je to počítač?
Ano (hra pokračuje novým tajným slovem dokud nevyprší časomíra) Obrázek 6: Ilustrace principu hry Verbosity, kde tajné slovo je počítač.
2.4.4 20Q
Jedná se o počítačovou implementaci hry Twenty Questions, která je výstupem i praktické části mojí diplomové práce. Hra byla oblíbená hlavně v 19. století ve Spojených státech. Později v roce 1940 se stala dokonce předlohou pro úspěšný týdenní program rádia, následně pak v roce 1950 i pro televizní program na stanici WOR-TV (dnes My9)4 v USA [10]. Smyslem hry je uhodnout objekt, na který hráč myslí. Druhá strana o jednom nebo více hráčích může pokládat zjišťovací otázky, na které lze odpovědět ano, ne, možná/nevím. Zavádějící či lživé odpovědi nejsou povoleny. Pokud hráč pokládající otázku uhodne správnou odpověď, vyhrává a role se vymění. Pokud hadač během dvaceti otázek neuhádne, prohrál a role se do dalšího kola nemění.
4 My 9nj (http://www.my9nj.com/) 7 Hra vychází z předpokladu, že k popisu libovolného objektu stačí 20 bitů [10]. Odpověď na otázku (kladná či záporná) je reprezentovaná jedním bitem . Pak 220 nám dává 1 048 576 objektů. Tedy pomocí 20 bitů lze reprezentovat více než milion objektů. Proto je nejefektivnější strategie pro hru při každé otázce rozdělit množinu objektů ideálně na poloviny. Princip můžeme například přirovnat k vyhledávání pomocí binárního stromu, kdy se v každém kroku zmenší množina hledaných objektů na polovinu [11]. Hra 20Q je rozdílná v tom, že roli hadače zaujímá počítač. Hru vymyslel v roce 1988 Robin Burgner za účelem testování umělé inteligence. V roce 2004 byla pak zpra- cována jako přenosná elektronická hra a zároveň v podobě webové stránky5. Hra pravdě- podobně funguje na základě nějakého algoritmu strojového učení, ale bližší informace nelze dohledat. Je možné, že dokonce používá umělou neuronovou síť, jak uvádí logo na webových stránkách. Do roku 2014 hra byla hrána více než 87 milionkrát. Na webu lze hrát v několika jazycích včetně českého jazyka. Kromě standardní hry, kde se hádají objekty reálného světa jako zvířata, rostliny a minerály, je možné hrát i v něko- lika populárních oblastech jako např. Simpsonovi, Disney nebo StarTrek. Dalším rozdílem proti originální hře je širší výběr odpovědí hráče, jenž si myslí tajný objekt: pravdě- podobně ano, pravděpodobně ne apod.
2.4.5 Akinator
Hra6 je principem podobná hře 20Q s tím rozdílem, že je zaměřená na známé osobnosti. Tuto hru uvádím zejména kvůli podobnosti pravidel s implementací mojí hry. Zda si dává za úkol budování znalostní databáze s pozdějším využitím, se mi nepodařilo dohledat, ale zřejmě slouží spíše ke komerčním účelům. Pravidla jsou totožná jako u 20Q, tzn. roli hadače plní počítač a člověk si myslí nějakou známou osobnost. Díky populárnímu tématu a zobrazování fotek tipovaných osobností je hra velice zábavná. Za vznikem (2007) stojí tři francouzští programátoři. Dnes (2014) je statistika hraní hry na úctyhodných více než 204 milionech odehraných her. Stejně jako 20Q, je možno na otázku odpovídat kromě ano, ne, nevím také pravděpodobně ano, pravděpodobně ne atp.
5 20Q (http://20q.net/) 6 Akinator, The Web Genie (http://en.akinator.com/) 8 3 Analýza a návrh
3.1 Požadavky na aplikaci
Následuje volně rozepsané zadaní praktické části. Na aplikaci nebyly kladené striktní požadavky ve všech směrech, ale naopak zadání mi poskytovalo dostatek volnosti a prostor k improvizaci. Cílem aplikace (hry) je: • Implementovat hru Myslím si zvíře tak, aby ji mohl hrát člověk s počítačem v roli hadače. • Implementovat vhodnou strategii kladení otázek. • Správně uhádnout objekt s co nejmenším počtem otázek. • Vypořádat se s nejistotou hráčovi odpovědi (za prvé hráč může mít nesprávné znalosti o tajném objektu, který si myslí a za druhé různí hráči odpovídají na stejné otázky různě). • Pokud je to možné, implementovat hru tak, aby se se zvyšujícím počtem odehraných her zvýšila i účinnost strategie kladení otázek.
Kapitola postupně pojednává o nejdůležitějších bodech při návrhu aplikace. Důraz je také kladen na popis mnohých problémů, které se během návrhu hry vyskytly, a jejich řešení. Následující diagram zobrazuje abstraktní návrh fungování aplikace. Detailnější diagramy strategie kladení otázek a podobně naleznete v oddílu 3.5.1.
Začátek hry R – výsledek { „Pokračuj“, „Prohra“, „Výhra“ T =NováHra() } T – identifikátor konkrétní hry Q – informace o následující otázce
R ==“ Výhra“ - || Q =ZískejOtázku(T) R ==“Prohra“ + R =ZískejOdpověď(Q) UložHerníData(T)
Konec hry
Diagram 1: Abstraktní vývojový diagram zobrazující princip fungování aplikace.
9 3.1.1 Základní notace, poznámky k pojmům
V průběhu následujícího textu jsou rozebírány principy hry a data obsažená ve hře pomocí termínů, které jsem v rámci návrhu zavedl (významy všech uvedených termínů jsou kvůli odlišení v následujícím textu značeny kurzívou). Poznamenám, že pro zjedno- dušení je hra zaměřena prozatím na doménu zvířat: • objekt – Jedinečný objekt, který je možné ve hře hádat. Představme si hierarchii tříd zvířat jako stromovou strukturu, kde koncové uzly jsou zvířata, která již nemají další podtřídu. Nekoncové uzly tvořící strukturu stromu jsou jejich nadtřídy. Příkladem koncového uzlu je golden retriever a jeho nadtřídou je nekoncový uzel retriever, který má jako nadtřídu dog. Hra umožňuje hráčovi myslet si jak koncové, tak nekoncové uzly jako tajný objekt. V našem pojetí tedy budeme objekt chápat jako jakýkoliv uzel z tohoto stromu. • vlastnost – Vlastnost objektu, mimo jiné slouží i k vygenerování otázky ve hře. V textu budu příklady konkrétních vlastností zapisovat ve formátu:
.
10 3.2 Výběr počátečních dat a iniciálních znalostí
Pro implementaci a fungování hry potřebujeme získat množinu objektů, které jsou možné ve hře hádat, vlastnosti objektů, relace mezi objekty a vlastnostmi a gramatická pravidla pro otázky kladené ve hře. Další data jsou potřebná jako počáteční znalosti, bez kterých by hra jen velice špatně fungovala. Ukažme na zjednodušeném příkladě, kde by mohl být problém. Vezměme v úvahu, že hráč si myslí 1 objekt z 50 a každý objekt má 20 vlastností (unikátní i společné s jinými objekty dohromady. 1 vlastnost = 1 otázka ve hře). Pravdě- podobnost, že hra položí náhodně takovou otázku, která radikálně zmenší množinu možných objektů bez počátečních znalostí, je velmi malá. Příklad: • Celkový počet vlastností cca 600, Počet vlastností na objekt cca 20. • P(hra položí jednu relevantní otázku během 1 pokusu): P = 20/600 = 0,03 • P(hra položí jednu relevantní otázku během 20 pokusů): P= 1- P(nepoloží žádnou relevantní) = 1- (580/600)^20 = 0,51 Tedy efektivita hry bez počátečních znalostí by byla velmi malá a relevantní znalosti by se tím pádem získávaly z počátku velice pomalu. A proto je potřeba mít v kladení otázek systém. Například nejdříve klást obecné otázky, tj. takové, které radikálně zmenší množinu možných objektů, upřednostňovat otázky s pravděpodobností kladné odpovědi a ty, na které je jen vzácně odpovězeno nevím atp. Toto nám umožní právě iniciální znalosti vyjádřené zejména váhou jakou přísluší jednotlivé vlastnosti ke konkrétním objektům. Stál jsem tedy před úkolem najít vhodné zdroje poskytující tato data. S postupem času jsem se přiklonil zabývat se zdroji v anglickém jazyce, které jsou proti zdrojům v českém jazyce obsáhlejší. Hra je z toho důvodu v anglickém jazyce. Tento fakt může podle mě přispět i ke snadnějšímu získávání nových hráčů mimo hranice ČR. Ve spojitosti s výběrem zdrojů a počátečních dat se v následujícím textu vyskytuje pojem ontologie. Předem je nutno říci, že slovo ontologie je převzato z filosofie, kde je jím nazývána disciplína týkající se jsoucna a bytí. Do informatiky byl pojem převzat a s původním filosofickým pojmem ontologie je jen volně spjat [13]. Uvedeme si definici podle T. Grubera: „An ontology is an explicit specification of a conceptualization.“[12]. V ní je požadováno, aby konceptualizace7 byla specifikována explicitně, tedy aby znalosti vyjádřené ontologií byly přístupné i ostatním a nikoli jen ukryté v hlavě autora. W.Borst definici dále modifikoval: „An ontology is a formal specification of a shared conceptua- lization“[14]. Tato definice klade požadavek jednak na formalizaci tj. použití jazyka s přesně danou syntaxí a tedy možností zpracovávat ontologii pomocí výpočetní techniky.
7 Ontologie je především konceptualizací vymezující, které objekty budeme v řešení uvažovat, jaké mají vlastnosti a v jakém vztahu jsou s jinými uvažovanými objekty [13]. 11 Dále klade požadavek na sdílenost tj. ontologie není individuální záležitost, ale měla by být výsledkem konsensu určité zájmové komunity.
3.2.1 Použité zdroje
Po prohledání volně dostupných zdrojů jsem výběr zúžil na čtyři zdroje. WordNet 3.0, ConceptNet 5, Wikipedia (DBpedia), a-z-animals.com. Pro účely získání počátečních dat a iniciálních znalosti jsem vyhledával téměř pouze strojově zpracovatelné a struktu- rované zdroje. Jejich stručný popis a účel použití v projektu je popsán v následujících oddí- lech.
3.2.1.1 WordNet WordNet je velká lexikální databáze či sémantická síť pro anglický jazyk. Je vyví- jena na Princetonské univerzitě8, kde ji založil americký psycholog George A. Miller již v polovině roku 1980 [15].
Struktura WordNet seskupuje slova podle svého významu a slovního druhu do skupin tzv. synsetů. Synsety jsou skupiny synonym, slov se stejným významem. Skládají se z jednoho či více slov stejného slovního druhu (podstatná jména, slovesa, přídavná jména a příslovce). Každý synset je identifikován následujícím zápisem
Následuje příklad všech nalezených synsetů, do kterých je zařazeno slovo dog. U každého synsetu je citována definice jeho významu. Data jsou získána z databáze WordNet 3.0 [15]: • dog.n.01 – „a member of the genus Canis (probably descended from the common wolf) that has been domesticated by man since prehistoric times; occurs in many breeds“ • frump.n.01 – „a dull unattractive unpleasant girl or woman“ • dog.n.03 – „informal term for a man“ • cad.n.01 – „someone who is morally reprehensible“ • frank.n.02 – „smooth-textured sausage of minced beef or pork usually smoked; often served on a bread roll“ 8 Princeton University (http://www.princeton.edu) 12 • pawl.n.01 – „a hinged catch that fits into a notch of a ratchet to move a wheel forward or prevent it from moving backward“ • andiron.n.01 – „metal supports for logs in a fireplace“ • chase.v.01 – „go after with the intent to catch“
Tedy slovo dog se objevuje hned v osmi různých smyslech a je vždy obsaženo v seznamu lemmat konkrétního synsetu. Každý synset obsahuje seznam lemmat, který obsahuje slova v základním tvaru se stejným významem jaký zastupuje daný synset. Dále databáze WordNet obsahuje mnoho lexikálních a sémantických vztahů v závislosti na slovních druzích. Vztahy se vyskytují jak mezi synsety, tak mezi lemmaty v rámci synsetů. Výčet nejdůležitějších vztahů pro jednotlivé slovní druhy: • podstatná jména – hyperonymum, hyponymum, holonymum, meronymum, souřadné pojmy • slovesa – hyperonymum, souřadné pojmy, troponymum, vyplývání • přídavná jména – příbuzné podstatné jméno, podobnost • příslovce – příbuzné přídavné jméno
WordNet také nabízí velké množství funkcí pracujících s hierarchií slov. Umožní například najít, jak blízko jsou dva synsety na základě nejkratší cesty v hierarchii (hyponym a hypernym) vyjádřené číslem v intervalu <0; 1>. Dalším zajímavým údajem může být například podobnost smyslu dvou synsetů založená na hloubce těchto smyslů v hierarchii, počítáno od nejnižšího společného uzlu a další [16].
Rozsah dat a použití v projektu WordNet ve verzi 3.1 je volně použitelný pod vlastní licencí9 a dostupný prostřednic- tvím mnoha knihoven různých programovacích jazyků. Ve své práci používám pro přístup k databázi knihovnu NLTK 3.010 v jazyce Python. WordNet ve verzi 3.0 obsahuje 155 287 slov uspořádaných do 117 000 synsetů [15]. V mém projektu našel WordNet dvě uplatnění: 1) Použití jako zdroj objektů, které je možné ve hře hádat – V tomto případě jsem využil výhodné struktury hierarchicky seřazených slov na základě vztahů hypernymum a hyponymum. Jako výchozí uzel jsem manuálně zvolil synset animal.n.01, který je hypernymem pro všechny zvířata v databázi. Poté jsem rekurzivně prošel celý graf od kořenu (animal.n.01) až po jeho listy vždy na základě hyponym aktuálního uzlu. Z takového seznamu synsetů, které pokládám za objekty ve hře, jsem použil i všechna jejich lemmata. Tato lemmata používám
9 License and Commercial Use of WordNet (http://wordnet.princeton.edu/wordnet/license/) 10 Natural Language Toolkit (http://www.nltk.org/) 13 jako synonyma k jednotlivým objektům reprezentovaných konkrétním zvířetem. U takto získaných dat se však vyskytly problémy: • Velké množství uzlů/zvířat – Rekurzivní průchod s kořenovým uzlem – synsetem animal.n.01 vrátil 3998 uzlů. To znamená téměř čtyři tisíce zvířat, která by hra měla umět uhádnout. Např. uzel dog.n.01 obsahuje 189 potomků (viz obr. 7) a cesta pro nejhlubší uzel od uzlu dog.n.01 vypadá násle- dovně: ◦ dog.n.01 --> hunting_dog.n.01 --> terrier.n.01 --> wirehair.n.01 --> welsh_terrier.n.01 --> sealyham_terrier.n.01
Obrázek 7: Vizuálně znázorněná hyponyma synsetu dog.n.01 v síti WordNet pomocí reálných dat. Graf vygenerovaný pomocí knihovny NetworkX (https://networkx.github.io/).
Po úvaze jsem se rozhodl takové množství redukovat ze dvou důvodů. Podle mě si většina hráčů nebude myslet tak velice speciální případy jako např. welsh terrier, ale spíše pouze nadřazený pojem – dog. Druhým důvodem jsou jen velice malé rozdíly ve vlastnostech poddruhů jednotlivých zvířat. Tím chci naznačit, že všichni psi mají čtyři nohy, srst a dobrý čich. A jen těžko bych získával nějaký zdroj dat, který by popisoval distinktivní rysy např. pro určité plemeno psa (např. že zlatý retrívr miluje vodu a plavání). Dále je potřeba vzít v úvahu, že samotní hráči pravděpodobně neznají velmi speciální druhy zvířat a tím pádem si je ani nebudou ve hře myslet jako tajný objekt. Data jsem tedy omezil vynecháním listových uzlů. To vyřadilo velkou část velice speciálních druhů zvířat, ale zároveň ponechalo dostatečně velký výběr a to 1055 objektů. U tohoto naivního vyfiltrování mohlo dojít k odfiltrování i zvířat běžně myšlených hráčem. Z tohoto důvodu aplikace nabízí v případě absence vložení nových zvířat do hry samotným hráčem, a tak postupné rozšiřování databáze o chybějící zvířata.
14 • Nežádoucí uzly – Rekurzivní průchod zahrnoval i nežádoucí uzly dělící zvířata do různých kategorií: work_animal, domesticated_animal, carnivore, omnivore, atp. Nežádoucí jsou z toho pohledu, že hráči mají za úkol myslet si spíše konkrétní druh zvířete než nadtřídu zvířete (podrobnější popis viz definici termínu objekt v oddílu 3.1.1). V tomto případě jsem žádné explicitní filtrování dat neprováděl a nechal to na hře samotné. Pokud si tyto uzly budou hráči určovat za tajný objekt jen zřídka, hra je časem nebude ani tipovat. 2) Zdroj vlastností objektů – Další uplatnění WordNetu jsem našel částečně jako získání vlastností pro objekty. Využil jsem sémantického vztahu meronymum (vztah celek-část). Ke všem objektům získaným pomocí rekurzivního průchodu jsem získal data (ne ve všech případech existovala) popisující z čeho se zvíře skládá, tedy jejich vlastnosti. Např. meronymem pro synset bird.n.01 je feather.n.01. Tyto získané vlastnosti objektů považuji za směrodatné a relaci objekt- vlastnost jsem přiřadil počáteční váhu 80 %11.
3.2.1.2 ConceptNet ConceptNet je velká sémantická síť obsahující pojmy ve formě slov či slovních spojení propojené sémantickými vztahy. Vznikl spojením hned několika zdrojů: projektu Open Mind Common Sense12, DBpedia13, WordNetu14, dat z hry Verbosity a dalších zdrojů. Data jsou dostupná v mnoha různých jazycích, kde největší podíl má angličtina [17].
Struktura ConceptNet má strukturu grafu. Uzly jsou reprezentovány pojmy a hrany vypovídají o existenci vztahu mezi dvěma pojmy v závislosti na zdroji a reprezentují znalost. Hrana je určitého typu říkající, jakým způsobem lze použít tvrzení v textu. Více o těchto vztazích v oddílu 3.4 o generování otázek. Ukázka některých vztahů (celkem existuje 31 vztahů): • RelatedTo – Nejobecnější vztah říkající, že mezi dvěma pojmy A a B je nějaký pozitivní vztah, ale ConceptNet nedokáže určit jaký přesně. • IsA – Pojem A je hypernymum pojmu B. • PartOf – Vyjadřuje vztah, že pojem A je meronymem pojmu B. • AtLocation – Říká, že pojem A se typicky může nacházet na místě reprezentovaném pojmem B.
11 Váha relace se během hraní her upraví, pokud si hráči opravdu budou myslet o relaci že je pravdivá, časem nabude hodnoty blížící se ke 100 %. 12 Open Mind Common Sense project (http://openmind.media.mit.edu/) 13 The DBpedia Knowledge Base (http://DBpedia.org/About) 14 What is WordNet? (http://WordNet.princeton.edu/) 15 Příkladem tvrzení může být: pojem dog => typ vztahu Desires =>pojem bury bone. Tedy databáze obsahuje znalost, že psi touží zahrabávat kosti. O pojmech a těchto tvrzeních lze vyčíst různé informace např.: • jaký je typ vztahu mezi pojmy, • jak moc je vztah mezi pojmy relevantní (vypočítáváno na základě počtu lidí, kteří ho považují za pravdivý a kteří nikoli), • jak často dané pojmy souvisí s konkrétním typem vztahu, • jakého jazyka se pojem/tvrzení týká, • v jakém gramatickém kontextu se pojem nejčastěji vyskytuje viz 3.4.3.1.
Rozsah dat a použití v projektu ConceptNet aktuálně existuje ve verzi 5 a je volně použitelný pod licencí Creative Commons licenses15. Databáze ConceptNet je dostupná buďto prostřednictvím webového API16 ve formátech JSON17, CSV18, nebo skrze knihovny nejrůznějších programovacích jazyků. Obsahuje 460306 pojmů a 828251 tvrzení (počítáno v rámci všech jazyků). Já jsem si pro přístup do databáze zvolil knihovnu ConceptNet 4.019 v jazyce Python. Databázi WordNet jsem využil ke dvěma účelům: 1. Získání vlastností objektů – Na základě objektů, které hra umožňuje uhodnout, jsem pro každý objekt vyhledával v ConceptNetu hrany s ním spojené předem vybraných typů (viz tabulku 2 na straně 27). Pokud hrana obsahovala určité minimální skóre20, použil jsem pojem touto hranou spojený jako vlastnost objektu. Tyto vlastnosti jsem později použil na vygenerování otázek konkrétních typů. Více o generování otázek v oddílu 3.4. 2. Získání počátečních znalostí – ConceptNet je hlavním zdrojem pro získání počá- tečních znalostí hry, které je úzce spojeno s generováním otázek. Postupoval jsem podobným způsobem jako v bodu jedna. Pro každou dvojici objekt/vlastnost ve hře jsem vyhledal v databázi ConceptNet odpovídající pojmy a hranu mezi nimi. Skóre21 hrany jsem použil jako počáteční znalost. Pomocí těchto údajů se vypočí- tává váha relace mezi objektem a vlastností ve hře (viz 3.3).
15 License (http://creativecommons.org/licenses/by-sa/3.0/) 16 ConceptNet 5 API (https://github.com/commonsense/ConceptNet5/wiki/API) 17 RFC (2006), The application/json Media Type for JavaScript Object Notation (http://www.ietf.org/rfc/rfc4627.txt) 18 RFC (2005) Common Format and MIME Type for Comma-Separated Values (CSV) Files (http://www.ietf.org/rfc/rfc4180.txt) 19 http://csc.media.mit.edu/docs/ConceptNet/overview.html 20 Hodnota vyjadřující relevantnost vztahu daného hranou mezi pojmy v ConceptNetu. Vypočítána na základě poměru počtu lidí považujících vztah za pravdivý a počtu lidí považujících vztah za nepravdivý. 21 Viz předchozí poznámka č.20. 16 3.2.1.3 Wikipedia, DBpedia Wikipedia22 je mnohojazyčná (přes 280 jazyků) otevřená webová encyklopedie, jejíž obsah vytvářejí sami uživatelé. Začala vznikat již v roce 1995 jako webové stránky, kam mohl každý uživatel svobodně přispívat. Dnes Wikipedia obsahuje přes 4,4 milionů anglických článků tvořících 14,5 % celkového počtu článků na Wikipedii [18]. DBpedia23 je projekt zabývající se získáním strukturovaných dat na základě infor- mací z Wikipedie, který vznikl v roce 2007. DBpedia ukládá data ve formátu RDF 24 a dnes (2014) obsahuje přes 2,49 bilionů trojic RDF popsaných pomocí vlastní ontologie. Na těchto datech umožňuje provádět sofistikované dotazy pomocí dotazovacího jazyka SPARQL25 a propojovat je s dalšími datovými zdroji na webu [19].
Použití v projektu Původním záměrem bylo ve velké míře využít strukturovaná data z DBpedie. Podrobnějším zkoumáním jsem však zjistil absenci potřebných common sense tvrzení (viz 2.4.3) jako obsahuje ConceptNet. Z DBpedie se nedozvím, že pes touží zahrabávat kosti, což je typ dat pro účel hry potřebný. Navíc data tohoto typu podle mě podporují hratelnost. Kdyby byly otázky postaveny jen na dotazech, zda zvíře patří do té či oné kategorie (což by ontologie DBpedie umožňovala), hra by zábavná moc nebyla. Navíc tato data mně poskytl i ConceptNet a částečně WordNet. I přestože články z Wikipedie nejsou dobře strojově zpracovatelné, pro jeden jsem v projektu našel využití26. Protože hru jsem zaměřil na doménu zvířat, hodily se mi infor- mace o zvucích zvířat, které jsem z tohoto zdroje poloautomaticky zpracoval a použil na generování otázek. Data sice slouží jen jako doplňkový zdroj, ale otázky zaměřené na zvuky zvířat mohou být příjemným zpestřením hry.
3.2.1.4 Doplňující zdroj Za účelem dostatečného množství dat jsem hledal další různé zdroje obsahující relevantní data. Nejlepším kandidátem na doplňující zdroj se stala encyklopedie zvířat: a-z-animmlas.com. Za účelem získání přístupu k databázi jsem kontaktoval správce, kteří mi takový přístup bohužel ale neposkytli. Dali mi však svolení, veškerý obsah z webu použít. Stránky podobně jako Wikipedia obsahují články s infoboxy27 s informacemi o zvířatech. Použití těchto dat je předmětem rozšíření hry do budoucna.
22 Wikipedia ( http://en.wikipedia.org/wiki/Wikipedia) 23 The DBpedia Knowledge Base (http://DBpedia.org/About) 24 Kapitola Ontologie a sémantický web, RDF [13]. 25 Kapitola Ontologie a sémantický web, Dotazovací jazyk SPARQL [13]. 26 List of animal sounds (http://en.wikipedia.org/wiki/List_of_animal_sounds) 27 Infobox je tabulka obsahující základní data o předmětu článku. 17 3.2.1.5 Přehled využití zdrojů Na závěr uvádím přehled zobrazující konkrétní data o využití jednotlivých zdrojů. Tabulka obsahuje procentuální vyjádření počtu objektů a vlastností použitých ve hře v závislosti na použitém zdroji. Protože objekty mohou do hry přidávat i samotní hráči, zahrnul jsem uživatele hry jako jeden ze zdrojů.
Tabulka 1: Zastoupení jednotlivých zdrojů dat použitých ve hře ke dni 25.3.2014 Zdroj Objekty (1075) Vlastnosti (897) WordNet 98,3 % 11,9 % ConceptNet 0 % 77,9 % Wikipedia 0 % 10,1 % Uživatelé hry 1,7 % -
Graf 1 zobrazuje počty vlastností na konkrétní objekty. Vlastnost je započítána, pokud relace je relevantní alespoň ze 60 %. Z grafu je patrné, že většina objektů má dvacet a méně vlastností. Velký počet objektů obsahuje naprosté minimum (jednotky) vlastností a zhruba dvěma třetinám zvířat nepřísluší žádné vlastnosti. To se týká velmi speciálních druhů zvířat např. dogfish, polychaete, shrew, nuthatch, guillemot a dalších. Částečné řešení problému vidím v pokusu o odvození vlastností na základě nadtříd těchto objektů. To by vyžadovalo využití vztahu hypernymum/hyponymum například ze sítě WordNet. Na druhou stranu si myslím, že hráči si budou tyto velice speciální druhy zvířat myslet jen zřídka. Pokud by tomu tak nebylo, časem by měly tyto objekty vlastnosti získat právě na základě odehraných her.
200 180 160
t
k
e
j 140
b
o
a 120
n
í
t
s 100
o
n
t
s 80
a
l
v
t 60
e
č
o
P 40 20 0 1 1 1 2 1 1 1 2 6 3 2 3 2 2 3 3 2 3 28 47 762 1 1 1 1 1 5 1 1 3 1 4 1 4 1 2 1 4 5 27 31 115 Počet objektů Graf 1: Počet vlastností na objekt. Relace mezi objektem a vlastností má v tomto případě váhu alespoň 60 %.
18 3.3 Reprezentace znalostí
Vytvoření znalostní databáze je jedním z hlavních cílů této práce. Při navrhování struktury databáze a zejména reprezentace znalostních dat jsem vycházel hlavně z faktu, že databázi bude používat hra za účelem hádání objektů vybraných vlastností. Základní princip strategie hry byl od počátku navrhnut jednoduše. Během hry bude vybráno nějakým způsobem maximálně 25 vlastností objektů a na základě nich se vyberou nejvíce vyhovující objekty. Nezabýval jsem se zatím složitějšími mechanismy jako je například odvozování znalostí z dat a jeho využitím ve hře. Za tímto účelem je vytvářená databáze formálně popsaná pomocí sémantické sítě. Sémantická síť je obecně chápána jako orientovaný graf28, kde uzly jsou koncepty a hrany jsou relace mezi uzly [13]. Koncepty chápejme jako objekty reálného světa uvažované v konkrétním řešení. Naše řešení je zaměřeno na doménu zvířat a koncepty jsou objekty a vlastnosti. Relace jsou v našem podání vážené relace mající určitý typ (viz poznámky k pojmům v oddílu 3.1.1). Naše síť obsahuje celkem dvanáct typů relací kompletně popsaných v tabulce 2 na straně 25. Tyto typy můžeme rozdělit do dvou skupin: • základní typy – Obecně používané typy relací často se vyskytující v sémantických sítích. Příkladem může být IsA vyjadřující, že objekt A je druhem objektu B (hypo- nymum, např. dog je hyponemem pro animal). Nebo relace typu HasA říkající, že objekt A má jako svou část objekt B (meronymum, např. wing je meronymem bird). • typy závislé na doméně – V našem případě typy potřebné pro modelování relací v doméně zvířat. Příkladem je typ Desires vyjádřující touhu objektu A po objektu B (např. cat touží po milk). Nebo typ DoSound vyjadřující, že objekt A dělá zvuky zastoupené objektem B (např. dog vydává zvuk bark).
Kromě znalostí uložených v relacích mezi objekty a vlastnostmi považuji za znalosti i data shromážděná v rámci každé řádně odehrané hry. Sbírám informace o tom kolikrát bylo na po sobě jdoucí otázky odpovězeno kladně, kolikrát záporně, jak dlouho hra trvala, kdo ji hrál apod. Data tohoto typu jsou také využívána strategií hry (viz 3.5.4). Následující sekce je věnována relevantnosti neboli váze relace mezi objekty a jejich vlastnostmi. Každý objekt je v relaci s každou vlastností ve hře. Data si můžeme představit jako matici, kde objekty tvoří řádky a vlastnosti sloupce matice. To, jak moc konkrétnímu objektu konkrétní vlastnost přísluší, vyjadřuje právě váha relace. Čím větší má váha hodnotu, tím je relace relevantnější (např. váha 50 % znamená, že polovina hráčů považuje relaci za relevantní, zatímco druhá ne). Každý objekt je reprezentován vektorem hodnot
28 Pojmem orientovaný graf se v teorii grafů označuje takový graf, jehož hrany jsou uspořádané dvojice. 19 vah jednotlivých relací. Zjednodušeně si situaci můžeme představit i jako diagram či graf na obr. 8.
Vlastnosti: 88% Desires_drink-milk 23%
95% 55% CapableOf_jump-fence Objekt:dog Objekt:cat 67% 89% AtLocation-kennel 5% 95% DoSound-bark
Obrázek 8: Vizualizace několika ukázkových relací mezi objekty dog a cat a vlastnostmi zachycující váhu relace v procentech.
3.3.1.1 Výpočet váhy relace Váha relace se vypočítává na základě počtu hráčů myslících si o konkrétní vlastnosti, že patří ke konkrétnímu objektu a počtu myslících si opak. Tyto dva údaje se získávají z jednotlivých her během kladení otázek. Hráč myslící si konkrétní tajný objekt během hry vlastně vyjadřuje svůj postoj, jestli daná vlastnost podle něho myšlenému objektu odpovídá či nikoli. Získání procentuální hodnoty váhy je založeno na upravené29 logistické funkci. Logistická funkce je často používaná v empirických vědách pro modelování růstu populací, koncentrací apod. Proměnná x zpravidla zastupuje čas a y velikost nějaké populace. Funkce je definovaná jako [20]: 1 f (x;a,b)= , b>0 (3.1) (1+e−(a+bx))
Stručně popíši charakteristiky této funkce. Definiční obor je ℝ , obor hodnot je tvořen intervalem (0, 1). Funkce je spojitá a rostoucí na celém svém intervalu. Para- metr a určuje posunutí funkce podél osy x. Parametr b určuje strmost křivky v okolí bodu a 1 [ ; ] . Pro svůj výpočet používám logistickou funkci s upravenou strmostí, kde parametr b 2 a = 0, b = 5. Funkce je vynesená na grafu 2.
29 Tato upravená funkce se často nazývá sigmoida a je to speciální případ logistické funkce. 20 Graf 2: Zobrazení logistické funkce s upravenou strmostí, pomocí které se provádí výpočet váhy relace.
Osu y si představme jako váhu relace (zatím nevyjádřenou v procentech). Osa x je vyjádřena hodnotou vypočítanou z celkových počtů kladných a záporných tvrzení o konkrétní relaci objekt/vlastnost zohledňující celkový počet tvrzení podle vzorce:
p−n x = , p∈ℕ: p≥0,n∈ℕ:n≥0,( p+n)>0 (3.2) p+n
Kde p je počet kladných tvrzení a n počet záporných tvrzení a x ∈<-1; 1>. Pomocí upravené logistické funkce (viz graf 2) dostaneme na základě vypočítané hodnoty x váhu relace vyjádřenou v procentech (po vynásobení hodnotou sto).
21 Na následujících třech příkladech nastíním výpočet váhy relace na ukázkových znalostních datech (z důvodu úspory místa uvádím výpočet pouze u prvního příkladu). Představme si, že výpočet je pro tři náhodné objekty: a, b, c a jejich vlastnost například – HasA_wings (a z ní vygenerovanou otázku – Does it have wings?).
Zadání: a) objekt a: p = 7, n = 4 b) objekt b: p = 55, n = 51 c) objekt c: p = 55, n = 1
Řešení:
a) ( p−n) (7−4) 3 x= = = =0,272 ( p+n) (7+4) 11 1 1 f (x)= = =0,79375 1 (1+e−(5∗x)) (1+e−(5∗0,272))
v1=0,79375∗100≈79 %
b) v2=0,54703∗100≈55 % c) v3=0,99200∗100≈99 %
Všimněme si, že v příkladu a) i b) je p-n = 3. Tedy součet kladných tvrzení mínus součet záporných je v obou případech stejný, výsledná váha však nikoli, protože do výpočtu je zahrnuta relativní četnost tvrzení. V příkladu b) počty kladných (55) a záporných (51) tvrzení jsou z pohledu relativní četnosti prakticky totožné. Proto i váha relace je cca 55 % oproti příkladu a), kde je téměř 80 %. U příkladu c) pak s tvrzením souhlasí většina a tomu odpovídá i váha relace 99 %.
22 3.4 Generování otázek
Podstatnou částí při tvorbě aplikace bylo získání otázek pro samotnou hru. Na kvalitě otázek společně se strategií je závislá efektivita hry a kvalita tvoření znalostní databáze. Jak jsem uvedl v sekci 3.1, předpokladem je uhodnout myšlený objekt (více jak z 1000 možných), během cca dvaceti otázek. Otázky by měly zjišťovat vlastnosti, chování, speci- ální charakteristiku či různé smysluplné kategorie hádaného objektu. Jedině tak může hra konvergovat ke správnému řešení.
3.4.1 Požadavky
Během návrhu hry začaly postupně vznikat určité požadavky na formu, obsah a množství otázek. Některé se možná zdají být samozřejmé, ale jejich splnění nebylo vždy snadné: • Otázky by se měly týkat přímo objektů ve hře. V podstatě logický požadavek. Hra by se neměla rozhodovat na základě otázek nesouvisejících s objekty ve hře. Na druhou stranu i takový způsob by mohl konvergovat k řešení a být zároveň zábavný. Napadá mě jednoduchý příklad (odvodit tajný objekt na základě osobních otázek na hráče): ◦ Do you like pets? – yes ◦ Do you have a cat granule at home? – yes ◦ Is it a cat? – yes (tipovací otázka) I tato strategie by byla za určitých okolností nejspíše možná, ale tento přístup jsem nezvolil. Otázky tedy budou směřovány přímo na vlastnosti, chování a jiné charak- teristiky tajného objektu. • Měly by existovat otázky zjišťující obecné vlastnosti, ale i vlastnosti velice speci- ální. S pomocí obecných otázek typu – Is it mammal? dokáže hra eliminovat velkou část objektů. Díky speciálním typu – Does it make sound like moo? dokáže pak s jistotou určit tajný objekt – cow. • Různorodost otázek. Pokud budou existovat jen otázky pouze na specifické zvuky zvířete, sice dříve nebo později (a to spíše) hra objekt uhodne, ale k hratelnosti to nepřispěje. • Dostatečné množství. Hra by měla pro každý objekt obsahovat alespoň nějaké specifické otázky, aby jej bylo možné přesně identifikovat. Požadavek na množství je důležitý i kvůli použití náhodnosti a zvýšení hratelnosti.
23 • Gramatická a významová správnost. Jeden ze složitějších požadavků. Aby vygene- rované věty dávaly smysl a byly alespoň z větší části gramaticky správné (správné předložky, členy apod.). • Otázky by neměly být duplicitní, tedy ptát se na stejnou věc různým způsobem. Příklad: ◦ It's a four-legged animal? ◦ Does it have 4 legs?
3.4.2 Možné přístupy
V tomto oddílu je popsán zvolený postup získávání otázek. Již při prvních úvahách bylo téměř jisté, že generování otázek nepůjde dělat při takovém množství ručně. Mluvím o stovkách otázek. V úvahu tedy připadal nějaký automatický či alespoň poloautomatický proces. Nyní uvedu možné přístupy, o kterých jsem uvažoval (zpočátku ještě nebyla ani představa jakým způsobem budou objekty reprezentovány viz 3.3). Uvádím všechny od těch takřka nerealizovatelných nápadů, až po postupy použité v projektu: • Manuální tvoření otázek pomocí skupiny dobrovolníků. Pro samotného člověka je manuální vymýšlení otázek z časového hlediska náročné, pro skupinu lidí je to již přijatelnější úkol. Tento přístup by byl však časově náročný a pokud by nebyli lidé motivováni finančně, tak zřejmě nerealizovatelný. • Náhodné generování otázek za pomocí slovníku (např. WordNet) – zřejmě nejméně realizovatelný přístup. Za pomocí vlastní gramatiky popisující několik druhů vět by se automaticky generovaly tázací věty na základě dat ze slovníku. Problém vidím ve způsobu testování smysluplnosti vzniklých vět. Většina kombinací slov ve větě by nedávala smysl. • Generování otázek na základě vztahu hypernymum/hyponymum mezi objekty. Tohle byla první uskutečnitelná myšlenka v době, kdy se rýsovaly smysluplné zdroje dat. Použít libovolný datový zdroj obsahující objekty rozdělené do smyslu- plných kategorií na základě vztahu hypernymum/hyponymum (např. pojem mammal je hypernymem pro objekt dog). Na základě nalezených hypernym by se utvořily otázky, které by zjišťovaly do té které kategorie objekt patří. • Generování na základě vlastností objektů. Objekty jsou v databázi reprezentovány pomocí svých charakteristických vlastností. Např. objekt dog má vlastnost DoSound_bark. Tyto vlastnosti lze jednoduše nalézt v již zmíněných datových zdrojích (3.2.1). Pak je zcela logické na jejich základě vytvořit tázací věty. Podrobnosti o tomto přístupu jsou v následujícím oddílu.
24 3.4.3 Princip generování
Z předchozích uvedených postupů jsem použil pro tvorbu otázek poslední, tedy generovat otázky na základě vlastností objektů ve hře. Při získávání vlastností byly využity zdroje z oddílu 3.2.1. Nyní již máme databázi objektů, vlastností a jejich relací, kde každá relace má určitý typ. Na základě těchto typů vznikají konkrétní typy otázek. Všechny typy relací jsem získal jedním z následujících způsobů v závislosti na zdroji dat: • ConceptNet – Typy relací jsem přebral přímo z typů vztahů mezi pojmy (koncepty). • WordNet – Na základě sémantického vztahu meronymum jsem vytvořil typ HasA. • WikiPedia – Poskytuje data o zvucích zvířat, nadefinoval jsem typ relace DoSound.
Tímto způsobem jsem získal množinu typů na jejichž základě jsem vytvořil šablony tázacích vět. Otázka poté vznikne spojením konkrétní vlastnosti a šablony dle typu relace. Následující tabulka obsahuje seznam všech typů relací a šablon pro konkrétní typy otázek.
Tabulka 2: Seznam všech typů relací a odpovídajících šablon otázek. Typ relace Šablona otázky Počet otázek (897) CapableOf Can it
25 3.4.3.1 Gramatika otázek V této fázi máme k dispozici velký počet relevantních otázek. Zbývá upravit jejich gramatickou správnost. Otázky jsou v databázi reprezentovány jako vlastnosti objektů, u kterých je uložen typ relace (na základě typu se vybere šablona otázky uložená v samo- statné tabulce). Mít u každé vlastnosti celý text otázky by byla redundantní informace. Vlastnosti pro otázky jsou uloženy v základních tvarech. Jedná-li se o sloveso, pak je uloženo jako infinitiv. Jedná-li se o podstatné jméno, pak je v prvním pádě č. jednotného, atd. Pouhým doplněním vlastnosti do patřičné šablony věta mnohdy nedává smysl. Příklad: • šablona – Is it
Následující krok je tedy úprava věty do správného gramatického tvaru (doplnění předložky, čísla, pádu apod.), popřípadě úprava významu celé otázky. Mějme příklad dvou možných významů po gramatické úpravě: • šablona – Does it desire to
Za účelem doplnění gramatiky do otázek jsem se zabýval těmito přístupy: • Použít existující software schopný otázku upravit nejvhodnějším možným způsobem, aby vlastnost vložená v šabloně otázky dávala smysl. Bohužel žádný takový software poskytující tuto funkcionalitu jsem nenašel. Vždy se jednalo spíše jen o softwary určené ke korekci gramatiky. • Dalším řešením by možná bylo prohledávání velkých korpusů. Zaměřit se na výskyt našich konkrétních vlastností ve větách (popř. v textu), udělat u nich gramatický rozbor a zjistit v jaké formě byla vlastnost ve větě použita. Před- pokládám, že by to mohl být reálný, ale časově náročný postup. • Nejsnadnějším řešením bylo použít již existující data. Samotný ConceptNet posky- tuje pravidla, pomocí kterých lze naše vlastnosti použít ve větách. Pro každý pojem obsahuje vždy několik pravidel použitelných v různých kontextech věty. Pro zjednodušení jsem si vybral vždy pravidlo nejčastěji se podle ConceptNetu vyskytující ve větách. I po přiřazení pravidel některé věty nemusejí být zcela 26 gramaticky správné a můžou se vyskytnout i ty, co nedávají smysl. Je to dáno omezeným počtem šablon na otázky, do kterých však vkládám desítky různých vlastností, kde každá může mít jiné pravidlo použití ve větě.
Ve výsledku je celý systém generování poloautomatický proces. Otázky vznikají spojením vlastnosti, konkrétní šablony a gramatického pravidla. Databáze aktuálně obsahuje celkem cca 900 otázek.
1) Vlastnost: IsA_bird-long-leg bird(1) long(2) leg(3)
2) Pravidlo: 1 with 2 3s bird with long legs
3) Šablona: Is it
Obrázek 9: Ilustrace principu generování otázky.
3.4.3.2 Možné problémy U zvoleného postupu tvorby otázek se vyskytla potenciální komplikace a to u klasifi- kačních otázek typu IsA (formát otázky je Is a
Př. 1: Př. 2: Př. 3: 1. mammal (třída), furniture (skupina) plane (skupina) 2. carnivore (řád) seating furniture (skupina) motorless plane (skupina) 3. dog (rodina) chair (skupina/typ ?) glider (skupina/typ ?) 4. retriever (skupina) 5. golden retriever (plemeno) Obrázek 10: Ukázka hierarchie různých objektů.
Obecně pro někoho může být myšlený objekt dog, pro někoho až golden retriever. Někdo si může myslet objekt furniture, jiný konkrétní kus nábytku chair atd. Jak tedy rozhodnout co je ještě smysluplná kategorie nebo již dostatečně konkrétní objekt. Tedy které pojmy použít ještě v klasifikačních otázkách typu IsA a které až v konečné otázce tipující tajný objekt? Musel jsem se vypořádat s těmito situacemi: • Hráč si myslí konkrétní objekt např. dog a v průběhu hra položí klasifikační (nikoli tipovací) otázku typu – Is it a dog? Tím se hra ptá, zda tajný objekt patří do skupiny dog. Hráč odpoví yes, protože to je jeho tajný objekt. Hra však odpověď hodnotí
27 jako odpověď na klasifikační otázku a místo ukončení hry pokračuje v pokládání dalších otázek. ◦ Řešení – Pokud hra pokládá klasifikační otázku typu IsA obsahující vlastnost, která může být zároveň i tajným objektem, zobrazí se hráčovi navíc tlačítko – yes, I think this animal. To umožňuje hře sdělit, že se opravdu jedná o tajný objekt a aplikace může ukončit aktuální hru. • Výjimečně může nastat také opačná situace. Hráč si myslí konkrétní objekt opět např. dog a v průběhu hra položí tipovací otázku – Is it mammal?. Jelikož tajný objekt patří do skupiny mammal, hráč odpoví right (nevšimne si, že se jedná o tipo- vací otázku) a hra se ukončí i přesto, že nebyl přesně uhodnut hráčův tajný objekt. ◦ Řešení – V těchto případech hra nabídne tlačítko typu – right, but continue. To umožňuje hře sdělit, že zvíře patří do tipované skupiny a zároveň hra může pokračovat v pokládání dalších otázek.
3.5 Strategie hry
Text kapitoly pojednává detailně o kompletní strategii hry. Nejdůležitější částí stra- tegie je systém získání následující otázky. Cílem hry je uhodnutí tajného objektu myšleného hráčem ideálně během prvních dvaceti otázek. Strategie získání následující otázky je rozdělena do několika bloků využívajících různé postupy, které budou rozebrány v následujících čtyřech oddílech.
3.5.1 Obecný algoritmus
Pomocí diagramu 2 jsem se snažil zjednodušeně zachytit funkcionalitu metody vracející následující otázku. Vstupem metody je jedinečný identifikátor reprezentující aktuální hru (token), na jehož základě se načte stav aktuální hry. Na základě stavu hry se vygeneruje otázka, která je jako výstup zaslaná klientu.
28 VraťDalšíOtázku(T) T – jedinečný identifikátor hry (token) QC – počet dosud položených otázek
PA – počet kladných odpovědí NačtiStavHry(T) Q – informace o následující otázce
QC < 5 OR Je hra + - (QC < 12 AND připravena hádat? PA < 4) + - „Matice otázek“ „Klasifikátor“ „Klasifikátor“ (Na základě matice odfiltruj (Klasifikuj objekty, ohodnoť (Klasifikuj objekty, ohodnoť otázky s pravděpodobností je pomocí skóre a vyber je pomocí skóre, seřaď a vyber záporné odpovědi) objekt s nejvyšším skóre) několik objektů s nejvyšším skóre)
- Pokud mají + objekty společné vlastnosti AND QC <= 15 „Obecnost otázek“ Vrať vlastnosti Vrať vlastnosti stejné (Ze setříděných vlastností objektu s nejvyšším pro skupinu objektů na základě obecnosti vyber skóre několik nejobecnějších)
+ QC <= 17 - „Matice otázek“
(Podle poslední kladené otázky vyber z matice otázku, na kterou bude pravděpodobně odpovězeno kladně)
Náhodně vyber jednu vlastnost ze seznamu
Q = VraťTextOtázky()
UložStavHry(T)
Návrat Q
Diagram 2: Zjednodušený diagram strategie vrácení následující otázky ve hře.
29 Následuje popis algoritmu pro získání následující otázky. U jednotlivých bloků kódu je uveden hrubý odhad časové složitosti. Do výpočtu nejsou zahrnuta vypočítaná data ve vyrovnávací paměti30 aplikace a dotazy SQL (m – počet objektů, n – počet vlastností, p – počet položených otázek): 1. Na základě jedinečného identifikátoru hry – tokenu se načte stav aktuální hry. Ten obsahuje seznam již položených otázek, jejich odpovědi, informace o hráčovi a další data zaznamenávající aktuální stav hry. Aktuální hra končí, pokud • hra tajný objekt uhodne, • hráč si nepřeje dále pokračovat po nesprávném tipu hry, • hra se vzdá (vždy po pěti neúspěšných tipech). 2. Poté, pokud si je hra dostatečně jistá tajným objektem nebo pokud bylo již položeno více než 17 klasifikačních otázek, hra se pokusí uhodnout tajný objekt. Od dvacáté klasifikační otázky se hra snaží tipovat vždy po každých dvou klasifikačních otáz- kách. Při vymýšlení strategie jsem se snažil o rozumný kompromis mezi co nejrychlejším uhádnutím tajného objektu a mezi dostatečným sběrem dat. Termínem hra si je dostatečně jistá tajným objektem rozumějme, že konkrétní objekt dosáhl určitého skóre (konkrétně hodnoty 1,2 vyjadřující dostatečnou shodu objektu s položenými otázkami). Skóre se vypočítává na základě klasifikátoru (viz 3.5.3). Algoritmus se tedy dále větví podle toho, zda: • Hra je připravena hádat – Pomocí klasifikátoru hra ohodnotí všechny existující objekty pomocí skóre a vybere objekt s nejvyšším skóre. V případě, že vybraný objekt není tajným objektem, je pro aktuální hru zcela vyřazen. (výpočet skóre objektů: O(m·p), seřazení podle skóre: O(m·log m), výběr objektu: O(1), celková složitost: O(m·p+m·log m+1) ) • Hra není připravena hádat – Pokračuje se výběrem následující klasifikační otázky. Následující otázka se vybírá na základě počtu již položených otázek, počtu kladně zodpovězených otázek a na základě vlastností, ze kterých byly otázky vygenerovány. Podle splnění následujících podmínek nastane jeden ze dvou případů získání otázky: ▪ (počet položených otázek < 5) nebo (počet položených otázek < 12 a počet kladných odpovědí < 4) – Otázky se vybírají na základě jejich obecnosti (viz 3.5.2). Snahou je během prvních otázek co nejvíce zúžit množinu objektů kandidujících na tajný objekt. Ideální jsou otázky dělící množinu objektů vždy na dvě skupiny, jejichž počty objektů se blíží poměru 1:1 (polovina skupiny otázce vyhovuje, druhá nikoli). Před samotným výběrem obecných vlastností se vyfiltrují vlastnosti na základě poslední zodpovězené otázky. Filtrují se ty, na které by hráč po vygenerování otázky pravdě-
30 Vyrovnávací pamětí aplikace je v tomto konkrétním případě myšlena souborová keš paměť, která je používána pro ukládání dat, k jejichž vytvoření vedl časově náročný výpočet. 30 podobně odpověděl záporně. Vyfiltrování se děje na základě matic otázek (viz 3.5.4), které tuto informaci poskytnou. Výstupem bloku je jedna náhodně vybraná vlastnost z určitého počtu nejvíce obecných vlastností. Podrobnější postup je rozebrán v následujícím oddílu 3.5.2. (odfiltrování položených otázek z matice: O(n), vyhledání poslední položené otázky v matici otázek: O((n-p)·log(n-p)), vyhledání nevhodných otázek: O((n-p)·log(n-p)), odfiltrování otázek z obecných otázek: O(n), náhodný výběr obecné otázky: O(1), celková složitost: O(n+2·((n-p)·log(n-p)+n) +1)) ▪ Pokud není splněna předcházející podmínka, algoritmus pomocí klasifiká- toru (viz 3.5.3) ohodnotí všechny objekty a vybere ty, jenž mají nejvyšší skóre. Podle těchto objektů se vyberou vlastnosti vhodné pro generování následující otázky na základě podmínek: (výpočet skóre objektů: O(m·p), seřazení podle skóre: O(m·log m), výběr objektu: O(1), celková složitost: O(m·p+m·log m+1) ) • Počet klasifikačních otázek <= 15 – Pro pět objektů s nejvyšším skóre se vyhledá vlastnost, kterou má společnou nejvíce objektů (to zajišťuje postupně výběr pěti nejpřesnějších objektů). Výstupem algoritmu je tato vyhledaná vlastnost. (odfiltrování již položených otázek z matice: O(p), vyhledání společných vlastnosti pro prvních pět objektů: O((n-p)·5), výběr nejvhodnější vlastnosti O(1), celková složitost: O(p+(n-p)·5+(1) ) ) • Počet klasifikačních otázek > 15 – V tomto případě předpokládáme, že po patnácti otázkách již hra dokáže vybrat konkrétní objekt, který může být tajným objektem. Číslo 15 má svoje opodstatnění. Kdyby každou otázkou se množina objektů rozdělila na dvě poloviny, konkrétní objekt bychom získali z množiny tisíce objektů během deseti otázek. Reálně však jedna otázka množinu objektů na poloviny zdaleka nedělí. Předpokládejme tedy, že již po patnácti otázkách je možné se zaměřit na konkrétní objekt. Na základě tohoto objektu je výstupem několik vlastností s největší vahou. (seřazení vlastností podle relevance: O((n-p)·log(n-p)), výběr nejvíce relevantních: O(1), celková složitost: O((n-p)·log(n-p)+1)) • Počet klasifikačních otázek > 17 – V tomto případě se provede jeden algoritmus z předchozích dvou bodů a pokud vrátí více jak jednu vlastnost, provede se navíc výběr na základě matic otázek (viz 3.5.4). Na základě poslední položené otázky vybereme pomocí matic tu otázku, na kterou bude s největší pravděpodobností odpovězeno kladně.
31 (odfiltrování položených otázek: O(n), vyhledání poslední položené otázky v matici otázek: O((n-p)·log(n-p)), vyhledání nejvhodnější otázky: O((n- p)·log(n-p)), celková složitost: O( n+2·((n-p)·log(n-p)))) 3. Pokud algoritmus vrátil identifikátor konkrétního objektu, vygeneruje se tipovací otázka. Pokud vrátil identifikátor konkrétní vlastnosti, vygeneruje se klasifikační otázka (viz 3.4). (vyhledání vlastnosti podle id: O(n·logn), vyhledání objektu podle id: O(m·logm), celková složitost: O(n·logn) nebo O(m·logm)) 4. Uloží se stav aktuální hry a metoda vrací nově vygenerovanou otázku, která je následně zpracována hráčem.
3.5.2 Výběr obecných otázek
Termín obecnost otázek můžeme v našem podání chápat jako schopnost otázky dělit množinu objektů ideálně na dvě stejně velké skupiny. Na základě kladné (nebo záporné) odpovědi na tuto otázku jsou objekty děleny do dvou skupin. Čím více se velikost skupin shoduje, tedy poměr objektů ve skupinách je blížící se 1:1, tím větší je obecnost otázky. Algoritmus klade nejobecnější otázky na počátku hry a to maximálně během prvních dvanácti otázek (viz 3.5.1). U výběru obecných otázek jsem zvažoval dva přístupy roze- brané v následujících dvou oddílech. Při vysvětlování principů obou přístupů je použito značení: • v – konkrétní vlastnost v,
• OV – množina všech existujících objektů v databázi,
• OK – množina kandidátních objektů (objektů vyhovujících položeným otázkám v aktuální hře) na tajný objekt,
• VO(v) – velikost množiny objektů, které mají vlastnost v (relace objekt/vlastnost má velkou váhu),
• ¬VO(v) – velikost množiny objektů, které nemají vlastnost v (relace objekt/vlastnost má malou váhu).
3.5.2.1 Přístup 1: náhodný výběr s filtrem V (v) O . Pro každou existující vlastnost v z databáze vypočítáme poměr ¬V O (v ) Poměr se počítá vždy na základě OV. Během aktuální hry se poměr znovu nepřepočítává například s ohledem na OK (na tomto principu pracuje přístup popsaný v následujícím oddílu). Vlastnosti seřadíme podle nejlepšího poměru (blížícího se 1:1, tedy nejvíce obecné) po nejhorší a po celou dobu aktuální hry se seřazení nemění. Tím získáme vlastnosti nejlépe dělící OV. Díky tomu, že se při rozhodování o výběru otázky v tomto případě nijak nezohledňuje OK, je potřeba se vyvarovat kladení otázek, které nám nepřinesou žádnou 32 informaci. Např. pokud bude kladně zodpovězena otázka – Has it four legs? nemá cenu pokládat otázku (kterou nám může nabídnout algoritmus na základě výše popsaného poměru) – Has it six legs?. Tomu se snažím zamezit použitím matic otázek (3.5.4). Pomocí těchto matic získám vlastnosti, na které by se po vygenerování otázky s největší pravdě- podobností odpovědělo záporně. Tyto vlastnosti vyfiltruji ze seznamu všech vlastností a poté vybíráme náhodně z prvních několika (průměrně z pěti) nejobecnějších. Tento způsob výběru počátečních otázek se mi osvědčil a je použit v algoritmu výběru otázky. Na základě pozorování po dvanácti úvodních otázkách dostatečně zúží OV do cca dvaceti objektů přibližně z tisíce (tyto objekty dosahují skóre více jak 70 % viz 3.5.3.2).
3.5.2.2 Přístup 2: výběr na základě rozhodovacího stromu Hlavní myšlenkou bylo vytvořit rozhodovací strom otázek obsahující od kořene nejobecnější otázky směrem k listům obsahující méně obecné otázky. Uzel by reprezen- toval konkrétní vlastnost, hrana pak odpověď (ano/ne/nevím) na otázku vygenerovanou z této vlastnosti. Vždy podle typu odpovědi by se algoritmus vydal do příslušné větve s následující otázkou. Na rozdíl od předchozího přístupu se poměr, kterým otázka dělí objekty na poloviny, vypočítává pouze na základě OK. Zjednodušený pseudokód 1 popisuje
//řádky jsou objekty, sloupce vlastnosti objektů, //buňky indikují zda objekt má vlastnost nebo nikoli MATICE = objekty a jejich vlastnosti
VytvořStromObecnosti(odpověď) { if hloubka(uzel) < MAX_HLOUBKA odstraň z MATICE: -objekty, které nesplňují odpověď na otázku z nadřazeného uzlu -vlastnost z nadřazeného uzlu uzel.hodnota = VyberNejobecnějšíAtribut()
//vytvoř potomka pro případ, že na otázku v předchůdci //se odpoví kladně uzel.levý = VytvořStromObecnosti(true) //vytvoř potomka pro případ, že na otázku v předchůdci //se odpoví záporně uzel.pravý = VytvořStromObecnosti(false)
return uzel }
VyberNejobecnějšíAtribut() { for vlastnost in všechny zbývající vlastnosti v MATICI poměr(počet zbývajících objektů mající vlastnost, počet zbývajících objektů bez vlastnosti)
return vyber vlastnost s poměrem nejvíce se blížící 1:1 } Pseudokód 1: Pseudokód algoritmu pro konstrukci rozhodovacího stromu obsahující nejobecnější otázky.
33 konstrukci takového rozhodovacího stromu. Pro jednoduchost zanedbávám u otázek možnost odpovědi typu nevím, protože většina objektů má zanedbatelný počet vlastností, kde relace má váhu okolo 50 %. Hlavní výhodou je tedy eliminace zbytečných otázek. Opět pro představu, pokud bude kladně zodpovězena otázka – Has it four legs? nebude již položena otázka – Has it six legs?. Toto chování, jak bylo napsáno výše, je zajištěno tím, že výběr následující otázky
(uzlu) je proveden jen na základě OK. Nevýhodu tohoto přístupu vidím v deterministickém kladení otázek. Jediná možnost, jak přidat prvek náhody, by byla po občasném náhodném výběru otázky zrekonstruovat strom. Na obr. 11 je část zkonstruovaného rozhodovacího stromu z reálných dat. Ve skutečnosti otázky nedělí objekty zdaleka na dvě poloviny (např. uzel s vlastností IsA_mammal dělí v poměru 40:1027). Můžeme proto během hry konkrétní objekt získat již během např. šesti otázek. Ve většině případů však konkrétní objekt či OK o velikosti cca 10 získáme až po mnoha dalších otázkách. Způsobeno je to faktem, že každý objekt má u většiny vlastností téměř nulovou váhu relace, tedy objektu většina vlastností nepřísluší. Tento přístup také neřeší situaci, kdy se hráč a hra neshodnou na odpovědi. Např. hráč si myslí tajný objekt cow a na otázku Can you find it in the zoo? odpoví ano. Hra si ale myslí opak a objekt cow dále nebude uvažovat při rozhodování o následující otázce. Podle mého názoru je tohle chybné chování, protože otázky mohou být co se týče subjektivních odpo- vědí velice sporné. Z důvodu tohoto chování a nutnosti opakované rekonstrukce rozhodovacího stromu při náhodném kladení otázek jsem se rozhodl používat první přístup z předešlého oddílu. Tento přístup navrhuji do budoucna pokusit se optimalizovat a zvážit jeho použití.
kladná odpověď (1) DoSound_chirrup (3) DoSound_howl záporná odpověď (2) AtLocation_africa (číslo) – počet objektů (6) HasProperty_cute (1) DoSound_chirrup (3) CapableOf_jump-fence (2) IsA_carnivore (13) CapableOf_jump (3) IsA_friendly-pet (1) DoSound_chirrup (2) IsA_good jump (7) AtLocation_small-river (2) HasIt_hair (40) AtLocation_zoo (4) CapableOf_lie-around (2) DoSound_chirrup
(6) AtLocation_lap … IsA_mammal (27) IsA_ carnivore
(1027)... (21) IsA_farm-animal ... Obrázek 11: Část stromu obsahující obecné vlastnosti objektů, které zastupují jednotlivé otázky, zkonstruovaný z reálných dat.
mammal – Is it a mammal? howl – Does it make sound like howl? zoo – Can you find it in the zoo? 34 jump fence – Can it jump fences? jump – Can it jump? friendly pet – Is it a friendly pet? carnivore – Is it a carnivore? lie around – Can it lie aroundly doing nothing? cute – Is some of its properities 'to be cute'? lap – Can you find it in a lap? small river – Can you find it in in a small river? farm animal – Is it a farm animal? 3.5.3 Klasifikátor objektů
Klasifikátor jako část aplikace má za úkol seřazení objektů ve hře na základě podobnosti se vstupním vektorem otázek a ohodnocení těchto objektů hodnotou skóre na základě určitých pravidel (viz 3.5.3.2). Pojem klasifikace, od kterého je odvozený název části aplikace – klasifikátor, je v našem případě mírně zavádějící. Klasifikace je většinou uváděna jako rozklad množiny objektů na třídy[21]. Klasifikátor jako součást algoritmu provádí vyhledávání nejvíce podobných objektů ve hře na základě vstupních dat (v našem případě vektoru o n složkách reprezentujících odpovědi na otázky), které chápeme také jako objekt. Spíše by se mělo tedy hovořit o podobnosti objektů. Algoritmus zajišťující tuto funkcionalitu se musí vypořádat s následujícími požadavky: • Při vyhledávání objektů na základě vektorů otázek je potřeba počítat s hráčovou odpovědí, která je v rozporu se znalostí hry. Např. hráč si myslí tajný objekt spider a záporně odpoví na otázku: Has it 8 legs?, na kterou by měl logicky odpovědět kladně. I v takovém případě je žádoucí objekt spider zcela nevyřadit z aktuální hry, i když pavouk má opravdu osm nohou (ne všichni hráči to ale s jistotou vědí). Stačí daný objekt jen znevýhodnit v šanci, že ho hra bude tipovat za tajný objekt. Díky tomuto požadavku byla ze samotného počátku vyřazena zamýšlená metoda klasifikace na základě rozhodovacího stromu31. Ten by takovému chování neodpo- vídal a při odpovědi, která je v rozporu se znalostí hry, by tajný objekt vyřadil. • Každý objekt je reprezentovaný vektorem hodnot vyjadřujícím váhu relace ke všem vlastnostem obsaženým ve hře. Během hry je položeno ale jen maximálně 25 otázek (na základě 25 vlastností). Klasifikaci tedy nelze provádět na základě všech vlastností objektu, ale jen na jejich zlomku z celkového množství (viz 3.3). Díky těmto skutečnostem jsem se zabýval spíše než klasifikačními metodami, metodami hledání podobnosti objektů.
31 Kapitola Adaptivní přístupy k dobývání znalostí, Rozhodovací stromy [13]. 35 3.5.3.1 Podobnost objektů Dále se budeme zabývat podobností objektů. Existují tři základní techniky porovnávání. Na základě [21]: • koeficientu asociace – Používá se jen pro porovnávání objektů charakterizovaných dichotomickými znaky32. Složky vektorů našich objektů však nabývají reálných čísel v intervalu <0;1>. • koeficientu korelace – Další způsob je porovnání pomocí koeficientu korelace sledující vzájemnou závislost porovnávaných objektů. Způsob nepovažuji za vhodný, jelikož objekty se porovnávají pouze pomocí několika málo znaků (vlastností) z celkového počtu znaků objektů. • metrik – Technika používaná v projektu. Při porovnávání pomocí metrik, literatura ([21]) uvádí, že se jedná o porovnávání na základě nepodobnosti objektů . Čím více jsou si objekty podobné, tím menší číslo metriky vracejí. Objekty o n atributech
budeme chápat jako modely v n-rozměrném euklidovském En prostoru.
Zavedeme následující označení: • n – Počet rozměrů. Každý rozměr zastupuje konkrétní vlastnost objektu.
• ax = (ax1, ax2, …,axn) – X-tý objekt reprezentovaný vektorem o n složkách
v n-rozměrném prostoru (objekt může též reprezentovat bod Ax v n-rozměrném prostoru).
• b = (b1, b2,..., bn) – Vektor o n složkách reprezentující odpovědi hráče během hry. Kladná otázka je zastupována hodnotou 1, záporná hodnotou 0 a neutrální hodnotou 0,5. Vektor chápeme také jako objekt, který porovnáváme s existujícími
objekty ax (Vektor může též reprezentovat bod B v n-rozměrném prostoru). • Složky vektorů objektů obsahují vždy hodnotu vyjadřující váhu relace objektu ke konkrétní vlastnosti. Všechny složky mají jednotkovou velikost z intervalu <0; 1>.
Metrika je obecně funkce definovaná na En× En přiřazující každé dvojici bodů (r,s) číslo δ(r, s) splňující tyto čtyři podmínky [21]:
δ (r , s)=0 ⇔ r=s (identita) δ (r , s)≥0 δ (r , s)=δ(r ,s) (symetrie) δ (r , t)≤δ (r ,s)+δ(s,t) (trojúhelníková nerovnost)
32 Znak nabývající pouze dvou hodnot, které se navzájem vylučují. 36 Vybrané metriky Tento oddíl popisuje několik metrik založených na geometrickém modelu dat, kterými jsem se blíže zabýval. Jednotlivé metriky [21]: • Euklidovská metrika – Metrika vychází ze vzdáleností bodů v prostoru. Čím větší je vzdálenost, tím jsou si objekty méně podobné. Metrika je dána předpisem:
n (3.3) 2 δ E( Ax ,B) = ∑ (Axi−Bi) √ i=1
• Lineární metrika – Metrika založená na součtu rozdílů vzdáleností jednotlivých složek vektorů. Je dána předpisem:
n (3.4)
δ L (A x ,B) = ∑∣axi−bi∣ √ i=1
• Sokalova metrika – Metrika vychází z euklidovské vzdálenosti. Je dána předpisem:
2 (3.5) δ ( A , B) δ ( A ,B) = E x S x √ n
• Sup-metrika – Metrika vrací jako výsledek největší hodnotu rozdílu jednotlivých složek vektoru:
(3.6) δ SP( Ax , B) = maxi=1..n {∣axi−bi∣}
• Kosinová vzdálenost – Pro porovnání metrik založených na vzdálenosti, uvádím metriku založenou na úhlu dvou vektorů v n-rozměrném prostoru. Kosinová vzdá- lenost se používá zejména v kladném prostoru, kde nabývá hodnot z intervalu <0; 1>. Tento interval platí pro libovolný počet rozměrů. Čím jsou si vektory podobnější, tím se kosinová vzdálenost zvětšuje (úhel mezi vektory se zmenšuje). Metoda je často využívána na zjišťování podobnosti dokumentů a je dána před- pisem 3.7 [22].
n a ×b a ⋅b ∑ xi i δ (a ,b) = cos(θ) = x = i=1 (3.7) C x n n ∥ax∥×∥b∥ 2 2 ∑ (axi) × ∑ (bi ) √ i=1 √ i=1
37 • Diskrétní metrika – Složky vektoru odpovědí b nabývají jedné ze tří hodnot:
0; 0,5; 1. Nechť jednotlivé složky vektoru ax jsou nahrazeny také těmito hodnotami následovně:
◦ 0 pokud axi ∈ <0; 0,45>,
◦ 0,5 pokud axi ∈ (0,45; 0,55>,
◦ 1 pokud axi ∈ (0,55; 1>. Toto rozdělení intervalu nám dovoluje využít diskrétní metriku, která říká,
že pokud ax a b se rovnají, pak metrika vrací hodnotu 0 jinak 1.
0 pro ax=b (3.8) δ D(ax ,b) = { 1 pro ax≠b
Následuje porovnání metrik na jednoduchém příkladu s ukázkovými daty. Před- stavme si situaci, že hráč si myslí objekt cat a je ve hře u páté otázky. Jednotlivé otázky jsou reprezentovány popořadě vlastnostmi (v závorce hráčova odpověď): IsA_carnivore (yes), IsA_mammal (yes), HasA_four-legs (yes), HasA_hair (yes), CanIt_jump (yes), CanIt_swim (no). Vektor otázek budeme pomocí všech metrik porovnávat s objekty: elephant, dog, cat, bird. Tabulka 3 zobrazuje hodnoty jednotlivých vektorů:
Tabulka 3: Ilustrační příklad objektů reprezentovaných n-složkovými vektory objekty/vlastnosti IsA_carnivore IsA_mammal HasA_four-legs HasA_hair CanIt_jump CanIt_swim b – odpovědi hráče 1,00 1,00 1,00 1,00 1,00 0,00 a – elephant 1 0,30 0,70 0,90 0,60 0,40 0,90 a – dog 2 0,80 0,80 0,90 0,80 0,70 0,70 a – cat 3 0,70 0,80 0,90 0,80 0,90 0,30 a – bird 4 0,60 0,00 0,20 0,50 0,70 0,00
Nyní je potřeba pro každý objekt z tabulky vypočítat podobnost s vektorem odpovědí hráče podle všech uvedených metrik. Obyčejně je vhodné vektory normalizovat33, aby měly jednotkovou normu. Tím se docílí vzájemného posuzování geometrické podobnosti objektů, které je nezávislé na velikosti měřených znaků. V našem případě je tento požadavek nežádoucí, protože nám na velikosti geometrického modelu objektu záleží (záleží nám jak na tvaru, tak na velikosti modelu). Výpočty podobnosti objektů s objektem zastupujícím hráčovy odpovědi jsou vyne- seny v grafu 3, který porovnává jednotlivé metriky. Pozn.: Kvůli porovnání kosinové vzdá- lenosti s ostatními metrikami je výsledek u kosinové vzdálenosti odečítán od hodnoty 1. Dosáhneme tak efektu, že čím jsou si objekty podobnější, tím metrika dává menší hodnotu.
33 Všechny složky vektoru dělíme normou vektoru (vypočítanou pomocí euklidovské vzdálenosti). 38 3,5
3
2,5 Lineární 2 Sokalova Euklidovská 1,5 Sup-metrika Kosinova Diskrétní 1
0,5
0 elephant dog cat bird Porovnávané objekty Graf 3: Porovnání objektů s vektorem odpovědí hráče pomocí jednotlivých metrik.
Z grafu 3 je patrné, že podobnost všech čtyř objektů porovnávaná s vektorem odpo- vědí je všemi uvedenými metrikami hodnocena podobným způsobem. Všechny metriky správně vyhodnocují, že objekt cat je nejvíce podobný vektoru hráčových odpovědí.
Problém vidím u diskrétní metriky δD, která bude vyhodnocovat ax a b jako podobné, pokud všechny složky těchto vektorů budou naprosto shodné. Ve hře by to znamenalo, že pokud hráč odpoví na otázku v rozporu se znalostí hry, jeho tajný objekt bude pro aktuální hru vyřazen (hra se ho již nepokusí hádat jako tajný objekt). V tomto chování můžeme spatřit jistou analogii s vyřazováním objektů na základě rozhodovacího stromu. Metriku z tohoto důvodu považuji za nevhodnou. Teoretický problém vidím i u kosinové vzdálenosti δC, protože se porovnává směr vektorů (ax a b), respektive úhel, který svírají. Může tak nastat situace, kdy vektory sice mají různé hodnoty složek, ale zároveň jsou rovnoběžné a svírají nulový úhel. To by znamenalo, že objekty jsou vyhodnocené jako totožné, ačkoliv tomu tak není (např. ax= (0,5; 0,5), b = (1; 1), δC(ax,b) = 1, tedy úhel vektorů je 0°). Jako nejlépe vypovídající metriky pro naše účely hodnotím ty, jež mají do výpočtu zahrnuty vzdálenosti všech složek vektorů. V algoritmu vycházím tedy z nejjednodušší lineární metriky δL, která pro naše účely postačuje. Výpočet jsem upravil tak, aby vracel hodnotu z intervalu <0; 1> vypovídající, jak moc porovnávané objekty vystihují vektor hráčových odpovědí. Čím větší je hodnota, tím je podobnost vyšší. Vztah pro výpočet:
n (3.9) ∑ 1−∣axi−bi∣ δ (a ,b) = i=1 x n
39 3.5.3.2 Konečný výpočet skóre Kromě výpočtu podobnosti ohodnocuji objekty pomocí skóre, které slouží k určení nejvhodnějších objektů pro tipování tajného objektu. Hodnoty získané z výpočtu podobnosti pro každý objekt ax dále ještě upravuji na základě vlastností (dimenzí) zahrnutých při výpočtu podobnosti. Čím je skóre objektu vyšší, tím má objekt větší šanci, že ho hra bude tipovat jako tajný objekt. Úprava na výsledné skóre se řídí následujícími pravidly: 1) U každé dimenze lze provést přičtení (zvýhodnění), nebo naopak odečtení (znevý- hodnění) skóre o hodnotu maximálně 0,5. 2) Výpočet probíhá podle následujícího vzorce (3.10):
0.5 − kat pro x≥0.7∧ y=0, { kat x∈ℕ: 0≤kat x≤4} 2 x f (x, y)= 0.5 kat , pro x≥0.7∧ y=1, { kat x∈ℕ: 0≤kat x≤4} 2 x (3.10) { 0 jinak n
skóre (ax ,b) = δ(ax ,b) + ∑ f (axi,bi) i=1
Vzorec zajišťuje iteraci přes všechny dvojice porovnávaných složek vektorů ax i b. A pak u každé dvojice: a) Pokud složka vektoru b obsahuje hodnotu 0 (tedy odpověď no) a složka
vektoru ax hodnotu větší jak 0,7, skóre objektu znevýhodníme, protože odpověď hráče je zcela opačná, než odpovědi většiny hráčů. Hodnotu znevýhodnění určujeme na základě třídy vlastnosti odvozené z její obecnosti (viz 3.5.2). Kategorie obecnosti jsou čtyři. Od nejméně obecných vlastností (tedy klíčové vlastnosti pro konkrétní objekt) – kategorie 4 po nejvíce obecné vlastnosti – kategorie 0. Celkové znevýhodnění odečteme od hodnoty podobnosti. b) Pokud složka vektoru b naopak obsahuje hodnotu 1 (tedy odpověď yes)
a složka vektoru objektu ax hodnotu větší jak 0,7, skóre objektu naopak zvýhodníme a to podle pravidel v bodě a). Celkové zvýhodnění přičteme k hodnotě podobnosti. 3) Nakonec provedeme sestupné seřazení objektů podle skóre. Objekt mající nejvyšší skóre je kandidátem na tajný objekt myšlený hráčem.
40 3.5.4 Matice otázek
Součástí strategie (viz 3.5.1) je ve dvou částech algoritmu i rozhodování o výběru následující otázky na základě matic otázek (tyto matice si můžeme představit jako upra- vené matice sousednosti34 zachycující vlastnosti mající mezi sebou vztah vyjádřený hodnotou pravděpodobnosti). Matice existují dvě. Jedna, pokud se rozhodujeme na základě otázky zodpovězené kladně – kladná matice. Druhou použijeme, pokud daná otázka byla zodpovězena záporně – záporná matice. Matice nám poskytují hodnotu pravděpodobnosti z intervalu <0; 1>. Ta vystihuje šanci, že pokud položím otázku x po otázce y (zodpovězené kladně či záporně), tak na otázku x bude odpovězeno kladně. Pravděpodobnost se získává z údajů ukládaných aplikací v rámci každé odehrané hry. Pro všechny dvojice po sobě položených (ne jenom bezprostředně po sobě položených) otázek v aktuální hře zaznamenává počet situací, kdy odpověď je: • u obou otázek kladná (značíme yy), • u první otázky kladná a u následující záporná (značíme yn), • u obou otázek záporná (značíme nn), • u první otázky záporná a u následující kladná (značíme ny).
Pro výpočet hodnoty pravděpodobnosti v každé buňce matice se používá princip založený na logistické funkci stejný jako v oddílu 3.3, proto ho již nebudu dále rozebírat. Jediný rozdíl je ve výpočtu hodnoty x (viz vzorec (3.2)) , kde hodnota je rovna pro: • kladnou matici: yy− yn x = , yy∈ℕ: yy≥0, yn∈ℕ: yn≥0,( yy+ yn)>0 yy+ yn • zápornou matici:
ny−nn x = , ny∈ℕ:ny≥0,nn∈ℕ: nn≥0,(ny+nn)>0 ny+nn
34 Šeda, M. (2003), Matice sousednosti (http://www.uai.fme.vutbr.cz/~mseda/TG03_MS.pdf) 41 Princip použití matic ilustruje příklad na obr. 12. Situace na obrázku ukazuje, že otázka, na základě které se rozhodujeme, byla vygenerována na základě vlastnosti HasProperty_friendly a dejme tomu, že byla zodpovězena kladně (použijeme kladnou matici). Algoritmus výběru následující otázky určil pouze dvě vhodné vlastnosti: DoSound_bark a AtLocation_kennel (matice jsou v průběhu hry filtrovány na základě již položených otázek). Největší hodnotu v průsečíku s vlastností HasProperty_friendly má vlastnost DoSound_bark. Pokud tedy vlastnost DoSound_bark použijeme v otázce, je šance kladné odpovědi 85 %.
vlastnosti vhodné pro generování následující otázky CanIt_ DoSound_ AtLocation_ CanIt_ P ...... swim bark kennel run ...... IsA_insect ... 0,20 0,05 0.03 0.65 HasA_four leg ... 0,55 0,65 0,32 0,81 HasProperty_friendly ... 0,10 0,85 0,70 0,92 CanIt_fly ... 0,37 0,02 0,05 0,47 ...
vlastnost otázky, na základě které se rozhodujeme Obrázek 12: Princip výběru vlastnosti na základě matice otázek (ukázková data).
42 4 Implementace
4.1 Architektura
Architektura aplikace je klasický model klient-server. Samotná hra je koncipována jako webová aplikace obsahující tenký javascriptový klient. Při návrhu architektury jsem se však nechtěl omezovat jen na webový klient a kladl jsem důraz na možnost budoucího rozšíření například i na desktop či mobilní zařízení. Snažil jsem se oddělit funkcionalitu klientu postaveného na libovolné platformě od serveru provádějícího veškeré výpočty, a to prostřednictvím univerzálně použitelného webového rozhraní (dále jen API). Toto rozhraní společně se serverem si můžeme představit jako službu komunikující přes HTTP35 protokol pomocí metody GET36, jak znázorňuje následující obrázek.
REST služba/API Webová stránka HTTP/GET Desktopový klient JSON / XML Hlavní aplikace Mobilní aplikace Databáze
Různé platformy .Net, PHP, Ajax, Java... Nastavení, Export dat Klient Serverová část
Obrázek 13: Ilustrace architektury celého projektu.
V následujících oddílech je rozebírána struktura a funkce jednotlivých části projektu z obr. 13. Nebudu se však zabývat veškerými implementačními detaily, které poskytuje webová dokumentace na přiloženém CD. Poskytnuty jsou spíše diagramy na analytické úrovni zachycující důležité třídy a moduly.
35 RFC (1999), Hypertext Transfer Protocol (https://tools.ietf.org/html/rfc2616) 36 RFC (1999), Hypertext Transfer Protocol, GET (https://tools.ietf.org/html/rfc2616#page-53) 43 4.2 Serverová část
4.2.1 Popis
Serverová část zahrnuje několik objektově orientovaných aplikací napsaných v jazyce Python [23]. Ten jsem si vybral z důvodu snadného naučení a kvůli vhodným knihovnám pro můj projekt. Jednotlivé části: • hlavní aplikace – Zajišťuje veškeré výpočty spojené s hraním hry a chodem hry samotné. Obsahuje programy pro nastavení projektu a export dat. • webové API – Poskytuje webové rozhraní tenkým klientům za účelem volání procedur nadefinovaných serverem. • nastavení, export dat – Umožňuje nastavování aplikace samotné, počáteční inicia- lizaci a exportování herních dat z databáze.
4.2.2 Hlavní aplikace
Hlavní aplikace slouží k udržování aktivních relací hry a jejímu řízení pomocí napro- gramované strategie, ukládání a zpracování herních výsledků, počáteční inicializaci dat hry a komunikaci s databázovým serverem. Seznam použitých externích knihoven: • ConceptNet 537 – Rozhraní přistupující k datábázi ConceptNet. • NLTK 3.0 38 – Knihovna pro práci s přirozeným jazykem, umožňuje přístup k WordNetu. • Scikit-learn39 – Obsahuje algoritmy strojového učení, nástroje na analýzu dat apod. • Django framework40 1.3 – Webový aplikační rámec v jazyce Python. • A další běžně používané knihovny v jazyce Python: MySQLdb41, Numpy42 apod.
V aplikaci jsem často řešil otázku rychlosti z důvodu plynulosti hraní. Mým poža- davkem na rychlost byla prodleva maximálně 2 s při vrácení následující otázky. Některé fragmenty kódu například pracují s maticemi o rozměrech 1060 (objekty) na 890 (vlastnosti), což nám dává téměř milion hodnot. Z toho důvodu hojně využívám kešování dat do souboru43 (dat načtených z databáze, popřípadě dat, jejichž výpočet je časově náročný). Data jsou uchovávána v paměti keš 180 s. K rychlejší odezvě serveru přispívá
37 ConceptNet5 (https://github.com/commonsense/conceptnet5) 38 Natural Language Toolkit (http://www.nltk.org/) 39 Scikit-learn, Machine Learning in Python (http://scikit-learn.org 40 The Web framework for perfectionists with deaflines (https://www.djangoproject.com/) 41 MySQLdb (http://mysql-python.sourceforge.net/MySQLdb.html#mysqldb) 42 NumPy (http://www.numpy.org/) 43 Django's cache framework (https://docs.djangoproject.com/en/dev/topics/cache/) 44 i použití vláken44. Do celkové prodlevy je možné započítat i prodlevu při přenosu poža- davku (ta je však téměř zanedbatelná v závislosti na připojení). K velkému zrychlení (cca 1000 ms) přispěl také přechod z rozhraní CGI45 webového serveru na FastCGI46. To zajistilo minimální časovou prodlevu spojenou s režií. Program se nezavádí do paměti při každém požadavku klientu, ale je v ní neustále načtený. Na základě těchto úprav je prodleva vrácení otázky průměrně cca 450 ms. Diagram 3 znázorňuje čtyři hlavní moduly v rámci hlavní aplikace a jejich závislosti. Funkčnost a struktura jednotlivých modulů je probrána v následujících oddílech.
Diagram 3: Diagram balíčků zobrazující závislosti mezi jednotlivými moduly hlavní aplikace.
4.2.2.1 Modul QCore
Modul QCore tvoří jádro celé aplikace. Obsahuje veškerou logiku hry řídící se stra- tegií probíranou v kapitole 3.5.1.
Diagram 4: Diagram tříd modulu QCore.
44 Higher-level threading interface (https://docs.python.org/2/library/threading.html) 45 W3C (2003), CGI: Common Gateway Interface (http://www.w3.org/CGI/) 46 FastCGI (http://www.fastcgi.com) 45 Popis jednotlivých tříd:
• GameLogic – Přebírá a zpracovává požadavky od rozhraní webové služby. Udržuje relaci aktuálních her pomocí session47, kde identifikátory konkrétních session jsou ukládané v cookie48souborech prohlížeče. Dalším úkolem je získání následující otázky pomocí třídy QuestionSelector a transakční zpracování odehraných her. Protože uložení a zpracování výsledku hry může zabrat více jak šedesát sekund, provádí se asynchronně. Hráč tak může ihned započít další hru.
• QuestionSelector – Kompletně zaštiťuje výběr následující otázky na základě stavu hry. Rozhoduje, zda se hra pokusí tipovat nebo položí klasifikační otázku. Podle aktuálního stavu hry využívá pomocné třídy PropertyGenerality, Classificator, AdjencencyMatrix. Výstupy metod GetNextProperty() těchto tříd slouží jako vstupy metod SetPropertyFilter() ostatních tříd, čímž se zajišťuje postupné zúžení množiny otázek vhodných k výběru.
• PropertyGenerality – Třída zajišťující výběr obecných otázek (viz 3.5.2).
• Classificator – Třída zajišťující výpočet podobnosti a ohodnocování objektů pomocí skóre (viz 3.5.3).
• AdjencencyMatrix – Třída zajišťující výběr otázek na základě matic otázek (viz 3.5.4).
• GameState, Player – Třídy sloužící pro uchování stavu hry a informací o hráčovi. Při ukládání stavu aktuální hry se instance třídy GameState serializuje do JSON a uloží do session na serveru. Při načítání stavu hry se provede vždy deserializace na původní objekt.
• TestBot – Třída implementuje bot, který slouží k simulaci hráče za účelem testování hry. Při vývoji jsem potřeboval alespoň částečně nasimulovat více hráčů hrajících současně nebo odehrání velkých počtů her (např. 1000). Třída umož- ňovala otestování stability a chování hry při stovkách odehraných her. Na začátku hry si bot náhodně vybral zvíře z předem dané množiny. Poté pomocí vlastního rozhraní využíval třídu GameLogic, která mu vracela otázky. Zdrojem znalosti pro bot byla databáze ConceptNet, a protože většina otázek ze hry je právě z tohoto zdroje, byl bot schopen otázky vyhodnocovat (respektive vlastnosti, ze kterých jsou otázky generovány viz 3.4). Jelikož se hra postupem času vylepšuje, tak stávající bot nedokáže již zcela správně reagovat na fungování hry. Dokud se tedy neupraví implementace botu, jeho použití začíná ztrácet smysl.
47 How to use session (https://docs.djangoproject.com/en/dev/topics/http/sessions/) 48 RFC (1997), HTTP State Management Mechanism (http://www.ietf.org/rfc/rfc2109.txt) 46 4.2.2.2 Modul QGenerator
QGenerator je pomocný modul zajišťující veškerou počáteční inicializaci dat pro hru z datových zdrojů a vygenerování potřebných dat v databázi pro chod hry.
Diagram 5: Diagram tříd modulu QGenerator.
Třída GeneratorBase obsahuje pomocné funkce pro ostatní třídy z ní dědící. Třída GeneratorProperty inicializuje vlastnosti ze zrdojů ConceptNet, WordNet a Wikipedia. GeneratorObject na základě kořenového uzlu (synset animal.n.01) generuje všechny objekty ve hře a jejich synonyma. GeneratorRelation pak ukládá typy relací do data- báze. Třídy mají využití i při nastavování aplikace pomocí programu gamesetup.py (viz 4.2.5).
4.2.2.3 Modul QConnector
Modul QConnecotor poskytuje vysoce abstraktní rozhraní umožňující provádět databázové příkazy různého typu včetně transakčního zpracování (implementováno pro databázi MySQL49). Modul při opětovném získávání dat využívá souborovou paměť keš (nastavenou na 180s) za účelem co nejmenších prodlev vracení dat z databáze.
Diagram 6: Diagram tříd modulu QConnector.
49 MySQL (http://www.mysql.com/) 47 Popis jednotlivých tříd:
• SqlMethods – Rozhraní popisující všechny definované databázové příkazy (aktuální počet cca šedesát příkazů)
• Methods – Statická třída implementující veškeré metody rozhraní SqlMethods. Příkazy SQL jsou buď uložené v tříde Query jako řetězec, nebo vznikají dyna- micky přímo v konkrétní metodě třídy Methods.
• Helper – Třída umožňující provádět jeden či více příkazů SQL v rámci jednoho připojení k databázi. Příkazy lze provést i v transakci. Podle typu příkazu SQL (SELECT, INSERT, UPDATE, DELETE apod.) se použije metoda Execu- teNenQuery() – nevrací data, ExecuteScalar() – vrací jednu konkrétní hodnotu nebo ExecuteDataset() – vrací data ve formě pole či matice.
4.2.2.4 Modul QHelper
Modul QHelper obsahuje pomocné statické třídy využívané napříč celou aplikací. Např. třída Utility obsahuje veškeré pomocné funkce (generování UUID50, metody pro zápis do logu, testování datových typů), třída Enums obsahuje veškeré výčty používané hojně v celém projektu apod.
4.2.3 Webové rozhraní
Jak již bylo uvedeno na začátku kapitoly, rozhodl jsem se oddělit serverovou část a klient pomocí webového API. Serverovou část můžeme pak chápat jako službu, ke které přistupujeme pomocí několika málo jednoduchých metod. Tento přístup jsem zvolil hlavně kvůli snadnější implementaci klientů na různé platformy za účelem šíření hry. K webové službě jsem vypracoval podrobnou příručku51, která je k nalezení na webu ale i v doku- mentaci na přiloženém CD. Příručka popisuje, jakým způsobem a v jakém sledu používat jednotlivé metody služby.
4.2.3.1 Popis technologie, použití API Technologicky se jedná o službu založenou na architektuře REST. Obecně REST umožňuje snadný a jednotný přístup ke zdrojům (zdroj můžeme chápat jako část infor- mace, která je jedinečně identifikovatelná) na internetu pomocí volání nadefinovaných procedur ve službě. Tyto procedury se volají pomocí URI. URI je obecně formát pro iden- tifikaci abstraktního nebo konkrétního zdroje mající nějakou identitu. V našem konkrétním případě se pro přístup k procedurám používá metoda GET52 [24].
50 RFC (2005), A Universally Unique IDentifier (UUID) URN Namespace (http://tools.ietf.org/html/rfc4122) 51 Manuál ke službě hry QGame (http://nlp.fi.muni.cz/projekty/qgame/QGame/static/Doc/ApiReference.pdf) 52 RFC (1999), Hypertext Transfer Protocol, GET (https://tools.ietf.org/html/rfc2616#page-53) 48 Webové API je vytvořené pomocí knihovny DjangoREST framework53. Je to knihovna poskytující spoustu funkcionality, vhodná pro vytvoření robustního API. Poskytuje možnosti serializace dat do různých formátů, nastavení bezpečnosti přenosu dat, různé způsoby autentizace a autorizace ke službě a v neposlední řadě webový nástroj pro ladění vlastního API. API hry poskytuje několik málo jednoduchých metod, pomocí kterých lze vytvořit vlastní implementaci hry. Jedná se o metody pro vytvoření nové hry, vrácení následující otázky, zaslání odpovědi apod. Následuje ukázkový příklad volání metody pro vrácení následující otázky ve formátu JSON54.
Požadavek Metoda: GET Hlavička Authorization: Basic cm9vdDoxMjM0 Odkaz na službu: http://nlp.fi.muni.cz/projekty/qgame/api/ Volání služby: getNextQuestion/token=f88196e-993b-4ab0-928a-01bd586a616c?format=json
Odpověď ve formátu JSON { "number": 2, "finish": "no", "text": "Can it jump?", "type": "standard", "viewFinishButton": "no" } Obrázek 14: Ukázka volání metody služby pro návrat následující otázky.
Bezpečnost API je prozatím řešena spíše demonstračně, a to pomocí Basic Authenti- cation55. Ochrana je tedy velmi slabá a je potřeba ji nahradit do budoucna sofisti- kovanějším ověřováním. Veškeré parametry kromě posledního se posílají v URL a oddě- lují lomítkem. Posledním parametrem se sděluje formát, v jakém budou vrácena data. Aktuálně API podporuje formáty JSON a XML56.
53 Django REST framework (http://www.django-rest-framework.org/) 54 RFC (2006), The application/json Media Type for JavaScript Object Notation (http://www.ietf.org/rfc/rfc4627.txt) 55 RFC (1999), HTTP Authentication: Basic and Digest Access Authentication (https://www.ietf.org/rfc/rfc2617.txt) 56 W3C (2003), Extensible Markup Language (xml) (http://www.w3.org/XML/) 49 4.2.4 Databáze
Databáze je navržena za účelem vhodné reprezentace, v našem případě trojic objekt-relace-vlastnost, ve kterých je uložená znalost. Tato znalostní data budou dostupná ke zpracování ostatními aplikacemi. Použitý databázový systém je MySQL 5.157. Na diagramu je znázorněno částečné schéma databáze, kde jsou zachyceny nejdůležitější tabulky. Modré obsahují znalosti o objektech, ostatní jsou důležité pro strategii hry.
Diagram 7: ER diagram zachycující nejdůležitější databázové tabulky.
Popis tabulek na diagramu:
• Question_Objects – Obsahuje všechny objekty ve hře. Každý objekt je reprezen- tován unikátním id, názvem, zdrojem, ze kterého pochází, a příznakem Original, jestli byl vytvořen automaticky při inicializaci databáze nebo vložen uživatelem v rámci hry.
• Question_Property – Obsahuje všechny vlastnosti objektů ve hře. Každá vlastnost má vlastní unikátní id, název, zdroj, ze kterého pochází. Dále id typu indi- kující, v jakých typech vět bude použita, a pravidlo UsingRule definující způsob použití ve větě (viz 3.4.3.1).
• Question_Relation – Obsahuje všechny typy relací mezi objekty a vlastnostmi. Každý typ obsahuje šablonu, pomocí které se generuje otázka daného typu.
57 MySQL (http://www.mysql.com/) 50 • Question_Assertion – Je klíčovou tabulkou databáze. Reprezentuje relaci objekt/vlastnost a obsahuje data na výpočet její váhy navzájem mezi všemi objekty a vlastnostmi. Hodnota váhy relace není v tabulce uložena, dopočítává ji až samotný program. Výpočet váhy relace probíhá podle postupu popsaného v oddílu 3.3.1.1.
• Game_Question_Stat – Obsahuje navzájem všechny dvojice vlastností kladené ve hře po sobě. Ke každé obsahuje údaje o počtu po sobě jdoucích kladných odpo- vědí (atribut YY) na otázky vygenerované z těchto vlastností, záporných odpovědí (atribut YN) atp. Tabulka je zdrojem pro matice otázek (viz 3.5.4).
• Další tabulky: Question_Object_Synonym – Obsahuje pro každý objekt syno- nymum získané z WordNetu. Question_Property_Statistic – pomocná tabulka obsahující rozšiřující údaje o vlastnostech např. jejich obecnost (viz 3.5.2). GameUser obsahuje informace o hráčích a tabulky Game_Archiv a Game_Archiv_Answer slouží pro zaznamenávání údajů o odehraných hrách. Poznámka k primárním klíčům: Každý objekt a vlastnost jsou nyní reprezentované pomocí UUID. Pro snadnější manipulaci s objekty a vlastnostmi do budoucna navrhuji identifikátory založené na otisku z dat. Pak bude možné na základě názvu konkrétního objektu/vlastnosti získat vždy jeho jedinečný otisk (identifikátor). Může to pomoci například snadnějšímu slučování dat z různých zdrojů (výpočet id pro objekt dog by pak mohl probíhat následovně: id = hash('object/dog') = '83aca5ae...').
4.2.5 Nastavení, export dat
Projekt obsahuje dva konzolové programy v jazyce Python, které jsou v kořenovém adresáři projektu. Podrobný popis jejich funkcionality a přepínačů je ve webové doku- mentaci na přiloženém CD, popřípadě v nápovědě programu (přepínač -h). Programy: • gamesetup.py – Umožňuje počáteční inicializaci a celkové zprovoznění projektu. Obsahuje nejrůznější procedury potřebné pro nastavení databáze. Program je nápo- mocný také například pro promazávání nežádoucích dat po testování a pro obnovu dat hry do počátečního stavu (přesný postup inicializace aplikace je k nalezení v dokumentaci). • gameoutput.py – Umožňuje exportovat užitečná data ze hry za účelem dalšího zpra- cování ostatními programy. Například může exportovat informace o všech vlastnostech, objektech či síle relace mezi nimi, nejčastěji myšlené objekty, úspěšnost hry apod. Formát výstupu je CSV58 s možností uložení do souboru.
58 RFC (2005), Common Format and MIME Type for Comma-Separated Values (CSV) Files (http://tools.ietf.org/html/rfc4180) 51 4.3 Klient
Klient je jednoduchá webová stránka využívající metody API (4.2.3) podle určitých pravidel popsaných v referenční příručce API (na přiloženém CD). Přestože podle obrázku 13 na straně 43 je klient od serveru oddělený, reálně je zahrnutý v jednom projektu společně s ostatními částmi aplikace. Tento způsob jsem zvolil jen kvůli usnadnění správy obou aplikací. Klient lze však kdykoliv jednoduše oddělit a umístit na jiný server. Aplikace s hrou je dostupná na adrese: http://nlp.fi.muni.cz/projekty/qgame/.
4.3.1 Popis
Dynamická část klientu je naprogramována pomocí Django frameworku 1.359 v jazyce Python. Statická část v HTML60, CSS61 a javascriptu s využitím knihovny jQuery62. Web obsahuje několik stránek poskytujících informace o hře, statistiku her a informace pro vývojáře. Samotnou hru tvoří převážně javascriptový kód. Volání všech metod služby probíhá asynchronně. Následující třídní diagram zachycuje javascriptové jádro aplikace – třídu GameCore a rozhraní k metodám služby, které se volají pomocí třídy ConnectorAjax.
Diagram 8: Diagram tříd tenkého javascriptového klientu.
Za účelem šíření hry a zvýšení hratelnosti jsem se soustředil na následující úkoly: • Propojení se sociální sítí – Webovou stránku jsem propojil se sítí Facebook63 pomocí dostupných nástrojů pro vývojáře64. Na začátku hry se aplikace pokusí zjistit, zda má uživatel účet na síti Facebook a popřípadě uložit id jeho účtu. To je ukládáno kvůli možné pozdější využitelnosti a dohledání dalších informací o uživa- telovi. • Design stránek – Nemalé úsilí jsem věnoval návrhu designu stránek. Myslím, že jednoduchý líbivý design vystihující účel webu dokáže uživatele zaujmout, nebo uživatele alespoň po příchodu neodradí.
59 Django documentation (https://docs.djangoproject.com/en/1.3/) 60 HTML (http://www.w3.org/html/) 61 CSS (http://www.w3.org/Style/CSS/) 62 What is jQuery? (http://jquery.com/) 63 Facebook (https://www.facebook.com/) 64 Documentation (https://developers.facebook.com/docs/) 52 • Přístupnost mobilních zařízení – V dnešní době velkou část přístupů na internet tvoří mobilní zařízení. Zobrazení kompletní webové stránky a natož hraní na malém displeji však bylo téměř nemožné. Upravil jsem tedy aplikaci za účelem správného zobrazování a pohodlného hraní na malých displejích pomocí tzv. responzivního web designu65. Ukázky kompletní aplikace a mobilní verze jsou v příloze. • Název hry – Pro snadnější šíření hry je důležité, aby měla jednoduše zapamatova- telný název a doménu. Já jsem zvolil název QGame odvozeno ze slov: question game. Bohužel doména (http://nlp.fi.muni.cz/projekty/qgame/) aktuálně nemá ideální podobu a navrhuji ji do budoucna zaměnit za jednodušší.
65 Beginner’s Guide to Responsive Web Design (http://blog.teamtreehouse.com/beginners-guide-to- responsive-web-design) 53 5 Statistiky hraní hry Kapitola obsahuje statistiky na základě her odehraných v období necelých tří měsíců (únor – duben 2014). Závěr kapitoly věnuji malému srovnání se hrou 20Q66, která je v podstatě také implementací hry Twenty Questions (viz 2.4.4). Statistické údaje pocházejí jednak ze samotných dat aplikace, ale také z údajů služby Google Analytics67 umožňující monitorování přístupů na web (statistiky webu se týkají pouze jediné stránky obsahující samotnou hru)
Tabulka 4: Zobrazení statistik odehraných her za období únor 2014 až duben 2014 Pozorovaná statistika Hodnota Poznámka Návštěvy celkem 772 Unikátní návštěvy 321
Počet dohraných her 346 Počítají se jen zcela Míra úspěšnosti hry 60,4 % dokončené hry a bezchybně uložené. Případy, kdy hra uhádla na: Nelze vyloučit případy, kdy – 1. pokus 56,4 % hráč myslel na jiný objekt – 2. pokus 19,1 % než tipovala hra, ale i přesto – 3. pokus 9,5 % ukončil aktuální hru s tím, – 4. a více pokusů 15,0 % že tipovala správně. Počítáno z odehraných her, kdy hra zvítězila (60,4 % případů) Průměrná délka hry: – v případě uhodnutí 213 s – v případě prohry 346 s
Poměr pohlaví: Statistika mužů je zkreslená – ženy (průměrný věk) 24,1 % (32,72 let) faktem, že u 26 odehraných – muži (průměrný věk) 75,9 % (22,3 let) her nebyly nastaveny údaje o pohlaví a věku. Tedy byly použity výchozí hodnoty (pohlaví: muž, věk: 4 roky). Přístup podle typu zařízení: – desktop 88,7 % – mobily + tablety 11,3 %
66 20Q (http://20q.net/) 67 Google Analytics (http://www.google.com/analytics/) 54 Pozorovaná statistika Hodnota Poznámka Pět nejčastěji myšlených 1. horse (20) Číslo v závorce udává počty objektů hráči 2. cat (18) případů kolikrát byl objekt 3. elephant (13) myšlen jako tajný objekt. 4. pig (10) 5. dog (10)
Počet nových objektů přidaných 19 objektů hráči
Počet zodpovězených otázek: – kladně 3166 – záporně 4701
Celkový počet získaných tvrzení 7867 Myšleno jako celkový počet zodpovězených otázek během řádně dokončených her (započítány jsou i opakující se tvrzení např. že pes má čtyři nohy).
Graf 4 zobrazuje počty návštěv webu a počty odehraných her během období leden 2014 až duben 2014. Z grafu je patrné, že návštěvnost stránek je velice nárazová a od toho se odvíjí také počet odehraných her. Vyšší počty návštěvnosti bylo dosaženo zejména po umístění odkazu například na Facebook nebo rozeslání odkazu okruhu mých známých.
60
50 Návštěvy Odehrané hry
n
e 40
d
a
z 30
v
ě
t
š
v 20
á
n
t
e
č 10
o
P 0 1. 11 21 3. 13 23 2. 12 2.2 .2 .2 3.2 .3 .3 4.2 .4 01 .20 .20 01 .20 .20 01 .20 4 14 14 4 14 14 4 14 Datum měření Graf 4: Počty návštěv webové stránky a počty odehraných her během 3 měsíců.
55 5.1 Srovnání s 20Q
Na závěr bych rád porovnal svoji hru s dlouho zavedenou hrou 20Q68 založenou na stejné myšlence a pravidlech. Údaje o hře 20Q jsem získal pozorováním při hraní nebo přímo z webu, na kterém je umístěna.
Tabulka 5: Porovnání mého projektu s podobnou hrou 20Q Pozorovaná vlastnost QGame 20Q Hra zaměřena na téma Zvířata Zvířata, Rostliny, Minerály, Ostatní. První otázka se vždy ptá na jednu z těchto kategorií Jazyk Angličtina Angličtina, Němčina, Francouzština, Čeština a 18 dalších Počet odehraných her 346 88,6 milionů Úspěšnost hry 60,07 % Udávaná na webu 80 %, při položení 25 otázek až 98 % První tip tajného objektu Od 15. otázky Zaznamenal jsem nejdříve od 16. otázky Po nesprávném tipnutí Ano Pravděpodobně ano objektu je objekt vyřazen ze hry? Počet neúspěšných tipů, než 5 5 se hra vzdá Možnost vložit nový objekt do Ano Ne hry Zobrazuje synonyma při Ano Ano tipování objektů Možnost myslet si konkrétní Ne Ne existující instance (např. auto značky Audi) Typy odpovědí Yes, No, Yes, No , Unknown, Irrelevant, Unknown Sometimes, Maybe, Probably, Doubtful, Usually, Depends, Rarely, Partly
Míra úspěšnosti u hry 20Q je úctyhodně vysoká, stejně jako počet odehraných her. Tento údaj jsem přebral přímo z webových stránek hry a nezbývá než mu důvěřovat. Pro porovnání, jakým způsobem hry postupují při kladení otázek, jsem umístil do přílohy (tabulka 6) jednu ukázkovou hru, kdy jsem jako tajný objekt zvolil zvíře elephant. Obsah některých otázek u obou her je až překvapivě podobný. Čtyři otázky jsou významově zcela shodné. Navíc u obou případů hra tipovala dříve nebo později zvíře hipopotamus, který je vlastnostmi velmi podobný se zvířetem elephant.
68 20Q (http://20q.net/) 56 6 Závěr
Diplomová práce popisuje rámcově téma her s účelem (GWAP), na němž je založena implementovaná hra, pro začátek zaměřená na doménu zvířat. Postupně se text zabývá podrobnou analýzou aplikace, ve které jsou rozebírány její jednotlivé dílčí části. V rámci použití iniciálních dat hry byly zvoleny zdroje WordNet a ConceptNet obsahující dostatečné množství použitelných strukturovaných dat v anglickém jazyce. Snahou bylo obohatit vytvářenou databázi i o další zdroje na zaměřenou doménu. Částečně byla využita nestrukturovaná data z Wikipedie se zvuky zvířat a v záloze zůstala velká webová encyklopedie zvířat. Zajímavým problémem bylo zvolení strategie algoritmu tak, aby kladl zpočátku obecné otázky dělící množinu objektů ideálně na dvě poloviny. Bohužel se ukázalo, že vlastnosti objektů nemají zdaleka takovou charakteristiku, aby tento postup bez problému fungoval. Systém byl tedy použit jen do jisté míry a doplněn ostatními tech- nikami. Algoritmus například umí do jisté míry určit, na jakou otázku bude nejpravdě- podobněji odpovězeno kladně, nebo se vypořádat s faktem, že různí hráči odpovídají na tutéž otázku odlišně. Vytvořenou implementaci se podařilo včas umístit na školní servery. Získal jsem první data z odehraných her a mohl částečně zhodnotit fungování hry. Očekávaným problémem bylo šíření hry mezi veřejnost za účelem získání vyššího počtu odehraných her. Podle mého názoru k tomu přispěla i absence silnějšího motivačního prvku hrát hru opakovaně. Hru jsem šířil zejména přes sociální sítě a do mého nejbližšího okolí. Bohužel na optimalizaci budování lepších pozic ve vyhledávačích nebyl dostatek prostoru, navíc když slovo game a jeho modifikace má v prostředí internetu tvrdou konkurenci (slovo qgame však již zaujímá v českém Google vyhledávači první pozici). Projekt stále skýtá spoustu prostoru pro různá vylepšení. Za účelem snadnějšího rozšiřování databáze by se hodilo nějaké univerzální rozhraní pro import nových objektů a vlastností. S tím je spojené možné rozšíření hry i o jiné domény kromě zvířat. Dále by se mohla implementovat podpora českého jazyka, čímž by se i samotná hra stala atraktivnější v prostředí českého internetu. V rámci hry by bylo dobré, kdyby hráči mohli vkládat nové vlastnosti objektů, podobně jako nyní vkládají nové objekty. Posledním rozšířením by mohl být vstup hry na trhy mobilních aplikací. Díky fungujícímu webovému rozhraní by byla implementace mobilního klientu velmi jednoduchá.
57 V diplomové práci jsem splnil všechny body zadání. Práce na tomto tématu mě zasvětila do problémů a úskalí týkajících se zpracování přirozeného jazyka. Taktéž mě naučila pracovat s dosud mnou nepoužívanými technologiemi jako jazyk Python, framework Django a s prostředím webových aplikací obecně. Závěrem lze říci, že imple- mentace takového systému, který bude správně fungovat, je netriviální záležitost. Podíl na tom mají hlavně rozdílné a různorodé názory lidí na vlastnosti jednotlivých objektů. Možná, že kdyby hra byla zaměřena na jinou doménu (například odbornou), kde by objekty měly striktněji přidělené vlastnosti, dosáhla by vyšší úspěšnosti. I přesto jsem rád, že jsem se mohl tohoto projektu ujmout a podařilo se mi vybudovat základy znalostní data- báze. Navíc hra v prvních měsících spuštění získala několik desítek záznamů her, ze kterých lze vypozorovat solidní úspěšnost cca 60 %. Věřím tedy, že systém může někomu poskytnout užitečná data.
58 Použité zdroje
[1] Essential facts about the computer and video game industry. [online]. Entertainment Software Association, 2013 [cit. 2014-05-15]. Dostupné z: http://www.theesa.com/facts/pdfs/esa_ef_2013.pdf [2] VON AHN, Luis. Human Computation. Pittsburgh, PA 15213, 2005. CMU-CS-05- 193. Dostupné z:http://reports- archive.adm.cs.cmu.edu/anon/anon/usr/ftp/home/ftp/2005/CMU-CS-05-193.pdf. Diplomová práce. Carnegie Mellon University. [3] VON AHN, Luis. Games with a Purpose. Computer. 2006, vol. 39, issue 6, s. 92- 94. DOI: 10.1109/MC.2006.196. Dostupné z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1642623 [4] DABBISH Laura a Luis VON AHN. Designing games with a purpose. Communi- cations of the ACM [online]. 2008-08-01, vol. 51, issue 8 [cit. 2014 -04-20]. DOI: 10.1145/1378704.1378719. Dostupné z: http://portal.acm.org/citation.cfm?doid=1378704.1378719 [5] DETERDING, Sebastian, Dan DIXON, Rilla KHALED a Lennart NACKE. From game design elements to gamefulness. In: Proceedings of the 15th International Academic MindTrek Conference on Envisioning Future Media Environments - MindTrek '11 [online]. New York, New York, USA: ACM Press, 2011, s. 9- [cit. 2014-04-21]. ISBN 9781450308168. DOI: 10.1145/2181037.2181040. Dostupné z: http://dl.acm.org/citation.cfm?doid=2181037.2181040 [6] SMITH, Barry. Formal ontology, common sense and cognitive science. International Journal of Human-Computer Studies [online]. 1995, vol. 43, 5-6, s. 641-667 [cit. 2014-05-15]. DOI: 10.1006/ijhc.1995.1067. Dostupné z: http://linkinghub.elsevier.com/retrieve/pii/S1071581985710671 [7] DOUGLAS, Lenat. CYC: A Large-Scale Investment in Knowledge Infrastructure. Communications of the ACM [online]. 19951101, vol. 38, issue 11, s. 32-38 [cit. 2014-04-21]. Dostupné z: http://www.cc.gatech.edu/~isbell/reading/papers/lenat95cyc.pdf [8] LIEBERMAN,, Henry, Hugo LIU a Barbara BARRY. Beating common sense into interactive applications. AI Magazine [online]. 20041201, vol. 25, issue 4, 63 - 76 [cit. 2014-04-21]. Dostupné z: http://web.media.mit.edu/~push/Beating-Common- Sense.pdf
59 [9] NEVĚŘILOVÁ, Zuzana. X-plain: A game that collects common sense proposi- tions. In: Proceedings of the 7th International Workshop on Natural Language Processing and Cognitive Science, NLPCS 2010, in Conjunction with ICEIS 2010. 20100101, 47 - 52. ISBN 9789898425133. [10] Twenty Questions. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-04-22]. Dostupné z: http://en.wikipedia.org/wiki/Twenty_Questions [11] WRÓBLEWSKI, Piotr. Algoritmy: datové struktury a programovací techniky. Vyd. 1. Překlad Marek Michalek, Bogdan Kiszka. Brno: Computer Press, 2004, 351 s. ISBN 80-251-0343-9. [12] GRUBER, Thomas R. A translation approach to portable ontology specifications. Knowledge Acquisition [online]. 1993, vol. 5, issue 2, s. 199-220 [cit. 2014-05-16]. DOI: 10.1006/knac.1993.1008. Dostupné z: http://www.dbis.informatik.hu- berlin.de/dbisold/lehre/WS0203/SemWeb/lit/KSL-92-17.pdf [13] MAŘÍK, V, O ŠTĚPÁNKOVÁ a Jiří LAŽANSKÝ. Umělá inteligence. Praha: Academia, 1993-2013, v. <2-4, 6>. ISBN 97880200227696. [14] BORST, Willem Nico. Construction of engineering ontologies for knowledge sharing and reuse. Enschede: CTIT, Centre for Telematics and Information Techno- logy, 1997. ISBN 90-365-0988-2. Dostupné z: http://doc.utwente.nl/17864/1/t0000004.pdf. PhD dissertation. University of Twente. [15] PRINCETON UNIVERSITY. WordNet: A lexical database for English [online]. 2014 [cit. 2014-04-22]. Dostupné z: http://wordnet.princeton.edu/ [16] MILLER, George A., Richard BECKWITH, Christiane FELLBAUM, Derek GROSS a Katherine J. MILLER. Introduction to WordNet: An On-line Lexical Database. International Journal of Lexicography [online]. 1990, vol. 3, issue 4, s. 235-244 [cit. 2014-04-22]. DOI: 10.1093/ijl/3.4.235. Dostupné z: http://wordnet- code.princeton.edu/5papers.pdf [17] ConceptNet 5 [online]. 2014 [cit. 2014-04-22]. Dostupné z: http://conceptnet5.media.mit.edu/ [18] Wikipedia. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-04-22]. Dostupné z: http://en.wikipe- dia.org/wiki/Wikipedia [19] DBpedia [online]. 2014 [cit. 2014-04-22]. Dostupné z: http://dbpedia.org/
60 [20] ZLÁMAL, Filip. Logistická regrese v R. Brno, 2013. Dostupné z: https://is.mu- ni.cz/th/78448/prif_b_b1/bakalarska_prace_Filip_Zlamal.pdf. Bakalářská práce. Masarykova univerzita. [21] LUKASOVÁ, Alena a Jana ŠARMANOVÁ. Metody shlukové analýzy. 1. vyd. Praha: Státní nakladatelství technické literatury, 1985, 210 s. [22] HUANG, Anna. Similarity Measures for Text Document Clustering. Department of Computer Science, The University of Waikato. Christchurch,New Zealand: NZCSRSC, 2008. Dostupné z: http://www.milanmirkovic.com/wp- content/uploads/2012/10/pg049_Similarity_Measures_for_Text_Document_Cluste- ring.pdf [23] HARMS, Daryl D a Kenneth MCDONALD. Začínáme programovat v jazyce Python. 2. opravené vyd. Překlad Ivo Fořt, Lubomír Škapa. Brno: Computer Press, 2008, xvi, 456 s. ISBN 978-80-251-2161-0. [24] WEERAWARANA, Sanjiva. Web services platform architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and more. Upper Saddle River, NJ: Prentice Hall PTR, 2005, xxxix, 416 p. ISBN 01-314-8874-0.
61 Seznam obrázků
Obrázek 1 – Ilustrace principu hry typu output-agreement. Hra končí úspěchem pokud výstup1,n = výstup2,n...... 3 Obrázek 2 – Ilustrace principu hry typu inversion-problem. Hra končí úspěchem, pokud výstup2,n = vstup...... 3 Obrázek 3 – Ilustrace hry typu input-agreement. Úspěch nastává v případě, že vstup1 = vstup2 [4]...... 4 Obrázek 4 – Ilustrace principu hry ESP Game...... 5 Obrázek 5 – Ukázka ze hry Peekboom. Vlevo je částečně odkrývající obrázek hráčem napravo...... 6 Obrázek 6 – Ilustrace principu hry Verbosity, kde tajné slovo je počítač...... 7 Obrázek 7 – Vizuálně znázorněná hyponyma synsetu dog.n.01 v síti WordNet pomocí reálných dat. Graf vygenerovaný pomocí knihovny NetworkX...... 14 Obrázek 8 – Vizualizace několika ukázkových relací mezi objekty dog a cat a vlastnostmi zachycující váhu relace v procentech...... 20 Obrázek 9 – Ilustrace principu generování otázky...... 27 Obrázek 10 – Ukázka hierarchie různých objektů...... 27 Obrázek 11 – Část stromu obsahující obecné vlastnosti objektů, které zastupují jednotlivé otázky, zkonstruovaný z reálných dat...... 34 Obrázek 12 – Princip výběru vlastnosti na základě matice otázek (ukázková data)...... 43 Obrázek 13 – Ilustrace architektury celého projektu...... 43 Obrázek 14 – Ukázka volání metody služby pro návrat následující otázky...... 49 Obrázek 15 – Ukázka webové verze aplikace...... 65 Obrázek 16 – Ukázka mobilní verze aplikace...... 65
Seznam grafů
Graf 1 – Počet vlastností na objekt. Relace mezi objektem a vlastností má v tomto případě váhu alespoň 60 %...... 18 Graf 2 – Zobrazení logistické funkce s upravenou strmostí, pomocí které se provádí výpočet váhy relace...... 21 Graf 3 – Porovnání objektů s vektorem odpovědí hráče pomocí jednotlivých metrik...... 39 Graf 4 – Počty návštěv webové stránky a počty odehraných her během 3 měsíců...... 55
62 Seznam tabulek
Tabulka 1 – Zastoupení jednotlivých zdrojů dat použitých ve hře ke dni 25.3.2014...... 18 Tabulka 2 – Seznam všech typů relací a odpovídajících šablon otázek...... 25 Tabulka 3 – Ilustrační příklad objektů reprezentovaných n-složkovými vektory...... 38 Tabulka 4 – Zobrazení statistik odehraných her za období únor – duben 2014...... 54 Tabulka 5 – Porovnání mého projektu s podobnou hrou 20Q...... 57 Tabulka 6 – Srovnání kladení otázek QGame a 20Q. Tajný objekt je elephant...... 64
Seznam diagramů
Diagram 1 – Abstraktní vývojový diagram zobrazující princip fungování aplikace...... 9 Diagram 2 – Zjednodušený diagram strategie vrácení následující otázky ve hře...... 29 Diagram 3 – Diagram balíčků zobrazující závislosti mezi jednotlivými moduly hlavní aplikace...... 45 Diagram 4 – Diagram tříd modulu QCore...... 45 Diagram 5 – Diagram tříd modulu QGenerator...... 47 Diagram 6 – Diagram tříd modulu QConnector...... 47 Diagram 7 – ER diagram zachycující nejdůležitější databázové tabulky...... 47 Diagram 8 – Diagram tříd tenkého javascriptového klientu...... 52
63 Přílohy
Tabulka 6: Srovnání kladení otázek QGame a 20Q. Tajný objekt je elephant QGame Odpověď 20Q Odpověď 1 Is it a carnivore? no Is it classified as Animmal Animal, Vegetable or Mineral? 2 Is it a mammal? yes Can it climb? no 3 Does it have four legs? yes Does it have short no fur? 4 Is some of its properities "to no Does it stand on two no be small"? legs 5 Can you find it in africa? yes Does it have teeth? yes 6 Is it a pet? no Is it a domesticated no animal? 7 Can it jump? no Can it do tricks? no 8 Is some of its properities "to yes Is it very large? yes be native to africa"? 9 Is it a friendly pet? no Does it like to run? no 10 Does it make sound like unknown Does it have a long yes grunt? nose? 11 Can you find it in the wild? yes Can it jump? no 12 Can you find it in zoo? yes Does it live in salt- no water? 13 Can it lie aroundly doing no Is it a mammal? yes nothing? 14 Does it make sound like unknown Can it carry people? no cah? 15 Does it have long necks? no Is it brown? no 16 Does it desire to eat? yes Can you see it in a yes zoo? 17 Can you find it in the yes Are there many no outdoors? different sorts of it? 18 Is it a hippopotamus? no Is it a lazy animal? yes 19 Does it have stripes? no Is it dangerous? no
64 20 Does it have tusk? yes I guessed that it close was an elephant's trunk? 21 Can you find it in the yes Is it grey? yes circus? 22 Is it a elephant? yes Can it live out of yes water? 23 I guessed that it wrong was a hippopotamus? 24 Does it bite? probably 25 Would you find it no on a farm? 26 I guessed that it wrong was an armadillo?
65 Obrázek 15: Ukázka webové verze aplikace.
Obrázek 16: Ukázka mobilní verze aplikace. 66 Elektronické přílohy
• adresář src – Obsahuje zdrojový kód serverové části aplikace a webový klient. • adresář doc – Webová dokumentace projektu v českém jazyce. Popisuje imple- mentaci projektu, použité knihovny, metriky projektu a ovládání programů game- setup.py a gameoutput.py. • licence.txt – Licence aplikace k použití zdrojových kódů.
67