System rekomendacji restauracji na urządzenia mobilne PRACA DYPLOMOWA INŻYNIERSKA. Łukasz Pochrzęst. Rok akademicki 2014/2015

Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki Rok akademicki 2014/2015 PRACA DYPLOMOWA INŻYNIERSKA Łukasz Pochrzęst System rekomendacji restauracji na urządzenia mobilne Opiekun pracy: dr inż. Robert Bembenik Ocena:................................................................... Podpis Przewodniczącego Komisji Egzaminu Dyplomowego

Kierunek: Specjalność: Informatyka Inżynieria Systemów Informatycznych Data urodzenia: 1992.10.06 Data rozpoczęcia studiów: 2011.09.30 Życiorys Nazywam się Łukasz Pochrzęst. Urodziłem się 6 października 1992 roku w Warszawie. W 2011 roku ukończyłem XIX Liceum Ogólnokształcące im. Jana Zamoyskiego w Warszawie. W tym samym roku rozpocząłem studia na Wydziale Elektroniki i Technik Informacyjnych w Warszawie na kierunku Informatyka. Po dwóch latach studiów wybrałem specjalność Inżynieria Systemów Informatycznych................................. Podpis studenta Egzamin dyplomowy Złożył egzamin dyplomowy w dniu............................................... z wynikiem..................................................................... Ogólny wynik studiów:.......................................................... Dodatkowe wnioski i uwagi Komisji:..............................................................................................................................................................................................................

Streszczenie Niniejsza praca dotyczy sposobu stworzenia systemu rekomendacji restauracji z użyciem danych pozyskanych za pomocą interakcji użytkownika z aplikacją na urządzeniu mobilnym, działającym pod systemem Android. W pracy znajduje się opis algorytmów rekomendujących oraz ich porównanie. Następnie, opisane jest wykorzystanie urządzenia mobilnego jako elementu, dzięki któremu system rekomendacji może m.in. proponować użytkownikowi restauracje, będące niedaleko obecnej lokalizacji użytkownika. W pracy opisana jest także architektura oraz sposób implementacji systemu. Słowa kluczowe: rekomendacja, restauracje, android, lokalizacja Restaurant recommendation system for mobile devices Abstract This thesis concerns method for developing restaurant recommendation system using data acquired from user interacting with mobile application created for Android devices. This thesis includes a description of recommendation algorithms and a comparison between them. Subsequently, usage of a mobile device as a factor capable of providing localization data for recommending nearby restaurants is described. Recommendation system architecture and implementation description is also part of this thesis. Keywords: recommendation, restaurants, android, localization

Spis treści 1. Wstęp........................................... 1 1.1. Istniejące rozwiązania w zakresie rekomendacji.................. 1 1.1.1. Yelp - system rekomendujący restauracje................. 2 1.1.2. Foursquare - system rekomendujący restauracje............. 3 1.2. Cel i zakres pracy.................................. 4 1.3. Zawartość pracy.................................. 4 2. Systemy rekomendacji.................................. 6 2.1. Metoda zbiorowej filtracji............................. 6 2.1.1. Podejście wykorzystujące podobieństwo użytkowników......... 7 2.1.2. Podejście wykorzystujące podobieństwo obiektów............ 9 2.1.3. Zalety i wady............................... 11 2.2. Metoda filtracji na podstawie zawartości..................... 11 2.2.1. Znajdowanie cech dokumentów - algorytm tf-idf............. 12 2.2.2. Klasyfikator Bayesa............................ 13 2.2.3. Zalety i wady............................... 13 2.3. Metoda spersonalizowanego uczenia oceniania.................. 14 2.4. Metoda wykorzystująca kontekst.......................... 14 2.5. Hybrydowe systemy rekomendujące........................ 15 2.5.1. Ważone systemy rekomendujące..................... 15 2.5.2. Przełączane systemy rekomendujące................... 16 2.5.3. Połączone systemy rekomendujące.................... 16 2.5.4. Systemy rekomendujące połączone poprzez stworzenie nowej cechy.. 16 2.5.5. Kaskadowe systemy rekomendujące................... 16 2.5.6. Systemy rekomendujące poszerzające zbiór cech obiektów....... 16 2.5.7. Systemy rekomendujące połączone za pomocą modelu......... 17 2.6. Ocena działania systemu rekomendującego.................... 17 2.6.1. Ocena offline............................... 18 2.6.2. Ocena online................................ 18

Spis treści B 2.7. Podsumowanie i wybór algorytmów........................ 18 2.8. Implementacja wybranych algorytmów rekomendujących............ 19 2.8.1. Metoda filtracji na podstawie zawartości................. 19 2.8.2. Metoda zbiorowej filtracji......................... 20 2.9. Porównanie zaimplementowanych algorytmów rekomendujących........ 20 2.9.1. Dane testowe............................... 20 2.9.2. Sposób oceny algorytmów........................ 20 2.9.3. Wyniki przeprowadzonych testów.................... 23 3. Specyfikacja wymagań dla systemu.......................... 26 3.1. Opis systemu i interakcji użytkownika....................... 26 3.2. Wymagania funkcjonalne............................. 26 3.3. Wymagania niefunkcjonalne............................ 27 3.4. Wymagania dotyczące urządzenia......................... 28 4. Realizacja systemu rekomendacji restauracji..................... 29 4.1. Stosowane narzędzia................................ 29 4.2. Wykorzystane technologie............................. 29 4.2.1. Android SDK............................... 29 4.2.2. Google Maps Android API v2....................... 30 4.2.3. JSON.................................... 30 4.2.4. Hibernate................................. 30 4.2.5. Baza danych Postgresql.......................... 30 4.2.6. JBoss AS.................................. 30 5. Architektura systemu rekomendacji restauracji................... 31 5.1. Struktura systemu................................. 31 5.1.1. Serwer................................... 31 5.1.2. Klient................................... 31 5.2. Baza danych.................................... 33 5.3. Silnik rekomendacji................................ 36 5.4. Użycie protokołu OAuth 2.0............................ 37 5.5. Lokalizacja geograficzna.............................. 39 6. Testowanie........................................ 41 6.1. Testy jednostkowe................................. 41

Spis treści C 6.2. Testy manualne................................... 41 6.3. Podsumowanie testów............................... 47 7. Podsumowanie...................................... 50 7.1. Dalsze prace.................................... 50 Bibliografia.......................................... 52

1. Wstęp W ostatnich latach niebywale zwiększyła się liczba osób aktywnie korzystających z tzw. inteligentnych telefonów (smartphones), czy podobnych urządzeń mobilnych, które stają się nieodłącznym elementem naszego życia. Jedną z największych zalet tego typu urządzeń jest umożliwienie nam niemal nieprzerwanego dostępu do sieci, co wraz ze zwiększającą sie popularnością różnych serwisów internetowych, takich jak sieci społecznościowe, powoduje to, że serwisy takie mają dostęp do ogromnej ilości spersonalizowanych danych, np. gdzie byliśmy, a nawet co robiliśmy. Dane te mogą być bardzo skutecznie wykorzystywane w przeróżnych silnikach rekomendujących, które dzięki nagromadzonych danych o użytkowniku są w stanie proponować odpowiednie dla użytkownika produkty, wydarzenia, czy też nawet spersonalizowany zestaw wyświetlanych na telefonie reklam. Jednym z pomysłów na wykorzystanie urządzeń mobilnych jest system rekomendacji, który jest w stanie zaproponować nam odpowiednią dla nas restaurację, za każdym razem, kiedy np. znajdziemy się w nowym, nieznanym dla nas mieście, czy też jeżeli po prostu szukamy nowych doznań smakowych. Dzięki urządzeniom mobilnym, proponowany system nie tylko może rekomendować restaurację niedaleko miejsca w którym aktualnie się znajdujemy, ale także poznać nasz gust kulinarny, rejestrując historię naszych dotychczasowych pobytów w restauracjach, co pomoże w rekomendacji lokalu idealnie dopasowanego do naszego smaku. 1.1. Istniejące rozwiązania w zakresie rekomendacji Systemy rekomendacji, wraz ze zwiększającym się wykorzystaniem reklam oraz wszelkich narzędzi podpowiadających w sieci, są budowane oraz rozwijane w celu poszukiwania klientów oraz rozwiązań przyciągających klientów. Na rynku możemy odnaleźć wiele systemów, które oferują funkcje rekomendujące. Rekomendacje wykorzystywane są w przeróżnych dziedzinach. Jednym z najczęstszych zastosowań jest rekomendacja produktów w sklepach internetowych, takich jak Allegro [3], czy Amazon [4]. Systemy rekomendujące są elementem wykorzystywanym również m.in w serwisach oferujących muzykę (itunes [12]), w serwisach oferujących możliwość udostępniania materiału wideo (Youtube [18], Metacafe [15]) oraz w serwisach oceniających filmy (Netflix [16], IMDb [11]).

1.1. Istniejące rozwiązania w zakresie rekomendacji 2 Jednym z zastosowań systemów rekomendacji jest rekomendacja restauracji. Na rynku istnieje kilka systemów tego typu. Dwa największe z nich to Foursquare 1 oraz Yelp 2. Są to amerykańskie serwisy oferujące możliwość ocen restauracji, wystawiania komentarzy, pisania artykułów o restauracjach oraz wyszukiwania restauracji. Obydwa serwisy oferują aplikacje mobilne, które w dużej mierze odzwierciedlają funkcjonalności, jakie znajdziemy logując się w tych serwisach poprzez przeglądarkę internetową. Obydwa serwisy mają ogromną popularność rzędu milionów użytkowników. Dowodzi to, że tego typu systemy są w stanie przyciągnąć bardzo dużą liczbę osób, które aktywnie korzystają z systemu. W przypadku serwisu Yelp jest to nawet 142 milionów unikalnych użytkowników w pierwszym kwartale roku 2015 3, natomiast liczba użytkowników Foursquare wynosi aż 55 milionów 4. 1.1.1. Yelp - system rekomendujący restauracje Serwis Yelp opiera się na stosunkowo obszernych recenzjach restauracji tworzonych przez użytkowników. Jest to często uznawane za negatywny aspekt tego serwisu, ponieważ niewielu użytkowników poświęca czas na to, by opisywać swoje doświadczenia kulinarne w postaci dłuższych opisów, przez co liczba opinii, które możemy znaleźć na temat danej restauracji jest stosunkowo niewielka. Z drugiej jednak strony artykuły te są często tworzone przez prawdziwych koneserów kulinarnych, którzy tworzą bardzo obszerne i pomocne artykuły oraz opinie. Przykładowa recenzja przedstawiona jest na rysunku 1.1. Yelp oferuje interfejs programistyczny, dzięki któremu można otrzymać dostęp do usług i wykorzystać je w swoich projektach. Interfejs dostępny jest w postaci usługi RESTful. Korzystanie z interfejsów odbywa się za pomocą zapytań HTTP. W odpowiedzi otrzymujemy dane w formacie JSON. Usługi, jakie oferuje serwis Yelp to m.in.: wyszukiwanie miejsc/restauracji po nazwie, kategorii, lokalizacji itp. informacje o miejscach: dane kontaktowe, opinie (artykuły), godziny otwarcia, zagregowane oceny kanał RSS z dostępem do informacji spersonalizowanych dla konta użytkownika możliwość zaznaczenia obecności w danym miejscu ( check-in``) Uwierzytelnianie odbywa się za pomocą protokołu OAuth. Zapytania wysyłane są poprzez protokół HTTPS. 1 https://foursquare.com/ 2 https://www.yelp.com/ 3 http://www.yelp.com/factsheet 4 https://foursquare.com/about

