Hi, thank you for your answers. I understand now why there is no built-in "adjusted cosine similarity" :) Unfortunately though, my question still stands - if I had to implement an "adjusted cosine similarity", how would I do it? For sake of simplicity I'll move the discussion to my other question "fast performance way of writing preferences to file?" and I'll explain there why I have to do it (or at least I *think* I have to do it). Looking forward to hearing from you in my other discussion, and thank you again (I'll reply on the other thread in a few minutes).
Pier Lorenzo -------------------------------------------- On Fri, 4/3/15, Pat Ferrel <p...@occamsmachete.com> wrote: Subject: Re: adjusted cosine similarity for item-based recommender? To: "user@mahout.apache.org" <user@mahout.apache.org> Date: Friday, April 3, 2015, 6:05 PM I’d add that overview and references are here: http://mahout.apache.org/users/algorithms/recommender-overview.html There are many benefits to this architecture including being able to make recs to anonymous users (as long as you have a little history for them) no need to retrain the recommender. The server is a fast scalable search engine and so the multimodal part is accessed by changing the query, which also means you can use context in realtime. Like what category you want recs to favor or be filtered by. In a cooccurrence recommender ratings are ignored. You want to gather history of some user action that is as close to the intended action you want to recommend. For ecom that’s probably purchase, for movies it might be a full movie view. The quality of this action is important. For an example movie recommender check the demo app, which uses most of the techniques mentioned in the references; https://guide.finderbots.com On Apr 3, 2015, at 8:48 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: For practical recommendation systems, ratings are almost irrelevant. Ratings were prominent in the original academic work on recommendations largely because with the early research systems, users had no recordable interactions with content other than ratings. The Taste component of Mahout was written largely by following that literature. In fact, in a real world system, this turns out to be very wrong. Ratings are a very poor source of recommendation information in most real applications for two reasons: 1) interpretation is hard (your issues with bias are just the beginning) 2) volume is very low because most (often >>99%) users don't rate If you are building a production recommender you should be looking at indicator-based techniques and moving to multi-modal recommendations. The code in question was deprecated precisely because it has little practical impact. On Fri, Apr 3, 2015 at 3:36 AM, PierLorenzo Bianchini < piell...@yahoo.com.invalid> wrote: > hello everyone, > I'm trying to build item-based recommender that would take the users' > rating-bias into account. According to my class' slides, that should > involve "adjusted cosine similarity". I couldn't find such implementation > in Mahout... did I search it in the wrong place or should I implement it? > If so, how? Any tips would be welcome since I'm new to Mahout... > > I found out that in mahout-0.8 there was a (deprecated) class that seemed > to do what I'm looking for ( > http://archive.cloudera.com/cdh5/cdh/5/mahout-0.8-cdh5.0.0/mahout-core/org/apache/mahout/cf/taste/impl/recommender/BiasedItemBasedRecommender.html). > Does anybody know why this was removed? > > Note: I also posted the question on stackoferlow ( > http://stackoverflow.com/questions/29419222/mahout-adjusted-cosine-similarity-for-item-based-recommender > ) > Thank you in advance! Regards, > > Pier Lorenzo >
