字節跳動系統設計面試真題：設計抖音推薦系統的完整思路

字節跳動系統設計面試真題：設計抖音推薦系統的完整思路

背景介紹

我是在2024年3月面的字節跳動，崗位是後端開發工程師，3年經驗。說實話，字節的系統設計面跟我想像的完全不一樣——不是那種「畫個架構圖就完事」的套路，而是真的會追著你問細節，問到你答不上來為止。我面的這個組正好是抖音推薦方向，所以面試官直接讓我設計抖音的推薦系統。當時我緊張得手心都在出汗，但好在之前準備過推薦系統的通用方案，所以還是硬著頭皮撐下來了。下面是我對這次面試的完整複盤。

面試流程複盤

面試官是一位看起來三十出頭的工程師，自我介紹說是抖音推薦架構組的。整個面試大概50分鐘，節奏非常緊湊。

前5分鐘：面試官簡單介紹了面試流程，然後直接進入正題：「請你設計一個類似抖音的短視頻推薦系統。」我按照之前準備的框架，先問了一堆需求澄清的問題。

5-15分鐘：需求澄清階段。我問了以下幾個關鍵問題：

1. 用戶規模？——面試官說「假設日活3億」。

2. 推薦目標？——「最大化用戶觀看時長和互動率」。

3. 實時性要求？——「用戶剛看完一個視頻，下一個視頻就要能反映這個行為」。

4. 冷啟動怎麼處理？——「新用戶和新視頻都要考慮」。

5. 內容安全？——「需要內容審核機制」。

面試官對我問的這些問題似乎比較滿意，點了點頭說「繼續」。

15-35分鐘：這是最核心的環節，我按照召回→排序→重排三層架構來講解。面試官在每個環節都追加了深入的問題，比如「協同過濾的冷啟動怎麼解決？」「精排模型用的什麼？」「怎麼保證推薦多樣性？」我逐一回答，有些回答得比較流暢，有些則磕磕絆絆。

35-45分鐘：面試官開始追問工程實現細節，比如「特徵怎麼實時更新？」「A/B實驗怎麼做？」「怎麼處理視頻的embedding？」這部分我覺得自己回答得一般，有幾個點確實沒想清楚。

最後5分鐘：面試官讓我問問題，我問了團隊的技術棧和推薦系統的迭代節奏。

真題匯總：設計抖音推薦系統

一、整體架構設計

我畫了一個三層架構圖：召回層（Recall）→排序層（Ranking）→重排層（Re-ranking）。面試官看了一眼說「基本框架沒問題，展開講講每一層」。

二、召回層設計

召回層的目標是從數億條視頻中篩選出幾千條候選集。我設計了四路並行召回：

1. 協同過濾召回：基於用戶行為矩陣，用ItemCF找到相似視頻。面試官追問「冷啟動怎麼辦」，我回答新視頻先走內容召回，積累足夠行為數據後再加入協同過濾池。

2. 內容召回：基於視頻的標籤、分類、embedding做相似推薦。這裡我提到了用雙塔模型分別提取用戶特徵和視頻特徵，然後做向量內積。面試官追問「向量檢索用什麼」，我回答FAISS或HNSW，支持十億級向量的毫秒級檢索。

3. 熱門召回：按地區、時段統計熱門視頻，保證新用戶也能看到優質內容。面試官追問「怎麼避免信息繭房」，我回答熱門召回只佔候選集的一小部分（約10%），並且會加入隨機探索機制。

4. 社交召回：關注的人看過的視頻、好友點讚的視頻。這個召回路徑的點擊率通常最高，但覆蓋面有限。

面試官對召回層的設計基本認可，但指出了一個我遺漏的點：召回去重。用戶看過的視頻、不感興趣的視頻需要在召回階段就過濾掉，否則會浪費排序層的計算資源。

三、排序層設計

排序層的目標是從幾千條候選中精選出幾百條。我分了粗排和精排兩步：

1. 粗排：用輕量級模型（如雙塔模型）快速打分，把幾千條候選縮減到幾百條。核心要求是低延遲，每個視頻的打分時間控制在1ms以內。

2. 精排：用深度學習模型（如DIN、DIEN、MMOE）做多目標優化。我詳細講了精排的幾個關鍵設計：

- 多目標優化：同時預測點擊率（CTR）、完播率、點讚率、評論率、分享率，最終用加權公式融合。面試官追問「權重怎麼定」，我回答「通過線上A/B實驗調優」。

