A question regarding GenericUserBasedRecommender

[Yanir Seroussi <ya...@gmail.com>]

Hi,

The first example here (
https://cwiki.apache.org/confluence/display/MAHOUT/Recommender+Documentation)
shows how to create a GenericUserBasedRecommender with a
NearestNUserNeighborhood. My problem/question is that setting n to any small
number seems to limit the coverage of the recommender, because the nearest n
users are calculated without taking the target item into account.
For example, given a user X and n = 10, if we want to estimatePreference()
for an item Y, if this item is not rated by any user in the neighbourhood,
the prediction will be NaN. I don't think that this is what one would expect
from a user-based nearest-neighbour recommender, as Herlocker et al. (1999),
who are cited in the example page above, didn't mention any change in
coverage based on the number of nearest neighbours.
Am I doing something wrong, or is this the way it should be? I have a
feeling it is not the way it should be, because then using small
neighbourhood sizes makes no sense as it severely restricts the ability of
the recommender to estimate preferences.

Please note that I observed this behaviour in version 0.3, but it seems to
be the same in the latest version.

Cheers,
Yanir

Re: A question regarding GenericUserBasedRecommender

[alex lin <al...@gmail.com>]

Hi,

   It seems like you have a very sparse user-item matrix, which is very
common in real world applications.  You can try to improve coverage with
Item-based Recommender (assuming you have much more Users in the dataset
compare to Items) or you can make CF neighborhood formation (similarity
measures) happen in SVD reduced space. How to find the most optimal low-rank
SVD setting is another long story.

fyi, above changes will not be able address to the low coverage issue caused
by cold-start problem.  Cold-start problem needs to be addressed by changing
data representation and features we use to construct user-item matrix.

Cheers,

Alex

On Mon, Aug 9, 2010 at 4:31 AM, Yanir Seroussi <ya...@gmail.com>wrote:

> Hi,
>
> The first example here (
>
> https://cwiki.apache.org/confluence/display/MAHOUT/Recommender+Documentation
> )
> shows how to create a GenericUserBasedRecommender with a
> NearestNUserNeighborhood. My problem/question is that setting n to any
> small
> number seems to limit the coverage of the recommender, because the nearest
> n
> users are calculated without taking the target item into account.
> For example, given a user X and n = 10, if we want to estimatePreference()
> for an item Y, if this item is not rated by any user in the neighbourhood,
> the prediction will be NaN. I don't think that this is what one would
> expect
> from a user-based nearest-neighbour recommender, as Herlocker et al.
> (1999),
> who are cited in the example page above, didn't mention any change in
> coverage based on the number of nearest neighbours.
> Am I doing something wrong, or is this the way it should be? I have a
> feeling it is not the way it should be, because then using small
> neighbourhood sizes makes no sense as it severely restricts the ability of
> the recommender to estimate preferences.
>
> Please note that I observed this behaviour in version 0.3, but it seems to
> be the same in the latest version.
>
> Cheers,
> Yanir
>

Re: A question regarding GenericUserBasedRecommender

[Yanir Seroussi <ya...@gmail.com>]

What I was trying to say is that creating a metric that captures *all* the
desired characteristics in a single score is hard.

I agree that it's not hard to come up with metrics that measure the quality
of a recommender's top-K recommendations, but I think that's one of the
problems -- there are many metrics out there and no consensus (as far as I
know) about which metric is the "best", and that makes it hard to compare
recommendation algorithms. However, I think that measuring the MAE/RMSE on
all the available test item/user preferences is still worthwhile, and can
give an indication of the overall performance of the recommender. Evidence
for this is given in Koren's "Factorization Meets the Neighborhood" (
http://research.yahoo.com/files/kdd08koren.pdf). He reported the results in
terms of RMSE and then looked at the results for top-K recommendations
(using his own metric...), and found that there's a strong link between
small improvements in RMSE and large improvements in top-K recommendation
quality:

"We are encouraged, even somewhat surprised, by the results. It is evident
that small improvements in RMSE translate into significant improvements in
quality of the top K products. In fact, based on RMSE differences, we did
not expect the integrated model to deliver such an emphasized improvement in
the test."

I agree that the overall performance of the system is probably more affected
by UI factors than by the accuracy of the underlying recommender, but these
two aspects can be developed separately. I think that the choice between
using a recommendation algorithm that magically manages to always generate
recommendations that are diverse, novel and accurate, and an algorithm that
sometimes fails to do that is obvious. So while bad UI design choices may
make a perfect recommendation algorithm useless, a good UI is likely to lead
to greater user satisfaction when a better recommendation algorithm is used,
and better may sometimes mean more accurate, all other things being equal.

On Sat, Aug 14, 2010 at 16:30, Ted Dunning <te...@gmail.com> wrote:

> I think that these statements are subject to substantial debate.
>
> Regarding the creation of a metric that captures important characteristics,
> it isn't that hard.  For instance, you can simply measure the estimation
> error on the items that appear in the top 50 of either reference or actual
> recommendations.  Likewise, you can use a truncated rank metric that
> measures the ranks at which reference items appear.  Neither of these
> measures is difficult to implement and both are better than mean squared
> error or other measurements that require all items to be scored.
>
> Capturing the diversity measurement *is* really difficult and the only way
> that I know to do that is to measure a real system on real users.  Beyond
> the limits of a fairly simple recommendation system, UI factors such as how
> you present previously recommended items, how many items are shown and what
> expectations you set with users will make far more difference than small
> algorithmic changes.  In fact, in a real system that is subject to the
> circular feedback that such systems are prone to, a system that degrades
> recommendation results with random noise can, in fact, provide a better
> user
> experience than one which presents unadulterated results.
>
> On Fri, Aug 13, 2010 at 9:06 PM, Yanir Seroussi <yanir.seroussi@gmail.com
> >wrote:
>
> > I still think that it's worthwhile to compare rating errors of different
> > algorithms on all items, because in general it is likely that the more
> > accurate algorithm will generate better recommendations. Comparing the
> > actual generated recommendations is not as simple as comparing rating
> > errors, though it is very important. As Ted said, you need to worry about
> > the ordering of the top few items, and you typically don't want all the
> > recommended items to be too similar to each other or too obvious.
> However,
> > capturing all these qualities in a single metric is quite hard, if not
> > impossible.
> >
>

Re: A question regarding GenericUserBasedRecommender

[Ted Dunning <te...@gmail.com>]

I think that these statements are subject to substantial debate.

Regarding the creation of a metric that captures important characteristics,
it isn't that hard.  For instance, you can simply measure the estimation
error on the items that appear in the top 50 of either reference or actual
recommendations.  Likewise, you can use a truncated rank metric that
measures the ranks at which reference items appear.  Neither of these
measures is difficult to implement and both are better than mean squared
error or other measurements that require all items to be scored.

Capturing the diversity measurement *is* really difficult and the only way
that I know to do that is to measure a real system on real users.  Beyond
the limits of a fairly simple recommendation system, UI factors such as how
you present previously recommended items, how many items are shown and what
expectations you set with users will make far more difference than small
algorithmic changes.  In fact, in a real system that is subject to the
circular feedback that such systems are prone to, a system that degrades
recommendation results with random noise can, in fact, provide a better user
experience than one which presents unadulterated results.

On Fri, Aug 13, 2010 at 9:06 PM, Yanir Seroussi <ya...@gmail.com>wrote:

> I still think that it's worthwhile to compare rating errors of different
> algorithms on all items, because in general it is likely that the more
> accurate algorithm will generate better recommendations. Comparing the
> actual generated recommendations is not as simple as comparing rating
> errors, though it is very important. As Ted said, you need to worry about
> the ordering of the top few items, and you typically don't want all the
> recommended items to be too similar to each other or too obvious. However,
> capturing all these qualities in a single metric is quite hard, if not
> impossible.
>

Re: A question regarding GenericUserBasedRecommender

[Yanir Seroussi <ya...@gmail.com>]

I agree with both of you (Ted and Sean) regarding the generation of
real-world recommendations, and I also think that it makes sense to use a
static neighbourhood when generating recommendations, because it will be too
slow to estimate the target user's rating of all the items in the system.

I still think that it's worthwhile to compare rating errors of different
algorithms on all items, because in general it is likely that the more
accurate algorithm will generate better recommendations. Comparing the
actual generated recommendations is not as simple as comparing rating
errors, though it is very important. As Ted said, you need to worry about
the ordering of the top few items, and you typically don't want all the
recommended items to be too similar to each other or too obvious. However,
capturing all these qualities in a single metric is quite hard, if not
impossible.

In any case, I think that the current behaviour should be documented, either
in the javadocs or in the wiki or both. I'm happy to update the
documentation if it's okay with you.

On Fri, Aug 13, 2010 at 06:09, Ted Dunning <te...@gmail.com> wrote:

> Focussing on rating error is also problematic in that it causes us to worry
> about being correct about the estimated ratings for items that will *never*
> be shown to a user.
>
> In my mind, the only thing that matters in a practical system is the
> ordering of the top few items and the rough composition of the top few
> hundred items.  Everything else makes no difference at all for real-world
> recommendations.
>
> On Thu, Aug 12, 2010 at 12:53 PM, Sean Owen <sr...@gmail.com> wrote:
>
> > I agree with your reading of what the Herlocker paper is saying. The
> > paper is focused on producing one estimated rating, not
> > recommendations. While those tasks are related -- recommendations are
> > those with the highest estimated ratings -- translating what's in
> > Herlocker directly to a recommendation algorithm is a significant
> > jump.
> >
>

Re: A question regarding GenericUserBasedRecommender

[Ted Dunning <te...@gmail.com>]

Focussing on rating error is also problematic in that it causes us to worry
about being correct about the estimated ratings for items that will *never*
be shown to a user.

In my mind, the only thing that matters in a practical system is the
ordering of the top few items and the rough composition of the top few
hundred items.  Everything else makes no difference at all for real-world
recommendations.

On Thu, Aug 12, 2010 at 12:53 PM, Sean Owen <sr...@gmail.com> wrote:

> I agree with your reading of what the Herlocker paper is saying. The
> paper is focused on producing one estimated rating, not
> recommendations. While those tasks are related -- recommendations are
> those with the highest estimated ratings -- translating what's in
> Herlocker directly to a recommendation algorithm is a significant
> jump.
>

Re: A question regarding GenericUserBasedRecommender

[Sean Owen <sr...@gmail.com>]

I agree with your reading of what the Herlocker paper is saying. The
paper is focused on producing one estimated rating, not
recommendations. While those tasks are related -- recommendations are
those with the highest estimated ratings -- translating what's in
Herlocker directly to a recommendation algorithm is a significant
jump.

Done that way, you start with all items as the set of candidate
recommendations, and for each, construct a neighborhood to estimate a
rating. Even with intelligent caching of user-user similarity -- the
framework does this -- this is orders of magnitude slower. It's
possible, but I don't think it's realistic in practice.

Instead I had always assumed the extension to an actual algorithm was
to let one neighborhood define the set of candidate items.

The issue isn't quite coverage, I think. If a user has no similarity
to any user, there can be no neighborhood, under any approach, and no
recommendations. If there is any neighborhood, recommendations can be
made.

The issue here it seems is including some particular item in the
recommendation, which is included in *some* neighborhood but not all
neighborhoods.

You give a good example where an item that, intuitively, should be
recommended is not a candidate for recommendation. I think there are
equal examples of this idea going wrong. Say that the most similar
users all have a similarity near -1. Under a simple threshold-based
neighborhood approach, no recommendations would be made, although,
there is indeed *some* neighborhood including those dissimilar users
from which recommendations could be made. But those aren't, likely,
good recommendations.

This is why I believe it's not in general a good idea to construct,
for each item, *some* neighborhood that finds that items and predict
from there. I can't say I've tested that claim though.

But what the Herlocker paper suggests, and I agree with, is that using
threshold-based definitions of neighborhoods is a good idea. And then
I think that the practical difference between constructing one
neighborhood and getting candidate items from there, versus
constructing a neighborhood for every item, is probably small. Again,
haven't tested that claim directly.

That's why I think the current implementation is OK, and at least
innocent until proven guilty, and why I also believe that this is the
canonical approach as well.

Re: A question regarding GenericUserBasedRecommender

[Yanir Seroussi <ya...@gmail.com>]

On Tue, Aug 10, 2010 at 15:54, Sean Owen <sr...@gmail.com> wrote:

> On Mon, Aug 9, 2010 at 6:46 PM, Yanir Seroussi <ya...@gmail.com>
> wrote:
> > As I see it, there are two separate tasks here. The first one is the
> > recommendation task, where it makes sense to take the N most similar
> users
> > and generate recommendations based on their preferences. The second one
> is
> > the rating prediction task (or preference estimation in Mahout terms),
> where
> > given a target user and a target item the recommender generates a
> prediction
> > of the rating for the item. In the way
>
> They are related tasks. Estimating preferences is *a* way to achieve
> the further goal of recommending items. It is how just about all
> algorithms work, so I'd say that in practice estimating preference is
> a sub-task of recommendation, and really the core of it.
>
>
Agreed.


> > GenericUserBasedRecommendation.estimatePreference() is implemented now,
> it
> > can only generate predictions for very few items unless the neighbourhood
> > size is very large.
>
> I don't think this is necessarily true. Sparse data can mean users are
> hard to connect to other users, or that those connections yield few
> candidates for recommendations, sure. A large neighborhood doesn't
> help this though. If there isn't 1 "nearby" user, there aren't 100
> either.
>
> But, crudely, I think your data has to be "really really sparse"
> before you frequently can't recommend anything at all.
>
> I don't believe it's a question of implementation. This is simply what
> user-based recommendation is.
>
>
As it is now, GenericUserBasedRecommendation.estimatePreference() can only
estimate preferences of items that were rated by users in the static
neighbourhood. Thus, a larger neighbourhood is likely to contain more
neighbours that rated unknown items. For example, if we take only one
neighbour, we can only estimate preferences of items that this neighbour
rated.


>
>
> > To make this concrete, I'll give an example. Suppose we choose N=20, and
> we
> > want to predict the rating of the target user for the movie The
> Godfather.
> > This movie was rated by many users in the dataset, but unfortunately it
> > wasn't rated by the 20 users that are most similar to the target user.
> Thus,
> > estimatePreference() will return NaN as the prediction.
>
> That's right. There would be no basis for estimating a preference.
>
>
> > Now suppose that these top 20 users have a similarity of 1 to the target
> > user, and that the next 20 users have a similarity of 0.99 to the target
> > user, and they have all rated The Godfather. It would make sense to
> generate
> > a rating prediction based on the next 20 users, and this prediction is
> > actually likely to be pretty good.
>
> True, and if this were the case, I'd suggest that you want to define
> the neighborhood by a similarity threshold, not by size. Let everyone
> with similarity >= 0.9 or something be in the neighborhood.
>
>
> > As I mentioned in my original message, it is implied from Herlocker et al
> > (1999) that the number of neighbours shouldn't affect coverage. Another
> > widely cited paper, by Adomavicius and Tuzhilin (2005, see
> >
> http://ids.csom.umn.edu/faculty/gedas/papers/recommender-systems-survey-2005.pdf
> ),
> > actually states that explicitly: "That is, the
> > value of the unknown rating r(c, s) for user c and item s is usually
> > computed as an aggregate of the ratings of some other (usually the N most
> > similar) users for the same item s: r(c, s) = aggr(c' in C^, r(c', s))
> where
> > C^ denotes the set of N users that are the most similar to user c and who
> > have rated item s (N can range anywhere from 1 to the number of all
> users)."
> >
> > While Sean's approach is probably also okay, especially for the
> > recommendation scenario, I think it's worthwhile documenting the fact
> that
> > this behaviour is somewhat inconsistent with the literature.
>
> As (I think) you say, it's consistent with Herlocker -- this is just
> plain-vanilla user-based recommendation.
>
> The other approach you cite makes sense but gets a lot more expensive
> to compute. You need a new neighborhood for every candidate item. It
> is also, in my world view, not the plain-vanilla approach that has
> become called "user-based recommendation". So, no I do not find this
> inconsistent.
>

