首先，推荐系统的多样性并不应该是一个推荐系统追求的终极目标。

多样性，是手段，不是目标！

多样性，是手段，不是目标！

多样性，是手段，不是目标！

重要的事情重复三遍，为什么不能作为目标呢？因为：

1. 多样性很难量化。3个体育新闻+7个小姐姐和7个小姐姐+3个体育新闻，哪个更加多样呢？

2. 多样性不是越多越好，一次推荐 list 10 篇文章，各是不同的话题的，显然比较多样，但是你确定是更好的推荐结果吗？你肯定会说，多样性要“合适”就好，问题就在这里，合适的点在哪里呢？那一定是通过其他真正的结果指标来告诉你的。

3. 多样性对于每个人，每个场景来说，是不一样的，好坏的点不同。比如说我最近刚有了宝宝，那么我恨不得淘宝给我推荐的商品全都是母婴用品，多样性并不是一个特别重要的事情。

哪些指标是合理的呢？

1. 用户反馈（喷产品经理）后台里关于多样性的反馈数量，别笑，这个指标至少是越少越好的，是一个非常可以量化的指标。不过这个信号太稀疏了，不足以从中提取有统计意义的信息。倒是有可能发现一些明显的 bad case 或者 bug。

2. 用户的点击率、阅读时长、留存、分享、互动数据。这是推荐系统的 ground truth，如果你可以建立这些 ground truth 和多样性之间的关系，那显然可以去做一些工作。

记住，用一个真正的指标为准绳和目标去优化多样性，不要为了多样性而多样性！

比如如果你的推荐系统的优化目标是阅读时长，如果增加多样性可以提升时长，就去做，如果增加多样性不能够提升时长，那你就不要这么做。

多样性真正的背后的问题，在于点击率预估模型也好、时长或者什么 xx 预估模型也好，预测的是一个 point-wise 的问题。就是你给某个具有 x 属性的用户在 c 的上下文下看一个叫做 i 的内容，他的点击率、时长、xx 可能会是多少。

而实际中的问题叫做，你给某个具有 x 属性的用户在 c 的上下文下看一串叫做 <i1,i2,i3,i4…> 的内容列表，他的点击率、时长、xx 可能会是多少。

所以多样性的问题就在于你的业务实际要优化一个排列组合，你优化的只是某一个点，那么因为你的模型和你使用模型的业务场景不同，你拿到的结果自然不是最优。更通俗地说，你喜欢吃虾，给你上一桌全是虾的菜，大概率是一个失败的菜单，而一桌有鱼有虾有鸡有鸭的菜可能会更好。因为你每个都不喜欢的概率大大降低了。

你肯定会问，为什么不直接去建立一个模型，样本就用 list，然后直接对所有候选集的可能排列组合进行打分然后选出最优的内容排列组合呢？

不妨先假设你已经训练出了这样一个模型，假设你是做短视频推荐信息流的，当前推荐有100个可选候选集，那么你推出一刷5个短视频，需要遍历100*99*98*97*96这么多种可能性才能找到最优的组合，这显然是没有计算可行性的。

而实际上，你训练出这样的一个模型，也对你的样本量和计算基础设施有非常高的要求。

那么怎么办呢？

1. 老专家规则。比如说你一拍脑门，说一次推荐5条内容里必须有至少1个视频，至少来自于3个不同的分类。接着你 abtest 了一下，这么做的情况下，用户的负反馈减少了、时长提升了。其实这是大多数推荐系统在使用的一个 good practice。老专家规则有很多，无非是一些启发式的策略，你拍拍脑袋或者抄一抄别的推荐系统，就能得到答案，然后通过大量快速的 abtest 迭代测试找到对你的业务场景来说靠谱可行的策略（集合）。

2. 使用更长更丰富的召回拉链，保证更多样的内容可以进入排序阶段。只要系统不会挂，这往往是没有什么坏处的，除了你的云服务器账单会增长得更快。但是仅仅增加召回拉链的数量，并不能彻底解决多样性问题，因为你并没有改变预估模型的逻辑，只是提供了更多的候选集。

3. 建立一个模型，用一些贪心的方法，比如要么减少搜索空间，要么对这个空间的性质做一些理想假设来降维，来预测什么样的 list 组合是最优的。这里有很多牛逼的方法，比如最近 youtube 的一篇论文，比如阿里现在在采用的一些 list-wise 模型策略。几种朴素的方法：

① 分类的空间比 item 小多了，比如说你的内容一共也就10个分类，一刷10个，不考虑顺序，再删除掉一些完全不可能的组合，那么组合的空间可以降低到几十 - 几百个，又回到了一个典型的机器学习在线预估问题。你可以先预测这一刷要给这个人看哪些分类的内容，各几个。然后再有一个模型从这些分类里取他可能更喜欢的内容。

② 对多样性进行一个度量，比如说每个 item 通过模型或者某种东西 embedding 成一个64维向量，然后再设法降维到10。每一刷10个，那么10行10维向量长成的空间的体积或者说这个矩阵的行列式就表达了这10个 item 的多样性。你可以把这当成一个特征去算每个人对这个多样性的偏好。对于不同偏好的人，在最后 rerank 的时候设定一个阈值去进行裁剪。

③ 构造一个特别的样本，特征包含展示在每个 item 之前的几个 item 的可以泛化的特征 ( 比如说类目、term、tag )，列表生成的时候对候选集的 item 使用这个模型来从上到下打分生成。每个列表第一个就放全局最后的 item1，第二个就用这个模型预测当第一个位置是 item1 ( 这样的 item ) 的时候，item2 应该选哪个最好，以此类推。

④ 更多骚气而你能想到的idea，都可以去实验。

简单总结一下：

1. 多样性不是你追求的目标，但是多样性确实可以帮助你提升你真的应该关注的指标：比如说更少的用户投诉、更多的时长、点击。

2. 多样性问题的本质是 ctr 或类似预估问题是对单点最优进行预测，而我们真实业务实际上往往给出的是一个列表。求列表最优的问题计算空间过大，所以我们会用一些歪门邪道，要么直接拍个老专家规则，要么降低空间的维度或者复杂度来取巧解决。

推荐系统教程之九：解密“看了又看”和“买了又买”（Item-Based）

快看漫画个性化推荐探索与实践.pdf(附下载链接)

阿里Java开发手册最新版.pdf(附下载链接)

Graph Embedding及其在知乎的实践（附pdf下载链接）

推荐系统教程之九：解密“看了又看”和“买了又买”（Item-Based）

每天超50亿推广流量、3亿商品展现，阿里妈妈的推荐技术有多牛？

feed流设计：那些谋杀你时间的APP

数据智能的发展特点和十大未来热点

2019人工智能发展趋势报告

今日头条推荐系统原理

关注我们

一个「在看」，一段时光！?