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?
On Feb 10, 2013, at 9:36 AM, Ted Dunning <ted.dunn...@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 <sro...@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.fer...@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.
