Rok akademicki 2011/2012 Politechnika Warszawska

Wydzia Elektroniki i Technik Informacyjnych Instytut Informatyki

PRACA DYPLOMOWA IN YNIERSKA

Daniel Bie kowski

Mechanizmy zaawansowanych rekomendacji w systemach portali internetowych

Opiekun pracy mgr in . Piotr Salata

Ocena: ...................................................

.............................................................. Podpis Przewodnicz cego

Komisji Egzaminu Dyplomowego

Specjalno : In ynieria Systemów Informatycznych

Data urodzenia: 1989.03.25

Data rozpocz cia studiów: 2009.02.23

yciorys

Urodzi em si 25 marca 1989 roku w Warszawie. Po uko czeniu szko y podstawowej

nr 254, a nast pnie gimnazjum nr 127 w zespole szkó nr 74, kontynuowa em nauk w XXII

Liceum Ogólnokszta cym im. Jose Marti, gdzie ucz szcza em do klasy o profilu

matematyczno-fizycznym. W roku 2008 zda em matur oraz rozpocz em studia dzienne na

wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej.

...................................................... Podpis studenta

EGZAMIN DYPLOMOWY

egzamin dyplomowy w dniu ............................................................................... 2012 r

z wynikiem ..............................................................................................................................

Ogólny wynik studiów: ............................................................................................................

Dodatkowe wnioski i uwagi Komisji: ......................................................................................

.................................................................................................................................................

.................................................................................................................................................

STRESZCZENIE

Niniejsza praca ma na celu przedstawienie mechanizmów zaawansowanych rekomendacji.

Obok aspektów teoretycznych zosta y zaprezentowane algorytmy u ywane w systemach

rekomendacji, w tym tak e rozpoznanie dziedziny Collaborative Filtering, która jest

znacz cym elementem praktycznej cz ci pracy. W pracy zawarto okre lenie stosowalno ci

wybranych metod rekomendacji oraz opracowanie projektu ich implementacji. Integraln

cz ci pracy jest aplikacja Findy, w której zaimplementowano opisane algorytmy. Aplikacja

umo liwia zaprezentowanie dzia ania mechanizmów rekomendacji w praktyce.

owa kluczowe: mechanizmy rekomendacji, filtrowanie z analiz zawarto ci, wspólna

filtracja, miary korelacji, miary podobie stwa.

ADVANCED RECOMMENDATION MECHANISMS

IN SYSTEMS OF WEB PORTALS

The purpose of this thesis is to present advanced recommendation mechanisms. Theoretical

aspects and algorithms used in recommendation systems were introduced, including

identification of fields of Collaborative Filtering, which is the significant element of the

practical part of the work. This thesis also contains presentation of applicability of selected

recommendation methods and description of project of their implementation. The integral part

of the thesis is Findy application, which includes implementation of described algorithms.

Application lets to present the recommendations mechanism in practical action.

Keywords: recommendation mechanism, Content-based filtering, Collaborative Filtering,

measure of correlation, measure of similarity.

Sk adam serdeczne podzi kowania mgr in . Piotrze

Salacie za pomoc i cierpliwo okazan przy

pisaniu niniejszej pracy.

5

Spis tre ci Rozdzia 1 Wprowadzenie ......................................................................................................7

Rozdzia 2 Informacje podstawowe ........................................................................................9

2.1. Wzorce projektowe...................................................................................................9

2.1.1. Automatyczne uzupe nianie ...............................................................................9

2.1.2. Najpierw najlepszy .......................................................................................... 10

2.1.3. Nawigacja fasetowa ......................................................................................... 12

2.1.4. Personalizacja ................................................................................................. 13

2.2. Metody tworzenia profili u ytkownika ................................................................... 15

2.2.1. Podej cie aktywne ........................................................................................... 16

2.2.2. Podej cie pasywne........................................................................................... 17

2.3. Podsumowanie ....................................................................................................... 18

Rozdzia 3 Systemy rekomendacji ........................................................................................ 19

3.1. Idea systemów rekomendacji .................................................................................. 19

3.2. Content-based Filtering .......................................................................................... 20

3.3. Collaborative Filtering ............................................................................................ 24

3.3.1. Metody wykorzystuj ce pami (Memory-based) ............................................ 24

3.3.2. Metody wykorzystuj ce model (Model-based) ................................................ 27

3.4. G ówne problemy przy stosowaniu mechanizmów rekomendacji............................ 28

3.4.1. Rzadko danych ............................................................................................. 28

3.4.2. Skalowalno .................................................................................................. 29

3.4.3. Pozosta e wyzwania ........................................................................................ 30

3.5. Podej cie hybrydowe .............................................................................................. 30

3.6. Podsumowanie ....................................................................................................... 35

6

Rozdzia 4 Aplikacja Findy .................................................................................................. 36

4.1. Za enia ................................................................................................................ 36

4.2. Specyfikacja wymaga ........................................................................................... 37

4.2.1. Wymagania funkcjonalne ................................................................................ 37

4.2.2. Wymagania niefunkcjonalne ........................................................................... 37

4.3. Realizacja ............................................................................................................... 37

4.3.1. Technologia Spring Framework....................................................................... 38

4.3.2. Technologia Vaadin ........................................................................................ 39

4.3.3. Wzorzec Model-View-Presenter ...................................................................... 42

4.4. Praca z aplikacj ..................................................................................................... 43

4.5. Sposób implementacji algorytmów rekomendacji ................................................... 46

4.5.1. Implementacja filtracji z analiz zawarto ci ..................................................... 46

4.5.2. Implementacja wspólnej filtracji ...................................................................... 49

4.6. Mo liwo ci rozwoju ............................................................................................... 51

Rozdzia 5 Podsumowanie .................................................................................................... 53

Rozdzia 6 Literatura ............................................................................................................ 56

Dodatek A Diagram klas modelu MVP w aplikacji Findy ..................................................... 58

Dodatek B Zawarto p yty CD ............................................................................................ 59

7

Rozdzia 1

Wprowadzenie We wspó czesnym wiecie, gdzie mamy do czynienia z mas wielorakich produktów i

olbrzymia liczb ró norodnych klientów, tradycyjne mechanizmy prezentacji produktów

sta y si niewystarczaj ce. Tradycyjna reklama w mediach czy na innych masowych

no nikach jest nieskuteczna, poniewa nie jest w aden sposób indywidualizowana i

kierowana do odpowiednich osób. Równie zalewanie potencjalnych klientów du ilo ci

e-maili b SMS-ów nie przynosi ju oczekiwanych, pozytywnych rezultatów, coraz

cz ciej powoduj c niech do zakupu czy zapoznania si bli ej z produktem. Dzisiejsze

spo ecze stwo sta o si bardzo wyczulone na narzucane im formy promocji i reklamy.

Skutkiem tej sytuacji s coraz wi ksze inwestycje w bardziej zaawansowane systemy

rekomendacji, obecnie cz sto wykorzystywane w wielu miejscach w Internecie, mi dzy

innymi w serwisach spo eczno ciowych, serwisach aukcyjnych czy sklepach on-line.

Nowoczesne mechanizmy rekomendacji korzystaj z algorytmów, które s w stanie

oszacowa , jaka oferta b jaki produkt wybrany z przestrzeni mo liwych opcji najlepiej

trafi w gusta konsumenta, a przy tym zwi kszy jego komfort podczas korzystania z

aplikacji, serwisu czy portalu. Ich dzia anie odbywa si w sposób transparentny dla

ytkownika, odfiltrowuj c tre ci mog ce go zainteresowa od tych nieinteresuj cych. W

niniejszej pracy skupiono si na problemie wykorzystywania powy szych mechanizmów

rekomendacji w systemach portali internetowych. G ównym celem pracy jest opracowanie

i implementacja aplikacji prezentuj cej ich dzia anie w praktyce. Przedstawione zostan

najpopularniejsze wzorce wykorzystywane w mechanizmach rekomendacji oraz okre lona

zostanie stosowalno wybranych metod rekomendacji, a w szczególno ci metody

Collaborative Filtering, która jest g ównym elementem praktycznej cz ci pracy

in ynierskiej.

Pocz tkowy rozdzia po wi cony jest wzorcom projektowym najcz ciej

wykorzystywanym przez mechanizmy rekomendacji, stanowi cym najpopularniejsze

rozwi zania typowych problemów, na które u ytkownik mo e natrafi podczas korzystania

z portalu. Zostan tu przedstawione konteksty u ycia danych wzorców oraz przyk adowe

sposoby wykorzystywania i zastosowania mechanizmów rekomendacyjnych. Opisany

zostanie mi dzy innymi wzorzec personalizacji, którego g ówna idea – ukazanie

ytkownikowi strony dostosowanej do jego potrzeb, zosta a zastosowana w aplikacji

8

Findy. Oprócz tego, w rozdziale zaprezentowano tak e metody tworzenia profili

ytkownika. Aby móc zastosowa mechanizmy rekomendacji, niezb dny jest proces

zbierania informacji o u ytkowniku i przygotowanie na jego podstawie matematycznej

reprezentacji jego preferencji czy wzorców zachowa . Ta reprezentacja, nazywana

profilem, wykorzystywana jest przez algorytmy do obliczania miar korelacji, czy

podobie stwa z innymi u ytkownikami stosowanych przy algorytmach obliczaj cych

rekomendacj . W niniejszej pracy zosta y przedstawione dwa podej cia pozwalaj ce na

zdobycie niezb dnych informacji wraz z przedstawieniem ich wad i zalet.

W dalszej cz ci pracy ukazano teoretyczne aspekty mechanizmów rekomendacji oraz

ich g ówne idee. Przedstawiono podzia mechanizmów na podstawowe podej cia. Pierwsz

kategori s mechanizmy bazuj ce na analizie zawarto ci i profili dotycz cych obiektów w

serwisie oraz na indywidualnych preferencjach u ytkownika (Content-based Filtering).

Drug kategori stanowi mechanizmy oparte na preferencjach oraz zachowaniach innych

ytkowników najbardziej podobnych do danego u ytkownika (Collaborative Filtering).

Dzi ki temu mo liwe jest proponowanie mu nowych obiektów, które z du ym

prawdopodobie stwem uzna za interesuj ce. Powy sze dwa podej cia zosta y

zaimplementowane w aplikacji Findy ukazuj cej ich zachowanie w praktyce. W niniejszej

pracy opisane zosta y tak e ograniczenia i problemy wyst puj ce przy zastosowaniu

wymienionych technik. Oprócz powy szych, zosta o opisane tak e podej cie hybrydowe,

które czy dzia anie obu zaprezentowanych koncepcji.

Kolejny rozdzia prezentuje sposób realizacji praktycznej cz ci pracy – aplikacji

Findy. Przedstawiono podstawowe jej za enia, specyfikacj wymaga oraz rozwi zania

techniczne u yte, aby móc zastosowa mechanizmy rekomendacji. Dodatkowo opisano

sposób pracy z aplikacj oraz jakie s mo liwo ci jej rozwoju.

W podsumowaniu przedstawiono analiz u ytych mechanizmów rekomendacji, oraz

wnioski z ich zastosowania. Omówiono ich wady i zalety w kontek cie u ycia w

praktycznej cz ci pracy oraz zakres zastosowa proponowanego rozwi zania. Na

zako czenie przedstawione zosta y przewidywane kierunki zmian w podej ciu do

problemu.

9

Rozdzia 2

Informacje podstawowe

2.1. Wzorce projektowe

2.1.1. Automatyczne uzupe nianie

Pierwszym wzorcem projektowym, który zostanie przedstawiony jest automatyczne

uzupe nianie (ang. autocomplete). Ma ono na celu u atwienie u ytkownikowi znalezienie

odpowiedniej frazy do wyszukania w jak najkrótszym czasie. Jest to mo liwe dzi ki kilku

aspektom. Pierwszym jest przewidywanie has a ju po wpisaniu pocz tkowych znaków,

dzi ki czemu u ytkownik zwolniony jest z obowi zku wpisywania ca ego zapytania, gdy

mo e wybra jedno z rekomendowanych mu przez odpowiedni algorytm. Kolejnym

udogodnieniem jest sugerowanie w czasie, gdy szukaj cy nie jest w stanie wpisa

prawid owego zapytania, gdy przyk adowo zapomnia fachowego zwrotu. W takiej

sytuacji mechanizm pomaga dobra odpowiednie wyra enie poprzez sugerowanie hase ,

których miara podobie stwa z podanym przez u ytkownika zapytaniem jest najwi ksza.

Trzecim aspektem jest podpowiadanie odpowiedniej pisowni. Przy pope nieniu b du

ortograficznego wyniki zapyta mog nie by zadowalaj ce, dlatego wy apywanie b dów

stanowi wa cz mechanizmu wyszukiwania opartego na rekomendacjach zwrotów

pozbawionych b dów.

Automatyczne uzupe nianie jest popularnym wzorcem u ywanym w Internecie

i stanowi wa sk adow wielu serwisów, mi dzy innymi jest wykorzystywane w

wyszukiwarce Google. Serwis ten gromadzi histori wyszukiwa , które by y wykonane

przez innych u ytkowników oraz udost pnia tak e mo liwo zachowywania naszych

historycznych wyszukiwa (przy w czonej opcji „Historia online”). Na podstawie

powy szych róde danych, stosowane algorytmy s w stanie przewidzie i zasugerowa

trafne zapytanie, bior c pod uwag popularno hase , które by y wyszukiwane oraz nasze

prywatne upodobania.

Niektóre serwisy rozszerzaj powy szy mechanizm o automatyczne sugerowanie

polegaj ce na proponowaniu zapyta nie zawieraj cych oryginalnych wyra

wprowadzonych przez u ytkownika, a has a podobne. Jest to mo liwe dzi ki

rozpoznawaniu wzorców zachowa . Algorytmy rozpatruj , jakie zapytania by y

10

wpisywane i modyfikowane po nieudanej próbie wyszukania has a, dzi ki czemu s w

stanie utworzy baz zwi zków logicznych, sugeruj c has a pokrewne. Taki mechanizm

jest pomocny nie tylko pocz tkuj cym u ytkownikom, którzy uzyskuj wskazówki jak

udoskonala swoje zapytania, a tak e s y wsparciem dla zaawansowanych, chc cych

wyszuka obiekty o zbli onym zagadnieniu.

Rys. 1. Automatyczne uzupe nianie w wyszukiwarce Google

Wzorzec jest u ywany na wielu platformach, nie tylko stacjonarnych. Trudno

wyobrazi sobie korzystanie z wyszukiwarki na urz dzeniach mobilnych, gdzie nie ma

mechanizmu korzystaj cego z automatycznego uzupe niania. Popularne dzi „smartfony”

ci gle borykaj si z problemem, jakim jest pisanie d szego tekstu, g ównie z powodu

ich miniaturyzacji, czy niewystarczaj cej czu ci ekranów dotykowych. Z tego powodu

projektanci ci gle usprawniaj mechanizmy rekomendacji u atwiaj cych korzystania z

takich urz dze . Dodatkow zalet automatycznego uzupe niania jest mo liwo

autonomicznego dzia ania oraz mo liwo wspó pracy z innymi wzorcami (np. z ni ej

opisanym „Najpierw najlepszy”).

