# 4. Collaborative-Filtering Recommender Systems

In my previous article of this recommender systems series, we took a look at the *content-based* approach to building recommender systems. In this article, we will take a look at another popular approach used in modern recommender systems, called *collaborative-filtering *(CF). There are two types of methods that are commonly used in CF: memory based and model based. In this article we'll take a look at how memory-based CF works.

The main idea around *collaborative-filtering* is quite simple. Suppose we have a user **x** to whom we want to make recommendations. First, we look for a group of other users whose likes and dislikes are similar to those of user **x**. For example, in the case of movies, we want to find a group of users that liked the same movies as user **x** and disliked the same movies as user **x**. We call this set of users **N**, the *neighborhood* of user **x**. Once we have defined this set of users **N**, we then look for movies that are liked by a lot of the users in the set **N** and recommend those to the user **x**.

The key here is to find the set of users that are similar to user **x** (the neighborhood **N** of user **x**) and to do that we need to define a notion of similarity between users. The figure below shows an example of a rating matrix with 4 users (* A*,

*,*

**B****, and**

*C***) and 7 items (**

*D***)**

*i*_{1}, i_{2}, i_{3}, i_{4}, i_{5}, i_{6}, i_{7}User ** A** has rated three items (

**), user**

*i*_{1}, i_{4}, i_{5}

*B**has also rated three items (*

**), like user**

*i*_{1}, i_{2}, i_{3}**(**

*C***), while user**

*i*_{4}, i_{5}, i_{6}**has rated only two items (**

*D***). Let's refer to each row in the rating matrix as the user's**

*i*_{2},i_{7}*rating vector*. Now, given two users

**x**and

**y**with rating vectors

*r*_{x}**, we need a similarity metric that looks at the rating vectors and computes similarity. What's interesting here, is that there are a lot of items the users did not rate, so the key in defining the similarity function is how we deal with these unknown values (unknown ratings). We'd like to define the rating vector in a way that captures the intuition that users with similar tastes should have higher similarity as opposed to users with dissimilar tastes. In the case of the example above, we can notice that**

*r*_{y}**and**

*A***rated only one item in common (**

*B***), however, they both rated that item highly. Whereas users**

*i*_{1}**and**

*A***have rated two items in common (**

*C***) but in a very dissimilar way (items**

*i*_{4}, i_{5}**liked,**

*A***didn't like and vice versa). It seems, intuitively, that users**

*C***and**

*A***are dissimilar while users**

*C***and**

*A***are similar. So we would like to be able to capture this intuition when defining the notion of similarity, therefore we would like the similarity between**

*B***and**

*A***to be higher than the similarity between**

*B***and**

*A***. Let's see how to do this.**

*C*

Once again the *cosine similarity* metric is what we want to use (refer to my previous article if you are not familiar with this metric). So the similarity between ** A** and

**will be calculated as the cosine similarity between the two vectors**

*B***and**

*r*_{a}**(rows in the rating matrix). If we compute the cosine similar this is what we obtain:**

*r*_{b}sim(A,B) = 0.38, sim(A,C) = 0.32

Notice that, to compute the cosine similarity, we have to assign a value to the unknown values in the rating matrix, and the simplest thing to do is to assign the value zero (**0**) to the unknown values as shown in the figure below.

As we can see looking at the computed similarity values, we obtain:

sim(A,B) > sim(A,C)

but not by much. These values don't seem to capture that ** A** and

**are much more similar to each other than**

*B**and*

**A****are. The problem with cosine similarity here is that we are treating unknown values as negative values (negative ratings). We are assuming that, if a user hasn't rated an item then his rating for that item is zero, the worst value possible (since we are in 5 stat rating example). This is actually a bad assumption. To fix this we use a variation of cosine similarity called the**

*C**centered cosine similarity*. Before performing the cosine similarity we "

*center*" the rating values around the zero value. To do so we normalize the ratings of a given user by subtracting the user's average rating from each rating value.

The next figure shows the average user rating, computed before performing normalization.

We then normalize the rating values subtracting the user's average rating from each known rating value in its rating vector (the user's row in the rating matrix) as shown in the next figure.

And the figure below shows the rating matrix after performing the normalization step.

It's interesting to notice that if you add the values in each row you obtain zero. What we have actually done here is we centered the ratings of each user around zero, by doing so, zero becomes the average rating value for every users. Now positive ratings indicate that a user likes an item more than average, and negative ratings indicate that the user likes the item less than average. Once we have done this "centering" operation, we can compute the cosine similarity using these "new" values. This is what we end up with:

sim(A,B) = 0.09, sim(A,C) = -0.56

Again we obtain sim(A,B) > sim(A,C)*,* but now the difference between the two similarities is bigger, and this captures the fact that user ** A** and user

**are quite dissimilar users. The items that**

*C***likes**

*A***doesn't like and the items**

*C***likes**

*C***doesn't like. The bigger gap between sim(A,B) and sim(A,C)**

*A**,*indicates that

**and**

*A***are much more alike than**

*B***and**

*A***are. The**

*C**centered cosine similarity*captures our intuition of similar users much better than the simple cosine similarity, and this is because the missing ratings are no longer treated as negative ratings, but as average ratings instead. It also turns out to be a good way to handle "tough raters" and "easy raters". In the world of Statistics the centered cosine similarity is also referred to as the

