hidasib / GRU4Rec

GRU4Rec is the original Theano implementation of the algorithm in "Session-based Recommendations with Recurrent Neural Networks" paper, published at ICLR 2016 and its follow-up "Recurrent Neural Networks with Top-k Gains for Session-based Recommendations". The code is optimized for execution on the GPU.
Other
754 stars 223 forks source link

Model Update Bug of BPR baseline #10

Closed voladorlu closed 7 years ago

voladorlu commented 7 years ago

In the update function of BPR baseline, you forget to update the bias parameters. That's very important since the defined relevance function includes this term. Please double check your code. Maybe it's the reason why the performance of BPR shown in your paper is so bad.

hidasib commented 7 years ago

You are right in the sense, that the biases are not updated during training. But this is not the reason why BPR-MF results are so bad. The reason for the bad performance is that BPR-MF is not suitable for the session-based task in which each test session is basically a user cold-start scenario. It is easy to see that this is the case, as BPR-MF, like any other matrix factorization, works best if the user/item set is fairly static thus it can use the representations it learned during training. It can't directly handle new items or users. In session-based recommendations every new session is basically a new "user" for which BPR doesn't have a model, thus can't recommend anything. Therefore we used only the item feature vectors from BPR to do the recommendations: we represent the session as the average of the feature vectors of the items in the session so far and we recommend the item(s) with the most similar feature vectors to this representation. In this setting, using biases doesn't really make sense. They can't be used during similarity computations. One could argue that they capture some aspects of the data allowing the item feature vectors to be better representations. We tried this, but the results were worse, so we removed this from the final version. Unfortunately it seems that some of the earlier version made it into the public repo. This is the reason while you see the initialization of the bias terms, but not their update. I'll completely remove them eventually with the next bigger update.

Side note: earlier experiments with BPR-MF on standard personalized recommendations (on implicit data) showed that using the bias term is not always beneficial even during the classic recommendation scenario. On 2 dataset of 5 we found that disabling the bias resulted in better accuracy. Since the examination of BPR-MF was not the focus of that project we didn't investigate this further, but my assumption is that sometimes item biases can learn the popularity bias of the training data too well, which is not beneficial if the trendiness of the items cahnge more rapidly. User biases don't mater during ranking, so their role is only to help learning better representations, which generally have lesser effect that the item biases.

voladorlu commented 7 years ago

@hidasib hidasib It's very glad to see your reply. I have read your paper again. More interesting things come into my mind. I used to think session data should include user identifier since online system can only allow users to buy something after logging in. However, the data used in your case only contains item sequence in a session, which becomes a sort of item-driven recommendation problem. Your statement clarifies my concerns very much. Thank you~