去重排序_推荐系统的去重问题

去重问题

去重可以拆解成两个子问题：

• 相同物料重复推荐：我已经浏览过这个物料，为什么刷新时依然又推荐一遍？“相同物料”有两种形式
  • 物料ID相同：系统推荐了好友A，刷新之后依然推荐好友A
  • 物料ID不同：系统推荐视频A和B，虽然视频内容一样，但由不同账号上传，两个视频的ID不同
• 近似物料重复推荐：我已经看过“美股暴跌”的新闻了，为什么刷新后又推荐了一篇，他们都在说一件事，只是来自不同的媒体

去重问题是最基础的用户体验，推荐系统精简到极致，可以只有两个功能，去重就是其中一个：1）热度排行榜：让每个用户都有物料可看；2）去重：让每个用户看到新的内容

相同物料重复推荐

先讨论物料ID相同的去重问题，可以拆成后端和客户端两部分：

• 后端去重：后端去重依赖用户的曝光历史，经常因为几种原因失败：1）客户端上报曝光有延迟：曝光是一个高频事件，客户端积累一批再上报，会有延迟；2）后端存储达到写一致、读一致、cache一致有延迟：例如后端从cache里读浏览历史，但cache里其实没有用户最新的曝光；3）请求超时：为了保证推荐请求端到端低延迟，如果x毫秒内还没拿到曝光历史，就跳过去重；4）不同后端请求之间无法去重：假设页面上有2个tab，每个tab的后端各自去重，但tab之间可能存在重复
• 客户端去重：可以看到后端去重并不是100%可靠的，客户端也需要实现去重，但依然有可能失败，常见的原因是cache：1）用户在浏览第一批推荐结果的时候，客户端提前请求下一批推荐结果；2）客户端发起请求时，用户在第一批推荐结果的曝光历史没有上报，无法去重；3）用户在第一批推荐结果的点击历史没有上报，导致推荐结果保持不变，基于3个原因，导致第二批推荐结果跟第一批推荐结果一模一样
• 后端去重 vs 客户端去重：推荐系统可以看成是一个漏斗，所有候选集经过后端召回、排序、重排序、客户端才展示给用户，所以去重功能理想中越靠近漏斗顶端越好：最理想的去重是在为召回服务的索引中去重，其次是在召回的结果中去重，最差是在排序过后去重，客户端为后端去重失败做兜底

再聊物料ID不同的去重问题：以视频为例，物料A和B内容上是相同的，但是不同人上传的。主要的思路是给每个物料一个哈希值，哈希值作为物料ID进行去重，上面所探讨的去重方法就可以适用了。具体实现上，把文本映射到哈希值已经很成熟了，搜索引擎在索引网页时就需要去重，但把视频映射成哈希值还有很多挑战，例如加水印、加黑边、裁剪、改变分辨率、截取部分视频，都有可能让算法误以为两个视频是不同的

近似物料重复推荐

用户问题：我已经看过“美股暴跌”的新闻了，为什么刷新后又推荐了一篇，他们都在说一件事，只是来自不同的媒体

在我看起来，定义问题本身就是很困难，因为重复性和相关性是有模糊的交集的：

• 从相关性角度说：我看到了美股暴跌的新闻，系统推荐出另一篇美股暴跌的新闻，是不同记者写的，但都围绕着美股暴跌，说明推荐的相关性好
• 从重复性角度说：我已经看过美国暴跌的新闻了，再推荐一篇类似的新闻，信息重合度高，说明重复性太强

虽然问题本身是模糊的，但可以考虑从两个方向入手：

• 利用负反馈：推荐第二篇美股暴跌的新闻时，觉得推荐重复的用户会直接跳过，可以看成是隐式负反馈，从召回和排序两个层面解决：1）召回上，可以考虑在U2I召回里，在User侧加入负反馈embedding，相比之下，I2I召回很难处理负反馈；2）排序上，除了把负反馈物料用作ID特征，还可以考虑构建<user, 物料>的实时特征，可以参考之前写的实时性的文章
• 多样性手段：在重排序中，可以将新闻按主题进行打散，防止美股暴跌的新闻扎堆出现，可以参见之前写的多样性的文章

小结

去重问题，站在用户的角度来说，就是“感觉推荐结果重复”一句话；但站在技术角度，解决问题需要把问题拆解成客户端、后端、NLP/CV标注等不同的任务，很锻炼端到端解决问题的能力，又是推荐系统的核心用户体验。可能因为学术上并没有太多故事可讲，在这里贡献一些解决思路和难点