地理位置召回
GeoHash召回
- 用户可能对附件发生的事感兴趣
- GeoHash：对经纬度的编码，地图上一个长方形区域。
- 系统维护一个地理位置 GeoHash 索引，GeoHash 意思是把经纬度编码成二进制哈希码，方便检索
- 索引：
GeoHash → 优质笔记列表（按时间倒排），以 GeoHash 为索引，记录地图上一个长方形区域的优质笔记 - 做召回的时候，给定用户的 GeoHash，会取回区域内一些比较新的优质笔记
- 这条召回通道没有个性化，召回纯粹只看地理位置。每次召回本地的一批优质笔记，完全不考虑用户兴趣
- 就是因为没有个性化，所以才得用优质笔记。笔记本身质量好，即使没有个性化，也很有可能会喜欢看。反过来，既没有个性化，也不是优质笔记，那么召回的笔记大概率通不过粗排和精排
- 圈出来的是 GeoHash，每个 GeoHash 都表示地图上的一个长方形区域
- 每个 GeoHash 后面都有一个笔记列表，意思是定位在这个位置的优质笔记，这个列表包含 k 篇优质笔记，排在最前面的是最新的笔记
- GeoHash 很简单，如果小红书用户允许小红书获取其定位，那么就根据用户定位的 GeoHash，取回该地点最新的 k 篇优质笔记
- 至于这些哪些会留在最终的曝光里面，这由排序模型决定
同城召回
- 用户可能对同城发生的事感兴趣，与上面的 GeoHash 的原理同理
- 索引：
城市 → 优质笔记列表（按时间倒排） - 这条召回通道没有个性化
作者召回
- 如果你对一个作者感兴趣，系统就会给你推这个作者发布的新笔记
- 用户对关注的作者发布的笔记感兴趣
- 索引：新发布的笔记排最前面
用户 → 关注的作者作者 → 发布的笔记
- 召回：
用户 → 关注的作者 → 最新的笔记
有交互的作者召回
- 如果用户对某笔记感兴趣（点赞，收藏，转发），那么用户可能对该作者的其他笔记感兴趣
- 比如我在小红书上刷到一个玉石加工的视频，我对其点了赞。虽然我没有买玉石或者收藏玉石的习惯，所以我不会关注这些作者。但给我推送这些作者新发布的玉石雕刻的视频，我很有可能会看完。所以即使我不关注作者，也应该继续推送他的视频
- 索引：
用户 → 有交互的作者，作者列表需要更新，最简单的方法就是保留最近交互的作者，删除一段时间没有交互的作者 - 召回：
用户 → 有交互的作者 → 最新的笔记
相似作者召回
- 如果用户喜欢某作者，那么用户喜欢相似的作者
- 索引：
作者 → 相似作者 - 作者相似性的计算类型类似于 ItemCF，如果两个作者的粉丝有很大的重合，那么就判定两个作者相似
- 召回：
用户 → 感兴趣的作者 → 相似作者 → 最新的笔记，感兴趣的作者包括用户关注的作者和用户有交互的作者，利用索引再找到相似作者，最后取回作者最新的一批笔记 - 如果每个作者召回最新的一篇笔记：
缓存召回
- 想法：复用前 n 次推荐精排的结果
- 背景：
- 精排输出几百篇笔记，送入重排
- 重排做多样性抽样，选出几十篇
- 精排结果一大半没有曝光，被浪费。这些都经历了很多计算，但是因为随机性的原因没有被曝光，是很可惜的
- 精排前 50，但是没有被曝光的，缓存起来，作为一条召回通道
- 缓存大小固定，需要退场机制，比如我的缓存大小就是 100 篇笔记，那么就需要确保缓存里面最多有 100 篇笔记
- 一旦笔记成功曝光，就从缓存退场
- 如果超出缓存大小，就移除最先进入缓存的笔记
- 笔记最多被召回 10 次，达到 10 次就退场
- 每篇笔记最多保存 3 天，达到 3 天就退场
- 这些都是比较简单的规则，还可以加上更复杂的规则，比如：假如想要扶持曝光比较低的笔记，那么可以根据笔记的曝光次数来设置规则，让低曝光的笔记在缓存里存更长时间
总结
