I may not be 100% following the thread, but: Similarity metrics won't care whether some items are really actions and some items are items. The math is the same. The problem which you may be alluding to is the one I mentioned earlier -- there is no connection between item and item-action in the model, when there plainly is in real life. The upside is what Ted mention: you get to treat actions like views separately from purchases, and yes it's also certain those aren't the same thing in real life. YMMV.
The piece of code you're playing with has nothing to do with latent factor models and won't learn weights. It's going to assume by default that all items (+actions) are equal. (user+action,item) doesn't make sense. You compute item-item similarity from (user,item+action) data. Some of the results are really item-action similarities or action-action. It may be useful, maybe not, to know these things too but you can just look at item-item if you want. On Sun, Feb 24, 2013 at 4:39 PM, Pat Ferrel <pat.fer...@gmail.com> wrote: > Yes I understand that you need (user, item+action) input for user based > recs returned from recommender.recommend(userID, n). > > But can you expect item similarity to work with the same input? I am fuzzy > about how item similarity is calculated in cf/taste. > > I was expecting to train one recommender with (user, item+action) and call > recommender1.recommend(userID, n) to get recs but also train another > recommender with (user+action, item) to get recommender2.mostSimilarItems( > itemID, n). I realize it's a hack but that aside is this second recommender > required? I'd expect it to return items that use all actions to calculate > similarity and therefore will use view information to improve the > similarity calculation. > > No? > > > On Feb 23, 2013, at 10:06 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > > No. > > It is uniformly better to have (item+action, user). In fact, I would > prefer to have it the other way around when describing it to match the > matrix row x column convention. > > (user, item+action) where action is binary leads to A = [A_1 | A_2] = user > by 2xitem. The alternative of (user+action, item) leads to > > [ A_1 ] > A = [ ] = 2xuser by item > [ A_2 ] > > This last form doesn't have a uniform set of users to connect the items > together. When you compute the cooccurrence matrix you get A_1' A_1 + A_2' > A_2 which gives you recommendations from 1=>1 and from 2=>2, but no > recommendations 1=>2 or 2=>1. Thus, no cross recommendations. > > > > On Sat, Feb 23, 2013 at 10:39 AM, Pat Ferrel <pat.fer...@gmail.com> wrote: > > > But the discussion below lead me to realize that cf/taste is doing > > something in addition to [B'B] h_p, which returns user history based > recs. > > I'm getting better results currently from item similarity based recs, > which > > I blend with user-history based recs. To get item similarity based recs > > cf/taste is using a similarity metric and I'd guess that it uses the > input > > matrix to get these results (something like the dot product for cosine). > > For item similarity should I create a training set of (item, > user+action)? > >