No, I'm not saying that it's consistent with Herlocker et al. They say in
section 6 that "The second technique is to pick the best n correlates for a
given n. This technique performs reasonably well, as it does not limit
prediction coverage". The fact that no matter what n you choose, your
coverage remains the same, means that the n users are dependent on the
target item. Also, in section 2 of the paper, they say that the second step
in generating a prediction is "select a subset of users to use as a set of
predictors (possibly for a specific item)". The other neighbourhood
selection technique they experimented with was setting similarity threshold,
which did affect coverage, as it is not item-specific. Putting all of this
together strongly suggests that the nearest-n approach they were referring
to is the item-specific one.

In addition, the paper I cited is a survey of recommender systems, and was
cited more than 1000 times (according to Google Scholar), which means that
probably quite a few people actually see the non-static neighbourhood as
plain-vanilla user-based recommendation.

I agree that the non-static approach is more expensive to compute in Mahout.
But if we disregard the way it is implemented at the moment, it doesn't
necessarily have to be expensive, because we have to compute the
similarities of the target user to all other users in any case. So if we
were to keep a sorted list of these similarities, generating a prediction
for an item would only consist of taking the top-n users in the list that
rated the item. However, it would probably require big changes in Mahout, so
it's probably better to leave it as-is and just let users know of this
issue.

