mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pat Ferrel <>
Subject Re: Cross recommendation
Date Sat, 23 Feb 2013 18:39:35 GMT
This is exactly what I was trying to say in an earlier email. It's an easy first cut. I understand
that it doesn't allow adjusting weights separately.

I'd create a training set of (item+action, user). So [B'B] will have four values for a single
item, This will use the views for similarity of user but would also return view recs, which
I could filter out.

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)? 

Thanks for sticking with this. I suspect many recommender users will eventually get to the
point where they want to use more than one implicit preference action. Especially in cases
where you don't have a lot of cf type data. Using extra actions gives more ways to find a

On Feb 22, 2013, at 3:46 PM, Ted Dunning <> wrote:

The absolutely minimal page is to give different ids to the different
actions against the same item.  Then analyze as normal, but ignore
recommendations to item/action combos that you can't deal with. This
computes all four parts of the combined item recommendation matrix which is
roughly twice as much work as you need to do and it also doesn't let you
adjust weightings separately.

But it is probably the simplest way to get going with cross recommendation.

On Fri, Feb 22, 2013 at 9:48 AM, Pat Ferrel <> wrote:

> Therefore my discussion was assuming the use of the entire mahout cf/taste
> framework even in the retrieving of recs. In that light  B'B h_p is just
> another way of stating the usual train with user and items purchased then
> get recs for users and so that part of recs is covered. Since this also
> supports item similarity based queries (no user in the query) I'm covered.
> As to the B'A h_v part, isn't that just replacing where cf/taste would
> calc B'B, the self-join matrix, with the result of B'A? To use cf/taste you
> would ingest the user and items viewed data to create h_v for all users,
> but instead of allowing cf/taste to calculate B'B you would replace it with
> B'A. Then at query time taste would take a user and return purchase recs by
> calculating B'A h_v? isn't this correct? I hope someone comments on this
> because it is the route I plan to explore.
> The downside is that without lucene I would  have two (or more) sets of
> recs to blend. I can make lucene return the raw recs fields but not sure
> how to return similarity based queries with lucene and don't really want to
> tackle that just yet (keep it simple?)
> Also in using cf/taste I don't need to create rows of the combined matrix,
> I can treat them as independent recommenders, which means I can tune them
> independently. I still have questions about how to generate the view values
> of A but that's another discussion.

View raw message