推荐系统的坑2

转自：http://www.wangke.me/?p=173

推荐系统的坑(2)

标准

上一篇《推荐系统的坑》主要讲了产品思路方面的坑，这一次，讲一讲做这个过程中的坑。这个坑，更坑。

第一坑，轻“效果”；

“推荐系统是解决互联网海量信息资源出现信息过载问题的方法…”如同日本片子开头的那个黑色的文字序幕，我已经看到不下六百篇介绍推荐系统的文章用了这个开头。可能这个开头如此广泛的存在让人误以为只要做了个推荐系统就能用来解决“信息过载”。殊不知要是效果不好（或者产品设计的方案不好），系统本身就是噪声信息的来源。用户避之唯恐不及，还特么解决人家的问题。

第二坑，轻“迭代”。

找到韩剧里面的白马王子，高富帅暖专一有腹肌然后嫁了。找个“牛人”把经验搬来，然后问题便迎刃而解了。找到Paper里面最牛逼方案，实现后效果便天下无敌了。都是春梦。

一个小数据集合，一个产品场景，一个评测指标一个推荐算法，可以有多少种具体实现方案呢？我上一篇博客《UserBased CF Optimization using Dimension Reduction》给出例子：几十种，而这显然远非全部。在具体场景与业务逻辑上，这样的变换会有多少？有牛人坐镇有大量开放资料是奢侈而宝贵的，但经验毕竟不可照办，资料只能参照，根据当下的产品场景具体分析，并且必须要不停的尝试。

是的，尝试。要重视搭建监控，重视数据分析，创造让效果“成长”的土壤，好的算法不是仅仅是设计出来的，好的方法是依托于迭代环境，不停尝试出来的。

第三坑，轻“设计”；

所有的方法都能“迭代”出来吗？达尔文在《物种起源》一书的第六章《理论的难题》的“极其完美和复杂的器官”这一节中，写到，‘眼睛有调节焦距、允许不同采光量和纠正球面象差和色差的无与伦比的设计。我坦白地承认，认为眼睛是通过自然选择而形成的假说似乎是最荒谬可笑的。’”。

可见进化也有局限，部分情况下，要突破，还是要好好设计，打破框架的束缚。

第四坑，轻“数据”；

推荐系统好比是皮条客。把大家看不到的，但有可能喜欢的结果给出来让用户选择。推荐系统多数要解决个性化问题，也就是，一个人喜欢长腿的，另一个可能喜欢大胸的。无法用产品经理或者任何人的感性认识去彻底理解系统，因为他代表不了“用户”，唯有通过数据分析，去“理性”的度量它。在推荐系统这个场景下，千万不要听小龙哥的，认为数据分析不重要，他不是说了吗，他所说的都是特么错的。

数据分析不能停止，由浅入深，积少成多，产品方向会越来越明确。

值得一提的是，数据分析不出彩，不高大上，任何职能可能都觉得不是份内之事，产品经理又搞不定线上，容易变成三不管地带。而配备一个分析师又太奢侈了，我们项目组，最后就我这个代码能力差也搞不出啥高大上东西的土包子管了。

第五坑，轻“协作”；

“协同过滤”究竟是一个算法呢，还是一个架构方式，还是一个产品方案？说它是一个算法，但是它决定了架构做什么，也决定了结果怎么出，也就是说它也一定程度上刻画了业务逻辑，决定了一大半产品方案。真是傻傻分不清楚。

另外，见过两个一样的推荐系统吗？少。看看各大公司的推荐架构，差异较大。关键在于方法，业务，数据等等均不一样。

对于推荐系统，分工是困难的，协作的难度更高，所以要求也更高，如何协作？目标一致，且团队要小。

第六坑，轻任何一个“职能”。

效果取决于哪些东西？系统架构，算法策略，业务逻辑，UI界面等等。算法很重要，但系统架构是算法的载体，业务逻辑为算法勾勒框架，UI的重要性自不用说。这几条腿任何一条短了，跑不快。

另外，推荐系统是个强技术驱动的东西，但是让产品经理处于核心位置依然必要，保底用于保证业务导向，优秀的话，产品经理应该去找到不同时间分布在各个职能上最有价值做的环节，也知道部分主导权，在合适时候还是要给技术的。

“方法论”不难找，可以说，三观正，没有对旧有经验的惯性，没有强烈的利益争夺，有一些见识之人的团队不会在这方面犯错误。多数人，本篇博客当个废话听听好了。