Podsumowanie wyników testów

5.6 Podsumowanie wyników testów

Sprawdzono działanie proponowanej rodziny metod na czterech kolekcjach dokumen-tów, stosując różne metody sztucznej inteligencji. Za każdym razem wyniki porówny-wano z rezultatami osiąganymi przez metodę Schenkera et al. oraz modelem wektoro-wym w odmianie uni–, bi– oraz tri–gramowej.

Tabela 5.32: Metody dające najlepsze rezultaty dla każdej kolekcji

k-najbliższych sąsiadów maksimum entropii Rzeczpospolita Wariant B Model wektorowy

Wariant A Wariant D Wariant B Metoda Schenkera Model 3-gramowy wiadomosci24.pl Wariant B Wariant D

Wariant A Wariant B Wariant D Wariant A Portal aukcyjny Wariant A Wariant D

Wariant B Wariant C Wariant D Wariant B Metoda Schenkera Wariant A

Metoda Schenkera CustomerThoughts Wariant D Wariant D

Wariant A Metoda Schenkera

Wariant B

Tabela5.32przedstawia podsumowanie najlepszych metod dla danego algorytmu uczenia i kolekcji dokumentów. Jeśli test statystyczny porównujący rezultat najlepszej metody z dowolną inną osiągał p–wartość niespełniającą warunek p < 0,05, metody takie zostały również umieszczone w tabeli, zgodnie z malejącą kolejnością p–wartości. Bardzo pożadaną cechą podczas szeroko pojętej klasyfikacji jest zapewnienie stabil-ności rezultatów danej metody. Nawet jeśli nie daje ona najlepszych rezultatów, może być preferowana ze względu na zapewnienie stałej jakości wyników dla szerokiej kla-sy analizowanych problemów. Sytuacja odwrotna bywa również oznaką występowania problemu nadmiernego dopasowania (over-fitting). Tabele5.33oraz5.33przedstawiają różnice miary F zaobserwowane pomiędzy daną metodą, a najlepszym uzyskanym re-zultatem w danym teście. Ostatnia kolumna zawiera średnią. Zwraca uwagę wyraźnie lepsza stabilność proponowanych wariantów, widoczna poprzez niewielkie odchyłki uzyskiwanych przez nie wyników, w porównaniu do metod wektorowych i propozycji Schenkera. W przypadku korzystania z algorytmu klasyfikacji k-najbliższych sąsiadów, najmniejsze różnice notuje Wariant A, a następnie Wariant B. Stosując algorytm maksi-mum entropii, najlepsze rezultaty osiągnął Wariant D, za którym niedaleko znalazły się

5.6. Podsumowanie wyników testów 114

Tabela 5.33: Porównanie różnic wielkości miary F w stosunku do najlepszego wy-niku dla rozważanych zbiorów, podczas klasyfikacji z zastosowaniem algorytmu k-najbliższych sąsiadów (dle metryki przy której otrzymano najlepszy rezultat)

Mikro-uśrednianie Rzeczpospolit a wiadomosci24.pl P^or tal aukcyjn y CustomerThoughts Średnia Model wektorowy −48% −13% −35% −4% −25,0% Model 2-gramowy −48% −9% −35% −62% −38,5% Model 3-gramowy −48% −11% −35% −26% −30,0% Schenker −5% −30% −3% −1% −9,8% Wariant A 0% −2% 0% −1% −0,8% Wariant B 0% 0% 0% −6% −1,5% Wariant C −10% −13% −5% −4% −8,0% Wariant D −8% −2% −3% 0% −3,3% Makro-uśrednianie Rzeczpospolit a wiadomosci24.pl P^or tal aukcyjn y CustomerThoughts Średnia Model wektorowy −74% −18% −32% −26% −37,5% Model 2-gramowy −74% −12% −32% −63% −45,3% Model 3-gramowy −75% −15% −34% −35% −39,8% Schenker −10% −35% −3% −7% −13,8% Wariant A −1% −2% 0% −6% −2,3% Wariant B 0% 0% 0% −11% −2,8% Wariant C −17% −17% −6% −7% −11,8% Wariant D −11% −2% −3% 0% −8,5%

