Intro to Recommender systems - Personalized & non-personalized

Hello everybody, happy to see you back. In this post I will focus on the most high level distinction of recommendations: Personalized and non-personalized

Non-personalized

Usually people think a recommendation has to always be tailored to each single individual but that is not entirely true. When we come back to the first post to the example about librarian recommending you a book to read, in one example they may say "this book has been super popular among readers within the last month". This is naturally a recommendation because the librarian is advising (recommending) you what to read.  But this recommendation is not specific for your person. Everybody walking into that library can hear the same sentence.

Non-personal recommendation, as the name says, are the same for everybody and usually they are put together as some form of aggregated statistics. This can be: most bough, most viewed, most shared, most talked about etc. As you can see there are particular areas where these make sense. If you go to a vacation you might want to welcome a recommendation that says "this is the top most bought location for people from your city". Or when you are looking at hotels you may welcome seeing the hotels with best ratings on the top. If you want to find more details on non-personalized here is a course course on it.

Personalized

On the other hand, as this name says, this group of recommendations is particularly tailored to each individual. So every person sees different recommendations. How this groups is technically composed is usually looking at each person's history of behavior. We do that in normal life as well. When you know that your friend has bough their last 10 shirts of a particular brand you can easily recommend them a new t-shirt from this same brand because you know the history what they bought.

Because we look at person's history there is one assumption that has to hold: People's past has to be able to predict their future. In other words if you like a t-shirt today there is a very high chance you will like it tomorrow. Of course, people's taste evolves over time but it is not jumping from positive to negative back and forth in a course of days. If this does not hold you cannot use people's history to give them recommendations. And that makes sense even in normal life, if I buy t-shirts at complete random (just because I find it enjoyable), you will not be able to recommend me with a repetitive success a t-shirt that I would end up liking and buying it.

How to do it?

When we know that the basic assumption that I said above holds, what approaches we can actually take? Let's take t-shirts as an example. The first approach is, we can be looking at features of the t-shirts that I bough in the past. The features would be, for example, color, size, brand, style, material, quality etc. So if you observe from my buying history that I like blue sport shirts that are cotton made with good quality you can then easily decide if to recommend to me (or not) any other t-shirt you come across. One important thing I have to mention is that we have to decide and pick which features are actually important for people when buying t-shirts and then we have to track these feature. If we happen to track wrong features, like we would only track what the t-shirt label color is, we would never be able to make a good recommendation.

The other approach that you can take is looking just purely at similar behavior of people. When we stay with the t-shirt example, if you know that me and my brother bought in the past the same t-shirts in 90% of the cases, then you can safely recommend to me a t-shirt that my brother just bought and I have not came across it. We need to realize that this approach is based purely on similar history of behavior of people. And because the assumption holds there is a very good likely hood that if we have bought same t-shirts quite often in the past we will continue doing so in near future.

In the field of recommender systems these two approaches are called:

1. Content based (the one looking at features of the t-shirt)
1. This method is based on anything related to the actual item. Be it metadata like genre, main actor, or the actual content like written text for books.
2. Collaborative filtering (the other one looking at behavior of people)

I will talk about each of them in more details in the coming posts.

 

Conclusion

Non personalized approach is based on aggregated statistics like most popular, most watched, most bought etc. In non-personalized category of recommendations everybody sees the same. Personalized approach is tailoring recommendations to each individual and it can be based on features of items or on the behavior of people in connection to the items.

Intro to recommender systems - When and why did we start talking about RS?

We covered the "definition" in the first post and we know now that this domain is very broad. In this post I want to elaborate on the question when we actually started being more interested in computer based RS and why.

From the previous post we know the the aspect of receiving a recommendation has been in people's lives all the time. The time we started talking much more about RS came when people started consuming much more content online, be it books, videos, items, anything. There are two reasons why RS became so popular in online consumption. One obvious one, although less important, is that in online world you are facing computers not people in most of the cases but you would still like that aspect of getting advice when you are looking for something. The other reason was much more along the side of the breadth of the offerings that the online stores have. I will illustrate it on an example.

Intro to Recommender systems - is there a definition?

Why this series?

2 years ago I discovered the domain of recommender systems. I found the beginnings quite challenging firstly because I am coming from Software engineering background and not from a data science background or pure math background and secondly because I was struggling to find any "overview" material. I ran into a lot of scientific papers that are, of course, awesome but they were usually focusing on one specific part. I was struggling to find some high level overview that would start from generics first and then go deeper. After two years in this field I have still tons to learn but I think I have gathered enough information to give you starting hints to you who might be at the same spot as I was 2 years ago.