1.1. Istniejące rozwiązania w zakresie rekomendacji 3 Rysunek 1.1. Przykładowa opinia wystawiona w serwisie Yelp 1.1.2. Foursquare - system rekomendujący restauracje Serwis Foursquare nie ma rozbudowanego systemu opinii czy artykułów na temat restauracji. Zamiast tego znajdują się tu informacje o wskazówkach`` użytkowników dotyczących restauracji - zazwyczaj nie dłuższe niż parę słów. Działanie serwisu opiera się na rekomendacjach bazujących na powiązaniach pomiędzy użytkownikami - restauracje, w których przebywali znajomi, których posiadasz w serwisie, są często rekomendowanymi restauracjami. Foursquare, podobnie jak Yelp, oferuje interfejs programistyczny, dostępny w postaci usługi RESTful. Serwis Foursquare, w porównaniu do interfejsu serwisu Yelp, udostępnia jednak o wiele bardziej rozbudowany interfejs, który oferuje więcej funkcjonalności. Poniżej znajduje sie lista usług jakie oferuje serwis Foursquare: dostęp do informacji o użytkownikach serwisu, m.in. wyszukiwanie użytkowników, listy znajomych użytkowników, listy miejsc w których użytkownik przebywał, możliwość zarządzania swoim kontem (dodawanie/usuwanie użytkownika, edycja danych profilu) dostęp do informacji o miejscach, m.in.: wyszukiwanie miejsc (według nazwy, kategorii, lokalizacji), dodawanie nowych miejsc, informacje o miejscach, statystki odwiedzin miejsc, nabardziej oblegane miejsca w danym momencie możliwość zaznaczenia obecności w danym miejscu ( check-in``) możliwość polubienia miejsc

1.2. Cel i zakres pracy 4 możliwość wystawiania komentarzy ( wskazówek``) dla innych użytkowników o danej restauracji Analogicznie jak w przypadku usług serwisu Yelp uwierzytelnianie odbywa się za pomocą protokołu OAuth. Zapytania wysyłane są poprzez protokół HTTPS. 1.2. Cel i zakres pracy Celem mojej pracy inżynierskiej jest stworzenie systemu rekomendacji restauracji, którego elementem jest aplikacja na urządzenia mobilne, działająca pod kontrolą systemu Android, wykorzystująca możliwości lokalizacyjne urządzenia. Na system składają się następujące elementy: aplikacja kliencka, działająca jako warstwa prezentacji dla użytkownika oraz będąca elementem, który dostarcza informacji o lokalizacji użytkownika serwer przechowujący oraz przetwarzający informacje o użytkownikach i restauracjach, na podstawie których tworzone są spersonalizowane rekomendacje Ważnym elementem systemu jest stworzenie algorytmów rekomendujących. Tworzenie wyszukanego interfejsu użytkownika zostało zaniedbane, gdyż wykracza to poza zakres tej pracy i może być samo w sobie tematem na oddzielną pracę. 1.3. Zawartość pracy Praca została podzielona na siedem rozdziałów, z których pierwsza zawiera wprowadzenie, cel i zakres pracy oraz opis istniejących rozwiązań w zakresie rekomendacji restauracji. W drugim rozdziale znajduje się opis zagadnienia, jakim są algorytmy rekomendacji. Przedstawione są różne algorytmy, sposób ich działania oraz problemy z nimi związane. Rozdział ten zawiera również opis algorytmów zaimplementowanych w systemie, porównanie ich działania oraz ocenę. Trzeci rozdział zawiera opis oraz specyfikację wymagań dla tworzonego systemu. Wymienione są zarówno wymagania funkcjonalne jak i niefunkcjonalne. Oprócz tego opisane są wymagania nałożone na urządzenie mobilne, na którym uruchamiana będzie aplikacja. Czwarty rozdział to opis realizacji aplikacji. Rozdział ten zawiera opis narzędzi oraz technologii, które zostały wykorzystane przy budowie systemu rekomendacji. W piątym rozdziale znajduje się opis architektury zaimplementowanego systemu, jego struktury, komunikacji pomiędzy elementami systemu, opis bazy danych oraz kwestie dotyczące bezpieczeństwa.

1.3. Zawartość pracy 5 Szósty rozdział został poświęcony testowaniu systemu. Zostały opisane testy jednostkowe oraz manualne. Ostatni, siódmy rozdział zawiera podsumowanie pracy. Opis tego, co zostało stworzone podczas pracy, osiągnięte cele oraz propozycje dalszego rozwoju aplikacji.

2. Systemy rekomendacji Jednym z podstawowych elementów systemu jest stworzenie i zaimplementowanie algorytmów rekomendujących. Znane są różne podejścia do problemu rekomendacji. Możemy dokonać podziału systemów rekomendacji na kilka typów: systemy wykorzystujące metodę zbiorowej filtracji ( collaborative filtering") systemy wykorzystujące metodę filtrowania na podstawie zawartości ( content-based filtering") systemy wykorzystujące metodę spersonalizowanego uczenia ocen ( personalized learning to rank") systemy wykorzystujące kontekst ( context aware recommendation") systemy hybrydowe Poza wymienionymi systemami istnieją również m.in. rzadziej stosowane systemy demograficzne, wykorzystujące geolokalizację, a także systemy społeczne, oparte na zaufaniu w sieciach społecznościowych. Poniżej znajduje się opis poszczególnych systemów. 2.1. Metoda zbiorowej filtracji Pytanie, jakie stawiamy sobie podczas rekomendacji, brzmi: "Które obiekty wyświetlić użytkownikowi, tak aby były dla niego jak najbardziej atrakcyjne?". Aby odpowiedzieć na to pytanie staramy się oszacować ocenę, którą wystawiłby użytkownik danemu obiektowi. Staramy się oszacować taką ocenę dla każdego obiektu w systemie. Następnie obiekty z najlepszymi oszacowanymi ocenami trafią do wynikowego zbioru rekomendacji, który może zostać przedstawiony użytkownikowi. W algorytmach wykorzystujących podejście zbiorowej filtracji abstrahuje się od właściwości obiektów, które są rekomendowane. W metodzie tej nie używamy atrybutów ani cech rekomendowanych obiektów. Informacje na podstawie których tworzone są rekomendacje pochodzą w ogólności od użytkowników, ich aktywności, preferencji, opinii na temat rekomendowanych przedmiotów. Stosowanym sposobem określenia preferencji jest ocena, jaką użytkownik wystawia jakiejś rzeczy może to być przypisanie pewnej ilości gwiazdek" np. w skali od zera do pięciu.

2.1. Metoda zbiorowej filtracji 7 Podstawowym założeniem podejścia zbiorowej filtracji jest to, że na podstawie zebranych i zagregowanych opinii i ocen innych użytkowników jesteśmy w stanie przewidzieć preferencje danego użytkownika na temat przedmiotu. Metoda zbiorowej filtracji jest ogólnym podejściem, w którym możemy wyróżnić dwa różne sposoby na realizację rekomendacji. Są to: podejście wykorzystujące podobieństwo użytkowników oraz podejście wykorzystujące podobieństwo obiektów. 2.1.1. Podejście wykorzystujące podobieństwo użytkowników Pierwszy sposób jest bezpośrednią interpretacją podstawowego założenia metody zbiorowej filtracji i polega na znalezieniu użytkowników, których oceny bądź zachowanie są podobne do użytkownika, dla którego tworzymy rekomendację, oraz przewidzeniu preferencji użytkownika na podstawie tych ocen. Proponowany wzór na przewidywaną preferencję został przedstawiony w pracy [22]. Przewidywana preferencja użytkownika u dla przedmiotu i jest obliczana na podstawie wyrażenia, które jest średnią ważoną ocen n podobnych do u użytkowników (sąsiadów u), gdzie wagą jest podobieństwo do użytkownika u: p u,i = r u + gdzie: n (r a,i r a ) s u,a a=1 n s u,a p u,i przewidywana ocena przedmiotu i przez użytkownika u r u średnia wszystkich wystawionych przez użytkownika u ocen r a średnia wszystkich wystawionych przez użytkownika a ocen r a,i ocena przedmiotu i przez użytkownika a sąsiada u s u,a funkcja podobieństwa między użytkownikiem u i a n pewna liczba najbliższych sąsiadów użytkownika u a=1 (2.1) Odjęcie od ocen r a,i średnich ocen sąsiadów r a rekompensuje różnice w tym, jak użytkownicy wykorzystują skalę ocen, której używają. Przykładowo załóżmy, że mamy dwóch użytkowników A i B, których średnie odpowiednio wynoszą 4 gwiazdki oraz 2,5 gwiazdki. Ocena użytkownika A wynosząca 5 gwiazdek jest w kontekście tego wzoru analogicznie ważna, jak ocena użytkownika B, wynosząca 3,5 gwiazdki. Równanie 2.1 można zmodyfikować używając normalizacji [24], która polega na podzieleniu różnicy między poszczególnymi ocenami użytkownika i średnią oceną użytkownika a (r a,i r a ) przez odchylenie standardowe ocen użytkownika a (σ a ), a następnie

2.1. Metoda zbiorowej filtracji 8 wymnożeniu ilorazu przez odchylenie standardowe ocen użytkownika u (σ u ). Normalizacja ta rekompensuje różnice w rozpiętości wystawianych przez użytkowników ocen. Wzór 2.2 przedstawia powyższą normalizację. p u,i = r u + σ u n (r a,i r a )s u,a /σ a a=1 n s u,a a=1 (2.2) Nie jest to jedyny sposób na obliczanie przewidywanych preferencji. Do stosowanych również metod należy m.in. wykorzystanie średniej nie ważonej, czy metod regresji. Średnia ważona jest jednak najczęściej używanym podejściem z powodu prostoty i zadowalających wyników. Podobieństwo użytkowników Funkcja podobieństwa użytkowników s u,a jest jednym z najważniejszych elementów algorytmu zbiorowej filtracji. Istnieje kilka znanych metod jej wyznaczania. Proponowanymi rozwiązaniami są m.in: odległość kosinusowa [22] lub współczynnik korelacji Pearsona [25]. Odległość kosinusowa. W tym podejściu użytkownicy są traktowani jak wektory o tylu wymiarach, ile jest możliwych do oceny przedmiotów. Współrzędna wektora w określonym wymiarze wynosi tyle, na ile dany użytkownik ocenił przedmiot. Podobieństwo między użytkownikami obliczane jest jako odległość kosinusowa pomiędzy wektorami ocen użytkowników, w sposób zobrazowany wzorem 2.3. s(u, a) = r u r a r u r a = i r2 u,i i r2 i r u,ir a,i a,i (2.3) gdzie: r u, r a wektory ocen odpowiednio użytkownika u oraz użytkownika a r u, r a długość wektorów ocen odpowiednio użytkownika u oraz użytkownika a r u,i, r a,i oceny wystawione obiektowi i odpowiednio przez użytkownika u oraz użytkownika a Częstym rozwiązaniem jest traktowanie nieznanych ocen jako 0 [22], dzięki czemu nie pojawiają się w liczniku i nie mają wpływu na obliczenia. Wynik jest liczbą z zakresu < 1; 1 >.

2.1. Metoda zbiorowej filtracji 9 Współczynnik korelacji Pearsona. Obliczenie tego współczynnika polega na wyznaczeniu korelacji pomiędzy wspólnymi ocenami tych samych przedmiotów przez dwóch użytkowników. Podstawą wzoru jest odległość kosinusowa s u,a, dana wzorem 2.3. Po zastosowaniu średnich wektorów ocen staje się korelacją Pearsona, daną wzorem 2.4. s(u, a) = i I u I a (r u,i r u )(r a,i r a ) i Iu Ia (r u,i r u ) 2 i Iu Ia (r a,i r a ) 2 (2.4) gdzie: I u, I a zbiory przedmiotów ocenionych przez odpowiednio użytkowników u oraz a r u,i, r a,i ocena wystawiona przedmiotowi i odpowiednio przez użytkownika u oraz a r u, r a średnie wszystkich ocen wystawionych odpowiednio przez użytkownika u oraz a 2.1.2. Podejście wykorzystujące podobieństwo obiektów W tym podejściu zamiast obliczać podobieństwo między użytkownikami, wyznaczane jest podobieństwo między przedmiotami, a raczej pomiędzy wzorcami oceniania przedmiotów przez różnych użytkowników. Stosowana jest tutaj również średnia ważona, podobna do tej używanej w podejściu wykorzystującym podobieństwo użytkowników, wagami jednak są podobieństwa pomiędzy przedmiotami. Opis wzoru znalazł się w pracy [22]. Wzór jest następujący: gdzie: p u,i = j S i r u,i s i,j j S i s i,j r u,i ocena wystawiona przedmiotowi i przez użytkownika u s i,j jest podobieństwem pomiędzy przedmiotami i oraz j (2.5) S i jest zbiorem przedmiotów podobnych do i. Zazwyczaj jest to k (zadane) najbardziej podobnych przedmiotów z wszystkich Aby nie wyjść poza skalę oceniania, co mogłoby się zdarzyć w przypadku, gdy suma w liczniku byłaby ujemna (możliwe, ponieważ s(i, j) < 1; 1 >, r > 0), nie bierze się pod uwagę przedmiotów o podobieństwie s(i, j) < 0.