5.6. Podsumowanie wyników testów 115

Tabela 5.34: Porównanie różnic wielkości miary F w stosunku do najlepszego wyniku dla rozważanych zbiorów, podczas klasyfikacji z zastosowaniem algorytmu maksimum entropii Mikro-uśrednianie Rzeczpospolit a wiadomosci24.pl P^or tal aukcyjn y CustomerThoughts Średnia Model wektorowy 0% −30% −14% −4% −12,0% Model 2-gramowy −3% −12% −16% −1% −8,0% Model 3-gramowy −1% −12% −16% −1% −7,5% Schenker −1% −30% −3% −3% −9,3% Wariant A −2% −3% −1% −3% −2,2% Wariant B 0% −2% −1% −5% −2,0% Wariant C −3% −2% 0% −6% −2,8% Wariant D 0% 0% 0% 0% 0,0% Makro-uśrednianie Rzeczpospolit a wiadomosci24.pl P^or tal aukcyjn y CustomerThoughts Średnia Model wektorowy 0% −35% −12% −11% −14,5% Model 2-gramowy −6% −15% −14% −11% −11,5% Model 3-gramowy −6% −17% −14% −13% −12,5% Schenker −4% −33% −3% −3% −10,8% Wariant A −4% −3% 0% −2% −2,3% Wariant B 0% −2% 0% −5% −1,8% Wariant C −6% −8% 0% −5% −4,8% Wariant D 0% 0% 0% 0% 0,0%

5.6. Podsumowanie wyników testów 116

Warianty A oraz B.

Na podstawie wszystkich rezultatów, poczynić można następujące obserwacje: 1. Niemal w każdym przypadku najlepsze rezultaty dawał któryś z proponowanych

wariantów, przy czym czterokrotnie był to Wariant D, dwukrotnie Wariant B i raz

Wariant A.

2. Metoda Schenkera et al. dawała niemal zawsze lepsze rezultaty niż dowolna me-toda wektorowa.

3. Rezultaty uzyskane algorytmem maksimum entropii były zawsze lepsze od rezul-tatów uzyskanych algorytmem k-NN (w niektórych przypadkach różnica była po-mijalna – np. dla korpusu Rzeczpospolitej).

4. W przypadku grafów (zarówno Schenkera et al. jak i proponowanej rodziny) naj-lepsze rezultaty dwukrotnie dała metryka dW GU −V (dla korpusu Rzeczpospolitej oraz opisów przedmiotów na portalu aukcyjnym), raz metryka dM CS – dla zbioru

Cu-stomerThoughts oraz raz metryka dW GU – dla wiadomosci24.pl.

5. Zgodnie z oczekiwaniami, Wariant D sprawdził się szczególnie dobrze w kolekcji dokumentów o kategoriach związanych z nacechowaniem emocjonalnym

(Custo-merThoughts). Dawał również najlepsze wyniki wśród metod grafowych, kiedy

stosowano algorytm maksimum entropii.

6. Rownież w zgodzie ze spodziewanymi rezultatami, zaobserwowano relatywnie dobry rezultat metody bi–gramowej dla zbioru wiadomosci24.pl (składającego się tekstów o relatywnie dużej długości i podzielonych na wiele kategorii).

7. Dla zbioru wiadomosci24.pl najlepiej sprawdzał się Wariant B. Wprawdzie najlep-szy wynik dla algorytmu maksimum entropii osiągnięty został dla Wariantu D, to różnica między nim, a drugim z kolei Wariantem B nie była statystycznie istotna. 8. Treści opisów przedmiotów na portalu aukcyjnym zostały najlepiej