Re: A question regarding GenericUserBasedRecommender

[Sean Owen <sr...@gmail.com>]

On Mon, Aug 9, 2010 at 6:46 PM, Yanir Seroussi <ya...@gmail.com> wrote:
> As I see it, there are two separate tasks here. The first one is the
> recommendation task, where it makes sense to take the N most similar users
> and generate recommendations based on their preferences. The second one is
> the rating prediction task (or preference estimation in Mahout terms), where
> given a target user and a target item the recommender generates a prediction
> of the rating for the item. In the way

They are related tasks. Estimating preferences is *a* way to achieve
the further goal of recommending items. It is how just about all
algorithms work, so I'd say that in practice estimating preference is
a sub-task of recommendation, and really the core of it.

> GenericUserBasedRecommendation.estimatePreference() is implemented now, it
> can only generate predictions for very few items unless the neighbourhood
> size is very large.

I don't think this is necessarily true. Sparse data can mean users are
hard to connect to other users, or that those connections yield few
candidates for recommendations, sure. A large neighborhood doesn't
help this though. If there isn't 1 "nearby" user, there aren't 100
either.

But, crudely, I think your data has to be "really really sparse"
before you frequently can't recommend anything at all.

I don't believe it's a question of implementation. This is simply what
user-based recommendation is.



