Tomáš Hejl Dotazovací jazyky II 2010/2011.  „Web-scale knowledge base“  Web obsahuje prakticky všechny dostupné znalosti  Současné vyhledávače  umí.

Prezentace na téma: "Tomáš Hejl Dotazovací jazyky II 2010/2011.  „Web-scale knowledge base“  Web obsahuje prakticky všechny dostupné znalosti  Současné vyhledávače  umí."— Transkript prezentace:

1 Tomáš Hejl Dotazovací jazyky II 2010/2011

2  „Web-scale knowledge base“  Web obsahuje prakticky všechny dostupné znalosti  Současné vyhledávače  umí nalézt stránku, která obsahuje hledané informace  neumí vytvářet souvislosti, odvozovat 2

3 „The Unreasonable Effectiveness of Data“ 3

4 FYZIKA  GRAMATIKA ANGLIČTINY (NEKOMPLETNÍ)  1700 stran textu Přirozené zpracování textu není možné popsat jednoduše, jsou zapotřebí komplexní teorie. 4

5  Google (2006)  Bilion slov  včetně chyb, překlepů…  včetně sekvencí slov do délky 5 a jejich frekvencí  Zahrnuje veškeré lidské znalosti, kompletní model 5

6  Převod řeči na text  Automatické překlady Důvod? Pro mnoho lidí každodenní běžné aktivity  Mnoho testovacích dat  Velká motivace pro automatizaci 6

7  Klasifikace dokumentů  Rozpoznávání slovních druhů  Syntaktická analýza (parsing)  V běžném životě nepříliš časté  Málo testovacích dat  Vyžadovány anotace lidským expertem  Anotace nebývají jednoznačné 7

8  Nespoléhat se na anotace  Využít dostupná objemná data  Sémantické vztahy se dají často odvodit ▪ Dotaz pro vyhledávač + Zvolená odpověď ▪ Formátovaná data na webu, tabulky se záhlavím 8

9  Lepší je jednodušší model s více daty, než naopak  Podobnost s překlady  Dříve: Složitá sémantická a syntaktická pravidla  Dnes: Rozsáhlá tabulka mapování frází 9

10  Realita = nekonečné množství dat  Úspěšná reprezentace či aproximace = stačí řádově miliardy či biliony příkladů 10

11  Nevyřazovat ojedinělé případy  Jednotlivě jsou vzácné, ale společně tvoří model  Komplexní pravidla mohou zastarat  Význam frází se mění, přibývají nová slova  Komplexní pravidla nemusí stačit  Lidé často nepíší podle pravidel, gramatiky, pravopisu… 11

12  Analýza pravděpodobnosti výskytů různých n-tic slov v textu  Mnoho jednoduchých automatických pravidel místo pravidel obecných 12

13 Dva přístupy 13

14 SÉMANTICKÝ WEB  Sémantika je ukryta v předem určených formátech  Lidé píšou v pevně daném formátu, počítače mu rozumí SÉMANTICKÁ INTERPRETACE  Sémantiku určují lidé přirozenou tvorbou jazyka  Počítač se snaží text interpretovat 14

15 15

16  Vytvoření ontologií  Již existují formáty pro mnoho témat (datum a čas, lokace, genové sekvence, rezervace hotelů…)  Méně používaná témata se zřejmě formátů nedočkají  Nutná shoda expertů, konkurenční společnosti prosazují vlastní formát  Drahé (Projekt Halo, převedení učebnice chemie, $10.000 za stránku) 16

17 HTML STRÁNKA  Textový editor SÉMANTICKÝ WEB  Webová služba  Databáze  Splnění všech požadavků na formát  Obtížné nasazení 17

18  Nutnost sémantické interpretace zůstává, byť v menším měřítku  Stroj podle ontologie ví, že „Joe‘s Pizza“ je název firmy  Stroj neví, o kterou firmu s tímto názvem se jedná  Stroj neví, že jde o pizzerii 18

