Aanraden van een verscheidenheid aan recepten aan gebruikersgroepen met gebruik van verklaarbare hybride filtering

hybride filtering

aan gebruikersgroepen met gebruik van verklaarbare

Aanraden van een verscheidenheid aan recepten

Academiejaar 2019-2020

Master of Science in de industriële wetenschappen: informatica Masterproef ingediend tot het behalen van de academische graad van

Begeleider: prof. dr. ir. Toon De Pessemier

Promotoren: prof. dr. ir. Toon De Pessemier, prof. dr. ir. Luc Martens

Studentennummers: 01708568, 01503289

Laura Snyers, Phaedra Neirinck

Dankwoord

Deze thesis behandelde een onderwerp die ons beiden aansprak. Het was dan ook een aangename kennismaking met recommender systems.

Graag zouden we onze promotor Toon De Pessemier willen bedanken voor zijn antwoorden op de vele mails, én de ideeën voor de uitbreidingen aan ons aanbevelingssysteem en onze

webapplicatie.

Recommending a diversity of recipes to groups of

users using explainable hybrid filtering

Phaedra Neirinck and Laura Snyers

Supervisor(s): Toon De Pessemier, Luc Martens, Femke Ongenae

Abstract— On a daily basis we get in touch with recommender systems which try to propose the most suitable products to our likings. Consumers use these recommendations to broaden their usage. They not only want to receive suggestions to likewise products, but also want to encounter new items they wouldn’t have come in contact with otherwise. As a con-sumer it’s not always clear why certain results were obtained, which makes it more difficult to place confidence in these systems. Over recent years transparancy has hence become an important aspect, which resulted in the rise of Explainable Artifical Intelligence. Which and how these explana-tions are best presented, depends on the type of application and its users.

In this article, we will focus on recommending recipes. It’s often hard to find a dish which can be enjoyed by multiple people since every person has their own constraints such as diet (veganism, vegetarism etc.), allergies, lifestyles (kosher, halal) and preferences. In addition to this, the proposed recipes should contain enough diversity to be able to make a decent choice and to get enough variation in meals throughout the week. A recommender system was built to propose recipes to groups of users and to offer them an explanation. To make the system more accessible for testing, a progressive webapplication was also created.

Keywords— recommender system, memory based collaborative filtering, matrix factorisation, content based filtering, term frequency-inverse docu-ment frequency, recipes

I. INTRODUCTION

O

PPOSED to other applications, it’s not possible to im-plicitly check whether users effectively prepared certain recipes and if they’ve enjoyed the meal, which makes the ap-plication completely dependent on explicite interaction such as reviews. Since consumers will be able to choose out of a large database of recipes, only a small amount of interactions will be made, resulting in a sparse dataset. The goal of a recom-mender system is to simulate the remaining reviews and thus achieving a dense dataset whose estimated scores will be used to make recommendations. The chosen filter method must be able to work with the dataset and satisfy the goal: the success of a system isn’t only dependent on the accuracy of the proposed recipes, but also its diversity, coverage, confidence, trust, nov-elty, risk and serendipity [1]. For each application the chosen primal characteristics will determine the most fitting filter and evaluation methods. We have chosen to implement two filter techniques in the recipe recommender system (hybrid), whereas one will focus on accuracy and the other one on diversity.

In this abstract, we will first explain which filter methods were used and why these were chosen. Next, we will check the transparancy issues and how these were handled. Afterwards the hypothesis and the evaluation scores for the characteristics accuracy and diversity will be revealed and how these tests were conducted.

II. THE RECOMMENDER SYSTEM OF THE RECIPE APPLICATION

To be able to choose which filter method is most fitted to gain more accuracy and diversity, certain key elements had to be compared between all possilibities. First of all, the bias-variance trade-off [2] played a key factor for the accuracy. Both bias and variance should be as low as possible, the former to avoid underfitting and the latter to avoid overfitting. Secondly, most filter techniques lead to excessive specialisation [3] in an infor-mation confinement area which increases the rich-get-richer ef-fect [2] and lowers the catalog coverage [4]. Users should be able to come in contact with recipes in the long tail [3]. This leads to an exploitation-exploration dilemma. Thirdly, a cold start problem should be avoided. To make the last qualification easier to achieve, the application doesn’t contain a feature to add new recipes, but does have a questionnaire for new user profiles, only asking them the most necessary information (diet, allergies, lifestyle) and a minimum of two chosen recipes out of each cat-egory. This leads to a higher item and user coverage [4]. The avoidance of the rich-get-richer effect and cold start problem are more important to diversity.

To generate the recommendations, we use the reviews, social info (followed profiles, group members), features of items (in-gredients, titles) and users (favorites, allergies, lifestyle, diet). A. Diversity

To increase the diversity, two methods will be introduced: weight using a follower system and similarity comparison us-ing TF-IDF (usus-ing the skycit-learn-library).

A.1 Weight with a follower system

Each profile can follow other profiles to get influenced by their opinions. When recommending recipes the estimated rat-ings for people joining dinner and their followers will be re-spectively weighted using a factor 2/3 and 1/3. By giving each person less impact it’s possible that recipes which are disliked by some members, will still be recommended in large groups. When no followers are present, the second part of the equation will lead to 0. Since the actual rating values have no importance (only their order matters), this will have no negative effect.

rgroup,i= 2/3 ∗ n X m=1 ˆ rm,i n + 1/3 ∗ n X g=1 ˆ rg,i n A.2 Similarity with TF-IDF

Content based filtering uses attributes (features) [3] of users and recipes. The goal is to group similar elements with the

as-the item based model was used for classification, more precisely TF-IDF (Term Frequency-Inverse Document Frequency) [6] to give each term a score for its contribution. This technique will be used to compute the similarity between recipe pairs, using the attributes ingredients and title. First, the term frequency will be calculated. The lower the frequency, the more unique and consequently the more important the word. This way certain ingredients, such as salt and pepper, who are very popular will have less influence and become irrelevant. Next, the inverse doc-ument frequency will be computed by checking in how much documents (recipes) the word occurs. Finally the weight for each term in a document can be calculated with the following formula:

wt,d= tft,d∗ log(

N dft

)

Later, the ingredients and title similarity between two doc-uments can be computed using a cosinus function [5] on the ingredient matrix and title matrix. The lower the distance, the more similar the elements. Afterwards, we’ve taken the sum of these two similarity values, resulting to values in the range [0,2].

sim(d, d0) = cos(θ) = rd.rd0 krdkkrd0k

The algorithm will run through all recipes in the recommen-dation list and compare the similarity of the (N+1)’th recipe with the previous N recipes. When two recipes have a similarity score above 0.70 and are deemed ”too similar”, the latter and thus less recommended recipe will be removed from the list.

B. Accuracy

To increase the accuracy we used matrix factorisation, which works with latent factors (using the surprise-library).

C. Latent factors with matrix factorisation

Collaborative filtering assumes users are interested in items similar to their previous likes (items are neighbours) or in items liked by users with similar taste (users are neighbours). Since memory based filtering only focuses on the local surroundings of users and items while model based filtering views the total picture, the latter was a better fit to increase the coverage. By using low rank matrix factorisation with a Latent Factor Model [10], [11], [12], [13] the system can detemine why certain in-teractions were formed and which would most likely be made in the future. This uses PCA (Principal Component Analysis) to execute SVD (Singular Value Decomposition). These algo-rithms assume that all characteristics of users and recipes are able to be described by features. For the user-item interac-tions, PCA creates a matrix consisting of principal components (eigenvectors) which all represent one latent factor. Each orig-inal vector can be expressed as combination of such eigenvec-tors. The system determines what these latent factors actually mean and represent them by positive or negative numbers. Not all eigenvectors are necessary to get an approximation, which means it’s acceptable to work with a sparse matrix such as our recipe dataset. SVD is calculated by solving a minimalisation

backpropagation via SGD (Stochastic Gradient Descent) which updates its parameters iteratively [9].

R = M ΣUT min pu,qi X rui∈R (rui− pu· qi)2.

SVD uses baseline predictors [16] to factor in the bias of the users, of the items and the global average of received ratings. This should lower the impact of users and items by themselves compared to the impact of user-item relations.

X rui∈Rtrain (rui− ˆrui) 2 + λ1 b2_i + b2_u+ ||qi||2+ ||pu||2

The goal is to receive some new recommendations each day and as long as new reviews get written by group members, fol-lowed profiles or enough outsiders, these new suggestions will be generated using TF-IDF, matrix factorisation or the follower system.

III. THE TRANSPARANCY IN THE RECIPE APPLICATION

The best way to gain a user’s confidence is through items they’ve already used (favorites, good reviews) or their social cir-cle (followed profiles). This way, the user will see a connection, which adds meaning to an item and creates less privacy issues.

Because of the chosen filtering methods, certain transparancy issues were created. Since PCA and SVD create their own fea-tures, it’s not possible to understand these and determine why each recommendation was precisely proposed, making a black box [7] in the process. This can be fixed by using a post-hoc method with a model-agnostic approach. By using features of recipes to compute the similarity in the social circle (social planations [15]), we can go the other way around to find an ex-planation for each result. The suggestions and exex-planations will thus be generated independently. Since we have enough infor-mation about the recipes from the database, we don’t need to use the more complex EFM (Explicit Factor Model) [7] and explain-able metrics such as MEP (Mean Explainability Precision) and MER (Mean Explainability Recall). That way we would have to modificate the SVD formulas and follow the process from beginning to end.

