大家好，我叫李茶，來自虎牙直播的推薦工程組，主要負責虎牙直播的推薦架構工作。直播推薦是一個頭部主播比較集中的場景，比較注重關系鍊、詞語以及長期的價值，業務訴求可能和其他推薦場景有所不同，這一點在工程架構上也會有所體現。本文将和大家分享下虎牙直播的推薦架構，包括以下幾方面内容：

• 業務背景
• 業務架構
• 向量檢索
• 精排
• 總結和展望

01

業務背景

首先和大家分享下虎牙直播的業務背景。虎牙直播的推薦場景主要有以下三個：首頁的直播推薦、廣場的視頻推薦以及直播間的廣告推薦，當然還有很多小的場景，在這裡就不展開講了。

直播是一個頭部主播比較集中的場景，比較注重關系鍊、詞語以及長期的價值，業務訴求和其他推薦場景有所不同，在工程架構上會有所體現。但整體推薦模塊和流程與業界主流推薦架構基本一緻。

02

業務架構

接下來和大家介紹下虎牙直播的業務架構。

虎牙直播推薦架構中涉及的模塊和流程與業界主流通用的一些推薦架構基本一緻，部分模塊會有一些定制化的設計。接入層用來做透傳的工作，提供融合、降級、去重的功能；畫像層提供用戶和主播長期、短期以及實時特征的能力，還有一些召回、排序、重排模塊以及一些周邊的平台支持。

現在舉例說明下虎牙直播的推薦業務特點以及和通常的圖文、視頻推薦業務的區别。拿接入層的去重來說，一般的圖文、視頻推薦業務有比較強的去重需求，比如用戶看過了某篇文章、某個視頻，大概率是不希望看到相同或者相似的内容。業界常用的做法是用一個布隆過濾器來做長期的去重。在虎牙直播推薦場景，主播的标簽或信息會有比較大的不确定性，很多都是在開播的時候才能确定。例如打遊戲的主播可能下一時刻會做才藝類型的直播。所以在這個場景下的去重對時效性的要求比較高，同時需要不斷的優化調整。

在後面的分享中，我将會從向量檢索和精排兩個方向詳細介紹下虎牙直播的推薦架構。這兩塊涉及到了推薦系統中的大部分技術點，并且它們之間聯系得也比較緊密。

03

向量檢索

1. 背景

2016年，谷歌分享了youtube視頻推薦和搜索的向量檢索架構，同時該架構的落地取得了比較不錯的收益，目前很多推薦系統也都在嘗試通過優化embedding來提升業務指标，實際效果也非常可觀。

虎牙直播早期由于主播數量較少，主要是通過暴力檢索。随着業務的發展，基于成本和性能的考慮，暴力檢索已經沒有辦法滿足業務需求，于去年年初開始投入人力進行向量檢索方向的調研和落地。

我們調研了Facebook開源的向量檢索框架Faiss和谷歌開源的向量檢索框架ScaNN，ScaNN在算法上做了一些優化。

如上面兩圖所示，經過數據的驗證以及ann-benchmarks的壓測，ScaNN在性能和準召率都是表現較好的。由于ScaNN是相對較新的檢索庫，也很難找到其他企業開源的成功應用案例，但是經過部門同學的二次開發和封裝，使ScaNN能夠相對較好地集成到現有架構中去，方便使用。

2. 技術挑戰

向量檢索的技術挑戰主要有以下三點：

• 生産環境需要一個高吞吐、低延時、高可用的系統；
• 結合向量檢索的業務訴求，數據需要快速更新，系統需要具備一定的容錯能力；
• 需要提升數據構建的效率，保證線上服務的質量。

3. 架構落地

基于前面提到的挑戰，我們設計了如下的讀寫分離、文件化的架構：

索引builder構建：文件化；易調試、準召保證。索引builder構建主要負責向量的生産和索引文件的構建。使用npy二進制的文件格式，減少文件體積并易于調試。索引builder使用SDK與模型和特征進行交互，同時在調試時也可以使用，有比較好的可複用性。

分發系統使用了阿裡開源的Dragonfly，支持P2P的分發，打通了公司的文件系統。

在線Server部分在架構上拆解為檢索引擎和算子模塊，使用SDK接入。

檢索引擎：防抖動；多文件；多版本。檢索引擎目前支持ANN檢索和暴力檢索，采用通用的API執行流程，包含加載、卸載、雙buffer切換等環節。開啟實驗時，實驗組和新增的引擎做好關聯即可，

算子模塊組：易擴展；靈活。算子模塊組是按照通用的算子執行邏輯設計的，使用的是标準的輸入輸出，比較方便擴展和複用。

上線流程通過管理平台來配置，提升了系統的叠代效率。

下面介紹下向量在線檢索的過程，業務方集成的SDK通過用戶的id信息進行畫像的查詢，同時進行一些特征處理，然後請求模型生成向量，最後通過向量來進行檢索，根據請求的數量返回topk。SDK支持跳過以上的任意步驟，比如直接通過向量來進行檢索。滿足算法同學的調試需求和線上的實際使用需求。

