lyst / lyst/lightfm

Question regarding how preferences are modeled with BPR loss

Open
#608 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
5.1k
Forks
724
PR merge metrics
No merged PRs in 30d

Description

Hi all!

First of all, thank you so much for the effort in this lib. Works really well :)

However, while using it with some implicit data (in fact, count data) I had a question on how the training is done with BPR loss. Let me explain:

As you already know: for modelling preferences with BPR loss, a pairwise loss is used; so each training instance is a triplet in the form of `(user, item1, item2)`; where the model learns the preference between the two items for that specific user.

Imagine that I have an implicit dataset with play counts for movies (how many times each user has watched a specific movie). To make things easier, let's imagine that I only have a single user, and the following interaction data:

- Movie A, watched 8 times
- Movie B, watched 2 times
- Movie C, watched 2 times
- Movie D, watched 0 times (this is, no interaction)

I was wondering how the training triplets would look like with such dataset. We know the preference for all possible triplet combinations, except for the one between B and C (as their play count is exactly the same; so we cannot infer any preference between them).

However by skimming through the source code, I would say that the way the *negative sampling* works in LightFM with BPR loss would yield only the following training triplets:

- `(user, Movie A, Movie D)`
- `(user, Movie B, Movie D)`
- `(user, Movie C, Movie D)`

Which is correct (as BPR assumes preference on all watched movies over the unwatched one). However, the model would me missing some valuable information: our user prefers Movie A over B and C also (as he/she has watched it way more times).

But for what I have seen in the source code, non-zero items are only compared against zero (unwatched) ones, therefore missing the *prefer A over B/D* training instances.

Is that right? If that is the case, would you be interested in a contribution to include those additional preferences as part of the training procedure?

Also, does it work the same way for WARP loss?

Thanks a ton!

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the source code's negative-sampling paths for BPR and WARP and compare their behavior with the count-data example in the issue. Confirm how equal and differing nonzero interactions are handled; done requires an agreed training design for additional preferences and tests covering the resulting triplets.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
machine-learning
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.