Inline ... slightly redundant relative to other answers, but that shouldn't be a problem.
On Mon, Jul 22, 2013 at 11:56 AM, Gokhan Capan <gkhn...@gmail.com> wrote: > Just to make sure if I understood correctly, Ted, could you please correct > me?:) > > > 1. Using a search engine, I will treat items as documents, where each > document vector consists of other items (similar to "words of documents") > with co-occurrence (LLR) weights (instead of tf-idf in a search engine > analogy). > LLR will just select indicators. Weighting can be done using native TF-IDF stuff that Solr already does. > So for each item I will have a sparse vector that represents the relation > of that item to other items, if there is an indicator that makes the > item-to-item similarity (co-occurrence) non-zero. (I will only use positive > feedback, I think, since I am counting co-occurrences) > Yes. Moreover, there will ultimately be multiple fields with different sets of indicators. This is how cross recommendation can be integrated. > > 2. To present recommendations, the system formulates a "query", with a > history of items --the session history for task based recommendation, or a > long term history. And the search engine will find top-N items, based on > the cosine similarities of the item (document) vectors and history (query) > vectors. > Yes. Cosine-ish ... the search engine has its own similarity calculation. That can be tuned ... later. > > 3. For example, if that was a restaurant recommendation, and we knew that > the restaurant was famous for its sushi, I would index this in another > field, "famous_for". > Now if, as a user, I asked for sushi restaurants that I would enjoy, the > system would add this to query along with my history, and the famous sushi > restaurant would rank higher in results, even if chances are equal that I > would like a steakhouse according to the computation in 2. > Yes. Moreover, we might put all the words in the descriptions of restaurants you have been to lately into a different history field. Each restaurant would also have an "indicator word" field against which we could query using your history words. Similarly, we could use cuisine classifiers. And we can compute a "local favorite" feature that is essentially a recommendation indicator from people in a particular area to restaurants. Recommendation queries can include any or all of these. Specialized pages might have a cuisine specific recommendation set for you. > > 4. Since this is a search engine, and a search engine can boost a > particular field, the system would let the "famous_for" overweigh the > collaborative activity, or the opposite (According to the use case, or for > example, number of items in the history) So I can define a weighting > (voting, or mixture of experts) scheme to "blend" different recommenders. > yes. I would recommend doing the blending in the search engine query itself. > Are those correct? > Pretty much!
