Recommender systems are used in many products to present users with relevant or personalized items (food, movies, music, books, news, etc). To do this, they learn from users’ previous interactions with items to identify users’ tastes and improve future recommendations.

This post will walk us through the prototyping of a new recommender system in Python using TensorRec including input data manipulation, algorithm design, and usage for prediction.

You can find the Python code from this post’s example here.

System Overview

TensorRec is a Python package for building recommender systems. A TensorRec recommender system consumes three pieces of input data: user features, item features, and interactions. Based on the user/item features, the system will predict which items to recommend. The interactions are used when fitting the model: predictions are compared to the interactions and a loss/penalty is calculated, which the system learns to decrease.

As we prototype our system, we’ll be tackling three major topics: how we handle interactions, how we handle features, and how we structure the recommender itself.

Interaction Data

For this example we’ll use the MovieLens dataset. This dataset contains 1–5 star ratings for movies, metadata about those movies, and tags that users applied to the movies. For our first prototype we’ll focus on the ratings, but we’ll return to the other metadata later.

In raw form, the ratings look like this:

userId, movieId, rating, timestamp
1,      1,       4.0,    964982703
1,      3,       4.0,    964981247
1,      6,       4.0,    964982224
1,      47,      5.0,    964983815
1,      50,      5.0,    964982931
1,      70,      3.0,    964982400
...

Each row represents a single rating: one user’s thoughts about one movie. We’ll be using these ratings as our interactions. Our first step toward training this system is to ingest and format this interaction data. First, we read in the CSV file of ratings.

At this point, we’ll break the ratings in to a training and test set by shuffling and splitting the ratings. Our prototypes will be trained on the training set, and we’ll evaluate their success using the test set. Splitting the train/test sets at random like this is crude, and there are more rigorous techniques for model evaluation, but it is quick and clear for the purposes of this example.

Next, we reorganize these ratings in to a Scipy sparse matrix. In this matrix, every row represents a user and every column is a movie. The [i, j]th value in this matrix is User i’s interaction with Movie j.

Collaborative Filter Prototype

A collaborative filter is an algorithm that learns which users have similar tastes and recommends items to a user based on what similar users have liked. A common way to do this is through matrix factorization. In matrix factorization, we have to learn two matrices (user representations and item representations) that, when multiplied together, approximate the interactions:

In this case, rows of W are the user representations, columns of H are the item representations, and values in V are the interactions. W and H need to be learned to produce the best approximation of V.

The width of W and the height of H are the same — this shared dimension is referred to as the “number of components.” A model with more components is learning more complex representations of users and items, but this can lead to over-fitting the training data. In general, we want to try to squeeze lots of information in to small representations. For this reason, in our prototype I’ve arbitrarily chosen to use 5 components. When prototyping further, we should experiment with increasing and decreasing the number of components and be wary of over-fitting.

TensorRec will perform matrix factorization by default if it is given only identity matrices as user/item features. These identity matrices are often called “indicator features.”

We have now created the two indicator feature matrices, built a simple collaborative filter model with 5 components, and fit the model!

Next, of course, we’ll want to see how well the model performs.

To do this, we’ll look at a metric called “recall at K.” Recall@K says, for the average user, what percentage of their test items made it in to the top K in the predicted rankings. In other words, if we get a recall@10 value of .06, then there is a 6% chance that a particular movie I like will make it in to my top 10 recommendations.

Recall@K is a nice metric for many recommender systems because it emulates the behavior of a recommendation product: If a movie website is only going to show me my top 10 recommendations, then their algorithm will want to be effective at putting movies I like in my top 10.

Before calculating the recall, we’ll want to decide which interactions should count as a “like.” In this case, I’ve chosen to use all ratings of at least 4.0 as “likes” and ignore the rest.

Great! Let’s check the results:

Matrix factorization collaborative filter:
Recall at 10: Train: 0.0008 Test: 0.0010

…Not great. These results tell us that, among the test-set movies, there is only a .1% chance that a liked movie made it in to the top 10. This recommender system is ineffective, and we’ll want to look for ways to improve it.

Loss Graphs

One way we can configure our TensorRec system is by changing the loss graph. The loss graph takes in predictions and interactions and calculates a penalty (loss) that the system will try to decrease as it learns.