- 特徵工程：用戶特徵（歷史行為序列、畫像標籤）、視頻特徵（時長、清晰度、標籤embedding）、上下文特徵（時間、網絡、設備）。其中用戶行為序列是最重要的特徵，用Attention機制提取與當前候選視頻相關的行為。

- 訓練數據：用曝光未點擊作為負樣本，但要注意樣本選擇偏差問題。面試官追問「怎麼解決」，我回答用隨機負採樣補充未曝光樣本。

四、重排層設計

重排層的目標是在精排結果上做業務規則調整和多樣性保證：

1. 多樣性控制：用MMR（Maximal Marginal Relevance）算法，在相關性和多樣性之間取平衡。避免連續推薦同類視頻。

2. 業務規則：廣告插入位、運營活動視頻保量、敏感內容過濾。這些規則會覆蓋模型排序結果。

3. 上下文調整：根據當前時間段（如深夜推助眠內容）、網絡狀態（弱網推短視頻）做動態調整。

五、實時特徵更新

這是面試官重點追問的環節。抖音推薦系統的核心優勢是實時反饋——用戶剛看完一個搞笑視頻，下一條就要推類似的。

我的設計方案：用戶行為→Kafka→Flink流式處理→特徵更新→模型推理。

具體來說，用戶的每次播放、點讚、劃走行為都實時寫入Kafka，Flink消費後更新用戶的實時特徵（如最近10條觀看記錄、當前session興趣標籤），更新後的特徵寫入Redis，精排模型推理時從Redis讀取。

面試官追問「實時特徵的延遲要求」，我回答「端到端延遲控制在500ms以內」。面試官又問「怎麼保證這個延遲」，我提到了幾個優化點：Flink用滾動窗口而非事件時間窗口減少等待；Redis用Pipeline批量讀寫；模型推理用GPU推理服務。

六、A/B實驗平台

面試官問「你怎麼驗證推薦算法的效果」。我講了A/B實驗的設計：

1. 分層實驗：召回層、排序層、重排層各有一層實驗，不同層的實驗正交，互不影響。這樣召回層實驗A和排序層實驗B可以同時運行。

2. 流量劃分：按用戶ID哈希分桶，保證同一用戶始終在同一組。實驗組通常佔5%-10%流量。

3. 指標監控：核心指標（人均觀看時長、互動率）+護欄指標（負反饋率、舉報率）。護欄指標不能惡化，否則實驗立即回滾。

七、冷啟動策略

新用戶冷啟動：註冊時選擇興趣標籤→熱門召回+興趣標籤召回混合→快速積累行為數據→逐步切換到個性化推薦。

新視頻冷啟動：新視頻先進入探索流量池（約5%流量），根據初始反饋決定是否擴大推薦。表現好的視頻會逐步進入更大的流量池，類似「賽馬機制」。

心得建議

1. 推薦系統的面試一定要按「召回→排序→重排」三層來講，這是業界標準框架，面試官一看就知道你懂行。

2. 不要只講算法，要講工程實現。面試官更關心你怎麼把模型落地，而不是模型本身有多先進。實時特徵更新、A/B實驗、冷啟動這些工程問題才是區分度。

3. 主動提trade-off。比如「粗排用簡單模型犧牲精度換延遲，精排用複雜模型犧牲延遲換精度」，這種表述非常加分。

4. 準備一些具體數字。比如「召回層從10億篩選到5000，粗排從5000篩選到500，精排從500篩選到100」。有數字比純文字更有說服力。

5. 字節的面評風格是「追到底」，面試官會一直追問直到你答不上來。這是正常的，不要慌，能答到什麼程度就答到什麼程度。

FAQ

Q：字節系統設計面一般面幾輪？

A：通常2-3輪系統設計面，第一輪偏通用架構，第二輪偏具體業務場景，第三輪可能是跨領域的綜合題。

Q：推薦系統面試需要了解哪些論文？

A：Deep Interest Network（DIN）、Deep Interest Evolution Network（DIEN）、Deep & Cross Network、Wide & Deep Learning。不用每篇都精讀，但核心思想要能講清楚。

Q：沒有推薦系統經驗怎麼辦？

A：可以從通用系統設計角度出發，把推薦系統拆解為「數據採集→特徵工程→模型訓練→在線服務」四個模組來講解。面試官更看重你的系統設計能力，而不是推薦算法的專業知識。