> To make this concrete, I'll give an example. Suppose we choose N=20, and we
> want to predict the rating of the target user for the movie The Godfather.
> This movie was rated by many users in the dataset, but unfortunately it
> wasn't rated by the 20 users that are most similar to the target user. Thus,
> estimatePreference() will return NaN as the prediction.

That's right. There would be no basis for estimating a preference.


> Now suppose that these top 20 users have a similarity of 1 to the target
> user, and that the next 20 users have a similarity of 0.99 to the target
> user, and they have all rated The Godfather. It would make sense to generate
> a rating prediction based on the next 20 users, and this prediction is
> actually likely to be pretty good.

True, and if this were the case, I'd suggest that you want to define
the neighborhood by a similarity threshold, not by size. Let everyone
with similarity >= 0.9 or something be in the neighborhood.


> As I mentioned in my original message, it is implied from Herlocker et al
> (1999) that the number of neighbours shouldn't affect coverage. Another
> widely cited paper, by Adomavicius and Tuzhilin (2005, see
> http://ids.csom.umn.edu/faculty/gedas/papers/recommender-systems-survey-2005.pdf),
> actually states that explicitly: "That is, the
> value of the unknown rating r(c, s) for user c and item s is usually
> computed as an aggregate of the ratings of some other (usually the N most
> similar) users for the same item s: r(c, s) = aggr(c' in C^, r(c', s)) where
> C^ denotes the set of N users that are the most similar to user c and who
> have rated item s (N can range anywhere from 1 to the number of all users)."
>
> While Sean's approach is probably also okay, especially for the
> recommendation scenario, I think it's worthwhile documenting the fact that
> this behaviour is somewhat inconsistent with the literature.

