You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mahout.apache.org by Koobas <ko...@gmail.com> on 2013/02/21 15:37:26 UTC
GenericUserBasedRecommender vs GenericItemBasedRecommender
In the GenericUserBasedRecommender the concept of a neighborhood seems to
be fundamental.
I.e., it is a classic implementation of the kNN algorithm.
But it is not the case with the GenericItemBasedRecommender.
I understand that the two approaches are not meant to be completely
symmetric,
but still, wouldn't it make sense, from the performance perspective, to
compute items' neighborhoods first,
and then use them to compute recommendations?
If kNN was run on items first, then every item-item similarity would be
computed once.
It looks like in the GenericItemBasedRecommender each item-item similarity
will be computed multiple times.
(How much, depends on the data, but still.)
I am wondering if anybody has any thoughts on the validity of doing
item-item kNN in the context of:
1) performance,
2) quality of recommendations.
Re: GenericUserBasedRecommender vs GenericItemBasedRecommender
Posted by Julian Ortega <jo...@gmail.com>.
The javadoc should be a nice start
https://builds.apache.org/job/Mahout-Quality/javadoc/org/apache/mahout/cf/taste/impl/recommender/AbstractCandidateItemsStrategy.html
Apart from that, I'd say you should have a look around the code.
On Thu, Feb 21, 2013 at 3:42 PM, Koobas <ko...@gmail.com> wrote:
> On Thu, Feb 21, 2013 at 9:39 AM, Sean Owen <sr...@gmail.com> wrote:
>
> > It's also valid, yes. The difference is partly due to asymmetry, but also
> > just historical (i.e. no great reason).* The item-item system uses a
> > different strategy for picking candidates based on
> CandidateItemStrategy.*
> >
> > Where do I find more information about this?
> And thanks for the instantaneous reply :)
>
> >
> > On Thu, Feb 21, 2013 at 2:37 PM, Koobas <ko...@gmail.com> wrote:
> >
> > > In the GenericUserBasedRecommender the concept of a neighborhood seems
> to
> > > be fundamental.
> > > I.e., it is a classic implementation of the kNN algorithm.
> > >
> > > But it is not the case with the GenericItemBasedRecommender.
> > > I understand that the two approaches are not meant to be completely
> > > symmetric,
> > > but still, wouldn't it make sense, from the performance perspective, to
> > > compute items' neighborhoods first,
> > > and then use them to compute recommendations?
> > >
> > > If kNN was run on items first, then every item-item similarity would be
> > > computed once.
> > > It looks like in the GenericItemBasedRecommender each item-item
> > similarity
> > > will be computed multiple times.
> > > (How much, depends on the data, but still.)
> > >
> > > I am wondering if anybody has any thoughts on the validity of doing
> > > item-item kNN in the context of:
> > > 1) performance,
> > > 2) quality of recommendations.
> > >
> >
>
Re: GenericUserBasedRecommender vs GenericItemBasedRecommender
Posted by Koobas <ko...@gmail.com>.
On Thu, Feb 21, 2013 at 9:39 AM, Sean Owen <sr...@gmail.com> wrote:
> It's also valid, yes. The difference is partly due to asymmetry, but also
> just historical (i.e. no great reason).* The item-item system uses a
> different strategy for picking candidates based on CandidateItemStrategy.*
>
> Where do I find more information about this?
And thanks for the instantaneous reply :)
>
> On Thu, Feb 21, 2013 at 2:37 PM, Koobas <ko...@gmail.com> wrote:
>
> > In the GenericUserBasedRecommender the concept of a neighborhood seems to
> > be fundamental.
> > I.e., it is a classic implementation of the kNN algorithm.
> >
> > But it is not the case with the GenericItemBasedRecommender.
> > I understand that the two approaches are not meant to be completely
> > symmetric,
> > but still, wouldn't it make sense, from the performance perspective, to
> > compute items' neighborhoods first,
> > and then use them to compute recommendations?
> >
> > If kNN was run on items first, then every item-item similarity would be
> > computed once.
> > It looks like in the GenericItemBasedRecommender each item-item
> similarity
> > will be computed multiple times.
> > (How much, depends on the data, but still.)
> >
> > I am wondering if anybody has any thoughts on the validity of doing
> > item-item kNN in the context of:
> > 1) performance,
> > 2) quality of recommendations.
> >
>
Re: GenericUserBasedRecommender vs GenericItemBasedRecommender
Posted by Sean Owen <sr...@gmail.com>.
It's also valid, yes. The difference is partly due to asymmetry, but also
just historical (i.e. no great reason). The item-item system uses a
different strategy for picking candidates based on CandidateItemStrategy.
On Thu, Feb 21, 2013 at 2:37 PM, Koobas <ko...@gmail.com> wrote:
> In the GenericUserBasedRecommender the concept of a neighborhood seems to
> be fundamental.
> I.e., it is a classic implementation of the kNN algorithm.
>
> But it is not the case with the GenericItemBasedRecommender.
> I understand that the two approaches are not meant to be completely
> symmetric,
> but still, wouldn't it make sense, from the performance perspective, to
> compute items' neighborhoods first,
> and then use them to compute recommendations?
>
> If kNN was run on items first, then every item-item similarity would be
> computed once.
> It looks like in the GenericItemBasedRecommender each item-item similarity
> will be computed multiple times.
> (How much, depends on the data, but still.)
>
> I am wondering if anybody has any thoughts on the validity of doing
> item-item kNN in the context of:
> 1) performance,
> 2) quality of recommendations.
>