By default, TensorRec uses RMSE (root mean square error) as the loss graph. This means that TensorRec is trying to estimate the values of the interactions exactly: if I rated a movie 4.5, TensorRec is trying to produce a predicted score of exactly 4.5.

This is intuitive, but it doesn’t line up with how recommender systems work in many products: a movie website doesn’t need to predict my rating exactly, it just needs to be able to rank movies I will like above movies I won’t like. For this reason, many systems function by “learning to rank.” We can make our TensorRec system work this way by using a loss graph called WMRB.

WMRB, which stands for “weighted margin-rank batch,” works by taking a random sample of items the user hasn’t interacted with and comparing their predictions to items the user likes. Over time, this pushes items a user likes to the top of the rankings.

We can tell TensorRec to use WMRB by specifying it when we construct the model and specifying the size of the sample batch when fitting the model. In this case, we’ll want to train the model on only the positive ratings (≥4.0) so WMRB pushes those to the top.

Let’s look at the results:

WMRB matrix factorization collaborative filter:
Recall at 10: Train: 0.1098 Test: 0.0776

Much better! We’ve gone from a .1% chance of a liked item reaching the top 10 all the way to a 7.76% chance. This is an example of how impactful the right loss function can be. TensorRec allows you to specify and customize your own loss graphs, and you can see more example loss graphs here.

Adding Metadata Features

To continue experimenting, we should try to make use of other data available to us. In the MovieLens example, we can use movie metadata, such as the movie’s genres, to enrich the recommendations.

In raw form, the movie metadata file looks like this:

movieId, title,                    genres
1,       Toy Story (1995),         Adventure|Animation|Children|C...
2,       Jumanji (1995),           Adventure|Children|Fantasy
3,       Grumpier Old Men (1995),  Comedy|Romance
4,       Waiting to Exhale (1995), Comedy|Drama|Romance
...

First, we’ll want to read this data, map the movies to our internal IDs, and keep track of the genres for each movie. Then we’ll binarize the genre labels using Scikit’s MultiLabelBinarizer. The binarized output will be our features for our new recommender system.

Running this will print out an example of the raw metadata and the binarized genres:

Raw metadata example:
['movieId', 'title', 'genres']
[0, 'Toy Story (1995)', ['Adventure', 'Animation', 'Children', 'Comedy', 'Fantasy']]

Binarized genres example for movie Toy Story (1995):
[0 0 1 1 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0]

Content-based Recommendation

Now that we have metadata about our items, one thing we can try is to recommend based solely on the item metadata.

To do this, we will configure a TensorRec model to use a pass-through representation graph for item features. For us, this means that the item representations will be the same as the item features that are passed in (just the movie genres) and the user representations will reflect how much the user likes that particular genre.

Great! Let’s check the results:

Content-based recommender:
Recall at 10: Train: 0.0471 Test: 0.0130

It’s not as good as the ranking collaborative filter but, with a recall@10 of 1.3%, it’s significantly more effective than our very first collaborative filter.

There is a major weakness to this system: genres alone are not very descriptive and are not enough information to make an informed recommendation. If we had more descriptive metadata (more tags, actors, sub-genres, etc) we may have more success with this content-based recommender system.

On the other hand, there is a major strength to this system: by relying on only metadata features, and not using indicator features, we can recommend movies which were not present when training the model. Similarly, if we have valuable user metadata we can avoid using user indicator features and make predictions for users who’ve never interacted with a movie before. This is called “cold-start” recommendation.

Hybrid Model

We know that our ranking collaborative filter gave us the best results, but it seems there is some value in using the movie metadata. Let’s combine these two: we’ll use indicator features to get the strengths of a collaborative filter, and we’ll also use the content features to take advantage of the metadata. Systems like this that combine collaborative filtering and content-based recommendation are called “hybrid” models.

We do this by stacking the two sets of features together:

Great! Let’s check the results:

Hybrid recommender:
Recall at 10: Train: 0.1196 Test: 0.0794

With a recall@10 of 7.94%, this is our strongest recommender system yet. Compared to the pure collaborative filter’s result of 7.76% the difference isn’t profound, but it is still an improvement. If we use more metadata than just genres, we’ll likely see an even larger impact.

Making Recommendations

We have a trained model and now we can use this model to make recommendations for our users. We do this by passing the user’s feature vector and all the item features to predict_rank() and examining the resulting rankings:

