# 为什么推荐系统需要多样性？
当前个性化推荐以及相关算法的关注点大多数在提高推荐的精准性，而忽略了推荐结果的多样性，导致容易出现"high similar items were clustered together"现象，即相似的Item扎堆，用户的兴趣被局限到一个相对"较窄"(信息量为0的"精准推荐")的推荐视野中，进而伤害了用户体验(尤其是兴趣宽泛、偏逛、需求不明确的用户)
推荐多样性问题的本质是排序中CTR(点击率)或类似(CVR转化率等)预估问题是单点(Point-wise)最优预测，而通常真实业务中往往是给到用户一个列表(List-wise排列组合优化)，即Point-wise和List-wise之间往往存在着较大的Gap。
多样性不是目标，但是实践证明多样性可以帮助提升时长、点击、用户长期留存等核心业务指标。此外，与精排阶段的点击率预估(用户是否点击)任务不同，多样性处理通常是没有groudtruth(真值)的，通常需要A/B实验来确定多样性策略的优劣。
推荐系统的多样性反应了一个推荐列表中内容不相似的程度。通过推荐多样性更高的内容，既能够给用户更多的机会去发现新内容，也能够让推荐系统更容易发现用户潜在的兴趣。但需要注意的是，精确性和多样性是一对Trade Off，提升多样性的代价往往以牺牲准确性为代价，因此如何平衡准确性和多样性是一个需要权衡的地方，或者从另一个角度讲如何在短期目标和长期目标间做平衡。
- 从用户体验来看，容易造成审美疲劳和新鲜感下降，进而造成消费下降和流失
- 从数据收集来看，用户的兴趣被局限，进而无法获得用户对于更多内容的样本，得不到用户级别更广泛兴趣的训练数据
- 从模型拟合来看，整个大盘的数据分布bias会更加严重，导致模型泛化性变差
- 从作者角度来看，多样性不足+bias严重导致A品类的作者天生就比B品类更容易分发消费，打击部分作者积极性
- 从内容生态来看，内容同质化+作者流失最终导致内容品类匮乏
# 如何评价推荐多样性的好坏？
对于多样性通常可以参考如下衡量指标：
- ILS(intra-list similarity)
ILS主要是针对单个用户，一般来说ILS值越大，单个用户推荐列表多样性越差。
- 海明距离(Hamming distance)
- SSD (self-system diversity)
SSD指推荐列表中没有包含在以前的推荐列表中的比例，主要考察推荐结果的时序多样性。
其中，
- 覆盖率(coverage)
覆盖率是推荐给用户的Item占所有Item的比例，用来衡量对长尾Item的推荐能力。
- K次重复率
在一次推荐请求中，同一类别的Item连续出现 [公式] 次的比率。
- Hellinger距离
通过计算生成的topK结果的多样性分布和理想的多样性分布之间的Hellinger距离，来衡量top K结果多样性的好坏。
其中，
# 推荐系统应该如何保障推荐的多样性？
召回：
- 热度降权：比如协同过滤中加一个热度的惩罚项
- 召回频控：对于具有相同属性的Item，比如作者、类别等，短时间内控制推荐的次数。这里的"短时间"，在不同业务场景不同Item类型都是不一样的，比如用户一次请求、用户session会话周期等。单路召回内部，或者多路召回merge时做一些多样性策略，还能缓解quota问题。
- 多兴趣召回：比如阿里的MIND，论文提出单一的向量无法准确表达出用户多种多样的兴趣，除非把这个向量长度变得特别大，如果单个兴趣向量没法做到将所有的用户兴趣点覆盖，那么就多搞几个向量，几个向量同时来表示用户的兴趣点。
- 兴趣探索召回：一些非模型的召回可以很简单达到这个目的，比如离线统计后验然后加一路redis召回，或者写个新的候选表复用主召回模型。
排序：
- 粗排后打散：如果粗排有截断，粗排打散再进精排可以缓解精排quota问题
- 精排从point-wise过渡到list-wise：point-wise毕竟只考虑了单个item的预估分，而list-wise会考虑一刷整体的收益
- 长期兴趣：除了召回外，精排也可以充分发挥超长行为序列的优势，提高长期/常尾兴趣的排出率，比如阿里妈妈的论文SIM就是超长行为序列的利用。
- 重排&混排：比如最简单的MMR（最大边界相关算法）提高多样性
- 多目标融合调优：如果只考虑ctr那么天然适合标题封面党，只考虑finish会利于短且内容密集的视频，staytime利于中长影视，以上还只是用户层面的；如果在融合公式加上作者侧、内容测、长期的指标，也会利于生态建设。
规则：
- 一些机制策略：作者/品类等规则打散；热度内容的deboost；长尾内容的boost等。核心是通过大量快速的abtest迭代测试找到靠谱可行的策略
- 消重与频控：这块需要提及的是为了避免用户短时间内看到相同/相似的item，客户端、服务端的窗口是不同的，服务端窗口更短。而像相关等场景其窗口和频控严格程度与feed是完全不同的。
- 其他场景引入：比如搜索进推荐，或者长尾场景的消费进主场景
https://zhuanlan.zhihu.com/p/381545437 https://www.zhihu.com/question/68299606/answer/1946009968
# 模型的实时性是如何影响推荐系统的效果的？
模型更新的间隔时间越长，推荐系统的效果越差；反过来说，模型更新得越频繁，实时性越好，损失越小，效果越好。
从用户体验的角度讲，在用户使用个性化新闻应用时，用户的期望是更快地找到与自己兴趣相符的文章；在使用短视频服务时，期望更快地”刷到“自己感兴趣的内容；在线购物时，也期望更快地找到自己喜欢的商品。只要推荐系统能感知用户反馈、实时满足用户的期望目标，就能提高推荐效果。
从机器学习角度来看，推荐系统的实时性重要之处体现在以下两个方面：
1）特征上的实时性：推荐系统对的更新速度越快，代表用户最近习惯和爱好的特征更新越快，越能为用户进行更有时效性的推荐。
2）模型上的实时性：推荐系统更新的越快，模型越容易发现最新流行的数据模式，越能让模型快速抓住最新的流行趋势。
# 客户端是如何做到对于实时特征进行实时推荐的？
客户端是最接近用户的环节，一般会利用客户端收集时间、地点、推荐场景等上下文特征，然后让这些特征随http请求一起到达服务器端，从而请求推荐服务，此外，客户端能够实时手机session（会话）内用户行为的地方。比如用户在一次会话中点击阅读了三篇文章，它们代表了用户的即时兴趣，若能根据用户的即时兴趣实时改变推荐结果，将大大提升用户体验。
所以可以通过客户端缓存session内部的行为，将其作为与上下文特征同样的实时特征传给推荐服务器，那么推荐系统就可以实时得到session内部的行为特征进行实时推荐。
# 流计算平台是如何进行准实时特征处理的？
Storm/Spark Streaming/Flink等流计算平台进行准实时的特征处理几乎成了推荐系统的标配，流计算平台是将日志以流的形式进行微批处理（mini batch）。由于每次需要等待并处理一小批日志，流计算平台并非完全实时的平台，但它的优势是可以进行简单的统计类特征，比如一个物品在该时间窗口内的曝光次数、点击次数等，计算出的特征可立刻存入特征数据库供推荐系统模型使用。虽然无法实时地根据用户行为改变用户结果，但分钟级别的延迟基本可以保证推荐系统能准实时地引入用户的近期行为。
# 分布式存储系统HDFS和分布式批处理平台在推荐中的作用有哪些？
用户的曝光、点击、转化数据往往是在不同时间到达HDFS的，有些游戏类应用的转化数据延迟甚至高达几个小时，因此只有在全量数据批处理这一阶段才能进行全部特征及相应标签的抽取和合并。也只有在全量特征准备好之后，才能够进行更高阶的特征组合工作。这往往是无法在客户端和流计算平台上进行的。
分布式批处理平台的计算结果的主要用途是：
1）模型训练和离线评估 2）特征保存入特征数据库，供之后的线上推荐系统使用
数据从产生到完全进入HDFS,再加上Spark的计算延迟，往往达到小时级别，已经无法进行所谓的”实时推荐“，因此更多的是保证推荐系统特征的全面性，以便用户在下次登录时进行更准确的推荐。
# 请简述offline/nearline/online训练方法和步骤。
offline即全量更新，是指模型利用某时间段内的所有训练样本进行训练，全量更新是最常用的模型训练方式，但需要等所有训练数据都存储在HDFS等大数据存储系统中才可，且全量样本训练的时间往往比较长，实时性最差。
nearline即近线更新，仅仅将新加入的样本”喂给“模型进行增量训练。从技术上讲，深度学习模型往往采用随机梯度下降（SGD）法及其变种进行学习，模型对增量样本的学习相当于在原有样本的基础上继续输入增量样本进行梯度下降。增量更新的缺点在于：增量更新的模型往往无法找到全局最优点，因此在实际的推荐系统中，经常采用增量更新与全局更新相结合的方式，在更新了几轮增量更新后，在业务量较小的时间窗口进行全局更新，纠正模型在增量更新过程中积累的误差。
online学习是进行模型实时更新的主要方法，即在获得一个新的样本的同时更新模型，online学习在技术上也通过梯度下降的训练方式实现，但线上环境进行模型训练需要更新和存储大量的参数，对工程要求比较高。
在线学习中，模型的稀疏性不强。在一个输入特征向量达到几百万维的模型中，如果模型的稀疏性较好，就可以在模型效果不受影响的前提下，仅让一部分特征对应的权重非零，摒弃所有权重为0的特征，从而让上线的模型体积很小，有利于加速模型服务。但使用SGD的方式更新模型，容易产生大量小权重特征，增大了模型体积，从而增大模型部署和更新难度。FTRL就是为了解决在在线学习过程中兼顾训练效果和模型稀疏性的问题二提出来的。