=Paper=
{{Paper
|id=Vol-1688/paper-07
|storemode=property
|title=Explicit Elimination of Similarity Blocking for Session-based Recommendation
|pdfUrl=https://ceur-ws.org/Vol-1688/paper-07.pdf
|volume=Vol-1688
|authors=Mattia Brusamento,Roberto Pagano,Martha Larson,Paolo Cremonesi
|dblpUrl=https://dblp.org/rec/conf/recsys/BrusamentoPLC16
}}
==Explicit Elimination of Similarity Blocking for Session-based Recommendation==
https://ceur-ws.org/Vol-1688/paper-07.pdf
Explicit Elimination of Similarity Blockers for
Session-based Recommendation
Mattia Brusamento1 , Roberto Pagano1 , Martha Larson2 , and Paolo Cremonesi1
1
DEIB, Politecnico di Milano, Milan, Italy, @polimi.it
2
Delft University of Technology, Delft & Radboud University, Nijmegen, Netherlands, m.a.larson@tudelft.nl
ABSTRACT The effect may be subtle, but a larger implication is that we
A single ‘odd’ interaction can cause two user interaction ses- should not assume that items occurring in similar sessions
sions to diverge in similarity, and stand in the way of gen- contribute positively to recommendations.
eralization. The sensitivity of session-based recommenders
to session similarity motivates us to explicitly identify and 2. REDUNDANCY AND RECSYS
remove such ‘similarity blockers’. Specifically, we leverage We identify items (pairs or small clusters) that have dif-
huge amounts of data, which allow us to identify blockers in ferent item IDs, but should be treated as the same item,
the form of non-co-occurring items. Other blockers can be since they will otherwise introduce a non-negligible ‘similar-
identified using content-based similarity. Our experiments ity blocking’ effect. We demonstrate two points: (1) these
reveal that explicitly eliminating relatively few blockers im- items should not be recommended together (since they are
proves performance. redundant) and (2) collapsing them before training a model
could enhance performance (by eliminating ‘blocking’).
Keywords We adopted two different approaches to find similarity-
blocker items. The first and more straightforward approach,
Near-duplicates; Session-based; Large-scale; 30Music dataset called technical duplicates, is based on the idea of detecting
near-duplicates in the collection of songs. In our case, the
1. INTRODUCTION available metadata is a Last.fm1 URL, consisting of a string
Session-based recommender systems leverage information containing artist and title. We apply some basic NLP tech-
about the current user session to predict how it will con- niques to compute the similarity between two items: after
tinue. Session-based methods often rely heavily on similar- properly parsing the URL, we compute the Jaccard simi-
ity between sessions. A single aberrant user interaction in a larity among the resulting words. Since we are looking for
session has the power to cause two otherwise highly similar near-duplicates, we apply a threshold to decide which items
sessions to suddenly become dissimilar. We refer to such an should be considered equal.
interaction as a ‘session blocker’, since it causes two sessions The second and more sophisticated approach, called col-
to be different without reflecting a real underlying difference laborative duplicates, leverages the fact that two items fail
of user preference. to ever co-occur despite their occurrence in similar (but sep-
Session blockers can arise in two ways. First, a user may arate) contexts. The idea finds support in our observation
interacts with an item only once, incidentally and unrelated that, for a given user, the similarity between sessions con-
to preference. Second, the user may click on a preference- taining technical duplicates is significantly higher than the
related item, but it is a near-duplicate, and has an unex- average pairwise session similarity: this suggests that we can
pected item ID. expect near-duplicates to appear in similar sessions from the
The current era of big data opens the ability to search same user. Moreover, we expect two near-duplicates never
for individual interactions that may have been incidental to co-occur in the same session, based on the rationale that
clicks. In the past, non-occurrence, or non-co-occurrence of the user would not listen to both of them together.
items could be attributed to lack of data. Now, however, it Next, we describe our technique. During training, we con-
makes sense to investigate whether this non-co-occurrence is sider the set of sessions from each user in turn, and compute
truly incidental or whether it could be considered the source the pairwise Jaccard similarity on this set. We retain the
of additional information that can be exploited for further pairs above a certain threshold. From these pairs of ses-
improve recommendations. For completeness we also look at sions, we extract pairs of items, such that one belongs to
conventional near-duplicates identified on the basis of their one session and one to the other, with the constraint that
metadata. We are inspired by our previous work on near- they must not co-occur in a session the training set for any
duplicates in large collections [3]. user. The score given to the pairs of items is calculated
In this paper, we show that considering items similar due as the average similarity between the pairs of similar ses-
to non-co-occurrence, and, more conventionally, on the ba- sions from which they come from, with a shrinkage factor.
sis of metadata will improve recommendation effectiveness. Finally, we keep the pairs of items with a score above the
average, thus creating a cluster for each of these items. In
Copyright is held by the authors. 1
RecSys 2016 Poster Proceedings, September 15-19, 2016, Boston, USA . http://www.last.fm
this way, many cluster overlap each other, and creating the can be considered more important. Figure 1 shows the dif-
transitive closure of the clusters will result in a unique single ferences between the performance obtained by applying the
big cluster containing all the clustered songs. Since we are clustering and the original IPR. We see that applying the
instead interested in micro-clusters we kept only the disjoint combination of the collaborative and technical redundancy
clusters, which usually contain 2 or 3 items. detection (Coll&J75 and Coll&J9), leads to a positive differ-
ence in the performance for all N , and has positive effects in
3. DATA AND EXPERIMENTS the training of the model. Precision, omitted here for space
We carried out our experiments with an already existing reasons, shows similar behavior.
large scale music recommender system: the implicit playlist
0.0015
recommender (IPR) [1]. The algorithm is trained using the J75
J9
user listening sessions: similar sessions from the same user Coll
Difference in recall@N w.r.t IPR
0.0010 Coll & J9
are considered as implicit playlists. The recommendations Coll & J75
are performed by matching the current session against the
implicit playlists, the songs from the best matching playlists 0.0005
are then recommended. Our goal is to improve the perfor-
mance of this algorithm by conflating redundant items. The 0.0000
data we used come from the 30Music dataset [2], thus the
size of the catalog is quite big (about 4M songs). We adopted
0.0005
Apache Spark to deal with the large-scale of the data. In
particular, we used a cluster composed by 200 nodes.
To compute technical duplicates, we applied some heuris- 0.00100 20 40 60 80 100
tic optimization, such as the assumption that two near- N
duplicates should have at least one bigram in common. In Figure 1: Impact of clustering on recommendation
this way, we avoid comparing each item with all the others.
By leveraging the map-reduce paradigm, our algorithm took The difference in performance can be explained by the fact
about 4 hours to identify near-duplicates. As one could ex- that merging redundant items allows the creation of more
pect, using this technique we find redundant items as: ’Chris playlists. In all the cases, our techniques improve the per-
James feat. Ria Moran - Song For Her’ and ’Chris James - formance for big N . This is because the original algorithm
Song for Her (feat. Ria Moran)’. In this way, we reduced poses an hard threshold on a soft similarity (shrunk Jac-
the number of items by 6.09%. card) and, by merging duplicates, a larger number of useful
As for the collaborative duplicates, the number of items implicit playlists are above the similarity threshold. In the
we were able to find was much lower (around 600). All of future, we plan to analyze the effects with different recom-
them belong to the long tail, but come from the most active mendation algorithms and also to evaluate online.
users, who have a higher probability of contributing. Finally, we double-checked our assumptions by mapping
our new recommendations into the original space, which we
Table 1: Collaborative Duplicates Examples did by flattening the clusters. As one would expect, this de-
Brutal Truth - Swift and Violent (Swift Version) grades the performance. This result confirms our conclusion
Brutal Truth - Swift and Violent - Swift Version that the groups of items we identified as redundant should
Luis Miguel - La Incondicional not be recommended together.
Luis Miguel - Cuando,vuelva a tu lado The findings in this paper are interesting in light of the
Underoath - Moving for the Sake of Motion currently growing importance of session-based recommen-
Demon Hunter - Less Than Nothing dation. Effectively, we have shown that not all similarity
is good: instead, items can potentially be too similar. The
Table 1 contains three characteristic examples of collab- approach of eliminating such similarity-blocker items explic-
orative duplicates: the first illustrates two songs that are itly, is greater than might be otherwise assumed, given their
technically equivalent and are detected also by the first tech- relative limited numbers. Merging items before training a
nique. The second example shows two songs from the same model can boost performance, and, moving forward, may
artist. Note we do not claim that two songs from the same also have important implications for diversity: by removing
artist should be automatically considered redundant. The too-similar items, more slots open for other items.
last example is the hardest to classify: these two songs have
a similar content, in the sense that they have the same acous-
5. REFERENCES
[1] R. Turrin, A. Condorelli, P. Cremonesi, R. Pagano, and
tic features. In this case, our mining technique shows the
M. Quadrana. Large scale music recommendation.
ability to spot also pairs of songs that are not straightfor-
Workshop on Large-Scale Recommender Systems
ward to classify even by a human.
(LSRS 2015) at ACM RecSys, 2015.
4. RESULTS AND DISCUSSION [2] R. Turrin, M. Quadrana, A. Condorelli, R. Pagano, and
P. Cremonesi. 30Music listening and playlists dataset.
We adopted the original experimental settings of the IPR2 ACM RecSys poster 2015
used in [1]. We ensure score comparability by projecting the CEUR-WS.org/Vol-1441/recsys2015 poster13.pdf.
recommendations generated by IPR into the cluster space of
[3] R. Vliegendhart, M. Larson, and J. A. Pouwelse.
the experimental conditions. Note that this process advan-
Discovering user perceptions of semantic similarity in
tages the baseline, meaning that smaller differences in score
near-duplicate multimedia files. CrowdSearch 2012
2
https://github.com/mquad/playlistrec CEUR-WS.org/Vol-842/crowdsearch-vliegendhart.pdf.