寻路推荐豆瓣推荐系统实践之路

36大数据 • 9年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

文|稳国柱（文章来自不周山）

两年多前，我在阿里技术沙龙讲了一个名为 “寻路推荐”的topic ，介绍了自己在豆瓣时代做的几个典型案例，属于比较务实的一个topic，自己把它定位为“实践篇”。随后一直想整理一个务虚版的“理念篇”，作为前置于“执行”的“思辨”过程，顺便把自己的寻路历程补充完整。

来到阿里这大半年，无论技术层面还是产品/业务层面，与前厂对比都非常强烈，也极大地刺激了自己的思维。感谢豆瓣给了我独立思考的空间和充分实践的土壤，感谢阿里给了我阅历上的增长，很多想法在这半年里开始成形。适逢@仁基再次邀请我去他的团队做个分享，也不希望带着“负债”离开，就找时间做了个阶段性总结。本来想小规模低调一点，不料会后不少同学得知后强烈要求加场。实在口干舌燥无力再战，就在lastday把分享会上那些尚未完全成熟的观点整理一下，写了下来。

产品与算法

推荐系统
这张图想说明一个问题，互联网几个主要算法领域中人员与底层技术、业务产品之间的相对关系。广告投放是一个问题定义得非常清晰的领域，大部分时候算法人员只需要针对一个确定的指标去优化即可。搜索领域稍前置一些，特别在近年大家都喜欢谈论搜索结果个性化之后。至于推荐，其实我现在更愿意提推荐产品，而非推荐技术。初入门的人总喜欢问学推荐需要学些什么算法，其实算法层面你需要懂的特定性的知识并不多，大部分还是传统的统计学、机器学习的知识和模型，加上一些常用的协同过滤、矩阵分解模型。过多地去钻研那些打着推荐系统幌子的特定新型算法反而是钻牛角尖了，发发paper可以，实用性不高，这个领域有更重要的问题值得你去关注。

关于产品与算法的关系，我觉得@横云有一句话总结得挺好，产品是1，算法是0（虽然我常跟别人说类似的意思，但我觉得这个描述足够简练传神），没有合适的产品之前，算法对用户几乎不产生什么价值，一旦产品成立，算法能让产品实现质的飞跃。对于跟产品端走得更近的推荐算法而言，这个效应尤其明显。

这里有一个案例，是我们前阵子跟的手机淘宝商品详情页的同店商品推荐，在一个较长期的纯粹算法层面的ctr预估版本的改进中，点击率提升了几个百分点。后来我们发现该模块的数据来源于两处——算法和卖家自定义。而实际上，后一个来源几乎不起作用，因为不可能有哪个卖家会去维护成百上千的商品之间的关联关系（不知道该产品当初是如何设计出来的）。实际数据对比也显示算法来源产生的点击和成交都三倍于店家自定义的数据结果。如果我们在业务上推动数据源全切换到算法来源，预期带来的效果提升比之前纯粹的算法改进要高出一倍。这个提升不牵涉到任何的模型改进，但需要算法人员保持对业务的关注和理解，而不是一直躲在后面。

这是个很简单但足够说明问题的案例，实际工作中复杂的产品模型对算法人员产生的误导会更多，我也会更加关注产品本身的定义，它是否是一个适合融入算法的土壤，或者什么形态才是产品和算法最好的契合点，而不是着眼于盲目铺开算法业务。

说到这里，让我想起几年前中国推荐社区早期热门讨论的一个话题：推荐技术是否能成就一个伟大的产品（公司），就像搜索技术之于google一样。我的观点，基于推荐技术对产品的强烈依附关系，它不会反过来促成一个产品，但它终将成就一种用户习惯（就像现在用户对搜索的认知一样，但个性化影响的用户习惯必将深远得多），特别是在现在的科技发展方向越来越贴近我们自身的时代，这也是一个激励我接下来去继续探索的领域。

算法效果的度量

我经历的两家公司正好代表了两种不同类型的推荐诉求——基于用户社区的兴趣型推荐，和以商业目标实现为前提的推荐（市面上还有其它类型差别较大的推荐）。注意到它们的差异，并采取不同的措施是件相当有价值的事情。

前者更关注长期的效果，用户是否愿意在你的社区留下来；后者更关注短期效果，用户在当前session是否会形成交易
前者更关注user；后者更关注uv。
推荐新item的重要性，前者是明显高于后者的，因为用户的主要诉求就是发现。曾经做豆瓣fm的时候，有一个dj的算法指标效果非常好，但它无法单独工作，因为它会导致用户的兴趣迅速收敛，只能在某个圈子里打转。