2.1.2. Najpierw najlepszy

Wzorzec „Najpierw najlepszy” (ang. Best First) jest obecnie najbardziej popularnym

wzorcem wykorzystywanym w mechanizmach rekomendacji [1]. Jego za eniem jest

sugerowanie produktów czy wyników zapytania nie w kolejno ci, w jakiej zosta y

odszukane, a przedstawienie ich od najbardziej trafnego dla u ytkownika. Niektóre

heurystyki zale ne od u ytych algorytmów analizy s u ywane do oceny wyników

zebranych np. w bazie danych i te najbardziej obiecuj ce ukazuje si u ytkownikowi jako

pierwsze. Wyniki najmniej obiecuj ce algorytmy sortuj ce umieszczaj na ko cu kolejki.

11

Ma to na celu przyspieszenie ko ca procesu wyszukiwania. Korzystaj cy z serwisu dostaje

z du ym prawdopodobie stwem to, czego szuka w prosty i szybki sposób.

Ocenianie i sortowanie – g ówne cz ci sk adowe powy szego mechanizmu

rekomendacji – s ró ne, w zale no ci od serwisu w którym dzia aj . Mo na jednak

znale cech wspóln – jest ni popularno has a, b produktu. Wspomniana

popularno jest oczywi cie ró nie rozumiana w kontek cie danego serwisu. Przyk adowo,

w serwisach stworzonych do gromadzenia i udost pniania zdj cyfrowych rekomendacja

„najpierw najlepsza” odbywa si poprzez ocen b sk adow liczby ods on danego

zdj cia, komentarzy pod nim czy liczby u ytkowników, którzy dodali je do swoich

ulubionych. W serwisach aukcyjnych sortowanie i ocena mo e odbywa si przy

uwzgl dnieniu liczby sprzedanych sztuk produktu. Tak e serwis Google stosuje swój

algorytm s cy do oceniania wyników wyszukiwa – „PageRank” [2]. G ówn sk adow

oceny tego algorytmu jest liczba odno ników do danej strony. Im wi cej stron odwo a si

do czyjego serwisu, tym bardziej serwis Google b dzie go uwa za pasuj cy do u ytego

zapytania. Popularno tego rozwi zania sprawi a, e w czasach rozkwitu biznesu

internetowego, tzw. e-biznesu, zacz to handlowa wspomnianymi odno nikami. Obecnie

jednak stworzono liczne ograniczenia i obostrzenia okre laj ce, które z nich zostan

uznane za wa ne i wliczone do oceny ogólnej serwisu.

Trafno danej rekomendacji mo e by tak e uzale niona od daty. Przyk adem mog

by nie tylko serwisy informacyjne, gdzie rekomendowane s najpierw artyku y o

najpó niejszej dacie napisania, ale tak e pozosta e serwisy, dla których wa na jest

aktualno prezentowanych wyników. W takim przypadku algorytmy korzystaj ce z

wzorca „najpierw najlepszy” bior pod uwag dat dodania produktu lub dat jego

ostatniej modyfikacji, dzi ki czemu s w stanie zasugerowa najm odsze, a przez to

wie e, pierwsze wyniki wyszukiwania.

Rezultat wyszukiwania wyników zapytania pod wzgl dem trafno ci najcz ciej jest

rozk adem pot gowym, co wymusza u ycie regu y „80/20” [3]. Polega ona na tym, e

pierwsze sugerowane wyniki uzyskuj trafno rz du 80%, a pozosta e mog liczy na

uzyskanie zaledwie kilkunastu procent. U ytkownik wówczas stwierdza, czy dana

rekomendacja jest zgodna z jego wymaganiami patrz c jedynie na pocz tkowe rezultaty

odpowiedzi na jego zapytanie, a nast pnie podejmuje decyzj , czy spróbowa innego

has a, czy uzna przedstawion za wystarczaj . Dzi ki wykorzystaniu rozpoznawania

12

wzorców takich zachowa , mechanizmy rekomendacji korzystaj ce z wzorca „najpierw

najlepszy” s w stanie jeszcze trafniej zasugerowa u ytkownikowi wynik wyszukiwania,

a jednocze nie sta si bardziej uniwersalnymi.

2.1.3. Nawigacja fasetowa

Kolejnym wzorcem, z którego mog korzysta mechanizmy rekomendacji jest

nawigacja fasetowa (ang. faceted navigation), uwa ana za jedn z najwi kszych innowacji

w dziedzinie wyszukiwania i rekomendacji [4]. W wykorzystuj cych j serwisach, po

wpisaniu przez u ytkownika has a, oprócz standardowej listy wyników, wy wietlana jest

tak e lista zawieraj ca dalsze kroki, które mo e podj , np. u ycie filtrów oraz dalszy

podzia na np. kategorie czy tre ci. Taka lista zawiera „fasety” (ang. facets) stanowi ce

najwa niejsz cz nawigacji. Charakterystyczn cech tego wzorca, jest to, e nie jest do

ko ca transparentny dla u ywaj cego, który musi kierowa mechanizmem, a do

wystarczaj cego zaw enia wyników.

Rys. 2. Nawigacja fasetowa w serwisie aukcyjnym Allegro

ytkownik z pomoc faset ma mo liwo wyselekcjonowania tre ci o cechach

wspólnych. Nak adaj c kolejne fasety ograniczana jest lista wyników, pozostawiaj c te

najodpowiedniejsze. Czynno ta jest pomocna przy ch ci znalezienia np. przedmiotu z

du ej kolekcji. Przyk adem takiego rozwi zania jest serwis aukcyjny Allegro

przedstawiony na rys. 2. Po wpisaniu has a „Pan Tadeusz” ukazuje nam si lista wyników

13

oraz fasety: po lewej stronie, gdzie mo emy wybra kategori , w której chcemy szuka

pozycji oraz na górze, gdzie mamy mo liwo zastosowania filtrów co do ceny czy

lokalizacji. Dobieraj c fasety odnajdujemy pozycje maj ce cz ci wspólne z

zasugerowanymi warto ciami.

Istotn w ciwo ci nawigacji fasetowej jest to, e ukazywane s u ytkownikowi

tylko te fasety, które s uwa ane przez mechanizmy rekomenduj ce za trafne. Pozosta e s

domy lnie zamkni te. Gdy rekomendacja faset oka e si niewystarczaj ca, szukaj cy ma

mo liwo przejrzenia tak e tych pocz tkowo ukrytych. Algorytmy weryfikuj ce wzorce

zachowania korzystaj c z takich dzia aktualizuj swoje oceny trafno ci, podobnie jak

odbywa si to w przypadku wzorca „najpierw najlepszy”.

Rekomendacja faset jest dziedzin ci gle rozwijan , a przy tym potrzebn

i przysz ciow . Im trafniej odb dzie si ich zasugerowanie u ytkownikowi, tym szybciej

zako czy si proces wyszukiwania, do czego d projektanci. Wzorzec znajduje nie tylko

zastosowanie na platformach stacjonarnych. Coraz cz ciej wyst puj kolejne próby

przeniesienia go na platformy mobilne [5]. Jak ju wspomniano, urz dzenia mobilne

charakteryzuj si ma ymi rozmiarami, przez co przeniesienie wzorca np. ze znanych

serwisów aukcyjnych nie jest mo liwe, dlatego stanowi to problem wci do rozwi zania.

2.1.4. Personalizacja

Personalizacja w portalach internetowych jest stosowana od wielu lat. Pocz tkowo

opiera a si jedynie na mo liwo ci dostosowania serwisu do swoich potrzeb, g ównie

wizualnych. U ytkownik mia udost pniony interfejs, z którego móg wybra kolor t a, typ

ikon, czy u enie okien i paneli. Wraz z rozwojem technologii internetowych, powy sze

udogodnienia zosta y rozszerzone o wybór rodzaju prezentowanych tre ci. Wówczas na

przestrzeni np. artyku ów odbywa a si filtracja, czego rezultatem by o wy wietlenie tylko

tych tematów, na które zdecydowa si wybieraj cy. W obecnych czasach i przy obecnej

szybko ci rozwoju techniki, nawet takie u atwienia przesta y by zadowalaj ce.

Obecnie nacisk k adziony jest na serwisy, które umo liwiaj rekomendacje tre ci, bez

przymusowych ustawie realizowanych podczas u ytkowania z serwisu. Niezb dne s do

tego zaawansowane mechanizmy b ce w stanie przetworzy np. histori wyszukiwa

ytkowników z serwisu albo ich wzorce zachowa . Obserwowanie operacji

wykonywanych przez u ytkownika mo e dostarczy niezb dnych informacji o jego

upodobaniach i rutynowych czynno ciach, które mog by podstaw zaawansowanej

14

personalizacji. Stworzenie na takiej podstawie profilu u ytkuj cego serwis, pozwoli

algorytmom dostosowa wygl d i zaprezentowa tre zgodnie z indywidualnymi

preferencjami, potrzebami i zainteresowaniami.

ycie odpowiedniego mechanizmu rekomendacji w powy szym wzorcu uzale nione

jest od charakteru serwisu. Mo liwe jest wyznaczenie trzech g ównych rodzajów

personalizacji i sposobów tworzenia profilu osoby korzystaj cej z serwisu. Najbardziej

podstawowym jest personalizacja o zasi gu indywidualnym. W takim przypadku istotne

jest zbieranie wszelkich informacji pozostawianych przez u ytkownika podczas swoich

dzia . Wówczas, weryfikuj c ró ne przypadki jego interakcji z serwisem, algorytmy

rekomenduj ce tre ci s w stanie przedstawi wyniki, które mo na uzna za

najodpowiedniejsze. Przyk adem takiego dzia ania jest ponowne u ycie tego samego

zapytania. Znaj c wzorzec zachowania u ytkownika przy jego pierwszej decyzji, mo na

uzna j za najtrafniejsz tak e i w tym przypadku, dlatego algorytmy analizuj ce proces

personalizacji wybior j , jako rekomendowan z najwi kszym prawdopodobie stwem.

Kolejnym aspektem jest personalizacja o zasi gu spo eczno ciowym. Wykorzystuje

si j , gdy indywidualne tworzenie profilu u ytkownika i analiza jego wzorców zachowa

mo e ulec zniekszta ceniu. Takie ryzyko mo e wyst pi przyk adowo w serwisach

aukcyjnych. Korzystaj cy z nich nie zawsze musi licytowa i kupowa produkty dla siebie,

dlatego algorytmy rekomenduj ce przetwarzaj ce takie zachowanie mog okaza si

myl ce. Podobny problem wyst puje w przewidywaniu, które produkty mog nas

zainteresowa w przysz ci. Wówczas niezb dne jest tworzenie profilu z uwzgl dnieniem

dzia naszego najbli szego otoczenia. Obecnie dzia a wiele serwisów

spo eczno ciowych analizuj cych blisko relacji u ytkowników, mi dzy innymi

LinkedIn. Taka wiedza mo e pozwoli udoskonala mechanizmy rekomendacji

sprawiaj c, e b w stanie proponowa tre ci, które zainteresowa y ju najbli szych

znajomych osoby korzystaj cej z serwisu, dlatego z du ym prawdopodobie stwem

zainteresuj tak e i jego. Analiza preferencji i zainteresowa najbli szej spo eczno ci w

serwisie tematycznym mo e u atwi sugerowanie najpopularniejszych zjawisk, a tak e

ukazywa mod , która aktualnie wyst puje.

Powy sza analiza mo e si jednak okaza niewystarczaj ca. W przypadku

wyszukiwania np. artyku ów naukowych o zaawansowanej tre ci, ich rekomendacja oparta

na obserwacjach otoczenia u ytkownika sk adaj cego si w wi kszo ci z nastolatków,

15

mo e okaza si nieskuteczna. Dlatego istniej sytuacje, gdzie niezb dna jest

personalizacja o zasi gu globalnym. Ma ona zastosowanie g ównie, gdy trafno

rekomendowanych tre ci zale y od szerokich statystyk. Wnioski wyci gane przez

algorytmy podczas analizy zachowa szerokiej spo eczno ci, np. z ró nych kontynentów,

mog by wolne od stereotypów czy tzw. chwilowej mody.

Innym wa nym elementem personalizacji, oprócz rozpatrywania zasi gu dzia ania,

jest tak e rozró nianie kontekstu u ycia. Wówczas mechanizmy rekomenduj ce musz

rozpozna intencje u ytkownika. Przyk adem takiego dzia ania jest rozró nienie platformy,

na której wykonywane jest zapytanie. Czym innym b dzie spowodowane wyszukanie np.

has a „kuchnia w oska” przez korzystaj cych z komputera stacjonarnego (prawdopodobnie

chodzi mo e o wyszukanie przepisów kucharskich), a czym innym przez u ywaj cych

urz dzenia mobilne (ch znalezienia najbli szej restauracji).

Przedstawiony wzorzec personalizacji jest zaawansowanym narz dziem w r kach

projektantów. U ywane w nim algorytmy rekomendacji nazywane s „opartymi na

analizie u ytkowników” (ang. user-based), którego przyk adem b dzie opisana w dalszej

cz ci pracy wspólna filtracja (ang. Collaborative Filtering). Dostarczaj one cennych

wniosków i przyk adów, które mog by stosowane tak e w innych wzorcach, mi dzy

innymi w tych wcze niej opisanych. Serwisy u ywaj ce takiego mechanizmu staj si wi c

na tyle inteligentne, e z du swobod i trafno ci potrafi sugerowa u ytkownikom

najlepszy wybór w danej sytuacji.

2.2. Metody tworzenia profili u ytkownika Systemy rekomendacyjne to specjalny typ systemów filtruj cych dane. Musz one

mierzy si z du przestrzeni informacji, z której wyszukuj najbardziej interesuj ce

i u yteczne rzeczy dla u ytkownika bazuj c na zdobytych danych. Podstawowym

narz dziem dla mechanizmów rekomenduj cych s profile sk adaj ce si z cech lub

atrybutów. Formalnie, ka dy profil jest opisany wektorem = ( , , … , ), gdzie

oznacza pewn cech lub atrybut danego profilu, a oznacza d ugo wektora [7].

W systemach rekomenduj cych stosuje si wiele koncepcji profilowania. Najbardziej

podstawowym profilem u ytkownika jest profil sk adaj cy si z wektora atrybutów

okre laj cych ocen przedmiotów dost pnych w serwisie. Ka da ocena przedmiotu mo e

sk ada si z konkretnej warto ci liczbowej, np. z przedzia u od 1 do 6, albo by ocen

niejawn okre laj fakt dodania przedmiotu do ulubionych czy najcz ciej ogl danych.

16

Istnieje tak e mo liwo , e ocena jest pusta, co mo e by oznaczone warto ci specjaln ,

rozpoznawan przez mechanizmy korzystaj ce z powy szego profilu. Oprócz ocen, wektor

ten mo e zawiera dodatkowo warto ci wag. Przyk adem mo e by waga b ca

odwrotno ci cz sto ci oceniania danego produktu [8]. Dzi ki zastosowaniu takiej

koncepcji mo liwe jest zwi kszenie priorytetu rzadko ocenianych produktów, przez co

mechanizmy rekomendacji maj szans sugerowa tak e takie obiekty. W powy szych

