A Case-Based Solution to the Cold-Start Problem in Group Recommenders

1 Introduction

Groups often dine in restaurants together; visit historic sights, galleries and museums together; attend concerts, the theatre and the cinema together; vacation together; cook and eat together; watch TV together. They must reconcile the different preferences and personalities of the group members when selecting the items they intend to consume together, ranging from restaurants to TV programmes, and may seek the support of a recommender system. While the majority of recommender systems suggest items based on the preferences of an individual consumer, group recommender systems suggest items taking into account the preferences and personalities of the members of a group [Jameson and Smyth, 2007].

In this paper, in the context of movie recommendation to groups of friends, we consider a group recommender system that aggregates the results of running a single-person recommender system to predict movie ratings for each member of the group. The single-person recommender that we use is a user-based collaborative recommender system [Herlocker, 2000], which predicts a user's rating for a candidate movie from the ratings given to that movie by a neighbourhood of users who are similar to that user.

But collaborative recommenders suffer from cold-start problems [Herlocker, 2000; Schafer et al., 2007]. In particular, a user-based collaborative recommender finds it difficult to make good predictions for new users, for whom it has few ratings. The group recommender inherits this problem too because it aggregates the predicted ratings from the singleuser collaborative recommender. Solutions to the cold-start problem for single-person recommenders are summarized in [Schafer et al., 2007] and include: non-personalized recommendations for cold-start users using population averages; intelligent ways to solicit more ratings (e.g., [Golbandi et al., 2011; Rashid et al., 2002]); and hybrid recommenders that resort to content-based recommendations when there are insufficient ratings to make collaborative recommendations (e.g., [Balabanovic and Shoham, 1997; Melville et al., 2002]).

∗The paper on which this extended abstract is based was the recipient of the best paper award of the ICCBR 2012 [QuijanoS´anchez et al., 2012].

The contribution of this paper is to introduce and evaluate a case-based reasoning (CBR) solution to this problem. We use a case base in which each case records a previous group movie recommendation event. When a group requests a new recommendation but where one or more of the group members is in cold-start, we find a case that describes a previous recommendation event where there are users who are not in cold-start but who play similar roles in their group to the roles the cold-start users play in the active group. We temporarily copy ratings from the users in the case to the corresponding users in the active group and only then proceed to run the single-person recommender and to aggregate its results. It is natural to use a CBR approach because, similar events recur: the same group (perhaps with some small variations) repeats activities together; and some age, gender and personality distributions will tend to recur too (e.g., two adults with two children going to the movies).

