Złożoność obliczeniowa

W porównaniu do podejścia przedstawionego przez Schenkera et al. [Schenker 2005], od strony kosztów obliczeniowych, proponowane warianty cechuje głównie dodatko-wy nakład czasu potrzebny na ustalenie części mododatko-wy dodatko-wyrazów oraz znalezienia

słowo-sensów.

Tagowanie części mowy jest złożonym procesem, który zależy od specyfiki danego języka i przyjętego algorytmu uczenia tagera. W typowej postaci, proces ten wymaga wykonania analizy morfologicznej, znalezienia kandydatów dla danego słowa i dez-ambiguacji (uściślenia). Zatem o ile w optymistycznym przypadku oznaczać to będzie znalezienie odpowiedniej pozycji w słowniku, to w pesymistycznym wariancie moż-na się spodziewać złożoności O(ls²) (dla tagerów opartych o ukryte modele Markova),

3.3. Propozycje wariantów budowy grafu dedyk. do wybranych zastosowań 61

szczęść* ^{robi dobrze ciało*}

Szczęście robi dobrze _ciału smutek rozwija siłę umysłu

, ale

Schenker

STOP

smutek* rozwija ^siła* umysł*

szczęść* ^ciało*

robi

+1 słowosens

smutek* ^siła* umysł*

dobrze +1 słowosens rozwija +1 słowosens Wariant C Wariant A szczęść* ^ciało* robi +1 słowosens

smutek* ^{siła* umysł*}

dobrze +1 słowosens rozwija +1 słowosens Wariant B ale STOP szczęść* ^{robi ciało*} +1 słowosens

smutek* _rozwija ^{siła* umysł*}

+1 słowosens ale dobrze STOP szczęść* ^ciało* robi +1 słowosens

smutek* ^{siła* umysł*}

NN NN dobrze +1 słowosens NN rozwija +1 słowosens NN Wariant D ale NN POS POS

NEG _NEG NEG

NEG

Rysunek 3.5: „Szczęście robi dobrze ciału, ale smutek rozwija siłę umysłu.” - metoda Schenkera, warianty A, B, C oraz D

3.3. Propozycje wariantów budowy grafu dedyk. do wybranych zastosowań 62

gdzie l to długość analizowanego zdania, a s to liczba możliwych stanów (tagów które można przypisać) [Hall 2003].

Wyszukiwanie słowosensów jest w istocie przeszukiwaniem binarnym słownika, więc można oczekiwać iż złożoność obliczeniowa tego etapu wynosi O(log n).

Należy zwrócić uwagę, że graf utworzony z wykorzystaniem dowolnego z propo-nowanych wariantów cechuje mniejsza liczba węzłów, niż gdyby wybrać wszystkie ter-miny znajdujące się w dokumencie (co ma miejsce w przypadku propozycji Schenke-ra et al.). W związku z tym, bez stosowania dodatkowego filtrowania (np. odsiewając rzadko występujące terminy, co ostatecznie wpływa niekorzystnie na dokładność uzy-skiwanych rezultatów [Schenker 2005]) uzyskuje się grafy o relatywnie niedużych roz-miarach, co ma pozytywny efekt na wydajność dalszych etapów przetwarzania. 3.3.7 Podsumowanie

Przedstawiona rodzina metod stanowi kolejne narzędzie inżynierii lingwistycznej, uogólnienie prac Schenkera et al. [Schenker 2005]. Będąc, w istocie, uporządkowaną me-todologią, pozwala kształtować reprezentację treści wypowiedzi, stosownie do danego zagadnienia. Użycie grafu umożliwia realizację tego w swobodny i intuicyjny sposób, poprzez inżynierię odpowiednich reguł dokładania wierzchołków i krawędzi. Efekt końcowy przypomina sieć semantyczną.

Mechanizm budowy grafu może zostać podzielony na trzy główne poziomy, osobno dla węzłów i połączeń. W przypadku tych pierwszych, jest to:

• filtrowanie  wierzchołki tworzone na podstawie wybranych terminów występu-jących w tekście,

• transformacja  wierzchołki tworzone poprzez przetworzenia występujących w tekście terminow,