sklasyfikowa-ne przy użyciu Wariantu A – który skupia się bardziej na filtrowaniu wybranych kategorii gramatycznych, zamiast na tworzeniu bardziej złożonych konstrukcji. Bardzo dobry (choć nie najlepszy) wynik został przez niego osiągnięty również dla serwisu wiadomosci24.pl – być może ma to związek z charakterem wypowie-dzi, zawierającymi tam relatywnie dużo czasowników i rzeczowników (które są głównymi budulcami Wariantu A i Wariantu B)

9. Korpus Rzeczpospolitej był jedynym, gdzie najlepszy rezultat osiągnął model wek-torowy. Stało się to przy zastosowaniu algorytmu maksimum entropii. Rezultat był zbliżony do tych osiąganych przez Wariant D lub Wariant B i nie był staty-stycznie istotny. Być może ma to związek z relatywnie dużą wielkością tego zbioru i domniemywaną jednolitością stosowanych form wypowiedzi.

10. Proponowane warianty dawały zawsze rezultaty co najmniej zbliżone do najlep-szego wyniku w danym teście.

Rozdział 6

Implementacja użytkowa - CLUO

Magnum in parvo (Dużo w małym)

Jednym z osiągnięć prowadzonych badań stało się praktyczne zastosowanie rezulta-tów prac do systemu informatycznego  CLUO¹[Maciolek 2013]  systemu eksploracji danych tekstowych na skalę internetową. Zbiera i monitoruje on informacje publiko-wane na tysiącach stron internetowych, blogach, serwisach informacyjnych, portalach społecznościowych i forach, wydobywając z nich istotną treść, wzbogacając i zapisując ją w rozproszonej bazie danych. Tak zebrane informacje mogą być przedmiotem eks-ploracji tekstowej, a w szczególności klasyfikacji.

W momencie rozpoczęcia prac nad CLUO istniało kilka zbliżonych rozwiązań

open-source, takich jak Bixo2

bądź Apache Nutch³. Występowało w nich jednak szereg ograni-czeń związanych z ich architekturą oraz docelowymi zastosowaniami. Apache Nutch jest zasadniczo wyszukiwarką oraz crawlerem  rozbudowanie go do celów OSINT byłoby dość złożone z uwagi jego wewnętrzną strukturę. Z kolei Bixo posiadał ograniczone możliwości przetwarzania w czasie rzeczywistym.

Główną ideą przyświecającą CLUO było zbudowanie platformy, która pozwalała-by analizować dokumenty pobrane z Internetu z wykorzystaniem nowoczesnych roz-wiązań, często będacymi efektami ostatnich badań naukowych. Dostępność technologii

Cloud Computing oraz rosnąca popularność rozwiązań Big Data spowodowały, że

zbie-ranie i przetwarzanie ogromnych ilości danych stało się bardziej dostępne niż kiedy-kolwiek. Budowa środowiska, które by je wspierało, pozwoliło efektywnie prowadzić badania nad dużymi zbiorami danych.

Sam proces klasyfikacji dokumentów, który został zrealizowany za pomocą prezen-towanej w niniejszej pracy rodziny metod, jest istotnym elementem kilku zastosowań

CLUO (por. rys.6.1):

• ropoznawania „spamu” (por.A.2.1)  odrzucone mogą być w ten sposób niechcia-ne dokumenty, które nie wnoszą żadniechcia-nej wartościowej informacji, a często wystę-pują w niektórych źródłach danych (np. komentarzach na serwisach informacyj-nych),

• przypisywania dokumentom dotyczących je kategorii, arbitralnie zdefiniowanych przez użytkownika (por.A.2.3)  pozwala stosować kategorie podczas

filtrowa-1http://www.cluo.eu

2http://openbixo.org

6.1. Architektura 118 Użytkownik Przypisuje kategorie do dokumentu (A.2.1, A.2.3) CLUO Trenuje klasyfikator dla dokumentów z przypisanymi kategoriami, wykorzystując rodzinę metod. (A.2.1, A.2.3) Przypisuje automatycznie kategorie do nowych bądź uaktualnionych dokumentów,

wykorzystując rodzinę metod.