CBR has been used in recommender systems before (e.g., [Ricci et al., 2002]) and explicit parallels between CBR and user-based collaborative recommenders have been drawn (e.g., [O'Sullivan et al., 2002]). But we are unaware of any previous use of CBR in group recommenders or in solutions to the cold-start problem.

Section 2 describes our group recommender method; Section 3 describes how we have extended our method to solve the cold-start problem; Section 4 proposes systems against which our system can be compared; Section 5 describes the dataset that we have used in our experiments; Section 6 presents our experimental method; Section 7 contains results; and Section 8 concludes our work.

2 Social Group Recommender Systems

Suppose there are n users, U = {u : 1 . . . n}, and m items (e.g., movies), I = {i : 1 . . .m}. Let ru,i be the rating that user u assigns to item i. Ratings are on a numeric scale, e.g., 1 = terrible and 5 = excellent, but ru,i = ⊥ signals that u has not yet rated i. Let Ga ⊆ U be an active group of users, in our case a group who intend going to see a movie together. The goal is to recommend to Ga a set of k items drawn from a set of candidate target items Ta ⊆ I. For example, Ta could be the set of movies showing this week at the local multiplex.

If none of the users in Ga is in cold-start the group recommender system operates as follows:

Step 1: It uses a user-based collaborative recommender to predict a rating ˆ rua,i for each ua ∈ Ga for the various i in Ta. The user-based collaborative recommender that we use works as described in [Herlocker, 2000; Schafer et al., 2007]. In brief, it computes the similarity between ua and each other user u ̸= ua who has rated i; it retrieves ua's 20 nearest neighbours, i.e. the 20 users who are most similar to ua; and its prediction ˆ rua,i is then a weighted average of the neighbours' actual ratings for i.

Step 2: For each i, it aggregates the predicted ratings of each ua ∈ Ga yielding a predicted group rating for that item:

where F is the aggregation function, which we discuss in more detail below.

• Step 3: Finally, it recommends the k items i ∈ Ta for which the predicted group ratings ˆ rua,i are highest.

Possible aggregation functions F include least misery (taking the minimum) and most pleasure (taking the maximum) [Masthoff, 2004]. We experimented with both before [Quijano-S´anchez et al., 2011a], and we found most pleasure to give better results, and so we adopt that here.

However, our previous work showed an improvement in the accuracy of predicted group ratings by taking into account the personality of the users in the group and the strength of their connections, which we refer to as their trust [QuijanoS´anchez et al., 2013; 2011a; Quijano-S´anchez et al., 2012]. We refer to our recommender that takes this extra social information into account as being social and the method it uses as being delegation-based. Specifically then, we have:

Here the most pleasure principle (maximum) is not applied directly to individual predicted ratings, ˆ rua,i. The ratings are modified by the dbr function, which takes into account personality and trust values within the group Ga.

We obtain the personality of each user u by requiring group members complete a personality test on registration with the recommender. The details of the personality test are in [Thomas and Kilmann, 1974]. In a real application, such as the Facebook social group recommender that we have built [Quijano-S´anchez et al., 2011b], trust between two users can be based on distance in the social network, the number of friends in common, relationship duration, and so on. Further details can be found in [Quijano-S´anchez et al., 2013].

We designate by Soc the social group recommender system outlined in this section.

3 Using CBR for Cold-Start Users

As explained above, an active user with few ratings is said to be in cold-start. For the recommender systems discussed here, this situation makes it challenging to find a reliable neighbourhood of similar users from which predictions can be made. One solution is to temporarily copy some ratings into the profile of the active cold-start user from a similar user who has additional ratings. Similarity in this case would be measured using demographic information [Schafer et al., 2007] because the active user has insufficient ratings to find a similar user based on co-rated items.

A group recommender can take the same approach when members of the group are in cold-start: prior to predicting individual ratings, it can temporarily augment the ratings profiles of group members who are in cold-start with ratings that are copied from the profiles of similar users. But in a group recommender, we can go further than using just demographic information. In our work, we investigate how to reuse ratings from similar users in similar groups in a case-based fashion.

Assume a case base CB in which each case c ∈ CB records a previous group movie recommendation event. Each case will have the following structure: 〈idc, 〈Gc, Tc〉, ic〉 where idc is a case identification number. The problem description part of the case comprises:

• Gc ⊆ U, the group of users who used the recommender previously. For each user u ∈ Gc, we will know u's age and gender; u's ratings, ru,i, for some set of items; and u's personality value. For each pair of users u ∈ Gc, v ∈ Gc, u ̸= v, we will know the trust value.
• Tc ⊆ I, the set of items that the users were choosing between. In our case, these were the movies that were at the local multiplex on the occasion when this group used the recommender.

And the solution part of the case contains just ic ∈ Tc, the item that the group agreed on. In our case, this is the movie that the group went to see together.

If none of the users in Ga is in cold-start, then the system will work in either of the fashions described in Section 2.

But suppose, on the other hand, that one or more members of Ga are in cold-start. We define this simply using a threshold, θ: a user ua is in cold-start if and only if the number of items s/he has rated is less than θ. In this case, we need to use the CBR. For each user who is in cold-start, we will copy ratings from the most similar user in the most similar group in the case base, as follows.

Case retrieval

We can write the problem statement as PS = 〈Ga, Ta〉. We will find the most similar case, c∗ , in the case base:

The similarity between a problem statement PS = 〈Ga, Ta〉 and a case c = 〈idc, 〈Gc, Tc〉, ic〉 ∈ CB, sim(PS, c), is calculated on the basis of group similarity:

This means that in our work case similarity takes only the groups, Ga and Gc, into account; it does not take into account the items, Ta and Tc. Tc contains the items that Gc contemplated in the past, but Ta contains items that Ga is contemplating right now, e.g., movies that have just come to town, and these sets need not even overlap.

This process requires a definition of group similarity, gsim. We compute the similarity of any pair of groups, G and G′ , from the similarity of the users in the two groups, psimCB(u,G, u′ ,G′ ), u ∈ G, u′ ∈ G′ . Specifically, we define gsim(G,G′ ) to be the average similarity of each user u in G to his/her most similar user in G′ . Note that we do not prevent two or more people from G being associated with the same user u′ ∈ G′ (and vice versa). This fact allows us to easily compare groups of different sizes. It does mean that, if two or more users from Ga are in cold-start, they may all copy ratings from the same user u′ ∈ G.

We define psimCB(u,G, u′ ,G′ ), the similarity between two users in groups, as an average similarity over the data that we hold about them: their ratings, gender, ages, personality values and trust values [Quijano-S´anchez et al., 2012].

Case reuse

Next, for each user ua in Ga who is in cold-start, we find the most similar user u∗ in case c∗ who has rated movies that ua has not. Let G∗ be the group of people described in case c∗ :

In the case of more than one such user, we choose the one from whom we can copy the most ratings, i.e. the one who has most ratings for movies that ua has not rated. Then, temporarily (for the purposes of making ua's prediction for the items in Ta), we copy into ua's profile the rating for each item i that u∗ has rated (ru∗ ,i ̸= ⊥) that ua has not (ru,i = ⊥).

With each cold-start user's profile augmented in this way, we can then proceed to compute group recommendations in the fashion described in Section 2. But, it should now be less problematic finding neighbourhoods for the users who are in cold-start because they now have augmented user profiles. We designate this system by Soc-CB.

4 Other Recommenders for Cold-Start Users

An obvious question is whether it makes a difference that our case-based solution to the cold-start problem in group recommenders works on a group basis at all. Why copy ratings from the most similar user in the most similar group? Why not copy ratings simply from the most similar user in the case base as a whole? Or why not copy ratings from the most similar user known to the system? Systems that work in these different ways will be useful for comparisons in our experiments, hence we define both of these more precisely now.

Consider the set of users who appear in at least one case in the case base:

When trying to predict group Ga's rating for an item i ∈ Ta, then for any user u ∈ Ga who is in cold-start, we could find, and copy ratings from, the most similar user in UCB:

This is different from first finding the most similar group and then, for each active user in cold-start, copying ratings from the most similar user in that group. Our case-based approach is conditioned on the groups; this alternative is not. We designate this recommender by Soc-UCB.

The second of our two alternative cold-start recommenders ignores the case base altogether. It finds, and copies ratings from, the most similar user in U (the entire set of users), wholly ignoring whether they have previously participated in group recommendations or not. Hence,

We designate this recommender by Soc-U.

5 Group Recommender Dataset

We need a dataset on which to evaluate our case-based solution to the cold-start problem in group recommenders. We are not aware of a public dataset for group recommenders, hence we created our own. We started from the MovieLens 1M dataset (www.grouplens.org). For each user, it records gender, age range, and at least twenty ratings. We impute a personality value to each used based on the population norms in [Schaubhut, 2007].

We created 100 groups, randomly choosing group members from all users in the MovieLens dataset subject to the following restrictions: in a group, users are distinct (but a user may be in more than one group); all users are in the same age range; and we ensure that there are at least 15 movies which are co-rated by all members of the group. When we create cases, these 15 movies will be the set Tc. Their ratings are withheld from the recommender, because it would not in general know a user's actual ratings for the candidate movies.

We conducted a Facebook poll in which we asked respondents to tell us, for the last five times that they went to the cinema in a group, how large the group was. We used the frequencies to create our groups.

As we have discussed, in our Facebook application, trust is computed from Facebook data (distance in the social network, etc.), but that information is not available to us for the users in the MovieLens dataset. Rather than simply imputing trust values at random, we chose to base them on the degree of shared taste as revealed by co-rated items.

To create a case, we need to indicate which of the 15 movies in Tc the group will actually have chosen. But we cannot ask random groups of MovieLens users to work out which of their 15 candidate movies they would have gone to see together. We used four human 'experts' who were given all the information about a group's members Gc and the candidate movies Tc (including the actual ratings by the members of Gc for the items in Tc) and were asked to decide which of the movies the group would be most likely to settle on. Each expert evaluated 50 cases, hence each of the 100 groups was evaluated by two experts (not always the same two). Experts were asked to give an ordered list of the three movies from Tc that they thought the members of Gc would agree on. We combined the experts' judgements into a single final ordered list, denoted by E (for "Expert"). Let Ei be the movie in positions i in E.

6 EvaluationMethodology

The dataset we created has 100 movie-going events. We use a leave-one-out cross-validation methodology, where we remove each case in turn from the case base and present it to the recommenders. We compare their recommendations with the experts' judgements. We report results from four recommenders: Soc, Soc-CB, Soc-UCB, and Soc-U. Each recommender recommends the top k = 3 movies from the 15 candidates. Let R be the set of recommendations made by a particular recommender. We compare R with E from above. We computed total success@n for n = 1, 2, 3, where success@n = 1 if ∃i, i ∈ R ∧ i ∈ En and is 0 otherwise. For example, when using success@2, we score 1 each time there is at least one recommended movie in the top two positions of E. We also computed total precision@n for n = 1, 2, 3, where precision@n ˆ= |{i : i ∈ R ∧ i ∈ En}|/n. For example, if no recommended movie is in the top two positions in E, then precision@2 = 0; if one recommended movie is in the top two positions in E, then precision@2 = 0.5.

We repeat the experiments with different cold-start thresholds (θ). For θ = 20, just over ten users are in cold-start; with θ = 40, an additional twenty users are in cold-start; and then as θ goes up by 20, the number of users in cold-start grows by about an additional ten each time. (The threshold excludes the 15 ratings for Ta withheld from the recommender.)

7 Results

Figure 1 shows success@n for n = 1, 2, 3 and precision@n for n = 2, 3 (precision@1 = success@1 and is therefore not shown) for cold-start threshold θ = 20.

Results show that as n gets bigger, results improve but differences between systems become less pronounced: with bigger n it is simply easier to make a recommendation that matches an expert judgement. Most importantly, we see that Soc-CB system out-performs the Soc-UCB system, which out-performs the Soc-U system, which out-performs the Soc system. So, a cold-start strategy that is conditioned on groups copies ratings in a more informed and successful way than strategies that copy without regard to groups, and copying ratings is more successful than having no cold-start solution.

Figure 2: Results for precision@2.

We tried out a similar cold-start solution in the context of a single-person recommender, where a single active user seeks movie recommendations. For an active user in cold-start, we copied ratings from a similar user in U. Interestingly, doing so made no or almost no change to the success@n and precision@n results (not shown) across several definitions of similarity. We conclude that, for our movie data, the coldstart solution is most effective on conditioning on groups.

We also studied the impact of varying θ in [20,200], Figure 2. In other words, more and more users are regarded as being in cold-start. The results for Soc itself remain the same for all values of θ because this system has no cold-start strategy. For the other systems, we see that results improve and then fall off as θ increases. For example, for Soc-CB, results improve until θ = 100. For this system, 100 is the cut-off point: users with fewer than 100 ratings are the ones we should regard as being in cold-start. A higher threshold treats so many users as being in cold-start that the tastes of the active group are swamped by the ratings copied from other users, causing system performance to decrease. The graph is for precision@2 but we observed the same pattern of results for all other measures.

8 Conclusions

We introduced a new solution to the cold-start problem in a collaborative group recommender. We use a case base of group recommendation events and copy ratings into the profile of users in cold-start from their most similar user in the most similar group in the case base. Experiments on movie data show that, for users with fewer than 100 ratings, our strategy improves the quality of the group recommendations.

Much can be done to take this work forward. Our next step is to consider a case base in which we more explicitly arrange that there be cases (e.g., movie-going events) involving groups whose members have a high degree of overlap with the members of the active group. We can then experiment with situations where the same group (or nearly the same group) consumes items together on a frequent basis. We also plan to enrich case representations by including timestamps, predicted and actual ratings from group members, and the dynamics of reaching a consensus (e.g., changes in group membership and changes in the selected item). We will gather more data from our Facebook application and use it to overcome the limitations of our current dataset.