This code snippet will print out the top 10 recommendations for user 432. I chose user 432 because I am familiar with the movies they’ve rated, so I feel I can put myself in their shoes and judge their recommendations. We should note that the movies user 432 has already rated will still be included — if we want to filter those out, we will need to do that with a post-processing step.

Let’s look at user 432’s training data to see what kinds of movies they like:

User 432 liked:
Usual Suspects, The (1995)
Pulp Fiction (1994)
Silence of the Lambs, The (1991)
Reservoir Dogs (1992)
Shawshank Redemption, The (1994)
Kill Bill: Vol. 1 (2003)
Social Network, The (2010)
Trainspotting (1996)
Arrival (2016)
My Big Fat Greek Wedding (2002)

Some crime, some dark comedy, and a notable love for Tarantino. Let’s look at user 432’s recommendations from our hybrid model:

User 432 recommendations:
Seven (a.k.a. Se7en) (1995)
Usual Suspects, The (1995)
Pulp Fiction (1994)
Silence of the Lambs, The (1991)
Fargo (1996)
American Beauty (1999)
Fight Club (1999)
Shawshank Redemption, The (1994)
Departed, The (2006)
Memento (2000)

Some more crime flicks with a definite dark comedy bent! This looks pretty good at-a-glance, but let’s check user 432’s test movies:

User 432's held-out movies:
Fargo (1996)
American History X (1998)
Fight Club (1999)
Dark Knight Rises, The (2012)

Both Fargo and Fight Club made it in to user 432’s recommendations — this is a great result! For this specific user, we achieved a recall@10 of 50%.

Going Forward

To continue to refine our recommender system we should experiment with more representation, prediction, and loss graphs, providing more metadata to the system, engineering those metadata features differently, managing interaction/feedback data differently, and optimizing the various hyper-parameters of the system.

I recently had the chance to visit MITRE to discuss many of the design choices when designing and deploying recommender systems. You can find a video of the talk here.

If you have questions, please feel free to ask them here or open a GitHub issue.

Getting Started with Recommender Systems and TensorRec was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the release of TensorRec v0.21, I’ve added the ability to easily use deep neural networks in your recommender system.

For some recommender problems, such as cold-start recommendation problems, deep learning can be an elegant solution for learning from user and item metadata. Using TensorRec with Keras, you can now experiment with deep representation models in your recommender systems quickly and easily.

Implementation

In a TensorRec model, the components that learn how to process user and item features are called the “representation graphs” (or “repr” for short). These graphs convert high-dimensional user/item features, such as metadata and indicator variables, into low-dimensional user/item representations.

Define your model’s representation graphs as a sequence of Keras layers by extending the class AbstractKerasRepresentationGraph. Next, overwrite the create_layers abstract method to return an ordered list of Keras layers.

Example

You can find the example above used in a full recommender system for the Book Crossing dataset in this module.

With this dataset, the recommender system is learning to recommend books to users based on user metadata (location, age) and book metadata (author, title, year publisher, etc). This example compares four different configurations of a recommender system using combinations of linear kernel representations and deep network representations.

The architecture of this network has not been optimized for the Book Crossing problem, and should be regarded only as an example of the new Keras functionality.

A Word of Caution

When you’re holding a hammer (or deep learning), everything looks like a nail (or a deep learning problem).

Many real-world recommendation problems are best solved through thoughtful analysis, feature engineering, simple models, and effective feedback systems. Deep models are highly flexible, but this makes them particularly susceptible to overfitting through overparameterization. In these cases, performance with previously-unknown users and items can be significantly harmed.

An example of this issue is the third configuration in the Book Crossing example above. This system is the most effective of the four configurations at making recommendations for existing users based only on their age and location but, based on the same user metadata, is the worst performer on new users — a classic example of overfitting. This problem could be avoided with richer metadata, better feature engineering, or simpler models.

The Book Crossing example also illustrates that the best product outcomes may be from having multiple recommender systems. A product that is driven by two recommender systems, one designed and optimized for warm-start users and another for new cold-start users, may be the optimal system design for your product.

If you’d like to contribute to (or even just try out) TensorRec I’d love to hear your feedback either on GitHub or in the comment section of this post.

Special thanks to Joe Cauteruccio (Spotify), Mike Sanders (Spotify), and Logan Moore (Northeastern University) for their contributions to TensorRec.