在線檢索的時候，通過索引文件雙buffer的無鎖加載，支持批量查詢，保證了系統的高吞吐；通過純内存計算、LRU cache以及指令集優化保證了系統的低延時；通過builder和server的分離、存算一體（啟動速度加快）以及服務無狀态（方便快速擴容）保證了系統的高可用。同時，在服務啟動的時候也加了一些保護，比如：隻有在數據加載完成後，才能注冊到名字服務中，提供對外服務的能力。

向量檢索系統的數據加載是非常快的，下面介紹下數據更新的相關邏輯。首先，在配置中指定數據源和模型名稱，builder進行定時調度獲取任務信息，關聯公司其他平台的任務産出，利用SDK來生成向量、構建索引文件，并把文件推送到P2P的源數據節點。P2P的管理節點會定時檢測源數據目錄的文件産出。在線的server會啟動dfagent進程，定時和P2P集群的管理節點同步心跳，獲取管理節點上需要同步的資源列表。管理節點将需要同步的節點組成p2p集群，進行P2P的分發。200w數據集能在5s内完成内存化，在10s内完成分發。另外文件是以時間戳為版本，在線支持多版本，加載前會校驗，和攔截告警，整體流程1分鐘内生效。

在離線構建部分也做了一些優化以實現效能提升和安全保障。為了保證性能和準召率，我們開發了一些半自動的尋參工具，通過設置少量的參數和一些我們預設的經驗參數，進行自動化的評估，對比結果輸出最優的參數來提供線上使用。不過目前這個工具是一個單獨的離線工具，後續的話會集成到平台。builder節點支持橫向擴展，通過分布式鎖來進行任務的搶占和執行。單個builder節點支持多進程的并行構建，提升構建速度。針對每個構建任務的都支持一些定制化的一些指标校驗，校驗的指标主要是耗時、準召率、召回成功率等。目前，索引數據檢索Top20準召0.99的覆蓋率達到90%，攔截異常數據次數達15次以上，3個builder節點支持50個以上的任務，能在分鐘級完成構建。

最後介紹下系統的擴展性，目前我們在服務、數據、引擎三個方向都做到了不錯的擴展性。在服務層面，服務無狀态、離線builder通過分布式鎖來搶占保證了擴展性。在數據層面，在線server通過配置來加載不同的數據分片，離線builder也可以通過一些調整來保證擴展性。在引擎層面，主要同過以下三點來保證擴展性：

• 标準數據讀接口API，算子邏輯支持自定義；
• 存算一體，對數據管理的通用抽象；
• 多元異構數據的文件分發。

04

精排

1. 數據流

數據流主要包含離線訓練、在線打分、特征處理三個部分。特征處理主要通過離線和實時任務挖掘用戶或主播長期、短期的興趣以及實時的反饋特征，數據的來源和更新頻率差異很大。用戶畫像服務主要對接用戶的存儲和公司内外部的第三方接口，出于性能的考慮，用戶畫像設置了LRU緩存以及必要的降級策略，同時為了進一步提升本地緩存命中率，在上遊調用的時候使用了一緻性hash校驗。針對主播畫像，因為一次召回會有很多的主播，讀放大很嚴重，也采用了業界通用的本地化緩存方案，早期主播的數量較少，采用的直接異步同步存儲信息到本地構建雙buffer，數據完整性很難保證，正在往向量檢索架構上進行遷移。

2. 特征

為了能夠同時支持分析和訓練，我們也設計了明文特征向tfrecord轉換的過程和格式，使用ProtocolBuffers協議進行schema的校驗和管理。離線特征處理通過JNI調用extractor來實現和在線特征處理邏輯的一緻性。

3. 推理

最後分享下在推理服務上的優化，主要做了以下幾個事情：

• 适配公司的生态繼承。推理服務默認是gRPC協議，我們做了編譯的集成，以動态庫的形式集成到服務裡面，使推理服務能夠更加适配公司的生态。
• 采用了社區通用的優化方案，對模型進行預熱和并對模型服務提供獨立的線程池。
• 分發優化：高峰期通過帶寬限制，控制模型的下載帶寬。
• 輸入優化：一般的精排做法會帶來很多user側的特征複制，在數據傳輸上會有比較大的壓力，我們将用戶特征拷貝遷移至推理服務，減小了帶寬，取得了不錯的收益。

最終，經過我們對精排服務的優化，服務的穩定性能夠達到4個9，數據傳輸帶寬節省了50%以上。

05

總結和展望

最後，分享一下我們的未來展望。我們的架構還有很多需要優化的地方，我們會緊跟業務的前沿，不斷優化架構，持續完善我們的平台，提升系統的叠代效率。

作者：李茶 虎牙直播推薦工程組負責人

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!