On Wed, Jan 27, 2010 at 2:15 AM, Jake Mannix <jake.man...@gmail.com> wrote: > There is no need (although there may be much *utility*) in ever thinking > about > interactions between items (item-item similarity) or users. Content-based > recommendations can act purely as a generalized search engine, where the > trick is just coming up with the search terms / query features to use for > each user.
Yes, you're right, if I understand your meaning correctly. I think that content-based recommendation of this form is not really a conventional recommender system. It smells much more like a search problem. I like attributes X Y and Z, so recommend me me items with attributes X Y and Z: call 'attributes' as 'search terms' and 'items' as 'search results' and yup, it's search. No real ratings here. So I suppose I am resisting implementing this as a recommender system since it's well in hand from search frameworks, but I'm not sure how valid that is. > * on webpage (type W), you have certain set of features, and users come to > that > webpage, sometimes with no prior history, so if you want to recommend > (serve) > ads (type A) to the user, recommending based purely on some kind of > content-based > correlation between items of type W and A can work. Alrighty so users are webpages (W) and items are ads (A) and you're recommending ads to webpages. And you intend to use the text of W and A to recommend? Yup, that's valid, but smells like search, and something a search framework would do well on. I would say: figure out which Ws 'prefer' which As based on clicks, and maybe base ad recommendations on textual similarity between As. That's a(n item-based) recommender. > In both of these cases, you can do a full-fledged recommendation engine with > no > users whatsoever, with content and item information across multiple domains. I think you hit the key advantage of not relying on preferences here. I guess I'm contending that without preferences, it's properly in the domain of search instead of recommendation (where I typically mean 'collaborative filtering' by this term) > The other advantage of thinking of content-based recommender systems this > way > is that now you have an entirely new axis to think about: CF goes one way, > and > content-based "searching" goes another, and there is an entire spectrum of > "fusion" > models which mix the two. Well there's no reason that a recommender framework shouldn't support search-like approaches. I have convinced myself that what I have on my hands is really a collaborative filtering framework. I think it's somewhere on the roadmap, therefore, to expand into these other techniques.