Note: This is a personal project and, at time of writing, is not associated with Spotify.

Deep Learning for Recommendation with Keras and TensorRec was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

That is why I built TensorRec, a framework intended to streamline the logistics of a TensorFlow-based recommendation engine and free you up to focus on the interesting stuff: developing your ideas for representation (also called embedding) functions, loss functions, and more robust learning.

Edit 1/22/19: There is now a Getting Started guide for TensorRec

TensorRec is a recommendation algorithm with an easy API for training and prediction that resembles common machine learning tools in Python. It also gives you the flexibility to experiment with your own representation and loss functions, letting you build a recommendation system that is tailored to understanding your particular users and items.

The TensorRec project is still young, but I invite any usage, participation, or criticism that you have to offer.

In building TensorRec, I had four goals:

1. Build a recommendation engine capable of learning from explicit positive and negative feedback.
2. Allow for arbitrary TensorFlow graphs to be used as representation functions and loss functions.
3. Provide reasonable defaults for representation functions and loss functions.
4. Pack as many Machine Learning buzzwords into a Medium post as possible.

While the first three goals remain a work in progress — your mileage may vary — I’m very satisfied with number four.

How It Works

TensorRec scores recommendations by consuming user and item features (ids, tags, or other metadata) and building two low-dimensional vectors, a “user representation” and an “item representation”. The dot product of these two vectors is the score for the relationship between that user and that item — the highest scores are predicted to be the best recommendations.

# Predict scores for all users and all items
predictions = model.predict(user_features=user_features,
                            item_features=item_features)

The algorithm used to generate these representations, called the representation function, can be customized: anything from a straight-forward linear transform to a deep neural network can be applied, depending on the particulars of the problem you need TensorRec to solve and the feature data you have available. Also, the user and item representation functions can be customized independently. You can find an example of representation function customization here.

TensorRec learns by comparing the scores it generates to actual interactions (likes/dislikes) between users and items. The comparator is called the “loss function,” and TensorRec allows you to customize your own loss functions as well. You can find an example of a custom loss function here.

The functions for fitting a TensorRec model are similar to fitting functions for other common machine learning tools:

# Fit the model for 5 epochs
model.fit(interactions, user_features, item_features,
          epochs=5, verbose=True)

Inspiration

I have used LightFM, developed by Maciej Kula and Lyst, extensively and I am impressed with its performance and usability. I wrote a blog post about using LightFM here.

LightFM generates user and item representations by functioning as a factorization machine and learning linear embeddings for each feature. By taking the dot product of these two representation vectors, you get a unitless score that, when ranked, tells you how good (or bad) a given user-item match would be.

This linear factorization method is effective and computationally efficient, but I have run into issues using LightFM with imbalanced, redundant, inconsistent, or highly-correlated features — learning to meaningfully embed these features would require a more complex representation function, such as a deep neural network. This representation function would be able to learn nuanced relationships in the user and item features and increase the overall information capacity of the system. This made me curious to explore options for representation functions that were non-linear, and I developed TensorRec as a framework to do just that.

TensorFlow for Recommendations

TensorFlow, originally developed by Google, is an open source tool that allows you to build, optimize, and distribute large, arbitrary machine learning systems.

In TensorFlow, a machine learning process is expressed as a ‘graph’ showing how data flows through the system. These graphs can be visualized using TensorBoard, giving a clearer explanation of the machine learning process at-hand.

To build our recommendation system, we need TensorFlow graphs that accomplish four tasks:

1. Transform input data into feature tensors for easy embedding.
2. Transform user/item feature tensors into user/item representations (the representation function).
3. Transform a pair of representations into a prediction.
4. Transform predictions and truth values into a loss value (the loss function).

TensorRec solves 1 and 3 while providing modularity and reasonable defaults for 2 and 4, giving you the freedom to experiment with representation and loss functions. All you need to do is plug in a function that builds your custom representation function graph or loss function graph, like this example.

What’s Missing

Many recent advances in information retrieval have come from sophisticated loss functions. Particularly interesting to me are pairwise loss functions, such as WARP, but these are challenging to represent as TensorFlow graphs. TensorRec’s value to users would increase with implementation of these loss functions.

