GeoHash 召回

屬于地理位置召回，用戶可能對附近發生的事情感興趣。GeoHash 是一種對經緯度的編碼，地圖上每個單位矩形的 GeoHash 的前幾位是相同的，GeoHash 編碼截取前幾位后，將相同編碼發布的內容按時間順序（先是時間更晚的）呈現，還需要經過排序模型的選擇。這種方式并沒有個性化，從另一個角度來說，用戶本就對附近的事有一定的興趣。

假設你在北京中關村，GeoHash 編碼是 wx4g0ec1，那周邊幾百米范圍內的位置可能都是以 wx4g0ec 開頭。
所以，如果你想查“附近的人”或“附近的商店”，只要查 GeoHash 以 wx4g0ec 開頭的就行。

同城召回

與 GeoHash 召回類似，范圍更大，按照當前的城市和以前居住過的城市的內容推薦。

作者召回

用戶對關注的作者發布的筆記感興趣。系統會維護兩個索引，一個是關注的作者，另一個是作者發布的筆記，同樣是按時間順序倒排。召回時對用戶的 id 查詢關注的作者，然后再查找這些作者最新的筆記。

有交互的作者召回

如果用戶對某筆記感興趣（點贊、收藏、轉發），那么用戶可能對該作者的其他筆記也感興趣。維護用戶交互過的作者的索引，長時間未交互的就刪除，維護最近交互過的作者，類似 lru。召回時對用戶的 id 查詢有交互的作者，然后再查找這些作者最新的筆記。

相似作者召回

和 itemcf 原理類似，如果用戶喜歡某作者，那么用戶也很有可能喜歡類似的作者。對作者維護相似作者的索引。召回時對用戶查詢其感興趣的作者，然后再查詢相似的作者，最后返回最新的筆記。例如用戶有 $n$ 個關注的作者，每個作者有 $k$ 個相似的作者，這就會有 $nk$ 個作者，每個作者都返回其最新的筆記也能有 $nk$ 篇筆記了。

緩存召回

精排沒有被曝光的筆記中排名靠前的，比如前 50，直接丟棄很浪費，緩存起來作為一條召回通道。
會遇到的問題：緩存大小固定，需要退場機制。
退場機制也和 lru 的思想類似。比如一旦筆記成功曝光，就從緩存退場；超過緩存大小移除最早進入的筆記；筆記召回上限為 10 次，一旦超過就退場；筆記最多保存 3 天，超過三天就退場。這些是相對暴力的方法，還有更精細的方法，比如想要多扶持低曝光的筆記可以設置動態的閾值，曝光次數較低的退場時間更長。