• generacja  wierzchołki są syntetycznymi cechami, stworzonymi w trakcie analizy treści dokument.

W przypadku krawędzi:

• porządek naturalny  połączenia dodawane są bezpośrednio między sukcesywnie występującymi terminami z których stworzone zostały węzły, zgodnie z kolejno-ścią terminów,

• skróty  wybrane wierzchołki zostają bezpośrednio połączone, przy czym dana reguła ustala jeden z końców zgodnie z porządkiem naturalnym,

• połączenia wygenerowane  krawędź może powstać pomiędzy dowolnymi dwoma wierzchołkami.

W porównaniu do worka słów, grafy są zdecydowanie bogatszą metodą reprezen-tacji treści. Ich stosowanie niesie jednak ze sobą również pewne wyzwania. Użycie go w metodach sztucznej inteligencji pociąga często za sobą potrzebę „zrzutowania” go do znacznie prostszej formy (wektora), a algorytmy, które opierają się na grafach bez-pośrednio, mają często istotną złożoność obliczeniową.).

3.3. Propozycje wariantów budowy grafu dedyk. do wybranych zastosowań 63

Staranne zbadanie możliwości, płynących z zastosowania prezentowanej rodziny metod, wymaga budowy adekwatnego środowiska testowego. Pozwoli ono, z jednej strony, porównać rezultaty między rozważanymi propozycjami a metodą Schenkera oraz wektorowymi. Z drugiej  umożliwi realizację tego na różnych, rozbudowanych, zbiorach testowych. Konieczna będzie także integracja z różnymi narzędziami lingwi-stycznymi (oprócz stemmera, także np. taggera części mowy czy też słownika sentymen-tu) oraz normalizacja przetwarzania dokumentow, procesów ekstrakcji cech oraz kla-syfikacji, tak aby wszelkie porównania miały zasadność.

Z uwagi na badawczy charakter prac, przydatne jest także dostarczenie różnorakich metryk dotyczących charakteru analizowanych zbiorów oraz integracja ze statystyczny-mi testastatystyczny-mi istotności przy analizowaniu uzyskanych rezultatów.

Problematyka związana z realizacją tego środowiska przedstawiona została w na-stępnym rozdziale.

Rozdział 4

Implementacja laboratoryjna

rodziny metod

Równolegle z opracowywaniem koncepcji metody, prowadzono prace nad systemem, który pozwalał na praktyczne weryfikowanie bieżących hipotez. Wraz z rozwojem prac pojawiały się kolejne wymagania. Ich ostateczna wersja dla systemu testującego jest na-stępująca:

1. Automatyzacja działania  potrzebna do sprawnego badania zachowania roz-ważanych metod, w różnych kombinacjach parametrów oraz zbiorów danych. 2. Wsparcie wybranych formatów korpusów  każdy z rozważanych zbiorów

te-stowych posiada specyficzny format i organizację (np. system oznaczania i licz-ność kategorii), który należało brać pod uwagę podczas wczytywania danych. 3. Filtrowanie danych wejściowych  w zależności od rodzaju wykonywanego

te-stu i cech analizowanego zbioru, pożadane było dostarczenie możliwości próbko-wania (ograniczenia wielkości zbioru) bądź filtropróbko-wania na podstawie wybranych cech (np. wybranych kategorii).

4. Integracja z wybranymi podsystemami  o ile większość wykorzystywanych na-rzędzi dostępna była w formie bibliotek, to niektóre działały jedynie jako osobne systemy, dla których konieczne było odpowiednie dostarczenie i odebranie anali-zowanych danych.

5. Dostarczenie funkcjonalności uczenia i sprawdzania  Z poziomu systemu po-winno się dać obsługiwać zarówno proces uczenia jak i sprawdzania danych, tak aby stosować te same metody podziału zbiorów oraz zapewnić izolację przykła-dów, które posłużyły do uczenia, od tych stosowanych przy weryfikacji.