算法效果的度量方式往往决定了你努力的方向，面向不同类型的推荐，其中一个重要措施，就是不要采用同样一套标准去衡量你的工作结果。这点我在很多技术paper中都没有看到有成系统的论述，这跟paper通常只论述通用性问题而非特定性问题有关，于是导致了在实践中永远只看到ctr、precision/recall、rmse那样的衡量指标。那是衡量一个单一算法，而不是一个推荐系统的指标，或者说，不是衡量跟它绑定在一起的推荐产品的指标。要推动产品和算法形成一个适合自身的指标非常困难，需要多方人员的认知并达成共识。

当你在做一个用户产品的时候，算法指标会变得尤其苛刻，直白一点，个性化，是要让所有人都满意，而不是为了统计上80%人的体验而牺牲掉剩下20%人的体验。这点我有深刻的体会，以前做豆瓣fm的时候，从算法整体指标来看效果还不错，但总是会有用户抱怨这些那些的问题。后来我才意识到，一个连《统计数字会说谎》都没有告诉我的道理——统计数字的代表性导致的局限性。一个反映了80%的用户在80%的时间里觉得满意的指标，对于一个号称个性化，并且是面向挑剔的兴趣社区的个性化，是远远不够的。

另一个案例比方说淘宝搜索个性化，如果我们衡量的指标是ctr、cvr，只要我们照顾好那80%大众用户和爆款商品，就能用最简单的方法获得最好看的统计数字指标。然后用他们产生的数据继续训练我们的模型，同时强化了这个结果。于是那20%（或许价值巨大）的用户永远也无法进入我们的视野，这终归是个蹩脚的个性化系统。

我又想起那篇文章 To Personalize or Not: A Risk Management Perspective ，是否所有人都需要个性化。或者我可以理解为，目前的个性化满足不了所有人的要求，有些用户宁可不要个性化。

推荐系统

算法人员的推动力

算法工作跟工程开发工作最大的不一样在于：算法产出是不可被直观测量的。如果流程正常，工程开发的产出是有产品文档、设计稿来验证的，功能缺陷、交互/界面有出入，一目了然。而算法，特别是个性化算法，是无法通过直观的手段来测量的。传统的测试手段只能测量其可用性，而不能测量其有效性。

这点差异导致了产品人员无法像管理开发效果那样管理算法效果，也是导致优秀的算法产品人员匮乏的重要原因。这不应认为给算法人员带来了什么优越感，相反，要使得自己的工作产生合理的价值，算法人员更应该站出来，主动填补算法与产品之间的空隙。因为正如第一点所说，算法价值的实现离不开产品。

要么有一个懂算法的产品经理，要么有一个能用产品语言说话的算法工程师。在我看来，后一个人必须具备的素质，除开工程能力和算法能力之外，还有对业务本身的理解，对产品流程的认知，以及良好的沟通能力、逻辑思维能力，这也是我招聘算法工程师的一个额外的标准。

人与推荐系统的相互作用

算法都依赖于数据，而推荐算法是一个极端依赖人与系统交互数据的实现。这里的“人”包括内部的编辑、运营人员，也包括外部最广泛的用户。内部的人员可以为算法产生有价值的推动，比如pandora的genome项目、精选集的产生、负样本的收集、推荐规则从经验到机器的总结和迁移；另外，外部的用户与系统交互产生的数据是否无偏地覆盖了用户的偏好？

有经验的人都知道，数据质量决定了算法效果的上界，算法模型的变换、算法参数的调优只不过是在努力逼近这个上界而已。所以，要想让你的算法产生更好的效果，有两种途径：优化算法；或者优化数据——具体到推荐领域，主要是优化人与系统的交互数据，但这不是单纯的算法问题。

目前大部分的优化都集中在算法层面上，而忽略了数据优化。一大原因是产品和算法人员的割裂，各自管理着自己擅长的事情。一个典型的例子是：在一个孤立的算法系统中，用户接收到的数据大部分来自于系统的推荐，系统收集到的也是用户基于这份数据的反馈信息，基于这个数据去训练模型，再度强化了之前的结果。用自动化系统的术语来说，这是一个正反馈加强的系统，而不是一个负反馈纠错的系统。豆瓣fm由于产品形态上整个音乐生态系统不完备，用户反馈的数据大都是基于系统推送的结果，就存在着这方面的问题。电商搜索引擎这个问题也很严重，在搜索是主要路径且搜索结果ctr目标的导向下，爆款会不断强化自身的爆款特性，导致更多优质数据无法进入模型的筛选范围。另一个例子是我以前所在的微淘产品，由于kpi的压力，运营做了很多无节操的误导用户关注微淘账号的事情，导致整个微淘关注数据基本不可用。

一言蔽之，不要过度迷信算法的作用，要充分利用产品和生态的力量。数据优化的增益能极大提升算法优化的上界。