Good explanation, this is kind of what I was trying to do by making assumptions from user preferences and returning the intersection of those with the item similarity list. Yes I also think this would be a valuable addition.
Sent from my iPhone On Jan 30, 2012, at 2:26 AM, Anatoliy Kats <[email protected]> wrote: > It stands to reason that if you click on an Amazon book description, you > should be offered to buy it next time. Amazon certainly does. I see Sean's > point, in a pure form a recommender should only recommend unknown items. > Certainly that's the behavior you need in a theoretical test framework. I > think where we differ is that some people here build systems where ratings > are computed from user behavior, and therefore decoupled from the set of > candidate items. I understand this is not Mahout's original purpose, and > that it's difficult to build this support into Mahout in a principled way. > But it would be helpful to some of us if Mahout had that capability. I > accomplished it by wrapping my own recommender class around Mahout's > delegate, overriding estimatePreference(), and using a CandidateSimilarity > that allows previously rated items. Perhaps a more acceptable solution is > adding a post-recommendation processing step that combines the recommendation > result with a set of userChoosableRecommendedItems, and returns the top N > items from that combined list. This design intrudes a lot less into Mahout's > internals. > > Would anyone else benefit from this addition? > > On 01/29/2012 12:33 AM, Ted Dunning wrote: >> Also, Lee, I think you have it backwards. It is true that clicks are not >> the same thing as preferences, but I don't think that I give a fig about >> preferences since they are the internal mental state of the visitor. I >> know that some of the visitors are mental, but I don't really care since >> that is their own business. What I care about is encouraging certain >> behaviors. >> >> So I find that mental state estimations are the indirect way to model and >> predict behaviors while directly modeling behaviors based on observed >> behaviors is, well, more direct. >> >> This is compounded by the fact that asking people to rate things invokes a >> really complicated social interaction which does not directly sample the >> internal mental state (i.e. the real preference) but instead measures >> behavior that is a very complicated outcome of social pressures, >> expectations and the internal mental state. So using ratings boils down to >> using one kind of behavior to estimate mental state that then is >> hypothesized to result in the desired second kind of behavior. >> >> >> >> On Sat, Jan 28, 2012 at 10:51 AM, Sean Owen<[email protected]> wrote: >> >>> It means *something* that a user clicked on one item and not 10,000 others. >>> You will learn things like that Star Wars and Star Trek are somehow related >>> from this data. I don't think that clicks are a bad input per se. >>> >>> I agree that it's not obvious how to meaningfully translate user actions >>> into a linear scale. "1" per click and "10" for purchase or something is a >>> guess. I do think you will learn something from the data this way. >>> >>> There is nothing conceptually wrong with mixing real data and estimated >>> data. If the results aren't looking right, it is not a problem with the >>> concept, but the mapping of action onto some rating scale. I think it's >>> hard to get that right, but is not impossible to get it "good". >>> >>> On Sat, Jan 28, 2012 at 10:15 AM, Lee Carroll >>> <[email protected]>wrote: >>> >>>>> I would argue, though, that .recommend() is aimed at the latter task: >>>> No . I think the mismatch here is you are using at best a wild guess >>>> at a preference for the convenience of using a recommender and then in >>>> the same breath expecting the recommender to "understand" that you are >>>> not using preferences at all and actually have no idea what the user >>>> preference is. You cant have it both ways :-) >>>> >>>> A click through on an item is not a measure of user preference for >>>> that item. I know its not what you want to hear (or better what your >>>> business users want to here) but there it is. >>>> >>>> We can pretend, or maybe even build a convincing narrative that a >>>> click is some sort of item association and use that as a proxy >>>> preference and we might even get some mileage out of it, but we should >>>> not change the behaviour of the .recommend() to hide its short >>>> comings. >>>> > >
