去重--推荐

• 相同物料重复推荐：我已经浏览过这个物料，为什么刷新时依然又推荐一遍？“相同物料”有两种形式

• • 物料ID相同：系统推荐了好友A，刷新之后依然推荐好友A
  • 物料ID不同：系统推荐视频A和B，虽然视频内容一样，但由不同账号上传，两个视频的ID不同

• 近似物料重复推荐：我已经看过“美股暴跌”的新闻了，为什么刷新后又推荐了一篇，他们都在说一件事，只是来自不同的媒体

利用负反馈：推荐第二篇美股暴跌的新闻时，觉得推荐重复的用户会直接跳过，可以看成是隐式负反馈，从召回和排序两个层面解决：1）召回上，可以考虑在U2I召回里，在User侧加入负反馈embedding，相比之下，I2I召回很难处理负反馈；2）排序上，除了把负反馈物料用作ID特征，还可以考虑构建<user, 物料>的实时特征，

**多样性手段：**在重排序中，可以将新闻按主题进行打散，防止美股暴跌的新闻扎堆出现

• 支持打散规则灵活迭代：打散规则会在几个方面进行变化：1）衡量多样性的维度，体育-动漫是一种衡量方式，视频-文本也是一种衡量方式；2）规则本身，设置最小间隔k只是一种打散规则，还可以想到体育类最多出现k次，最低出现l次这种规则；3）规则组合，例如针对重度体育用户，放宽多样性限制，避免对所有用户强加多样性。所以，重排序的实现需要支持灵活的规则变动
• 处理规则冲突：假设推荐结果同时存在是视频和文本，满足了体育类不能连续出现k次，可能就无法满足视频类不能连续出现k次
• 不同请求间保证多样性：用户前后两次session，甚至是同一session里不同的请求，都需要保证多样性，如果上一个请求已经展示了很多体育类的，下一个请求就需要作出调整。
• **不同的页面间保证多样性：**产品可能存在多个板块，用户在A板块看到了很多体育内容，跑去别的页面就应该看到不一样的内容。不同板块通常是不同的团队开发的，由于时间前后不同，采用可能后端都不一样，需要让各个页面协同维护全站的多样性

一种推荐算法

Bloomfilter
问题：防止已经推荐的内容被重复推荐。

内容的 ID 用一个不太长的字符串或者整数。

对于这类形如模式串的去重，显然可以用单独专门的数据库来保存，为了高效，甚至可以为它建上索引。

但对于用户量巨大的情况下，这个做法对存储的消耗则不可小看。实际上，解决这类看一个字符串在不在一个集合中的问题，有一个有点老但很好用的做法，就是 Bloomfilter，有时候也被称为布隆过滤器。

布隆过滤器的原理也要用到哈希函数。它包含两部分：一个很长的二进制位向量，和一系列哈希函数。Bloomfilter 是一个很巧妙的设计，它先把原始要查询的集合映射到一个长度为 m 的二进制位向量上去，它映射的方法是：

1. 设计 n 个互相独立的哈希函数，准备一个长度为 m 的二进制向量，最开始全是 0；

2. 每个哈希函数把集合内的元素映射为一个不超过 m 的正整数 k，m 就是二进制向量的长度；

3. 把这个二进制向量中的第 k 个位置设置为 1；也就是一个元素会在二进制向量中对应 n 个位置为 1。

看示意图。

这个示意图中，原始的模式串经过三个互相独立的哈希函数，映射到 8 位二进制向量中的三个位置了。

原始的模式串集合经过这样的处理后，就得到一个很大的二进制向量。在应用阶段时，假如来了一个模式串 s，需要查询是否在这个集合中，也需要经过同样的上述步骤。

每个哈希函数对这个模式串 s 哈希后都得到一个整数，看看这个整数在二进制向量中所指示的位置是不是 1，如果每个哈希函数所指示的位置都是 1，就说明模式串 s 已经在集合中了。