067 推荐的Exploit和Explore算法之一:EE算法综述

上周,我们聊了一些比较高级的模型,包括张量分解和协同矩阵分解,讨论这些模型如何能够抓住更多的用户和物品之间的关系。最后,我们还讨论了如何优化更加复杂的目标函数。

这周,我们来看一个完全不同的话题,那就是 Exploitation(利用)和 Exploration(探索)的策略,俗称“EE策略”。

一个推荐系统,如果片面优化用户的喜好,很可能导致千篇一律的推荐结果。其实,EE策略是推荐系统里很有意思,但也非常有争议的一个话题。一方面,大家都明白这类算法的目的,每年有很多相关论文发表。但另一方面,工业界对于部署这类算法非常谨慎,有的产品经理甚至视之为“洪水猛兽”。我们今天就来分析一下导致这个现象的一些因素。

走一步看一步的策略

这里再简单阐述一下什么是EE。简单来说,就是我们在优化某些目标函数的时候,从一个时间维度来看,当信息不足或者决策不确定性(Uncertainty)很大的时候,我们需要平衡两类决策:

在做这两类决策的过程中,我们也逐渐更新对所有决策不确定性的认识。最终,从时间的维度上来看,我们在不确定性的干扰下,依然能够去优化目标函数。

也就是说,EE可以看作是一个优化过程,需要多次迭代才能找到比较好的方案

EE的应用历史

早期把EE应用于新闻推荐系统的文章,主要关注在雅虎的今日新闻(Today Module)这一产品上,这也基本上是EE最早在互联网应用的尝试,目的是为了优化点击率(CTR)。而更早的一些奠基性的文章,则是在广告的数据集上展示实验结果。

雅虎的今日新闻其实为EE提供了一些被很多学者和工业界人士忽视了的条件和成功因素。如果不考虑这些因素,鲁莽地在其他场景中使用这些文献中相似的算法,很可能会产生相当差的效果。那么是哪些因素呢?主要有两点。

  1. 相对少量的优质资源。今日新闻每天的内容池(Content Pool)其实并不大。这里面都是网站编辑精选了的大概100篇文章。这些文章原本的质量就非常高,无论是这里面的任何一组,用户体验都没有明显变差。内容池每天都人为更换。
  2. 非常大的用户量。有亿万级的用户,最终可能是从算法随机产生的文章排序中选择了阅读的文章。因为用户数量巨大,所以算法就相对比较容易收敛(Converge)到稳定的方案,也就是前面讲的,优化CTR的状态。

正因为有了以上两个因素,在这个模块上,工程师和科学家们享受了后来学者们所无法想象的“奢侈”,比如运行Epsilon-Greedy这种简单粗暴的EE算法;甚至是完全随机显示新闻,收集到了大量无偏(Unbiased)的数据,都为很多学术工作奠定了数据基础。时至今日,依然有不少后续学者,在今日新闻随机数据的基础上进行算法改进。

如果没有了这两条因素,最早的解决方案可能都没法在当时的雅虎施行。原因很简单,如果资源良莠不齐,资源数量非常大,那么在仅有的几个展示位置,优质资源显示的可能性在短期内就会比较小(因为系统对于大多数的资源还有很高的不确定性,需要Explore)。

由于优质资源显示得少了,用户就会明显感受到体验下降,最直接的可能就是倾向于不点击甚至放弃使用产品。用户不和系统交互这样的行为,又进一步减缓了系统学习资源不确定性的速度。这时,也许亿万级用户数都没法满足学习所有资源的用户数量(毕竟所有用户只有一部分会落入Exploration)。

关于这个解决方案有一个很有意思的点值得一提,在雅虎的研究人员跳槽到了LinkedIn以后,LinkedIn也推了相似的方案。为了模拟雅虎今日新闻的这些条件,就对用户内容流里的数据进行了大规模的过滤。这样就有少数的信息符合高质量的要求,并且能够在用户数允许的情况下探索到合适的解决方案。

EE的产品部署难点

我们来讲一下EE的产品部署难点,这些难点普遍高于具体的EE算法选择(比如选某一个UCB或者某一个Thompson Sampling)在产品工程解决方案上的抉择。

为了便于讨论,我们把所有EE算法整体叫作“Random”,简称“R算法”,而把不做EE的算法叫作“Deterministic”,简称“D算法”。这里面的假设是,D算法比较静态,能够产生高质量、一致性的内容。这里的一致性是指用户在短时间内的体验比较稳定,不会有大幅度的界面和内容变化。相反,整体来说,R算法的不确定性比较大,用户体验和产生的内容可能会有比较大的波动。

第一个难点是如何上线测试。这看上去不应该是难点,但实际上需要格外小心。传统EE文献,只是把问题抽象为每一次访问需要做一个决策的选择。然而,文献却没有说,这些访问是否来自同一个用户。

那么,理论上,EE应该对所有的访问不加区别,不管其是否来自同一个用户。用我们这篇文章的术语来说,就是所有的流量都做R算法。虽然从理论上讲这样没有问题,但实际上,用户体验会有很大的差别。特别是一些推荐网站,用户希望自己前后两次对网站的访问保持一致性。如果不加区分地做R,对于同一个用户来说,很可能两次看见的内容完全迥异。这对用户熟悉产品界面,寻找喜爱的内容会产生非常大的障碍。

那么,我们对绝大部分用户做D,对另外一小部分用户做R,这样会好一些吗?这其实就是“牺牲”少部分用户体验,来换取绝大多数用户体验的一致性。这样实现也是最直观的,因为很多在线系统的A/B测试系统是根据用户来进行逻辑分割的。也就是说,某一部分用户会进入一个Bucket,而另一批用户会进入另外一个Bucket。按用户来做D & R可以很容易和Bucket System一致起来,方便部署。当然,这样做也是有潜在风险的。那就是,这部分老做R的用户,在当了别人的小白鼠以后,很可能永远放弃使用产品。

另外一个难点就是如何平衡产品。EE几乎是一定会导致用户对产品的体验下降,至少是在短期内会这样。如何弥补这一点,技术上其实比较困难。比如做过滤是一种思路,那就是只在优质内容里探索。当然,有人会说,这样其实也没有多大的意义。然而,一旦把质量的闸门打开了,那就会对用户体验带来很大的影响。

这也是很多产品经理对于EE非常谨慎的原因,能不做就不做。而且,牺牲了用户体验后,EE所带来的好处其实是很难评测的,这主要是由线上产品的评测机制和评测原理决定的。目前还没有比较统一的解决方案。

如何能够做到“用户友好型”的EE呢?这里面可以有两种思路。

思路一,不是所有人群的所有访问都适合做R。和传统EE不同的是,做“反向EE”。也就是说,我们只针对常用产品的用户做探索,而并不是针对新用户或者是还没有那么熟悉系统的人群。这个思路和EE完全相反,但是更加人性化。

思路二,夹带“私货”。也就是更改EE的算法,使得高质量的内容和低质量的内容能够相伴产生,并且高质量的内容更有几率排在前面。这样用户体验的损失是可控的。

其实,EE和产品的结合点应该是工程和研究的重点,但遗憾的是,碍于数据和其他方面的因素,这方面的研究工作几乎没有。

小结

今天我为你讲了推荐系统的一个重要的问题,就是如何持续挖掘用户可能的喜好,也就是做EE。

一起来回顾下要点:第一,我们讲解了什么是EE;第二,我们介绍了EE的一些简要历史;第三,我们讨论了EE的部署难点。

最后,给你留一个思考题,EE策略是不是一定会导致用户看到多样不同的东西呢?