Valuable additions to TensorRec would be new features for dealing with large interaction data, managing model state, and handling implicit interactions.

If you’d like to contribute to, or even just try out, TensorRec I’d love to hear your feedback either on GitHub or in the comment section of this post.

Note: This is a personal project and, at time of writing, is not associated with Spotify

TensorRec: A Recommendation Engine Framework in TensorFlow was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

When an expert signs up for Catalant, they can provide a description of themselves in their ‘About Me’ section and tag themselves with skills and industries that represent their expertise. Similarly, when a business posts a project to our site, they write a project description and can tag their project with the skills they need. Experts are able to search for projects on their own, but we want to make it easy by recommending the most relevant projects for them.

One way we could generate these recommendations is by tracking which projects experts like and dislike (‘bookmark’ or ‘hide’ on Catalant), comparing these interactions to other experts’ likes and dislikes, and recommending projects that similar experts have liked. This is called ‘collaborative filtering,’ and it covers many algorithms with their own strengths and weaknesses. Collaborative filters are widely used on shopping websites like Amazon, news services, and video content providers like YouTube.

There is an important difference between how websites like Amazon incorporate collaborative filters and how Catalant must recommend projects: Catalant project life-times are very short. Products stay on Amazon’s catalog for months and in that time they will be purchased and rated by potentially thousands of users. This allows them to develop a very rich understanding of what kinds of items are purchased by the same customers and make recommendations based off these user-clusters. A Catalant project will only be accepting bids for a few days, may be interacted with by less than thirty experts, and needs to be recommended to the right experts the moment it is posted. This short lifetime and small number of interactions would hobble many collaborative filtering strategies.

An alternative to collaborative filtering is content-based filtering. A content-based recommender is one that matches a user with items that have metadata (tags, genres, etc.) similar to items that user has already liked. On Netflix, that means breaking down movies by their genre, actors, subject matter or other criteria.

For Catalant, a content-based approach means recommending projects to a user that have similar industry and skill tags to projects the user has already bookmarked. There are two major drawbacks to content-based recommendation systems: they require a lot of manual processing to ensure that the project metadata is thorough and rich, and they miss out on the potential to learn from comparing different users’ behavior (called ‘transfer learning’).

The appropriate solution for Catalant recommendations is somewhere in-between collaborative filters and content-based recommenders. That is where LightFM comes in.

LightFM is a hybrid model that incorporates both content-based recommendations and the transfer learning of collaborative filtering methods; it gives us the best of both worlds. Developed by Lyst, a Fashion e-Commerce site based in London, LightFM figures out what users like by learning relationships that map users and user metadata to the projects and project metadata that they like. These relationships are called ‘embeddings.’ In order to build these embeddings, LightFM utilizes three sets of information: the expert metadata, the project metadata, and the interactions between them.

For expert metadata, we build a matrix containing all of the expert’s industry and skill tags, as well as selected words from their profile tagline and ‘About Me’ section. That matrix looks something like this:

Similarly, for project metadata, we build a matrix containing the project’s industry tags, skill tags, selected words from the project name and description, and budget range:

The interactions are also put in to a matrix where every positive value represents a like and every negative is a dislike:

LightFM then takes these three matrices and solves for the embeddings that will allow it to most accurately predict the values in the interactions matrix. You can read more about how LightFM learns (called ‘stochastic gradient descent’) in this paper by Maciej Kula from Lyst.

To create recommendations for an expert, we give LightFM that expert’s metadata and the metadata of all out-for-bid projects. LightFM then uses the embeddings that it has learned to score each project on how much the expert will like it. The top-scoring projects are the user’s recommendations.

This system is something between a collaborative filter and a content-based system. It learns how groups of experts interact with various projects, like a collaborative filter, but it is also learning relationships between expert and project metadata, like a content-based system. By working in both worlds, LightFM gives us the strengths of both, and helps us match our diverse projects to our equally diverse experts.

In future posts, we will dive further in to how we measure success, how we break down expert/project metadata, how we optimize these models, and plans for maximizing sick wheelie hang-time.

If these problems are interesting to you, we have plenty more to solve at Catalant Technologies. We are looking for Data Science Engineers and Software Engineers. Learn more here.

Using LightFM to Recommend Projects to Consultants was originally published in Catalant Technologies on Medium, where people are continuing the conversation by highlighting and responding to this story.