przyk adach wszelkie informacje dotycz ce u ytkowników i ich ocen reprezentowane s

macierz o wymiarach na , gdzie okre la liczb przedmiotów w serwisie, a

liczb go u ytkuj cych. Ka da warto macierzy - , , okre la ocen -tego u ytkownika,

która dotyczy -tego przedmiotu.

Inn jest koncepcja, w której profil u ytkownika sk ada si nie z jednego wektora, w

którym znajduj si oceny wszystkich przedmiotów, a z listy przedmiotów, gdzie ka dy

przedmiot jest tak e okre lony pewnym osobnym profilem, b cym wektorem w pewnej

przestrzeni cech. Dana cecha mo e okre la nie tylko ocen , ale mo e by dowolnym

atrybutem takim jak tytu dla ksi ki, czy re yser dla filmu. Przedmioty s uto samiane z

profilem u ytkownika w momencie jego oceny albo gdy zostan uznane przez

mechanizmy weryfikacji wzorca zachowa za preferowane.

Aby móc stworzy profile omawiane powy ej, potrzebne jest u ycie metod, dzi ki

którym mo liwe b dzie zebranie informacji. Informacje te b sk adowymi wektora cech

w profilu. Istniej dwa podej cia, które s najcz ciej wykorzystywane:

podej cie aktywne,

podej cie pasywne.

2.2.1. Podej cie aktywne

Pierwsz metod zbierania informacji o u ytkowniku jest profilowanie aktywne,

inaczej jawne (ang. explicit profile). Sposób ten opiera si na informacjach uzyskanych

bezpo rednio od u ytkownika, które s nast pnie przechowywane w jego profilu

i wykorzystywane przez mechanizmy rekomendacji. Przyk adem takiego wydobywania

wiedzy jest ankietowanie, gdzie u ytkuj cy serwis udziela odpowiedzi na pytania, które s

przetwarzane tak, aby mo na by o je zapisa w pewnym wektorze cech u ytkownika.

Obecnie taki sposób nie spotyka si z uznaniem internautów, gdy uwa any jest za

irytuj cy, przez co ankiety s niech tnie wype niane.

17

Powy szy sposób jest coraz rzadziej spotykany, gdy stosuje si inne, bardziej

przyjazne i mniej k opotliwe dla u ytkuj cych serwis. Takim przyk adem jest

zastosowanie mechanizmu oceniania. Spotykany jest na przyk ad w serwisach

po wi conym filmom, czy ksi kom, gdzie ka demu tytu owi u ytkownik mo e

przydzieli w asn ocen w pewnej z góry ustalonej skali liczbowej. Dzi ki temu

pomys owi mechanizmy rekomendacji mog w prosty sposób, korzystaj c z profilu, gdzie

zawiera si lista ocen, zasugerowa tytu y podobne do tych najbardziej lubianych

i preferowanych. Podobnym wyj ciem jest umo liwienie dodawania przedmiotów do

ulubionych, czy nawet do nielubianych. W ten sposób mechanizm rekomendacji mo e

stwierdzi , jakie przedmioty mog sta si interesuj ce dla u ytkownika, a jakie wr cz

przeciwnie.

Omówione przyk ady dostarczaj informacji o u ytkowniku, które sam przeka e lub

udost pni, dlatego odzwierciedlenie jego profilu staje si subiektywne, a nawet niekiedy

nieprawdziwe. Nie zawsze uda si otrzyma pe gam odpowiedzi, które najpe niej

oddadz obraz profilu. Mo e wyst pi sytuacja, e u ytkownik celowo b dzie odpowiada

niezgodnie z w asnym gustem, znu ony d ug list pyta czy d ugim procesem

ankietowania, dlatego przy profilowaniu jawnym wyst puje trudno przy zdobywaniu

wi kszej ilo ci informacji.

2.2.2. Podej cie pasywne

Nast pn metod umo liwiaj stworzenie profilu u ytkownika jest profilowanie

pasywne, inaczej domniemane (ang. implicit profile). W podej ciu pasywnym zbieraniem

informacji zajmuje si system, który obserwuje dzia ania i weryfikuje wzorce zachowa

ytkownika, a nast pnie udoskonala i aktualizuje jego profil. Serwisy korzystaj ce z

takiego podej cia nie bazuj na opinii u ytkuj cego ani nie oczekuj udzielania

odpowiedzi na zadawane pytania czy samodzielnego dostarczania informacji. Skupiaj si

na analizie czasu, który jest po wi cany na czytanie o danym produkcie oraz na analizie

cech przedmiotów, które s najcz ciej ogl dane.

Wa nym narz dziem powy szego podej cia jest prowadzenie archiwum, w którym

system b dzie przechowywa ostatnio ogl dane, zamawiane czy kupowane przedmioty.

Ma to na celu zgromadzenie pe nego spektrum informacji o zachowaniach u ytkownika.

Maj c takie dane mo liwe jest stworzenie profilu, który ma szanse by obrazem

rzeczywistej dzia alno ci u ytkownika w systemie. Taki profil stanowi podstaw dzia ania

18

mechanizmów rekomendacji, które mog z du ym prawdopodobie stwem sugerowa

przedmioty najlepiej pasuj ce do ju kupionych czy najcz ciej analizowanych przez

ytkownika. Daje to mo liwo ukazania produktów równie interesuj cych, a tak e

poszerzenia kr gu zainteresowa .

W przeciwie stwie do podej cia aktywnego, profilowanie pasywne jest niewidoczne

dla u ytkownika. Takie dzia anie umo liwia zebranie du ej ilo ci informacji o

ytkowniku bez wymuszania na nim konkretnych akcji, a tak e bez wy ej wspomnianych

negatywnych emocji wspomnianych. Wad takiego rozwi zania mo e by niew ciwie

tworzenie profilu podczas analizowania archiwum zakupionych przedmiotów. Ma to

miejsce w sytuacji, gdy u ytkownik dokonuje zakupów nie dla siebie, a np. na prezent dla

znajomego. W takich przypadkach nie zawsze pasywna metoda zdobywania informacji

mo e pozna faktyczne opinie czy cele u ytkownika.

2.3. Podsumowanie Dzisiejszy post p techniczny sprawia, e mechanizmy rekomendacji staj si coraz

bardziej zaawansowane, przez co dok adniejsze i bardziej pomocne. Efektywno

przedstawianych wzorców powoduje, e znajduj zastosowanie w wi kszo ci serwisów

przynosz cych dochody. Wida to mi dzy innymi w sklepach on-line, czy serwisach

aukcyjnych, gdzie wyst puj elementy, podpisane jako „Zobacz tak e”, „Produkty

powi zane”, czy „ ytkownicy, którzy kupili ten produkt, kupili tak e…”, podpowiadaj ce

ytkownikom, jakie produkty s najbli sze im zainteresowaniom czy potrzebom. Takie

wykorzystanie personalizacji spowodowa o, e 35% dochodów serwisu Amazon [6],

pochodzi w nie z takiego typu rekomendacji.

W opozycji do powy szego przyk adu stoi wykorzystanie rekomendacji jedynie w

celach marketingowych, nie analizuj ce np. wzorców zachowa . Wówczas reklamowanie

produktów wiadczy o preferencjach sprzedawcy, a nie o potrzebach klienta. Jednak takie

przypadki s w mniejszo ci. Obecnie w cicielom znanych serwisów powi zanych z

e-biznesem zale y na innowacyjno ci i stosowane mechanizmy potrafi automatycznie

dobra ofert produktow dla konsumenta wykorzystuj c jego profil stworzony na

podstawie jego dzia podczas u ytkowania serwisu.

19

Rozdzia 3

Systemy rekomendacji

3.1. Idea systemów rekomendacji Wraz ze wzrostem popularno ci Internetu ros y tak e wymagania jego u ytkowników.

Jak wspomniano wcze niej, mo liwo samodzielnego dostosowania portalu do swoich

potrzeb czy w asnor cznego przeszukiwania spo eczno ci w celu znalezienia

odpowiedniej, pasuj cej do zainteresowa , przesta a by interesuj ca. Zapotrzebowanie

rozwijaj cego si rynku sprawi o, e wypracowana zosta a nowocze niejsza koncepcja,

która ma na celu zwolnienie u ytkuj cego portal od samodzielnych ustawie . Jej celem

jest prezentowanie tre ci ca kowicie spersonalizowanej, czyli dostosowanej do aktualnych

potrzeb, preferencji i zainteresowa u ytkownika. Systemy oferuj ce tak funkcjonalno

nosz nazw systemów rekomendacji. U ywaj one mechanizmów zwracania uwagi

ytkowników na odpowiednie produkty oraz powoduj cych wzrost zadowolenia

korzystaj cego.

Mechanizmy rekomendacji mog by wykorzystywane w serwisach o charakterze

non-profit [9], dzia aj cych nie dla osi gania zysku, lecz w wi kszo ci przypadków

wykorzystywane s w serwisach komercyjnych. W takich miejscach, dzi ki analizie

danych u ytkownika i wydobywaniu najprzydatniejszych informacji, mo liwe s

prognozy, co najlepiej trafi w gusta klienta, co jest w stanie zapewni , jak wspominano na

przyk adzie Amazon, wzrost wp ywów ze sprzeda y.

Systemy rekomendacji projektowane s tak, aby mierzy si z problemem wyszukania

przedmiotów o jak najwi kszej warto ci funkcji przydatno ci ka demu z u ytkowników w

jak najkrótszym czasie (1).

, = max ( , ) (1) gdzie:

– zbiór wszystkich u ytkowników serwisu,

– zbiór wszystkich rekomendowanych obiektów w serwisie,

× – funkcja przydatno ci przedmiotu dla u ytkownika .

20

W powy szym celu wykorzystywane s techniki analityczne, okre laj ce podobie stwo

mi dzy elementami przestrzeni danych. Mo emy je podzieli na trzy podej cia:

Content-based Filtering – podej cie zapewniaj ce rekomendacje oparte na

analizie i dopasowywaniu cech produktów do indywidualnych preferencji

ytkownika,

Collaborative Filtering – podej cie zapewniaj ce rekomendacje oparte na

preferencjach podobnych u ytkowników,

Podej cie hybrydowe – koncepcja cz ca obie powy sze metody.

3.2. Content-based Filtering Pierwsz technik rekomendacyjn jest filtrowanie z analiz zawarto ci (ang. Content-

based Filtering), które sugeruje produkty na podstawie podobie stwa ich cech z profilem

ytkownika. Uwzgl dniaj c jego upodobania filtrowanie z analiz zawarto ci wyszukuje

pozycje podobne bazuj c na analizowaniu atrybutów specyficznych dla danego systemu.

Przyk adem mo e by wypo yczalnia filmów, gdzie polecane s klientowi filmy z

udzia em jego ulubionego aktora, b filmy re ysera, którego ceni najbardziej. W takim

przypadku wspomnianym atrybutem b dzie aktor lub re yser. Innym przyk adem s

ksi garnie, które poleca b ksi ki z gatunku najcz ciej czytanego przez u ytkownika

ksi ki zawieraj cej w tytule s owa, pojawiaj ce si najcz ciej w innych pozycjach

wybranych przez klienta. Analogicznie serwisy informacyjne d ce do rekomendowania

artyku ów o tre ci najbardziej podobnej do artyku ów, wybieranych przez u ytkuj cego.

W powy szym podej ciu, oprócz stworzenia profilu u ytkownika, niezb dne jest

stworzenie profilu dla ka dego produktu znajduj cego si w bazie serwisu. Taki profil,

podobnie jak profil u ytkownika, b dzie stanowi wektor w przestrzeni cech b

atrybutów, o których pisano wy ej. Nast pnym etapem jest wybranie tych produktów,

których wektor cech jest najbardziej podobny do wektora u ytkownika. Miar takiego

podobie stwa mo na wyliczy na wiele sposobów.

Pierwszym ze sposobów jest wykorzystanie odleg ci euklidesowej pomi dzy dwoma

punktami o wspó rz dnych okre lonych przez wektory cech (2).

21

( , ) = ( ) + ( ) + … + ( )

( , ) = (( ) )

(2)

gdzie:

– wspó rz dne wektora cech u ytkownika,

– wspó rz dne wektora cech obiektu rekomendowanego,

( , ) – odleg euklidesowa mi dzy dwoma punktami,

– liczba obiektów w serwisie.

Odleg euklidesowa jest równa d ugo ci odcinka cz cego punkty i , dlatego im

mniejsza warto ( , ), tym aktywny obiekt bardziej pasuje do u ytkownika. Przyj o

si jednak, e porównywane dwa profile s tym do siebie bardziej podobne, im miara ich

podobie stwa jest wi ksza, dlatego dodatkowo stosuje si normalizacj (3).

( , ) =1

1 + ( , ) (3)

gdzie:

( , ) – znormalizowana miara podobie stwa.

