召回11：地理位置召回、作者召回、缓存召回

GeoHash 召回

属于地理位置召回，用户可能对附近发生的事情感兴趣。GeoHash 是一种对经纬度的编码，地图上每个单位矩形的 GeoHash 的前几位是相同的，GeoHash 编码截取前几位后，将相同编码发布的内容按时间顺序（先是时间更晚的）呈现，还需要经过排序模型的选择。这种方式并没有个性化，从另一个角度来说，用户本就对附近的事有一定的兴趣。

假设你在北京中关村，GeoHash 编码是 wx4g0ec1，那周边几百米范围内的位置可能都是以 wx4g0ec 开头。
所以，如果你想查“附近的人”或“附近的商店”，只要查 GeoHash 以 wx4g0ec 开头的就行。

同城召回

与 GeoHash 召回类似，范围更大，按照当前的城市和以前居住过的城市的内容推荐。

作者召回

用户对关注的作者发布的笔记感兴趣。系统会维护两个索引，一个是关注的作者，另一个是作者发布的笔记，同样是按时间顺序倒排。召回时对用户的 id 查询关注的作者，然后再查找这些作者最新的笔记。

有交互的作者召回

如果用户对某笔记感兴趣（点赞、收藏、转发），那么用户可能对该作者的其他笔记也感兴趣。维护用户交互过的作者的索引，长时间未交互的就删除，维护最近交互过的作者，类似 lru。召回时对用户的 id 查询有交互的作者，然后再查找这些作者最新的笔记。

相似作者召回

和 itemcf 原理类似，如果用户喜欢某作者，那么用户也很有可能喜欢类似的作者。对作者维护相似作者的索引。召回时对用户查询其感兴趣的作者，然后再查询相似的作者，最后返回最新的笔记。例如用户有 $n$ 个关注的作者，每个作者有 $k$ 个相似的作者，这就会有 $nk$ 个作者，每个作者都返回其最新的笔记也能有 $nk$ 篇笔记了。

缓存召回

精排没有被曝光的笔记中排名靠前的，比如前 50，直接丢弃很浪费，缓存起来作为一条召回通道。
会遇到的问题：缓存大小固定，需要退场机制。
退场机制也和 lru 的思想类似。比如一旦笔记成功曝光，就从缓存退场；超过缓存大小移除最早进入的笔记；笔记召回上限为 10 次，一旦超过就退场；笔记最多保存 3 天，超过三天就退场。这些是相对暴力的方法，还有更精细的方法，比如想要多扶持低曝光的笔记可以设置动态的阈值，曝光次数较低的退场时间更长。