Fakulta elektrotechnická Katedra počítačů. Bc. Vítězslav Musil

Č ESKÉ VYSOKÉ UČENÍ TECHNICKÉ V P RAZE Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Služba čtení sumarizovaných zpráv na SmartKiosku Bc. Vítězslav Musil

Vedoucí práce: Ing. Ladislav Kunc Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 27. listopadu 2011

v

Poděkování Ze všeho nejvíce bych chtěl poděkovat svému vedoucímu Ing. Ladislavu Kuncovi, bez jehož nápadů a rad by tato práce nevznikla. Dále děkuji těm, kteří se na této práci nepřímo účastnili. Zejména mým testerům a přátelům, jmenovitě Ing. Tomáši Skopcovi, MUDr. Hance Hroudové a Bc. Josefu Hroudovi. Také děkuji výrobcům kafe a energetických nápojů, bez nichž by vypracování této práce trvalo mnohem déle.

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 27. 11. 2011

ix

Abstract Summarized News Reading in SmartKiosk The aim of this work is to design and implement application handled from Touch Screen Kiosk. This will serve to download English articles from servers contained news and will present it in a short form to user by help of some free summarization technologies, e.g. Java Text Mining Toolkit. An existing project “Talking head” was used to present and read these articles.

Abstrakt Služba čtení sumarizovaných zpráv na SmartKiosku Cílem této práce je navrhnout a implementovat aplikaci ovládanou z dotykového kiosku. Ta bude sloužit ke stažení anglického článku ze zpravodajského serveru, který bude prezentován ve zkrácené verzi uživateli. Shrnutí staženého článku bude dosaženo pomocí některého z volně dostupných sumarizačních algoritmů, například Java Text Mining Toolkitu. K prezentování a přečtení článku v angličtině bude použit již existující projekt zvaný “Talking head“ (mluvící hlava).

xi

Obsah KAPITOLA 1 .................................................................................................................... 1 Úvod ............................................................................................................................................... 1 1.1

Struktura textu ............................................................................................................. 2

1.2

Cíle diplomové práce ................................................................................................. 2

KAPITOLA 2 .................................................................................................................... 5 RSS - Rešerše I ............................................................................................................................ 5 2.1

Definice ........................................................................................................................... 5

2.2

Historie ........................................................................................................................... 5

2.3

RSS verze 1.0 a 2.0 ...................................................................................................... 6

2.3.1 Příklad XML ........................................................................................................... 6 2.3.2 Příklad RSS verze 1.0 ......................................................................................... 7 2.3.3 Příklad RSS verze 2.0 ......................................................................................... 7 2.4

RSS tagy ........................................................................................................................... 8

2.4.1 Povinné RSS tagy dle: ........................................................................................ 8 2.4.2 Nepovinné RSS tagy dle .................................................................................... 9 KAPITOLA 3 ................................................................................................................. 11 Sumarizační technologie - Rešerše II ............................................................................. 11 3.1

Definice ........................................................................................................................ 12

3.2

Vznik ............................................................................................................................. 12

3.3

Vstupní aspekty ........................................................................................................ 13

3.3.1 Počet vstupních dokumentů ....................................................................... 13 3.3.2 Struktura dokumentu .................................................................................... 14 3.3.3 Jazyková závislost ........................................................................................... 14 3.3.4 Délka vstupního textu .................................................................................... 14 3.3.5 Domain versus General aspekt ................................................................... 15

xii 3.4

Výstupní aspekty ...................................................................................................... 15

3.4.1 Typ výstupu ....................................................................................................... 15 3.4.1 Zobrazení výstupu ........................................................................................... 16 3.4.2 Délka souhrnu ................................................................................................... 16 3.5

Dělení podle účelu ................................................................................................... 17

3.5.1 Podle míry informovanosti .......................................................................... 17 3.5.2 Rozdělení souhrnů s ohledem na požadavky uživatele .................... 17 3.6

Sumarizační metody ............................................................................................... 18

3.7

Hodnocení kvality souhrnu .................................................................................. 19

3.7.1 Typy hodnotících metod ............................................................................... 20 3.7.2 Co je třeba hodnotit ........................................................................................ 20 3.8

ROUGE (Recall-Oriented Understudy for Gisting Evaluation) ................... 21

3.8.1 Definice ................................................................................................................ 21 3.8.2 Způsoby hodnocení ......................................................................................... 22 KAPITOLA 4 ................................................................................................................. 25 Architektura ............................................................................................................................. 25 4.1

Návrh ............................................................................................................................ 25

4.2

UML ................................................................................................................................ 26

4.2.1 Use Case diagram.............................................................................................. 26 4.2.2 Diagram nasazení ............................................................................................ 27 KAPITOLA 5 ................................................................................................................. 29 Implementace .......................................................................................................................... 29 5.1

Sumarizační algoritmy ........................................................................................... 29

5.1.1 Jak porovnávat .................................................................................................. 29 5.1.2 Jak získat souhrny ........................................................................................... 31 5.1.3 Výsledky .............................................................................................................. 32 5.2

Algoritmus Lucene ................................................................................................... 41

xiii 5.2.1 Používané praktiky ......................................................................................... 41 5.2.2 Pseudo-algoritmus .......................................................................................... 42 5.3

BoilerPipe .................................................................................................................... 42

5.4

Talking Head (TH) ................................................................................................... 45

5.4.1 Algoritmus TH ................................................................................................... 45 5.4.2 Schopnosti TH ................................................................................................... 46 5.4.3 Spuštění a nastavení....................................................................................... 46 5.4.4 Činnost klienta .................................................................................................. 47 KAPITOLA 6 ................................................................................................................. 51 Usability testing ....................................................................................................................... 51 6.1

Vstupní dotazník ...................................................................................................... 51

6.2

Co je možné v aplikaci otestovat ........................................................................ 51

6.3

Výstupní dotazník .................................................................................................... 52

6.4

Odpovědi ..................................................................................................................... 52

KAPITOLA 7 ................................................................................................................. 57 Závěr ........................................................................................................................................... 57 7.1

Splnění cílů ................................................................................................................. 57

7.2

Možnosti vylepšení.................................................................................................. 58

7.3

Zhodnocení ................................................................................................................. 59

Literatura .................................................................................................................................. 61 Příloha A – Seznam použitých zkratek .......................................................................... 63 Příloha B – Obsah přiloženého CD ................................................................................... 65

xv

Seznam obrázků Obrázek 1 – RSS feed ................................................................................................................ 5 Obrázek 2 – Use Case diagram ........................................................................................... 26 Obrázek 3 – Diagram nasazení ......................................................................................... 27 Obrázek 4 – ROUGE-SU4 ...................................................................................................... 37 Obrázek 5 – ROUGE-W-1.2 .................................................................................................. 38 Obrázek 6 – Odchylky Lucene od průměrné hodnoty ROUGE-SU4 ..................... 39 Obrázek 7 – Odchylky Lucene od průměrné hodnoty ROUGE-W-1.2 ................. 39 Obrázek 8 – Screenshot aplikace verze 1.0 ................................................................... 47 Obrázek 9 – Screenshot aplikace verze 2.0 ................................................................... 56

xvii

Seznam tabulek Tabulka 1 – Pearsonova korelace u DUC 2001 a 2002 ............................................ 30 Tabulka 2 – Pearsonova korelace u DUC 2003 ........................................................... 30 Tabulka 3 – ROUGE-SU4 (Average Recall Score)......................................................... 35 Tabulka 4 – ROUGE-W-1.2 (Average Recall Score)..................................................... 36 Tabulka 5 – Vliv parametrů Lucene na jeho průměrné ROUGE-SU4 skóre ...... 40 Tabulka 6 – Usability testing .............................................................................................. 52

1

KAPITOLA 1 Úvod V dnešní době obsahuje internetová síť mnoho informací. Díky tomu nastává čas, kdy klesají prodeje novinek a zpráv tištěných na papír. Různé noviny, časopisy a dokonce i knížky se přestávají prodávat. Není to ale proto, že by lidé přestali číst. Pouze přestali kupovat potištěný papír a začali používat moderní způsoby čtení, např. z mobilního telefonu nebo z elektronické čtečky knih, která je skladnější než jedna průměrná knížka a zároveň se do ní vejde mnohem více textu. Tato čtečka ale neslouží jen ke čtení knížek, ale samozřejmě i ke čtení zpráv ze světa aj. Díky bezdrátovému připojení si tak uživatel stáhne nejnovější zprávy během okamžiku a může si je kdekoliv, kde má přístup k internetu, přečíst. Jelikož je však informací mnoho a člověk má stále méně a méně času, začaly se vyvíjet tzv. sumarizační techniky, jejichž úkolem je shrnout text do kratší formy tak, aby se zachovalo jádro textu a další podstatné informace. V této práci se budeme zabývat zejména těmito technikami; jak je porovnat, jestli jsou závislé na jazyce a druhu textu atd. Dále jsme se rozhodli naprogramovat aplikaci, která bude používat volně dostupný, co nejvíce kvalitní sumarizační algoritmus. Aplikace, která je součástí této práce, jde však mnohem dále. Článek, který si uživatel ze zpravodajského serveru stáhne, nejenže shrne do podstatně menší části, ale zároveň je schopná jej přečíst, a to díky projektu Talking head (“mluvící hlava“). Prozatím je však možné přečíst články psané pouze v anglickém, případně italském jazyce. Dnes se také často přechází na zařízení s dotykovou obrazovkou. Pomalu každý má dotykový mobil. Počítače v knihovnách, bankách a v nákupních centrech jsou také často vybaveny dotykovou obrazovkou, pro kterou je Talking head velmi vhodná. Představte si, že přijdete do novinového článku a místo kupování novin hodíte drobnou bankovku do malého počítače s dotykovou obrazovkou a ta Vám během pár minut sdělí všelijaké novinky ve zkrácené podobě. Nebo budete mít tuto aplikaci přímo v mobilním telefonu kdekoliv u sebe, což bude čím dál tím víc běžné, protože internetové připojení potřebné ke stažení článků má dneska velká

2 část lidí. Proto je naše aplikace spustitelná nejen na běžném počítači, ale i na dotykovém kiosku vybaveném operačním systémem Windows. Je to jakýsi předvoj k aplikacím podobného druhu, které časem poběží třeba i na Vašem dotykovém mobilním telefonu.

1.1 Cíle diplomové práce Hlavním cílem je pomocí projektu Talking head (dále pouze TH) navrhnout a implementovat aplikaci, která bude běžet na dotykově ovládaném kiosku. Ta bude umět stáhnout článek z některého ze zpravodajských serverů, který bude zkrácen pomocí sumarizačního algoritmu a prezentován (přečten) uživateli. Náš cíl se skládá hlavně z těchto problémů: potřebujeme získat html link na článek ze zpravodajského serveru a přitom nechceme, aby uživatel vyhledával linky nebo aktuální články po internetu pokud máme odkaz na článek, potřebujeme z něj získat pouze relevantní text a nikoliv reklamy či odkazy na jiné články, menu, záhlaví atd. ke shrnutí získaného textu potřebujeme vybrat nejlepší volně dostupnou sumarizační technologii, z čehož plyne další problém, a to, jak vlastně porovnávat výsledné souhrny po splnění předchozích bodů nám zbývá navrhnout uživatelské rozhraní, které bude uživatelsky přívětivé, rychlé a hlavně funkční. V něm pošleme výsledný text mluvící hlavě, která jej odprezentuje. Nakonec otestujeme pomocí několika potenciálních uživatelů, zdali jsme tyto problémy úspěšně vyřešili.

1.1 Struktura textu Tato diplomová práce je rozdělena dle obvyklých standardů do několika kapitol: V kapitole 1 jsme si řekli, co je účelem této práce a uvedli si naše cíle, kterých bychom rádi dosáhli. Také jsme se zmíníli o hlavních problémech, které bylo potřeba vyřešit před samotnou implementací.

3 2. kapitola pojednává o způsobu získání článků ze zpravodajských serverů pomocí RSS zdrojů. 3. kapitola obsahuje rešerši existujících sumarizačních algoritmů, jejich techniky a zejména hodnocení výsledných souhrnů. Kapitola 4 se zabývá architekturou a návrhem aplikace. Obsahuje i některé UML diagramy. Kapitola 5 pojednává o implementaci algoritmů a samotného programu. Otestujeme zde hlavně různé druhy sumarizačních technik. Kapitola 6 je o testování výsledného programu. Je zde popsán test použitelnosti a hodnocení několika vybranými uživateli. Kapitolou 7, jenž je kapitolou poslední, je závěrečné ohodnocení našich cílů. Zda jsme byli úspěšní a co by bylo možné ještě vylepšit.

5

KAPITOLA 2 RSS - Rešerše I V této kapitole bychom chtěli seznámit čtenáře zejména s formátem RSS, který slouží jako zdroj aktuálních článků ze zpravodajských serverů. Srovnáme si i jeho dvě nejčastější verze.

2.1 Definice Co je to vlastně RSS? A co je to feed (někdy se setkáme i s termínem channel (kanál))? V předkladu to znamená “krmítko“, což je vlastně dosti výstižný termín. Jde o XML (Extensible Markup Language) formát, který slouží jako informační zdroj upozorňující uživatele na nejaktuálnější zprávy. Procházíte každý den nejznámější webové stránky a hledáte aktuální informace? Právě toto ulehčuje RSS kanál, který je vstupem pro RSS čtečku, což je program umožňující zobrazit úryvek z článku, titulek, autora, datum vytvoření, jméno serveru, ze kterého byl článek stažen a hlavně odkaz na jeho kompletní verzi. Může obsahovat i jiné nepovinné údaje v závislosti na verzi RSS. A kde vlastně tento RSS kanál získat? Najdeme jej na zpravodajských webových stránkách, zejména tam, kde jsou stále nové a nové zprávy, případně na některém z uživatelských blogů. RSS feed je vždy doprovázen ikonou, která znázorňuje oranžový čtvereček s bílými rádio vlnami:

Obrázek 1 – RSS feed