As (I think) you say, it's consistent with Herlocker -- this is just
plain-vanilla user-based recommendation.

The other approach you cite makes sense but gets a lot more expensive
to compute. You need a new neighborhood for every candidate item. It
is also, in my world view, not the plain-vanilla approach that has
become called "user-based recommendation". So, no I do not find this
inconsistent.

Re: A question regarding GenericUserBasedRecommender

[Yanir Seroussi <ya...@gmail.com>]

I'll try to explain the problem again, but note that at this stage I'm
trying to establish a user-based collaborative recommendation baseline,
rather than getting the best performance I can get for a given dataset, so
while the suggestions are appreciated I'd like to focus on
GenericUserBasedRecommender with NearestNUserNeighborhood.

As I see it, there are two separate tasks here. The first one is the
recommendation task, where it makes sense to take the N most similar users
and generate recommendations based on their preferences. The second one is
the rating prediction task (or preference estimation in Mahout terms), where
given a target user and a target item the recommender generates a prediction
of the rating for the item. In the way
GenericUserBasedRecommendation.estimatePreference() is implemented now, it
can only generate predictions for very few items unless the neighbourhood
size is very large.

To make this concrete, I'll give an example. Suppose we choose N=20, and we
want to predict the rating of the target user for the movie The Godfather.
This movie was rated by many users in the dataset, but unfortunately it
wasn't rated by the 20 users that are most similar to the target user. Thus,
estimatePreference() will return NaN as the prediction.
Now suppose that these top 20 users have a similarity of 1 to the target
user, and that the next 20 users have a similarity of 0.99 to the target
user, and they have all rated The Godfather. It would make sense to generate
a rating prediction based on the next 20 users, and this prediction is
actually likely to be pretty good.

