Why You Should Not Build a Recommendation Engine • Hacker News Board

Re: Why You Should Not Build a Recommendation Engine

#11

Post by numlocked » Sun, Mar 08, 2015, 4:35 PM UTC

solve wrote: post #4

Directly giving the users predictions that are based on latent factors has a huge problem -- is there ever really a case where the latent factors have very high prediction ability, but an analyst can't simply see what's driving the preferences by looking at those factors, and then create something better by targeting that interaction directly? Better to analyze the latent factors, and then use that analysis to gain e…

Is this true? Really interesting. Any links to write ups from Netflix on how their approach has shifted? Or other big guys?

Re: Why You Should Not Build a Recommendation Engine

#12

Post by muglug » Sun, Mar 08, 2015, 4:41 PM UTC

Title is a fudge – the article should really be titled "Why you should not build a recommendation engine unless you have lots of existing users and vast amount of content". That message is a lot more common-sensical, from a stats perspective.

Re: Why You Should Not Build a Recommendation Engine

#13

Post by muglug » Sun, Mar 08, 2015, 4:41 PM UTC

Title is a fudge – the article should really be titled "Why you should not build a recommendation engine unless you have lots of existing users and vast amount of content". That message is a lot more common-sensical, from a stats perspective.

Re: Why You Should Not Build a Recommendation Engine

#14

Post by graycat » Sun, Mar 08, 2015, 4:48 PM UTC

Nonsense. The OP sets up a straw man just to knock it down. The descriptions of recommendation engines are naive, uninformed, narrow, and not at all comprehensive.

What can be done with good applied math for making recommendations has variety nearly beyond belief; the approaches outlined by the OP are, of course, just silly.

For the cold start problem, that need not be very difficult -- just start in niches.

Re: Why You Should Not Build a Recommendation Engine

#15

Post by leereeves » Sun, Mar 08, 2015, 4:58 PM UTC

biomimic wrote: post #8

Algorithmic Recommendation system builder here. I would include recommendation systems based on 'human generated lists'. See: http://www.google.com/patents/US8108417 I have developed these and they are far more powerful and relevant to the subjective user tastes involved with light-weight approaches related to collaborative filtering. An ensemble approach is absolutely the best while also keeping in mind that one use…

Should you use an algorithm that appears to be protected by a patent?

Re: Why You Should Not Build a Recommendation Engine

#16

Post by biomimic » Sun, Mar 08, 2015, 5:08 PM UTC

leereeves wrote: post #15

biomimic wrote: post #8

Algorithmic Recommendation system builder here. I would include recommendation systems based on 'human generated lists'. See: http://www.google.com/patents/US8108417 I have developed these and they are far more powerful and relevant to the subjective user tastes involved with light-weight approaches related to collaborative filtering. An ensemble approach is absolutely the best while also keeping in mind that one use…

Should you use an algorithm that appears to be protected by a patent?

Many things can be learned from what's inside Google, Apple, IBM patents. Learn from what inside patents. It's a great way to spark ideas as opposed to going in blind.

Re: Why You Should Not Build a Recommendation Engine

#17

Post by ffn » Sun, Mar 08, 2015, 5:55 PM UTC

In more mathematical terms, the value a rec engine provides you looks like:

value = k1 * users + k2 * products + k3 * products * users

Prioritize building your rec engine feature after you've built user on-boarding features and product on-boarding features because without users and products, rec engines contribute 0 value.

Re: Why You Should Not Build a Recommendation Engine

#18

Post by dmichulke » Sun, Mar 08, 2015, 6:54 PM UTC

If someone told me to build a recommendation engine, I'd basically use a knn-approach.

You'd need to define

- a similarity measure for users (based on, e.g., what they bought and what they looked at) and

- you just recommend the top items the k nearest users bought (weighted by distance), possibly subtracted by the items already bought by the user in question and cleaned from explicit items.

Of course, the system would start really bad but it would get gradually better. This doesn't sound too complicated nor too simplistic nor "heavy data science".

Unfortunately there are no real technical insights in the article justifying why I shouldn't do this, so anyone can tell me why my approach would be bad or good?

Re: Why You Should Not Build a Recommendation Engine

#19

Post by nitwit005 » Mon, Mar 09, 2015, 12:28 AM UTC

I have to disagree with the definition: "A recommendation engine is a feature (not a product) that filters items by predicting how a user might rate them."

The feature bit is correct, but the rating bit might not be. People very often give high ratings to things they are not interested in. People may highly rate jewelry that they cannot afford, or give a five star rating to a movies considered classics, that they don't actually want to view.

What you are trying to optimize is ultimately purchasing, continued subscription, ad views, or some other profit metric. That can be hard to directly measure, so something like ratings can be a stand in, but you may accidentally optimize for something deeply undesirable like recommending expensive jewelry to everyone that they will never buy.