(A.2.3) Przegląda i wyszukuje dokumenty na podstawie kategorii (A.2.3) Przegląda trendy występowania kategorii w wybranym kontekście (A.2.4) Definiuje kryteria niektórych zadań przetwarzania danych z wykorzystaniem kategorii (A.2.4.) Zaznacza "SPAM" (A.2.1)

Rysunek 6.1: Przypadki użycia związane z klasyfikacją dokumentów, realizowane w CLUO

nia, wyszukiwania lub analizy dokumentów, umożliwiając grupowanie rezulta-tów wedle przypisanych klas,

• śledzenia popularności danego tematu wiadomości, znajdowaniu pierwotnej wy-powiedzi (por.A.2.4)  jest to szczególny przypadek klasyfikacji, kiedy zgrupo-wane zostają dokumenty, w których występuje podobna wypowiedź; umożliwia śledzenie drogi danej wypowiedzi oraz analizowanie związanych z nią trendów.

6.1 Architektura

Z uwagi na realizowane zadania, CLUO można zaliczyć do systemów OSINT (Open

So-urce Intelligence)  czyli narzędzi białego wywiadu. OSINT jest definiowany [dod 2006] jako zbiór metod pozwalających na uzyskanie informacji z publicznie dostępnych danych

 zbieranych, wydobywanych i rozpowszechnianych w sprawny sposób do grupy docelowej, dostarczając określone wymagania wywiadowcze. Ocenić można, że implementacja takiego

6.1. Architektura 119

rozwiazania może być podzielona na trzy części:

1. Zbieranie  poszukiwanie i pobieranie otwarcie dostępnych danych.

2. Ekstrakcja i analiza  wydobycie treści z zebranych zbiorów, zastosowanie metod znajdujących dodatkowe informacje.

3. Prezentację  przedstawienie i interaktywna analiza zebranych i przetworzonych informacji.

Powyższa koncepcja została odzwierciedlona w procesie działania (rys. 6.2) oraz podziale architektonicznym (rys.6.3). Podstawowymi komponentami, które można wy-dzielić w CLUO są: podsystem zbierania danych, łańcuch wstępnego przetwarzania, łańcuchy

przetwarzania żądań oraz interfejs użytkownika .

Internet Pobieranie danych z serwisów internetowych Dane nieustrukturyzowane Dane ustrukturyzowane Łańcuch wstępnego przetwarzania Użytkownik Interfejs użytkownika Łańcuch przetwarzania żądań Żadanie _Wynik Zbieranie Ekstrakcja i analiza Prezentacja Rodzina metod Rodzina metod

Rysunek 6.2: Ogólny schemat działania CLUO

Z racji ogromnego zakresu przetwarzanych informacji, często miliardów dokumen-tów, konieczne było dostarczenie odpowiedniej skalowalności rozwiązania. Aby speł-nić to wymaganie, zastosowano paradygmat rozproszonego przetwarzania

MapRedu-6.1. Architektura 120

ce[Dean 2008] w środowisku Apache Hadoop⁴oraz Apache HBase⁵, w którym to program

wędruje do danych, zamiast dane do programu.

Łańcuchy  zarówno wstępnego przetwarzania jak i przetwarzania żądań  zostały

za-implementowane jako sekwencje kilku operacji MapReduce. 6.1.1 Podsystem zbierania danych

System udostępnia ogólne API pozwalające na dostarczenie albo surowych bądź już wstępnie przetworzonych danych, których analizą zajmuje się dalej rdzeń systemu. Ko-munikacja odbywa się za pomocą REST [Fielding 2000], co pozwala na łatwą imple-mentację własnego klienta z zastosowaniem praktycznie dowolnego języka programo-wania.