6. Obsługa zarówno metod grafowych jak i wektorowych  konieczne było zaim-plementowanie niektórych części systemu, tak aby działały zarówno z metodami grafowymi jak i wektorowymi. Dotyczyło to w szczególności metod wyboru cech, algorytmu k-najbliższych sąsiadów, stosowanych metryk, metod budowania wekto-rów dla pozostałych algorytmów maszynowego uczenia.

7. Możliwość porównania wyników różnych metod dla tych samych przypad-ków testowych  każda z metod powinna być testowana równolegle z innymi, co eliminuje różnice związane z fluktuacjami podczas wyboru zbiorów uczą-cych/testowych (np. kiedy jednej metodzie mógłby się przypadkowo trafić „ła-twiejszy” podzbiór).

4.1. Architektura systemu testującego 65

8. Obsługa wielu metryk, na wielu poziomach grupowania danych  konieczne do sprawnego porównywania rezultatów, zarówno na poziomie całości, jak i po-szczególnych kategorii lub podzbiorów.

9. Wydobycie dodatkowych informacji  pomocnych przy analizie charakteru ba-danego zbioru (np. rozkład danych cech języka, występowanie kategorii, średnia długość tekstu, etc.)

4.1 Architektura systemu testującego

Pierwotne wersje systemu działały jako aplikacje jednowątkowe, zapisujące dane (np. słownik, model dokumentu) w bazie relacyjnej. Kolejna wersja zrezygnowała z bazy re-lacyjnej na korzyść prostej persystencji w systemie plików oraz uruchamiała kilka zadań w osobnych wątkach. Wraz ze zwiększeniem zakresu danych, które były przedmiotem analizy oraz testowaniem wielu wariantów jednocześnie, czas przeprowadzania poje-dyńczego testu istotnie się wydłużył. W związku z tym, kolejna wersja została zaim-plementowana jako system w architekture MapReduce, zachowujący dane pomocnicze w bazie typu BigTable. Użyto do tego celu odpowiednio Hadoop oraz HBase. Finalnym etapem rozwoju systemu była integracja z CLUO (por.6) wraz z włączeniem w jego łań-cuch przetwarzania oraz persystencji danych. Dzięki temu, rezultaty niniejszych prac badawczych mogły wspomóc działanie komercyjnego systemu Text Mining.

Proces testowania został przedstawiony na rys.4.1. W pierwszej kolejności koniecz-ne jest zaimportowanie rozważakoniecz-nego zbioru. W wyniku tego procesu otrzymywakoniecz-ne są poszczególne dokumenty wraz z odpowiadającymi im kategoriami oraz treścią i (opcjo-nalnie) tytułem. Dane te są następnie przedmiotem wstępnego przetwarzania, na które składa się:

• Tokenizacja i segmentacja  tekst źródłowy zostaje podzielony na zdania i wy-razy. W pierwszej wersji systemu stosowano wewnętrzne metody dostępne w sto-sowanych tagerach części mowy – wówczas TaKIPI oraz Stanford POS Tagger (kiedy analizowano dokumenty w języku angielskim). Obecna wersja wykorzystuje to-kenizer 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). • Tagowanie częsci mowy  w początkowych pracach stosowano znakomity

pro-jekt TaKIPI³ [Piasecki 2007], jednak problemy z licencjonowaniem wykorzysty-wanych przez niego komponentów oraz integracją (program jest dostępny z linii poleceń, a jego instalacja wymaga również konfiguracji zależności, co utrudnia korzystanie z niego w rozproszonym środowisku przetwarzania) spowodowały, iż zaczęto poszukiwać alternatywnego rozwiązania. Ostatecznie, zdecydowano

1http://lucene.apache.org

2http://unicode.org/reports/tr29/

4.1. Architektura systemu testującego 66 Zbiór dokumentów Import Tokenizacja i segmentacja Tagowanie sentymentem Znajdowanie rdzeni Tagowanie części mowy Zbudowanie modelu Uczenie oraz weryfikacja Zebranie rezultatów Wydobycie cech Podział na zbiory uczące i testujące dla każdej kategorii

DB

Podsumowanie wyników Dla każdej testowanej

metody Wstępne przetwarzanie,

dla każdego dokumentu

Rysunek 4.1: Proces działania systemu testującego