19 19

20  Obsah již existuje  Obsah je agregován a indexován  Obsah neumíme strojově interpretovat  20

21  Jedno vyjádření  různé významy  Jeden význam  různá vyjádření  Hledání synonym, atributů třídy…  Pomocí tabulek v HTML  Pomocí vyhledávacích dotazů 21

22 22

23  Nástroj  Umožňující propojení všech informací na webu  Automaticky odpovídající na faktografické dotazy  Doménově nezávislý, obecný 23

24 24

25  University of Washington  Zaměření na obecný text  Analyzuje věty a vytváří systém trojic („Einstein se narodil v roce 1879“  přidá pár do relace „narození“)  Podle frekvence výskytu kontroluje přesnost Validní informace o Einsteinově narození bude na mnoha webech  http://www.cs.washington.edu/research/textrunner/indexTRTypes.html http://www.cs.washington.edu/research/textrunner/indexTRTypes.html 25

26  Dipre  KnowItAll  SnowBall  Yago  Kylin 26

27  Dávkový režim  Podobně jako tradiční vyhledávače  Zpracuje veškerá dostupná data najednou, produkuje a ukládá velké množství trojic  Konkurence vybírá kde hledat až podle dotazu  Schéma si vytváří sám za běhu  Konkurence vyžaduje schéma trojic, názvy relací, fráze odpovídající relacím atd. 27

28  První test  9M stránek  1M trojic  88% úspěšnost  Druhý test  500M stránek  200M trojic  Přesnost v době vydání článku (2008) ještě nebyla známa 28

29  Odlišné od klasických relačních dat  Počet „sloupců“ ▪ TextRunner – 2, SQL tabulky – více  Doména ▪ SQL – „tabulkové“ hodnoty, v textu bývají více textové  Počet výskytů ▪ TextRunner bere v úvahu jen vícenásobné výskyty  Názvy sloupců ▪ TextRunner nemá pojmenované prvky relací 29

30 30

31  Google Research (+MIT, Univ. Washington, Berkeley)  Extrahuje data z HTML tabulek  Jen 1.1% HTML tabulek obsahuje relační data!  154M tabulek je i tak největší relační databáze vůbec (o 5 řádů) 31

32  Rozpoznání relační tabulky je obtížné  Krok 1. Vyhodit zřejmé nerelační tabulky  Jen 1 řádek, 1 sloupec, kalendáře, HTML layout  Ruční pravidla  Odstraní cca 89% tabulek  Krok 2. Trénované statistické filtry  Počet prázdných buněk, počet číselných dat, počet řádků a sloupců…  Obtížné a nedokonalé: 81% úplnost, 41% přesnost  125M rel.tab. + 146M falešných tabulek 32

33  Krok 3. Hledání metadat relací  71% relací má metadata  Na rozdíl od databází nemůžu počítat s cizími klíči atd.  Pouze hlavičky sloupců (někdy obtížné najít) ▪ Opět trénované filtry ▪ 89% přesnost, 85% úplnost 33

34  Tabulky přímo definují relace i jejich metadata  Tabulky určují příslušnost prvků do množin  WebTables – všechny prvky sloupce  TextRunner – ve „sloupci“ jsou různé informace  Data z WebTables mohou rozšířit data z TextRunneru 34

35 35

36  Deep-Web = Data z běžných databází, dostupná pouze přes HTML formuláře 36

37  Na rozdíl od HTML tabulek nedostupné pomocí běžných vyhledávačů  Neumí vyplňovat formuláře  Spekulace: Data v Deep-Web DB výrazně počtem převyšují doposud indexovaná data  Cca 10M takových formulářů 37

38  Google  Cíle  Zpřístupnit Deep-Web DB pro vyhledávání  Univerzálně pro všechny typy formulářů  Projekt : Deep-Web Crawl  Data z něj již jsou dostupná přes Google 38