2.1. Metoda zbiorowej filtracji 10 Podobieństwo obiektów Podobnie jak w przypadku zbiorowej filtracji z wykorzystaniem podobieństwa użytkowników istnieje kilka metod, które zostały zaproponowane do obliczania podobieństwa obiektów, m.in.: odległość kosinusowa [22], współczynnik korelacji Pearsona [30] lub model prawdopodobieństwa warunkowego [22]. Odległość kosinusowa. Odległość kosinusowa jest użyta do wyznaczenia odległości pomiędzy wektorami ocen. Jest to najpopularniejsze podejście. W porównywanych wektorach wymiarami są użytkownicy a współrzędna w danym wymiarze jest oceną, jaką dany użytkownik wystawił restauracji. Podobieństwo obiektów dane jest wzorem 2.6. s i,j = u r2 u,i u r2 u r u,ir u,j u,j (2.6) Analogicznie jak w przypadku podobieństwa użytkowników wynik jest liczbą z zakresu < 1; 1 > o identycznej interpretacji jako korelacja pomiędzy obiektami. Współczynnik korelacji Pearsona. Wyrażenie na podobieństwo obiektów przy użyciu współczynnika korelacji Pearsona dane jest wzorem 2.7. s i,j = u U i U j (r u,i r i )(r u,j r j ) u Ui Uj (r u,i r i ) 2 u Ui Uj (r u,j r j ) 2 (2.7) gdzie: U i, U j zbiory użytkowników, którzy ocenili przedmioty i, j r u,i, r u,j ocena wystawiona przedmiotom i, j przez użytkownika u r i, r j średnie wszystkich ocen wystawionych przedmiotom i oraz j Prawdopodobieństwo warunkowe. Prawdopodobieństwo warunkowe jest stosowane dla modelu bez ocen. Wykorzystywane są tylko informacje takie, jak historia wydarzeń (np. historia zakupów). Podobieństwo obiektów dane jest wzorem 2.8. gdzie: B przykładowo, historia zakupów użytkownika s i,j = P (j B i B) (2.8) Podstawową informacją wykorzystywaną we wzorze 2.8 jest częstotliwość występowania przedmiotów j oraz i w koszykach użytkowników. Do tego wyrażenia stosowany jest jeszcze dodatkowo współczynnik alfa, który pozwala na uniknięcie sytuacji, gdy

2.2. Metoda filtracji na podstawie zawartości 11 przedmiot j jest bardzo często kupowany i z tego powodu jest traktowany jako przedmiot podobny do wielu innych. Z powodu współczynnika funkcja przestaje być symetryczna. Wyrażenie to dane jest wzorem 2.9. Powyższe podejście przedstawione zostało w pracy [22]. gdzie: s(i, j) = F req(i j) F req(i)f req(j) α (2.9) F req(x) liczba użytkowników, która kupiła przedmioty ze zbioru X 2.1.3. Zalety i wady Obydwa podejścia wykorzystujące zbiorową filtrację posiadają podobne słabe strony. Trudne jest skategoryzowanie nowego użytkownika w przypadku podejścia wykorzystującego podobieństwo użytkowników. Powodem jest to, że rekomendacje powstają na zasadzie porównania ocen wystawionych przez użytkowników. Jeżeli nowy użytkownik ocenił jeszcze niewiele przedmiotów, mamy o nim małą wiedzę. Analogicznie jest w przypadku nowego przedmiotu, który jest oceniony przez niewielką liczbę użytkowników. Profil oceniania takiego przedmiotu jest trudny do porównania z przedmiotami, które mają wiele ocen i porównanie takie może nie dawać wiarygodnych informacji o faktycznym podobieństwie przedmiotów. Jest to problem znany jako problem zimnego startu. Ponadto systemy wykorzystujące metodę zbiorowej filtracji cierpią z powodu problemu rozproszonych preferencji. Systemy te polegają na nakładaniu się ocen wśród użytkowników i nie dają dobrych rezultatów, jeżeli liczba przedmiotów jest bardzo duża, a użytkownicy oceniają stosunkowo niewiele przedmiotów. Niewątpliwą zaletą metod wykorzystujących zbiorową filtrację jest to, że metody te są niezależne od dziedziny problemu i mogą być wykorzystywane uniwersalnie dla systemów rekomendujących różne obiekty. Algorytmy zbiorowej filtracji są szybkie i wydajne. Co więcej, podejście wykorzystujące podobieństwo przedmiotów jest dobrze skalowalne [27]. 2.2. Metoda filtracji na podstawie zawartości Metody wykorzystujące filtrację na podstawie zawartości polegają na opisie przedmiotów oraz profilu użytkownika stworzonego na podstawie jego dotychczasowych preferencji oraz na porównaniu ich w celu wyznaczenia najbardziej podobnych profilowi przedmiotów. Filtracja na podstawie zawartości, w przeciwieństwie do zbiorowej filtracji, wykorzystuje informacje o rekomendowanych obiektach, ich właściwościach i atrybutach. Dla zachowania ogólności rekomendowane przedmioty przedstawiane są jako wektory. Tworzony na podstawie historii aktywności użytkownika (jego preferencji) profil

2.2. Metoda filtracji na podstawie zawartości 12 również jest wektorem. Współrzędne tego wektora mogą powstać np. z użyciem średniej ważonej danej właściwości przedmiotów. W rozdziale 2.2.1 znajduje się opis przykładowego algorytmu wykorzystywanego do stworzenia reprezentacji dokumentów, która później może być wykorzystana w algorytmie filtracji na podstawie zawartości. Następnie, w rozdziale 2.2.2 znajduje się opis algorytmu wykorzystującego klasyfikator Bayesa do przewidzenia ocen użytkownika. 2.2.1. Znajdowanie cech dokumentów - algorytm tf-idf Algorytm tf-idf (od ang. term frequency inverse document frequency - częstość słów-odwrotna częstość dokumentu) jest popularnym algorytmem, który pozwala na stworzenie reprezentacji dokumentów, która wykorzystywana jest później w algorytmach rekomendujących. Celem algorytmu jest stworzenie statystyki odzwierciedlającej, jak bardzo dane słowo jest ważne w dokumencie. Algorytm został opisany w pracy [28]. Dla słowa t, dokumentu d oraz zbioru dokumentów D, tf-idf jest iloczynem dwóch funkcji: tf(t, d) (częstość słowa) oraz idf(t, D) (odwrotna częstość dokumentu). Częstość słowa w dokumencie (tf) może być liczbą wystąpień danego słowa t w dokumencie d: tf(f, d) = f(t, d). Istnieją również inne funkcje wykorzystywane przy obliczeniu tf. Są to m.in. częstość występowania skalowana logarytmicznie oraz znormalizowana częstość występowania [28]. Częstość skalowana logarytmicznie wyrażona jest wzorem 2.10 [28]. tf(t, d) = 1 + logf(t, d) (2.10) Częstość znormalizowana wykorzystuje zwykłą częstość występowania słowa podzieloną przez liczbę wystapień najczęstszego słowa w dokumencie. Funkcja dana jest wzorem 2.11 [28]. tf(t, d) = 0, 5 + 0, 5 f(t, d) max{f(w, d) : w d} (2.11) Odwrotna częstość dokumentu (idf) jest natomiast miarą, która mówi jak dużo informacji dane słowo dostarcza. Miara ta zależy od tego, czy słowo często występuje we wszystkich dokumentach. Odwrotna częstość dokumentu obliczana jest jako logarytm z ilorazu całkowitej liczby dokumentów przez liczbę dokumentów zawierających dane słowo. Funkcja dana jest wzorem 2.12 [28]. N idf(t, D) = log d D : t d (2.12)

2.2. Metoda filtracji na podstawie zawartości 13 gdzie: N liczba wszystkich dokumentów d D : t d - liczba dokumentów, w której wystepuje słowo t. Jeżeli słowa t nie ma w żadnym dokumencie, trzeba uważać na próbę wykonania dzielenia przez zero. Końcowy wzór na tfidf określony jest wzorem 2.13 [28]. tfidf(t, d, D) = tf(t, d) idf(t, D) (2.13) 2.2.2. Klasyfikator Bayesa Podejście wykorzystujące klasyfikator Bayesa zostało przedstawione w pracy [23]. Jest to model prawdopodobieństwa warunkowego p(cj F 1,, F n ) gdzie C j jest klasą a F i to pewne właściwości dokumentu. Prawdopodobieństwo, że dokument d jest w klasie C j jest obliczane za pomocą wzoru 2.14. P (C j d) = P (C j) P (d C j ) P (d) (2.14) Zakładając, że cechy dokumentu są niezależne, można przedstawić wyrażenie 2.14 w postaci wzoru 2.15: P (C j d) = P (Cj) n P (F i C j ) i=1 P (F 1,, F n ) (2.15) Z racji tego, że mianownik jest niezależny od d, wystarczy wyznaczyć licznik. Dla C j (czyli ostatecznej oceny w przypadku 5 gwiazdowej skali C j 1, 2, 3, 4, 5) P (C j d) mówi o tym, z jakim prawdopodobieństwem dany przedmiot otrzyma od użytkownika ocenę C j. Ostateczne oszacowanie oceny użytkownika wyrażone jest wzorem 2.16. C = argmax Cj P (C j ) P (d C j ) P (d) (2.16) 2.2.3. Zalety i wady W przypadku algorytmów z filtrowaniem na podstawie zawartości nie ma problemu zimnego startu. Dla użytkownika mającego małą liczbę ocenionych restauracji algorytm wciąż jest w stanie stworzyć odpowiednie dla użytkownika rekomendacje na podstawie opisu i atrybutów restauracji. Wadą podejścia wykorzystującego filtrowanie na podstawie zawartości jest to, że atrybuty przypisywane obiektom często nie oddają całości obrazu i wszystkich informacji o tym, jaki w rzeczywistości jest dany obiekt. Na przykład dla problemu rekomendacji restauracji możliwe jest określenie w prosty sposób typu restauracji, jak np. włoska`` czy