się na opracowanie własnego tagera podstawowych kategorii gramatycznych (opi-sanego w4.5). W przypadku testów dla języka angielskiego, wykorzystywany był

Stanford POS Tagger4

[Toutanova 2000].

• Znajdowanie rdzeni wyrazów (stemming)  w przypadku tekstów w jezyku pol-skim stosowany jest podwójny proces, w którym najpierw następuje próba zna-lezienia lematu za pomocą biblioteki morfologik-stemming⁵, a jeśli nie udaje się go znaleźć, zwracany jest algorytmicznie znaleziony rdzeń z zastosowaniem

Stempe-la6

. Powodem tej dychotomii jest istotna niedokładność działania Stempela, który niekiedy zwraca różne wyniki dla form wyrazowych niektórych popularnych ter-minów. W przypadku pozostałych języków, wykorzystana jest popularna

biblio-4http://nlp.stanford.edu/software/tagger.shtml

5http://morfologik.blogspot.com/

4.1. Architektura systemu testującego 67

teka Snowball⁷.

• Tagowanie sentymentem  za pomocą tagera systemu CLUO, oznaczane zostają terminy mogące nieść istone informacje związane z sentymentem wypowiedzi. Dysponując tymi informacjami, możliwe jest już zbudowanie reprezentacji tekstu, dla każdego badanego wariantu. Wcześniej jednak, system dokonuje podziału doku-mentów na podzbiory testowe i uczące, zgodnie z rozważanymi kategoriami. Dzięki wykonaniu tego już na tym etapie, późniejsze testy wykonywane będą na takich sa-mych podzbiorach dla każdej sprawdzanej metody.

Podział na zbiory testowe i uczące

Stosując uczenie z nadzorem, konieczny jest dostęp do zbioru zawierającego przykłady oraz odpowiadające im kategorie. Aby zmierzyć jakość wyników osiąganych przez daną metodę, wymagane jest dostarczenie zarówno podzbioru treningowego (do uczenia) jak i weryfikującego (do testów). Zrealizować to można na dwa sposoby:

• statycznie zdefiniować dwa odrębne podzbiory  testowy i treningowy  przy-pisując do nich przykłady  podejście takie zapewnia stabilność uzyskiwanych wyników, ale ogranicza ilość przykładów, jakie mogą występować podczas ucze-nia i weryfikacji,

• zastosować kroswalidację (cross-validation, sprawdzian krzyżowy)  zbiór jest dzielony na N podzbiorów, na których następnie iteracyjnie jest dokonywany pro-ces uczenia i walidacji, w taki sposób, że najpierw zbiór 1 jest zbiorem walidu-jącym, a 2 . . . N uczącymi, następnie zbiór 2 jest zbiorem waliduwalidu-jącym, a 1 oraz 3 . . . N uczącymi, itd.; podejście takie pozwala szeroko zbadać metodę klasyfika-cji, korzystając z możliwie dużego zbioru uczącego i nie pomijając żadnego przy-kładu podczas uczenia lub walidacji.

Klasyfikacja binarna a wieloklasowa

Wiele algorytmów klasyfikacji umożliwia jedynie klasyfikację binarną. To znaczy, okre-ślane jest, czy dany przykład należy do rozpatrywanej klasy, czy też nie. W praktyce jed-nak, często ma się do czynienia z problemem przypisania jednej z wielu klas. Zależnie od konkretnego problemu można tutaj zastosować jedną ze strategii:

• przypisać najbardziej prawdopodobną klasę  w takim wypadku, każdy doku-ment będzie przynależał do dokładnie jednej klasy; użyty klasyfikator musi do-starczyć możliwość zmierzenia istotności każdej z klas; sytuacja taka występuje na przykład podczas klasyfikacji sentymentu, gdzie każdemu dokumentowi mo-że zostać przypisana dokładnie jedna z kategorii: negatywny, pozytywny, neutralny, • dokonać klasyfikacji dla każdej z klas z osobna  wówczas każdemu przykła-dowi zostaje przypisane od 0 do N kategorii; każdy klasyfikator binarny zwraca