As I mentioned in my original message, it is implied from Herlocker et al
(1999) that the number of neighbours shouldn't affect coverage. Another
widely cited paper, by Adomavicius and Tuzhilin (2005, see
http://ids.csom.umn.edu/faculty/gedas/papers/recommender-systems-survey-2005.pdf),
actually states that explicitly: "That is, the
value of the unknown rating r(c, s) for user c and item s is usually
computed as an aggregate of the ratings of some other (usually the N most
similar) users for the same item s: r(c, s) = aggr(c' in C^, r(c', s)) where
C^ denotes the set of N users that are the most similar to user c and who
have rated item s (N can range anywhere from 1 to the number of all users)."

While Sean's approach is probably also okay, especially for the
recommendation scenario, I think it's worthwhile documenting the fact that
this behaviour is somewhat inconsistent with the literature.

On Tue, Aug 10, 2010 at 00:32, Sean Owen <sr...@gmail.com> wrote:

> This is expected behavior as far as I understand the algorithm. I
> don't see how a user-based recommender can estimated a preference by X
> for Y if nobody who rated Y is connected to X at all.
>
> You can use a PreferenceInferrer to fill in a lot of missing data, but
> I don't really recommend this for more than experimentation.
>
> The issue here is mostly that the user-item matrix is too sparse. And
> yes there are load of follow-up suggestions that tackle that,
> depending on your data, as alex hinted at.
>
> On Mon, Aug 9, 2010 at 3:31 AM, Yanir Seroussi <ya...@gmail.com>
> wrote:
> > Hi,
> >
> > The first example here (
> >
> https://cwiki.apache.org/confluence/display/MAHOUT/Recommender+Documentation
> )
> > shows how to create a GenericUserBasedRecommender with a
> > NearestNUserNeighborhood. My problem/question is that setting n to any
> small
> > number seems to limit the coverage of the recommender, because the
> nearest n
> > users are calculated without taking the target item into account.
> > For example, given a user X and n = 10, if we want to
> estimatePreference()
> > for an item Y, if this item is not rated by any user in the
> neighbourhood,
> > the prediction will be NaN. I don't think that this is what one would
> expect
> > from a user-based nearest-neighbour recommender, as Herlocker et al.
> (1999),
> > who are cited in the example page above, didn't mention any change in
> > coverage based on the number of nearest neighbours.
> > Am I doing something wrong, or is this the way it should be? I have a
> > feeling it is not the way it should be, because then using small
> > neighbourhood sizes makes no sense as it severely restricts the ability
> of
> > the recommender to estimate preferences.
> >
> > Please note that I observed this behaviour in version 0.3, but it seems
> to
> > be the same in the latest version.
> >
> > Cheers,
> > Yanir
> >
>

Re: A question regarding GenericUserBasedRecommender

[Sean Owen <sr...@gmail.com>]

This is expected behavior as far as I understand the algorithm. I
don't see how a user-based recommender can estimated a preference by X
for Y if nobody who rated Y is connected to X at all.

You can use a PreferenceInferrer to fill in a lot of missing data, but
I don't really recommend this for more than experimentation.

The issue here is mostly that the user-item matrix is too sparse. And
yes there are load of follow-up suggestions that tackle that,
depending on your data, as alex hinted at.

On Mon, Aug 9, 2010 at 3:31 AM, Yanir Seroussi <ya...@gmail.com> wrote:
> Hi,
>
> The first example here (
> https://cwiki.apache.org/confluence/display/MAHOUT/Recommender+Documentation)
> shows how to create a GenericUserBasedRecommender with a
> NearestNUserNeighborhood. My problem/question is that setting n to any small
> number seems to limit the coverage of the recommender, because the nearest n
> users are calculated without taking the target item into account.
> For example, given a user X and n = 10, if we want to estimatePreference()
> for an item Y, if this item is not rated by any user in the neighbourhood,
> the prediction will be NaN. I don't think that this is what one would expect
> from a user-based nearest-neighbour recommender, as Herlocker et al. (1999),
> who are cited in the example page above, didn't mention any change in
> coverage based on the number of nearest neighbours.
> Am I doing something wrong, or is this the way it should be? I have a
> feeling it is not the way it should be, because then using small
> neighbourhood sizes makes no sense as it severely restricts the ability of
> the recommender to estimate preferences.
>
> Please note that I observed this behaviour in version 0.3, but it seems to
> be the same in the latest version.
>
> Cheers,
> Yanir
>