*Pearson correlation*.

So far we have come up with a way to estimante similarity between users, but how do we actually make predictions for a user?

Let * r_{x}* be the vector of user

**x**'s ratings (a row in the rating matrix). We'll use the notion of

*centered cosine similarity*to find the set

**N**of

**k**users most similar to

**x**that have also rated an item

*. Once we have determined the set*

**i****N**of users that are similar to

**x**, we can make predictions for the user

**x**and item

*.*

**i**

One first simple option to make a prediction is to take the average rating for item * i* from the neighborhood:

This option is very simple but it actually ignores the similarity values between users. The neighborhood **N** contains users that are similar to the target user **x**, but the similarity values may be very different. There may be users very similar to user **x** and user that are not that similar to user **x**. So what we really want to do is to weigh the average rating with the similarity values, which leads us to the following rating formula:

The technique we have described so far is called *user-based collaborative filtering**, *because, given an active user it tries to find other users that are similar to that active user, and then leverages the ratings of these similar users to make predictions for the active user.

A *dual* approach to *user-based* *collaborative filtering* is** item-based collaborative filtering**. Instead of starting off with a user, we start off with an item, and we try to find similar items. Then we compute ratings prediction for the target item, based on the ratings of similar items. We can use the same similarity metrics and prediction functions as per the user-based approach. Let's walk through an example to see what this means.

Given the rating matrix shown in the figure above, let's see how item-based collaborative filtering works, using a neighborhood **N** that contains only **2** items (given an item ** i**, we will be looking at the two nearest neighbors of item

**). Our goal is to estimate (predict) the rating of user**

*i***for item**

*u*_{5}**. The figure below shows our goal.**

*i*_{1}

The first step is to take item ** i_{1}** and find other items that are similar to

**. To do so we calculate the**

*i*_{1}*centered cosine similarity*(or

*Pearson correlation)*between item

**and all the other items, and then we concentrate on those other items that user**

*i*_{1}**has also rated.**

*u*_{5}

The figure above shows the values of the similarity between item ** i_{1}** and every other item. For purely didactic purposes we calculated also the similarity between item

**and itself and, as expected, we obtained 1.0 since the two vectors are identical. After computing the centered cosine similarity between the items, we concentrate on the items that**

*i*_{1}**has rated and we pick the**

*u*_{5}*top-2*items with the highest

*centered cosine similarity*(remember in this example we are considering a neighborhood of size

**2**).

As shown in the figure above the two items that are the most similar to item** i_{1}**, are item

**and item**

*i*_{6}**. Therefore,**

*i*_{3}**and**

*i*_{6}**are the neighbors of item**

*i*_{3}**and we can use the weighed average formula to predict the rating for item**

*i*,_{1}**by user**

*i*_{1}**. Let's recall the rating prediction formula we are going to use first (figure below).**

*u*_{5}

Now, let's compute the rating prediction for item ** i_{1}** by user

**.**

*u*_{5}r_{15}= (0.59*3 + 0.41*2) / (0.59+0.41) = 2.59 ~ 2.6

So the predicted rating for item ** i_{1}** by user

**u**is

_{5}**2.6,**as show in the figure below.

Should we recommend an item to a user for which we have predicted a rating value of **2.6** (in a 5-star rating context)? We may introduce a threshold and not recommend items that have a predicted rating value below this threshold, but there are other elements that play an important role in recommender systems, for instance *coverage*. Coverage is simply the percentage of possible recommendation a recommender systems is able to provide. If you enforce a high quality threshold on the recommendation you might improve your accuracy at expense of coverage. Finding the balance of where and when exactly you are better off recommending nothing at all can be delicate. Coverage can be also important to watch because it gives you the sense of how quickly new items in your catalog will start to appear in your recommendations. When a new book appears on Amazon, it won't be recommended until at least a few people buy it, therefore establishing patterns with the purchase of other items. But here we are entering the topic of tuning and evaluating recommender systems, that might be the subject of a next upcoming article.

Recommender systems are often consider to be closer to an art than to science.

*User-based* and i*tem-based* are the two ways you can perform *collaborative filtering*. In theory these are dual approaches and should have similar kind of performance, but in practice they don't perform similarly at all. It has been observed that i*tem-based* collaborative filtering outperforms *user-based* collaborative filtering in many use cases.

Items are "simpler" than users

This is because items are "simpler" than users. Items belong to a small set of genres, while users tend to have varied tastes. A user, for example, may like both pop music and classical music, while it's very unlikely that an item will belong to both those genres. So it turns out that the notion of item similarity is more meaningful than the notion of user similarity. That's why item-based collaborative filtering works better than user-based collaborative filtering in most cases.

Both of these techniques belong to a category called memory-based collaborative filtering methods (or *neighborhood-based methods*). Because of their simple and intuitive approach, they are easy to implement and it is often easy to justify why a specific item is recommended, and the interpretability of item-based methods is particularly significant. The main disadvantage of these methods is their limited coverage because of data sparsity. Data sparsity also creates challenges for robust similarity computation when the number of mutually rated items by two users is small. Also these methods suffer the cold-start problem both for new items and new users.

That's all for now. But there is still a lot to say about the fascinating world of recommender systems, so... stay tuned!

This article is written by Riccardo Saccomandi, Co-founder and CTO of Kickdynamic.