I guess another way that I think of it is that CF is actually a very special case of recommendation: you have generic items and users, and withou knowing anything about the content of the items (or items), you can use ratings to predict unknown preferences.
The general case is that you have users, items, and you DO know something about the attributes of the items and users. Then you could try to do "untrained recommendation" ie search, but better is to use explicit ratings to do feature selection and feature weighting. I'm not sure how that fits best with Taste, but that's the hierarchy of recommenders I see... -jake On Jan 27, 2010 2:51 PM, "Jake Mannix" <jake.man...@gmail.com> wrote: On Wed, Jan 27, 2010 at 2:27 PM, Sean Owen <sro...@gmail.com> wrote: > > On Wed, Jan 27, 2010 at 2:1... But how is "presence of term X in both item1 and user1" as a boolean preference value any different than "user1 has a preference for attribute(X)"? Similarly, tf-idf weightings provide a floating point "rating" for correlations between different item types. The reason why I think this kind of recommender is not so strange is that you can group together attributes into fields / column-families, and while presence/absence (or tf-idf, or whatever) can act as raw ratings, you can then add in arbitrary model weights *between* fields which are *learned* by feedback (use logistic regression, for example) from the user-item ratings table. Does that make sense? > > So I suppose I am resisting implementing this as a recommender system > since it's well in ha... It *exists* as a search setup, but at least in e.g Lucene, it's not designed to do this, really, and there are lots of hacks you have to do (the normalization is wrong, the dot product isn't really cosine, you have to work to make it into tanimoto/etc). And search setups aren't really designed to do batch recommendations of this kind either. Trust me, you can do this with search, and sometimes its a good idea, but it's kindof a kludge, and it's not at all straightforward (but the goal is a totally valid one!). > > > > > * on webpage (type W), you have certain set of features, and users come to > > that > ... But what you're suggesting here is one particular choice of solution - it's presupposing that that one is the best. Why not say: similarity(W,A) = alpha_0 * (W_title * A_title) + alpha_1 * (W_header * A_title) + alpha_2 * (W_subHeader * A_body) + alpha_3 * (W_tags * A_landingURL) + ... and then train your alpha_i to optimize clickthrough? > > Well there's no reason that a recommender framework shouldn't support > search-like approach... Why should we limit ourselves to just a CF framework? Why not a recommendation framework which can easily do both? -jake