2.2 Historie Dle [1] RSS vymyslela původně firma Netscape v roce 1999. Z první verze 0.90 byla odebrána podpora RDF [2] (Resource Description Framework – systém popisu zdrojů) a vznikla tak verze 0.91. V roce 2000 se proto vývoj RSS rozděluje do dvou odvětví: Verzi 1.0 vyvíjí skupina RSS-DEV Working Group a vychází z původní verze 0.90, která je rozšířena o formát RDF 1.0, a proto není zpětně

6 kompatibilní s verzí 0.91. Označení RSS 1.x je někdy nahrazeno písmeny RDF 1.x. Druhé odvětví zastupuje verze 0.92 od firmy UserLand Software, která je kompatibilní s verzí 0.91. V roce 2002 je vydána její nejznámější verze RSS 2.0, se kterou se změnila zkratka Rich Site Summary na Really Simple Syndication. V dnešní době je vývoj ukončen ve verzi 2.0.1, která se používá nejvíce. Pro úplnost musíme zmínit ještě formát CDF [1] (Channel Definition Format), který se v praxi vůbec neprosadil a poměrně nový formát Atom [3] (plným názvem Atom Syndication Format), který navazuje na ukončený vývoj RSS. Při jeho vývoji byl kladen důraz na jednoduchost a pokus opravit limitace formátu RSS. Protože je však RSS starší formát a je tedy mnohem více rozšířený, nebudeme se formátem Atom zaobírat podrobněji. Z laického hlediska se dá říci, že jsou pouze některé názvy tagů vhodněji pojmenovány a některé doplněny. Co je to tag, viz kapitola 2.3.1.

2.3 RSS verze 1.0 a 2.0 Hlavní rozdíl mezi verzí 1.0 a 2.0 je v podstatě jen v přídavných informacích a jejich jednodušším zápisem. Verze 1.0 nám kromě názvu a krátkého popisu neřekne nic navíc. Kdežto verze 2.0 umožňuje tvůrci RSS kanálu zahrnout i další informace jako je autor článku, datum jeho vydání atd. Zejména datum umožňuje RSS čtečce seřadit více článků podle aktuálnosti. Tyto informace se zapisují uvnitř párových tagů ve formě XML, které musí mít název shodný s danou specifikací té či oné verze RSS, jinak by nebyly čitelné ve všech RSS čtečkách.

2.3.1

Příklad XML

párový tag jmeno:

<jmeno>Vítězslav Musil

nepárový tag dalsiRadek:

7

2.3.2

Příklad RSS verze 1.0

]> Zpravodajský server http://zpravodajskyServer.cz <description>informace nejen o počasí cs Nehoda na dálnici D1 http://zpravodajskyServer.cz/nehody/nehodaD1.html <description>Na dálnici D1 došlo opět ke střetu několika vozidel. Na místě je již policie a usměrňuje provoz do jednoho pruhu. Nehoda se obešla bez zranění. Příčinou srážky dvou vozidel typu Škoda je nejspíše nepřizpůsobení jízdy stavu vozovky. ...

2.3.3

Příklad RSS verze 2.0

/ Zpravodajský server zpravodajskyServer.cz/logo.gif Zpravodajský server – Hlavní stránka zpravodajskyServer.cz <description>informace nejen o počasí cs Fri, 2 Dec 2011 21:48:51 GMT Nehoda na dálnici D1 /nehody/nehodaD1.html <description>Na dálnici D1 došlo opět ke střetu několika vozidel. Na místě je již policie a usměrňuje provoz do jednoho pruhu. Nehoda se obešla bez zranění. Příčinou srážky dvou vozidel typu Škoda je nejspíše nepřizpůsobení jízdy stavu vozovky.

8 [email protected] ...

Z příkladů je vidět, že RSS verze 2.0 je čitelnější a v tomto případě obsahuje navíc datum publikování a autora článku. Naše aplikace proto bude používat pouze tuto verzi.

2.4 RSS tagy Z důvodu mnohem většího rozšíření se budeme zabývat pouze tagy verze 2.0 dle [4].

2.4.1

Povinné RSS tagy:

o