Po jej zastosowaniu miara podobie stwa zawiera si b dzie w przedziale (0, 1

sprawiaj c, e rozpatrywanie trafno ci danego porównania b dzie wygodniejsze.

Innym sposobem mierzenia podobie stwa jest odleg Hamminga, która okre la

ró nic mi dzy dwoma ci gami o takiej samej d ugo ci. Wynikiem jest liczba miejsc, na

których wyst puj odmienne warto ci, czyli najmniejsza liczba zmian, któr nale y

przeprowadzi , aby zmieni jeden ci g na drugi. Przyk adowo maj c wektor cech

ytkownika = (1, 0, 0, 7, 0, 2) i wektor cech przedmiotu = (1, 1, 0, 5, 0, 2), odleg

Hamminga mi dzy nimi wynosi ( , ) = 2, gdy oba ci gi ró ni si na dwóch

pozycjach. Powy sza metryka dostarcza w takim przypadku informacji o odmienno ci

dwóch wektorów. Im odleg jest mniejsza, tym bardziej wektory s podobne, tym

samym profile je zawieraj ce mo na uzna za s siednie. Ma ona g ównie zastosowanie w

przypadku u ywania warto ci binarnych. W pozosta ych przypadkach mo e okaza si

bardzo nieskuteczn , gdy odrzuca warto ci ró ne, a niekiedy w rekomendacji mog si

okaza spokrewnione, przez co istotne przy ewentualnym sugerowaniu u ytkownikowi.

22

Najpopularniejszym sposobem w mechanizmach rekomendacji do oceniania

przedmiotów, czy s najbardziej pasuj ce do profilu u ytkownika, jest odleg

kosinusowa (4). Miara ta jest wykorzystywana mi dzy innymi w serwisie Amazon [9].

( , ) = cos( , ) =

°| | | |

( , ) =+ + … + + + + … +

(4)

gdzie:

– wspó rz dne wektora cech u ytkownika,

– wspó rz dne wektora cech obiektu rekomendowanego,

( ) – odleg kosinusowa mi dzy dwoma punktami,

– liczba obiektów w serwisie.

Odleg kosinusowa jest zdefiniowana, jako znormalizowany iloczyn skalarny dwóch

wektorów, a estymacja ich podobie stwa odbywa si poprzez obliczenie kosinusa k ta

pomi dzy nimi.

Rys. 3. Idea odleg ci kosinusowej

23

Prezentowany powy ej rys. 3. ukazuje ide odleg ci kosinusowej. Dane s trzy cechy ,

i , oraz 4 profile reprezentowane przez wektory cech , , i . Je eli k t

pomi dzy wektorami albo k t pomi dzy wektorami zmierza do 0,

wówczas kosinus tego k ta d y do 1. Takie profile le w bliskim s siedztwie, dlatego

mog by uwa ane za podobne. Porównuj c tak profil u ytkownika z profilem produktu

mo na stwierdzi , czy dany produkt mo e by obiektem rekomendowanym.

System rekomendacji w pocz tkowej fazie stosuje wybran metryk , która okre la

miar podobie stwa pomi dzy produktami a profilem u ytkownika. Z grupy wybranych

produktów najbardziej podobnych usuwane s pozycje, które u ytkownik ju zna i by y

przez niego ju analizowane. Powsta y w ten sposób zbiór produktów stanowi list

rekomendacji, któr mo na przedstawi u ytkownikowi jako najbardziej zgodn z jego

preferencjami. Je eli powy sza lista zawiera wi cej pozycji ni zmie ci si w miejscu na

rekomendacje, to mo e zosta posortowana np. od najwcze niej dodanych i wy wietlona w

formie najlepszych (ang. Top-N recommendation). Schemat dzia ania takiego systemu

opartego o filtrowanie z analiz zawarto ci przedstawiono na rys. 4.

Rys. 4. Schemat dzia ania systemu rekomendacji opartej na Content-based Filtering ród o: opracowanie w asne na podstawie: [7]

Wad powy szej techniki rekomendacji jest opieranie si jedynie na profilu

ytkownika, przez co istnieje du e ryzyko oszukania systemu oraz, e rekomendowane

produkty bardzo podobne do siebie. Oprócz tego, filtrowanie z analiz zawarto ci

niesie ze sob konieczno reprezentacji przedmiotu w formie, któr b dzie w stanie

24

zanalizowa system komputerowy. Przyk adowo istnieje niemo no rekomendacji

muzyki, czy obrazów, gdy problemem jest zdefiniowanie ich cech i atrybutów.

3.3. Collaborative Filtering Drugim podej ciem stosowanym w systemach rekomendacyjnych jest tzw. wspólna

filtracja (ang. Collaborative Filtering). Opiera si ona na za eniu, e je eli dwóch

ytkowników lubi podobne produkty lub ma podobne preferencje, to z du ym

prawdopodobie stwem b podobnie zachowywa si w odniesieniu do innych rzeczy.

Przyk adem mo e by ksi garnia internetowa, w której u ytkownik i ocenili ksi ek

podobnie, ale u ytkownik dodatkowo oceni w pozytywny sposób inna ksi . W takiej

sytuacji, mechanizm wspólnej filtracji zarekomenduje t ksi u ytkownikowi ,

zak adaj c, e i jemu przypadnie do gustu. W powy szej sytuacji nie polegamy na cechach

czy atrybutach danego produktu, jak to mia o miejsce w przypadku filtrowania z analiz

zawarto ci, a opieramy si na opinii osób, których zainteresowania i preferencje uznajemy

za podobne.

Mechanizmy rekomendacji oparte o wspóln filtracj u ywaj algorytmów, które

dziel si na dwie kategorie:

metody wykorzystuj ce pami (Memory-based Collaborative Filtering),

metody wykorzystuj ce model (Model-based Collaborative Filtering).

Ich charakterystyk zaprezentowano w poni szych rozdzia ach.

3.3.1. Metody wykorzystuj ce pami (Memory-based)

Pierwsz kategori algorytmów s mechanizmy wykorzystuj ce pami .

Charakteryzuj si one tym, e do przeprowadzenia rekomendacji u ywa ca ej bazy

danych serwisu. Zak adaj , e ka dy u ytkownik jest cz ci pewnej grupy, dlatego

ywaj metod statystycznych do znalezienia tzw. „najbli szych s siadów”, czyli grupy

ytkowników o podobnych zainteresowaniach.

W pierwszym kroku mechanizm rekomendacji tego typu wyszukuje grup

najbli szych s siadów poprzez obliczenie wagi , , która okre la podobie stwo lub

korelacj pomi dzy dwoma u ytkownikami: i . Nast pnie obliczana jest prognoza

okre laj ca, czy dany produkt mo e by polecony u ytkownikowi w oparciu o jego

25

najbli szych s siadów. Ostatnim krokiem jest wybór obiektów najbardziej pasuj cych do

ytkownika i przedstawienie ich w postaci rekomendacji.

Obliczanie podobie stwa pomi dzy u ytkownikami, który ocenili te same produkty,

dodali takie same do ulubionych, czy obserwowanych, jest kluczowym krokiem

mechanizmu rekomendacji. Do tego celu mo e by u yta np. odleg kosinusowa (4),

lecz najbardziej rozpowszechnion miar podobie stwa w systemach rekomenduj cych

jest korelacja Pearsona [10], któr zapisuje si wzorem (5).

, = , ,

, ,

(5)

gdzie:

, – korelacja Pearsona pomi dzy u ytkownikiem i ,

, – porównywani u ytkownicy,

– zbiór obiektów, które zosta y ocenione przez obu u ytkowników,

, – ocena -tego przedmiotu przez u ytkownika ,

, ,

– rednia ocen u ytkownika ,

, – ocena -tego przedmiotu przez u ytkownika ,

, ,

– rednia ocen u ytkownika .

Aby wyró ni u ytkowników najbardziej podobnych stosuje si dodatkowo

normalizacj (6).

, = , , (6)

gdzie:

, – znormalizowana korelacja Pearsona pomi dzy u ytkownikiem i ,

, – korelacja Pearsona pomi dzy u ytkownikiem i

– moc normalizacji,

1.

W powy szym równaniu parametr okre la jak bardzo ma by podkre lona ró nica

mi dzy wysokim a niskim wynikiem korelacji Pearsona. Typowo w mechanizmach

26

rekomendacji parametr wynosi 2,51. Przyk adowo dzia anie normalizacji sprawi, e w

przypadku korelacji , = 2, mechanizm otrzyma , 5,6. W przypadku korelacji

, = 0,2, otrzyma , 0,018, sprawiaj c, e stanie si wyra nie nieistotn

i pomijaln .

Maj c obliczone korelacje pomi dzy u ytkownikami mo liwe jest utworzenie

najbli szego s siedztwa u ytkownika. Im korelacja jest wi ksza, tym bardziej

porównywani u ytkownicy s do siebie podobni, czyli stanowi bli sze s siedztwo.

Kolejn czynno ci , kiedy grupa najbli szych s siadów zosta a znaleziona, jest obliczenie

prognozy rekomendacji na podstawie ocenionych, b wybranych przez nich

przedmiotów, których jednocze nie nie zna dany u ytkownik. Prognoza pozwala

stwierdzi jak bardzo dany przedmiot pasuje do u ytkownika, który go nie oceni , ani nie

analizowa . Obliczana jest na podstawie poni szego wzoru (7).

, = +

( . ) ,

,

(7)

gdzie:

, – wa ona suma ocen innych u ytkowników przedmiotu liczona dla

ytkownika ,

– zbiór u ytkowników, którzy ocenili przedmiot ,

– rednia wszystkich pozosta ych ocen u ytkownika ,

– rednia wszystkich pozosta ych ocen u ytkownika ,

, – korelacja Pearsona pomi dzy u ytkownikiem i .

W ko cowym etapie, mechanizm rekomendacji, maj c obliczone prognozy, mo e

stwierdzi , które przedmioty najbardziej pasuj do danego u ytkownika. Maj c tak list

mo liwe jest zaprezentowanie u ytkownikowi wszystkich propozycji, b konkretnych,

np. w formie najlepszych.

Zalet omówionego wy ej sposobu jest to, e nie musi si opiera na analizie

konkretnych cech produktów. Jego dzia anie jest mo liwe dla dowolnego typu obiektu.

Dodawanie nowych danych nie przynosi dodatkowych trudno ci w dzia aniu powy szych

algorytmów, lecz przy du ych zbiorach danych powy szy mechanizm mo e mie

ograniczon skalowalno , co omówiono w rozdziale 3.4.2. Dodatkowo, gdy danym

1 D. Lemire, “Scale and translation invariant collaborative filtering systems”, 2005, str. 129–150

27

ytkownikiem jest u ytkownik nowo dodany, wyst puje problem braku informacji w jego

profilu o preferencjach. Rozwi zaniem tego problemu mo e by dodatkowe zastosowanie

danych demograficznych przy wyszukiwaniu korelacji, co zosta o omówione w rozdziale

3.4.1. Najkosztowniejszym elementem mechanizmów wykorzystuj cych pami jest

znajdowanie u ytkowników najbardziej podobnych, czyli wyszukiwanie najbli szego

siedztwa. Alternatyw dla tego kroku mo e by u ycie grupowania, co zosta o szerzej

opisane w rozdziale 3.4.2.

3.3.2. Metody wykorzystuj ce model (Model-based)

Drug kategori algorytmów wykorzystywanych we wspólnej filtracji s algorytmy

wykorzystuj ce model. Podstaw ich dzia ania jest utworzenie modelu ocen u ytkownika,

który b dzie w stanie przewidzie jego ocen dotycz przedmiotów. Podczas tworzenia

modelu wykorzystywane s techniki uczenia maszynowego na podstawie danych

treningowych.

Jednym ze sposobów oszacowania rekomendacji przedmiotu dla danego u ytkownika

jest u ycie naiwnego klasyfikatora bayesowskiego, który jest najcz ciej stosowany w

serwisach rekomendacyjnych [11]. Stanowi on jedn z metod uczenia maszynowego

okre laj , do której z klas decyzyjnych nale y przypisa nowy przypadek. W kontek cie

mechanizmów rekomendacji okre la b dzie, jak bardzo wybrany produkt b dzie trafny

dla danego u ytkownika.

Proces budowania modelu mo e wykorzystywa tak e inne techniki uczenia

maszynowego, lecz nie s one tak popularne, jak klasyfikator bayesowski. W

mechanizmach rekomendacji spotyka si jeszcze metod regu asocjacyjnych. Podej cie to

wykorzystuje algorytmy odkrywaj ce regu y asocjacyjne pomi dzy przedmiotami a

ytkownikami. Znalezione asocjacje s do okre lania si y powi zania pomi dzy

przedmiotem, a danym u ytkownikiem. W ko cowym etapie zbierane s najsilniejsze

asocjacje i prezentowane jako lista rekomendacji.

Przy stosowaniu powy szego mechanizmu nie wyst puje problem rzadko ci danych

i skalowalno ci (patrz ni ej), lecz jego implementacja jest du o bardziej k opotliwa i

skomplikowana, ni w przypadku mechanizmu wykorzystuj cego pami . Z tego powodu

bardzo rzadko stosuje si podej cie modelowe. Oprócz tego, u ycie redukcji

wielowymiarowych zada np. przy naiwnym klasyfikatorze bayesowskim mo e

spowodowa utrat informacji i pogorszy wyniki rekomendacji.

28

3.4. ówne problemy przy stosowaniu mechanizmów rekomendacji

3.4.1. Rzadko danych

Mechanizmy rekomendacji musz mierzy si z wieloma problemami. Pierwszym jest

rzadko danych. Pojawia si on, gdy dodawany jest nowy u ytkownik lub nowy produkt.

W takiej sytuacji system mo e nie mie wystarczaj co du o informacji, eby by w stanie

poprawnie wykona rekomendacj , gdy nie s znane preferencje takiego u ytkownika czy

jego historia dzia . Podobnie jest z nowo dodanym produktem, który, dopóki nie

zostanie oceniony, dodany do ulubionych, czy dodany do obserwowanych, nie mo e by

prawid owo rozpatrzony przez mechanizm filtrowania. Problem te nazywany jest

problemem „zimnego startu” (ang. cold start).

Zimny start nie stanowi problemu dla mechanizmów filtrowania z analiz zawarto ci,

gdy ich dzia anie opiera si na rekomendacji produktów podobnych do ju

obserwowanych i mo e by pomocne w momencie, gdy nie zosta y zebrane wystarczaj ce

informacje, by u mechanizmu wspólnej filtracji. Ta my l pos a do zbudowania

grupy algorytmów hybrydowych, wykorzystuj cych obie kategorie mechanizmów. Ich

charakterystyka opisana jest w rozdziale 3.5.

Jak wspomniano, problem rzadko ci danych stanowi du przeszkod w dzia aniu

mechanizmów wspólnej filtracji. Innym rozwi zaniem tego problemu, obok podej cia

hybrydowego, jest dodatkowe zastosowanie danych demograficznych w profilach

ytkowników. W sytuacji, gdy dany u ytkownik nie ma ocenionych produktów i nie

mo na zastosowa korelacji Pearsona (5), wówczas tworzony jest dodatkowy wektor.

Wektor ten sk ada si z atrybutów powsta ych podczas weryfikacji cech demograficznych.

Przyk adowe cechy zosta y przedstawione w Tabeli 1.

Tabela 1 Struktura wektora demograficznego

cecha przynale no do cechy komentarz 1 wiek 15 je li dany u ytkownik przynale y

do wybranej cechy, wówczas dany atrybut wektora przyjmuje

warto 1, a w pozosta ych przypadkach 0.

2 15 < wiek 20 3 20 < wiek 30 4 30 < wiek 45 5 wiek > 45 6 == m czyzna 7 == kobieta

29

Wówczas obliczanie prognozy rekomendacji odbywa si dla najbli szego s siedztwa

opartego na korelacji demograficznej [12], zgodnie z równaniem (8).

, =

( . ) _ ,

_ ,

(8)

gdzie:

, – wa ona suma ocen innych u ytkowników przedmiotu liczona dla

ytkownika w najbli szym s siedztwie demograficznym,

_ , – korelacja demograficzna pomi dzy u ytkownikiem i .

Do obliczenia powy szej korelacji demograficznej _ , , najcz ciej stosuje si

odleg kosinusow [13]. Nast pnie, maj c wyliczon prognoz rekomendacji,

mechanizm zachowuje si dalej tak, jak zosta o to opisane przy wspólnej filtracji.

3.4.2. Skalowalno

Kolejnym problemem jest skalowalno . Wyst puje ona w momencie znacznego

wzrostu istniej cych u ytkowników i przedmiotów w systemie. Wówczas rekomendacja na

podstawie porównania profilu u ytkownika z profilami innych mo e by czasoch onna. W

takim przypadku macierz systemu sk adaj ca si z ocen u ytkowników staje si

rozbudowana. Stosuje si wtedy rozk ad macierzy wed ug warto ci osobliwych (ang.

Singular Value Decomposition) [14], zgodnie z równaniem (9).

( ) = (9) gdzie:

( ) – przedstawienie macierzy A o rozmiarach w postaci rozk adu

wed ug warto ci osobliwych,

– macierz ortonormalna o rozmiarach , czyli ortogonalna maj ca

ugo ka dego wektora w macierzy równ 1,

– macierz diagonalna o rozmiarach , posiadaj ca na przek tnej

nieujemne warto ci osobliwe macierzy ,

– macierz ortonormalna o rozmiarach , czyli ortogonalna maj ca

ugo ka dego wektora w macierzy równ 1.

Mechanizmy rekomendacji korzystaj z macierzy sk adaj cej si z ocen przedmiotów

ka dego z u ytkowników. Zastosowanie powy szego rozk adu sprawi, e ta macierz

zostanie zredukowana i stanie si wolna od nieistotnych u ytkowników.

30

Innym sposobem radzenia sobie ze skalowalno ci jest grupowanie. Dzi ki

zastosowaniu tej techniki, rekomendacje mog by wyznaczane dla pewnych grup, a nie

dla indywidualnych u ytkowników. Taki mechanizm jest mniej kosztowny obliczeniowo,

gdy grupy u ytkowników s mniej liczne, nawet o kilka rz dów wielko ci, od ca ej

przestrzeni danych. Oprócz tego, atutem grupowania jest zwi kszenie wydajno ci serwisu

oraz skalowalno ci, lecz przez to efektywno rekomendacji b dzie du o gorsza, ni ta

oparta na analizie indywidualnej u ytkuj cych serwis. Dodatkowo podzia na grupy mo e

by wykonywany off-line, bez udzia u u ytkowników. Ze wzgl du na du z ono

problemu grupowania, nie b dzie on szerzej omawiany w niniejszej pracy.

3.4.3. Pozosta e wyzwania

Wy ej wymienione problemy stanowi najwi ksze przeszkody w projektowaniu

systemów rekomendacyjnych. Istniej jednak mniej wymagaj ce problemy, o których

warto wspomnie . Jest nim mi dzy innymi problem tzw. „czarnej owcy” (ang. gray sheep),

wyst puj cy g ównie w przypadku mechanizmów korzystaj cych ze wspólnej filtracji

i grupowania. Wówczas istnieje ryzyko, e preferencje danego u ytkownika nie b

pasowa do adnej z grup, przez co nie b dzie móg korzysta z profitów mechanizmu

rekomendacji. W takich przypadkach wyj ciem jest zastosowanie mechanizmów

hybrydowych, które wspierane s dodatkowo przez filtrowanie wykorzystuj ce analiz

zawarto ci. Znajdowana jest wówczas rekomendacja najbardziej pasuj ca do potrzeb

indywidualnych poprzez analiz produktów ju dodanych lub obserwowanych.

ród wyzwa wokó systemów rekomenduj cych wyró nia si nagroda miliona

dolarów w konkursie og oszonym przez serwis Netflix, który jest internetow

wypo yczalni filmów. Za eniem konkursu, którego start odby si w 2006 roku, jest

udoskonalenie silnika rekomendacyjnego serwisu, tak aby poprawi jego wspó czynnik

trafno ci o 10%. Uda o si to zespo owi BellKor's Pragmatic Chaos w lipcu 2009 roku

[15]. Pomys opiera si w du ej mierze na dopracowaniu modelu najbli szego s siedztwa,

dzi ki czemu uda o si poprawi wspó czynnik poprawno ci do 10,06%.

3.5. Podej cie hybrydowe ywanie filtrowania wykorzystuj cego analiz zawarto ci wi e si z ryzykiem, e

rekomendacja przy uwzgl dnianiu jedynie produktów podobnych do ogl danych b dzie

nienajlepsz . Powstaje wówczas sytuacja, e wi kszo u ytkowników ogl da jedynie

niewielk cz wszystkich produktów. Nazywane jest to problemem „ ugiego ogona”,

31

którego ilustracj wida na rys. 5. Przyk adem takiej sytuacji mo e by rekomendacja

tylko najpopularniejszych i najlepszych pozycji. Powoduje to, e produkty mog ce okaza

ciekawymi dla u ytkownika, nie b mu prezentowane. Rozwi zaniem takiego problemu

jest dodatkowe zastosowanie metod wspólnej filtracji, które b w stanie

zarekomendowa mniej popularne produkty pasuj ce do u ytkownika, powoduj c

aktywacj pozosta ej cz ci „ ugiego ogona”.

Jednoczesne lub zamienne stosowanie obu metod, tj. filtrowania z analiz zawarto ci i

wspólnej filtracji, nosi nazw podej cia hybrydowego.

Rys. 5. Problem „d ugiego ogona” ród o: opracowanie w asne na podstawie: [8]

Najcz ciej wykorzystywanym typem mechanizmu hybrydowego jest wspólna

filtracja wspomagana zawarto ci (Content-Boosted Collaborative Filtering). Atutem tego

rozwi zania, oprócz mo liwo ci spersonalizowanych rekomendacji na podstawie

najbardziej podobnych u ytkowników, których dostarcza wspólna filtracja, jest dodatkowo

poprawa danych o u ytkownikach i przedmiotach dzi ki wykorzystaniu cech przedmiotów

oraz osobistych preferencji u ytkuj cych serwis pochodz cych z zastosowania filtrowania

z analiz zawarto ci. Jak wspomniano w poprzednich rozdzia ach, zastosowanie podej cia

hybrydowego pozwala unikn problemów jakim jest np. rzadko danych, czyli problem

nowego u ytkownika.

32

Koncepcja mechanizmów hybrydowych opiera si na tworzeniu pseudowektorów

dla ka dego u ytkownika w bazie. Atrybuty pseudowektora budowane s zgodnie z

wzorem (10).

, = ,

, . . . (10)

gdzie:

, – ocena przedmiotu u ytkownika w pseudowektorze ,

, – ocena u ytkownika przedmiotu ,

, – ocena u ytkownika przedmiotu powsta a przez zastosowanie metody

filtrowania z analiz zawarto ci.

Zastosowanie powy szej metody zapewni, e ka dy przedmiot b dzie oceniony przez

ytkownika albo przez niego osobi cie, albo poprzez zastosowanie metody filtrowania

opartego na analizie zawarto ci opisanej w rozdziale 4.2. Z one pseudowektory

ytkowników dadz macierz systemu, gdzie nie wyst pi problem rzadko ci danych.

Nast pnym krokiem jest zastosowanie korelacji Pearsona (5) do obliczania podobie stwa

mi dzy u ytkownikami, znanej z metody wspólnej filtracji, lecz w podej ciu hybrydowym

nie stosuje si omawianych w rozdziale 4.3.1 wektorów ocen u ytkowników i , a ich

pseudowektory i .

Dok adno pseudowektorów liczona dla konkretnego u ytkownika jest zale na od

liczby ocenionych przez niego przedmiotów. Je li liczba ocen jest du a, to

prawdopodobie stwo, e rekomendacja z pomoc filtrowania z analiz zawarto ci b dzie

trafna, tak e b dzie wysokie. W przeciwnym przypadku, pseudowektor mo e by nie do

dok adny dla potrzeb prognozy rekomendacji. Stwierdzono [16], e mo e to powodowa

myl co wysokie korelacje mi dzy niektórymi u ytkownikami, dlatego stosowana jest w

takim przypadku wa ona rednia harmoniczna, która okre la wag dok adno ci

pseudowektora. W pierwszym kroku liczony jest wspó czynnik u ytkownika (11).

= 50 < 50

1 . . .

(11)

gdzie:

– wspó czynnik u ytkownika ,

– liczba ocen u ytkownika .

33

Powy szy wspó czynnik opiera si na progu, który zosta dobrany na podstawie bada

Toma M. Mitchela2. Zastosowano wówczas krzywe uczenia si na zbiorze treningowym

132 u ytkowników, którzy ocenili wi cej ni 200 produktów. Wykryto, e je eli

predykator dostaje coraz wi cej danych treningowych, to jego wydajno przewidywania

poprawia si , lecz po przekroczeniu oko o 50 ocen dok adno zwi ksza si jedynie

nieznacznie. Maj c wspó czynnik mo liwe jest wyznaczenie wspomnianej wa onej

redniej harmonicznej (12).

, =

2+

(12)

gdzie:

, – wa ona rednia harmoniczna u ytkowników i ,

, – wspó czynniki u ytkowników i .

Zastosowanie powy szego równania pozwoli obliczy tendencj do odchylenia wagi w

kierunki mniejszej z warto ci i . Dzi ki temu korelacja pomi dzy dwoma pseudo-

wektorami z co najmniej 50 ocenami ka dego z u ytkowników i otrzyma najwi ksz

wag , niezale nie od liczby ocenionych produktów przez pozosta ych u ytkowników. Z

kolei je li jeden z u ytkowników oceni mniej ni 50 produktów, waga takiej korelacji

zostanie odpowiednio zdewaluowana.

Dodatkowo stosuje si tzw. „wag znaczeniow ” (ang. Significance Weighting) [17],

która ma za zadanie zmniejszy znaczenie korelacji opartych na u ytkownikach maj cych

ma o ocen (13).

, =

,

50 < 501 . . .

(13)

gdzie:

, – waga znaczeniowa u ytkowników i ,

, – liczba ocen wspólnie ocenionych przedmiotów przez u ytkowników

i .

Powy sza waga wykorzystywana jest do obliczenia hybrydowej wagi korelacji (14) (ang.

Hybrid correlation weight), której u ywa si w ostatecznej prognozie rekomendacji.

Sk ada si ona z dwóch wcze niej omawianych wag. 2 Michalski R., Carbonell J., Mitchell T., „Machine Learning: An Artificial Intelligence Approach”, Tioga Press, 1983

34

, = , + , (14) gdzie:

, – hybrydowa waga korelacji u ytkowników i ,

, – wa ona rednia harmoniczna u ytkowników i ,

, – waga znaczeniowa u ytkowników i .

W metodzie wspólnej filtracji prognoz rekomendacji przewiduje si na podstawie

najbli szego s siedztwa danego u ytkownika, zgodnie z wzorem (6). W podej ciu

hybrydowym do powy szego równania nale y w czy dodatkowo pseudoocen obliczon

na podstawie danego u ytkownika, zgodnie z filtrowaniem z analiz zawarto ci. Ma to na

celu zwi kszenie dok adno ci rekomendacji. Zazwyczaj wykonuje si to z uwzgl dnieniem

wagi danej pseudooceny. Waga ta, nazywana „samowag ” (ang. Self Weighting) wygl da

nast puj co (15):

= 50 < 50

. . .

(15)

gdzie:

– waga okre laj ca znaczenie pseudooceny u ytkownika ,

– liczba ocen u ytkownika .

– parametr okre laj cy zaufanie, jakim darzona jest metoda filtrowania z

analiz tre ci w podej ciu hybrydowym, zazwyczaj wynosi 2 [16].

Nast pnym krokiem jest obliczenie prognozy rekomendacji znanej z metody wspólnej

filtracji, lecz dostosowanej do wspó pracy z filtrowaniem z analiz tre ci. W podej ciu

hybrydowym tak prognoz oblicza si stosuj c równanie (16).

, = +

, + ( . ) , ,

+ , ,

(16)

gdzie:

, – wa ona suma ocen innych u ytkowników przedmiotu liczona dla

ytkownika ,

– zbiór u ytkowników, którzy ocenili przedmiot ,

– rednia wszystkich pozosta ych ocen u ytkownika ,

– rednia wszystkich pozosta ych ocen u ytkownika ,

, – korelacja Pearsona pomi dzy u ytkownikiem i ,

, – ocena u ytkownika przedmiotu powsta a przez zastosowanie metody

35

filtrowania z analiz zawarto ci,

– waga okre laj ca znaczenie pseudooceny u ytkownika ,

, – hybrydowa waga korelacji u ytkowników i .

Po obliczeniu prognoz rekomendacji, w podej ciu hybrydowym post puje si tak, jak

zosta o to opisane przy wspólnej filtracji. Analizowane s wyniki prognoz, wybierane

najlepsze i przedstawiane u ytkownikowi jako lista rekomendacji.

3.6. Podsumowanie Systemy rekomendacyjne s zaawansowanymi systemami, trudnymi do

implementacji. Ich wybór zale y od miejsca, w którym zostan u yte. Mechanizm

filtrowania z analiz zawarto ci bazuje na informacjach o produkcie oraz na jego

ciwo ciach. Takie podej cie znane jest z systemów wyszukiwania i filtrowania

informacji. Jest ono skuteczne, gdy mamy ma o wiadomo ci preferencjach danego

ytkownika. Nie maj c informacji o jego upodobaniach, mechanizm jest w stanie

zarekomendowa jedynie produkty, które s najbardziej podobne do tych ju znanych i

ogl danych przez u ytkownika. Powoduje to, e wykorzystanie tego podej cia do budowy

pe nego systemu rekomendacji mo e sta si ma o efektywne.

W sytuacji, gdy w systemie jest du o danych na temat u ytkowników i ich preferencji,

mo liwe jest zastosowanie mechanizmów wspólnej filtracji. Opieraj si one na zbieraniu

i analizowaniu informacji o zachowaniach u ytkowników oraz ich preferencjach. Na tej

podstawie s w stanie rekomendowa produkty bazuj c na obliczonym podobie stwie z

innymi u ytkuj cymi serwis, przy za eniu, e najbardziej podobni u ytkownicy wybior

te same przedmioty. Wspólna filtracja obarczana jest problemami zimnego startu,

skalowalno ci i rzadko ci danych. W celu ich unikni cia stosuje si ró ne zabiegi, w tym

rozszerzenie profilu u ytkownika o wektor z danymi demograficznymi. Wolnym od

powy szych problemów jest mechanizm filtrowania hybrydowego, cz cego oba

wymienione podej cia.

Przed implementacj wybranego mechanizmu w systemie rekomendacji, istotnym jest

okre lenie celów, jakie ma realizowa oraz przewidzenie danych, jakie b analizowane

w trakcie jego dzia ania. Dzi ki temu, na pocz tkowym etapie tworzenia systemu,

projektant ma mo liwo poznania problemów mog cych wyst pi w dzia aj cym

systemie i wybra odpowiednie metody je niweluj ce.

36

Rozdzia 4

Aplikacja Findy

4.1. Za enia Aplikacja Findy jest praktyczn cz ci pracy. G ównym celem realizacji aplikacji jest

implementacja prototypu systemu zaawansowanych rekomendacji. W projekcie skupiono

si na wdro eniu dwóch mechanizmów rekomendacyjnych: filtrowania z analiz

zawarto ci omówionego w rozdziale 3.2 oraz wspólnej filtracji wykorzystuj cego pami

omówionego w rozdziale 3.3.1. Findy jest aplikacj internetow dzia aj na serwerze i

komunikuj si z komputerem u ytkownika poprzez sie komputerow przy u yciu

przegl darki internetowej.

Ide aplikacji jest pomoc u ytkownikowi w wyborze sposobu i miejsca sp dzenia

wolnego czasu. Na potrzeby projektu skupiono si na aktywnym sposobie, czyli

uprawianiu sportów w Warszawie. Aplikacja umo liwia wybór dyscypliny sportu,

rekomenduje u ytkownikowi najlepsze miejsca z wykorzystaniem filtrowania z analiz

zawarto ci wraz z mo liwo ci wyboru daty, kiedy ma odby si wydarzenie, a nast pnie

zapisuje wszystkie informacje w bazie danych. Stworzone w taki sposób wydarzenie

dzie wy wietlane u ytkownikowi w jego spersonalizowanym oknie wraz z

komunikatami o zbli aj cych si terminach. Dodatkowo, na wspomnianym

spersonalizowanym oknie b rekomendowane inne wydarzenia, które najbardziej pasuj

do u ytkownika z wykorzystaniem mechanizmu wspólnej filtracji wykorzystuj cego

pami .

Za eniem aplikacji Findy jest planowanie aktywno ci. W szybki sposób, w paru

krokach, u ytkownik ma mo liwo przejrzenia najbardziej pasuj cej oferty, wybrania tej

interesuj cej oraz u enie jej na swoim panelu, umo liwiaj c sprawne uk adanie grafiku

aktywno ci. Na bie co dany u ytkownik jest informowany o miejscach i wydarzeniach,

które mog by przez niego preferowane za spraw dzia ania mechanizmu rekomendacji

opartego na wspólnej filtracji. Dodatkowo ma mo liwo oceny danego miejsca

wydarzenia, co jest podstaw dzia ania algorytmów rekomendacji.

37

4.2. Specyfikacja wymaga Poni ej przedstawiono specyfikacj wymaga funkcjonalnych i niefunkcjonalnych,

jakie za ono przy implementacji aplikacji Findy.

4.2.1. Wymagania funkcjonalne

1. Aplikacja wspiera tworzenie wydarze , w których u ytkownik chce wzi

udzia .

2. Aplikacja umo liwia gromadzenie wydarze u ytkownika i przypomina o

nadchodz cych terminach.

3. Aplikacja umo liwia ocenianie miejsc wydarze ,

4. Aplikacja umo liwia szczegó owy podgl d wydarzenia u ytkownika,

5. Aplikacja rekomenduje miejsca, na podstawie których u ytkownik ma

mo liwo stworzenia w asnego wydarzenia.

6. ytkownik mo e usuwa za one wydarzenia.

7. ytkownik mo e tworzy nowie miejsca wydarzenia, które mog by

rekomendowane innym u ytkownikom.

8. Aplikacja wy wietla komunikaty pomagaj ce w u ytkowaniu.

4.2.2. Wymagania niefunkcjonalne

1. Logowanie – aby u ytkownik móg zacz korzysta z aplikacji musi si

zalogowa podaj c login i has o, które s weryfikowane w bazie danych, po

czym nadawane s odpowiednie uprawnienia.

2. Dost pno – dost pno do aplikacji jest mo liwa ca dob , ka dego dnia.

3. ono – aplikacja powinna by intuicyjna, nauka korzystania z aplikacji

nie powinna zaj wi cej ni 10 minut.

4. Bezpiecze stwo – ka dy zarejestrowany u ytkownik powinien mie dost p

jedynie do wydarze i informacji, przechowywanych o nim samym.

4.3. Realizacja Aplikacja Findy jest aplikacj typu RIA (ang. Rich Internet Application) w wi kszo ci

napisan w technologii Vaadin, b cej szkieletem (ang. Framework) do tworzenia

aplikacji w j zyku Java. W Vaadinie zosta zaimplementowany interfejs u ytkownika,

wykorzystuj cy dodatkowo technologi Spring Framework. Oprócz tego wykorzystano

szkielet Hibernate do realizacji warstwy dost pu do danych zapisanych w bazie

PostgreSQL oraz technologi JSP do stworzenia dynamicznych stron z logowaniem

38

ytkownika. Ca y projekt budowano przy u yciu narz dzia Apache Maven

automatyzuj cego proces kompilacji oraz pozwalaj cego w atwy sposób dodawa

zale no ci do zewn trznych bibliotek u ywanych w aplikacji. Zbudowana aplikacja

uruchamiana jest na serwerze aplikacyjnym Apache Tomcat w wersji 6.0.35.

4.3.1. Technologia Spring Framework

Framework Spring zosta u yty w wersji 3.0.5. RELEASE do tworzenia tzw. „ziaren”

(ang. Bean) za pomoc adnotacji. Ziarna opakowuj obiekty, np. metody, zmienne, w

jeden serializowalny obiekt pozwalaj cy na dostanie si do swoich elementów przy

pomocy metod dost powych „get” i „set”, za adnotacje pozwalaj na ich konfiguracj .

Aby adnotacje by y rozpoznawane przez kontekst Springa (czyli g ówny interfejs

zapewniaj cy konfiguracj aplikacji podczas jej dzia ania), zosta a uruchomiona us uga

adnotacji w pliku konfiguracyjnym applicationContext.xml. Dodatkowo wskazano

pakiet pl.findy.web, gdzie kontekst ma szuka okre lonych adnotacji.

Najwa niejsze cz ci projektu, czyli algorytmy u ywane w mechanizmach

rekomendacji zosta y oznaczone adnotacj @Service. Korzystanie z nich mo liwe jest

dzi ki wstrzykiwaniu ich zale no ci (ang. Dependency Injection) poprzez adnotacj

@Autowired. Przyk adem jest zastosowanie w klasie MainWindowPresenter.java,

gdzie u yto wstrzykni cia prosto do pola collaborativeFilteringService:

@Autowired private CollaborativeFilteringService collaborativeFilteringService;

Dodatkowo u ywane s adnotacje @Component okre laj ce komponenty b ce ziarnami

klas prezenterów, widoków (które zostan omówione w rozdziale 5.3.3) oraz pozosta ych

obiektów, które wi si z warstw aplikacji.

Wykorzystywane s tak e adnotacje okre laj ce zasi g dzia ania ziaren, czyli czas ich

ycia. Dost pne s nast puj ce mo liwo ci okre lenia zasi gu: „singleton”, „prototype”,

„request”, „session” i „global session”. W aplikacji Findy stosowane s komponenty o

zasi gu „prototype”. Ma to zwi zek z architektur Vaadina, która zostanie dok adniej

omówiona w nast pnym podrozdziale. Vaadin jest aplikacj , która dzia a na serwerze,

przez co wysy a ona u ytkownikom tzw. terminale, czyli konkretne ekrany akcji. Z tego

wzgl du u ycie zasi gu typu „singleton” powodowa oby, e ka dy u ytkownik

odwiedzaj cy aplikacj widzia by dok adnie ten sam ekran, gdy ziarno tworzone by oby

39

raz. Przyk adowo, gdyby jeden u ytkownik wywo by jak akcj , to ta sama akcja

zosta aby ukazana pozosta ym u ytkownikom. U ycie zasi gu „prototype” powoduje, e

je eli dana aplikacja po stronie klienta si gnie do kontekstu Springa po ziarno, to zostanie

ono stworzone jako nowy obiekt. Zasi g „request” w kontek cie Vaadina zachowuje si

podobnie jak „prototype”. Pozosta e typy zasi gów: „session” i „global session” s

stosowane w aplikacjach wykorzystuj cych interfejs „HTTPSession” do komunikacji i

tworzenia sesji pomi dzy klientem a serwerem.

4.3.2. Technologia Vaadin

W celu zobrazowania i przedstawienia dzia ania mechanizmów rekomendacji zosta

yty framework Vaadin, obecnie uwa any za bardzo dojrza y projekt fi skiej firmy

Vaadin (kiedy IT Mill Toolkit). Oparty jest na pakiecie Google Web Toolkit (GWT),

innym frameworku do budowania aplikacji internetowych. Charakteryzuje si tym, e

jego standard zapewnia poprawne wy wietlanie kontrolek, czyli komponentów, na

wszystkich najbardziej popularnych przegl darkach.

Dzieki u yciu Vaadina, GWT wykorzystywane jest raz. Dzieje si to jedynie w

momencie, kiedy kontrolki u ywane w aplikacji, takie jak pole do wpisywania tekstu, czy

lista rozwijana, s kompilowane przez GWT. Od tego momentu mo na ich u ywa bez

ponownych aktualizacji przy rekompilacji projektu. Oznacza to, e ka da zmiana w

kodzie nie b dzie nios a ze sob konieczno ci budowy projektu na nowo. Zmiany te

zostaj automatycznie wprowadzane w trakcie dzia ania aplikacji na serwerze, która

wymaga jedynie od wie enia w przegl darce, aby zmiany by y widoczne.

Pozosta e przypadki wykorzystania frameworków zosta y stworzone na nowo przez

Vaadina. Dzi ki temu mo liwe by o unikni cie wad, jakie niesie ze sob u ywanie

normalnego GWT, mi dzy innymi problemów internacjonalizacyjnych (wymóg

tworzenia dodatkowych modu ów obs uguj cych zmiany j zyka) oraz problemów z

szybkim przyrostem aplikacji (im wi kszy rozmiar aplikacji, tym szybciej zwi ksza si

rozmiar JavaScriptu generowanego przez GWT, w przeciwie stwie do Vaadina, gdzie

generowany JavaScript zwi ksza si nieznacznie w czasie rozwoju projektu, co opisano

w nast pnym akapicie). Innym udogodnieniem w porównaniu do GWT jest brak

konieczno ci dzielenia kodu na cz serwerow i klienck . Kod aplikacji napisanej w

Vaadinie jest wykonywany w ca ci po stronie serwera. Powoduje to, e aplikacje pisze

si atwiej, lecz serwer jest bardziej obci any. Jednak w dobie dzisiejszego rozwoju

40

techniki obci enie to jest niemal niewidoczne. Aplikacja Findy rednio u ywa 33kB

pami ci RAM, co daje mo liwo podtrzymywania 30000 sesji na ka dy 1 GB pami ci.

W Vaadinie to, co przesy ane jest do klienta do przegl darki, jest niezale ne od

wielko ci aplikacji, poniewa wysy any jest tylko obiekt zmiany informuj cy o sposobie

wy wietlania i zachowania si kontrolek. Ka de po czenie klienta z aplikacj powoduje

traktowanie go jako klienta terminala, który odbiera wspomniany obiekt zmiany

zawieraj cy informacj np. jak widok ma si zmieni pod wp ywem akcji w aplikacji.

Obiekt zmiany tworzony jest za pomoc j zyka UIDL (User Interface Definition

Language) opartego na notacji JSON (JavaScript Object Notation), co przedstawiono na

rys. 6. Mechanizm UIDL pozwala na przesy anie obiektów „lekkich”, które mog by

liczone w bajtach, w przeciwie stwie do j zyka XML, gdzie wyst puje narzut tagów, co

zwi ksza obj to obiektów. Widok w aplikacji, podobnie jak w przypadku innych

aplikacji internetowych, kompilowany jest do JavaScriptu, dlatego dodatkowe stosowanie

UIDL pozwala na szybk komunikacj z serwerem.

41

Rys. 6. Architektura Vaadin’a ród o:Book of Vaadin, rozdzia 3.1, vaadin.com/book/

Na rysunku przedstawiono tak e Vaadin Terminal Adapter, który jest niewidoczny dla

ytkowników. Jest to abstrakcyjna warstwa stworzona przez twórców Vaadina, która w

atwy sposób pozwala na przej cie do innej technologii kompilacji kontrolek. Tak jak

teraz pozwoli a na u ycie GWT, tak w przysz ci pozwoli na szybkie przej cie do innej

technologii, np. bardziej efektywnej. Poni ej w architekturze mamy wspomniane

kontrolki u ytkownika, które s w stanie wi za si z danymi w bazie danych oraz logik ,

czyli sam aplikacj napisan w Vaadinie.

Pisanie aplikacji przebiega bardzo podobnie, jak przy pisaniu aplikacji desktopowych

z wykorzystaniem Java Swing. Programista zwolniony jest z obowi zku znajomo ci

42

zyka HTML, JavaScript, czy arkusza stylów CSS. Dzi ki temu tworzenie interfejsu

graficznego przesta o by wymagaj czynno ci , pozwalaj c na po wi cenie du o

wi cej czasu na implementacj logiki aplikacji. Przyk ad tworzenia cz ci widoku

wyst puj cy w oknie modalnym 2 kroku wyboru wydarzenia zaprezentowano poni ej.

public void initialize() { VerticalLayout dateLayout = new VerticalLayout(); dateLayout.addComponent(getDateFields()); dateLayout.setComponentAlignment(dateField, Alignment.MIDDLE_CENTER); addComponent(dateLayout); }

Pocz tkowo odbywa si okre lenie uk adu widoku. Wybrany zosta uk ad pionowy, czyli

kolejne komponenty b dodawane w pionie. Nast pnie do stworzonego uk adu dodane

jest pole z dat i okre lone zostaje jego po enie wzgl dem uk adu: wy rodkowane. Aby

stworzy powy szy interfejs graficzny nie jest potrzebne wype nianie arkusza CSS czy

ustawianie elementów na stronie HTML. Wystarczy znajomo Javy Swing i dodawanie

kolejnych komponentów do siebie. Za kwesti wygl du strony i jej interfejsu graficznego

odpowiada Vaadin, a konkretnie jeden z trzech motywów dost pnych do wyboru:

Chameleon, Reindeer i Runo Theme. Pierwszy z nich mo emy dodatkowo zmienia w

edytorze on-line udost pnionym przez Vaadina. Po dostosowaniu go do w asnych potrzeb

wystarczy go podmieni w aplikacji, aby zmiany by y widoczne.

Zastosowanie technologii Vaadin pozwoli o na atwe dostosowanie interfejsu

ytkownika do potrzeb mechanizmów rekomendacji. W aplikacji rekomendacj jest

obiekt wydarzenia, który zosta wybrany przez zastosowany algorytm filtrowania. Taki

obiekt ma w sobie informacje o miejscu wydarzenia oraz o uprawianej dyscyplinie.

Nast pnie ka dy taki obiekt wydarzenia wi zany jest z obiektem typu panel, po czym

wy wietlany u ytkownikowi jako rekomendacja.

4.3.3. Wzorzec Model-View-Presenter

Technologia Vaadin nie ma okre lonego wzorca tworzenia aplikacji, dlatego wybrany

zosta wzorzec model-widok-prezenter (ang. Model-View-Presenter), którego diagram

klas zaprezentowano w dodatku A. W zastosowanym wzorcu prezenter przechowuje stan

widoku, dlatego jest on dost pny ca y czas, gdy obecny jest jego widok. Ró ni si to od

koncepcji kontrolera w powszechnie wykorzystywanym wzorcu model-widok-kontroler

(ang. Model-View-Controler), gdzie kontroler jedynie zwraca widok i ko czy swoje

dzia anie.

43

Istniej dwa podwzorce tworzenia widoku. Pierwszym jest podej cie „supervising

controller”, gdzie prezenter dopuszcza powi zanie widoku z warstw danych, czyli

modelem. Wówczas prezenter nadzoruje ca operacj , przekazuj c widokowi jedynie

polecenia (np. o pobraniu danych), a nast pnie widok sam pobiera z modelu potrzebne

informacje. Drugim podej ciem, które zastosowano w aplikacji Findy jest „passive view”.

W takim przypadku widok nie ma informacji o tym, co wykonuje, ani jak dzia a logika

aplikacji. Jest odseparowany tak e od ród a danych. Funkcj zarz dzania takim

widokiem przejmuje prezenter, który odbiera od widoku informacje o tym, co zosta o na

nim wykonane, a nast pnie na tej podstawie kieruje jego dalsz prac . Przyk adem mo e

by klikni cie przycisku na widoku, które ma na celu za adowanie danych. Gdy prezenter

odbierze tak informacj i odpowiednio j przetworzy, b dzie wiedzia sk d pobra

wymagane dane, a nast pnie prze le dane do widoku w celu ich wy wietlenia.

W projekcie u yto interfejsów reprezentuj cych prezentera. Taki prezenter

uruchamiany jest przez zdarzenie, np. klikni cie na odpowiedni przycisk. Wówczas

prezenter wywo any przez takie zdarzenie zwraca widok jako komponent, którym

zarz dza. Specjalnym typem widoku i prezentera jest tzw. wizard, czyli umo liwienie na

jednym ekranie wybierania kolejnych paneli i elementów. Zosta on u yty w oknie

wyboru wydarzenia u ytkownika w aplikacji Findy.

Model jest warstw dost pu do danych, gdzie zastosowano komponenty, które

dostarczaj odpowiednie interfejsy do komunikacji mi dzy aplikacj , a baz danych. W

implementacji zastosowano obiekty DAO (ang. Data Access Object) przy u yciu

narz dzia Hibernate. W ramach projektu stworzono generyczne DAO, które pozwala na

dynamiczne przeprowadzenie operacji CRUD na bazie danych dla ka dego obiektu. Gdy

odpowiedni obiekt zostanie wskazany, zostanie automatycznie zmapowany na

odpowiedni tabel bazodanow .

4.4. Praca z aplikacj Aby móc korzysta z aplikacji Findy nale y najpierw zalogowa si loginem i has em.

Z podanego has a generowany jest skrót za pomoc algorytmu kryptograficznego MD5, a

nast pnie wraz z loginem sprawdzana jest ich obecno w bazie danych. Gdy u ytkownik

zostaje znaleziony przekierowywany jest na stron z aplikacj .

Po przej ciu procedury logowania, uruchamiana jest aplikacja Findy. Jej ekran g ówny

zaprezentowany jest na rys. 7. G ównymi cz ciami sk adowymi s nag ówek, pasek

44

nawigacji oraz panel u ytkownika. W nag ówku mamy mo liwo wpisania nazwy

dyscypliny, jak chcemy uprawia . Po wpisaniu odpowiedniego has a i klikni ciu w

przycisk „+”, otworzone zostanie okno modalne z mo liwo ci wybrania szczegó ów

nowo tworzonego wydarzenia. W pasku nawigacji znajduj cym si po lewej stronie

ekranu g ównego, ukazane s rekomendacje powsta e przy u yciu wspólnej filtracji. Po

klikni ciu na przycisk „o” panelu z rekomendacj uka e si podobne, jak wy ej, okno

modalne z podanymi szczegó ami danej rekomendacji. W panelu u ytkownika

stanowi cym g ówn , centraln cz ekranu, zebrane s panele, które odpowiadaj

wydarzeniom danego u ytkownika. Mog by one oznaczone trzema kolorami:

czerwonym – je li wydarzenie si odby o, tym – je li do wydarzenia zosta o mniej ni

1 dzie , oraz zielonym – je li wydarzenie odb dzie si , za co najmniej 1 dzie . Na

panelach mamy tak e przyciski „-” s ce do usuwania danego wydarzenia z profilu

ytkownika, oraz „o”, które ukazuje szczegó y danego wydarzenia oraz oferuje

mo liwo oceny danego miejsca.

Rys. 7. Ekran g ówny aplikacji Findy

Tworzenie nowego wydarzenia polega na przej ciu dwóch kroków, które ukazuj si

kolejno na oknie modalnym typu „wizard”. W pierwszym oknie, które przedstawiono na

rys. 8., u ytkownik ma mo liwo podania nazwy tworzonego wydarzenia oraz wyboru

45

miejsca na mapie, którego wydarzenie b dzie dotyczy . Wybranie miejsca na mapie

mo liwe jest albo poprzez wybór jednego z zarekomendowanych znaczników na mapie

przez mechanizm filtrowania z analiz zawarto ci, albo poprzez samodzielne stworzenie

asnego znacznika. Wybór znacznika w pierwszym sposobie jest nieintuicyjny, gdy

samo klikni cie na niego nie powoduje automatycznie jego wybrania. Nale y lekko

znacznik przesun na mapie, by uznany by za wybrany przez u ytkownika. Przyczyn

takiego zachowania jest niekompatybilno najnowszej wersji 0.9.13 dodatku

GoogleMapWidget ze stabiln wersj 6.7.8 Vaadina. W tej wersji Vaadina

nieobs ugiwany jest s uchacz MarkerClickListener, a jedynie MarkerMovedListener, st d

zdecydowano si na u ycie opcji z przeci gni ciem znacznika.

Rys. 8. Krok 1 tworzenia wydarzenia

Po przej ciu do nast pnego kroku przy u yciu przycisku „Dalej” pojawi si mo liwo

wyboru daty wydarzenia, co pokazano na rys. 9. Domy lnie wybrana jest data aktualna.

Zako czenie operacji dodawania wydarzenia po wci ni ciu przycisku „Utwórz” sprawi,

46

e na panelu u ytkownika zostanie dodany nowy panel, reprezentuj cy nowo dodane

wydarzenie.

Rys. 9. Krok 2 tworzenia wydarzenia

4.5. Sposób implementacji algorytmów rekomendacji W aplikacji Findy zaimplementowano dwa mechanizmy rekomendacji. Pierwszym

jest filtracja z analiz zawarto ci korzystaj ca z obliczania miary kosinusowej, a drugim

jest wspólna filtracja wykorzystuj ca pami wspomagana dodatkowo danymi

demograficznymi. Podczas implementacji u yto g ównie wzorców „Najpierw najlepszy”

oraz „Personalizacja”, które zosta y omówione w pierwszym rozdziale.

Mechanizmy rekomendacyjne obliczaj potrzebne prognozy i sugestie na podstawie

profili u ytkowników i przedmiotów. Profile te tworzone s za pomoc obu podej

okre lonych w rozdziale drugim. Podej cie aktywne objawia si obowi zkowym

wyborem miejsca zamieszkania przy pierwszym zalogowaniu, co jest wykorzystywane

przy filtrowaniu z analiz zawarto ci, oraz udost pnieniem mo liwo ci ocenienia miejsca

wydarzenia, które stanowi podstaw dzia ania mechanizmu wspólnej filtracji. Oprócz

podej cia aktywnego wykorzystywane jest tak e podej cie pasywne. System przechowuje

wydarzenia u ytkownika oraz analizuje, jaka dyscyplina sportu jest aktualnie wybierana.

Na podstawie takich danych mo liwe jest dope nienie profili u ytkowników tak, aby

rekomendacje by y relatywnie najlepsze.

4.5.1. Implementacja filtracji z analiz zawarto ci

Gdy u ytkownik zdecyduje si na wybór dyscypliny sportu, to kluczowym elementem

aplikacji Findy jest rekomendacja najbli szych miejsc, gdzie mo e t aktywno

47

uprawia . Zosta do tego wybrany mechanizm filtrowania z analiz zawarto ci, czyli

oparty tylko na cechach przedmiotów, bez uwzgl dniania preferencji innych

ytkowników. Prognoza trafno ci danej rekomendacji opiera si na obliczeniu korelacji

pomi dzy profilem u ytkownika, a profilem danego wydarzenia, których zawarto

przedstawiono w Tabeli 2, wraz z przyk adowym wywo aniem metod pobieraj cych

dane.

Tabela 2 Struktura profili u ytkownika i wydarze u ywanych przy rekomendacji „Content-based Filtering”

Nazwa ytkownika

Wspó rz dna X u ytkownika Wspó rz dna Y u ytkownika

user. getName()

user.getLocalizationX() user.getLocalizationY()

Nazwa wydarzenia

Wspó rz dna X miejsca wydarzenia

Wspó rz dna Y miejsca wydarzenia

place. getName()

place.getLocalizationX() place.getLocalizationY()

Serwis, który odpowiada za stosowanie i obliczanie algorytmów niezb dnych do

filtrowania z analiz zawarto ci znajduje si w klasie

ContentBasedFilteringService. Znajduj si tam dwie metody:

makePlaceOfEventVector(PlaceOfEvent placeOfEvent) i makeUserVector

(FindyUser findyUser), które odpowiednio tworz wektor miejsca wydarzenia oraz

wektor u ytkownika. Na potrzeby aplikacji wektory te sk adaj si tylko z dwóch

atrybutów przedstawionych w Tabeli 2. Nast pnie obliczany jest wspó czynnik

podobie stwa, czyli korelacja pomi dzy tymi wektorami. Zgodnie z tym, co opisano w

rozdziale 3.2, u yto sposobu wykorzystywanego m.in. w serwisie Amazon, czyli miary

odleg ci kosinusowej, a wykonuje j metoda

countCosineSimilarity(vectorFindyUser,vectorPlaceOfEvent),

znajduj ca si w serwisie CosineSimilarityService, która przyjmuje w

parametrze dwa wektory o dowolnej równej d ugo ci, a nast pnie za pomoc wzoru (4)

wylicza korelacj . Ka da wyliczana korelacja jest normalizowana z wykorzystaniem

wzoru (2), po czym przy pomocy odpowiedniej struktury danych mapy, czona z

obiektem reprezentuj cym miejsce wydarzenia jako klucz danego obiektu. Stworzone

pary klucz-warto s w ko cowym etapie sortowana malej co po warto ciach obliczonej

korelacji za pomoc biblioteki Google Guava.

Na potrzeby testu przygotowano zbiór 18 danych testowych b cymi p ywalniami w

ró nych cz ciach Warszawy. Dla przyk adowego u ytkownika, którego profil sk ada si

48

ze wspó rz dnych (21.014528; 52.230464) obliczono rekomendacj opart na

filtrowaniu z analiz zawarto ci, któr przedstawiono w Tabeli 3.

Tabela 3 Przyk adowe rekomendacje dla danych testowych przy u yciu „Content-based Filtering”

Id. Wspó rz dne miejsca wydarzenia Korelacja z u ytkownikiem 1 (20.942814 ; 52.221913) 0.0343158481256633 2 (20.991176 ; 52.208914) 0.03431407312753843 3 (20.984428 ; 52.216551) 0.034312729273387556 4 (20.977472 ; 52.230592) 0.03430966035440842 5 (20.994464 ; 52.236352) 0.034306219145497883 6 (20.928896 ; 52.274624) 0.034302996686063264 7 (20.988848 ; 52.255584) 0.034301589134495054 8 (21.013188 ; 52.246384) 0.03430142460409226 9 (20.997452 ; 52.260512) 0.0342992995546276 10 (20.978141 ; 52.275584) 0.03429731284429493 11 (20.984624 ; 52.276832) 0.03429625994502311 12 (20.968296 ; 52.284624) 0.03429593171783209 13 (20.954421 ; 52.296832) 0.03429413206403262 14 (21.12005 ; 52.231398) 0.034293811360119296 15 (21.114176 ; 52.24672) 0.03429027458076378 16 (21.11748 ; 52.253918) 0.03428795173468065 17 (21.032864 ; 52.298944) 0.03428494169857731 18 (21.213096 ; 52.228101) 0.03428457556869002

W ko cowym kroku zwracane s klucze ze wspomnianej mapy, czyli miejsca

wydarzenia, posortowane od najbardziej pasuj cych do u ytkownika. Nast pnie na mapie

umieszczanych jest 5 pierwszych pozycji, czyli zgodnie ze wzorcem Top-5

recommendation. Zastosowana rekomendacja przedstawiona jest na rys. 10.

49

Rys. 10. Przyk adowa rekomendacja bazuj ca na danych testowych

4.5.2. Implementacja wspólnej filtracji

Za eniem aplikacji Findy by a mo liwo proponowania u ytkownikowi obiektów,

których jeszcze nie zna, a mog yby by uznane przez niego za interesuj ce. Aby taka

funkcjonalno by a mo liwa, niezb dne jest wykorzystanie algorytmów obliczaj cych

miar podobie stwa u ytkowników. Na podstawie tej miary istnieje mo liwo wybrania

takich obiektów, które zosta y docenione przez najbli szych s siadów, dlatego mog by

tak e docenione przez aktywnego u ytkownika. W tym celu wybrano mechanizm wspólnej

filtracji oparty na pami ci, który zosta opisany w rozdziale 3.3.1., gdy jest najbardziej

elastyczny i za jego pomoc atwo mo na ukaza rekomendacj w praktyce.

Pierwszym krokiem jest obliczenie najbli szego s siedztwa u ytkownika.

Wykonywane jest to przez metod countPearsonCorrelation(List<FindyUser>

findyUsers, FindyUser findyUser) w serwisie PearsonCorrelationService.

Przyjmuje ona dwa parametry: list wszystkich u ytkowników bez aktualnego

ytkownika oraz aktualnego u ytkownika, a zwraca map Map<FindyUser, Double>.

Mapa ta zawiera powi zanie ka dego u ytkownika i miary korelacji Pearsona z aktualnym

ytkownikiem, która liczona jest zgodnie ze wzorem (5). W ko cowym etapie, korelacja

Pearsona jest jeszcze poddawana normalizacji (6).

Nast pnym krokiem jest wyliczenie prognozy rekomendacji na podstawie obiektów,

których nie oceni , ani nie analizowa dany u ytkownik, a robili to pozostali z najbli szego

siedztwa. W tym celu u yte zosta o równanie (7). Spo ród wszystkich wydarze

50

mechanizm wybiera tylko te, które zosta y ocenione przez u ytkowników oraz te, których

aktywny u ytkownik jeszcze nie oceni . Wykonywane jest to przez metod makeMapOFEventsToRecommendation (Map<FindyUser, Double>

mapOfNeighbourhood, List<UserEvent> userEventsForRecommendation,

FindyUser findyUser) w serwisie CollaborativeFilteringService. Metoda ta

przyjmuje kolejno map zawieraj powi zanie u ytkownika i wyliczonej korelacji

Pearsona z aktywnym u ytkownikiem obliczonej w poprzednim kroku, list wszystkich

wydarze w serwisie oraz profil danego u ytkownika. Zwraca ona posortowan map

cz miejsce wydarzenia z jako ci rekomendacji, od najbardziej trafnych, do

najbardziej nieznacz cych.

Po stworzeniu powy szej mapy, mechanizm jest w stanie wytworzy list

rekomendacyjn . Miejsca wydarze , które maj by zarekomendowane, ukazywane s

ytkownikowi w panelu nawigacyjnym w formie paneli, zgodnie ze wzorcem Top-4

recommendation.

Powy sze dzia anie jest jednak niewystarczaj ce, gdy nie jest odporne na problem

nowego u ytkownika i inne, które zosta y opisane w rozdziale 3.4.. W sytuacji, gdy do

systemu loguje si u ytkownik, który nie postawi jeszcze adnej oceny, to system nie jest

w stanie porówna go z adnym innym u ytkuj cym serwis. Aby zapobiec temu

problemowi, wzbogacono mechanizm rekomendacji o analiz danych demograficznych.

Ka demu u ytkownikowi przypisywany jest wektor reprezentuj cy jego profil

demograficzny. Sk ada si on z atrybutów zawartych w Tabeli 1. oraz dodatkowych trzech,

okre laj cych miejsce zamieszkania u ytkownika: pó nocna Warszawa, rodkowa

Warszawa, oraz po udniowa Warszawa. Dzi ki utworzeniu takich profili przy u yciu

metody makeDemographicVectorOfUser (FindyUser findyUser), mo liwe jest

wyliczenie na ich podstawie miary podobie stwa u ytkowników. Do tego celu u yto

ponownie miary kosinusowej opisanej w poprzednim rozdziale. Nast pnie tworzona jest

mapa cz ca u ytkownika i jego miar podobie stwa z aktywnym u ytkownikiem. W

dalszym kroku u ywana jest ponownie metoda

makeMapOFEventsToRecommendation(), lecz teraz z u yciem mapy opartej na danych

demograficznych.

Dzi ki zastosowanemu sposobowi, system jest odporny na problemy zimnego startu,

rzadko ci danych i nowego u ytkownika. W sytuacji, gdy aktywny u ytkownik nie ma

ocenionych przedmiotów lub takich ocen jest ogólnie ma o w systemie, typowy

51

mechanizm wspólnej filtracji zast powany jest wspomaganym przez dane demograficzne,

który jest w stanie zarekomendowa produkty bazuj c na podobie stwie demograficznym.

Dla przyk adowych danych treningowych mechanizm rekomendacji danych wylicza

prognozy rekomendacji zawarte w Tabeli 4., gdzie „Id. M” oznacza identyfikator miejsca

wydarzenia, a „Id. D.” oznacza identyfikator dyscypliny, której dotyczy.

Tabela 4 Przyk adowe rekomendacje dla danych testowych przy u yciu „Collaborative-based Filtering”

Id. M. Id. D. Rekomendacja oparta na „Collaborative-based Filtering”

Rekomendacja oparta na „Collaborative-based Filtering”

i dane demograficzne 1 2 3.6726244272871664 -0.4304816216540128 1 3 2.6726861880795467 -0.8536107249209965 6 7 1.9651811280232696 -0.4774959664614553 7 7 1.9643966019741497 -1.1533271730684431 8 7 0.4652751831359738 0.7564044705769841 9 7 1.9643966019741497 -1.1533271730684431

Na powy szym przyk adzie wida , e oba podej cia rekomendacji mog da ró ne

rezultaty. Przy u yciu samego mechanizmu wspólnej filtracji wykorzystuj cego pami

wida , e najbardziej trafna b dzie rekomendacja miejsca wydarzenia o id = 1

i dyscyplinie o id = 2. W sytuacji, gdy mechanizm skorzysta dodatkowo z danych

demograficznych, to najlepiej pasuj cym oka e si miejsce wydarzenia o id = 8 i

dyscyplinie = 7. Chc c oferowa wydarzenia najlepiej trafiaj ce w gusta u ytkowników,

wi kszy priorytet ma rekomendacja wykonana tylko na podstawie filtrowania z analiz

zawarto ci. W sytuacji, gdy taka rekomendacja nie zwróci wystarczaj cej liczby

rezultatów, b nawet adnego, wówczas u ywany jest mechanizm dodatkowo

wykorzystuj cy dane demograficzne. Dzi ki temu ka da graniczna sytuacja w systemie

dostarczy odpowiednich rekomendacji.

4.6. Mo liwo ci rozwoju Aplikacja Findy, cho jest tylko prototypem implementuj cym wybrane mechanizmy

rekomendacji danych, mo e by rozwijana w bardzo wielu kierunkach. Jednym z nich

mo e by interakcja z serwisem spo eczno ciowym Facebook. Wówczas rejestracja nie

by aby niezb dna, a proces logowania by by zintegrowany z tym serwisem. Taki wybór

umo liwia by tak e tworzenie wydarze o zasi gu spo eczno ciowym oraz poznawanie

ytkowników o podobnych upodobaniach sportowych. Okno tworzenia wydarzenia

zosta oby poszerzone o krok 3, polegaj cy na dodaniu znajomych do danego nowo

52

tworzonego wydarzenia, a panel u ytkownika o propozycje uczestnictwa w grupowych

wydarzeniach utworzonych przez najbli szych znajomych.

Inn mo liwo ci rozwoju jest umo liwienie reklamowania miejsc. W takim

przypadku nie by oby mo liwe wybranie w asnego miejsca wydarzenia, a jedynie tych

reklamowanych przez serwis. Baza miejsc wydarze by aby typowo skomercjalizowana,

czyli zawiera aby tylko takie miejsca, które zgodzi yby si na reklamowanie w serwisie. W

takim przypadku przestrze obiektów by aby relatywnie wi ksza, co poci gn oby za sob

konieczno jeszcze wi kszej optymalizacji systemu oraz konieczno kontroli

efektywno ci i trafno ci u ytych mechanizmów rekomendacyjnych w trakcie dzia ania

aplikacji.

Zaimplementowane mechanizmy rekomendacyjne s w pe ni funkcjonalne i spe niaj

swoj rol , lecz mo liwo ci rozwoju jest zmiana wykonywania obliczania rekomendacji

dla u ytkowników. W obecnym prototypie rekomendacje obliczane s przy ka dym

za adowaniu okna g ównego aplikacji. Operacja ta mog aby zosta sparametryzowana i

okre la moment ponownego obliczenia rekomendacji, np. raz dziennie w godzinach

wieczornych, gdy ruch u ytkowników po aplikacji by by ni szy. Spowodowa oby to

mniejsze obci enie serwera w godzinach szczytu.

53

Rozdzia 5

Podsumowanie Zastosowanie mechanizmu filtrowania z analiz zawarto ci, omówionego w rozdziale

4.5.1., spe ni o swoj rol . W krótkim czasie pozwoli o na efektywne i trafne

rekomendacje miejsc wydarze . Rozwi zanie to jest wolne od problemu, jakim jest nowy

ytkownik, gdy do obliczenia korelacji z przedmiotami wystarcza informacja o jego

miejscu zamieszkania podawana po pierwszym zalogowaniu. Problemem mo e jednak

okaza si rozrost bazy danych. W prototypie aplikacji Findy skupiono si jedynie na

miejscach na terenie Warszawy, gdzie liczba miejsc jednego typu, np. p ywalni, b dzie

liczona w dziesi tkach lub setkach. W sytuacji gdyby przestrze informacji o miejscach

zosta a poszerzona np. o dane z ca ej Polski, problemem by by wyd ony czas

odpowiedzi systemu rekomendacyjnego, a jednym z jego za jest zwrócenie

odpowiedzi w czasie jak najkrótszym. Rozwi zaniem mog oby by omówione wcze niej

grupowanie, które pozwoli oby na podzia przyk adowego kraju na obszary, do których

ogranicza yby si mechanizmy licz ce korelacje. Innym sposobem mo e by obliczanie

rekomendacji off-line w czasie, gdy ruch w aplikacji by by najmniejszy, lecz w takim

przypadku niezb dne by oby przygotowanie bazy danych do przechowywania ko cowych

wyników oblicze . Inna zauwa alna wada tego rozwi zania polega na tym, e cz sto

pokazywane s miejsca wydarze , które u ytkownik ju zna, powoduj c, e ogl da tylko

cz zgromadzonych obiektów w bazie. Jednak z drugiej strony, sposób u ycia

filtrowania z analiz zawarto ci w aplikacji wolny jest od problemu, jakim jest

rekomendacja u ytkownikowi obiektów wyszukiwanych na podstawie wielu atrybutów.

Przyk adem takiej sytuacji jest ksi garnia internetowa, która na podstawie analizy

preferencji u ytkownika tworzy aby profile sk adaj ce si z wielu ulubionych autorów,

gatunków, czy daty wydania. Taki przypadek wymaga by utworzenia skomplikowanego

zapytania, które musia oby by specjalnie optymalizowane, by zwróci o wyniki w

rozs dnym czasie. W zastosowanym rozwi zaniu wyszukujemy zawsze jeden rodzaj

obiektów. Ten, który jest powi zany z dyscyplin wybran przez u ytkownika.

Podobnie zastosowanie mechanizmów omówionych w rozdziale 4.5.2. pozwoli o na

spe nienie za zaawansowanego systemu rekomendacyjnego. W efektywny sposób

wyszukiwane s obiekty uznane za najbardziej pasuj ce do aktywnego u ytkownika na

podstawie jego podobie stwa z innymi u ytkownikami. W tym celu u ywana jest historia

54

wydarze zawieraj ca oceny nadane miejscu, gdzie odby o si dane wydarzenie.

Problemem mo e by du y rozrost tej historii. W sytuacji gdy u ytkownik b dzie mia

ug list wydarze , które ju si zako czy y, niezb dne b dzie wybranie tylko cz ci z

nich, gdy skorzystanie ze wszystkich w algorytmach rekomendacji spowoduje, e czas

reakcji systemu b dzie wyd ony. W takiej sytuacji nale y zoptymalizowa algorytmy

tak, aby wybiera y tylko np. najnowsze wydarzenia albo tylko te zawieraj ce miejsca

najcz ciej wybierane. Im wi kszy by by rozrost serwisu, tym wi ksza by aby przestrze ,

w której nale oby wykonywa obliczenia niezb dne w rekomendacjach. Wówczas koszt

takich oblicze móg by by za du y i korzystanie z aplikacji sta oby si niepraktyczne.

Rozwi zaniem w takim przypadku mog oby by wykorzystanie podej cia hybrydowego,

omówionego wcze niej, b zastosowania grupowania lub wyboru tylko cz ci

przestrzeni obiektów, lecz w takich przypadkach jako i trafno rekomendacji mog aby

by niska, gdy algorytmy rekomendacji bazowa yby na uogólnionych zbiorach.

W niniejszej pracy zosta y przedstawione ró ne podej cia w zastosowaniu

mechanizmów rekomendacji danych oraz ukazane przyk adowe ich zastosowanie. Wyniki

pracy wskazuj , e zaimplementowane algorytmy maj zdolno trafnego sugerowania

ytkownikowi obiektów dla niego interesuj cych. Prototyp systemu jest w stanie

przewidzie ocen u ytkownika na temat innych miejsc na podstawie ocen innych

ytkowników i ich korelacji. Zastosowane techniki bardzo dobrze sprawdzi y si na

zbiorze danych w aplikacji Findy. Ich dzia anie mo e by jednak dalej rozwijane w

kierunku wi kszej optymalizacji dla innych, specyficznych zbiorów danych.

Idealny system rekomendacji powinien by dynamiczny, co oznacza, e aktualizacja

profili i obliczanie rekomendacji powinno by wykonywane w jak najkrótszym czasie,

dlatego rozwój tego typu mechanizmów kierowany jest w stron coraz skuteczniejszej

optymalizacji czasu wykonania. Widoczne jest to g ównie w sytuacji, gdy mechanizmy

musz bazowa na rozleg ym zbiorze danych, dlatego wzrost mocy obliczeniowej

serwerów oraz opracowywanie algorytmów o jak najmniejszej z ono ci obliczeniowej s

bardzo pomocne w dziedzinie systemów rekomendacyjnych.

Problemem, z jakim musz mierzy si projektanci, jest wybór cz stotliwo ci

aktualizacji profili u ytkownika oraz ich rekomendacji. Do dzi trwaj dyskusje na ten

55

temat, lecz bez w tpienia d y si do tego, aby wszelkie obliczenia by y wykonywane w

jak najkrótszym czasie, algorytmy oferowa y jak najni sz z ono obliczeniow , co

zmniejszy obci enie systemu i pozwoli na wyeliminowanie omawianych wcze niej

potencjalnych problemów przy stosowaniu mechanizmów rekomendacyjnych.

56

Rozdzia 6

Literatura

[1] Bergmark D., Lagoze C., Sbityakov A., „Focused Crawls, Tunneling, and Digital

Libraries”, VI Europejska Konferencja Bibliotek Cyfrowych, Rzym, W ochy 2002,

str 3-5

[2] Bailyn E., Bailyn B., „Przechytrzy Google. Odkryj skuteczn strategi SEO i

zdob szczyty wyszukiwarek”, Helion, 2012

[3] Morville P., Callender J., „Wzorce wyszukiwania. Projektowanie nowoczesnych

wyszukiwarek”, Helion, 2011

[4] Hearst M., „UIs for Faceted Navigation Recent Advances and Remaining Open

Problems”, II Warsztaty na temat interakcji cz owiek-komputer – HCIR 2008, Redmond

2008, str 1-4

[5] Nudelman G., „Design Patterns for Mobile Faceted Search: Part I”,

http://www.uxmatters.com/mt/archives/2010/04/design-patterns-for-mobile-faceted-

search-part-i.php

[6] Marshall M., „ Aggregate Knowledge raises $5M from Kleiner, on a roll”,

http://venturebeat.com/2006/12/10/aggregate-knowledge-raises-5m-from-kleiner-on-a-

roll/

[7] Meteren R., Someren M., „Using Content-Based Filtering for Recommendation”,

str 1-3

[8] Tsissput, „Systemy rekomendacyjne od kuchni”,

http://tsiss.wordpress.com/2012/01/12/systemy-rekomendacyjne-od-kuchni/

[9] Chen A., McLeod D., „Collaborative Filtering for Information Recommendation

Systems”, str 1-4

[10] Su X., Khoshgoftaar T., „A Survey of Collaborative Filtering Techniques”, 2009,

str 5-11

57

[11] Miyahara K., Pazzani M., „Improvement of Collaborative Filtering with the Simple

Bayesian Classifier”, str 4-10

[12] Vozalis M., Margaritis K., „Collaborative Filtering Enhanced By Demographic

Correlation”, str 3-6

[13] Vozalis M., Margaritis K., „ Enhancing Collaborative Filtering with Demographic

Data: The case of Item-based Filtering”, str 1-5

[14] Paterek A., „ Improving regularized singular value decomposition for collaborative

filtering”, str 2-3

[15] Lohr S., „ Netflix Awards $1 Million Prize and Starts a New Contest”,

http://bits.blogs.nytimes.com/2009/09/21/netflix-awards-1-million-prize-and-starts-a-

new-contest/

[16] Melville P., Mooney R., Nagarajan R., „Content-Boosted Collaborative Filtering for

Improved Recommendations”, str 1-4

[17] Herlocker, J., Konstan, J., Borchers, A., Riedl, J., „An algorithmic framework for

performing collaborative filtering”, 22 Konferencja Specjalnej Grupy do Wyszukiwania

Informacji - SIGIR ’99, Berkeley 1999, str 2-6

58

Dodatek A

Diagram klas modelu MVP w aplikacji Findy

59

Dodatek B

Zawarto p yty CD

Aplikacja Findy

Znajduj si tu wszystkie pliki niezb dne do uruchomienia aplikacji w rodowisku Eclipse oraz

skompilowana aplikacja w formacie .war, któr mo na uruchomi na serwerze aplikacyjnym.

Konfiguracja serwera aplikacyjnego

Znajduje si tu konfiguracja do serwera aplikacyjnego Apache Tomcat w wersji 6.0.35, któr

mo na uruchomi w rodowisku Eclipse.

Skrypty do bazy danych

W katalogu znajduj si skrypty do utworzenia bazy danych, tabel oraz dodaj ce dane

inicjalne, na których testowana by a aplikacja.

Praca in ynierska - Daniel Bie kowski.pdf

Praca in ynierska w formacie .pdf.