39  Vytvoření vyhledávačů-prostředníků pro každou doménu (auta, knihy, nemovitosti…)  Dotaz na vyhledavač aut převede dotaz na jednotlivé dotazy pro všechny formuláře, týkající se aut, pomocí sémantického mapování složí výsledky  Problémy  Ruční vytváření prostředníků a mapování je pracné a drahé  Rozpoznání domény vstupu je obtížné  Mnoho domén, mnoho jazyků  Nevhodné 39

40  Odvození vhodných vstupů pro formulář  Indexování dosažených výsledků  Může využít stávající metody indexování do běžných systémů 40

41  Dva typy textových vstupů  Obecné vyhledávání ▪ Přijme všechny řetězce, občas nevrátí nic ▪ Pomáhá analýza již naindexovaného okolí formuláře a iterativní zlepšování analýzou vrácených výsledků  „Typovaný“ vstup ▪ Přijme pouze prvky své domény, která nemusí být zřejmá ▪ Používá se knihovna často používaných typů (např. PSČ) ▪ Většina těchto vstupů se dá pokrýt malým množstvím typů 41

42  select / checkbox prvky jsou „snadné“  Není vhodné zkoušet všechny možnosti  Př.: cars.com, 5 selectů = 200M možností, reálně 650 000 aut  Algoritmus prochází kartézský součin všech možností a hledá kombinace, které generují webové stránky s unikátním obsahem 42

43  Několik stovek vstupů pro každý formulář  Počet vstupů je poměrný velikosti databáze, ne počtu prvků vstupu  Výsledky obsahují velké procento Deep-Web databáze, bez jediného lidského zásahu 43

44  Při surfacingu se ztrácí struktura databáze  (strukturovaná databáze  HTML)  Výsledky často v podobě HTML tabulek  WebTables, lepší než obyčejná tabulka (více podobných tabulek, snazší odvozování)  Prostor na zlepšení do budoucna  Popisky formulářů  metadata 44

45 45

46  Yahoo!  Zpracovává tabulky na webu, konkrétně tabulky dvojic (Atribut/Hodnota)  Cíl = trojice (Subjekt / Atribut / Hodnota) 46

47  Klasifikace tabulek  Tabulky layoutu  Tabulky Atribut/Hodnota  Ostatní  5000 tabulek ohodnocených experty  učení  Pravidla (layout buněk, typ obsahu…)  Přesnost 76%, úplnost 76% 47

48  „Protagonist Detection“  Hledání předmětu ke dvojicím atribut-hodnota  V tabulce (atribut name) atp.  V titulku stránky  V odkazech, vedoucích na stránku  Nalezení všech n-tic ve stránce  Nejčastější text odkazu  40% přesnost  ProIde  65% přesnost 48

49 49

50  Velkou cenu mají kolekce metadat  Názvy sloupců v tabulkách či formulářových prvků, vyskytujících se spolu  Časté hodnoty prvků s daným názvem, tedy doména daného atributu  Názvy sloupců se stejnou doménou (synonyma)  Sémantické služby, poskytující informace o těchto souvislostech, např. hledání synonym 50

51 51

52  TextRunner  Zpracovává obecný text  Hledá trojice (relace a dva prvky)  WebTables  Zpracovává HTML tabulky  Hledá relační data  Deep-Web Crawl  Zpracovává data, přístupná přes formuláře  Hledá relační data  TabEx + ProIde  Zpracovává dvousloupcové HTML tabulky  Hledá trojice (subjekt / atribut / hodnota) 52

53  The Unreasonable Effectiveness of Data  Alon Halevy, Peter Norvig, Fernando Pereira  Web-Scale Extraction of Structured Data  Michael J. Cafarella, Jayant Madhavan, Alon Halevy  Web-Scale Knowledge Extraction from Semi-Structured Tables  Eric Crestan, Patrick Pantel 53

54 54