Mechanizmy zaawansowanych rekomendacji w systemach portali

Transkrypt

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
pisaniu niniejszej pracy.
okazan przy
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
3.3.2.
Metody wykorzystuj ce model (Model-based) ................................................27
3.4.
(Memory-based) ............................................ 24
G ówne problemy przy stosowaniu mechanizmów rekomendacji............................28
3.4.1.
Rzadko
danych .............................................................................................28
3.4.2.
Skalowalno
3.4.3.
Pozosta e wyzwania ........................................................................................ 30
..................................................................................................29
3.5.
Podej cie hybrydowe .............................................................................................. 30
3.6.
Podsumowanie .......................................................................................................35
5
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
6
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
e-maili b
ilo ci
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
7
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.
8
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
historycznych wyszukiwa
zachowywania naszych
(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
9
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
ich miniaturyzacji, czy niewystarczaj cej czu
szego tekstu, g ównie z powodu
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.
10
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
popularno
wspóln
– jest ni
popularno
has a, b
produktu. Wspomniana
jest oczywi cie ró nie rozumiana w kontek cie danego serwisu. Przyk adowo,
w serwisach stworzonych do gromadzenia i udost pniania zdj
„najpierw najlepsza” odbywa si poprzez ocen b
cyfrowych rekomendacja
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
zapytania. Popularno
tego rozwi zania sprawi a,
za pasuj cy do u ytego
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
by
danej rekomendacji mo e by tak e uzale niona od daty. Przyk adem mog
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
11
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
12
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.
pozycje
Dobieraj c
fasety odnajdujemy
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
i przysz
ci gle rozwijan , a przy tym potrzebn
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
upodobaniach i rutynowych czynno ciach, które mog
niezb dnych informacji o jego
by podstaw
zaawansowanej
13
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
myl ce. Podobny problem wyst puje w przewidywaniu, które produkty mog
zainteresowa w przysz
dzia
naszego
si
nas
ci. Wówczas niezb dne jest tworzenie profilu z uwzgl dnieniem
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
sprawiaj c, e b
mechanizmy rekomendacji
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,
14
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
oznacza pewn cech lub atrybut danego profilu, a
=( ,
oznacza d ugo
,…,
), gdzie
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.
15
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
odwrotno ci
dodatkowo warto ci wag. Przyk adem mo e by
waga b
ca
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
liczb go u ytkuj cych. Ka da warto
okre la liczb przedmiotów w serwisie, a
macierzy -
która dotyczy -tego przedmiotu.
,
, okre la ocen
-tego u ytkownika,
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.
16
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
17
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
powi zane”, czy „
elementy, podpisane jako „Zobacz tak e”, „Produkty
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,
pochodzi w
e 35% dochodów serwisu Amazon [6],
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
podstawie jego dzia
dla konsumenta wykorzystuj c jego profil stworzony na
podczas u ytkowania serwisu.
18
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
potrzeb
czy
w asnor cznego
samodzielnego dostosowania portalu do swoich
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).
,
gdzie:
= max ( , )
(1)
– zbiór wszystkich u ytkowników serwisu,
– zbiór wszystkich rekomendowanych obiektów w serwisie,
×
– funkcja przydatno ci przedmiotu dla u ytkownika .
19
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. Contentbased 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
udzia em jego ulubionego aktora, b
klientowi filmy z
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).
20
( , )=
(
gdzie:
) + (
( , )=
((
) + …+ (
)
) )
(2)
– 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
( , ), tym aktywny obiekt bardziej pasuje do u ytkownika. Przyj o
mniejsza warto
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).
( , )=
gdzie:
1
1+ ( , )
( , ) – znormalizowana miara podobie stwa.
Po jej zastosowaniu miara podobie stwa zawiera
si
(3)
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
przeprowadzi , aby zmieni
ytkownika
nale y
jeden ci g na drugi. Przyk adowo maj c wektor cech
= (1, 0, 0, 7, 0, 2) i wektor cech przedmiotu
Hamminga mi dzy nimi wynosi
= (1, 1, 0, 5, 0, 2), odleg
( , ) = 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.
21
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(
gdzie:
( , )=
+
+ …+
,
)=
|
°
| |
+
+
(4)
|
+ …+
– 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
22
Prezentowany powy ej rys. 3. ukazuje ide odleg
i
ci kosinusowej. Dane s trzy cechy
, oraz 4 profile reprezentowane przez wektory cech
pomi dzy wektorami
albo k t
,
,
i
. Je eli k t
zmierza do 0,
pomi dzy wektorami
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
23
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
podobnie, ale u ytkownik
i
ocenili
dodatkowo oceni w pozytywny sposób inna ksi
sytuacji, mechanizm wspólnej filtracji zarekomenduje t
ksi
ksi ek
. W takiej
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
Pierwsz
Charakteryzuj
kategori
algorytmów
si one tym,
danych serwisu. Zak adaj ,
(Memory-based)
s
mechanizmy
wykorzystuj ce
pami .
e do przeprowadzenia rekomendacji u ywa ca ej bazy
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
korelacj pomi dzy dwoma u ytkownikami:
,
, która okre la podobie stwo lub
i . Nast pnie obliczana jest prognoza
okre laj ca, czy dany produkt mo e by polecony u ytkownikowi w oparciu o jego
24
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).
,
gdzie:
,
=
,
,
,
(5)
,
– 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).
,
gdzie:
,
,
=
,
(6)
,
– znormalizowana korelacja Pearsona pomi dzy u ytkownikiem
i ,
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
25
rekomendacji parametr wynosi 2,51. Przyk adowo dzia anie normalizacji sprawi, e w
przypadku korelacji
,
= 0,2, otrzyma
i pomijaln .
,
= 2, mechanizm otrzyma
,
0,018, sprawiaj c,
5,6. W przypadku korelacji
,
e stanie si
wyra nie nieistotn
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).
,
gdzie:
=
+
(
.
,
)
(7)
,
– 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 ,
,
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
np. w formie
Zalet
konkretnych,
najlepszych.
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
1
skalowalno , co omówiono w rozdziale 3.4.2. Dodatkowo, gdy danym
D. Lemire, “Scale and translation invariant collaborative filtering systems”, 2005, str. 129–150
26
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
modelu wykorzystywane s
przedmiotów. Podczas tworzenia
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
maszynowego, lecz nie s
tak e inne techniki uczenia
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
wielowymiarowych zada
podej cie modelowe. Oprócz tego, u ycie redukcji
np. przy naiwnym klasyfikatorze bayesowskim mo e
spowodowa utrat informacji i pogorszy wyniki rekomendacji.
27
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
1
2
3
4
5
6
7
przynale no
do cechy
wiek 15
15 < wiek 20
20 < wiek 30
30 < wiek 45
wiek > 45
== m czyzna
== kobieta
komentarz
je li dany u ytkownik przynale y
do wybranej cechy, wówczas
dany atrybut wektora przyjmuje
warto 1, a w pozosta ych
przypadkach 0.
28
Wówczas obliczanie prognozy rekomendacji odbywa si dla najbli szego s siedztwa
opartego na korelacji demograficznej [12], zgodnie z równaniem (8).
,
gdzie:
=
(
.
)
_
_
,
,
ytkownika
_
,
w najbli szym s siedztwie demograficznym,
– korelacja demograficzna pomi dzy u ytkownikiem
_
Do obliczenia powy szej korelacji demograficznej
odleg
(8)
,
kosinusow
[13]. Nast pnie, maj c wyliczon
,
i .
, najcz ciej stosuje si
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).
( )=
gdzie:
(9)
( ) – przedstawienie macierzy A o rozmiarach
w postaci rozk adu
wed ug warto ci osobliwych,
– macierz ortonormalna o rozmiarach
ugo
, czyli ortogonalna maj ca
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
ugo
, czyli ortogonalna maj ca
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.
29
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
niewielk cz
u ytkowników ogl da jedynie
wszystkich produktów. Nazywane jest to problemem „ ugiego ogona”,
30
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
jest
dodatkowe
zarekomendowa
zastosowanie
mu prezentowane. Rozwi zaniem takiego problemu
metod
wspólnej
filtracji,
które
b
w
stanie
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.
31
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).
,
gdzie:
=
,
,
– ocena przedmiotu u ytkownika
,
,
,
(10)
. . .
w pseudowektorze
,
– ocena u ytkownika
przedmiotu ,
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
ytkowników dadz macierz
one pseudowektory
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
pseudowektory
Dok adno
i
i , a ich
.
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
pseudowektora. W pierwszym kroku liczony jest wspó czynnik
= 50
gdzie:
– wspó czynnik
1
u ytkownika ,
< 50
dok adno ci
u ytkownika (11).
(11)
. . .
– liczba ocen u ytkownika .
32
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,
predykator dostaje coraz wi cej danych treningowych, to jego wydajno
poprawia si , lecz po przekroczeniu oko o 50 ocen dok adno
nieznacznie. Maj c wspó czynnik
e je eli
przewidywania
zwi ksza si jedynie
mo liwe jest wyznaczenie wspomnianej wa onej
redniej harmonicznej (12).
,
gdzie:
(12)
+
– wa ona rednia harmoniczna u ytkowników i ,
,
,
2
=
– 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).
,
gdzie:
,
,
=
,
50
1
< 50
(13)
. . .
– 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
33
,
gdzie:
,
,
=
,
+
(14)
,
– hybrydowa waga korelacji u ytkowników
i ,
– wa ona rednia harmoniczna u ytkowników
,
– waga znaczeniowa u ytkowników
i ,
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
gdzie:
. . .
(15)
< 50
– 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).
,
gdzie:
=
+
,
+
+
(
.
,
)
,
,
,
(16)
,
ytkownika ,
– zbiór u ytkowników, którzy ocenili przedmiot ,
,
,
i ,
przedmiotu powsta a przez zastosowanie metody
34
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,
implementacji. Ich wybór zale y od miejsca, w którym zostan
filtrowania z analiz
trudnymi
do
u yte. Mechanizm
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.
35
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
komunikuj
na serwerze i
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
spersonalizowanym oknie b
si
terminach.
Dodatkowo,
na
wspomnianym
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
interesuj cej oraz u
przejrzenia najbardziej pasuj cej oferty, wybrania tej
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.
36
4.2.
Specyfikacja wymaga
Poni ej przedstawiono specyfikacj wymaga
jakie za
funkcjonalnych i niefunkcjonalnych,
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.
3.
Dost pno
ono
– dost pno
– aplikacja powinna by intuicyjna, nauka korzystania z aplikacji
nie powinna zaj
4.
do aplikacji jest mo liwa ca dob , ka dego dnia.
wi cej ni 10 minut.
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
37
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
38
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
Vaadinie jest wykonywany w ca
si
serwerow i klienck . Kod aplikacji napisanej w
ci po stronie serwera. Powoduje to, e aplikacje pisze
atwiej, lecz serwer jest bardziej obci any. Jednak w dobie dzisiejszego rozwoju
39
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.
40
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
41
zyka HTML, JavaScript, czy arkusza stylów CSS. Dzi ki temu tworzenie interfejsu
graficznego przesta o by wymagaj
wi cej czasu na implementacj
czynno ci , pozwalaj c na po wi cenie du o
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.
42
Istniej dwa podwzorce tworzenia widoku. Pierwszym jest podej cie „supervising
controller”, gdzie prezenter dopuszcza powi zanie widoku z warstw
modelem. Wówczas prezenter nadzoruje ca
danych, czyli
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
43
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
czerwonym – je li wydarzenie si odby o,
by
one oznaczone trzema kolorami:
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
44
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
GoogleMapWidget ze stabiln
wersj
najnowszej wersji 0.9.13 dodatku
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,
45
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
46
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
user.
getName()
Nazwa
wydarzenia
place.
getName()
Wspó rz dna X u ytkownika
Wspó rz dna Y u ytkownika
user.getLocalizationX()
user.getLocalizationY()
Wspó rz dna X miejsca
wydarzenia
place.getLocalizationX()
Wspó rz dna Y miejsca
wydarzenia
place.getLocalizationY()
Serwis, który odpowiada za stosowanie i obliczanie algorytmów niezb dnych do
filtrowania
z
analiz
zawarto ci
ContentBasedFilteringService.
Znajduj
znajduje
si
si
w
tam
dwie
klasie
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
47
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.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Wspó rz dne miejsca wydarzenia
(20.942814 ; 52.221913)
(20.991176 ; 52.208914)
(20.984428 ; 52.216551)
(20.977472 ; 52.230592)
(20.994464 ; 52.236352)
(20.928896 ; 52.274624)
(20.988848 ; 52.255584)
(21.013188 ; 52.246384)
(20.997452 ; 52.260512)
(20.978141 ; 52.275584)
(20.984624 ; 52.276832)
(20.968296 ; 52.284624)
(20.954421 ; 52.296832)
(21.12005 ; 52.231398)
(21.114176 ; 52.24672)
(21.11748 ; 52.253918)
(21.032864 ; 52.298944)
(21.213096 ; 52.228101)
W ko cowym kroku zwracane s
Korelacja z u ytkownikiem
0.0343158481256633
0.03431407312753843
0.034312729273387556
0.03430966035440842
0.034306219145497883
0.034302996686063264
0.034301589134495054
0.03430142460409226
0.0342992995546276
0.03429731284429493
0.03429625994502311
0.03429593171783209
0.03429413206403262
0.034293811360119296
0.03429027458076378
0.03428795173468065
0.03428494169857731
0.03428457556869002
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.
48
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
49
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
makeMapOFEventsToRecommendation
mapOfNeighbourhood,
przez metod
(Map<FindyUser,
List<UserEvent>
Double>
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
50
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
1
6
7
8
9
2
3
7
7
7
7
3.6726244272871664
2.6726861880795467
1.9651811280232696
1.9643966019741497
0.4652751831359738
1.9643966019741497
-0.4304816216540128
-0.8536107249209965
-0.4774959664614553
-1.1533271730684431
0.7564044705769841
-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
51
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.
52
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
odpowiedzi systemu rekomendacyjnego, a jednym z jego za
ony czas
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
53
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
54
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.
55
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-facetedsearch-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-aroll/
[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
56
[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-anew-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
57
Dodatek A
Diagram klas modelu MVP w aplikacji Findy
58
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.
59

Mechanizmy zaawansowanych rekomendacji w systemach portali

Transkrypt

Podobne dokumenty

404 Strony nie znaleziono

Idź Software

Zastosowanie do instalowania pod natryskami

- Ergonomia i projektowanie ergonomiczne

Oprogramowanie PowerSoft Plus

REGULAMIN USŁUGI POD NAZWĄ TELEFONICZNE CENTRUM

Analityk Systemów Informacyjnych

VirtualBox i problemy z portami USB w Ubuntu