mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Implicit preferences
Date Sat, 16 Feb 2013 04:42:57 GMT
On Tue, Feb 12, 2013 at 9:18 AM, Pat Ferrel <pat.ferrel@gmail.com> wrote:

> Maybe I'm splitting hairs here but I was thinking of using the frequency
> in the views. Maybe above some number of view = 1, below = 0.
>
> In any case this just seems like a different way of constructing A, no?
>

Correct.

In general, getting the best surrogate for your measure of engagement is
one of the hardest things to do.

Frequency might be right, but isn't very general.  For videos, I have used
>30 second views.  For music, time works, but is very complicated.  For web
pages, time spent in focus might be useful (but you have to worry about
people who open lots of pages in new tabs... thus the focus qualifier).

The trick with all of these is that you want to avoid good headlines or
descriptions that lead to bad content.

Surrogates are usually necessary for training rec engines because the real
target is either unobservable (user liked it) or too rare (purchases,
perhaps) or takes too long to measure (user takes meat-space action over a
period of weeks).


>
> On Feb 10, 2013, at 9:36 AM, Ted Dunning <ted.dunning@gmail.com> wrote:
>
> Actually treating the different interactions separately can lead to very
> good recommendations.  The only issue is that the interactions are no
> longer dyadic.
>
> If you think about it, having two different kinds of interactions is like
> adjoining interaction matrices for the two different kinds of interaction.
> Suppose that you have user x views in matrix A and you have user x
> purchases in matrix B.  The complete interaction matrix of user x (views +
> purchases) is [A | B].
>
> When you compute cooccurrence in this matrix, you get
>
>               [A | B] = [ A' ]           [ A' A  A' B ]
>      [A | B]' [A | B] = [    ] [A | B] = [            ]
>               [A | B] = [ B' ]           [ B' A  B' B ]
>
> This matrix is (view + purchase) x (view + purchase).  But we don't care
> about predicting views so we only really need a matrix that is purchase x
> (view
> + purchase).  This is just the bottom part of the matrix above, or [ B'A |
> B'B ].  When you produce purchase recommendations r_p by multiplying by a
> mixed view and purchase history vector h which has a view part h_v and a
> purchase part h_p, you get
>
>      r_p = [ B' A  B' B ] h = B'A h_v + B'B h_p
>
> That is a prediction of purchases based on past views and past purchase.
>
> Note that this general form applies for both decomposition techniques such
> as SVD, ALS and LLL as well as for sparsification techniques such as the
> LLR sparsification.  All that changes is the mechanics of how you do the
> multiplications.  Weighting of components works the same as well.
>
> What is very different here is that we have a component of cross
> recommendation.  That is the B'A in the formula above.  This is very
> different from a normal recommendation and cannot be computed with the
> simple self-join that we normally have in Mahout cooccurrence computation
> and also very different from the decompositions that we normally do.  It
> isn't hard to adapt the Mahout computations, however.
>
> When implementing a recommendation using a search engine as the base, these
> same techniques also work extremely well in my experience.  What happens is
> that for each item that you would like to recommend, you would have one
> field that has components of B'A and one field that has components of B'B.
> It is handy to simply use the binary values of the sparsified versions of
> these and let the search engine handle the weighting of different
> components at query time.  Having these components separated into different
> fields in the search index seems to help quite a lot, which makes a fair
> bit of sense.
>
> On Sun, Feb 10, 2013 at 9:55 AM, Sean Owen <srowen@gmail.com> wrote:
> >
> > I think you'd have to hack the code to not exclude previously-seen items,
> > or at least, not of the type you wish to consider. Yes you would also
> have
> > to hack it to add rather than replace existing values. Or for test
> > purposes, just do the adding yourself before inputting the data.
> >
> > My hunch is that it will hurt non-trivially to treat different
> interaction
> > types as different items. You probably want to predict that someone who
> > viewed a product over and over is likely to buy it, but this would only
> > weakly tend to occur if the bought-item is not the same thing as the
> > viewed-item. You'd learn they go together but not as strongly as ought to
> > be obvious from the fact that they're the same. Still, interesting
> thought.
> >
> > There ought to be some 'signal' in this data, just a question of how much
> > vs noise. A purchase means much more than a page view of course; it's not
> > as subject to noise. Finding a means to use that info is probably going
> to
> > help.
> >
> >
> >
> >
> > On Sat, Feb 9, 2013 at 7:50 PM, Pat Ferrel <pat.ferrel@gmail.com> wrote:
> >
> >> I'd like to experiment with using several types of implicit preference
> >> values with recommenders. I have purchases as an implicit pref of high
> >> strength. I'd like to see if add-to-cart, view-product-details,
> >> impressions-seen, etc. can increase offline precision in holdout tests.
> >> These less than obvious implicit prefs will get a much lower value than
> >> purchase and i'll experiment with different mixes. The problem is that
> some
> >> of these prefs will indicate that the user, for whom I'm getting recs,
> has
> >> expressed a preference.
> >>
> >> Using these implicit prefs seems reasonable in finding similarity of
> taste
> >> between users but presents several problems. 1) how to encode the prefs,
> >> each impression-seen will increase the strength of preference of a user
> for
> >> an item but the recommender framework replaces the preference value for
> >> items preferred more than once, doesn't it? 2) AFAIK the current
> >> recommender framework will return recs only for items that the user in
> >> question has expressed no preference for. If I use something like
> >> view-product-details or impressions-seen, I will be removing anything
> the
> >> user has seen from the recs, which is not what I want in this
> experiment.
> >>
> >> Has anyone tried something like this? I'm not convinced that these other
> >> implicit preferences will add anything to the recommender, just trying
> to
> >> find out.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message