As we’ve chosen to use the post-hoc method the explanations won’t always be the reason why an item was proposed to a user by the SVD algorithm, but it could be the reason why it was ul-timately suggested after being influenced by the other elements. Thus the generated explanation won’t be ”fake” since all claims will be true, but it’s not possible to determine if it’s actually the reason why something was explicitly recommended.

These are the three templates we’ve used, dependent on social circles and feature-based explanation:

• ”This has been recommended because it has high similarity with <recipe> and <users> marked that recipe as favorite.” The recipe has more than 0.60 similarity with a recipe which belongs to the favorites of group members or profiles followed by them.

• ”This has been recommended because <users> liked it.” The

recipe got a review of 4 or 5 from group members or profiles followed by them, or belongs to their favorites.

• ”This has been recommended because it’s popular.” The recipe didn’t get any explanation by above logic and thus the SVD algorithm took into account the outsiders which had the same taste. Users didn’t have any ties with these persons.

IV. THE EVALUATIONS OF THE RECOMMENDER SYSTEM

The recommender system is a hybrid using matrix factorisa-tion for its basic recommendafactorisa-tions and adding the results of the follower system and word similarity as postprocessing. Since there’s a trade-off between accuracy and variation, the hypoth-esis consists of a slightly lower accuracy, but strongly higher diversity. Recipes with less connections to the user will be cho-sen instead of already recommended and very similar recipes. The graphs show the results of the four tests: SVD, SVD + F (<follower system), SVD + D (<diversity), SVD + D + F), for the courses: AP (<appetizer), BR (<breakfast), DE (<dessert), MC (<main course), SD (<side dish), SN (<snack).

A. Testing accuracy

We’ve chosen to use two different metrics, NDCG and MAP, while testing N=50 (with N=amount of recommendations in each category). Both evaluation methods give the review pre-dictions different roles and have different kinds of errors to pe-nalise.

A.1 Accuracy testing with NDCG

The NDCG (Normalised Discounted Cumulative Gain) [1] experiments used letor-metrics1 to evaluate the accuracy of the item ordening. NDCG calculates a score while taking into ac-count if the ordening between the reviewed recipes in the rec-ommendation list is correct. There will be penalised when the ordening doesn’t follow the GTP (Ground Truth Positives). The NDCG results can be found in graph 1.

DCG = 1 N N X u=1 J X j=1 guij max(1, logbj) N DCG = DCG DCG∗ A.2 Accuracy testing with MAP

The MAP (Mean Average Precision) [14] experiments used ml-metrics2 _{to evaluate the accuracy of the user expectations.}