Co oczywiste, system internetowy będący źródłem danych najczęściej zawiera ko-lekcję dokumentów. Niekiedy wiele z nich znajduje się pod tym samym adresem URL. Istotne jest zatem ustalenie, co rozumiane będzie przez pojedyńczy dokument. W przy-padku CLUO przyjęto, że jest nim dowolny spójny tekst. Może to być: wpis na blogu, artykuł w portalu internetowym, pojedyńczy wpis na forum, publikacja, dowolny ko-mentarz, etc. Dokumentami nie są np. wątki forów internetowych bądź kompletne strony internetowe, są nimi za to ich poszczególne składniki (w tym przypadku odpowiednio – wpisy oraz artykuł i opcjonalne komentarze). Wspierane jest przypisywanie tych skład-ników do ich całości, co umożliwia ich analizę w wybranym kontekście (jako niezależne elementy bądź też poprzez ich „rodzica”).

Istotną cechą CLUO jest skupienie się na wydobyciu wysokiej jakości informacji, po-zbawionych zbędnych elementów (które nie są związane z treścią), podzielone na tekst główny i ewentualne komentarze. Oprócz tytułu oraz głównego tekstu, zapisane są me-tadane, takie jak: autor, data publikacji, pozycja w sekwencji (jeśli to komentarz bądź wpis na

forum), kategoria danego serwisu internetowego (jeśli występuje), etc. Podejście takie

wyma-ga stworzenia ekstraktorów dedykowanych do danych źródel danych, odwdzięcza się jednak, w porównaniu do zwykłego crawlera, ogromnym polepszeniem jakości zbiera-nych informacji.

System posiada obecnie kilka aplikacji klienckich, pozwalających na pobieranie in-formacji z następujących źródeł:

• Facebook  zbierane są wpisy na portalu społecznościowym na podstawie do-starczonych zapytań (terminów kluczowych)

• Crawler for internetowych  przeglądane są całe fora internetowe. Wspierane są najpopularniejsze silniki, takie jak phpBB, vBulletin, IP-Board i inne.

• Serwisy informacyjne i blogi  dostarczone są dedykowane ekstraktory dla sze-regu popularnych serwisów. Strony będące przedmiotem ekstrakcji są dostarczo-ne przez zewnętrzny crawler, oparty o crawler4j⁶.

4http://hadoop.apache.org

5http://hbase.apache.org

6.1. Architektura 121

Do celów testów napisane zostały też aplikacje „karmiące” CLUO danymi pochą-dzącymi z wybranych korpusów tekstów bądź baz danych, co służy pracom badaw-czym oraz mierzeniu jakości uzyskiwanych rezultatów.

6.1.2 Łańcuch wstępnego przetwarzania

Każdy dokument dostarczony do CLUO jest w pierwszej kolejności poddawany proce-sowi wstępnego przetwarzania. Jego celem jest wydobycie istotnej treści oraz przypi-sanie szeregu cech, wykorzystywanych później podczas analizy danych. Składa się on z następujących elementów:

1. Wydobycie treści  uzyskana zostaje istotna zawartość (pozbawiona reklam, nawigacji, etc.), o ile nie została w takiej postaci już dostarczona przez de-dykowany ekstraktor. Wykorzystywane są tutaj metody takie jak Boilerplate ⁷

[Kohlschütter 2010].

2. Rozpoznanie języka  następuje automatyczne rozpoznanie języka danego do-kumentu. Realizacja tego kroku pozwala w dalszych etapach na zastosowanie me-tod zoptymalizowanych pod konkretny język. Wykorzystano bibliotekę Cybozu

Language Detect [Shuyo 2010].

3. Wydobycie daty publikacji  wykorzystując metadane, surową treść oraz zbiór opracowanych heurystyk, ustalana jest data publikacji danego dokumentu. 4. Tokenizacja i segmentacja  proces ten został zrealizowany w oparciu o

toke-nizer projektu Lucene ⁸ zgodny ze standardami segmentacji tekstu Unicode ⁹. Do dzielenia tekstu na zdania wykorzystywany jest zbiór reguł dostępny w Javie za pośrednictwem klasy java.text.BreakIterator (wspierający wiele jezyków). CLUO wzbogaca model tekstu o dodatkowe cechy wynikające z jego struktury  np. oznacza występujące adresy internetowe, znaki interpunkcyjne i formatowanie tekstu.

