
Ask HN: What are some good architectures for building recommendation systems? - n_siddharth
I have been working on AI&#x2F;recommendations(for music) for a while now and run a few experiments with some ALS models which have shown promising results during A&#x2F;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&#x2F;elasticsearch solutions.<p>Here are a few links I found online while researching this.<p>https:&#x2F;&#x2F;www.elastic.co&#x2F;blog&#x2F;looking-at-content-recommendation-through-a-search-lens<p>https:&#x2F;&#x2F;mapr.com&#x2F;blog&#x2F;inside-look-at-components-of-recommendation-engine&#x2F;#.VSv8o_nF81J
======
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](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.

------
drewjaja
Take a look at the Annoy library
[https://github.com/spotify/annoy](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

~~~
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.

------
smorgrav
Take a look at Vespa. The recommendation use case is featured in one of the
tutorials: [http://docs.vespa.ai/documentation/tutorials/blog-
recommenda...](http://docs.vespa.ai/documentation/tutorials/blog-
recommendation.html)

~~~
n_siddharth
This looks interesting. Will explore more.