AP (Actual Precision) calculates a score while taking into ac-count if only the reviewed recipes were at the front of the rec-ommendation list. There will be penalised when unreviewed and thus unnecessary recipes interrupt this set of reviewed recipes. It doesn’t matter which sequence the reviewed recipes in the front of the queue follow or which ordening the unreviewed recipes at the back of the list have. The MAP results can be found in graph 2. 1_{https://gist.github.com/mblondel/7337391} 2_{https://github.com/benhamner/Metrics/tree/master/Python/ml metrics} AP BR DE MC SD SN 0.984 0.986 0.988 0.990 0.992 0.994 0.996 0.998 1 Courses Accurac y Test results NDCG SVD SVD + D SVD + F SVD + D + F

Fig. 1. Test results NDCG

AP BR DE MC SD SN 0 0.5 1 1.5 2 ·10−2 Courses Accurac y

Test results MAP

Fig. 2. Test results MAP

AP @k = (change in recall) k X i=1 T P seen i M AP = 1 N N X i=1 AP i

B. Testing diversity with TF-IDF

Since the complexity of the diversity tests with TF-IDF is O(N2), we’ve chosen to limit the recommender system to N=20 during these tests. The goal is to reach higher variety, by getting a lower similarity value. The results will be in the range [0,2] since they consist of the sum between the ingredients similarity and the title similarity. The average and maximum similarity can be found in the graphs 3 and 4 .

AP BR DE MC SD SN 1 2 3 Courses Similarity

Fig. 3. Test results average similarity

AP BR DE MC SD SN 0.4 0.6 0.8 1 1.2 1.4 Courses Similarity

Test results maximum similarity

Fig. 4. Test results maximum similarity

C. Analysing the test results

The difference between the accuracy test results is rather low for MAP, which is why we chose to focus on the results of NDCG, especially for the courses ”breakfast” and ”snack”. It’s clear that the follower system and similarity filtering didn’t have a lot of effect on their own, but when combined, there is an ob-vious decline in accuracy. The small accuracy difference for the other courses and MAP can be declared by the fact that only 804 of the 2.605 users made use of the follower system and the low amount of similar recipes because of the preprocessing, result-ing in only 2.047 restresult-ing recipes. To make these offline tests as realistic as possible both profiles with as low as 12 reviews and profiles with more than 100 reviews were used, which also lead to the low amount of reviews.

There is only a slight difference in average similarity between SVD and the postprocessing. The results of the follower system and similarity filtering did increase a little in contrast to SVD, which was rather unexpected since both were supposed to make

average similarity to SVD, except for the snacks. For this course the results were quite different: The follower system increased the similarity while the similarity filtering lowered it. From these test results we can also determine that the general simi-larity of the basis recommandations was already low because of the preprocessing which removed reviews.

The results of the maximum similarity of SVD were less pro-nounced than expected. Since a low number of recommenda-tions (N=20) was used during the diversity tests, there was only a small chance to find good matches with the other recipes. Con-trary to our expectations, the maximal similarity did increase for two courses because of the follower system. The results of the similarity filtering were predictable because of the removal of recipes when recipe pairs reached a minimal similarity of 0.70.

V. CONCLUSION

The goal of this thesis was to build a recommender system to propose a diversity of recipes to groups of users, each supported by an explanation. A hybrid system was chosen, consisting of matrix factorisation, using SVD, as basis algorithm, with a fol-lower system and similarity filtering, using TF-IDF, as postpro-cessing.

The recommender system was tested for its accuracy using NDCG and MAP and for its diversity with intra-list similarity. Because of the necessary amount of preprocessing, resulting in a lower amount of recipes and thus a lower amount of similar recipes; the low amount of users making use of the follower system and because of the low amount of reviews; the results were less noticeable than predicted. The test results were of-ten contradictory between the various courses. A few courses shared a strong decline of accuracy while the other courses had a rather small accuracy drop after postprocessing. All courses, except for the snacks, had a very small increase in average simi-larity or stayed the same, which wasn’t expected. The maximum similarity did obviously decline for each course.

It’s important to encourage the users to make use of the fol-lower system and to review because the postprocessing won’t come through otherwise, resulting in SVD with filtered out max-ima similarity.

REFERENCES

[1] G. Shani and A. Gunawardana, “Evaluating recommendation systems,” in Recommender Systems Handbook. Boston, MA: Springer, 2010, pp. 257–297

[2] B. Rocca. (2019, Jun. 3) Introduction to recommender systems. Accessed: Mar. 3, 2020. [Online]. Available: https://towardsdatascience.com/introduction-to-recommendersystems-6c66cf15ada

[3] G.Rodr´ıguez. (2018, May. 9) Introduction to recom-mendersystems. Accessed: Mar.3,2020. [Online]. Available: https://tryolabs.com/blog/introduction-to-recommender-systems/ [4] Anna B. (2016, Jan. 27) Recommender systems — it’s not

all about the accuracy. Accessed: Apr. 29, 2020. [Online]. Avail-able: https://gab41.lab41.org/recommender-systems-its-notall-about-the-accuracy-562c7dceeaff

[5] N. Sharma. (2019, Aug. 22) Recommender systems with python — part i: Contentbased filtering. Accessed: Apr. 29, 2020. [Online]. Avail-able: https://heartbeat.fritz.ai/ recommender-systems-with-python-part-i-content-based-filtering-5df4940bd831

Apr. 29,2020. [Online]. Available: https://www.onely.com/blog/what-is-tf-idf/

[7] B. Abdollahi and O. Nasraoui, “Using explainability for constrained ma-trix factorization,” in Proceedings of the Eleventh ACM Conference on Recommender Systems, ser. RecSys ’17. New York, NY, USA: Asso-ciation for Computing Machinery, 2017, p. 79–83. [Online]. Available: https://doi.org/10.1145/3109859.3109913

[8] C. Desrosiers and G. Karypis, “A comprehensive survey of neighborhood-based recommendation methods,” in Recommender Systems Handbook. Boston, MA: Springer, 2010, pp. 107–144.,

[9] B. Fortuner. (2018, Jul. 23) Gradient descent. [Online]. Available: https://mlcheatsheet.readthedocs.io/en/latest/gradient descent.html [10] N. Hug. (2017, Jun. 14) Understanding matrix factorization for

recom-mendation (part 1) - preliminary insights on pca. Accessed: Mar. 11,2020. [Online]. Available: http://nicolas-hug.com/blog/matrix facto 1

[11] N. Hug. (2017, Jun. 15) Understanding matrix factorization for recom-mendation (part 2) - the model behind svd. Accessed: Mar. 11,2020. [On-line]. Available: http://nicolas-hug.com/blog/matrix facto 2

[12] N. Hug. (2017, Jun. 16) Understanding matrix factorization for recom-mendation (part 3) - svd for recomrecom-mendation. Accessed: Mar. 11,2020. [Online]. Available: http://nicolas-hug.com/blog/matrix facto 3

[13] N. Hug. (2017, Jun. 17) Understanding matrix factorization for recom-mendation (part 4) - algorithm implementation. Accessed: Mar. 11,2020. [Online]. Available: http://nicolas-hug.com/blog/matrix facto 4

[14] R. J. Tan. (2019, Mar. 24) Breaking down mean average pre-cision (map). Accessed: Apr. 15, 2020. [Online]. Available: https://towardsdatascience.com/breaking-down-meanaverage-precision-map-ae462f623a52

[15] Y. Zhang and X. Chen, “Explainable recommendation: A survey and new perspectives,” CoRR, vol. abs/1804.11192, 2018. [Online]. Available: http://arxiv.org/abs/1804.11192

[16] Y. Koren and R. Bell, “Advances in Collaborative Filtering,” in Advances in Collaborative Filtering. Boston, MA: Springer, 2010, pp. 145-186.,

Lijst van figuren 13

Lijst van tabellen 15

1 Inleiding 17

1.1 Wat is een recommender system . . . 17

1.2 Probleemstelling en doel van de masterproef . . . 18

1.3 Indeling van de thesis . . . 19

2 Soorten recommender systems 20 2.1 Content based filtering . . . 22

2.2 Collaborative filtering . . . 24

2.2.1 Memory based collaborative filtering . . . 24

2.2.2 Model based collaborative filtering . . . 26

2.3 Hybrid filtering . . . 32

3 Recommender system van de receptenapplicatie 33 3.1 Basisrecommandaties in de receptenapplicatie . . . 33

3.2 Diversiteit in de receptenapplicatie . . . 34

4 Verklaringen van recommender systems 36

INHOUDSOPGAVE 11

4.1 Verklaringstechnieken AI . . . 36

4.2 Explainable Filtering . . . 38

5 Evaluatie van het recommender system 40 5.1 Soorten evaluatiemetrieken . . . 40

5.1.1 Nauwkeurigheidsmetrieken . . . 41

5.1.1.1 Accuratie van de reviewschattingen . . . 41

5.1.1.2 Accuratie van de itemordening . . . 42

5.1.1.3 Accuratie van de gebruiksverwachtingen . . . 44

5.2 Uitgevoerde experimenten . . . 47

5.2.1 Test- en trainingsdata . . . 47

5.2.2 Experimenten op nauwkeurigheid . . . 49

5.2.3 Experimenten op diversiteit . . . 52

5.3 Analyseren van resultaten . . . 54

6 Application data 55 7 Mogelijkheden voor de user interface 59 7.1 Mobiele webapplicaties . . . 59

7.2 Native applicaties . . . 60

7.3 Cross-platform development . . . 60

7.4 Progressive webapplicaties (PWA) . . . 60

7.5 Front-end . . . 61

7.6 Back-end: node.js . . . 63

8 De ontwikkelde front-end 66 8.1 Loginscherm . . . 67 8.2 Overzichtsscherm . . . 67 8.3 Zoekscherm . . . 68 8.4 Detailscherm . . . 70 8.5 Profielschermen . . . 70 8.6 Groepsschermen . . . 71

9 Evaluatie van de receptenapplicatie 73 9.1 Conclusie pilot test . . . 74

10 Docker 76

11 Conclusie 79

Bibliografie 81

Lijst van figuren

2.1 Long tail [1] . . . 21

2.2 Matrix factorisation [2] . . . 28

4.1 Relevant-user en relevant-item explanation [3] . . . 37

4.2 Feature-based explanation [4] . . . 38

5.1 RMSE . . . 42

5.2 Confusion matrix [5] . . . 45

5.3 Testresultaten MAP . . . 51

5.4 Testresultaten NDCG . . . 52

5.5 Testresultaten gemiddelde similariteit . . . 53

5.6 Testresultaten maximale similariteit . . . 53

8.1 Loginscherm . . . 67 8.2 Recommandaties . . . 68 8.3 Sidebar . . . 68 8.4 Favorieten . . . 69 8.5 Reviews . . . 69 8.6 Volgers . . . 69 13

8.7 Zoeken recepten . . . 69

8.8 Zoeken profielen . . . 69

8.9 Details recept . . . 70

8.10 Details recept vervolg . . . 70

8.11 Details profiel . . . 71 8.12 Veranderen profiel . . . 71 8.13 Toevoegen profiel . . . 71 8.14 Veranderen groep . . . 72 8.15 Toevoegen groep . . . 72 8.16 Verwijderen groep . . . 72

Lijst van tabellen

5.1 Testresultaten MAP . . . 50

5.2 Testresultaten NDCG . . . 51

5.3 Testresultaten gemiddelde similariteit . . . 52

5.4 Testresultaten maximale similariteit . . . 53

6.1 Frequentie recepten in receptencollectie . . . 56

9.1 Testresultaten pilot test . . . 74

1 Gebruikte data voor één recept . . . 57

2 Recommandatiescollectie . . . 57

3 Accountscollectie: gebruikte data voor één account . . . 58

4 Dockerfile voor het importeren van accounts in databank . . . 77

5 Dockerfile voor starten van de Python-job . . . 77

6 Dockerfile voor starten van back-end webapp . . . 78

1

Inleiding

Dagelijks worden we verschillende keren geconfronteerd met recommender systems: wanneer we een nieuwe serie willen uitkiezen op Netflix, populaire muziek willen ontdekken via YouTube of bij het aankopen van trendy kleren met de Zalando-app. Steeds proberen recommender systems de juiste producten aan te raden, rekening houdend met de interesses van de gebruikers. Toch is het voor de consument niet steeds duidelijk waarom bepaalde resultaten verkregen werden. In deze masterproef werd er een applicatie uitgeschreven om recepten op een transparante manier te suggereren aan gebruikersgroepen. Hierbij wordt er rekening gehouden met het dieet, de allergieën en de lifestyle van de client. De voorstellen worden beïnvloed door de beperkingen en reviews van de gebruiker zelf, door zijn vrienden waarmee er samen gegeten wordt of door de personen wiens meningen geapprecieerd worden door de gebruiker. Om niet steeds soortgelijke recepten aangeboden te krijgen, wordt er ook voor variatie gezorgd in de suggesties. Ten slotte wordt er nog aan de gebruiker meegedeeld waarom een bepaald gerecht wordt voorgesteld.

1.1 Wat is een recommender system

Recommender systems geven nieuwe suggesties op basis van oude reviews (expliciete interactie),

zoek- en klikgeschiedenis of karakteristieken van gebruikers en producten (impliciete interactie). Vaak kunnen klanten kiezen tussen een groot aantal producten en komt elk account maar enkele keren in contact met een item waardoor de meeste interacties niet voorkomen (sparse dataset). Het doel is om ontbrekende reviews te simuleren en zo een dense dataset te bekomen. Deze

scores kunnen onmogelijk correct berekend worden, maar hiermee krijgt men wel een zicht op de verwachte interesses zodat de items met de hoogste waarderingscijfers voorgesteld kunnen worden. Dit verbetert de klantervaring waardoor de consument loyaal blijft aan het bedrijf én worden er nieuwe kopers aangetrokken. Daarnaast is het belangrijk dat gebruikers ook onver-wachte aanbiedingen krijgen waaruit mogelijks nieuwe interesses ontstaan. Zo worden er meer verschillende producten geconsumeerd en stijgt de winst.

1.2 Probleemstelling en doel van de masterproef

Bij het voorstellen van gerechten moet er met een aantal parameters rekening gehouden worden. Zo volgt iedereen een welbepaald dieet (veganisme, vegetarisme, pescetarianisme), hebben som-migen bepaalde allergieën (zuivel, eieren, (pinda)noten, schaaldieren, tarwe, soja, vis) en krijgen anderen beperkingen door hun religie (kosher, halal). Wanneer er in groep samengegeten wordt, moet er vervolgens rekening gehouden worden met deze grenzen (harde eisen), maar ook met de voorkeuren van elk persoon (zachte eisen). Hiernaast is het belangrijk dat er voldoende variatie zit in de voorstellen zodat de gebruiker nieuwe recepten ontdekt en geen ééntonig dieet heeft. Deze thesis focust op de implementatie en uitbreiding van bestaande algoritmen met een transpa-rante verwerking van de verkregen resultaten voor gebruikersgroepen in een eigen recommender

system. Er werd een progressieve webapplicatie ontwikkeld zodat de resultaten gemakkelijk

uit-getest konden worden op een testgroep. Elk account kan één of meerdere profielen aanmaken waarbij de beperkingen en eerste voorkeuren worden geselecteerd. Zo’n profiel kan één persoon, een gezin of cheat-dagen met steeds andere eisen voorstellen. Wanneer gebruikers samen eten, wordt er een groep gevormd met hun profielen. Daarnaast kan elk profiel meerdere gebruikers volgen om ook beïnvloed te worden door hun interesses. Elk voorgesteld gerecht zal bovendien verklaren waarom de gebruiker dit te zien krijgt.

Er wordt verondersteld dat het klikken op of zoeken naar een recept nog niet getuigt van inte-resse, maar van nieuwsgierigheid in het bekijken van de verdere instructies. Andere applicaties weten steeds wanneer gebruikers naar een serie gekeken hebben of bepaalde kledingstukken aan-gekocht hebben, maar de receptenapplicatie heeft geen enkele manier om te checken of recepten wel degelijk bereid werden. Er wordt dus verwacht dat de gebruikers enkele keren een review meegeven om aan te tonen of het gerecht juist wel of net niet in de smaak viel. Zolang gebruikers reviews geven, zal het recommender system nieuwe voorstellen kunnen berekenen.

Om het project uit te testen, zullen er zowel enkele profielen, gezinsprofielen als gebundelde profielen in groep aangemaakt worden. Vervolgens zal de testgroep een enquête invullen waarbij ze verklaren of de applicatie te complex was, of de verkregen recepten verwacht waren, of er rekening gehouden werd met hun beperkingen, of er genoeg variatie was en hoeveel reviews ze hebben gemaakt. Hiernaast worden er testen uitgevoerd om het basisalgoritme te vergelijken met de verdere postprocessing.

1.3. INDELING VAN DE THESIS 19

1.3 Indeling van de thesis

Eerst worden verschillende filtertechnieken toegelicht in hoofdstuk 2 met verklaring waarom de besproken filtermethode juist wel of net niet gebruikt werd in de receptenapplicatie. De gevolgde werkwijze bij het toepassen van de algoritmen wordt verklaard in hoofdstuk 3. Daarna wordt de evaluatie van recommender systems en de noodzaak van transparantie besproken, met toepassing op het uitgewerkte project. Dit wordt toegelicht in hoofdstuk 4. De testresultaten van het aanbevelingssysteem worden besproken in hoofdstuk 5.

De databank, de gebruikte dataset en zijn preprocessing worden besproken in hoofdstuk 6. Vervolgens worden in hoofdstuk 7 de gebruikte back-end en front-end van de receptenapplicatie verder toegelicht, met in hoofdstuk 8 de visualisatie van de front-end. De webapplicatie wordt met gebruikersinteractie geëvalueerd in hoofdstuk 9.

2

Soorten recommender systems

In dit hoofdstuk worden de verschillende soorten recommender systems en hun implementaties afgewogen ten opzichte van elkaar. Er wordt gezocht naar een filtertechniek die aansluit bij de gekregen dataset en matcht met het doel van de receptenapplicatie. Alvorens de verschillende filtertechnieken overlopen kunnen worden, moeten enkele kernelementen verklaard worden die als kwalificaties kunnen dienen voor recommender systems én worden vervolgens hieruit de juiste termen geselecteerd voor de receptenapplicatie. Deze kwalificaties [6] zullen ook gebruikt worden bij evaluatie in hoofdstuk 5.

Het succes van een aanbevelingssysteem is niet enkel afhankelijk van de nauwkeurigheid in het geven van aanbevelingen, maar ook van het aanbieden van een diverse verzameling items

(di-versity), dekking van de hele dataset (coverage of category di(di-versity), vermijden van een cold start, betrouwbaarheid van de gegeven aanbevelingen (confidence), vertrouwen in het systeem

qua privacy (trust), toegevoegde nieuwigheden (novelty), genomen risico’s (risk) en serendipiteit (serendipity). Voor elke toepassing worden de voornaamste karakteristieken behorend aan zijn

recommender system bepaald zodat de beste filtertechniek en vervolgens de juiste evaluaties

ge-kozen kunnen worden (property-directed evaluation). Voor de receptenapplicatie wordt er gezocht naar een goede nauwkeurigheid onder de juiste bias-variance trade-off, een grotere coverage door het verkleinen van het rich-get-richer effect en door het ontwijken van een cold start problem, en het behalen van voldoende diversity zodat er gerechten uit de long tail gesuggereerd worden. Deze begrippen zullen hieronder verklaard worden. Hiernaast moet er ook nagegaan worden of

21

Figuur 2.1: Long tail [1]

er aan deze kwalificaties voldaan kan worden bij gebruik van één filtertechniek en of er beter gekozen wordt voor combinatie van meerdere technieken (hybride).

Het is belangrijk om te letten op de bias-variance trade-off [7] tussen de verschillende soorten filtersystemen aangezien variantie en bias fouten veroorzaken in de geschatte scores. Door deze fouten kan er moeilijk op basis van info uit de leerverzameling veralgemeend worden bij het schatten van reviews waardoor de nauwkeurigheid van het systeem daalt. Het doel is om een minimum te vinden voor zowel bias als variantie, maar hoe lager de variantie wordt, hoe hoger de bias en omgekeerd. Hoge bias zorgt voor underfitting waarbij er foutieve veronderstellingen worden gemaakt door het negeren van belangrijke relaties tussen recepten of gebruikers onder-ling, wat leidt tot een verminderde personalisering in de resultaten. Bij een hoge variantie wordt er aan overfitting gedaan waarbij ruis ook opgenomen wordt in de voorstellen, voorgesteld door minder relevante recepten die een te groot effect hebben op de leerverzameling.

De meeste filtertechnieken kunnen leiden tot excessive specialisation [1] in een information

con-finement area waarbij het rich-get-richer effect [7] ervoor zorgt dat enkel populaire recepten

aangeraden worden en daarna nog meer gewenst zullen worden. Hierdoor zullen minder gebrui-kers de mogelijkheid krijgen om nieuwe recepten te leren kennen en reviewen waardoor het aantal gegenereerde combinaties tussen gebruikers en recepten zullen dalen. Dit leidt vervolgens tot een lagere catalog coverage [8], het percentage van aangeraden gebruiker-recept-paren tot het aantal potentiële paren. Alhoewel recommender systems goed werken op populaire gerechten die in veel interacties terugkomen, zijn deze gerechten minder waardevol voor gebruikers omdat ze vaak al gekend zijn. Zo worden suggesties met items uit de long tail [1] geprefereerd aangezien de gebruikers deze niet hadden gevonden zonder het recommender system. Met andere woorden, er moet afgestapt worden van de continue exploitation waarbij enkel hetgene aangeraden wordt dat succesvol bleek in het verleden. Dit gebeurt door afwisseling met exploration waarbij nieuwe en nog onbekende recepten uitgetest worden. De resultaten van deze randomisatie zullen onver-wacht zijn en kunnen zowel positief als negatief uitvallen, maar leiden tot meer diversiteit. Voor de receptenapplicatie zal er dus gezocht worden naar een filtertechniek waarbij zoveel mogelijk ontdekkingen buiten de lokale omgeving gebeuren.

Ten slotte is het belangrijk dat het gekozen recommender system geen last heeft van een cold

start problem [1] ondanks de info uit de dataset. Dit betekent dat nieuwe gebruikers onmiddellijk

nauwkeurige suggesties dienen te verkrijgen en dat nieuwe recepten de mogelijkheid krijgen om onmiddellijk gesuggereerd te worden aan gebruikers. Om dit probleem te minimaliseren, werd er gekozen om geen applicatiefeature beschikbaar te stellen waarbij nieuwe recepten toegevoegd kunnen worden. Daarentegen kunnen nieuwe accounts en profielen nog steeds aangemaakt wor-den en zal het tekort aan info deels opgelost worwor-den door een vragenlijst. Deze oplossingen zullen bijdragen tot een hogere item en user coverage [8], respectievelijk het percentage aangeraden recepten tot het aantal recepten en het percentage gebruikers met gegenereerde recommandaties tot het aantal gebruikers.

Er werd besloten om gebruik te maken van twee technieken waarbij de ene techniek zich zal focussen op het kenmerk nauwkeurigheid en de andere techniek op diversiteit. In de volgende secties zullen de gepaste algoritmes gezocht worden.

2.1 Content based filtering

Bij de simpelste filtermethode worden er extra attributen (features) [1] van gebruikers en recep-ten meegegeven, respectievelijk voor het maken van een item-, gebruikersgecentreerd of gemixt model. Het doel is om gelijkaardige elementen te groeperen met de veronderstelling dat door interesse in één van die elementen, men ook geïnteresseerd zal zijn in gelijkaardige elementen uit de groep. Deze filtertechniek vormt dan ook de basis voor feature-based explanation in de sectie 4.1. Het nadeel aan deze techniek is dat er veel metadata nodig is om elk element te kunnen beschrijven. In het algemeen zorgt deze filtermethode echter voor de hoogste bias en laagste variantie aangezien elk element vast zit aan zijn representatie. De trade-off [7] is hier wel verschillend tussen de twee modellen, namelijk item- en gebruikersgecentreerd.

Bij een itemgecentreerd model krijgt elk recept een model dat getraind wordt door gelijkaardige recepten. Hierbij zullen enkel reviews van die ene receptengroep gebruikt worden waardoor er veel en mogelijks sterk verschillende gebruikers invloed hebben op het model. Aangezien de gebruikers uiteenlopende features kunnen hebben, zullen de suggesties minder gepersonaliseerd zijn (hogere bias). Daarnaast wordt er voor elk recept met veel scores rekening gehouden waardoor elke score maar een laag gewicht heeft op de suggesties en er minder ruis is (lagere variantie).

Bij een gebruikersgecentreerd model krijgt elke gebruiker een model dat getraind wordt door gelijkaardige gebruikers. Er wordt enkel rekening gehouden met de interacties van die ene ge-bruikersgroep waar men voorstellen voor zoekt waardoor de suggesties persoonlijker zullen zijn (lagere bias). Aangezien elke gebruiker slechts met enkele recepten in contact is gekomen, zullen deze een te groot effect hebben op de uiteindelijke aanbevelingen (hogere variantie).

De aanbevelingen kunnen verkregen worden via classificatie [7] waarbij er gecheckt wordt of de gebruiker geïnteresseerd zou zijn in een recept of via regressie [7] waarbij de review van de

2.1. CONTENT BASED FILTERING 23 gebruiker geschat wordt.

Regressie

Bij regressie-analyse wordt de relatie tussen twee datasets getoond op een grafiek via correlatie. Er worden verwachtingen en voorspellingen gemaakt over de aanpassingen van een feature on-der invloed van veranon-deringen op de anon-dere features. Bij een itemgecentreerd model wordt de vraag gesteld “Welke score wordt er aan dit recept gegeven door elke gebruiker” terwijl bij een gebruikersgecentreerd model de vraag luidt “Welke score wordt er door deze gebruiker aan elk recept gegeven”.

Classificatie

Er is een vooraf bepaalde verzameling van klassen waartoe de gebruikers of recepten moeten verdeeld worden. Enkele voorbeelden van gebruikersklassen zijn ”jongeren/ouderen”, ”werkende ouders”, ”sporters” etc. aangezien die allemaal een verschillend budget, dieet of tijdslimiet heb-ben. Enkele voorbeelden van receptenklassen zijn ”goedkoop/duur”, ”gemakkelijk/complex” en ”snel/traag”. Indien er gewerkt wordt met een klein aantal duidelijk gescheiden klassen kunnen de elementen herkend worden via patroonherkenning (harde classificatie). Ook kan er gekozen worden voor meerdere klassen met een continue overgang ertussen waardoor het minder dui-delijk is tot welke categorie een element behoort (zachte classificatie). Bij een itemgecentreerd model stellen we vragen van de vorm “Wat is de kans dat dit recept leuk gevonden wordt door elke gebruiker” en bij een gebruikersgecentreerd model van de vorm “Wat is de kans dat deze gebruiker elk recept leuk vindt”. Classificatie kan uitgewerkt worden op verschillende manieren, zoals met een beslissingsboom en een Bayesiaanse classifier.

Onder classificatie bestaat de techniek Term Frequency-Inverse Document Frequency (TF-IDF) [9] (binnen de gekozen skycit-learn-library) waarbij elke term een score krijgt voor zijn bijdrage. Er wordt berekend hoeveel keer elk woord voorkomt in elk document ( Term Frequency, TF) en hoe lager deze frequentie, hoe unieker en bijgevolg hoe belangrijker het woord. Hierdoor worden stopwoorden (lidwoorden, voorzetsels, ...) irrelevant. Vervolgens wordt er gecheckt in hoeveel documenten dat woord voorkomt (Inverse Document Frequency, IDF). In onderstaande formule wordt het gewicht w voor een term t in document d bepaald door het product van TF en het logaritme van IDF. Hierbij stelt N het aantal documenten (corpus) voor waarbinnen de berekeningen gebeuren.

wt,d= tft,d∗ log( N dft

)

Deze content based filtertechnieken kunnen leiden tot excessive specialisation waarbij gebruikers enkel nog aanbiedingen krijgen uit dezelfde groepen en er geen nieuwe ontdekkingen meer worden gedaan buiten de reeds bestaande interesses. Er is minder kans tot een cold start problem aan-gezien elk item zijn kenmerken vanaf het begin meekrijgt en gemakkelijk relevant gepaard kan worden. Indien er nieuwe features bijkomen of indien er zonder dataset begonnen wordt, zullen

er nog geen interacties beschikbaar zijn en zal er wel een cold start problem bereikt worden. Het is best om content based filtering te gebruiken wanneer men over veel metadata van de recep-ten en gebruikers beschikt. Door de verkregen dataset zou het enkel mogelijk zijn om het model op recepten te trainen aangezien deze een uitgebreide attributenverzameling hebben: ”country” (land van oorsprong), ”course_prediction”: ”label” (soort gang in de maaltijd), ”dishtype_pre-diction”: ”label” (gerechtstype), ”ingredients”: ”raw” (ingrediënten), ”region_pre”dishtype_pre-diction”: ”la-bel” (continent van oorsprong). Deze features werden meegegeven in het JSON-bestand waarvan het formaat later besproken wordt in hoofdstuk 6.

Er werd gekozen om gebruik te maken van een itemgecentreerd model, meer bepaald TF-IDF op de gerechten, om meer diversiteit te creëren in de resultaten. Het is niet interessant om een gebruikersgecentreerd model te creëren aangezien de verkregen dataset slechts de gebruikersid’s zonder persoonlijke info bevat. Zo was het niet mogelijk van elke bestaande gebruiker de at-tributen ”leeftijd”, ”geslacht”, ”interesses”, ”achtergrond”, ”allergieën”, ”dieet” en ”lifestyle” te bepalen. Dit betekent dat er voor de gebruikerscollectie vanaf 0 gestart zou moeten worden met een cold start problem. Het is wel mogelijk om elke nieuwe gebruiker een vragenlijst in te laten vullen met hun persoonlijke data, maar niet elke gebruiker wil hieraan meewerken omwille van privacyredenen. Uiteindelijk werd er dan ook gekozen om hen enkel het broodnodige te vra-gen in de receptenapplicatie, namelijk datvra-gene dat onvermijdelijke invloed moet hebben op de voorgestelde recepten (allergieën, dieet en lifestyle).

2.2 Collaborative filtering

Hierbij wordt er verondersteld dat gebruikers interesse hebben in items gelijkaardig aan hun vorige likes of in items waar gebruikers met dezelfde smaak in geïnteresseerd zijn. De geplaatste reviews worden opgeslagen in een user-item interactions matrix waarin er steeds gezocht wordt naar soortgelijke gebruikers of recepten (buren). Bij nieuwe gebruikers of items is er een tekort aan info waardoor er geen nauwkeurige aanbevelingen van hen zullen voorkomen. Dit resulteert in een cold start problem waarbij er moeilijk buren gevonden worden en vervolgens ook slech-te voorsslech-tellen volgen. Pas wanneer het programma langer gebruikt wordt en de matrix voller wordt, zullen de voorstellen nauwkeuriger zijn. Collaborative filtering kan op een memory based-of model based-benadering [7] uitgewerkt worden die beiden hieronder verklaard worden. De

memory-based filtertechnieken vormen ook de basis voor item explanations en relevant-user explanations, zie sectie 4.1.

2.2.1 Memory based collaborative filtering

De suggesties zijn de populairste oude interacties van dichtstbijzijnde buren [7] waarbij deze buren ofwel gebruikers voorstellen (bij een user-user memory based system, ”gelijkaardige ge-bruikers vonden dit item leuk”) en ofwel recepten voorstellen (bij een item-item memory based

2.2. COLLABORATIVE FILTERING 25 of recepten wordt berekend via een afstandsfunctie waarbij een kleinere onderlinge afstand wijst op meer gelijkaardigere elementen. Er wordt aangeraden om de suggesties niet enkel te baseren op buren aangezien dit leidt tot een information confinement area. In het algemeen wordt er vanuit gegaan dat memory based collaborative filtering een lage bias en hoge variantie heeft aangezien het niet op een latent model gebaseerd is waardoor alle data rechtstreeks aanwezig is via een user-item interactions matrix. De trade-off is echter verschillend tussen de user-user en

item-item-gebaseerde filterfunctie [7].

Bij een gebruikersgecentreerde filterfunctie zal de afstand berekend worden tussen gebruikers, door rekening te houden met het aantal recepten waarop ze dezelfde mening delen. Indien twee personen gelijkaardige scores plaatsen op veel recepten, zal de afstand tussen hen kleiner zijn. Het is belangrijk dat beide gebruikers een hoog aantal reviews geplaatst hebben zodat hun gemeenschappelijke interesses duidelijker worden. Het proces voor het bepalen van voorstellen voor een gebruiker gaat als volgt: eerst worden de gebruikers met dezelfde gereviewde recepten als deze gebruiker in de user-item interactions matrix gezocht. Daarna wordt de afstand berekend tussen deze gebruiker en de andere gebruikers om zo de buurgebruikers te vinden waarvan hun populaire ongereviewde recepten kunnen worden aangeraden. Vaak plaatsen gebruikers maar enkele reviews en indien dit aantal zeer laag is, zal er een grote gevoeligheid zijn per individueel recept met veel ruis tot gevolg (hogere variantie). Er wordt hier wel rekening gehouden met gelijkaardige gebruikers waardoor de suggesties meer gepersonaliseerd zullen zijn (lagere bias). Onderstaande formules gelden als voorbeeld voor een mogelijke similariteitsberekening bij de gebruikersgecentreerde filterfunctie. De gebruikersrij uit de user-item ratingsmatrix wordt als vector (embedding) gebruikt. Vervolgens kan er een cosinussimilariteitsfunctie [10] uitgevoerd worden waarbij de cosinus van de hoek tussen twee gebruikersvectoren de similariteit is. Uit-eindelijk kunnen we een similariteitsindex opbouwen met alle afstanden waarmee de afwezige reviews geschat worden. Voor gebruikers u en u’ wordt de cosinussimilariteit als volgt berekend:

sim(u, u0) = cos(θ) = ru.ru0 krukkru0k =X i rui.ru0_i r P i r2 ui r P i r2 ui

De rating voor een recept i van gebruiker u kan vervolgens geschat worden door een gewogen som van ratings over recept i van alle andere gebruikers u’, met als gewicht de consinussimilariteit. Het is belangrijk alle ratings te normaliseren voor het aantal andere gebruikers u’.

ˆ rui= P u0 sim(u, u0)ru0_i P u0 |sim(u, u0_)|

Bij een itemgecentreerde filterfunctie wordt de afstandsfunctie uitgevoerd op recepten, gebaseerd op het aantal gebruikers met dezelfde mening over een recept. Hoe meer gebruikers gelijkaardige scores hebben op twee gerechten, hoe kleiner de afstand tussen die recepten is. Er kan wel

enkel een eerlijke score toegekend worden indien het aantal gebruikers die reviews plaatsten, groot is. Het proces voor het bepalen van voorstellen voor een gebruiker gaat als volgt: eerst worden de populairste recepten van de gebruiker opgezocht in de user-item interactions matrix. Vervolgens wordt de afstandfunctie op de populaire recepten en andere recepten uitgevoerd om zo de buurrecepten te vinden. Daaruit worden de recepten die reeds gereviewd werden door de gebruiker, gefilterd. Veel gebruikers beoordelen hetzelfde recept waardoor een individueel review minder effect heeft op de berekening en er minder ruis is (lagere variantie). De reviews van alle gebruikers die mogelijks sterk variërende interesses hebben, tellen even zwaar mee bij het zoeken naar voorstellen waardoor er minder personalisering is (hogere bias). De gebruikte formule is gelijkaardig aan deze voor de gebruikersgecentreerde filterfunctie.

De collaborative filtermethode schaalt slecht bij een groot aantal gebruikers of recepten. Bij grote sparse matrixen zijn het aantal user-item interacties immers te laag om kwaliteitsvolle suggesties te genereren. Dit zorgt ervoor dat er te veel gerechten en gebruikers verwijderd zullen moeten worden tijdens preprocessing, wat minder interessant is. Het cold start problem op nieuwe profielen wordt gemakkelijk opgelost door selectie van de eerste voorkeuren bij het aanmaken van zo’n profiel. Ten slotte kan het rich-get-richer effect opgelost worden door bij de postprocessing ook rekening te houden met verdere buren. Er werd uiteindelijk gekozen om niet met memory

based collaborative filtering te werken in de receptenapplicatie aangezien het rich-get-richer effect

beter ontweken kan worden via model based collaborative filtering, zie verder. 2.2.2 Model based collaborative filtering

Deze filtermethodes zijn gebaseerd op machine learning- en data mining-technieken. In tegenstel-ling tot de voorgaande buurtechniek waarbij er slechts rekening gehouden wordt met de lokale omgeving van een recept of gebruiker wordt het totaalplaatje hier wel geobserveerd. Dit heeft tot gevolg dat er gemakkelijk over kleine verzamelingen van sterk gerelateerde items gekeken kan worden.

Eén van de gebruikte methodes is low rank matrix factorisation met als rank het aantal lineair onafhankelijke kolommen of rijen in de matrix en het aantal niet-nul eigenwaarden. Dit gebruikt een Latent Factor Model (LFM) [11] waarlangs men de interacties tussen recepten en gebruikers probeert te verklaren zodat er nieuwe suggesties gecreëerd kunnen worden. Deze techniek kan wél werken met een groot aantal gebruikers en recepten (large coverage), ook al zitten er veel gaten in de uiteindelijke user-item interactions matrix. Om deze reden werd het gebruikt door het winnende team Bellkor van de Netflix Prize, een competitie die georganiseerd werd om een efficiënter collaborative filtering algoritme te vinden voor de Netflix-applicatie. In deze paragraaf wordt de werking van matrixfactorisatie verklaard en het verkozen algoritme daarbinnen:

Singu-lar Value Decomposition (SVD) (binnen de gekozen Surprise-library). Dit algoritme is gebaseerd

op de inzending van het winnende Bellkor-team en geïnspireerd op de bevindingen van Simon Funk die zelf tot het derde team behoorde.

2.2. COLLABORATIVE FILTERING 27 Matrixfactorisatie gebruikt Principal Component Analysis (PCA) [11] om SVD [12, 13, 14] uit te voeren. Deze algoritmes veronderstellen dat alle karakteristieken van recepten en voorkeuren van gebruikers beschreven kunnen worden via features die voorgesteld worden in een embedding

model. Het systeem zal zelf deze features ontdekken om eigen representaties te vormen van clients en gerechten en stelt de features voor als positieve of negatieve getallen. Aangezien

het systeem zelf alles ontdekt (black box [3]), is het bijgevolg onmogelijk om bij elk voorstel te verklaren waarom het nu werkelijk aangeraden werd (explainability [3]), wat wel mogelijk is bij buurgebaseerde technieken zoals memory based collaborative filtering. In tegenstelling tot laatstgenoemde filtertechniek wordt er hier niet enkel rekening gehouden met de buren, waardoor elke review een kleinere impact heeft op de uiteindelijke berekening (lage variantie). Aangezien er rekening gehouden wordt met alle gebruikers, ook deze met sterke verschillende karakteristieken, zal het uiteindelijke resultaat minder gepersonaliseerd zijn (hoge bias). Omdat matrixfactorisatie de beste coverage én nauwkeurigheidsresultaten biedt, werd deze techniek als basis verkozen voor de receptenapplicatie.

PCA van een ratingmatrix berekenen

De enige info die nodig is om te starten, is een regel met formaat ”userid itemid score” per review zodat er een user-item interactions matrix verkregen wordt. Eerst wordt er verondersteld dat de ratingmatrix geen gaten bevat en pas daarna zal de werkelijke situatie bekeken worden. Het PCA-algoritme geeft voor de ratingmatrix een simpele outputmatrix, opgebouwd uit principal

components (eigenvectors) [11] die orthogonaal zijn en typical vectors genoemd kunnen worden

doordat ze elk één latent factor voorstellen van de data. Die principal components zijn aspecten die de data definiëren en verborgen waren tot ze ontdekt werden door het systeem (latent). Elke originele vector uit de inputmatrix kan uitgedrukt worden als combinatie van de eigenvectors zodat de input terug opgebouwd kan worden. In onderstaand voorbeeld worden de verschillende categorieën uit de webapplicatie (appetizer, breakfast, dessert, main course, side dish, snack) gebruikt om gebruikers voor te stellen. Elke user heeft een welbepaalde interesse voor elke gang en om de ratingmatrix terug op te bouwen kunnen ”typische gebruikers” met voorkeur voor één welbepaalde gang (fan) als latente factoren gebruikt worden:

user1 = 10%appetizerfan + 5%breakfastfan + 2%dessertfan + ... user2 = 0%appetizerfan + 15%breakfastfan + 6%dessertfan + ...

Als voorbeeld werden er typische vectoren met een duidelijke betekenis (gang bij maaltijd) ge-bruikt, maar in feite worden ze gekozen door het systeem en zullen ze niet zo duidelijk zijn als deze categorieën. Hierdoor is het niet mogelijk om deze features te begrijpen en te achterha-len wat de reden tot de verkregen suggesties was. Kortweg wordt PCA gebruikt om ”typische reviewers” te krijgen zodat de originele reviewers terug opgebouwd kunnen worden. Om een benadering te krijgen van die originele reviewers zijn niet eens álle ”typische reviewers” (laten-te factoren) nodig, dus een ratingmatrix met ga(laten-ten levert genoeg info. Als we de ratingmatrix

Figuur 2.2: Matrix factorisation [2]

transposeren en het PCA-algoritme erop loslaten, worden er vervolgens ”typische recepten” ver-kregen waarmee de originele recepten heropgebouwd kunnen worden. De principal components zijn dan orthonormaal.

Het uiteindelijke aantal gebruikte latente factoren is de embedding dimension [15]. Een volle-dige matrix met m gebruikers en n items heeft O(nm) inputs terwijl zo’n embedding matrix slechts O((n+m)d) inputs heeft waarbij de dimensie meestal veel kleiner is dan n en m. Met andere woorden, PCA geeft een compactere representatie door dimensiereductie. Helaas wordt er hierdoor wel aan overfitting gedaan [16]. Het omgekeerde hiervan, is het opvullen van de ont-brekende waarden in de matrix (imputation [16]), wat de grootte van de data sterk verhoogt, duur én onnauwkeurig is.

SVD van een ratingmatrix berekenen via een objective function

SVD voert zowel op de ratingmatrix R als op de getransposeerde ratingmatrix RT PCA uit, om de outputmatrixen M, Σ en U te verkrijgen via factorisatie. De kolommen van M zijn de eigenvectoren van RRT en de rijen van U zijn de eigenvectoren van RTR. Σ wordt gevormd door de geassocieerde eigenwaarden.

R = M ΣUT

De ratingmatrix kan via die output terug opgebouwd worden, via principiële componenten in de kolommen van M en rijen van UT die respectievelijk de kolommen en rijen van de ratingmatrix vormen. Σ is een diagonale eenheidsmatrix die de schaling voorstelt en kan weggelaten worden uit de formule door aan te nemen dat het vermenigvuldigd werd met een andere factor.

R = M UT

De rating ruistelt de interesse van gebruiker u in karakteristieken van het item i voor en wordt verkregen via een dot product met vector pu als rij van M en vector qi als kolom van UT. De

2.2. COLLABORATIVE FILTERING 29 vectoren pu en qi stellen de affiniteit [12] van de gebruiker u en recept i voor bij de latente factoren waarbij pu meet hoeveel interesse (positief of negatief) de gebruiker heeft in items met hoge factorwaarde en qu de mate (positief of negatief) waartoe het item deze latente factoren bevat. Hoe hoger rui is, hoe meer interesse de gebruiker u heeft in het recept i.

rui= pu· qi

We kunnen SVD berekenen door het minimalisatieprobleem op te lossen waarbij de vectoren pu en qi van een matrix met lage rank gezocht worden zodat de berekende matrix het best zou aansluiten bij de bestaande ratingmatrix (low rank approximation). Als objective function [17] wordt de Euclidische afstand gekozen en wordt er gezocht naar een minimale reconstructiefout. De orthogonaliteitsbeperkingen [13] worden weggelaten uit de formule aangezien ze niet voor extra nauwkeurigheid zorgen, maar enkel helpen bij het interpreteren van de resultaten.

min pu,qipu⊥pvqi⊥qj X rui∈R (rui− pu· qi)2 min pu,qi X rui∈R (rui− pu· qi)2.

In volgende paragraaf worden zowel het gebruikte SVD-algoritme uit de Surprise-library als zijn extensies aangekaart.

Singular Value Decomposition

Bij recommender systems wordt er gewerkt met sparse ratingmatrixen, dus er moet een oplossing gevonden worden voor de ontbrekende reviews bij het uitvoeren van de berekeningen. Dit kan ofwel door een heuristiek en ofwel wordt het optimalisatieprobleem zo uitgewerkt dat de niet-ingevulde waarden niét vervangen worden door een 0 en bijgevolg genegeerd worden. Het idee om de bewerking uit te voeren op een incomplete matrix is afkomstig van Simon Funk en werd ook toegepast in de Surprise-library, wiens versie hieronder verder verklaard wordt. Het optima-lisatieprobleem kan meerdere antwoorden hebben en wordt hier opgelost met backpropagation via Stochastic Gradient Descent (SGD) [13].

Er worden baseline predictors (biases) [16] gebruikt om tijdens de berekeningen rekening te kunnen houden met de bias van gebruikers, van items en het globale gemiddelde van de verkregen ratings. Hiermee moet de impact van de gebruikers of items zelf kleiner worden ten opzichte van de impact van de relaties ertussen (user-item-interacties). Het zou bijvoorbeeld kunnen dat bepaalde gebruikers gemiddeld hogere scores uitgeven aan recepten. De predictors moeten nauwkeurig zijn zodat enkel de ongewilde invloed opgevangen wordt en het model vervolgens enkel de interacties voorstelt. De baseline prediction voor een rating bij een bepaalde gebruiker u en item i bestaat uit de bias van de gebruiker bu (aantal punten dat de gebruiker gemiddeld boven/onder de norm µ ligt) en die van het item bi (aantal punten dat het recept gemiddeld boven/onder de norm µ ligt) en het gemiddelde van ratings over alle gebruikers en recepten µ.

ˆ

rui= µ + bu+ bi+ pu· qi

Die baseline- en regularisatieparameters worden gezocht via de onderstaande objective function. Wanneer de gebruiker ongekend is, zijn bu en pu 0 en wanneer het item ongekend is, zijn bi en qi 0. De geleerde parameters krijgen groottebeperkingen via regularisatieconstanten λ om stabielere resultaten te krijgen.

X

rui∈Rtrain

(rui− ˆrui)2+ λ1 b2i + b2u+ ||qi||2+ ||pu||2

SGD wordt gebruikt om een lokaal minimum te zoeken van een differentiale functie. Iteratief wordt er naar de steilste afdaling, in de richting van de negatieve gradiënt, toebewogen en worden de parameters geüpdatet [18]. Hieronder wordt SGD toegepast op het minimalisatieprobleem fui en de afdaling wordt berekend via de afgeleide, in functie van de parameters.

∂fui ∂bu = ∂ ∂bu  (rui− ˆrui)2+ λ1 bi2+ b2u+ ||qi||2+ ||pu||2
 = 2(rui− ˆrui)(−1) + λ1(2bu) = −2eui+ 2λ1bu = −2(eui− λ1bu) ∂fui ∂bi = ∂ ∂bi  (rui− ˆrui)2+ λ1 bi2+ b2u+ ||qi||2+ ||pu||2
 = 2(rui− ˆrui)(−1) + λ1(2bi) = −2eui+ 2λ1bi = −2(eui− λ1bi) ∂fui ∂pu = ∂ ∂pu  (rui− ˆrui)2+ λ1 bi2+ b2u+ ||qi||2+ ||pu||2
 = 2(rui− ˆrui)(−qi) + λ1(2||pu||) = −2eui.qi+ 2λ1.pu = −2(eui.qi− λ1pu) ∂fui ∂qi = ∂ ∂qi  (rui− ˆrui)2+ λ1 bi2+ b2u+ ||qi||2+ ||pu||2
 = 2(rui− ˆrui)(−pu) + λ1(2||qi||) = −2eui.pu+ 2λ1.qi = −2(eui.pu− λ1qi)

De vectoren bu, bi, puen qiworden random geïnitialiseerd en voor alle gekende reviews worden de berekeningen herhaald. Er wordt een leerfactor [19] als hyperparameter gebruikt om te bepalen hoeveel het model verandert bij elke update van de gewichten. Indien de leerfactor te klein wordt gekozen, zal het leerproces te lang duren en mogelijks blokkeren. Indien de leerfactor te groot wordt gekozen, kan het leerproces onstabiel worden of worden er te snel suboptimale

2.2. COLLABORATIVE FILTERING 31 gewichten gebruikt. De fout euistelt het verschil voor tussen de werkelijke en verwachte rating. Het leerproces van de verschillende parameters met leerfactor γ wordt voorgesteld als volgt:

θ ← θ − α∂fk ∂θ eui= rui− ˆrui bu ← bu+ γ(eui− λbu) bi← bi+ γ(eui− λbi) pu← pu+ γ(eui· qi− λpu) qi← qi+ γ(eui· pu− λqi)

De oude waarden zullen langzaam aan vergeten worden aangezien hun bijdrage steeds kleiner wordt. De vectoren worden bij SGD steeds gelijkertijd geüpdatet. Het oorspronkelijke algoritme van Funk volgde echter Alternating Least Squares (ALS), waarbij de vectoren afwisselend bere-kend worden. Hiernaast is het ook mogelijk de berekeningen te ontkoppelen zodat bu en biapart berekend kunnen worden via volgende, minder nauwkeurige, formules:

bi = P iR(i)(R(ui) − µ) 2 + |R(i)| bu= P uR(u)(R(ui) − µ − bi) 3 + |R(u)|

Wanneer alle vectoren berekend zijn, kunnen de nodige reviews geschat worden met volgende formule.

ˆ

rui= µ + bu+ bi+ pu· qi

Uitbreidingen op SVD

Matrixfactorisatiemodellen kunnen gemakkelijk aangevuld worden met bijkomende features, zo-als impliciete feedback of tijdsvariërende info. Hieronder worden nog enkele uitbreidingen op SVD voorgesteld waar geen gebruik van werd gemaakt.

SVD++ [16] is een verdere uitbreiding op SVD waarbij er wél rekening gehouden wordt met im-pliciete feedback zoals zoek- en klikgeschiedenis of karakteristieken van gebruikers en producten. In de receptenapplicatie wordt er echter verondersteld dat gebruikers bij het zien van een foto of naam van een gerecht over te weinig info (ingrediënten, werkwijze, gemiddelde score) beschikken om een oordeel te vormen waardoor dit niet gebruikt werd. Er zal ook pas in de postprocessing rekening gehouden worden met enkele karakteristieken van gebruikers en recepten. Zo kan er duidelijk geprogrammeerd worden wat er precies moet gebeuren.

PMF [20] kan gezien worden als een probabilistische extensie op SVD waarbij er lineaire schaling is met het aantal user-item-interacties en waarbij er een goede performantie is op een grote

sparse dataset. Bij probabilistische matrixfactorisatie worden er geen extra parameters gebruikt

om de algemeen hoge bias te verlagen. Deze versie wordt dan ook bekomen wanneer de baseline

predictors weggelaten worden. Hieronder staan zowel de minimalisatiefunctie als de berekende

afdaling via SGD. min pu,qi X rui∈R (rui− pu· qi)2. ∂fui ∂pu = ∂ ∂pu (rui− pu· qi)2 = 2(rui− pu· qi)(−qi) = −2qi(rui− pu· qi) ∂fui ∂qi = ∂ ∂qi (rui− pu· qi)2 = 2(rui− pu· qi)(−pi) = −2pu(rui− pu· qi) Vervolgens worden de volgende leerparameters bekomen.

θ ← θ − α∂fk ∂θ

pu← pu+ α · qi(rui− pu· qi)

qi← qi+ α · pu(rui− pu· qi)

Wanneer alle vectoren berekend zijn, kunnen de nodige reviews geschat worden met volgende formule.

ˆ

rui= pu· qi

Terwijl er bij SVD een hogere kans is op overfitting, is er bij PMF meer aanleiding tot under-fitting. Er werd geen gebruik gemaakt van PMF aangezien er verkozen werd een lagere bias te behalen via SVD.

Het is ook mogelijk dat receptenvoorkeuren wijzigen met de tijd (seizoensgebonden, smaak ver-andert met de leeftijd), maar toch wordt er geen rekening gehouden met tijdsfactoren aangezien dit buiten de scope van het project ligt.

2.3 Hybrid filtering

Het is mogelijk dat meerdere filtertechnieken gecombineerd moeten worden tot het voldoen aan de voorafbepaalde kwalificaties van het recommender system. Zo’n hybride systeem werd ook verkozen bij het uitbouwen van de receptenapplicatie. Enerzijds wordt model based collaborative

filtering, meer bepaald matrixfactorisatie, verkozen om een goede nauwkeurigheid te bereiken én

om een goede basis te creëren qua coverage. Anderzijds wordt content based filtering gebruikt zodat de diversiteit meer uitgewerkt kan worden. In het volgende hoofdstuk zal de gevolgde werkwijze verklaard worden voor het combineren van beide filtertechnieken.

3

Recommender system van de receptenapplicatie

In deze sectie wordt er beschreven hoe de uiteindelijke suggesties tot stand komen na gebruik van SVD en TF-IDF, respectievelijk voor het voldoen aan de nauwkeurigheids- en diversiteitskwa-lificaties. Er wordt steeds gewerkt met de variabelen M en N, waarbij M>N en N=10 gekozen werd bij de werkelijke receptenapplicatie. Bij de evaluaties in hoofstuk 5 werd een hogere N gekozen om de invloed van de postprocessing duidelijker te maken. Hierbij stellen M en N het aantal voorstellen in de recommandatielijst voor, respectievelijk voor en na filtering.

3.1 Basisrecommandaties in de receptenapplicatie

Er werd gekozen om matrixfactorisatie (SVD) met behulp van reviews te gebruiken voor het opbouwen van de recommandaties in de receptenapplicatie. De verdere verwerking van deze resultaten (postprocessing) wordt daarentegen gebaseerd op sociale info (gevolgden, groepsleden),

features van items (ingrediënten, titels) en gebruikers (favorieten, allergieën, lifestyle, dieet).

Eerst wordt SVD op de hele dataset getraind via een bestand in het formaat ”userid itemid rating” waarna de scores voor de ontbrekende user-item interacties geschat worden. De output wordt in het formaat ”userid itemid rating estimation details” verkregen, zonder info over de gebruikte latente factoren. De meegegeven userid’s stellen de gebruikersprofielen voor (waar-van er meerdere tot één account en groep kunnen behoren). Voor elk gebruikersprofiel wordt er vervolgens een top M van elke gang overgehouden waarna die suggesties een eerste keer ge-filterd worden op allergieën, lifestyle en dieet en de top N per gang geselecteerd wordt. Die

gefilterde verzameling wordt in de databank opgeslagen, zie code in Bijlage F. Elke dag worden deze basissuggesties één keer vernieuwd aangezien er anders onnodig veel berekeningen zouden worden uitgevoerd. In feite is het enkel zinvol de training opnieuw uit te voeren nadat iemand een nieuwe rating heeft geplaatst, anders wordt dezelfde trainingset verkregen. Er zijn echter enkele uitzonderlijke gevallen waarbij deze top N suggesties per gang onmiddellijk ververst zou-den moeten kunnen worzou-den, namelijk wanneer een nieuw profiel aangemaakt wordt. Om dit te kunnen vermijden, werd er gekozen de eerste dag te werken met de populairste aanbiedingen, na filtering op de beperkingen, en pas vanaf de volgende dag effectief recommandaties voor te stellen. De gebruiker zal dit hoogstwaarschijnlijk niet opmerken. Om geen cold start problem te verkrijgen, moet de gebruiker bij het aanmaken van een profiel minimum twee gerechten selec-teren per gang. De verkozen gerechten krijgen een score van 4/5 die later nog aangepast kan worden, maar dient voor de eerste ladingen suggesties.

3.2 Diversiteit in de receptenapplicatie

De opgevraagde suggesties van een groep gebruikers worden gebaseerd op de opgeslagen top N per gang van alle mee-eters en diegenen die ze volgen, weliswaar na een tweede filtering op de beperkingen van alle mee-eters. De nieuwe scores worden beïnvloed door een respectievelijk gewicht van 2/3 en 1/3 voor de basisscores van de mee-eters en gevolgde gebruikers. Er werd gekozen voor deze parameterwaarden om toch voldoende effect te kunnen zien in de evaluaties. Het is natuurlijk ook mogelijk dat er geen gevolgde gebruikers zijn waardoor dit onderdeel voor elk recept herleid wordt tot 0. Aangezien enkel de volgorde van de recepten interessant is, maakt het dan ook niet uit of de mee-eters een gewicht van 3/3 of 2/3 krijgen. Na deze berekeningen worden de verkregen resultaten gesorteerd om een nieuwe top M te verkrijgen. Op deze manier is het weliswaar mogelijk dat enkele leden uit een grote groep de bovenste recepten een slechte score gaven, maar dit niet tot uiting kwam door de overige reviews. Naast de verdeling 2/3-1/3, werd er niet meer getest op andere verhoudingen wegens de lange testduratie.

rgroep,i= 2/3 ∗ n X m=1 ˆ rm,i n + 1/3 ∗ n X g=1 ˆ rg,i n

Om meer diversiteit te verkrijgen, wordt de similariteit tussen de recepten uit de top M berekend via content based filtering (TF-IDF). Elk receptenpaar krijgt zo’n similariteitsscore op basis van hun features ”titel” en ”ingrediënten”. TF-IDF zorgt ervoor dat ingediënten zoals ”peper” en ”zout” die vaak voorkomen in gerechten, minder bijdragen tot de similariteit tussen de recepten. De gevolgde werkwijze is voorzien in code Bijlage E. De TfidfVectorizer [21] gaat allereerst de tekst binnen de features normaliseren door punctuatie te verwijderen, de tekst over te zetten naar kleine letters én vervolgens alle stopwoorden te negeren. Vervolgens worden TF en IDF berekend, voor beide kenmerken afzonderlijk, en opgeslagen in een matrix. De similariteit tussen twee documenten (hier gerechten) op basis van ingrediënten en titel kan vervolgens berekend worden via een cosinusfunctie op respectievelijk twee keer de ingrediëntenmatrix en twee keer

3.2. DIVERSITEIT IN DE RECEPTENAPPLICATIE 35 de titelmatrix [22]. Vervolgens kan de uiteindelijke similariteit tussen twee gerechten verkregen worden door hun twee similariteitsscores op te tellen, wat leidt tot een maximale similariteit van 2. In het algoritme worden alle gerechten uit de huidige recommandatielijst afgelopen en wordt de similariteit van elk (M+1)’de gerecht vergeleken met die van de vorige M gerechten om te bepalen welke gerechten overgehouden worden. Indien twee gerechten een similariteit boven 0.70 vertonen, wordt het gerecht met de kleinst verwachte rating uit de recommandatielijst verwijderd. Op deze manier wordt er meer diversiteit gecreëerd in de uiteindelijke aanbevelingen. De uiteindelijke top N wordt via een message overgestuurd naar de webapplicatie en dus niet opgeslagen in de databank. Bij het wijzigen van profielsbeperkingen, toevoegen of verwijderen van groepen en (ont)volgen van gebruikers kan de opgeslagen basisverzameling behouden worden aangezien de tweede filtering de nodige wijzigingen kan verwerken. Hierdoor is het zinvoller deze uiteindelijke berekeningen (postprocessing) in real-time af te leggen.

Het doel is om dagelijks enkele andere aanbevelingen te verkrijgen en zolang er nieuwe reviews worden gegeven door de groepsleden en gevolgden of door voldoende buitenstaanders, worden onder invloed van TF-IDF, SVD en het volgersysteem nieuwe suggesties verkregen.