HN Explorer

Ask HN: What are some good architectures for building recommendation systems?

55 points by n_siddharth ↗ HN
I have been working on AI/recommendations(for music) for a while now and run a few experiments with some ALS models which have shown promising results during A/B tests. Would like to build a proper recommendation system with online and offline models. I have searched around and elastic search and Solr come up as good ways of building one (reduce the recommendation problem to an implicit search problem) but after talking to a few folks at work it seems like it may not be the most scalable or simplest solution for us. What are some other architectures to consider? Are there any good resources for this? After a lot of searching, I have not been able to find much other than the aforementioned Solr/elasticsearch solutions.

Here are a few links I found online while researching this.

https://www.elastic.co/blog/looking-at-content-recommendation-through-a-search-lens

https://mapr.com/blog/inside-look-at-components-of-recommendation-engine/#.VSv8o_nF81J

11 comments

[ 4.2 ms ] story [ 36.1 ms ] thread
drewjaja
Take a look at the Annoy library https://github.com/spotify/annoy, implemented by a developer from Spotify. It uses K-nearest neighbour to find close data points.
n_siddharth
Not quite what I am asking. I am looking for system architecture not specific algorithms.Btw, We do use annoy and various other algorithms for our recommendations.
eshvk
Not really sure what your central question then is: The general theme for building a recommender system architecture is:

1. Decide whether you are okay with a batch approach or an online learning approach or a hybrid.

2. Start simple with a batch approach (similar to what you are doing):

a) Get features ready from your dataset (assuming you have interaction data) : Pre-processing via some big data framework (Map Reduce, Data flow etc)

b) Build a vector space and nearest neighbors datastructures.

c) Stick both into a database optimized for reads

d) Stick a service in front of it and serve.

Once you are happy with 2, you can try out variations involving either online updates to your recommender system which involves changes to the type of database you might want to optimize. etc

chudi
this is a really good answer, at my job we use this approach
n_siddharth
I guess I should elaborate a little more on what I am looking for. I already have a hybrid approach working where batch processing informs and improves the ALS models and these models are stored in memory to do some (Near)real time recommendations. The attractive bit about using something like Solr is that the user behavior on the app/front-end is easily modeled in terms or query parameters that could help serve better recommendations and also improve the model. It also seems to be the most commonly used approach based on what I have seen. I am wondering if there are other ways of doing this. In the broader sense, I guess my question is what are the next steps to build on this basic recommendation system? What is a good way to serve recommendations based on user behavior in near-real time and how do these systems take feedback to improve the models.
eshvk
> In the broader sense, I guess my question is what are the next steps to build on this basic recommendation system? What is a good way to serve recommendations based on user behavior in near-real time and how do these systems take feedback to improve the models.

In the past, I have helped build Lambda architectures where we use a batch model to build a content vector space, build estimates of users in batch, update those in realtime (using PubSub/Kafka) based on user feedback.

Other online mechanisms could be to use Contextual Bandits: e.g. use context in terms of user interactions with the several arms of the bandits being recommendation choices etc. This interaction data can be used to continuously improve your policy. Of course, the key benefit over a Matrix Factorization setup where the interaction matrix is continuously rebuilt over time based on new data, is the in built exploration which minimizes regret.

wballard
Besides reduction to search — solr / elastic / Lucerne / xapian, which is the most common approach I have used commercially, my actual favorite is precomputation.

At the moment, keras embedding model, multiprocessing, annoy, and emitting csv (object id, other object id, score) as a batch process and loading it in my database. Queryti recommend. This trades a prebuilt for near instant runtime and — near Nothing net new to break.

I’m working at commercial — 2-5 million item — scale, not ‘internet scale’ billions of items.

Hope that helps.

seektable
No need to reinvent the wheel: take a look to the Apache Mahout collaborative filtering engine - it can be used for both 'small' and 'big' data. If you have one-machine dataset (millions of items) I may recommend to use non-Hadoop algorithms implementation that can be used as usual java lib (in case of .NET C# port is available: https://github.com/nreco/recommender ).

Also you can check 'Mahout in Action' book - part 1 is about recommendations and it explains everything that you need to know for building your own recommendation engine.

bjourne
If you want something that scales, I believe you have to build it yourself. A recommendation system personalized for each user and adapting to feedback in real-time is very resource intensive. The problem is that for the recommendation system to be fast and adaptive, it needs tight integration with your database(s) which is hard for prebuilt solutions to afford.

Fortunately, building a recommendation system is not that hard. Google and read up on postgresql's ts_vectors and refresh your linear algebra. You probably will have to make some trade-offs; the more personalized the recommendations, the less likely it is to scale well.

Note: It was over seven years since I worked with a recommendation system. The prebuilt solutions might have improved since then.