2.3. Metoda spersonalizowanego uczenia oceniania 14 azjatycka``. Nie jest natomiast proste przekazanie informacji na przykład o tym, jaki klimat panuje w danej restauracji, czy obsługa jest miła itp. Co więcej, w systemach rekomendujących takie obiekty, jak wiadomości, czy artykuły, istnieje problem, polegający na tym, że rekomendowane są kolejne artykuły dotyczące tego samego tematu, co dotychczas przeczytane artykuły, mimo że nie wnoszą już żadnych nowych informacji ani nie przekazują niczego odkrywczego w stosunku do poprzednich, podobnych artykułów. Eksploracja przestrzeni może być niezadowalająca. 2.3. Metoda spersonalizowanego uczenia oceniania W praktyce wynikiem działania systemu rekomendacji jest uporządkowana lista z obiektami. Niekoniecznie interesują nas przewidywane oceny, jakie użytkownik wystawiłby obiektom, natomiast interesuje nas kolejność obiektów na wynikowej liście rekomendacji. System spersonalizowanego uczenia oceniania zajmuje się optymalizacją n elementowych list (top n), zawierających rekomendowane obiekty, spersonalizowane pod kątem użytkownika, które są mu następnie prezentowane [26]. Algorytmy typu spersonalizowanego uczenia oceniania zostały podzielone na trzy grupy, stosujące różne podejścia: podejście punktowe ( pointwise") - w tym podejściu zakłada się, że każdej parze użytkownik - rekomendowy obiekt, przypisany jest jakiś wynik, np. jakaś liczba. Jest to tradycyjne podejście. Problem do rozwiązania polega na przewidzeniu oceny użytkownika dla danego obiektu. Wykorzystywane są metody klasyfikacji oraz regresji. podejście zajmujące się parami ( pairwise") - w tym podejściu stara się zminimalizować liczbę inwersji w liście rankingowej, tj. liczbę takich par obiektów, które powinny być w odwrotnej kolejności na wynikowej, rekomendowanej liście. Jest to problem binarnej klasyfikacji. Klasyfikator ma za zadanie ocenić, który z pary obiektów rekomendowanych jest preferowany względem drugiego. podejście zajmujące się listami ( listwise") - w tym podejściu oceniane są całe listy z obiektami rekomendowanymi. 2.4. Metoda wykorzystująca kontekst W systemach wykorzystujących kontekst używane są dodatkowe informacje, które wpływają na preferencje użytkownika, takie jak np. czas, nastrój itp. W tym podejściu oceny są zdefiniowane nie jako dwuargumentowe funkcje przedmiotów i obiektów rekomendowanych, ale jako funkcje przedmiotów, obiektów i kontekstu. W systemach nie wykorzystujących kontekstu, dane wykorzystywane do rekomendacji to zbiór użytkowników, obiektów oraz ocen. System rekomendujący wykorzystuje

2.5. Hybrydowe systemy rekomendujące 15 funkcję, która szacuje nieznane jeszcze oceny użytkowników, na podstawie tych danych. Wykorzystując tą funkcję dla konkretnego użytkownika, otrzymuje się listę przedmiotów dla Niego rekomendowanych. W przypadku systemu wykorzystujęcego kontekst, dane zawierają informacje o kontekście wystawianej oceny przez danego użytkownika. Ta dodatkowa informacja może być zastosowana w różnym momencie procesu tworzenia rekomendacji. Ze względu na sposób, w jaki wprowadza się informację o kontekście do rekomendacji, został zaproponowany [19] podział systemów wykorzystujących kontekst na trzy typy: systemy wprowadzające kontekst do wejścia algorytmu rekomendującego ( contextual pre-filtering``) - kontekst wykorzystywany jest do filtrowania danych przekazywanych na wejście algorytmu rekomendującego w taki sposób, aby były brane pod uwage jedynie dane ważne z punktu widzenia danego kontekstu systemy wprowadzające kontekst do wyjścia algorytmu rekomendującego ( contextual post-filtering``) - kontekst wykorzystywany jest do filtrowania wyników algorytmów rekomendacji systemy wykorzystujące model z kontekstem ( contextual modelling``) - zamiast wykorzystywania dwuwymiarowych (użytkownik - obiekt) funkcji w algorytmach rekomendujących, stosowane są wielowymiarowe funkcje biorące pod uwagę kontekst. Przykładowo funkcje podobieństwa biorą pod uwagę kolejne elementy kontekstu, jak np. czas, miejsce pobytu, czy też zadeklarowany przez użytkownika nastrój. 2.5. Hybrydowe systemy rekomendujące Hybrydowe systemy rekomendujące tworzone są w celu zwiększenia wydajności oraz uniknięcia niektórych problemów napotkanych przy wcześniej wymienionych rozwiązaniach. Poniżej przedstawiono kilka typów hybrydowych systemów rekomendujących. Poniżej opisane typy systemów rekomendujących zostały zaproponowane w pracy [21]. 2.5.1. Ważone systemy rekomendujące Ważone systemy rekomendujące są systemami, których wynik jest obliczany na podstawie wszystkich dostępnych w systemie algorytmów rekomendujących. W zależności od wag, większy, bądź mniejszy wpływ na przewidywaną ocenę danego przedmiotu ma jego wynik w jednym, bądź drugim algorytmie. Wagi mogą być dynamiczne, zwiększane lub zmniejszane w zależności od tego, czy rekomendacje zostały pokryte przez samego użytkownika czy nie.

2.5. Hybrydowe systemy rekomendujące 16 2.5.2. Przełączane systemy rekomendujące Są to systemy, które na podstawie wewnętrznego mechanizmu, progu przełączają używany algorytm rekomendujący. Przełączanie następuje na przykład wtedy, kiedy aktualny algorytm nie da żadnych rezultatów, jego rezultaty obarczone są dużą niepewnością, bądź też niezależnie od wyników rekomendacji, po zdefiniowanej ilości użyć aktualnego algorytmu. Rozwiązanie takie pozwala na możliwość większej eksploracji przestrzeni rekomendowanych przedmiotów. W pewnym momencie, w rekomendowanych przedmiotach możemy otrzymać dotychczas nieproponowane pozycje, niezwiązane ściśle z dotychczas rekomendowanymi przedmiotami, ale nadal istotne z punktu widzenia użytkownika. 2.5.3. Połączone systemy rekomendujące Przykładem łączonego systemu rekomendującego jest wykorzystanie zarówno metody zbiorowej filtracji, jak i metody filtracji na podstawie zawartości, poprzez połączenie wyników tych algorytmów w jedną rekomendację. Takie rozwiązanie pozwala uniknąć problemu nowego przedmiotu w systemie, dzięki użyciu filtracji na podstawie zawartości oraz ma cechę większej eksploracji przestrzeni, dzięki zastosowaniu zbiorowej filtracji. 2.5.4. Systemy rekomendujące połączone poprzez stworzenie nowej cechy To podejście traktuje wynik działania metody zbiorowej filtracji jako kolejną z właściwości rekomendowanego przedmiotu w algorytmie filtracji na podstawie zawartości. Pozwala to na korzystanie z danych pozyskanych od preferencji innych użytkowników bez bezpośredniego zajmowania się nimi a jedynie za pośrednictwem algorytmu zbiorowej filtracji. 2.5.5. Kaskadowe systemy rekomendujące Kaskadowe systemy rekomendujące łączą działanie dwóch algorytmów rekomendujących w taki sposób, że pierwszy algorytm jest wykorzystywany do określenia wstępnego zbioru rekomendowanych obiektów, natomiast drugi algorytm wykorzystuje wstępny zbiór, wybierając z niego elementy wchodzące do ostatecznego zbioru rekomendowanych restauracji. 2.5.6. Systemy rekomendujące poszerzające zbiór cech obiektów Systemy poszerzające zbiór cech obiektów wykorzystują informacje uzyskane poprzez wyniki jednego algorytmu rekomendującego. Informacje te są przetwarzane i wykorzystywane do zmodyfikowania danych wejściowych drugiego algorytmu rekomendującego. Przykładem jest system opisany w pracy [29]. W systemie tym rekomendowane są książki

2.6. Ocena działania systemu rekomendującego 17 przy pomocy danych z systemu rekomendacji Amazon, dzięki któremu dane o książkach zostały poszerzone o takie informacje, jak powiązani autorzy`` oraz powiązane tytuły``. Tak wzbogacone dane zostały następnie użyte w systemie wykorzystującym filtrację na podstawie zawartości. Systemy poszerzające zbiór cech obiektów są podobne do systemów rekomendujących połączonych przez stworzenie nowej cechy. Jednak, w przypadku systemów połączonych przez stworzenie nowej cechy, wykorzystywane są bezpośrednie wyniki jednego z algorytmów do stworzenia nowej cechy. W systemach poszerzających zbiór cech obiektów informacje pochodzące z jednego z algorytmów są przetworzone i zinterpretowane, najczęściej przez oprogramowanie pośredniczące. 2.5.7. Systemy rekomendujące połączone za pomocą modelu Systemy rekomendujące połączone za pomocą modelu wykorzystują jeden algorytm rekomendacji do stworzenia modelu, który następnie jest przekazywany jako wejście do drugiego algorytmu rekomendacji. Przykładowo, pierwszy algorytm tworzy pewien zbiór rekomendowanych obiektów, który jest opisem obszaru zainteresowań użytkownika. Zbiór ten zostaje następnie wykorzystany jako wejściowy model przekazany na wejście drugiego algorytmu rekomendującego. Inaczej niż w przypadku kaskadowych systemów rekomendacji oraz systemów poszerzających zbiór cech, w systemach połączonych za pomocą modelu, algorytm tworzący ostateczny zbiór rekomendacji nie wykorzystuje oryginalnych danych wejściowych dla całego systemu, a wyłącznie rezultat działania algorytmu tworzącego model. W przypadku kaskadowych systemów rekomendacji, drugi z algorytmów w kaskadzie korzysta z rezultatów pierwszego algorytmu oraz pierwotnych danych o użytkowniku i jego preferencjach. W przypadku systemów poszerzających zbiór cech, główny algorytm rekomendacji, który tworzy ostateczny rezultat rekomendacji, korzysta z pierwotnych danych wprowadzonych na wejście systemu, które zostały jedynie poszerzone przez inny algorytm. Natomiast w systemach rekomendujących, gdzie wykorzystywane jest połączenie za pomocą modelu, główny algorytm korzysta wyłącznie z modelu stworzonego przez inny algorytm. Jest to pewnego rodzaju zamiana danych wejściowych. 2.6. Ocena działania systemu rekomendującego Aby podjąć próbę porównania działania algorytmów rekomendujących należy ocenić te algorytmy. Znane są dwa podejścia: ocena systemu, który jeszcze nie został udostępniony użytkownikom (offline) oraz ocena systemu w trakcie jego faktycznego działania (online). Podejścia te zostały opisane w pracy [31].

2.7. Podsumowanie i wybór algorytmów 18 2.6.1. Ocena offline Jednym ze sposobów oceny systemu rekomendującego jest ocena offline. Polega na zebraniu zbioru danych o użytkownikach z pewnego okresu. Najlepiej żeby to były dane czysto losowe, nie zawierające żadnego śladu wzorca, powtarzalności bądź tendencji. Aby stworzyć ocenę offline należy symulować działanie systemu w stanie, kiedy część danych nie została jeszcze do niego wprowadzona. Część danych jest ukrywana. Optymalnie, jeżeli przechowywane są informacje o czasie, ukrywa się dane od jakiegoś wybranego punktu w historii działania systemu, a następnie wykonuje się algorytmy rekomendujące, porównując ich wyniki z rzeczywistymi preferencjami użytkownika. Następnie, iteracyjnie, w kolejnych wywołaniach algorytmu rekomendującego można uzupełniać dane uzyskiwane w kolejnych odstępach czasowych, symulując zmiany w preferencjach użytkowników w czasie i testując sposób radzenia sobie z nimi w systemie. Prostszym podejściem do problemu jest losowe wybranie zbioru użytkowników oraz losowe wybranie momentu w czasie, od którego zakrywane są dane o wybranych użytkownikach. W takim stanie systemu należy wykonać algorytmy rekomendacji i porównać ich wyniki z zakrytymi preferencjami. Innym podejściem jest założenie, że czas nie gra roli i nie wpływa na preferencje użytkownika. Należy przysłonić systemowi pewną liczbę losowych użytkowników oraz pewną liczbę losowych preferencji tych użytkowników, a następnie wykonać algorytmy rekomendacji. 2.6.2. Ocena online Systemy rekomendacji mogą służyć do wpływu na preferencje i decyzje użytkowników. Dlatego też czasem zamiast badać, jak dobrze algorytmy rekomendujące potrafią przewidzieć preferencje użytkowników, testuje się to, jak bardzo wyniki rekomendacji wpływają na preferencje i decyzje użytkowników. Jednym ze sposobów na zmierzenie tego jest sprawdzenie, czy użytkownicy bardziej, bądź mniej podążają za rekomendacjami, czy kupują rekomendowane przedmioty itp. Ocena takiego wpływu stanowi ocenę online. 2.7. Podsumowanie i wybór algorytmów Istnieje wiele algorytmów i podejść, które można wykorzystać przy implementacji systemu rekomendującego. Jak widzimy, różne podejścia posiadają różne wady i zalety. Wybór metody może być zależny od rodzaju implementowanego systemu, bądź też od założonych do osiągnięcia celów. W moim systemie zdecydowałem się na implementację

2.8. Implementacja wybranych algorytmów rekomendujących 19 dwóch algorytmów, opierających się na metodzie zbiorowej filtracji oraz jednego, opierającego się na metodzie filtracji na podstawie zawartości. Wybór został podyktowany popularnością tych metod, a także dobrymi rezultatami, jakie te metody oferują. 2.8. Implementacja wybranych algorytmów rekomendujących System został oparty na połączeniu trzech algorytmów: dwóch opierających się na metodzie zbiorowej filtracji oraz jednego opierającego się na metodzie filtracji na podstawie zawartości. Stworzony system łączy wyniki tych trzech algorytmów w jedną listę i taką rekomendację przedstawia użytkownikowi. Jest to więc połączony system rekomendacji. Poniżej opisuję szczegóły implementacji tych trzech algorytmów. 2.8.1. Metoda filtracji na podstawie zawartości Do stworzenia algorytmu posłużyłem się podejściem, które nie agreguje wiedzy o upodobaniach użytkownika, natomiast bazuje na podobieństwie pomiędzy wszystkimi przedmiotami już ocenionymi przez użytkownika, a przedmiotem, którego ocenę staramy się przewidzieć. Posłużyłem się klasyfikatorem Bayesa. Zastosowanie klasyfikatora Bayesa Wykorzystując wcześniej opisany model prawdopodobieństwa warunkowego p(c j F 1,, F n ), gdzie C j jest możliwą przewidywaną oceną danej restauracji, a F i to pewne właściwości (atrybuty) restauracji oraz zakładając niezależność atrybutów, prawdopodobieństwo, że restauracja z atrybutami F = (F 1,, F n ) otrzyma ocenę C j dane jest wzorem 2.17. P (C j F ) = P (C f ) n P (F i C j ) i=1 P (F 1,, F n ) (2.17) Przykładowo P (5 F ) = 0, 6 oznacza, że użytkownik oceni restaurację z atrybutami F na 5 gwiazdek z prawdopodobieństwem 60%. W przypadku mojego systemu C j {1,..., 5} - od jednej do pięciu gwiazdek. Naszym oszacowaniem oceny użytkownika zostanie liczba gwiazdek, która uzyska największe prawdopodobieństwo wystąpienia (wzór 2.18). p u,r = argmax Cj P (C j ) P (F C j ) P (F ) (2.18)

2.9. Porównanie zaimplementowanych algorytmów rekomendujących 20 2.8.2. Metoda zbiorowej filtracji Zarówno algorytm implementujący metodę zbiorowej filtracji z wykorzystaniem podobieństwa użytkowników, jak i podobieństwa obiektów jest odpowiednią implementacją wzorów (2.1) oraz (2.5). Do obliczenia podobieństwa pomiędzy użytkownikami oraz podobieństwa pomiędzy przedmiotami został wykorzystany współczynnik korelacji Pearsona. 2.9. Porównanie zaimplementowanych algorytmów rekomendujących Porównanie zaimplementowanych algorytmów zostało przeprowadzone z użyciem podejścia testowania systemu offline. System nie ma aktualnie pracujących na nim użytkowników, więc podejście wykorzystujące ocenę online było niemożliwe. 2.9.1. Dane testowe Do testowania zostały wykorzystane dane o restauracjach oraz ocenach użytkowników z konkursu serwisu Yelp 1. Dane zapisane są w plikach w formacie JSON. Pliki te przechowują informacje o: 366 715 użytkownikach 1 569 264 ocenach miejsc przez użytkowników 60 785 miejscach Wśród powyższych danych znajduje się wiele informacji, które nie dotyczą restauracji. Informacje takie zostały przefiltrowane. Do systemu zostały wprowadzone dane, które zawierają wyłącznie informacje o restauracjach oraz o preferencjach użytkowników w stosunku do restauracji. Przykładowo, do systemu nie zostały wprowadzone m.in. dane o takich miejscach, jak kliniki ortodontyczne, czy warsztaty samochodowe. Po przefiltrowaniu danych, do bazy danych systemu zostały wprowadzone informacje o: 269 231 użytkownikach, którzy ocenili chociaż jedną restaurację 958 777 ocenach restauracji przez użytkowników 21 892 restauracjach (informacje o kategorii oraz o cenach w lokalu) 2.9.2. Sposób oceny algorytmów Oceny użytkowników zostały podzielone w losowy sposób na dwie części: 1 http://www.yelp.pl/dataset_challenge

2.9. Porównanie zaimplementowanych algorytmów rekomendujących 21 zbiór uczący (stanowiący 80% wszystkich ocen) zbiór testujący (stanowiący pozostałe 20% wszystkich ocen) Każdy z algorytmów został wykorzystany do przewidzenia oceny ze zbioru testującego, posługując się danymi ze zbioru uczącego. Do oceny dokładności przewidywania zostały wykorzystane miary: średni błąd bezwzględny (mean average error - MAE) oraz pierwiastek błędu średniokwadratowego (rooted mean squared error - RMSE). MAE jest średnią z różnic pomiędzy przewidywaną oceną a rzeczywistą oceną użytkownika. MAE jest obliczana za pomocą wzoru 2.19. gdzie: n liczba testowanych ocen 1 n n p k r k (2.19) k=1 p k - ocena przewidywana przez system r k - faktyczna ocena użytkownika Interpretacja wyniku jest prosta. Przykładowo dla MAE = 1.5 oznacza, że algorytm przewiduje średnio ocenę o półtorej gwiazdki`` źle - w jedną czy drugą stronę. RMSE natomiast jest obliczany za pomocą wzoru 2.20. 1 n n (p k r k ) 2 (2.20) k=1 Właściwością tej miary jest to, że algorytm jest gorzej oceniany, gdy zdarzają się pojedyncze duże błędy w oszacowaniu oceny, niż gdy pojedyncze błędy w oszacowaniu oceny są mniejsze, ale w większej liczbie oszacowań. Na rysunku 2.1 przedstawiona jest część tabeli bazy danych, w której znajdują się wprowadzone do systemu testowe dane. Test, który został wykonany, polega na przewidzeniu ocen preferencji, które są w zbiorze testującym, a następnie porównanie wyniku z faktycznymi danych. Przykładowo, jeżeli dane z rysunku 2.1 byłyby zbiorem testującym, to we wzorze 2.19 oraz we wzorze 2.20 liczba testowanych ocen n wyniosłaby 16, oceny r k byłyby kolejnymi liczbami z kolumny score (liczba gwiazdek wystawiona restauracjom przez użytkowników), natomiast przewidywane oceny p k byłyby kolejnymi oszacowaniami preferencji użytkowników, stworzonymi przez dany algorytm rekomendujący na podstawie danych ze zbioru uczącego. Na rysunku 2.2 przedstawiona jest część tabeli bazy danych zawierająca informacje o restauracjach. Dane te wykorzystywane są przez zaimplementowany algorytm filtracji na podstawie zawartości.

2.9. Porównanie zaimplementowanych algorytmów rekomendujących 22 Rysunek 2.1. Część tabeli z testowymi danymi o preferencjach użytkowników.

2.9. Porównanie zaimplementowanych algorytmów rekomendujących 23 Rysunek 2.2. Część tabeli z testowymi danymi o restauracjach. Tablica 2.1. Wyniki oceny algorytmów rekomendacji algorytm MAE RMSE zdolność oceny (%) user-user collaborative filtering 0.9615 1.3057 64.5 item-item collaborative filtering 0.9380 1.2128 61.6 content-based filtering 1.3130 1.8561 82.7 2.9.3. Wyniki przeprowadzonych testów Każdy z algorytmów miał do oszacowania 191 772 preferencji użytkowników (zbiór testujący - 20% wszystkich danych o preferencjach użytkowników względem restauracji). Testy zostały wykonane na komputerze stacjonarnym z dwurdzeniowym procesorem Intel i5. Czasy wykonywania algorytmów to odpowiednio: algorytm zbiorowej filtracji wykorzystujący podobieństwo obiektów: 33,9980 sekundy, algorytm zbiorowej filtracji wykorzystujący podobieństwo użytkowników: 26,4609 sekundy, algorytm filtracji na podstawie zawartości: 5,5970 sekundy. W tabeli 2.1 przedstawiono wyniki testów przeprowadzanych na wszystkich trzech algorytmach. Dla danego zbioru danych lepiej poradziły sobie algorytmy z grupy algorytmów zbiorowej filtracji, które myliły się średnio o mniej niż jedną gwiazdkę``, w

2.9. Porównanie zaimplementowanych algorytmów rekomendujących 24 przeciwności do algorytmu filtracji na podstawie zawartości. W przypadku algorytmu filtracji na podstawie zawartości zdarzało się również więcej pojedynczych dużych błędów w oszacowaniu oceny. Powodem słabszej zdolności algorytmu filtracji na podstawie zawartości do oceny może być niewystarczająca korelacja ocen użytkowników z atrybutami przypisywanymi restauracjom. Wydaje się, że kombinacja atrybutów takich jak np. pizzeria`` oraz tania restauracja`` niekoniecznie musi nieść wystarczająco dużo informacji o restauracjach. Fakt, że jedna z takich restauracji była dobrze oceniona przez któregoś z użytkowników niekoniecznie musi świadczyć o podobnym sukcesie innej restauracji. Przykładowo, użytkownik, który wysoko ocenia pizzerię z sieci Trattoria``, niekoniecznie musi zasmakować się w wypiekach Telepizzy``, mimo, że posiadają te same atrybuty. Co więcej, zauważalne jest to, że restauracje należące do tych samych sieci (co praktycznie zawsze oznacza ten sam zbiór atrybutów) różnią się w jakością usług. Zaletą algorytmów filtracji na podstawie zawartości jest możliwość rekomendacji użytkownikowi wielu restauracji mimo posiadania niewielu informacji o jego preferencjach. Przygotowując oszacowanie ocen użytkowników ze zbioru testującego, algorytmy zbiorowej filtracji były w stanie oszacować w niewiele ponad 60% oceny użytkowników. W pozostałych przypadkach oceny były niezdefiniowane z powodu niewystarczającej informacji o użytkownikach. Algorytm filtracji na podstawie zawartości był natomiast w stanie zadziałać w ponad 80% przypadków. Zdolność tą można także powiększyć, zwiększając dziedzinę atrybutów oraz przydzielając restauracjom większą ich liczbę. W przypadku zaimplementowanego algorytmu filtracji na podstawie zawartości powodem, dla którego niektóre oceny użytkownika nie mogły zostać przewidziane (nie były zdefiniowane) przez algorytm jest to, że restauracje te miały zupełnie różny zbiór atrybutów w porównaniu ze zbiorem atrybutów wszystkich restauracji, które użytkownik ocenił w zbiorze uczącym. W przypadku algorytmu zbiorowej filtracji z podobieństwem użytkowników, podstawowy powód tego, że niektóre oceny użytkowników nie zostały przewidziane (zdefiniowane) to fakt, że niektórzy użytkownicy mieli niewystarczająco dużo ocen w zbiorze uczącym (np. stosunkowo nowi użytkownicy). Z tego powodu z daną osobą można było porównać tylko niewielką liczbę użytkowników (określić współczynnik podobieństwa między nimi). Natomiast, jeżeli użytkownik miał niewielki zbiór użytkowników podobnych, to było możliwe, że żaden z tych użytkowników podobnych nie ocenił danej restauracji, więc algorytm nie był w stanie oszacować oceny użytkownika.

2.9. Porównanie zaimplementowanych algorytmów rekomendujących 25 Analogiczna sytuacja miała miejsce przy obliczeniach prowadzonych w algorytmie zbiorowej filtracji z podobieństwem obiektów. W tym przypadku, dla restauracji z niewielką liczbą wystawionych ocen, algorytm określił niewielką liczbą restauracji podobnych. Z tego też powodu nie było możliwe oszacowanie oceny użytkownika dla tej restauracji, ponieważ zbiór restauracji ocenionych dotychczas przez użytkownika (tzn. będących w zbiorze uczącym) nie miał elementów wspólnych z małym zbiorem restauracji podobnych. Wyniki potwierdzają więc wnioski z teoretycznej analizy algorytmów. Rezultaty oceny algorytmów mogłyby się jednak zmienić, w szczególności, gdyby system pracował na innej dziedzinie danych, np. rekomendując artykuły na stronie internetowej. Inna dziedzina atrybutów oraz ich specyfika mogłaby zmienić rezultaty powyższej oceny.

3. Specyfikacja wymagań dla systemu W ramach pracy powstał system rekomendujący restauracje na urządzenia mobilne. System powinien mieć możliwość tworzenia rekomendacji restauracji na podstawie upodobań kulinarnych użytkownika, którego profil jest poznawany za pomocą aplikacji, która zbiera informacje o historii pobytów użytkownika w restauracjach oraz o jego preferencjach. System powinien wykorzystywać takie elementy jak geolokalizacja oraz algorytmy rekomendujące. Poniżej znajduje się opis proponowanego systemu oraz wymagania. 3.1. Opis systemu i interakcji użytkownika Użytkownik jest wyposażony w urządzenie mobilne, działające pod systemem Android, z zainstalowaną aplikacją. Użytkownik ma możliwość oceny dowolnej restauracji w systemie za pomocą przypisania jej pewnej ilości gwiazdek (od 1 do 5). Użytkownik ma również możliwość włączenia opcji śledzenia, dzięki czemu na podstawie lokalizacji GPS aplikacja zapisuje historię miejsc, w których użytkownik się zatrzymywał. Następnie, w jednym z widoków aplikacji, użytkownik ma możliwość podglądu swojej historii i przypisania swojej aktywności do okolicznych restauracji, w których przebywał. Tak zapisana informacja o pobycie użytkownika w restauracji jest później wykorzystywana do tworzenia rekomendacji. W przypadku, kiedy użytkownik pojawił się w restauracji, co do której nie określił jeszcze preferencji, system dodaje informację o ocenie danej restauracji przez użytkownika, wynoszącej średnią liczbę gwiazdek, przypisywaną przez tego użytkownika. Jeżeli użytkownik znajdzie się np. w nowym mieście i będzie poszukiwał restauracji, wybierze opcję rekomenduj, a następnie na podstawie historii aktywności użytkownika oraz lokalizacji, w której się znajduje, otrzyma rekomendowane dla niego restauracje wraz z opisem i zaznaczeniem restauracji na mapie. Co więcej, użytkownik ma możliwość wyszukiwania restauracji według kryteriów oraz synchronizacji ze swoim kontem na serwerze. 3.2. Wymagania funkcjonalne Tworzony system powinien mieć następujące funkcje:

3.3. Wymagania niefunkcjonalne 27 1. Utrzymywanie informacji o koncie użytkownika na serwerze. Serwer jest miejscem, przy którym działa baza danych systemu, w której przechowywane są wszystkie informacje o użytkownikach, ich preferencjach, historii restauracji w których byli oraz restauracjach. 2. Możliwość logowania się użytkownika na swoje konto z poziomu aplikacji. Aby otrzymać dostęp do swojego konta aplikacja, użytkownik ma możliwość zalogowania się do systemu. 3. Możliwość śledzenia poczynań użytkownika. Użytkownik może uruchomić usługę, która analizuje na bieżąco jego lokalizację i zapisuje w historii miejsca, w których się zatrzymywał. Użytkownik może później wykorzystać te informacje do zapisania w swojej historii restauracji, w której w tym czasie w przebywał. 4. Możliwość uzyskania rekomendacji restauracji z wykorzystaniem m.in. obecnej lokalizacji użytkownika. Użytkownik może odpytać system o rekomendowane restauracje, z uwzględnieniem miejsca w którym się znajduje. 5. Możliwość oceniania restauracji. Użytkownik może dowolnej restauracji w systemie przydzielić ocenę w skali od jednej do pięciu gwiazdek. 6. Możliwość wyszukiwania restauracji. Do dyspozycji użytkownika oddana jest prosta wyszukiwarka, w której może przeszukiwać restauracje wg nazwy, atrybutu lub adresu. 7. Możliwość zarządzania swoim kontem (dodawanie obecności w restauracji itp.) Użytkownik ma uprawnienia do prostych operacji administracyjnych w ramach swojego konta. 3.3. Wymagania niefunkcjonalne 1. Prosty i intuicyjny interfejs użytkownikami. Aplikacja mobilna musi mieć przejrzysty interfejs. 2. Bezpieczeństwo przesyłanych informacji. Dane przesyłane pomiędzy aplikacją oraz serwerem są danymi spersonalizowanymi

3.4. Wymagania dotyczące urządzenia 28 (jak np. lokalizacja użytkownika). Dane te nie mogą zostać wykradzione, ich transport musi się Fodbywać za pomocą bezpiecznych kanałów. 3. Możliwość zarządzania kontem offline (opcja późniejszej synchronizacji). Aplikacja działa także w środowisku offline, kiedy nie są wymagane dane z serwera. Możliwość późniejszej synchronizacji z kontem. 3.4. Wymagania dotyczące urządzenia 1. Urządzenie pracujące pod systemem Android 2.3 oraz wyższym. 2. Urządzenie z dostępem do sieci Internet. 3. Urządzenie najlepiej z wbudowanym modułem GPS. W przypadku braku takiego modułu mniej dokładna lokalizacja może odbywać się za pomocą informacji z sieci GSM.

4. Realizacja systemu rekomendacji restauracji System został stworzony w postaci aplikacji mobilnej na system Android oraz aplikacji uruchamianej w serwerze aplikacyjnym. Język wykorzystany do tworzenia aplikacji to Java w wersji 1.7. Aplikacja serwera została stworzona z wykorzystniem technologii Java Enterprise Edition. Ze względu na konfigurację niektórych narzędzi, został również wykorzystany język znaczników XML. 4.1. Stosowane narzędzia W trakcie prac wykorzystane zostały narzędzia wspomagające tworzenie aplikacji. Użyte zostało środowisko Eclipse do tworzenia zarówno aplikacji serwera, jak i aplikacji mobilnej. Do budowania aplikacji mobilnej użyta została wtyczka Android Development Tools. Wtyczka ta umożliwia m.in także wyświetlanie logów z urządzenia lub emulatora systemu Android, a także zaawansowane opcje śledzenia błędów (debug). Do budowania aplikacji serwera został wykorzystany program Maven w wersji 3.0.5, automatyzujący zarządzenie i budowanie aplikacji. Dodatkowo wykorzystany został system kontroli wersji Git, dzięki któremu możliwe było utrzymywanie repozytorium kodu. Aplikacja pod system Android jest uruchamiana na urządzeniu Sony Ericsson Neo V z Androidem w wersji 2.3.7. Zostało wykorzystane fizyczne urządzenie zamiast emulatora systemu Android, głównie z powodu powolnego działania emulatora oraz problemów z dostępnością serwisów udostępnianych przez Google ( Google Play Services``) w systemie uruchamianym na emulatorze. 4.2. Wykorzystane technologie Poniżej znajduje się krótki opis technologii wykorzystywanych w trakcie tworzenia systemu. 4.2.1. Android SDK Android SDK (Software Development Kit) [5] jest pakietem dostarczającym narzędzia i biblioteki wykorzystywane przy tworzeniu aplikacji na system Android. Pakiet zawiera m.in. emulator systemu, kompilator i narzędzie pozwalające zarządzać obrazami różnych wersji systemu.

4.2. Wykorzystane technologie 30 4.2.2. Google Maps Android API v2 Google Maps Android API v2 [9] umożliwia wykorzystanie map Google na urządzeniu Android. Umożliwia wyświetlanie i zarządzanie mapą na telefonie, a także rysowanie linii, punktów i innych obiektów na mapie. 4.2.3. JSON JSON jest lekkim formatem wykorzystywanym przy przesyłaniu danych. Została wykorzystana darmowa biblioteka [14] wspomagająca mapowanie obiektów do formatu JSON oraz parsowanie plików w tym formacie. 4.2.4. Hibernate Hibernate [10] jest narzędziem do mapowania obiektowo-relacyjnego. Jedno z najpopularniejszych rozwiązań dostępnych na rynku. Oferuje jezyk zapytań Hibernate Query Language (HQL), alternatywny do SQL, który opiera się na obiektach Hibernate. Dokładniejszy opis znajduje się w sekcji 5.2. 4.2.5. Baza danych Postgresql Postgresql [17] jest jedną z najpopularniejszych i najbardziej zaawansowanych otwartych relacyjnych baz danych na rynku. W moim projekcie posłużyłem się tą bazą do przechowywania danych po stronie serwera. Wykorzystana została wersja 9.3. 4.2.6. JBoss AS JBoss AS [13] jest serwerem aplikacyjnym Java, tworzony przez firmę RedHat. Wykorzystana została darmowa i otwarta wersja 7.1.1. Serwer umożliwia uruchomienie aplikacji Java pisanych zgodnie ze specyfikacją Java Enterprise Edition. JBoss AS implementuje w pełni usługi Java Enterprise Edition.

5. Architektura systemu rekomendacji restauracji Sposób działania zaimplementowanych algorytmów rekomendujących, które wymagają dostępu do informacji o wszystkich użytkownikach, powoduje to, że system zbudowany jest w architekturze klient-serwer, gdzie klientem jest aplikacja mobilna, natomiast serwerem jest aplikacja Java uruchamiana na serwerze aplikacyjnym Jboss Application Server 7.1.1, która oferuje m.in. usługę rekomendacji restauracji. Po stronie serwera znajduje się baza danych, w której przechowywane są informacje o restuaracjach, użytkownikach oraz ich preferencjach. Komunikacja między aplikacją mobilną a serwerem odbywa się za pomocą protokołu HTTPS przy użyciu formatu JSON. 5.1. Struktura systemu Na diagramach 5.1 oraz 5.2 przedstawiony jest podział aplikacji serwera oraz aplikacji mobilnej (klienckiej) na pakiety. Poniżej znajduje się szczegółowy opis tych diagramów. 5.1.1. Serwer Aplikacja serwera składa się z następujących pakietów: recommender - zawiera wszystkie klasy odpowiedzialne za algorytmy rekomendacji controllers - zawiera kontrolery odpowiedzialne za odpowiadanie na żądania klienta oraz wykonywanie akcji z nimi związanymi domain - zawiera klasy odpowiedzialne za komunikację z bazą danych utils - zawiera klasy pomocnicze, jak np. narzędzia do mapowania do formatu JSON oraz stałe pomocnicze common - zawiera klasy implementujące wspólne dla klienta i serwera interfejsy, definiujące przesyłane pomiędzy klientem i serwerem dane 5.1.2. Klient Aplikacja kliencka składa się z następujących pakietów: services - zawiera klasy odpowiedzialne za realizację usługi systemu Android mającą na celu śledzenie lokalizacji użytkownika

5.1. Struktura systemu 32 Rysunek 5.1. Diagram struktury aplikacji serwera. Rysunek 5.2. Diagram struktury aplikacji klienckiej.

5.2. Baza danych 33 Rysunek 5.3. Model fizyczny bazy danych serwera. activities - zawiera klasy odpowiedzialne za wszystkie widoki aplikacji domain - zawiera klasy odpowiedzialne za komunikację z lokalną bazą danych na urządzeniu Android utils - zawiera różne klasy oraz stałe pomocnicze common - zawiera klasy implementujące wspólne dla klienta i serwera interfejsy, definiujące przesyłane pomiędzy klientem i serwerem dane web - zawiera klasy odpowiedzialne za komunikację z serwerem 5.2. Baza danych Główna baza danych systemu znajduje się na serwerze i jest to baza danych Postgresql 9.3. Komunikacja z bazą danych odbywa się za pomocą sterownika JDBC bazy danych. Dodatkowo wykorzystane zostało narzędzie do mapowania obiektowo-relacyjnego - Hibernate. Rysunek 5.3 przedstawia model danych po stronie serwera. Każdy z użytkowników systemu (rrs user) ma w systemie zapisane informacje o zadeklarowanych przez siebie preferencjach w stosunku do pewnych restauracji (preference) oraz informacje o tym,

5.2. Baza danych 34 gdzie i kiedy w danej restauracji użytkownik się znajdował (event). Co więcej, każda z restauracji (restaurant) posiada pewien zbiór atrybutów (restaurant attribute). 1 @Entity @Table( name = "\" restaurant_attribute\"") public class RestaurantAttributeEntity implements RestaurantAttribute { 5 /* *... */ 10 private Integer Id; private RestaurantEntity restaurant; private String key; private String value; 15 @Id @GeneratedValue( strategy = GenerationType. IDENTITY) @Column( name = " id", unique = true, nullable = false) public Integer getid() { return Id; 20 } 25 public void setid( Integer Id) { this. Id = Id; } @ManyToOne @JoinColumn( name=" restaurant_id") public RestaurantEntity getrestaurant() { return restaurant; 30 } 35 40 public void setrestaurant( RestaurantEntity restaurant) { this. restaurant = restaurant; } @Column(name = "key") public String getkey() { return key; } public void setkey( String key) { this. key = key; } 45 @Column( name = " value") public String getvalue() { return value; } 50 public void setvalue( String value) { this. value = value; } }

5.2. Baza danych 35 Wydruk 5.1. Przykładowa klasa odwzorowywana na tabelę bazy danych Wydruk 5.1 przedstawia przykładową klasę, która jest używana przy odwzorowywaniu obiektowo - relacyjnym. Encja restaurant attribute jest ważnym elementem wykorzystywanym przez algorytm filtracji na podstawie zawartości. Wszystkie atrybuty restauracji, które są wykorzystywane do opisu restauracji są przechowywane właśnie przy pomocy tabeli restaurant attribute. Przykładowo, jeżeli restauracja z identyfikatorem 24 będzie miała przypisany atrybut Italian``, identyfikujący kategorię do której należy, to jeden z wierszy w tej tabeli będzie wyglądał następująco: (restaurant id, key, value) = (24, IDENTIFIER, Italian). Do konfiguracji odwzorowania obiektowo-relacyjnego przez Hibernate zostały użyte adnotacje. Wykorzystane zostały następujące adnotacje: Adnotacja @Entity deklaruje obiekt jako klasę używana w komunikacji z bazą danych. Adnotacja @Table pozwala nam wskazać wiersze której tabeli w bazie reprezentują instancje tej klasy. Adnotacja @Identifier wskazuje pole przechowujące identyfikator obiektu. Adnotacja @Column pozwala na wskaznie kolumny do wartości których odwołuje się dane pole klasy. Adnotacje @OneToMany i @ManyToOne pomagają wskazać relacje jeden do wielu po obu stronach tej relacji. Adnotacje @OneToMany i @ManyToOne posiadają możliwy do określenia opcjonalny element, mówiący o sposobie pobierania danych z bazy ( FetchType``). Możliwe opcje to ładowanie leniwe oraz ładowanie zachłanne. Ładownie leniwe polega na tym, że dane zostaną pobrane dopiero w momencie pierwszej próby dostępu do nich. Dzieki temu, przy pobieraniu danych z bazy nie są pobierane od razu dane z tabel podrzędnych, przez co pobieranie danych jest szybsze. Ładowanie zachłanne polega na natychmiastowym pobraniu wszystkich tabel podrzędnych. W moim projekcie wykorzystywane było leniwe ładowanie danych. Adnotacja @JoinColumn deklaruje się kolumnę, która uczestniczy przy łączeniu tabel. Poza testowaniem i porównywaniem algorytmów rekomendacji, które zostało wykonane z użyciem danych z serwisu Yelp (opis w sekcji 2.9), wykorzystano dane o restauracjach z serwisu Foursquare. Serwer przechowuje dane o lokalizacji i atrybutach restauracji, które zostały pobrane za pomocą udostępnionej przez Foursquare usługi. Jest to usługa RESTful, do skorzystania z której potrzeba zarejestrować swoją aplikację na stronie serwisu Foursquare. Dostępne jest 500 darmowych zapytań do usługi na użytkownika dziennie. Do pobrania danych o restauracjach za pomocą interfejsu Foursquare API wykorzystana została otwarta biblioteka [6] upraszczająca komunikację z serwisem Foursquare.

5.3. Silnik rekomendacji 36 5.3. Silnik rekomendacji Silnik rekomendacji zawiera klasy, w których zaimplementowane są algorytmy rekomendujące. Silnik jest stworzony w taki sposób, aby możliwe było ponowne jego wykorzystanie w innych aplikacjach. Dostęp do danych odbywa się za pomocą klasy implementującej interfejs, dzięki czemu silnik może pracować z różnymi źródłami danych. Za tworzenie rekomendacji odpowiadają trzy klasy: CFItemRecommender, CFUserRecommender oraz CBFRecommender, odpowiednio odpowiadające za algorytmy zbiorowej filtracji: z podobieństwem obiektów i z podobieństwem użytkowników oraz za algorytm filtracji na podstawie zawartości. Wykorzystanie tych klas jest proste i sprowadza się do wywołania odpowiedniej metody recommend(). Wydruk 5.2 przedstawia blok kodu serwera odpowiedzialny za tworzenie rekomendacji dla danego użytkownika. 1 @Controller @RequestMapping("/ recommend") public class RecommendController { 5 /* *... */ @RequestMapping( method = RequestMethod. GET) 10 public void recommend() { //... PreferenceDataModel preferencedatamodel = 15 new RestaurantPreferenceDataModel (); PearsonCorrelationSimilarity pearsoncs = new PearsonCorrelationSimilarity (); 20 // content - based filtering CBFRecommender cbfrecommender = new CBFRecommender( preferencedatamodel); 25 List < RestaurantScore > cbfrecommendedlist = cbfrecommender. recommend( user. getuserid ()); // collaborative filtering - item item similarity 30 CFItemRecommender cfitemrecommender = new CFItemRecommender( preferencedatamodel, pearsoncs); 35 40 List <ItemScore > cfitemrecommendedlist = cfitemrecommender. recommend( user. getuserid(), false); // collaborative filtering - user user similarity CFUserRecommender cfrecommender = new CFUserRecommender( preferencedatamodel, pearsoncs);

5.4. Użycie protokołu OAuth 2.0 37 List <ItemScore > cfuserrecommendedlist = cfrecommender. recommend( user. getuserid(), false); 45 // merge recommendation results List < RestaurantScore > mergedrestaurants = mergerecommendations( cbfrecommendedlist, Utils. fetch( cfuserrecommendedlist), 50 Utils. fetch( cfitemrecommendedlist) ); //... 55 } } Wydruk 5.2. Blok kodu odpowiedzialny za stworzenie list rekomendacji 5.4. Użycie protokołu OAuth 2.0 System rekomendacji przetwarza wrażliwe z punktu widzenia użytkownika dane, m.in. o jego lokalizacji. Z tego powodu system musi zapewnić odpowiednie mechanizmy bezpieczeństwa. Wykorzystany został protokół OAuth 2.0. OAuth jest otwartym standardem służącym do autoryzacji. Definiuje on proces autoryzacji osób trzecich do zasobów na serwerze. OAuth przewiduje cztery role [20]: 1. aplikację kliencką ( application``) która próbuje otrzymać dostęp do konta użytkownika 2. serwer z zasobami ( resource server``) używany do uzyskania dostępu do informacji o użytkowniku 3. serwer autoryzacji ( authorization server``) używany do sprawdzania tożsamości użytkownika i wydawania znaczników dostępu 4. właściciel zasobów ( user``) osoba, która daje dostęp do swojego konta/jego części Aby skorzystać z protokołu OAuth należy najpierw zarejestrować aplikację (klienta) w usłudze (na przykład w przypadku implementacji protokołu przez Google - Google API Console [7]). Po zarejestrowaniu, aplikacja otrzymuje swój identyfikator klienta (client ID) oraz tzw. sekret (client secret). Identyfikator klienta jest ogólnie znany, natomiast sekret musi pozostać tajemnicą. Ogólny proces autoryzacji przewidziany w protokole OAuth wygląda następująco [20]: 1. Pierwszym krokiem jest prośba aplikacji o autoryzację użytkownika.

5.4. Użycie protokołu OAuth 2.0 38 2. Jeżeli użytkownik zautoryzował, to aplikacja otrzymuje tzw. udzielenie (authorization grant). 3. Aplikacja wysyła prośbę o znacznik dostępu (access token) do serwera autoryzacji, prezentując udzielenie. 4. Jeżeli aplikacja została zidentyfikowana przez serwer i udzielenie jest poprawne, serwer zwraca znacznik dostępu. Koniec autoryzacji. 5. Aplikacja wysyła prośbę o zasób do serwera z zasobami, prezentując znacznik dostępu do uwierzytelnienia. 6. Jeżeli znacznik dostępu jest poprawny, serwer z zasobami daje dostęp aplikacji do zasobu. W aplikacji korzystam z usługi OAuth w wersji 2.0, oferowaną przez Google. Są różne scenariusze, które ta usługa wspiera. Wybrany został scenariusz cross-client identity`` [1], specjalnie przygotowany dla aplikacji złożonych z różnych modułów (w tym przypadku serwer oraz aplikacja mobilna). Celem tego scenariusza jest możliwość komunikacji aplikacji z serwerem z użyciem tzw. znacznika identyfikacji (ID Token). Dzięki temu nie musimy budować oddzielnego mechanizmu uwierzytalnienia na naszym serwerze. Do tego celu wykorzystujemy serwery Google oraz konto Google. Aplikacja na telefonie, po zalogowaniu się użytkownika, przesyła na serwer Google prośbę o znacznik identyfikacji, zawierający identyfikator naszego serwera (aplikacja serwera i aplikacja mobilna są zarejestrowane w Google API Console pod jednym projektem i posiadają swoje identyfikatory). Na rysunku 5.4 znajduje się ekran potwierdzenia zezwolenia dostępu aplikacji do konta Google, wyświetlany przy pierwszej próbie dostępu do konta przez aplikację. Serwer Google, po skonsolidowaniu tego, że aplikacja z danym identyfikatorem klienta jest w jednym projekcie z aplikacją mobilną, przesyła podpisany kryptograficznie przez Google znacznik identyfikacji. Znacznik identyfikacji zawiera pola z danymi, między innymi: pole email``, które identyfikuje użytkownika pole aud``, które identyfikuje nasz serwer (identyfikator naszego serwera z Google API Console) pole azp``, które identyfikuje aplikację mobilną (identyfikator aplikacji mobilnej z Google API Console) Znacznik powinien być przesyłany między modułami (aplikacją i serwerem) przez bezpieczny protokół - wykorzystany został HTTPS. Po otrzymaniu znacznika nasz serwer musi zweryfikować podpis kryptograficzny i sprawdzić, czy odpowiednie pole aud`` znacznika jest identyczne, jak identyfikator modułu serwera, otrzymany za pomocą rejestracji w Google API Console. Znacznik jest w postaci JSON Web Token``, dla której istnieją różne otwarte i darmowe biblioteki do weryfikacji. W projekcie wykorzystana jest biblioteka pochodząca od Google [8].

5.5. Lokalizacja geograficzna 39 Rysunek 5.4. Ekran potwierdzenia dostępu aplikacji do danych konta Google [2]. Po weryfikacji znacznika, moduł serwera może być pewien, że znacznik został wydany przez Google oraz, że znacznik był przesłany z urządzenia obsługiwanego przez użytkownika identyfikowanego przez pole email``. Serwer nie jest jednak pewien, czy komunikacja odbywa się za pomocą aplikacji, której globalny identyfikator znajduje się w polu azp`` znacznika, czyli w polu identyfikującym aplikację mobilną. Powodem może być używanie zrootowanych telefonów z systemem Android. Po uwierzytelnieniu, serwer wymienia z aplikacją informacje użytkownika, np. w trakcie synchronizacji konta. Wszelkie dane przesyłane są za pomocą HTTPS, w formacie JSON. 5.5. Lokalizacja geograficzna Większość współczesnych urządzeń mobilnych jest wyposażonych w nadajnik GPS. Dzięki niemu możliwe jest dokładne określenie położenia użytkownika. W przypadku smartfonów, oprócz nadajników GPS. wykorzystuje się także odbiorniki GSM oraz Wi-Fi. Dostarczają one jedynie przybliżone położenie, zazwyczaj jednak w krótszym czasie i z mniejszym wykorzystaniem energii.

5.5. Lokalizacja geograficzna 40 Odczyty położenia za pomocą sieci GSM odbywają się na podstawie siły sygnału pobliskich anten nadawczych. Dokładność tych metod zależy od koncentracji stacji nadawczych, w miastach jest zazwyczaj możliwe uzyskanie bardziej dokładnych pomiarów niż na terenie z gorszą infrastrukturą GSM. Odczyty za pomocą Wi-Fi polegają na odczycie siły sygnału pobliskich punktów dostępowych. Potrzebna jest jednak informacja o położeniach danych punktów dostępowych. Co więcej, nie jest to zasięg tak dostępny jak np. sieci komórkowej. Określenie położenia za pomocą sygnału z satelity jest sposobem, który wymaga połączenia się z satelitą, co może długo trwać. Sposób ten jest także kosztowny energetycznie. Kolejnym minusem jest to, że urządzenie musi działać w otwartym terenie, aby uzyskać informację z satelity. W aplikacji wykorzystane zostały dwa rozwiązania: w przypadku śledzenia aktywności użytkownika potrzebna była jak najbardziej dokładna informacja o położeniu użytkownika, więc do uruchomienia tej opcji potrzebne jest uruchomienie modułu GPS, natomiast w przypadku wyszukiwania pobliskich restauracji oraz rekomendacji restauracji znajdujących się w pobliżu, wykorzystano rozwiązanie dostarczone przez Google, zwane Fused Location Provider. Jest to rozwiązanie które łączy trzy poprzednie techniki i w zależności od zadeklarowanego priorytetu (dokładność, mały pobór mocy) dynamicznie dostarcza informacji o położeniu z różnych źródeł. W przypadku rekomendacji oraz wyszukiwania nie jest potrzebna bardzo precyzyjna lokalizacja, więc priorytet został ustawiony na zbalansowanie energii.

6. Testowanie W celu weryfikacji działania zbudowanego systemu zostały przeprowadzone testy aplikacji po stronie serwera oraz aplikacji mobilnej. Przeprowadzone zostały testy jednostkowe po stronie serwera oraz testy manualne, testujące aplikację na urządzeniu mobilnym, jak i sprawdzające współpracę serwera z aplikacją. 6.1. Testy jednostkowe Dla aplikacji serwera został stworzony specjalny kontroler, który po wysłaniu odpowiedniego zaptytania do serwera uruchamiał testy jednostkowe. Testy obejmowały: 1. testy bazy danych: operacje CRUD na tabelach, odwzorowanie obiektowo-relacyjne, obsługę obiektów ładowanych leniwie 2. test poprawności obliczeń algorytmu filtracji na podstawie zawartości 3. test poprawności obliczeń algorytmu zbiorowej filtracji z podobieństwem użytkowników 4. test poprawności obliczeń algorytmu zbiorowej filtracji z podobieństwem przedmiotów 5. test poprawności odwzorowania klas na obiekty JSON oraz obiektów JSON na klasy 6.2. Testy manualne Testy manualne służą do testownia aplikacji mobilnej oraz sprawdzeniu współpracy pomiędzy komponentami systemu - serwerem i aplikacją kliencką. Zostały przygotowane scenariusze testowe, a następnie zostały one wykonane na działającym systemie. Synchronizacja aplikacji z serwerem Kroki: 1. uruchomienie aplikacji 2. zaznaczenie opcji sync 3. zakończenie

6.2. Testy manualne 42 Rysunek 6.1. Aplikacja niezsynchronizowana z serwerem. Rysunek 6.2. Aplikacja po synchronizacji danych z serwerem. Oczekiwany rezultat: wyświetlenie listy historii odwiedzin restauracji oraz ukazanie się listy ocen restauracji pod opcją favourites. Przebieg testu: po nacisnięciu opcji synchronizacji pojawia sie pasek ładowania, a po chwili na ekranie wyświetla się lista z historią odwiedzin restauracji (nazwa restauracji i czas), zgodna z danymi w bazie danych. Proces synchronizacji pokazany jest na rysunkach 6.1 oraz 6.2. Co więcej, w zakładce favourites ukazuje się lista restauracji z ocenami, zgodna z danymi w bazie danych. W każdy z elementów tych list można przejść, po czym ukazuje się odpowiednio ekran edycji odwiedzin (z możliwością podglądu restauracji i edycji czasu) i ekran z podglądem restauracji (rysunek 6.3). Możliwy jest również podgląd restauracji na mapie (6.4). Wyszukiwanie restauracji Kroki: 1. uruchomienie aplikacji

6.2. Testy manualne 43 Rysunek 6.3. Widok podglądu restauracji. Rysunek 6.4. Lokalizacja restauracji na mapie. 2. przejście do opcji search w menu 3. wpisanie testowych danych w formularz wyszukiwania (nazwa restauracji oraz ewentualnie wybranie lokalizacji i promienia, w jakim ma znajdować się restauracja) 4. naciśniecie przycisku search 5. wyświetlenie listy wyszukanych restauracji 6. zakończenie Oczekiwany rezultat: wyświetlenie listy wyszukanych restauracji z informacją o odległości restauracji od miejsca, w którym się znajdujemy (jezeli wybraliśmy opcję lokalizacji). Przebieg testu: po wejściu w menu search (rysunek 6.5), do formularza wyszukiwania wpisana została nazwa restauracji, za pomocą przycisku get location zostały odczytane aktualne współrzędne za pomocą GPS a pole z promieniem zostało pozostawione bez zmian, z wartością domyślną (rysunek 6.6). Po wcisnięciu przycisku search ukazała się lista z restauracjami, mającymi w nazwie podaną frazę oraz odległości do tych restauracji (rysunek 6.7). Wszystkie restauracje mieszczą się w zadanym promieniu. Po przejściu

6.2. Testy manualne 44 w dany element listy można podejrzeć resztę informacji o restauracji oraz sprawdzić jej położenie na mapie. Rysunek 6.5. Opcje głównego menu. Rysunek 6.6. formularz wyszukiwania restauracji. kiwania Rysunek 6.7. Wyniki wyszu- restauracji. Rekomendacja Kroki: 1. uruchomienie aplikacji 2. przejście do opcji recommend w menu 3. wprowadzenie danych o lokalizacji za pomocą przycisku get location lub zaznaczenia miejsca na mapie) 4. naciśniecie przycisku recommend 5. wyświetlenie listy rekomendowanych restauracji 6. zakończenie Oczekiwany rezultat: wyświetlenie listy wyszukanych restauracji w porządku od najlepiej rekomendowanych do najmniej rekomendowanych, z uwzględnieniem lokalizacji. Przebieg testu: po wejściu w menu recommend, za pomocą przycisku get location zostały odczytane aktualne współrzędne, przy pomocy GPS. Po wcisnięciu przycisku recommend ukazała

6.2. Testy manualne 45 się lista z restauracjami rekomendowanymi przez system (rysunek 6.8). Restauracje te wyświetlają się w porządku od najlepiej ocenionych przez algorytmy rekomendujące, do najgorzej ocenionych. Przewidywana ocena jest wyświetlona przy nazwie restauracji. Po wejściu w dany element listy można podejrzeć resztę informacji o restauracji (rysunek 6.9) oraz sprawdzić jej położenie na mapie (rysunek 6.10). Rysunek 6.8. Wyniki rekomendacji. Rysunek 6.9. Podgląd rekomendownej restaracji. komendowanej Rysunek 6.10. Położenie re- restauracji. Śledzenie Warunki początkowe: 1. uruchomiony moduł GPS Kroki: 1. uruchomienie aplikacji 2. zaznaczenie opcji trace 3. przebycie pewnego dystansu 4. sprawdzenie zapisu o odwiedzonych miejsach 5. wyłączenie opcji trace 6. zakończenie

6.2. Testy manualne 46 Rysunek 6.11. Zapisane przez aplikację miejsca postoju. Oczekiwany rezultat: automatyczne dodanie do historii miejsc w których się zatrzymywaliśmy - w których potencjalnie byliśmy w restauracji. Przebieg testu: po wybraniu uruchomieniu opcji śledzenia przeszedłem się na spacer. Zatrzymywałem się w trzech miejscach na około 4-5 minut. Po spacerze, w historii śledzenia znalazły się miejsca w których się zatrzymywałem (rysunek 6.11), które były potencjalnymi miejscami, w których mogłem zatrzymać się, aby zjeść w restauracji. Dodanie nowej aktywności na podstawie historii śledzenia lokalizacji geograficznej Warunki początkowe: 1. niepusta historia śledzenia lokalizacji Kroki: 1. uruchomienie aplikacji

6.3. Podsumowanie testów 47 2. przejście do opcji manage w menu 3. przejście do pozycji show my activity 4. wybranie miejsca, z dostępnych rozpoznanych przez aplikację, w której się kiedyś zatrzymywaliśmy 5. wybranie restauracji znajdującej się w pobliżu tego miejsca 6. zapisanie nowej aktywności 7. zakończenie Oczekiwany rezultat: dodanie do historii odwiedzin restauracji nowej pozycji na podstawie historii śledzenia naszej lokalizacji geograficznej. Przebieg testu: na ekranie przedstawiającym historię śledzenia lokalizacji wybrałem istniejący testowy dostępny punkt (rysunek 6.12). Po zaznaczeniu, ukazały mi się pobliskie restauracje (rysunek 6.13). Następnie odświeżyłem listę pobliskich restauracji (rysunek 6.14), wybrałem jedną z restauracji i w nowym ekranie wybrałem datę pobytu i zatwierdziłem nową aktywność (rysunek 6.15). Nowe miejsce pobytu pojawiło sie na głównym ekranie aplikacji. 6.3. Podsumowanie testów Przeprowadzone testy miały za zadanie sprawdzenie poprawności działania systemu oraz komunikacji aplikacji z serwerem. Wszystkie przeprowadzone testy dały pozytywne wyniki, dzięki czemu jesteśmy w stanie stwierdzić, że system jest stabilny oraz, że spełnia stawiane mu wymagania.

6.3. Podsumowanie testów 48 Rysunek 6.12. Wybór lokalizacji rozpoznanej podczas śledzenia użytkownika. Rysunek 6.13. Wybór pobliskiej restauracji.

6.3. Podsumowanie testów 49 Rysunek 6.14. Przeszukanie wszystkich pobliskich restauracji. Rysunek 6.15. Potwierdzenie pobytu w restauracji.