5. Tagowanie części mowy  w początkowych pracach stosowano znakomity pro-jekt TaKIPI ¹⁰ [Piasecki 2007], jednak problemy z licencjonowaniem wykorzy-stywanych przez niego komponentów oraz integracją (program jest dostępny z linii poleceń, a jego instalacja nie jest prosta, co utrudnia korzystanie z nie-go w rozproszonym środowisku przetwarzania) spowodowały, iż zaczęto poszu-kiwać alternatywnego rozwiązania. Ostatecznie zdecydowano się na opracowa-nie własnego tagera podstawowych kategorii gramatycznych (opisanego w4.5). W przypadku języka angielskiego, wykorzystywany jest Stanford POS Tagger ¹¹

[Toutanova 2000]. 7http://code.google.com/p/boilerpipe/ 8http://lucene.apache.org 9http://unicode.org/reports/tr29/ 10http://nlp.pwr.wroc.pl/takipi/ 11http://nlp.stanford.edu/software/tagger.shtml

6.1. Architektura 122

6. Znajdowanie trzonów (stemming)  w przypadku tekstów w języku polskim sto-sowany jest podwójny proces, w którym najpierw następuje próba znalezienia le-matu za pomocą biblioteki morfologik-stemming¹², a jeśli nie udaje się go znaleźć, zwracany jest algorytmicznie znaleziony trzon z zastosowaniem Stempela¹³. Po-wodem tej dychotomii jest relatywnie istotna niedokładność działania Stempela, który niekiedy zwraca różne wyniki dla form wyrazowych niektórych popular-nych terminów. W przypadku pozostałych jezyków, wykorzystana jest popularna biblioteka Snowball¹⁴.

7. Tagowanie sentymentem  oznaczane zostają terminy mogące nieść istone infor-macje związane z sentymentem wypowiedzi. Określana jest także globalna opinia całego dokumentu.

8. Budowa modelu  utworzony zostaje wewnętrzny (obiektowy) model treści. Za-wiera on również informacje o metadanych, formatowaniu, odnośnikach, etc. 9. Ekstrakcja nazwanych jednostek  system automatycznie rozpoznaje nazwane

jednostki  nazwy miejsc, organizacji, osoby, etc. Dodatkowo  przypisany im zostaje kontekst w jakim wystąpiły. Dla języka polskiego zastosowany został sa-modzielnie opracowany mechanizm (w oparciu o maszynowe uczenie).

10. Klasyfikacja  każdy dokument jest rozpatrywany pod kątem automatycznego przypisania mu danej kategorii na podstawie jego treści. Wykorzystana zostaje prezentowane w niniejszej pracy podejście, z zastosowaniem jednego z rozpatry-wanych wariantów.

11. Indeksowanie  zebrane dane są indeksowane, umożliwiając później szybkie od-nalezienie dokumentów spełniających dane kryteria.

Proces ten zaimplementowany jest za pomocą sekwencji trzech operacji MapReduce. 6.1.3 Łańcuchy przetwarzania żądań

Budowa raportów oraz implementacja algorytmów eksploracji danych są realizowane za pomocą koncepcji łańcucha przetwarzania żądań. Składa się on z trzech etapów:

1. Filtrowania  tworzone jest zapytanie, w oparciu o kryteria dostarczone przez użytkownika. Pozwala to na wybranie docelowych dokumentów (bądź innych obiektów) będących przedmiotem analizy.

2. Przetwarzania  równoległe procesy przetwarzają znalezione obiekty, wydoby-wając z nich wybrane dane (np. kontekst, informacje o sentymencie, liczbę wystą-pień danego terminu, etc.)

3. Łączenia  wydobyte dane zostają znormalizowane, połączone i przetworzone do wybranej postaci docelowej.

12http://morfologik.blogspot.com/

13http://www.getopt.org/stempel/