mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Webster <>
Subject Re: Recommender system implementations
Date Thu, 21 Oct 2010 03:50:48 GMT
I wasn't part of the arguing about and settling on this, but I still 
think it's the right behavior.  Firstly, the point of a recommender is 
to maximize accuracy, so it makes sense to return the true rating if 
it's known.  Secondly, the only time when actualPref would be non-null 
is when you're testing on your training data; in any valid test, the 
data points would be unseen and thus actualPref would always be null. 
So I think that code is just there for real-world cases when you have to 
display predicted ratings for any available item, not just items from 
the test block, in which case you want to display the user's actual 
rating for items that the user has rated.

But more to the point, the only time there might be true ratings
On 10/21/10 10:56 AM, Lance Norskog wrote:
> Since this is Recommender day, here is another kvetch:
> The recommender implementations with algorithms all do this in
> Recommender.estimatePreference():
>   public float estimatePreference(long userID, long itemID) throws
> TasteException {
>      DataModel model = getDataModel();
>      Float actualPref = model.getPreferenceValue(userID, itemID);
>      if (actualPref != null) {
>        return actualPref;
>      }
>      return doEstimatePreference(userID, itemID);
>    }
> Meaning: "if I told you something, just parrot it back to me."
> Otherwise, make a guess.
> I am doing head-to-head comparisons of the dataModel preferences v.s.
> the Recommender. This code makes it impossible to directly compare
> what the recommender thinks v.s. the actual preference. If I wanted to
> know what I told it, I already know that. I want to know what the
> recommender thinks.
> If this design decision is something y'all have argued about and
> settled on, never mind. If it is just something that seemed like a
> good idea at the time, can we change the recommenders, and the
> Recommender "contract", to always use their own algorithm?
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message