This will be a series or posts where I will cover 360 degree overview of recommender systems to get you the starting information. I want to make this series a one stop shop  for starters full of information I found myself until now, heard at the conferences, learnt from papers/books etc.

Reusing ExecutorService inside itself - NOT GOOD

This week I ran into an interesting deadlock situation in my Java web app code. I have never faced it before and also never read any "Don't do it this way" warnings. So I thought I will share it as it was pretty interesting what happened.

Setup

I needed to parallelize the run of the web application in order to gain speed. Task was well parallelizable so I put in an implementation of an Executor service. Because the computer is expected to have 4 cores (for now) and the task is purely CPU intensive (no IO) I wanted to limit the workers in the thread pool so that I don't have unnecessary too many threads. So I picked 10 (out of the blue). The task can be parallelized at different levels and because I did not want to have one executorService per level I created a general one so that when any part of the codebase on the particular critical path need to paralyze it can take it and use it. I thought it was clever and first everything ran ok. Before I proceed lets look at how the situation looked:

The path of execution is starting at the top where it splits into two tasks that can run in parallel, this happens per the request arriving to the server. On the second level each task splits their work again into two so that in the end I utilize fully all 4 cores. Then all the tasks on 3rd level has to finish so that the tasks on the 2nd level are finished and the client's request is completed. On both the 2nd and 3rd level I used the same ExecutorService instance that had 10 threads limit.

The problem:

I tried to test it and everything looked nice and the speed per one request was improved. So I proceeded to putting a higher load (in terms of requests per second) on the web app. And again it was looking good and smooth so I thought GOOD WORK! Until I increased the load even more and the whole system completely deadlocked.

What went wrong:

First I was troubleshooting Semaphores and some locking I had inside but every time I put extreme load on the server it deadlocked. Finally I found why. When you put on the set up so many requests per second what happens is that many tasks are being forked on the 1st level before anything started being forked on the 2nd level. This leads to the ExecutorService workers being fully depleted at the 1st level and there are no more available workers. For a worked to finish it would mean that any task from the 2nd level has to finish which means that all of its sub tasks from 3rd level have to finish, but they cannot because there are no more available workers in the executor service to start execution on 3rd level.

How I fixed it:

For the sake of simplicity and because the performance was actually better than I needed I decided to remove the forking on the 2nd level and run it single threaded at that level. For the future I would probably just implement two different executor services per each level. So the lesson I learnt is never to use the same executor service "inside" itself.

Resurrecting my "not yet started" blog

Several years ago...

Several years ago I thought that it was a good idea to try blogging. I wrote 5 more or less testing posts but then focused on other university stuff and overall did not think I had much to blog about.

...now...

Fast forwarding 5 years to now (interesting that the month is the same:)) the same thought came into my mind "to blog". Main reason why that came into my head is that I was rethinking areas where to get different kind of experience which would be fun and stuff like open source project or blogging seemed like a good and interesting area. I like explaining what I have learned or discovered so that plays along as well. Also my current manager told me that this is actually a good idea and he has had a positive experience with opensource/blogging himself. Meeting new people is also the second main reason for doing this. And last but not least is that now I feel more comfortable that I actually have something to blog about that could be potentially interesting to some audience. If this goes well it may also bring some interesting opportunities along the way.

...is coming...

You can expect topics like recommender systems (I absolutely love this domain as the whole), programming in general, some focus on Clojure as I am starting with it.

First from the phone post

The very first try of blogger mobile
A little time ago I set up my own blog to make some posts about what interests me. After first post I was enthusiastic to find out if there is also some possibility to blog from the mobile phone, for which google has its own app.

At the first look the blogging range of features is shrinked on the mobile. You can choose only bold and underlined formating for the text. Text size or headlines - not possible. However, not that bad, but not dedicated to full blogging experience.

The second aspect that came into mu mind was number of missclicks using the mobile keyboard. In my case it was fair enough but not suited for longer text. You can even proofread it comfortably either.

I would guess that it demands longer practising and more focus on what I am writing. Also spellchecker is missssing and speaking I am not native english speaker I use spellchecking quite some time.

Debugging of parallel programm

It is definitely not easy
Everybody is likely to know that multithreaded apps are very tough to find a bug in. I had the similar opinion but today I had to get into fight with my program that is for school and is to do its job in parallel. 
 
I would have guessed how hard/easy it could be. Hard for that it was very hard to decide where to find to find a defect. On the other side surprisingly easy when I used "couts". Did not have time to look for some debugger (if such one exists and is free). However, using "couts" and grep (first this time I appreciated its qualities) pretty much helped.