mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <>
Subject Re: What is content based recommendation, to you
Date Wed, 27 Jan 2010 22:27:15 GMT
On Wed, Jan 27, 2010 at 2:15 AM, Jake Mannix <> 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

View raw message