1 Introduction
Food recommender systems | Papers | Recommendation approaches | Functionality |
---|---|---|---|
Type 1: Considering user preferences | (El-Dosuky et al. 2012) |
Knowledge-based recommendation
| Proposing a framework for a Personalized nutrition service with knowledge-based recommendation. |
(Freyne and Berkovsky 2010) |
CB, CF, Hybrid recommendation
| Predicting item ratings by breaking down recipes into ingredients and vice versa. | |
(Freyne et al. 2011) |
CB, CF, Hybrid recommendation
| Improving the quality of recommendations by using machine learning techniques and an understanding of user reasoning. | |
(Svensson et al. 2000) | CF | Developing an on-line grocery store to provide users with recipe recommendations by analyzing the social navigation in groups. | |
(Elahi et al. 2015) |
Matrix factorization
| ChefPad - Generating food recommendations by eliciting users’ long-term and short-term preferences. | |
(Kuo et al. 2012) |
Graph-based recommendation
| Recommending sets of recipes by using user-specified ingredients. | |
Type 2: Considering nutritional needs of users | (Ueta et al. 2011) |
Goal-oriented recipe recommendation which suggests the right type of nutrient to treat users’ health problems | Helping users to deal with health problems (e.g., acne) |
(Aberg 2006) |
Hybrid recommendation (CB & CF), Constraint-based recommendation
| Meal Planning System - Aiding the elderly to deal with malnutrition problems and change the food consumption behavior. | |
Type 3: Balancing between user preferences and nutritional needs of users | (Elsweiler et al. 2015) |
CB
| Applying different approaches to bring healthiness aspects into recommender systems. |
Type 4: Food recommender systems for groups | (Berkovsky and Freyne 2010) |
CF, group-based recommendation
| Applying different aggregation strategies and user weighting models to generate recipe recommendations to a group of users. |
(Elahi et al. 2014) |
Group recommendation, Critiquing-based conversational recommendation
| ChefPad - Generating food recommendations to groups by exploiting users’ tags and ratings. |
2 Recommender systems
2.1 Recommendation techniques for individuals
-
Requirement specification: Users can interact with a recommender system for specifying their requirements.
-
Repair of inconsistent requirements: If the recommender can not find a solution, it suggests a set of repair actions, i.e., it proposes alternatives to user requirements ensuring the identification of a recommendation (Felfernig et al. 2011).
-
Presentation of results: A set of alternatives is delivered to the user. These are usually presented as a ranked list according to the item utility for the user (Felfernig et al. 2006).
-
Explanation: For each presented alternative, the user can activate a corresponding explanation to understand why a specific item has been recommended (Felfernig et al. 2006).
2.2 Recommendation techniques for groups
-
Aggregated model generates predictions for a group on the basis of aggregating individual user preferences into a group profile. The group recommendation process can be executed in three steps: First, users with similar preferences will be classified in subgroups. Next, the available items will be ranked based on each subgroup preference. Finally, related items in subgroups are merged to get the ranking for the whole group. This approach was applied in some well-known systems, e.g., musicfx (McCarthy and Anagnost 1998) and intrigue (Ardissono et al. 2003) for the purpose of supporting a group of users to choose suitable alternatives.
-
Aggregated prediction firstly computes the recommendation for each group member and then computes the intersection of individual recommendations to get the common recommendations for whole the group. For instance, polylens (O’Connor et al. 2001) generates a ranked list of movies for each group member by using a classic CF approach. After that, the individual ranked lists are merged according to the least misery strategy, i.e., group’s happiness is the minimum of the individual members’ happiness scores.
3 Food recommender systems
3.1 Type 1: Considering user preferences
-
Break down an unrated target recipe r t into ingredients i n g r 1, i n g r 2, ..., i n g r n .
-
Assign the rating value for each ingredient in the target recipe r t according to (1) as shown below. Particularly, the rating value of the user u a for a specific ingredient i n g r i in the target recipe r t (i.e., rat(u a , i n g r i )) is calculated by using rating values of the user u a for all other recipes r l which contain the ingredient i n g r i (i.e., rat(u a , r l )). The value l mentioned in (1) is the number of recipes containing i n g r i .$$\begin{array}{@{}rcl@{}} \text{rat }(u_{a}, ingr_{i}) = \frac{{\sum}_{l\;s.t\; ingr_{i} \;\in \; r_{l}} rat(u_{a}, r_{l})}{l} \end{array} $$(1)
-
Predict the rating value of the user u a for the target recipe r t (i.e., pred(u a , r t )) based on the average of all the rating values of all ingredients i n g r 1, ..., i n g r j included in this recipe (see (2)).$$\begin{array}{@{}rcl@{}} \text{ pred }(u_{a}, r_{t}) = \frac{{\sum}_{j \; \in \; r_{t}} rat(u_{a}, ingr_{j})}{j} \end{array} $$(2)
3.2 Type 2: Considering nutritional needs of users
-
Step 1: An energy table from DACH4 (see Fig. 3) is used to estimate the amount of calories (in kcal) which the user u a should get per day. The amount of calories intake per day for each person is estimated according to age, gender and PAL (Physical Activity Level) value. PAL value is categorized into 3 types: + PAL = 1.4: Is used for people who have exclusively sedentary lifestyles (such as office workers, precision mechanics) with very little or no strenuous leisure activity. + PAL = 1.6: Is used for people who have sedentary lifestyles, but an additional energy is required for long-time walking and standing activities, such as laboratory assistants, students, production line workers. + PAL = 1.8: Is used for people who have extensive lifestyles, for instance, sellers, waiters, mechanics, artisans. In this example, user u a is an office worker with very little physical activity (only 10 minutes/day for walking), that means his PAL value belongs to the first type. By looking up information regarding age, gender and physical activity from Fig. 3, we can find the daily calories intake for u a is 2200 kcal.
-
Step 2: Filtering menus with the amount of calories smaller or equal 2200 kcal/day.
-
Step 3: Ranking filtered menus in the ascending order of fat (since u a has heart disease, less fatty menus will be shown to him first).
Menus | Main ingredients | Calories (kcal) | Fat(%) |
---|---|---|---|
m
e
n
u
1
| Butter, chicken, potato, cucumber, cream, garlic, salt, pepper | 2010 | 27 |
m
e
n
u
2
| Pork, mushroom, broccoli, paprika, green onion, oil, salt, pepper | 2200 | 30 |
m
e
n
u
3
| Chicken, mushroom, salad, onion, olive oil, tomato, salt, pepper | 1500 | 21 |
m
e
n
u
4
| Beef, shrimp, tomato, garlic, egg, salt, pepper | 2400 | 31 |
m
e
n
u
5
| Pork, bean, tomato, pumpkin oil, salad, egg, salt, pepper | 1700 | 25 |
Menus | Main ingredients | Calories (kcal) | Fat(%) |
---|---|---|---|
m
e
n
u
3
| Chicken, mushroom, salad, onion, olive oil, tomato, salt, pepper | 1500 | 21 |
m
e
n
u
5
| Pork, bean, tomato, pumpkin oil, salad, egg, olive oil, salt, pepper | 1700 | 25 |
m
e
n
u
1
| Butter, chicken, potato, cucumber, cream, garlic, salt, pepper | 2010 | 27 |
m
e
n
u
2
| Pork, mushroom, broccoli, paprika, green onion, oil, salt, pepper | 2200 | 30 |
-
Dietary restrictions, such as allergic ingredients.
-
Nutritional values, such as the amount of fat or protein contained in a recipe.
-
Preparation time of a meal.
-
Preparation difficulty of a meal.
-
Cost of necessary ingredients for a meal.
-
The availability of ingredients for a meal.
-
The variety of meals in terms of used ingredients and meal category.
-
User food preferences, i.e., rating of a user for a certain recipe.
Constraint satisfaction problem | Parameter-based approach |
---|---|
Variables | Time, cost, energy, protein |
Variable domains | Variable domains are defined on the basis of existing values in the recipe database (e.g., cost = [1..100] represents the cost of a recipe can be from 0 to 100 euros). |
Knowledge base |
Hard constraints:
|
– The constraint: {\(allergies = seafood \Rightarrow ingredients \neq sea-crab\)} represents the knowledge that if a user is allergic to seafood then sea-crab should not be included into recommended recipes. | |
Soft constraints: | |
– For the variety of recipes, recipes having many similar ingredients to the previous meals will not be chosen (e.g., beef and potato will not be chosen for dinner today because they were already consumed on lunch); | |
– Recipes with high predicted rating will have higher probability to be recommended to users. |
-
V = {time, cost, ingredients, energy, protein, allergies, diseases}
-
D = {dom(time) = [1..60], dom(cost) = [1..100], dom(energy) = [1..3000], dom(protein) = [1..100], dom(allergies) = [ m i l k,e g g,p e a n u t,s e a f o o d,w h e a t], dom(diseases) = [ d i a b e t e s, c a r d i o v a s c u l a r, p a r k i n s o n, d i g e s t i o n, a l z h e i m e r,o s t e o a r t h r i t i s,o s t e o p o r o s i s], dom(ingredients) = [ v e g e t a b l e s, s h r i m p, s e a−c r a b, f i s h, p o r k, b e e f, c h i c k e n,s p i c e s, b u t t e r, c h e e s e, f r u i t s] }
-
CKB = { c 1 : t i m e < 60, c 2 : c o s t < 100, c 3 : e n e r g y < 3000, c 4 : p r o t e i n < 35%, c 5 : d i s e a s e = c a r d i o v a s c u l a r ⇒ p r o t e i n < 30, c 6 : a l l e r g i e s = s e a f o o d ⇒ i n g r e d i e n t s≠s e a − c r a b }
-
PREF = { p r e f 1 : t i m e < 30,p r e f 2 : c o s t < 50, p r e f 3 : e n e r g y = 2200,p r e f 4 : p r o t e i n = 25%, p r e f 5 : a l l e r g i e s = s e a f o o d,p r e f 6 : d i s e a s e = c a r d i o v a s c u l a r}
3.3 Type 3: Balancing between user preferences and nutritional needs of users
-
Step 1: Estimating the daily amount of calories for user u a by looking up the energy table shown in Fig. 3. The user u a is an office worker and has very little physical activity per day (only 10 minutes/day for walking), hence the nutrient intake of the user u a is 2200 kcal.
-
Step 2: Filtering menus from Table 2 which contain lower or equal 2200 kcal of calories, and include favourite ingredient “tomato”.
-
Step 3: Ranking filtered menus in the ascending order of fat (because u a has vascular disease, less fatty menus will be shown to him first).
Menus | Main ingredients | Calories (kcal) | Fat(%) |
---|---|---|---|
m
e
n
u
3
| Chicken, mushroom, salad, onion, olive oil, tomato, salt, pepper | 1500 | 21 |
m
e
n
u
5
| Pork, bean, tomato, pumpkin oil, salad, egg, salt, pepper | 1700 | 25 |
-
The first approach figures out trade-offs between giving the user some foods she really likes and some foods which are really healthy to her. This approach is implemented by using the following steps. First, a prediction algorithm estimates the top recipes for the user, i.e., a set of recipes with predicted probability above a certain threshold. Next, the amount of calories and fat per gram for each recipe in the chosen set is calculated. Finally, meals with less fat or calories per gram will be chosen for the final recommendation.
-
In the second approach, instead of recommending individual meals, this approach proposes complete meal plans, which are generated not only based on the users’ food preferences but also conform to daily nutritional guidelines (Harvey and Elsweiler 2015). For making recommendations, the user provides information regarding his/her preferences by rating a number of recipes in the system on a 5-star rating scale. In addition, the “Recommender” also takes into account additional users’ personal information, such as height, weight, age, daily activity level, and goal (lose, gain, or maintain weight) in order to calculate the nutritional needs. The nutritional requirements of users are calculated by using an updated version of the Harris Benedict equation (Roza and Shizgal 1984). After that, the “Recommender” predicts ratings for unrated recipes and sends a ranked list of recipes with high ratings (e.g., 4 or 5 stars) to the “Planner”. The “Planner” takes top-n recipes from the ranked list of recipes and splits them into two separated sets: one for breakfasts and one for main meals. A full search is performed to find all combinations of these recipes in the sequence {Breakfast, Main meal, Main meal} which meets the target nutritional needs. For instance, {Muesli Breakfast Muffins, Catalan Chickpeas, Chicken Cacciatore} (Harvey and Elsweiler 2015) represents a complete menu recommended to users, where Muesli Breakfast Muffins is for breakfast, Catalan Chickpeas for lunch, and Chicken Cacciatore for dinner. Combinations with the same recipes can not be repeated, for instance, { r 1,r 2,r 3} and {r 1,r 3,r 2} are considered as only one menu plan.
3.4 Type 4: Food recommender systems for groups
-
Aggregated models strategy. First, this strategy computes a rating r a t(f a ,r i ) for a family f a and recipe r i by aggregating the individual ratings r a t(u x ,r i ) of family members u x ∈ f a who rated recipe r i according to their relative weight ω(u x ,f a ) (see (3)). The authors add weights into the rating calculation process for the purpose of allowing some users in a family to have more influence on the group decision than others. For instance, parents have more influence on the group decision than children, therefore weights assigned for parents are higher than the children’s ones. The details of weighting models will be presented in the next paragraph.After that, CF is applied to the family model. Particularly, a prediction p r e d(f a ,r i ) for the whole family f a and unrated recipe r i is generated by computing similarity degree s i m(f a ,f b ) between the family f a and all other families f b ∈ F, and then aggregating all family’s ratings r a t(f b ,r i ) for recipe r i according to the similarity degree s i m(f a ,f b ) (see (4)).$$\begin{array}{@{}rcl@{}} rat(f_{a}, r_{i}) = \frac{{\sum}_{x\in f_{a}}\omega(u_{x}, f_{a})rat(u_{x}, r_{i})}{{\sum}_{x\in f_{a}}\omega(u_{x}, f_{a})} \end{array} $$(3)$$\begin{array}{@{}rcl@{}} pred(f_{a}, r_{i}) = \frac{{\sum}_{f_{b}\in F}sim(f_{a}, f_{b})rat(f_{b}, r_{i})}{{\sum}_{f_{b} \in F}sim(f_{a}, f_{b})} \end{array} $$(4)
-
Aggregated predictions strategy. First, this strategy generates individual predictions p r e d(u x ,r i ) for user u x and unrated recipe r i by using the standard CF algorithm (see (5)). In this prediction, the degree of similarity s i m(u x ,u y ) between the target user u x and all other users u y ∈ U is calculated according to (6) Freyne et al. (2011). Then, individual ratings r a t(u y ,r i ) of users who rated r i are aggregated according to the similarity degree s i m(u x ,u y ).where:$$\begin{array}{@{}rcl@{}} pred(u_{x}, r_{i}) = \frac{{\sum}_{y \in U}sim(u_{x}, u_{y})rat(u_{y}, r_{i})}{{\sum}_{i \in U}sim(u_{x}, u_{y})} \end{array} $$(5)where k is the number of items already rated by the user u x and the user u y .$$\begin{array}{@{}rcl@{}} sim(u_{x}, u_{y}) = \frac{{\sum}_{i=1}^{k}(u_{x_{i}} - \overline{u_{x}})(u_{y_{i}} - \overline{u_{y}})}{\sqrt{{\sum}_{i=1}^{k}(u_{x_{i}} - \overline{u_{x}})^{2}}\sqrt{{\sum}_{i=1}^{k}(u_{y_{i}} - \overline{u_{y}})^{2}}} \end{array} $$(6)After that, to generate the prediction p r e d(f a ,r i ) for the whole family f a and recipe r i , individual predictions p r e d(u x ,r i ) of family members u x ∈ f a are aggregated according to their relative weight ω(u x ,f a ) (see (7)).Both aggregated models strategy and aggregated predictions strategy recommend a list of recipes to the whole family by considering the task of recommending top-k recipes, i.e., k recipes having the highest predicted ratings.$$\begin{array}{@{}rcl@{}} pred(f_{a}, r_{i}) = \frac{{\sum}_{x\in f_{a}}\omega(u_{x}, f_{a})pred(u_{x}, r_{i})}{{\sum}_{x \in f_{a}}\omega(u_{x}, f_{a})} \end{array} $$(7)The evaluation results on MAE (Mean Absolute Error) show that aggregated models strategy are usually predominant to aggregated predictions strategy (Berkovsky and Freyne 2010). This means that individual models of users should be aggregated into a group model first and then using this model in the recommendation process.
-
Weighting models. Inspired by allowing for some users to have more influence than others, the authors proposed four different weighting models when aggregating the data of individual users. Two first models (called uniform model and role-based model) assign pre-defined weights for users. Particularly, the uniform model uses the same weight for all group members. The role-based model weights users according to their role. For instance, there are two roles specified in a family party: organizer and family member. The weight for the organizer will be 2 because she is responsible for organizing the party as well as preparing food. Whereas, the weights for family-members are 1 because they are likely less important people. Two other models (called role-based model and family-log model) weight users according to their interactions with the content. The role-based model weights users according to their activities across the entire community. The activity of a certain user is predicted based on the number of ratings which (s)he rated for items. The family-log model weights users according to their activities in relation to other family members.
Recipes | |||||
---|---|---|---|---|---|
User |
r
e
c
i
p
e
1
|
r
e
c
i
p
e
2
|
r
e
c
i
p
e
3
|
r
e
c
i
p
e
4
|
r
e
c
i
p
e
5
|
u
s
e
r
1
| 4 | 4 | 4 | 2 | 5 |
u
s
e
r
2
| 4 | 4 | 5 | 4 | 5 |
u
s
e
r
3
| 5 | 2 | 5 | 4 | 3 |
u
s
e
r
4
| 4 | 5 | 3 | 3 | 4 |
Group (Least misery strategy) |
4
| 2 | 3 | 2 | 3 |
4 Research challenges
Research challenges | Proposed solutions |
---|---|
Collecting user information | – Taking advantage of information about users’ previous meals (Van Pinxteren et al. 2011). |
– Implicitly collecting user information so that they don’t have to invest too much time and effort (Freyne and Berkovsky 2010). | |
Gathering nutritional information of recipes | – The quantity of gathered recipes should be representative enough to vary the recommendations. |
Recommendation algorithms | – Improving the quality of recommendations by integrating constraints (e.g., health situations, nutrition needs, the availability of ingredients) into the recommendation process. |
Explaining recommendations | – Providing explanations which increase the trustworthiness of decision outcomes and persuade users to accept food recommendations (Elahi et al. 2014). |
Changing eating behaviors | – Employing health psychology theory in food recommender systems to encourage users to comply healthy eating behaviors (Snooks 2009). |
– Proposing potential dietary changes on the basis of exploiting the ideal nutrients from reliable resources (e.g., USDA, DACH). | |
Generating bundle recommendations | – Expressing acceptable trade-offs among group members by employing negotiation and argumentation mechanisms (Felfernig et al. 2014b). |
Achieving fast consensus in group decision making | – Enriching user interfaces supporting basic negotiation mechanisms among group members (Thuy Ngoc Nguyen 2017). |
4.1 Challenges regarding user information
-
The uncertainty of nutritional information from users: In order to make recommendations, the system needs to collect nutritional needs, ratings for food items/recipes and information of previous meals from users (Mika 2011). Most of the information is only provided through continuous interactions with users. However, in reality, recording nutritional intake from users can not avoid faults because users usually forget or give wrong information about the foods they have consumed (Mika 2011). Although some systems were proposed to tackle with these problems, for instance, foodlog (Aizawa et al. 2010), they are not able to give the accurate information about the consumed meals, even though they can estimate the nutritional balance among different kinds of food in a meal.
-
Collecting user rating data: Food recommender systems need information about users’ preferences to recommend similar food items ((Van Pinxteren et al. 2011; Mika 2011)). This information can be gathered by asking users to rate foods/recipes. However, it is not convenient if the system asks users to rate too many items. Hence, a challenge entailed is “How to collect enough users’ ratings while saving their effort?” Freyne and Berkovsky (2010). Besides, similar to keeping reporting food consumption (as mentioned above), persuading users to keep rating dishes also becomes another challenge for food recommender systems (Mika 2011).
4.2 Challenges regarding recommendation algorithms
-
User information (e.g., likes, dislikes, food consumption, or nutritional needs): Similar to recommender systems in other domains, food recommender systems also face with the cold-start problem when the system is used in the first time (Mika 2011). This problem can be surmounted by using information about users’ previous meals to calculate similarity and then recommend new recipes to users (Van Pinxteren et al. 2011). However, this solution requires many user efforts and abates the desire of system usage.
-
Recipe databases: Mika (2011) discussed two challenges that need to be solved:How many recipes the system should have? The quantity of gathered recipes should be large enough to accommodate the preferences of many users and vary the recommended recipes while still minimize the time for making recommendations. This is a tricky problem when the system tries to balance between the variety of recommendations and system response time. Hoxmeier et al. (Hoxmeier and Manager 2000) point out that long response times triggers user dissatisfaction which further decreases continuous use of the system.How to gather accurate nutritional information of recipes? It is observed that with the same food item, if we use different ways to cook it then we will get different nutritional values from it Mika (2011). Therefore, it is very difficult to ensure that whether gathered nutritional tables for food items are accurate because when comparing different nutritional value table of foods, sometimes it returns varying values for the same food items (Mika 2011). For instance, the nutritional value of celery in “a salad recipe” is different from the nutritional value of itself “in a fried recipe”, since cooking with high temperature make celery lose a big amount of essential oil. It means that the amount of essential oil of celery in the “fried recipe” could be lower than in the “salad recipe”.
-
A set of constraints or rules: Considering more constraints and rules in the recommendation process will improve the quality of recommendations (Mika 2011). For instance, with a user who has heart disease, the system should recommend menus with less fat and salt. Moreover, it is very necessary to detect the conflicts among the constraints or rules which prevent the recommendation algorithms from finding a solution. However, with the large database (e.g., thousands of foods/recipes), checking constraints/rules in the database brings negative effects for system performance (Mika 2011). In addition, food recommender systems should take into account constraints with regard to the availability of ingredients in the households for the purpose of helping users to save money and prevent the food waste behavior. The challenge here is how to propose food which meets health situations and nutritional needs of users, as well as taking advantages of the ingredients that are currently in the fridge. In this scenario, recommender systems seems to require many efforts from users because users have to report the consumption of all ingredients regularly and this can prevent users from using the system permanently.
4.3 Challenges regarding changing eating behavior of users
4.4 Challenges regarding explanations
4.5 Challenges regarding group decision making
-
Bundle recommendations: Group recommender systems usually attach the requirements/preferences of different users into group recommendation. This is the crucial idea discussed in many related studies (Masthoff 2011; O’Connor et al. 2001; Berkovsky and Freyne 2010). In the food domain, the aggregation process raises more challenges when users want to get recommendations for a complete meal with the combination of many recipes/food or a food schedule for more than one day (e.g., foods for next week). This issue is known as bundle recommendation which is a new research branch of recommender systems. The idea here is recommending a sequence of items instead of separated ones. In the healthy food domain, recommending a complete meal is even more complicated because the system has to consider not only preferences of group members but also other aspects, e.g., the variety of meals, weather and season (Van Pinxteren et al. 2011), the healthiness of recipes, health problems or daily nutrition needs of group members, etc. On the other hand, the recommendation of bundles has to assure the fairness among users within the group. It means that negotiation and argumentation mechanisms have to be developed in order to support group members to express acceptable trade-offs (Felfernig et al. 2014b). For instance, in a meal plan for a week, the preferences of users who were discriminated in previous meals should have a higher emphasis in the upcoming meals.
-
Achieving fast consensus in groups: In group recommender systems, although different aggregation approaches have been applied to generate group recommendations, such processes do not ensure that the recommended items reflect a high agreement level among group members (Castro et al. 2015). In this context, achieving consensus helps to bring individual preferences closer to each other before delivering group recommendations. However, further issues need to be considered in order to accelerate the achievement of consensus in groups. One of the promising solutions is enriching user interfaces which support basic negotiation mechanisms among users. User interfaces are designed such that all members can share their preferences within the group (Thuy Ngoc Nguyen 2017). Knowing the preferences of each other helps the group to reach a consensus quickly. An example thereof is the following: user A prefers cheese, whereas user B is interested in beef. There is a probability to achieve a consensus between user A and user B is that user A will eat recipes with beef as long as they include cheese. How to represent the current decision situation is considered as an issue of future work.