obsahuje informace o daném kanále. Musí obsahovat tagy (jméno kanálu), <link> (url webu), <description> (popis kanálu) a <image> (XML element s odkazem na logo webu. Obsahuje další povinné elementy <link>, <title>, <url>) <description> o je textový popis uvnitř elementu <channel>, <item>, <image> a <textinput> <language> o specifikuje jazyk daného kanálu <link> o adresa dané položky či webu. Opět se vyskytuje uvnitř <channel>, <item>, <image> a <textinput> <title> o je textová reprezentace dané položky v závislosti na umístění. Pokud se použije uvnitř <item>, slouží jako jméno odkazu. Uvnitř <image> označuje alternativní text obrázku. V elementu <channel> značí titulek daného kanálu a v elementu <textinput> titulek textového pole. 9 2.4.2 Nepovinné RSS tagy Protože je nepovinných tagů mnohem více než povinných, uvedeme si pouze ty nejzajímavější: <?xml?> o identifikuje verzi xml dokumentu a použité kódování. Nejčastější výskyt je tento: <?xml version=”1.0 encoding=”UTF-8”?> <author rel="nofollow"> o obsahuje emailovou adresu autora článku uvedeného jako internetový odkaz v položce <item>. Z důvodů spamu se mu někteří vývojáři vyhýbají. <item> o nejdůležitější položka obsahující článek z RSS kanálu <pubDate> o datum poslední publikace buď pro celý RSS xml soubor nebo pro samotnou položku <item> (záleží na umístění pubDate) <lastBuildDate> o čas poslední modifikace RSS xml souboru Další existující tagy jsou například: <comments>, <enclosure>, <category>, <cloud>, <copyright>, <docs>, <generator>, <guid>, <height>, <managingEditor>, <rating>, <rss>, <skipDate>, <skipHours>, <source>, <textInput>, <ttl>, <url>, <webMaster>, <width>, a značení pro komentář  . 11 KAPITOLA 3 Sumarizační technologie - Rešerše II Na první pohled je důvodem pro vytváření souhrnů ušetření času při čtení dlouhého textu. Každý z nás jistě potřeboval někdy nastudovat informace z tisku nebo z učebnice. Z toho plyne potřeba mít informace co nejkvalitnější a pokud možno s co nejmenším úsilím vstřebatelné. Ne všichni máme trpělivost číst stále dokola redundantní a dlouhé zprávy a vyhledávat v nich to, co potřebujeme. Téma, o kterém se chceme něco dozvědět, nemusí také být pouze v jediném dokumentu. Zajímáme se například o určitý motiv, ale nechce se nám přitom číst stohy knih. Tyto technologie nejenže pomohou vybrat nejvhodnější knihu, ale zároveň ji zkomprimují do kratší formy. Sumarizací se může rozumět i automatické vytváření titulků k novinovým zprávám nebo vytvoření abstraktu například k této diplomové práci společně s jejím názvem. Bohužel nelze jakýkoliv text zkrátit vždy do jedné věty, a tak je sumarizace složitou a velmi individuální záležitostí a mnohdy slouží spíše jako ochutnávka toho, co v textu nalezneme. Podobně jako u souborů komprimujeme data pro menší velikost, zde komprimujeme počet slov. Dalo by se nadneseně říci, že jde o jakousi ztrátovou kompresi podobnou jako například u obrázků formátového typu JPEG (Joint Photographic Experts Group). V případě sumarizace ale vyřazujeme nepotřebná či méně důležitá sdělení obsažená v textu tak, aby výsledný souhrn, z důvodu čitelnosti, měl formu vět a nejen pouze slov. Toho dosáhneme tím, že věty nejčastěji z textu celé vyřadíme podle jejich důležitosti nebo je ponecháme, někdy pouze minimálně upravené. V budoucnu se ale dá očekávat, že stroj tvořící souhrn, bude schopen složit postupně celou větu z jednotlivých slov. Takovou vyjímku tvoří již dnes počítač Watson od firmy IBM [5] a jemu podobné. 12 3.1 Definice Než se pustíme do popisování sumarizačních technologií, musíme si definovat, co vlastně slovo sumarizace znamená. Podle [6] jej lze definovat jako: “Vytvoření přesné a stručné reprezentace obsahu dokumentu.“ nebo například jako: “Vyjmutí nejdůležitějších informací ze zdrojového textu s ohledem na úlohy a účely uživatele.“ 3.2 Vznik Ačkoliv by se mohlo zdát, že sumarizační algoritmy se začly vyvíjet teprve s masovým rozvojem internetu, kde je dnes nepředstavitelné množství informací, není tomu tak. První publikace o sumarizaci je z roku 1958 od autora H. P. Luhna [7], v níž je sumarizace řešena pomocí statistických informací odvozených z počtu opakujicích se slov, které mohou být zvýhodněny pozicí uvnitř věty. Tyto frekvence byly počítány automaticky strojem IBM 704 data-processing a to nejdříve pro jednotlivá slova a poté pro celé věty. Ohodnocení slov a vět označujeme jako “váha“. Věty s největším vahou jsou poté extrahovány (vyňaty) z textu a vytištěny na výstup. Další významnou prací je od H.P. Edmundsona z roku 1968 publikace New Methods in Automatic Extracting [8], v níž se autor už nezabývá pouze frekvencí slov, ale dalšími třemi aspekty: tzv. “cue words“, slovy z titulku nebo nadpisu, a umístěním vět v dokumentu. „Cue words“ jsou v překladu věcná slova. Algoritmus postupoval tak, že měl k dispozici tři slovníky věcných slov, které, pokud se vyskytovaly ve větě, ji určitým způsobem ohodnotily zvýšením či naopak snížením váhy slova. Tyto váhy slov se pro každou větu následně pouze sečetly. Slovníky věcných slov byly získány statistickou metodou ze sta různých dokumentů. Jednalo se o slovníky: Bonus words –slova, po nichž zpravidla následovala hodnotná informace. Byly to příslovce typu “závěrem“, “nakonec“ apod. 13 Stigma words – tzv. vycpávky vět. Jde o anaforická vyjádření (slova odkazující na předcházející kontext); nedůležitá, příliš detailní vyjádření; technické a archaické značení atd. Null words –většinou zájmena, předložky, přídavná jména a sloveso “to be“ (být) Dalším aspektem byly slova z nadpisu dokumentu. Je zřejmé, že těmto slovům a jejich synonymům bylo potřeba přikládat větší důležitost. Také umístění vět v dokumentu mělo dle statistiky velký význam. Věty umístěné hned za nadpisem byly mnohem významnější než věty umístěné dále v článku. Stejně jako věty umístěné jako první na začátku odstavce. Mezi několika dalšími významnými publikacemi lze ještě jmenovat práci od J. Kupiec, J. O. Pedersen, F. Chen: A Trainable Document Summarizer [9], ve které se začínají uplatňovat metody umělé inteligence založené na naivním Bayesovském klasifikátoru, kde je pravděpodobnostní model trénován na korpusu (souboru) dvojic: dokument - souhrn. Tento model je pak použit pro vybírání důležitých informací z textu. Z důvodu složitosti se tímto klasifikátorem nebudeme dále zabývat. V dnešní době se sumarizační tématikou a jejím ohodnocováním zabývá zejména konference Document Understanding Conference (DUC), nově nazývaná Text Analysis Conference (TAC) realizovaná organizací NIST (National Institute of Standards and Technology). Následující vstupní, výstupní a účelové aspekty jsou inspirovány publikací [10]. 3.3 Vstupní aspekty Každý z níže uvedených aspektů popisuje vstupní část sumarizátoru. 3.3.1 Počet vstupních dokumentů single dokument – na vstupu je pouze jediný zdrojový dokument, který chceme sumarizovat 14 multi dokument – vstupem je několik jednotek až stovek dokumentů, které spolu často sdílejí nějaké téma a mají mezi sebou souvislosti. Vzniká zde problém redundantnosti informací, který je třeba určitým způsobem řešit. 3.3.2 Struktura dokumentu V některých případech máme k dispozici nejen samotný text, ale i nějaké informace o jeho struktuře. Kupříkladu víme, co je hlavní nebo vedlejší nadpis, úvod, citace, co je závěr, kde začínají a končí odstavce atd. Tyto informace nám v mnohém pomohou vytvořit si představu o tom, co je v dokumentu důležité nebo není. Opakem je plain text, což je strohý text bez jakéhokoliv formátování. 3.3.3 Jazyková závislost závislé nezávislé Jazyková závislost, neboli Language dependency, je důležitou vlastností sumarizátorů. Často je totiž text upravován ještě předtím, než se začnou počítat výskyty slov nebo utvářet vektory podobnosti apod. Například je častým jevem, že nejdříve algoritmus odstraní z vět tzv. stop-words, což jsou slova, která nemají v textu žádný význam a nepřenášejí žádnou důležitou informaci. V případě českého jazyka jde například o zvratné zájmeno “se“, sloveso „být“, různé předložky, spojky, zájmena apod. Při počítání výskytů slov je také důležité znát jejich kořeny nebo mít k dispozici slovník, který nám pomůže určit, že “auto“ a “motorka“, ač mají jiný kořen, jsou slova ze stejného žánru. Používání těchto metod je důsledkem závislosti na jazyce textu.V tomto ohledu jsou lepší algoritmy založené na naivním Bayesovském klasifikátoru, který je jazykově nezávislý. 3.3.4 Délka vstupního textu Pokud máme na vstupu velmi dlouhý dokument, nebudou jednotkou sumarizace věty, ale spíše celé odstavce, které budou jednotlivě ohodnoceny vahou a podle toho následně zařazeny do souhrnu. 15 3.3.5 Domain versus General aspekt Podobně jako v případě struktury dokumentu, nám může pomoci doména. Říká nám, o jakém tématu se v dokumentu pojednává a my toho můžeme využít. Například synonymům k názvu dokumentu nebo slovům spadajícím do daného tématu budeme příkladat větší význam (sumarizátor tyto slova ohodnotí větší vahou). Opakem je general aspekt, kdy o dokumentu nevíme vůbec nic. 3.4 Výstupní aspekty Jedná se o parametry, které nějakým způsobem ovlivňují výstupní souhrn sumarizačního algoritmu. 3.4.1 Typ výstupu Z pohledu složitosti je dělení sumarizátorů podle formy souhrnu nejdůležitější. Člověk takřka vůbec nedělá manuální sumář tak, že by vzal jen podstatné věty z dokumentu. Nejdříve přečte celý text a poté, dle svého vlastního úsudku, sepíše souhrn, který co nejlépe odráží všechny věty v textu. Zatímco počítač v běžné domácnosti nemá svůj vlastní úsudek, textu nemůže porozumět tak dobře jako člověk a jeho vlastní umělá inteligence není zatím natolik vyspělá. Proto jsou stále nejčastější automatické souhrny typu extrakt. Abstrakt o Jde o souhrn nejdůležitějších informací sepsaných formou vět, jejichž slova se nemusí ve vstupním textu vůbec vyskytovat a mohou mít souvislost například s všeobecně známou událostí, která v textu zmíněna vůbec nebyla. Příklad: Vstupní text: „Nedaleko naší chaty jsme zasadili pár nových stromů. Nejdříve jsme vykopali jámu pro dvě jabloně, poté i pro hrušeň a tři švestky.“ Výstupní text: „Poblíž chaty jsme si vytvořili menší ovocný sad.“ 16 V tomto příkladu bychom jako stroj museli znát, že jabloň, hrušeň a švestka jsou ovocné stromy, které mohou dohromady utvářet sad. Pokud by dnešní počítače uměly porozumět významu nejen tohoto textu, mnoho lidí v zaměstnání by jistě nahradily stroje... Extrakt o Z důvodu jednoduchosti jsou výsledkem sumáře typu extrakt věty, které se ve vstupním textu nacházejí. Jde jen o to určit, které věty jsou ty nejdůležitější. Žádné nové se do výstupu nepřidávají. Z tohoto důvodu není nutné textu porozumět, proto je tento typ vhodnější pro počítače. Mohou nám stačit i pouhé statistické údaje o výskytu slov, aniž bychom věděli, co znamenají. Velkou nevýhodou extraktů je, že věty tvořící výstup na sebe nemusí navazovat a mohou obsahovat také redundantní (nadbytečné) informace. Velkým problémem jsou také zájmena, která zastupují podmět z předchozí věty. Pokud bychom vybrali do souhrnu pouze větu s tímto zájmenem, nepoznáme, o čem věta vypovídá. 3.4.1 Zobrazení výstupu Výstupní souhrn lze zobrazit několika různými způsoby. Buď pouze zvýrazníme text ve vstupním dokumentu nebo nahradíme celý dokument výstupem, případně sumarizátor vytvoří nějaké linky do zdrojového dokumentu. 3.4.2 Délka souhrnu Jednotkou délky jsou buď procenta nebo jde nejčastěji o počet slov, případně vět. Dále se vyskytuje i pojem kompresní poměr, což je desetinné číslo mezi nulou a jedničkou. Nejčastěji jde o poměr počtu vět nebo slov mezi zdrojovým textem a jeho souhrnem. Čím větší bude tento poměr, tím bude shrnutý text delší a kvalitnější, ale čas vynaložený na jeho přečtení nebude tak efektivní. 17 3.5 Dělení podle účelu Tyto parametry mají vliv na vnitřní činnost algoritmu v závislosti na tom, k jakému účelu souhrn slouží. 3.5.1 Podle míry informovanosti Indikativní (svědčící)souhrny o Algoritmy hledají v textu věcná slova pro určité téma. Výsledkem je souhrn dávající informaci o tom, co se z textu můžeme dozvědět, jakým tématem se vlastně dokument zabývá. Uživatel se tak může rozhodnout, zdali je čtení celého dokumentu pro něho přínosem. Obvyklá délka indikativních souhrnů je přibližně 10% vstupního textu. Nejčastěji jsou používány jako výstup vyhledávacích systémů. Informativní souhrny o Neslouží již pouze jako “ochutnávka“ vstupního dokumentu, ale shrnují celý text do kratší podoby, po jejímž přečtení je uživatel zběžně seznámen s celým tématem. Míra informování by měla umožnit uživateli vyhnout se čtení celého dokumentu. Z těchto důvodů je původní text zkrácen většinou o 70 až 80%. Agregativní souhrny o obsahují navíc myšlenku, která se ve vstupním textu nevyskytuje Kritické souhrny o součástí souhrnu je nějaká pozitivní či negativní kritika na vstupní text. V tomto případě je nutné znát i sémantiku důležitou k porozumění dokumentu. Automaticky je to i dnes velmi složité a bude ještě nějakou chvíli trvat, než se nějaký takový program vyvine. 3.5.2 Rozdělení souhrnů s ohledem na požadavky uživatele Vstupní text může pojednávat o několika tématech zároveň a je na nás, zdali algoritmu sdělíme, co nás zajímá nebo chceme obecné informace o všem. 18 Text-driven (Generic Summaries) o což znamená “řízený textem“. Při vytváření souhrnu má algoritmus k dispozici pouze text a nic navíc, co by mu pomohlo ke kvalitnějšímu zpracování. User-focused (uživatelsky zaměřený) o kromě vstupního textu jsou zadány některé informace navíc, které algoritmus využije při zpracování, aby splnil uživatelovi požadavky. Může se jednat i o témata, na která by se měl algoritmus více soustředit. Výstup je pak tematicky zaměřený (Topic-focused). o Podskupinou jsou i tzv. Query-focused (dotazově zaměřené), kde chceme pouze najít odpověď na náš dotaz. Aktualizační požadavky (just-the-news) o víme, že uživatel má nějaký přehled o určité oblasti a chceme v textu najít pouze nové informace a aktualizovat tak vlastně předchozí dokumenty či znalosti uživatele. Opakem aktualizačního souhrnu je souhrn typu Background, kdy nemáme k dispozici žádné údaje, které by jsme chtěli aktualizovat. 3.6 Sumarizační metody Dle použitého principu rozdělujeme metody dle [6] nejčastěji na: Heuristické – jsou podobně jako statistické metody založeny na faktu, že často vyskytované termy jsou v textu důležité. Při počítání těchto četností nejsou zahrnuta tzv. stop-words, jako jsou předložky, zájmena zvratné zájmeno “se“ apod. Je zde použita heuristika, kdy slova z nadpisu jsou ohodnocována lépe než slova ostatní, plus je příkládán velký význam slovům následujícím po přídavných jménech jako “důležitý“, “významný“ apod. Statistické – i v tomto případě je počítána četnost jednotlivých slov. Pokud se ale slovo vyskytuje až příliš často, je potřeba mu zmenšit váhu, protože jeho důležitost klesá. Toho dosáhneme tím, že jeho frekvenci (značíme tf (term frequency)) vynásobíme inverzní dokumentovou frekvencí (značíme idf neboli inverted document 19 frequency). K hledání slov, která jsou si podobná, ať už tématem nebo kořenem slova, se používá slovník WordNet [11]. Častěji se ale využívá odlišná metoda založena na naivním Bayesově klasifikátoru [9]. Grafové – zjišťování důležitosti či podobnosti slov je získáváno operacemi například nad stromovou strukturou vytvořenou ze zdrojového dokumentu [12]. V jiných metodách mohou například uzly grafu představovat věty, a hrany mezi uzly souvislosti mezi nimi. Poté se například pomocí metody PageRank [13] vypočítá významnost vrcholů v grafu. Algebraické – mezi tyto metody spadá LSA neboli latentní sémantická analýza, která používá metodu rozkladu matic singulární dekompozicí (SVD) [14]. Z důvodu rozsáhlosti dané tematiky se nebudeme těmito metodami dále zabývat. 3.7 Hodnocení kvality souhrnu Nejdůležitější z problémů, které se vyskytují při výtváření souhrnů, je samotné určení, je-li jeden souhrn lepší než druhý. Jak jsme již zmiňovali dříve, vytvoření souhrnu manuálně je velmi individuální záležitostí. Pokud dáme někomu vytvořit abstrakt, můžeme si být takřka jistí, že nebude takový, jak bychom jej napsali my, pokud bychom jej vytvářeli nezávisle. Tato skutečnost se týká i vytváření extraktů. Viz příklad. Příklad: Vstupní text: „V Praze dnes bouraly dvě tramvaje. Zranilo se 5 lidí těžce a 10 lehce. Pokud by v tomto případě anotátor (tj. člověk hodnotící dokument) vybral první větu a automatický sumarizátor větu druhou, jednalo by se o 100% chybu. Hodnocení kvality souhrnů je proto problém, který je potřeba řešit. Dále uvedené způsoby hodnocení jsou převzaty z [15]. 20 3.7.1 Typy hodnotících metod Rozdělení metod podle použití: Vnitřní metody – hodnotí souhrn na základě kvality jednotlivých vět Vnější metody – ohodnocují souhrn jako celek a posuzují, jak je souhrn kvalitní pro použití v nějaké další úloze (např. k vyhledávání) Metody dělíme také podle způsobu činnosti: manuální – výsledné souhrny jsou ohodnoceny a porovnány člověkem, který se sumarizací zabývá. Tento způsob je asi nejspolehlivější, ale bohužel velmi časově náročný a nepraktický. semi-automatické (polo-automatické) – některé části textu je potřeba anotovat manuálně. Zbytek práce je ale automatický, což ušetří hodně času. automatické – celé ohodnocení a porovnání je vykonáno automaticky 3.7.2 Co je třeba hodnotit lingvistická kvalita – tj. jazyková správnost tvořená kvůli složitosti manuálně anotátory. Dále se dělí na: o gramatická správnost – hodnotí se kvalita věty, zdali neobsahuje například nějaké výčty, chyby apod. o redundance – věty ve výsledku by neměly pojednávat stále o té samé skutečnosti, ale měly by informovat o stále nových záležitostech nebo je nějakým způsobem upřesňovat o srozumitelnost – často se vyskytuje jev zvaný reference clarity, což jsou zájmena, která mají souvislost s kontextem věty předchozí. Pokud však do souhrnu zahrneme pouze tuto větu s odkazujícím zájmenem, pak nevíme, co toto zájmeno zastupuje. o struktura a souvislost – shrnutý text by měl na sebe určitým způsobem navazovat a být nějak utříděn do odstavců, případně i nadpisů apod. Nelze popisovat hrušky a v další větě jablka... 21 obsahová kvalita o když anotátor vytvoří extrakt - porovnáváme automatický extrakt a extrakt od anotátora například metodou přesnosti a úplnosti (co mají extrakty společného, jak spolu souvisí atd.). Při manuální tvorbě extraktu a následném porovnání se setkáváme s problémem uvedeným v předchozím příkladě v kapitole 3.7. Pokud by jsme se chtěli tomuto problému vyhnout, je nutné použít jinou metodu, kde je ovšem potřeba anotovat všechny věty v původním dokumentu, nejen některé z nich. o když anotátor vytvoří abstrakt - častější způsob, kdy se porovnává mezi manuálně vytvořeným abstraktem a automatickým extraktem či abstraktem. Tímto se zabývají techniky typu ROUGE [16], který je plně automatický, nebo semi-automatická technika pyramidy. Systémem typu ROUGE se budeme zabývat dále. 3.8 ROUGE (Recall-Oriented Understudy for Gisting Evaluation) V předchozí kapitole jsme se zmínili o porovnávacím systému ROUGE, který potřebuje ke své práci automatický souhrn a souhrn vytvořený anotátorem (pozn.: k jednomu automatickému souhrnu může existovat i více manuálních souhrnů kvůli lepší kvalitě porovnání). Tento systém se používal i na konferencích DUC 2004 a 2005, o kterých jsme se zmínili ke konci kapitoly 3.2. Ponechme nyní stranou, kde vzít abstrakty k porovnání a vysvětleme si, co je ROUGE. 3.8.1 Definice dle [16] „Jde o běžnou, pohodlnou a opakovatelnou metodu hodnocení, kterou lze snadno aplikovat na systém podporu rozvoje a just-in-time (“právě včas“) porovnání mezi různými způsoby sumarizace.“ 22 3.8.2 Způsoby hodnocení Systém ROUGE měří překrývající se jednotky jako jsou n-gramy (tj. sled n po sobě jdoucích položek z dané posloupnosti [17]). Porovnávají se například sekvence slov či dvojice slov (bigramy) mezi automatickým souhrnem a souhrnem tvořeným manuálně. Porovnávacích způsobů existuje hned několik. Jmenujme například: ROUGE-N, ROUGE-L, ROUGE-W a ROUGE-S. ROUGE-N – počítá výskyty n-gramů mezi souhrny dle vzorce [18]: , kde n znamená délku ngramu (gramn), a Countmatch(gramn) je maximální počet n-gramů shodných v automatickém souhrnu (kandidát na ideální souhrn) a v referenčním manuálním souhrnu. V případě, že n=1, jde o maximální počet výskytů každého slova z automatického souhrnu v referenčním souhrnu děleno počtu všech slov v referenčním souhrnu. Ze vzorce je vidět, že počet n-gramů se zvyšuje, pokud přidáváme více referenčních souhrnů. Výsledkem je, že sumář je tím kvalitnější, čím víc obsahuje společných slov v co největším počtu referenčních souhrnů. o ROUGE-Nmulti – v případě, že máme k dispozici více referenčních souhrnů, spočítáme ROUGE-N pro všechny páry automatického souhrnu S a referenčního souhrnu ri z množiny referenčních souhrnů. Poté vezmeme maximum z těchto vypočítaných dvojic jako finální hodnotu: Tento vzorec je aplikovatelný také pro ROUGE-L, ROUGE-W a ROUGE-S. ROUGE-L – definice dle [18]: Sekvence Z=[z1, z2, …, zn] je podřetězcem jiné sekvence X=[x1, x2, …, xm], jestliže existuje striktně se zvyšující sekvence [i1, i2, …, ik] taková, že pro všechny j=1, 2, ..., k platí xij = zj. 23 Pokud tedy máme dvě sekvence X a Y, tak nejdelší společná subsekvence (dále LCS, neboli Longest Common Subsequence) X a Y je společná subsekvence o maximální délce. Pro sumarizační účel je doporučeno použít LCS založenou na F-měření, kterým se ale nebudeme z důvodu složitosti zabývat. ROUGE-W – vážená nejdelší společná subsekvence (Weighted LCS). LCS má mnoho dobrých vlastností, ale bohužel neumí rozlišit LCS, které jsou různě prostorově rozloženy. Viz příklad: o Příklad: Mějme referenční souhrn X a dva kandidáty Y1 a Y2 na ideální souhrn: X= [A B C D E F G], Y1= [A B C D H I K], Y2= [A H B K C I D]. Přestože je Y1 jasným favoritem na ideální souhrn, mají Y1 a Y2 stejné skóre ROUGE-L. Z tohoto důvodu vzniklo ROUGE-W, které si navíc pamatuje délku po sobě jdoucích výskytů. ROUGE-S – Skip-Bigram ROUGE, což je dvojice slov ve správném pořadí ve větě, která může být nahodile přerušena. Více viz příklad. o Příklad: S1: police killed the gunman S2: police kill the gunman S3: the gunman kill police S4: the gunman police killed Každá věta má 6 bigramů (vypočteno jako C(4, 2) = 4! / (2!*2!) = 6). Věta S1 má tyto bigramy: (“police killed“, “police the“, “police gunman“, “killed the“, “killed gunman“, “the gunman“). U dalších vět se počítají pouze bigramy shodné s větou S1. Protože mohou vzniknout nic neříkající bigramy typu “the the“ nebo “of in“, je možné zavést maximální skokovou vzdálenost dskip, která omezuje počet slov mezi jednotlivými bigramy. o ROUGE-SU – U ROUGE-S se vyskytuje problém, kdy neexistuje způsob, jak ohodnotit větu, která by mohla být zvolena do 24 souhrnu, pokud se v ní nevyskytuje žádná slovní dvojice shodná s referenčním souhrnem  Příklad: S1: police killed the gunman S5: gunman the killed police Skóre věty S5 pro ROUGE-S je v tomto případě nula, protože S5 je převrácená věta S1. Protože bychom ale rádi rozlišili věty podobné větě S5 od věty, která nemá žádný shodný skip-bigram s větou S1, bylo zavedeno ohodnocování ROUGE-SU (skip unigram), které počítá navíc i shodné výskyty jednotlivých slov, podobně jako u ROUGE-N. Jaká z těchto metod byla nakonec vybrána k našemu porovnávání uvádíme v kapitole 5.1.1. 25 KAPITOLA 4 Architektura 4.1 Návrh V této kapitole bychom rádi nastínili strukturu našeho programu. Jde o aplikaci vytvořenou na podkladu Talking head (TH), která je typu klient-server. Definice [19]: „Klient-server je síťová architektura, která odděluje klienta (často aplikaci s grafickým uživatelským rozhraním) a server, kteří spolu komunikují přes počítačovou síť. Alternativou architektury klientserver je peer-to-peer (klient-klient).“ V našem případě se jedná o server s grafickým uživatelským rozhraním (zkráceně GUI neboli Graphical User Interface). Server je naprogramovaný v jazyce C++ s použitím několika knihoven. Z tohoto důvodu je platformově závislý a běží pouze pod operačním systémem Windows. Jelikož serverová část byla již naprogramována a její zdrojové kódy jsme ani neměli k dispozici, zabývali jsme se pouze klientskou částí, která je psaná v jazyce Java a tudíž je nezávislá na platformě. Neobsahuje žádné grafické rozhraní, protože je již přítomné v serverové části. Klient stahuje zpravodajský článek, vykonává sumarizační práci a posílá příkazy po síti TH. Definuje také, které png obrázky budou na serveru zobrazeny, případně jakým typem písma bude text zobrazen. Dané obrázky nebo soubory s písmem musí být přítomny na počítači, kde je umístěna serverová část. Základem aplikace v klientské části je datová struktura typu fronta, která přijímá události od serveru. Kdykoliv uživatel klikne myší do plochy TH, pošle se událost klientovi, který ji uloží do fronty ke zpracování. Podle typu události a místě kliknutí se pak spustí obslužná metoda. Je potřeba také navrhnout grafické rozložení prvků, které uživateli zpříjemňují práci s programem a definují klikatelné části aplikace. Co se týče sumarizace, je nutné otestovat alespoň tři volně dostupné metody a vybrat tu nejlepší možnou. Je také nutné navrhnout způsob, jak získat čistý obsah webové stránky určený k sumarizaci a poté k prezentaci pomocí TH. 26 4.2 UML UML (Unified Modeling Language) je grafický jazyk určený k navrhování a dokumentaci programových systémů [20]. My si navrhneme diagram nasazení, který zobrazuje rozmístění zdrojů a jednotlivé softwarové komponenty. Nejdříve ale nakreslíme Use Case diagram (diagram případu užití), který nám definuje chování celého systému z hlediska uživatele. 4.2.1 Use Case diagram Obrázek 2 – Use Case diagram Z obrázku je vidět, že uživatel může zobrazit nápovědu v případě, že by nevěděl, jak se s aplikací zachází. Dále může vybrat článek z RSS serveru, který má TH slovně prezentovat a může také nastavit různé parametry v konfiguračním souboru jako je druh písma a jeho velikost a zejména počet vět, do kterých chce shrnout prezentovaný článek. 27 4.2.2 Diagram nasazení Obrázek 3 – Diagram nasazení Obrázek zobrazuje klientské PC (Personal Computer) s běžícím virtuálním strojem JVM (Java Virtual Machine), který překládá javový byte-code ze souboru talkingHead.jar obsahujícím sumarizační algoritmy, metody na obsluhu událostí a uložené RSS zdroje ve formě souboru. JVM komunikuje po síti se serverovým PC, kde běží TH s uživatelským grafickým rozhraním. 29 KAPITOLA 5 Implementace 5.1 Sumarizační algoritmy V následujících podkapitolách budeme porovnávat sumarizátor pomocí technologie Lucene [21], Open Text Summarizer (OTS) [22] a Classifier4J (C4J) [23] a pro zajímavost i komerční Copernic Summarizer [24] (free edice pouze na 30dní). 5.1.1 Jak porovnávat V kapitole 3.8.2 jsme se zmínili o porovnávacím systému ROUGE, který potřebuje ke své práci automatický souhrn a jeden či více souhrnů vytvořených anotátorem. Protože systém ROUGE obsahuje několik metod na porovnání souhrnů, museli jsme vybrat některý z nich, který bude pro naše účely nejvhodnější. Naštěstí se tím již nemusíme zabývat, jelikož to vyřešili jiní. V měření dle [18] se zjišťovalo, jak spolehlivé jsou výsledky ze systému ROUGE. Více prozrazuje obrázek s Pearsonovu korelací (tj. vzájemným vztahem) mezi skóre vypočítané pomocí ROUGE a mezi manuálním ohodnocením sumarizovaného souhrnu. Označení ROUGE-R1 až R9 je označení pro ROUGE-N pro dané n. Číselné hodnoty uvedené za ROUGE-S nebo SU určují maximální možnou vzdálenost mezi dvojicí slov (hvězdička značí jedničkovou vzdálenost) a hodnota 1.2 uvedená za ROUGE-W označuje standardní váhu používanou při výpočtu. Ve sloupcích jsou označeny data z DUC konference a to z roku 2001 a 2002, kdy se hodnotily dokumenty dlouhé 100 slov s použitím jednoho a tří (v roce 2002 pouze dvou) referenčních souhrnů. Zeleně označené položky jsou nejlepší dosažené a šedé položky jsou statisticky ekvivalentní k těmto nejlepším výsledkům. Sloupec CASE značí výsledky, kdy se měření provádělo nad nezměněným originálním a manuálním souhrnem. Ve sloupci STEM jsou hodnoty, kdy byly slova z porovnávacích souhrnů ořezány tak, aby zbyly pouze jejich základní tvary. Teprve poté se hledají jejich výskyty (např.: “motorkářský“ a “motorový“ mohou být počítány jako dvojí výskyt jednoho slova). Ve třetím STOP podsloupci jsou navíc ze 30 souhrnů vyřazená i nevýznamná stop-words jako jsou předložky, spojky atd. Většinou tím dojde i ke zrychlení práce algoritmu. Tabulka 1 – Pearsonova korelace u DUC 2001 a 2002 Na dalším obrázku jsou porovnávána data z konference z roku 2003, ale už pouze desetislovná. Tabulka 2 – Pearsonova korelace u DUC 2003 V našem případě budeme mít pouze jeden referenční souhrn (více viz další podkapitola), kdy použijeme stem filter, který dává dle tabulek o malinko lepší 31 výsledky. Porovnání provedeme dle ROUGE-SU4 a můžeme si pro zajímavost uvést například i hodnoty pro ROUGE-W-1.2. 5.1.2 Jak získat souhrny Protože jsme nezískali data a jejich manuální abstrakty z konferencí DUC, uchýlili jsme se k jinému kroku. Našli jsme linuxový program “Text-CorpusSummaries-Wikipedia-0.21“ [25], který vytvoří korpusy pro sumarizační testování z článků anglické Wikipedie. Některé tyto články totiž mají přesně definovanou strukturu, kde v úvodu vlastně shrnují obsah celého textu. Jedná se tedy o abstrakt k single dokumentu. Jako výstup programu dostaneme “manuální“ abstrakt plus celý článek v textovém souboru, který následně použijeme na otestování sumarizátoru. Ke stažení těchto dvojic článků stačí nainstalovat program a přídavné knihovny a spustit v příslušném adresáři příkaz: create_summary_corpus.pl [-d corpusDirectory –l languageCode –p maxProcesses –h –t n] kde corpusDirectory je adresář, kam se uloží korpusy; languageCode je jazyk stahovaných článků; maxProcesses je počet procesů, ve kterých bude probíhat složitý výpočet; -h vytiskne nápovědu a –t n určí, kolik článků se stáhne. Pokud hodnotu n neuvedeme, stáhnou se všechny články (pozn.: cca po 4 hodinách jsme stáhli se 4 procesy na 350 anglických článků a program stále běžel). Automatické souhrny jsme získali pomocí několika programů: OTS o v repozitáři operačního systému Ubuntu jsme stáhli knihovnu libots, s jejíž pomocí získáme 20% souhrn spuštěním následujícího příkazu: ots "vstupni_dokument" -o "vystupni_souhrn" --ratio=20 Mohli bychom použít také parametr –dic jmeno_souboru, který říká, že chceme zvolit náš slovník používaný k vyhledávání četností slov. Tím vlastně také určujeme, v jakém jazyce je sumarizovaný článek. My jsme ale spoléhali na standardně přiložený OTS slovník. 32 C4J o stáhneme jej jako knihovnu [26] a poté spustíme pomocí následujícího java kódu, ve kterém vytvoříme objekt typu SimpleSummarizer a zavoláme jeho třídní metodu summarise() spolu se vstupním dokumentem a počtem vět, které chceme ve výstupním souhrnu. Ten je uložen do Stringu pojmenovaném jako summary. ISummariser summarizer = new SimpleSummariser(); String summary = summarizer.summarise(text, POCET_VET); LUCENE alg. o Správně bychom neměli pojmenovávat tento algoritmus jako Lucene, jelikož sumarizátor se tak nejmenuje. Ve skutečnosti jde o sumarizátor založený na Lucene algoritmu [27], což je vyhledávací engine. Pro jednoduchost však budeme i nadále používat toto pojmenování. Samotný sumarizátor a jeho úpravy provedl pan Sujit Pal [28], který jej uveřejnil na svém blogu. Samotný sourhn získáme podobně jako v případě C4J. Více viz pseudo-algoritmy. Copernic Summarizator o Pro zajímavost jsme uvedli i skóre, kterého dosáhl tento komerční sumarizátor [29] volně dostupný pouze na 30 dní. 5.1.3 Výsledky Porovnání jsme spustili skriptem runROUGE-diplomka.pl : perl ROUGE-1.5.5.pl -e ./data -2 4 -u -c 95 -m -r 1000 -w 1.2 -x ./xml/ROUGE-diplomka_01.xml 01 > ./ROUGE-diplomka-c95-m-r1000-w1.2LUCENE.out"; kde jednotlivé argumenty představují: e adresar – pokud nemáme nastavenou proměnnou prostředí, specifikujeme tímto adresář s daty (např. umístění slovníku WordNet [30], který se používá při vyhledávání četností slov apod.) 2 4 – je aplikována metoda skip bigram ROUGE-S s hodnotou 4 u – bude se počítat také s unigramy, čili jde o ROUGE-SU4 33 c 95 – použije se standardní interval spolehlivosti 95% m –aplikuje PorterStemmerFilter, který ponechává v souhrnech pouze základní tvary slov r 1000 – určuje tzv. bootstrap vzorkování. Čím menší je číslo, tím je výpočet rychlejší, ale s méně spolehlivým intervalem spolehlivosti. Hodnota 1000 je brána jako standardní. w 1.2 – bude proveden výpočet s ROUGE-W s implicitním váhovým faktorem 1.2 x – výstup nebude zahrnovat skóre z ROUGE-L, které se počítá automaticky jako podúloha k ostatním způsobům ohodnocování “soubor.xml id_number > soubor“ – určuje vstupní soubor, ve kterém jsou uvedeny cesty k souhrnům s jejich id označením. Vypočtené hodnoty jsou poté přesměrovány ze standardního výstupu do souboru. Stažený manuální abstrakt z Wikipedie může mít odlišný počet vět, než automatický souhrn. Potíž je ale v počtu vět, které jsou výsledkem těchto automatických sumarizátorů. Zatímco Lucene požaduje jako parametr počet vět, algoritmus OTS má tento parametr v procentech. Z tohoto důvodu jsme museli spustit nejdříve algoritmus OTS se standardním 20% výstupem, poté jsme spočítali počet vygenerovaných vět pro každý článek a spustili další algoritmy s tímto počtem, jinak by nebyly výsledky vypovídající. Nejlepší hodnotící metodou jsme zvolili ROUGE-SU4 se stem filtrem na základě tabulky z kapitoly 5.1.1. Dále je uvedena i metoda ROUGE-W s váhovým faktorem 1.2. Je nutno poznamenat, že články stahované z anglické Wikipedie jsou o něco delší než z konferencí DUC a z časových důvodů také není možné potvrdit kvalitu těchto článků, jejich gramatickou správnost a hlavně úvodní abstrakt, který je brán jako souhrn k porovnání. Spoléháme proto na informace dodané k programu TextCorpus-Summaries-Wikipedia-0.21, který toto uvádí. Naším cílem je tak pouze porovnat čtyři sumarizátory. Následující tabulky obsahují výsledky pro 50 vybraných článků (article). Pro každý článek je uvedeno skóre ze všech sumarizátorů, které jsou označeny 34 v závorkách číslem. Ve sloupci MAX je pak některé z těchto čísel označující sumarizátor s nejlepším skóre, v dolní části tabulky vidíme dosažené průměrné skóre a počet nejlepších dosažených výsledků pro každý algoritmus zvlášť (řádek Average a Sum Best). Uvádíme také celkový počet vět článku a počet vět ve výsledném souhrnu (všechny sumarizační algoritmy jej mají stejný). Počet vět je z časových důvodů počítán automaticky pomocí sentence (větného) tokenizátoru, který, jak jsme zjistili, není bezchybný. Pokud jsou například věty oddělené prázdnými řádky, počítají se jako věta, což bylo nutné opravit. Bylo by možné se také zamyslet nad tím, jestli by nebylo vhodnější místo počtu vět omezit výstupní souhrn na počet slov, jelikož počet vět nám definitivně neurčuje délku souhrnu (věty jsou různě dlouhé). Z našeho subjektivního pohledu dával zejména sumarizátor Copernic delší souhrny. Protože počet prvních umístění (Sum best) by nebyl jako porovnávací parametr dostačující, umístili jsme do tabulky ještě odchylku Lucene skóre od průměrné hodnoty všech algoritmů pro daný článek. Uvedené skóre je typu Average Recall Score (průměrné “vzpomínací“ skóre). Systém ROUGE poskytuje ještě další dvě hodnotící skóre (Precision (přesnost) a F-measure (F-měření)), ale kvůli zpětné kompatibilitě se staršími hodnotami z konferencí DUC zůstáváme věrni hodnotě Recall. Zbylé dvě hodnocení jsou užitečné, pokud nepožadujeme na výstupu předem definovanou délku, proto je Recall pro nás vhodnější, jelikož my daný počet vět chceme. 35 Tabulka 3 – ROUGE-SU4 (Average Recall Score) Article C4J (1) OTS (2) LUCENE (3) Copernic Sentence MAX (4) in article Sentence in summary Average number Difference Lucene score from average 1 0,22929 0,28857 0,30714 0,24143 3 121 20 0,2666075 0,0405325 2 0,22128 0,30743 0,34628 0,29307 3 112 18 0,292015 0,054265 3 0,28061 0,28599 0,28991 0,26983 3 115 21 0,281585 0,008325 4 0,20092 0,24711 0,21132 0,25173 4 44 7 0,22777 -0,01645 5 0,25846 0,26769 0,31385 0,30462 3 111 20 0,286155 0,027695 6 0,14179 0,18433 0,24403 0,19776 3 195 21 0,1919775 0,0520525 7 0,21596 0,26064 0,23777 0,22394 2 95 14 0,2345775 0,0031925 8 0,23922 0,28639 0,30458 0,24596 3 115 20 0,2690375 0,0355425 9 0,13667 0,16299 0,18251 0,18506 4 112 21 0,1668075 0,0157025 10 0,26589 0,26059 0,2553 0,28072 4 113 21 0,265625 11 0,20943 0,29473 0,26976 0,28155 2 134 21 0,2638675 0,0058925 12 0,21041 0,2434 0,29179 0,2632 3 78 13 0,2522 13 0,28 0,2725 0,26 0,21125 1 157 21 0,2559375 0,0040625 14 0,21406 0,24313 0,25159 0,33245 4 103 13 0,2603075 -0,0087175 15 0,25755 0,26192 0,26391 0,23768 3 145 21 0,255265 0,008645 16 0,23948 0,30122 0,29794 0,2928 2 94 18 0,28286 0,01508 17 0,23145 0,27893 0,31899 0,32493 4 84 12 0,288575 0,030415 18 0,23122 0,30781 0,29823 0,27172 2 108 18 0,277245 0,020985 19 0,3 0,30366 0,32356 0,30209 3 112 20 0,3073275 0,0162325 20 0,1689 0,11839 0,20718 0,1985 3 304 21 0,1732425 0,0339375 21 0,30941 0,35644 0,31188 0,31188 2 90 13 0,3224025 -0,0105225 22 0,18733 0,22841 0,27019 0,24025 3 111 17 0,231545 0,038645 23 0,138 0,18053 0,19282 0,13611 3 68 10 0,161865 0,030955 24 0,24185 0,23965 0,26167 0,15859 3 469 21 0,22544 0,03623 25 0,36753 0,42629 0,45618 0,41335 3 117 21 0,4158375 0,0403425 26 0,2396 0,2443 0,24362 0,23557 2 84 11 0,2407725 0,0028475 27 0,24694 0,28634 0,2697 0,25832 2 125 17 0,265325 28 0,18088 0,24942 0,303 0,21141 3 138 21 0,2361775 0,0668225 29 0,2248 0,236 0,2904 0,2096 3 167 21 0,2402 0,0502 30 0,23417 0,21267 0,2631 0,25958 3 167 21 0,24238 0,02072 31 0,23211 0,2176 0,32785 0,24371 3 64 10 0,2553175 0,0725325 32 0,13849 0,25989 0,28237 0,22662 3 130 20 0,2268425 0,0555275 33 0,16767 0,24219 0,25781 0,16827 3 80 13 0,208985 34 0,2626 0,23674 0,26525 0,25332 3 166 21 0,2544775 0,0107725 35 0,23423 0,2065 0,26004 0,25526 3 119 17 0,2390075 0,0210325 36 0,24688 0,24493 0,32956 0,27262 3 146 21 0,2734975 0,0560625 37 0,24105 0,23508 0,24344 0,20764 3 339 21 0,2318025 0,0116375 38 0,21675 0,21523 0,2599 0,25838 3 135 21 0,237565 0,022335 39 0,25076 0,31307 0,35866 0,21353 3 176 21 0,284005 0,074655 40 0,15793 0,2289 0,23529 0,16688 3 211 21 0,19725 0,03804 41 0,31947 0,29356 0,35008 0,32104 3 95 18 0,3210375 0,0290425 42 0,21039 0,20187 0,25213 0,22743 3 259 21 0,222955 0,029175 43 0,18971 0,24863 0,31383 0,27337 3 109 17 0,256385 0,057445 44 0,21986 0,28082 0,28151 0,21507 3 139 21 0,249315 0,032195 45 0,28233 0,30047 0,30442 0,29338 3 129 21 0,29515 0,00927 46 0,21654 0,3161 0,32699 0,25299 3 121 20 0,278155 0,048835 47 0,20495 0,19965 0,20009 0,19125 1 312 21 0,198985 0,001105 48 0,23388 0,26245 0,33429 0,23102 3 206 21 0,26541 0,06888 49 0,15835 0,19111 0,2305 0,15484 3 412 21 0,1837 0,0468 50 0,2578 0,30758 0,3425 0,26969 3 141 21 0,2943925 0,0481075 - 149,54 18,44 Average 0,226897 0,2567968 0,2818942 0,2468252 Sum best 2 7 36 5 0,2531033 -0,010325 0,03959 0,004375 0,048825 0,0287909 36 Tabulka 4 – ROUGE-W-1.2 (Average Recall Score) Article 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 C4J (1) 0,13812 0,15278 0,14388 0,13439 0,1884 0,0996 0,13821 0,14877 0,10129 0,16855 0,15306 0,13282 0,19962 0,11766 0,14539 0,1338 0,15334 0,14642 0,15118 0,10503 0,21569 0,14144 0,10535 0,13891 0,1962 0,12343 0,14804 0,12806 0,14901 0,12659 0,12745 0,11453 0,12227 0,12792 0,14901 0,13174 0,13571 0,12651 0,1529 0,09945 0,16775 0,12459 0,10191 0,12298 0,17813 0,1262 0,12198 0,13243 0,10812 0,1566 OTS (2) 0,15605 0,16849 0,14839 0,15543 0,18322 0,11731 0,14519 0,15025 0,12282 0,15663 0,18077 0,1498 0,19477 0,13353 0,15235 0,14463 0,18726 0,17464 0,14647 0,08911 0,22438 0,1458 0,14321 0,13175 0,21625 0,12471 0,15772 0,14497 0,15768 0,11383 0,11937 0,18449 0,13313 0,12429 0,13454 0,12547 0,13388 0,13106 0,16484 0,13021 0,16443 0,12145 0,1265 0,14752 0,17623 0,15508 0,11551 0,14283 0,12602 0,16662 LUCENE (3) 0,16553 0,17731 0,14605 0,16141 0,21551 0,14398 0,14035 0,16343 0,13097 0,17256 0,18086 0,17224 0,19135 0,14399 0,16042 0,14813 0,20718 0,1715 0,15459 0,12438 0,20602 0,16333 0,1473 0,14101 0,24359 0,12352 0,16018 0,16275 0,16799 0,13032 0,15674 0,19717 0,14873 0,13057 0,14858 0,14941 0,14111 0,13451 0,18493 0,13781 0,17483 0,14052 0,15218 0,14844 0,17196 0,16358 0,12259 0,17513 0,14382 0,20175 Copernic Sentence MAX (4) in article 0,13617 0,16494 0,14552 0,16632 0,21675 0,12751 0,1366 0,14723 0,12716 0,17546 0,18365 0,15639 0,16248 0,1722 0,14095 0,14779 0,21433 0,17142 0,16201 0,11865 0,20081 0,15904 0,11583 0,09653 0,22036 0,12828 0,1552 0,14007 0,14595 0,14079 0,14477 0,15907 0,11123 0,13886 0,15249 0,14173 0,12786 0,14218 0,13333 0,10808 0,17294 0,13439 0,13966 0,12019 0,17747 0,13606 0,11853 0,12917 0,10989 0,15535 Average 0,1390642 0,1488176 0,1608422 0,1485928 Sum best 2 4 32 12 Sentence in summary Average number 3 3 2 4 4 3 2 3 3 4 4 3 1 4 3 3 4 2 4 3 2 3 3 3 3 4 3 3 3 4 3 3 3 4 4 3 3 4 3 3 3 3 3 3 1 3 3 3 3 3 121 112 115 44 111 195 95 115 112 113 134 78 157 103 145 94 84 108 112 304 90 111 68 469 117 84 125 138 167 167 64 130 80 166 119 146 339 135 176 211 95 259 109 139 129 121 312 206 412 141 20 18 21 7 20 21 14 20 21 21 21 13 21 13 21 18 12 18 20 21 13 17 10 21 21 11 17 21 21 21 10 20 13 21 17 21 21 21 21 21 18 21 17 21 21 20 21 21 21 21 0,1489675 0,16588 0,14596 0,1543875 0,20097 0,1221 0,1400875 0,15242 0,12056 0,1683 0,174585 0,1528125 0,187055 0,141845 0,1497775 0,1435875 0,1905275 0,165995 0,1535625 0,1092925 0,211725 0,1524025 0,1279225 0,12705 0,2191 0,124985 0,155285 0,1439625 0,1551575 0,1278825 0,1370825 0,163815 0,12884 0,13041 0,146155 0,1370875 0,13464 0,133565 0,159 0,1188875 0,1699875 0,1302375 0,1300625 0,1347825 0,1759475 0,14523 0,1196525 0,14489 0,1219625 0,17008 - 149,54 18,44 0,1493292 Difference Lucene score from average 0,0165625 0,01143 0,00009 0,0070225 0,01454 0,02188 0,0002625 0,01101 0,01041 0,00426 0,006275 0,0194275 0,004295 0,002145 0,0106425 0,0045425 0,0166525 0,005505 0,0010275 0,0150875 -0,005705 0,0109275 0,0193775 0,01396 0,02449 -0,001465 0,004895 0,0187875 0,0128325 0,0024375 0,0196575 0,033355 0,01989 0,00016 0,002425 0,0123225 0,00647 0,000945 0,02593 0,0189225 0,0048425 0,0102825 0,0221175 0,0136575 -0,0039875 0,01835 0,0029375 0,03024 0,0218575 0,03167 0,011513 37 ROUGE-SU4 (Average Recall Score) 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 C4J OTS LUCENE Copernic article 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0,05 0,1 0,15 0,2 0,25 0,3 0,35 score Obrázek 4 – ROUGE-SU4 0,4 0,45 0,5 38 ROUGE-W (Average Recall Score) 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 article 27 C4J OTS LUCENE Copernic 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0,05 0,1 0,15 score 0,2 Obrázek 5 – ROUGE-W-1.2 0,25 0,3 39 article Difference Lucene ROUGE-SU4 score from average score 49 47 45 43 41 39 37 35 33 31 29 27 25 23 21 19 17 15 13 11 9 7 5 3 1 -0,04 -0,02 0 0,02 0,04 0,06 0,08 0,1 score Obrázek 6 – Odchylky Lucene od průměrné hodnoty ROUGE-SU4 article Difference Lucene ROUGE-W-1.2 score from average score 49 47 45 43 41 39 37 35 33 31 29 27 25 23 21 19 17 15 13 11 9 7 5 3 1 -0,01 -0,005 0 0,005 0,01 0,015 0,02 0,025 0,03 0,035 score Obrázek 7 - Odchylky Lucene od průměrné hodnoty ROUGE-W-1.2 0,04 40 Z naměřených údajů vyplývá, že nejlepšího ROUGE-SU4 skóre jednoznačně dosáhl algoritmus Lucene (počet výher 36 z 50), který byl vítězem i v případě ROUGE-W (32 výher z 50). Pouze v několika málo případech byl horší, než je průměrné skóre všech sumarizátorů pro jednotlivé články (tj. záporné hodnoty odchylek). Pokud ale porovnáme průměrné skóre ze všech článků, zjistíme, že se tak moc neliší. Proto jakýkoliv malý zásah do kódu algoritmu má velký vliv na výsledky. Následující tabulka ukazuje vliv parametrů algoritmu Lucene na průměrné ROUGE-SU4 skóre. My jsme v předchozích tabulkách použili nejlepší nastavení, což byly hodnoty sentenceDeboostBase=0.8, topTermCutOff=0.1, sentenceDeboost=0.1 (více o těchto parametrech v kapitole 5.2.1). Pokud bychom ale použili nastavení 0.5, 0.5, 0.2, což byly přednastavené hodnoty autora algoritmu Sujit Pala, dosáhl by Lucene pouze 18 výher v případě ROUGE-SU4 a pouze 10 výher v případě ROUGE-W-1.2. Tabulka 5 – Vliv parametrů Lucene na jeho průměrné ROUGE-SU4 skóre sentenceDeboostBase topTermCutOff sentenceDeboost Average ROUGE-SU4 score 0.5 0.1 0.2 0.2814474 0.5 0.1 0.4 0.2798304 0.5 0.1 0.8 0.2811776 0.5 0.1 0.0 0.2790798 0.5 0.5 0.2 0.2568252 0.5 0.2 0.2 0.265679 0.5 0.0 0.2 0.280704 0.8 0.1 0.8 0.281067 0.8 0.1 0.4 0.28106 0.8 0.1 0.1 0.281894 0.8 0.1 0.0 0.2790798 0.8 0.1 0.2 0.28106 0.8 0.02 0.1 0.281221 Je také zřejmé, že ačkoliv sumarizátor Copernic měl většinou souhrny s delšími větami, nemusí to znamenat nutně přínos. 41 Pro náš projekt s mluvící hlavou jsme se tedy rozhodli použít sumarizátor Lucene s co nejlepšími parametry, protože vykazoval dobré výsledky a byl napsán jako volně šiřitelný program v javě, což bylo pro naše případy také klíčové. 5.2 Algoritmus Lucene Algoritmus má následující vlastnosti: single-document jazykově závislý (angličtina) tvoří souhrny typu extrakt heuristická metoda text-driven vstup general aspect (nemáme k dispozici doménu článku) jednotkou pro výpočty jsou slova (články nejsou moc dlouhé) informativní souhrn délka souhrnu dána počtem vět 5.2.1 Používané praktiky Hlavní myšlenky algoritmu dvě, a to použítí vyhledávacího algoritmu Lucene k nalezení a vyřazení stop-words díky StopFilteru a upravení všech slov do základního tvaru pomocí PorterStemmerFilteru, které jsou po mezivýpočtech ukládány pomocí metody docFreq() ze třídy IndexReader do mapové struktury. Z těchto důvodů je algoritmus jazykově závislý na anglickém jazyce. Po aplikování těchto dvou filtrů se článek musí rozdělit na jednotlivé odstavce a ty pak na věty pomocí paragraph a sentence tokenizátoru. Teprve poté je spočtena četnost všech zbývajících slov. Do další fáze výpočtu se vezmou jen ty nejčastější (parametr topTermCutOff). Objekt BooleanQuery poté najde věty, ve kterých jsou nejčastější slova obsaženy a zvýhodní je podle jejich umístění v dokumentu. Jako souhrn se vezme daný počet vět, které jsou nejvýše hodnocené. V kódu se používá několik pomocných hodnot: topTermCutOff – jde o hodnotu v intervalu (0, 1), která rozhoduje, jestli budou brány v potaz všechny termy a jejich četnosti. Pokud je 42 četnost termu vyšší než (topTermCutOff * nejvyššíČetnostZeVšechSlov), účastní se dalších výpočtů. V našem případě hodnota topTermCutOff =0.1. sentenceDeboost – taktéž hodnota od 0 do 1. Je aplikována od druhé věty ve druhém odstavci a dále. Těmto větám je sníženo hodnocení, jelikož mají menší význam než celý první odstavec a první věty v odstavcích následujících. Hodnocení je počítáno jako: (1-pozice_věty*sentenceDeboost). Pokud je výsledná hodnota menší než sentenceDeboostBase, není již hodnocení věty dále snižováno a je nastaveno na tuto hodnotu. Hodnota sentenceDeboost je nastavena na 0.1, sentenceDeboostBase je rovno 0.8. 5.2.2 Pseudo-algoritmus Input: vstupní dokument Output: daný počet vět obsahujících nejvíce hodnocené termy (slova) setAnalyzator( stop_words, porterStemmerFilter); for each paragraph { for each sentence { setDeboostOfSentence( sentenceDeboost, sentenceDeboostBase ); //snizi ohodnoceni vety podle jejiho umisteni v odstavci a v dokumentu useLuceneAnalyzator (sentence); //odstrani stop-words a pouzije stemmer } } countOccursOfWords (); //spocita vyskyty slov sortDescendingOccursOfWords (); //seradi slova od nejvyssi cetnosti k nejnizsi useTopTermCutOff(); //odrizne slova s nizkou cetnosti returnSummary(); //vrati vety v poradi, v jakem byly v dokumentu s co nejvyssim zastoupenim nejcastejsich slov 5.3 BoilerPipe [31] Jedná se o knihovnu napsanou Christianem Kohlschütterem, která poskytuje algoritmy k detekování “nepořádku“ (boilerplate textu [32]) kolem hlavního textu původně za účelem zrychlení načítání webových stránek, zpřesnění vyhledávání či získávání dat (tzv. data mining). Nepořádkem se rozumí navigační menu, vložené 43 obrázky, odkazy na jiné články či webové servery, různé reklamy apod. Ty jsou následně odstraněny a uživateli je navrácen text v potřebném formátu dle [33]: extract HTML – vrátí pouze “okleštěný“ text v HTML highligted HTML – zvýrazněný text v HTML stránce plain text – neformátovaný text, bez jakýchkoliv doplňujících značek JSON – hlavní kontext je vrácen v JSON (JavaScript Object Notation) formátu, který je určen pro výměnu dat mezi objekty Debug – slouží k výpisu doplňujících informací, které umožňují uživateli pochopit funkčnost algoritmu Pro naše potřeby je dostačující plain text, bez jakýchkoliv formátovacích tagů, i když by bylo možné se zamyslet nad použitím HTML formátu, který by sumarizačnímu algoritmu sdělil, co je nadpisem, kde začíná a končí odstavec dle použitých HTML tagů. BoilerPipe pracuje celkem uspokově, ale i tak pro potřeby uživatelů nabízí několik extrakčních metod [33]: ArticleExtractor – standardně použitý extraktor, který je nastaven přednostně pro novinové aktuality. V této oblasti je lepší, než DefaultExtractor. DefaultExtractor – velmi obecný extraktor, který není zaměřený na žádnou oblast. Díky této univerzálnosti je občas méně přesný, než ArticleExtractor LargestContentExtractor – podobný DefaultExtractoru, ale zaměřuje se pouze na nejdelší bloky textu. Je proto vhodný pouze pro články s jedním hlavním textovým blokem. KeepEverythingExtractor – všechny bloky článku považuje za obsah. Je užitečný pro SAX parsing errors (Simple Api for XML), což je alternativa k DOM (Document Object Model). Jde o mechanismy sloužící ke čtení dat z XML dokumentů. CanolaExtractor – extraktor trénovaný na datech z krdwrd Canola, které slouží jako vstup k podobným nástrojům typu BoilerPipe 44 Z našeho pohledu, kdy jsme vyzkoušeli všechny tyto metody na českých novinkách, jsme dospěli k názoru, že standardní ArticleExtractor, i když není úplně bez chyb, je nejlepší. U ostatních extraktorů byly do textu někdy zařazeny také odkazy na jiné články (jejich nadpisy a krátký začátek článku), datum poslední úpravy webové stránky, copyright práva apod. I v případě ArticleExtractoru se někdy stane, že plain text obsahuje i popisek k vloženému obrázku a jejího autora. Je však možné, že toto se nevyskytuje u anglických článků, se kterými byl BoilerPipe testován. Přesto je určen i pro různé jazykové verze. Následující vlastnosti jsou převzaty z [32]: BoilerPipe využívá tvrzení, že počítá četnost několika termů (HTML tagů) v HTML stránce, který označí jako boilerplate text, což je zřejmé, jelikož např. menu se objevuje na každé stránce stejné a je velmi často odkazované linkem A. Naopak nepoužívá template statictics (“učení se šablony webu“), protože není zaručena doménová nezávislost webového serveru, a protože by se tento template musel učit na každé stránce, což není realizovatelné. Také se vyhýbá složitému renderování stránky, jelikož je výpočetně náročné. BoilerPipe bere při výpočtu v úvahu také jen několik málo HTML tagů (H1, H2, H3, H4, H5, H6, P, DIV, A), jelikož se stále častějším použitím CSS (Cascading Style Sheets) stylů se jiné tagy používají velmi individuálně a není proto na ně spolehnutí. Naopak se snaží nahlížet na web pouze povrchně, neklasifikuje jednotlivá slova a díky tomu je jazykově a doménově nezávislý. Bere v úvahu i kvantitativní lingvistická hlediska, jako je průměrná délka věty, že bílé znaky jsou odděleny minimálně jedním písmenem nebo číslem a používá heuristiky, kdy u velmi segmentované stránky je full-text následovaný full-textem a šablona šablonou. Zejména hlavní text bývá ohraničen záhlavím, zápatím, levým či pravým navigačním menu apod. Důležitá je také textová hustota, kdy se počítá počet termů v částěčném textovém bloku dělený počtem zaplněných řádek mínus 1 (poslední řádek není většinou zaplněn celý), kde délka řádku je empiricky zvolena na cca 80 až 90 znaků, což je optimální hodnota pro anglické texty. BoilerPipe byl trénován a testován dle [32] na 621 manuálně hodnocených anglicky psaných novinových článcích z mnoha rozdílných oborů, které byly vybrány z velkého množství 254 000 článků sesbíraných ze 7 854 webových 45 stránek po více než půl rok. Články byly také z rozdílných anglicky mluvících zemí jako USA, Kanada, Indie, Jižní Afrika a Austrálie. Z tohoto důvodu si umíme vysvětlit, že pro české články není algoritmus stoprocentně úspěšný. I tak ale poskytuje velmi kvalitní výsledky. Pro naše účely je ale naprosto vyhovující, jelikož TH umí prezentovat články pouze v anglickém jazyce. 5.4 Talking Head (TH) Mluvící hlavy, neboli Talking heads, jsou většinou nasazovány jako doplňkový asistent k zákaznické službě na internetu nebo call centeru. Mohou sloužit také k výuce, vědecké simulaci, v komunikačních programech apod. Jejich výhodou je provoz 24 hodin 7 dní v týdnu, kdy například v call centrech až o 30% redukují čas vynaložený zaměstnanci [34]. Důležitost verbální a neverbální komunikace si každý z nás jistě dokáže představit. Mnohem lepší je text nejen číst, případně od někoho slyšet, ale také “vidět“. Mluvící hlava, kterou máme k dispozici, dokáže také napodobit lidskou mimiku a její mluvený projev už zdaleka nepřipomíná “plechového“ robota jako je tomu vidět ve vědecko-fantastických filmech. V běžných podmínkách českého uživatele však nemá naše TH veliké uplatnění, protože zvládá pouze anglický a italský mluvený projev. Česky mluvící uživatelé musí doufat pro budoucí nástavbu k této aplikaci. 5.4.1 Algoritmus TH Naše TH obsahuje anglický IBM ViaVoice TTS (Text-to-Speech) syntetizátor, což je nástroj, který rozloží vstupní text na skupiny fonémů, které se ve smyčce vyhodnocují a interpretují se jako příkaz hlavě pro zobrazení výrazu, představující vizém. Foném lze definovat jako základní jednotku zvukové stavby jazyka schopnou rozlišit význam [35]. Vizém je pak grafické znázornění mimiky obličeje, který tento foném vyslovuje. Fonémy jsou pro každý jazyk jiné, a proto není možné použít syntetizátor např. pro český jazyk. 46 5.4.2 Schopnosti TH Grafická reprezentace hlavy představuje v našem případě ženskou hlavu umožňující vykonávat veškeré běžné pohyby a jiné příkazy. Jmenujme ty nejdůležitější: “<act rel="nofollow">ELEMENT</ act>“, kde ELEMENT= o <gesture /> s atributy:  zoom; head_x; head_y; head_angle; eye_vert; eye_horiz; expr= {neutral, turn right, turn left, bend forward, band backward, tilt right, tilt left, smile, open mouth, anger, surprise, sadness, fear, disgust, left blink, right blink, close eyes, spock, rised_eyebrows, yes, quick yes, no, sceptical no, laugh, lookaround, fear lookaround, yawn, whistle, wahha, roll head, sleep, twitch, strict, disgust without mouth, wink}; idle= {WakeUp, LookAndSleep, LieDownAndSleep, OnlyFlyOut, FlyOut, FlyIn, RollingHead, RollingAndZoomingHead}; expr_scale; persistent; ref; pointer; pointer_x; pointer_y; move_time; text; pos_x; pos_y; scale; persistent o <overlay></overlay> s atributy:  ref; z-index; visible; pos_x; pos_y; scale; delete o <text> text </ text> s atributy:  ref; font; height; pos_x; pos_y; wrap; delete o <stop /> o <quit /> <speak> text k přečtění </speak> <sleep /> Z názvů těchto příkazů je čtenáři jistě patrné, kterou činnost představují, proto se nebudeme podrobněji zabývat jejich definicí. 5.4.3 Spuštění a nastavení TH používá konfigurační soubor Talking_Head.conf, ve kterém nastavujeme pozadí aplikace, druh použitého písma a jeho velikost, počet znaků k zalamování 47 řádků (wrap), rozlišení, na kterém byla aplikace vyvíjena a rozlišení, na kterém aplikace aktuálně běží, barvu písma a boxu, který může být zobrazený vedle hlavy, pozice okna a jiné. Můžeme také použít xml soubor definující oblasti, na které když uživatel klikne myší, nevrátí server zprávu pouze se souřadnicemi, ale také se jménem této oblasti. Xml soubor se musí jmenovat stejně jako obrázkový soubor s pozadím, kromě přípony. Server aplikaci spouštíme příkazem: Talking_head_rel_emb [m|l|s|g|c] [v|s|o] [port] kde m, l, s, g nebo c značí druh zobrazené hlavy; v, s, o určuje IBM ViaVoice TTS (volba v), MS SAPI TTS (volba s) nebo individuální soubor s fonémy, jehož jméno musí následovat za argumentem o. Dále musíme zvolit síťový port, na který se připojí klient. Ten spouštíme takto: java –jar talkingHead.jar adresaServeru:port Na následujícím obrázku vidíme ukázku naší aplikace běžící na localhostu s defaultním IBM ViaVoice TSS a hlavou typu m (Masha) na portu číslo 40000. Obrázek 8 – Screenshot aplikace verze 1.0 5.4.4 Činnost klienta Naše aplikace funguje podle následujícího pseudokódu: 48 while(true) { if (eventArray.size > 0) { serveEvent(); } else { threadSleep(); } } Při implementaci aplikace nemůžeme posílat act či speak příkazy z metody, která obsluhuje událost (tzv. eventListener), proto jsme naprogramovali tuto smyčku, která neustále kontroluje frontu událostí, která se plní v eventListeneru, když uživatel klikne myší do okna s TH. Tehdy server pošle klientovi událost se souřadnicemi x a y, případně i se jménem oblasti (tag area). Pokud je fronta událostí prázdná, uspíme vlákno a čekáme do té doby, dokud jej neprobudí uživatel svou činností (tím se spustí eventListener, který vlákno se smyčkou probudí). Jak jsme zjistili, jde o lepší způsob, než neustále po daných časových intervalech kontrolovat tuto frontu, protože se pak procesor více zatěžuje. Pozor je třeba dávat i na to, že k frontě musíme přistupovat atomicky, protože jej nesmí v jednom okamžiku používat jak metoda obsluhy událostí, tak hlavní vlákno programu. Vyřešili jsme to javovským příkazem synchronized. V případě, že uživatel klikl myší na tlačítko aktualizace, které načítá data ze souboru rssList.txt, je zakázáno přidávání událostí do fronty, jelikož načítání nějakou chvíli trvá. Pokud máme definovány oblasti v xml souboru, je nutné brát v úvahu, že server v tomto případě neposílá jednu událost, ale dvě. Jedna obsahuje číselné souřadnice a druhá jméno oblasti. Osobně si myslíme, že by bylo dobré je sjednotit do jedné události. Je nutné počítat i s tím, že pokud hlava mluví, nemůžeme ji poslat další text ke čtení. V takovém případě hlava další text nepřečte a aplikace dokonce spadne. Lze to vyřešit tím, že budeme posílat blokující speak událost. Problém je ale v tom, že pak uživatel musí čekat, než hlava domluví celou zprávu, což občas trvá velmi dlouho, podle toho, jak dlouhý souhrn jsme ji poslali ke čtení. My proto posíláme neblokující speak, ale před každým posláním nové zvukové zprávy kontrolujeme, jestli už hlava domluvila, což se projeví tím, že server odešle událost s parametrem receive_sentence. Ten neobsahuje počet přečtených vět, ale pouze se přičte jednička k předchozí hodnotě (pozn.: tato hodnota je vynulována až po restartu serveru a 49 ne pouze klienta). Celkem aplikace obsahuje pouze tyto dvě obsluhy událostí, jednu na act příkazy a druhou na odchytávání receive_sentence zprávy. Práce se vstupním souborem, ze kterého se načítají webové adresy RSS serverů, se nám zdála být celkem zdlouhavá, proto ihned po startu aplikace vytváříme samostatný thread (vlákno), který běží paralelně vedle hlavního vlákna. Tím jsme dosáhli mnohonásobného zrychlení načítání. Pokud hlavní vlákno dorazí k zobrazení těchto právě čtených RSS serverů dříve, je uspáno a čeká. Soubor s definovanými adresami RSS serverů jsme rozšířili o několik parametrů jako je typ písma (musí být uložen v adresáři Font v server aplikaci), výška písma, počet odkazů na stránce a vzdálenost mezi nimi, počet znaků na řádek a zejména počet vět souhrnu, který se posílá sumarizačnímu algoritmu. Pokud tyto parametry nedefinujeme (nebo řádek zakomentujeme znakem #), bude použita přednastavená hodnota. Necháváme uživateli úplnou volnost ve volbě těchto parametrů, proto se může při jejich nevhodném zvolení stát, že budou znaky v aplikaci mimo zobrazovací oblast a tedy nečitelné. Pro lepší znázornění jsou klikatelné části naprogramovány tak, že pokud na ně uživatel klikne, dojde na okamžik k jejich zvětšení nebo k podobnému zvýraznění. Program obsahuje i nápovědu, která ukáže uživateli pointerem, na co má kliknout a co se poté stane. 51 KAPITOLA 6 Usability testing Po dokončení aplikace jsme nechali otestovat její funkčnost a výkonnost na několika osobách rozdílné povahy. Testované osoby byly ponechány o samotě bez jakéhokoliv vlivu autora u notebooku s instalovanou TH. Součástí testování bylo vyplnění vstupního dotazníku a předložení několika úkolů a nakonec vyplnění výstupního dotazníku, který nás zajímal nejvíce. Odpovědi na tyto otázky jsou uvedeny v tabulce výše. Testování od autora probíhalo na notebooku Lenovo R400 s dvoujádrovým procesorem 1.8Ghz, 3GB RAM, integrovanou grafickou kartou Intel 4500MHD se sdílenou pamětí a bez přídavných reproduktorů. Kdežto testování eventuálních uživatelů probíhalo na notebooku HP ProBook 6560b s procesorem Core i5 taktovaném na 2.3Ghz (plus v případě vytížení je automaticky přetaktován až na 2.9Ghz) se 4GB RAM a grafickou kartou AMD Radeon HD6470M s vlastní pamětí rovněž bez přídavných reproduktorů. 6.1 Vstupní dotazník Hodnoťte prosím na stupnici 1 až 5, kde 1 je nejlepší a 5 nejhorší (podobně jako známkování ve škole) 1. Vaše úroveň angličtiny (1-5): 2. Víte, co jsou RSS feeds (zdroje)? (ano/ne): 3. Používal(a) jste je někdy? (ano/ne): 4. Setkal(a) jste se někdy s mluvící hlavou nebo zařízením napodobujícím lidskou řeč? (ano/ne): 6.2 Co je možné v aplikaci otestovat Do aplikace přidejte nějaký svůj vlastní RSS odkaz (aby jej mohla hlava přečíst, musí obsahovat články v angličtině). Můžete změnit velikost písma, odsazení mezi vypisovanými odkazy, počet znaků na řádek a zejména počet vět prezentovaného článku. 52 Nápověda: pokud jste dosud nenašli způsob, jak přidat RSS odkaz nebo změnit parametry, otevřete soubor rssList.txt v adresáři resources (tato informace je napsaná v info boxu vedle hlavy, když zvolíte nápovědu). Můžete zkusit měnit soubor i za běhu aplikace. Načtete jej kliknutím na ikonku update v aplikaci na první straně s RSS odkazy (na stránkách s odkazy na články se updatují pouze tyto články). 6.3 Výstupní dotazník 5. Líbila se Vám aplikace jako celek? (1-5): 6. Používal(a) by jste ji na svém počítači nebo jinde? Můžete případně uvést i název zařízení kde by jste jej používal? (ano/ne/název): 7. Ohodnoťte prosím grafickou podobu aplikace (1-5): 8. Ohodnoťte prosím grafickou podobu mluvící hlavy (1-5): 9. Rozumněl(a) jste hlavě její verbální prezentaci? (1-5): 10. Kolik vět by podle Vás měl mít souhrn, aby jste si jej v klidu poslechl(a) celý? Můžete uvést i procentuální hodnotu z originálního článku: 11. Myslíte si, že je aplikace dostatečně rychlá? (ano/ne): 12. Co by se podle Vás dalo zlepšit? Zde můžete uvést i chyby, na něž jste narazili během testování. Nebojte se se rozepsat. Děkujeme 6.4 Odpovědi Odpovědi jsou buď slovního typu, případně ano/ne nebo pomocí stupnice 1-5, kde 1 je nejlepší a 5 nejhorší. Tabulka 6 – Usability testing Osoba A – muž, VŠ (Ing.), 30 let, programátor Číslo otázky Odpověď 1 2 2 ano 3 ano, denně 4 ano, např.: Kindle 5 3 6 ano - jako demonstrativní účely, iPad, TV 53 7 3 8 2 9 1 10 7 11 ano 12 ikony jsou barevně nejednotné, evidentně stažené z různých zdrojů projekční plátno je zešikmené, kdežto text není. Nevypadá to dobře. animace rozbalovacího plátna je trhavá a kostrbatá (nápad: místo animace plátno pouze “rozsvítit“) rozložení ikon nedává smysl (domeček je napravo od ostatních tlačítek a je i jinak veliký). Hezčí by byly v jedné řadě a ne ve tvaru převráceného písmene L. pozadí je hezké, ale přeplácané, tudíž je na text málo místa při změně velikosti okna se vše trochu “rozhodí” 1 3 2 ano B – muž, VŠ (Bc.), 25 let, 3 ano elektroenergetik 4 ano 5 1 6 ano - Smart-phone 54 7 2 8 1 9 1 10 5 11 ano 12 možnost výběru jazyka možnost interpretace zpráv prostřednictvím jiného objektu než “hlavy“ (robot, rádio apod.) 1 3 2 ne 3 ne 4 ano 5 2 C – žena, 28 let, VŠ 6 ano – Smart-phone (MUDr.), patolog 7 2 8 2 9 1 10 6 11 ano 12 - Účastníci se shodli na tom, že délka optimálního prezentovaného článku je přibližně 2 až 7 vět v závislosti na tom, jak dlouhé věty sumarizátor vybere. Všichni byly spokojeni jak s grafickou úpravou, tak i s verbální komunikací TH a dokázali by si aplikaci představit v praktickém užití, například ve svém telefonu. Celková rychlost aplikace byla taktéž hodnocena jako velmi dobrá. Z uvedených údajů a posléze z osobní zpovědi testerů jsme zjistili, že si nikdo nestěžoval na prodlevu, kterou má TH mezi odesláním článku a začátkem mluvení. Tato prodleva byla narozdíl od naší zkušenosti prý snesitelná, což si vysvětlujeme tím, že aplikace během testování běžela na mnohem rychlejším, o 3 roky novějším 55 počítači a zároveň nebyly testovány souhrny o větším počtu vět než 7, jelikož poté tester přestával vnímat prezentovaný článek. Na našem starším notebooku byla prodleva u cca 10 prezentovaných vět přibližně 10-20 vteřin, což se nám zdálo mnoho. Dále uvedený seznam shrnuje všechny nalezené problémy s přiřazenou prioritou (hodnota od 1 do 5, kde 1 je nejzávažnější a 5 nejméně závažný) podle důležitosti: ikony všech tlačítek nejsou jednotné; barevně nijak neladí – priorita 4 ikona domečku je větší, než ostatní ikony – priorita 5 rozložení ikon není v jedné řadě, ale ve tvaru obráceného písmene L, což vypadá podivně – priorita 5 animace projekčního plátna je kostrbatá a zobrazený text na něm není zešikmený jako plátno – priorita 4 na text článku je málo místa; plocha aplikace je “přeplácaná“ – priorita 4 při změně velikosti okna se rozložení ikon a textu “rozhodí“ – priorita 3 TH trvá celkem dlouho, než začne číst delší článek – priorita 3 Na základě kritiky grafické části aplikace od účastníků jsme se rozhodli ji předělat do vzhlednější formy, která se líbila mnohem více a byla uživatelsky přívětivější. Byly vybrány prvky, jejichž barevné kombinace byly podobné a lépe spolu kombinovaly. Odstraněna byla i nápověda ve formě boxu vedle hlavy, která zbytečně zabírala místo, plus nepotřebný pointer. Nyní je nápověda zobrazena pouze slovně v okně pro články. Ikony pro hlavní menu jsou nyní v jedné řadě a shodně veliké. Kromě změny vzhledu aplikace neprodělala dalších větších změn. Screenshot z této druhé verze ukazuje obrázek výše. 56 Obrázek 9 – Screenshot aplikace verze 2.0 57 KAPITOLA 7 Závěr V této kapitole bychom chtěli shrnout své snažení o vypracování aplikace sloužící k získání a sumarizaci článků ze zpravodajských serverů. 7.1 Splnění cílů Ve druhé kapitole jsme si předsevzali několik cílů a nyní si můžeme říci, jestli se nám je podařilo splnit. Naprogramovali jsme rychlou, uživatelsky a graficky přívětivou klientskou část aplikace v jazyce java, která s použitím knihovny BoilerPipe stáhne ze zpravodajského serveru čistý článek v podobě plain textu a předá ho poměrně kvalitnímu sumarizátoru používajícímu vyhledávací algoritmus Lucene. Tento sumarizační algoritmus jsme vybrali na základě testování metodou ROUGE-SU4, jejímž vstupem byly kromě automatických extraktů také abstrakty získané aplikací Text-Corpus-Summaries-Wikipedia-0.21. Vybraný sumarizátor shrne stažený článek do uživatelem definovaného počtu vět, zobrazí jej v okně aplikace a po stisku příslušného tlačítka si jej uživatel může vyslechnout od krásně vypadající mluvící hlavy s dobrou mimikou v obličeji. Aplikace je také uživatelsky modifikovatelná díky konfiguračnímu souboru rssList.txt, v němž lze zvolit odkazy na vlastní RSS zdroje verze 2.0, velikost a typ používaného písma, počet zobrazených položek v okně aplikace a již zmíněný počet vět, do kterých chceme článek shrnout. Funkčnost a výkonnost aplikace jsme otestovali na několika potenciálních uživatelích a poté jsme na základě jejich kritiky vylepšili zejména její grafickou část. Přesto by si aplikace zasloužila rozsáhlejší testování. Myslíme si, že jediné, co brání nasazení aplikace do našeho běžného života je, že Talking head není prozatím distribuovatelná pod volně šířitelnou licencí a také, že je limitována prezentováním článku pouze v anglickém jazyce. Pokud by byla aplikace nasazena i na mobilní telefony, bylo by potřeba ji patřičně upravit, jelikož výkonové nároky mluvící hlavy jsou značné. 58 7.2 Možnosti vylepšení Ačkoliv je aplikace ke čtení článků plně postačující, nabízí se mnoho možností jejího rozšíření. Například modifikace parametrů a odkazy na RSS zdroje, které jsou nyní prováděny v souboru, by se mohly měnit přímo v okně aplikace za pomocí checkboxů. Dokonce by bylo možné uvést nejen RSS zdroj, ale jakýkoliv odkaz na článek nacházející se na internetu nebo i kdekoliv na vnitřním disku počítače ve formě html souboru nebo souboru obsahujícího neformátovaný plain text. Týká se to i nastavování parametrů na straně serveru, kdy musíme ručně editovat soubor Talking_Head.conf, ve kterém lze měnit rozlišení, barvu boxu vedle hlavy a jiné. K tomu všemu by bylo ale potřeba graficky znázornit a vhodně rozmístit tlačítka klávesnice v okně aplikace, protože dotykový SmartKiosek neobsahuje externí klávesnici. Pokud by se však aplikace používala pouze na počítači, bylo by možné zachytávat uživatelem stisknuté klávesy a grafická podoba klávesnice by tak nebyla potřeba. Aplikace nyní nabízí pouze tlačítko na stopnutí prezentace mluvící hlavy. V případě dlouhých článků by ale mohla obsahovat i tlačítko pauza, po jehož opětovném stisknutí by prezentace pokračovala od místa přerušení. Aktuálně čtený text by se také mohl na obrazovce zvýrazňovat, aby uživatel viděl, v které fázi textu se prezentace nachází. Zjistili jsme také, že posílaný text serverové straně nesmí obsahovat diakritiku, protože by nebyla správně zobrazena, což je značně omezující z toho důvodu, že sumarizační algoritmus pracuje uspokojivě například i s českým jazykem a mohli bychom si shrnutý český text alespoň přečíst. Serverová část neumí zobrazit ani některé jiné znaky, jako například znak procenta, znak nového řádku apod. Bylo by dobré, kdyby posílaný text mohl být více formátovaný, než jen typem písma a jeho velikostí. Potřebovali bychom zobrazit například podtržený nebo tučný text. Také odsazení odstavců by bylo příjemné. Nadstandardní funkcí by mohlo být i ovládání hlasitosti přímo z okna aplikace. Přítomen by mohl být i frekvenční ekvalizér ovlivňující kvalitu hlasu. 59 Ceníme si vhodně zvoleného png formátu obrázků, které je možné zobrazit. Přesto bychom uvítali možnost použití animovaného obrázku typu gif, který jsme chtěli použít jako ikonku znázorňující načítání dat ze souboru, stahování článků z internetu nebo jako ikonku indikující mluvení hlavy. 7.3 Zhodnocení Je vidět, že možností rozšíření je spousta a další by se daly jistě vymyslet. Myslíme si ale, že současná forma aplikace již postačuje k běžnému použití. Přesto budeme rádi, když vývoj aplikace bude pokračovat, ať už námi nebo někým jiným. Malinko bychom například vylepšili anglickou výslovnost TH, snížili její nároky na výkonnost počítače a hlavně bychom přidali i jiné jazyky, zejména ten náš český ... 61 Literatura [1] http://en.wikipedia.org/wiki/RSS [2] http://en.wikipedia.org/wiki/Resource_Description_Framework [3] http://cs.wikipedia.org/wiki/Atom_(standard) [4] http://www.w3schools.com/rss/rss_channel.asp [5] http://en.wikipedia.org/wiki/Watson_(computer) [6] KAREL JEŽEK, JOSEF STEINBERGER: Sumarizace textů [7] LUHN, H. P.: The Automatic Creation of Literature Abstracts (1958) [8] EDMUNDSON, H.P. 1968. New Methods in Automatic Extraction. Journal of the ACM 16(2) [9] KUPIEC, J., J. PEDERSEN, AND F. CHEN. 1995. A Trainable Document Summarizer. In Proceedings of the Eighteenth Annual International ACM Conference on Research and Development in Information Retrieval (SIGIR), Seattle, WA. [10] SPARK JONES, K. 1997. Invited keynote address, Workshop on Intelligent Scalable Text Summarization. ACL/EACL Conference. Madrid, Spain [11] HOVY, E., LIN, C-Y.: Automated Text Summarization in SUMMARIST. In: I. Mani and M.T. Maybury (Eds.), Advances in Automatic Text Summarization, The MIT Press, (1999) [12] MARCU, D.: From Discourse Structures to Text Summaries. In: Proceedings of the ACL97/EACL97 Workshop on Intelligent Scalable Text Summarization, Madrid, Spain, (1997) [13] BRIN, S., PAGE, L.: The anatomy of a large-scale hypertextual Web search engine. In: Computer Networks and ISDN Systems, 30, (1998) [14] GONG, X., LIU X.: Generic Text Summarization Using Relevance Measure and Latent Semantic Analysis. In: Proceedings ACM SIGIR. New Orleans, USA (2001) [15] STEINBERGER, J., JEŽEK, K.: Evaluation Measures for Text Summarization. In: Computing and Informatics, 28(2), (2009) [16] http://berouge.com/default.aspx [17] http://cs.wikipedia.org/wiki/N-gram 62 [18] LIN, CHIN-YEW. 2004a. ROUGE: A Package for Automatic Evaluation of Summaries. In Proceedings of the Workshop on Text Summarization Branches Out (WAS 2004), Barcelona, Spain, July 25 - 26, 2004 [19] http://cs.wikipedia.org/wiki/Klient-server [20] http://cs.wikipedia.org/wiki/Unified_Modeling_Language [21] http://sujitpal.blogspot.com/2009/02/summarization-withlucene.html [22] http://libots.sourceforge.net/ [23] http://classifier4j.sourceforge.net/ [24] http://www.copernic.com/en/products/summarizer/index.html [25] http://search.cpan.org/~kubina/Text-Corpus-SummariesWikipedia-0.21/ [26] http://sourceforge.net/projects/classifier4j/files/ [27] http://lucene.apache.org/java/docs/index.html [28] http://www.blogger.com/profile/06835223352394332155 [29] http://www.softpedia.com/get/Office-tools/Other-OfficeTools/Copernic-Summarizer.shtml [30] http://wordnet.princeton.edu/ [31] http://code.google.com/p/boilerpipe/ [32] CHRISTIAN KOHLSCHÜTTER, PETER FANKHAUSER, WOLFGANG NEJD: Boilerplate Detection using Shallow Text Features [33] http://boilerpipe-web.appspot.com/ [34] http://en.wikipedia.org/wiki/Interactive_online_characters [35] http://cs.wikipedia.org/wiki/Fon%C3%A9m 63 Příloha A Seznam použitých zkratek RSS Really Simple Sindication, Rich Site Summary TH Talking Head XML Extensible Markup Language HTML HyperText Markup Language RDF Resource Description Framework Atom Atom Syndication Format CDF Channel Definition Format JPEG Joint Photographic Experts Group ROUGE Recall-Oriented Understudy for Gisting Evaluation DUC Document Understanding Conference TAC Text Analysis Conference NIST National Institute of Standards and Technology JVM Java Virtual Machine SVD Singular Value Decomposition LSA Latent Semantic Analysis tf term frequency idf inverted term frequency GUI Graphical User Interface UML Unified Modeling Language OTS Open Text Summarizer C4J Classifier for Java SAX Simple API for XML DOM Document Object Model JSON JavaScript Object Notation CSS Cascading Style Sheet TTS Text to speech 65 Příloha B Obsah přiloženého CD Adresář data obsahuje soubory s informacemi používanými v této práci, např. soubor s grafy, sumarizační algoritmy aj. Adresář exe obsahuje .jar soubory klienta a textové či obrázkové soubory potřebné ke spuštění. Serverová část aplikace nemohla být z důvodu licenčních podmínek zahrnuta. Adresář html obsahuje český a anglický abstrakt Src adresář obsahuje zdrojové soubory pro klienta, a to verzi 1.0 a verzi 2.0, která byla zejména graficky vylepšena na základě kritiky testerů. Adresář text obsahuje tuto diplomovou práci v pdf a také v docx (MS Word 2010) formátu. soubor index.html obsahuje nejdůležitější odkazy na soubory nacházejících se na přiloženém dvd install.txt obsahuje informace ke spuštění aplikace, jak serverové, tak klientské readme.txt shrnuje informace o všech souborech a adresářích na přiloženém dvd Pozn.: uvedené textové a html soubory jsou psány znakovou sadou UTF-8. </div> </div> </div> </div> </div> </div> </div> </div> <div class="modal fade" id="report" tabindex="-1" role="dialog" aria-hidden="true"> <div class="modal-dialog"> <div class="modal-content"> <form role="form" method="post" action="https://adoc.pub/report/fakulta-elektrotechnicka-katedra-poita-bc-vitzslav-musil" style="border: none;"> <div class="modal-header"> <button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button> <h4 class="modal-title">Report "Fakulta elektrotechnická Katedra počítačů. Bc. Vítězslav Musil"</h4> </div> <div class="modal-body"> <div class="form-group"> <label>Your name</label> <input type="text" name="name" required="required" class="form-control" /> </div> <div class="form-group"> <label>Email</label> <input type="email" name="email" required="required" class="form-control" /> </div> <div class="form-group"> <label>Reason</label> <select name="reason" required="required" class="form-control"> <option value="">-Select Reason-</option> <option value="pornographic" selected="selected">Pornographic</option> <option value="defamatory">Defamatory</option> <option value="illegal">Illegal/Unlawful</option> <option value="spam">Spam</option> <option value="others">Other Terms Of Service Violation</option> <option value="copyright">File a copyright complaint</option> </select> </div> <div class="form-group"> <label>Description</label> <textarea name="description" required="required" rows="3" class="form-control" style="border: 1px solid #cccccc;"></textarea> </div> <div class="form-group"> <div style="display: inline-block;"> <div class="g-recaptcha" data-sitekey="6LcEnMcZAAAAAFHzKKgaE-Qh57XzUTzpfRElD4dP"></div> </div> </div> <script src='https://www.google.com/recaptcha/api.js'></script> </div> <div class="modal-footer"> <button type="button" class="btn btn-default" data-dismiss="modal">Close</button> <button type="submit" class="btn btn-primary">Send</button> </div> </form> </div> </div> </div> <script> $(document).ready(function () { var inner_height = $(window).innerHeight() - 250; $('#pdfviewer').css({"height": inner_height + "px"}); }); </script> <footer class="footer" style="margin-top: 60px;"> <div class="container-fluid"> Copyright © 2024 ADOC.PUB. All rights reserved. <div class="pull-right"> <a href="https://adoc.pub/about">About Us</a> | <a href="https://adoc.pub/privacy">Privacy Policy</a> | <a href="https://adoc.pub/term">Terms of Service</a> | <a href="https://adoc.pub/copyright">Copyright</a> | <a href="https://adoc.pub/contact">Contact Us</a> | <a href="https://adoc.pub/cookie_policy">Cookie Policy</a> </div> </div> </footer>  <div class="modal fade" id="login" tabindex="-1" role="dialog" aria-labelledby="myModalLabel"> <div class="modal-dialog" role="document"> <div class="modal-content"> <div class="modal-header"> <button type="button" class="close" data-dismiss="modal" aria-label="Close" on="tap:login.close">×</button> <h4 class="modal-title" id="add-note-label">Sign In</h4> </div> <div class="modal-body"> <form action="https://adoc.pub/login" method="post"> <div class="form-group"> <label class="sr-only" for="email">Email</label> <input class="form-input form-control" type="text" name="email" id="email" value="" placeholder="Email" /> </div> <div class="form-group"> <label class="sr-only" for="password">Password</label> <input class="form-input form-control" type="password" name="password" id="password" value="" placeholder="Password" /> </div> <div class="form-group"> <div class="checkbox"> <label class="form-checkbox"> <input type="checkbox" name="remember" value="1" /> Remember me </label> <label class="pull-right"><a href="https://adoc.pub/forgot">Forgot password?</a></label> </div> </div> <button class="btn btn-primary btn-block" type="submit">Sign In</button> </form> </div> </div> </div> </div>  <script async src="https://www.googletagmanager.com/gtag/js?id=UA-177279549-1"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-177279549-1'); </script> <script src="https://adoc.pub/assets/js/jquery-ui.min.js"></script> <link rel="stylesheet" href="https://adoc.pub/assets/css/jquery-ui.css"> <script> $(function () { $("#document_search").autocomplete({ source: function (request, response) { $.ajax({ url: "https://adoc.pub/suggest", dataType: "json", data: { term: request.term }, success: function (data) { response(data); } }); }, autoFill: true, select: function( event, ui ) { $(this).val(ui.item.value); $(this).parents("form").submit(); } }); }); </script>  <div id="ADOCPUB_cookie_box" style="z-index:99999; border-top: 1px solid #fefefe; background: #FFC107; width: 100%; position: fixed; padding: 5px 15px; text-align: center; left:0; bottom: 0;"> Our partners will collect data and use cookies for ad personalization and measurement. <a href="https://adoc.pub/cookie_policy" target="_blank">Learn how we and our ad partner Google, collect and use data</a>. <a href="#" class="btn btn-success" onclick="accept_ADOCPUB_cookie_box();return false;">Agree & close</a> </div> <script> function accept_ADOCPUB_cookie_box() { document.cookie = "ADOCPUB_cookie_box_viewed=1;max-age=15768000;path=/"; hide_ADOCPUB_cookie_box(); } function hide_ADOCPUB_cookie_box() { var cb = document.getElementById('ADOCPUB_cookie_box'); if (cb) { cb.parentElement.removeChild(cb); } } (function () { var ADOCPUB_cookie_box_viewed = (function (name) { var matches = document.cookie.match(new RegExp("(?:^|; )" + name.replace(/([\.$?*|{}\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)")); return matches ? decodeURIComponent(matches[1]) : undefined; })('ADOCPUB_cookie_box_viewed'); if (ADOCPUB_cookie_box_viewed) { hide_ADOCPUB_cookie_box(); } })(); </script>  </body> </html> <script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script>

Fakulta elektrotechnická Katedra počítačů. Bc. Vítězslav Musil

Recommend Documents