最近和產品團隊同事討論推薦系統時，發現大家對於推薦系統流程缺乏共通的語言，導致在溝通時耗費了較多時間來釐清「目前討論的推薦系統的哪一個步驟」
為了提升溝通效率，我分享了一部講解推薦系統流程的影片（觀看影片），並藉此文章記錄影片內容，補充我個人的理解以及公司的實際案例
推薦的核心
在介紹推薦系統流程之前，先介紹一下「推薦」這件事實際上在做什麼。多數推薦系統的應用場景都是：「推薦適合的 item 給 user」
舉影片提到的小紅書為例，user 是使用者，item 是內容（文章或影片） ；而以我們公司的獵人頭平台為例，推薦的目標是希望幫 Job 找到適合的人選，因此 user 是 JD，item 是人選
召回（Retrieval）
推薦系統的第一步是召回，目的是從龐大的 item pool 中挑選出一群適合的 items。召回的主要目標是大量減少潛在可考慮的 items 數量（後稱 candidates），在這一步精準度不必特別高，因此通常使用簡單的邏輯或演算法進行篩選
例如，影片中提到的「關注的作者內容推薦」，未經機器學習演算法，只依賴用戶特徵進行篩選；我們公司的案例則是透過「JD 與 Resume 的文本相似度」來進行召回
在召回時，縮減 candidates 的數量至關重要，但也需謹慎避免過早篩掉合適的 candidates。實務上常會採用多路召回的方式，結合多種邏輯與演算法，以確保能夠包含更多可能的適合 items
因為有了篩選的步驟，就有可能會在這一階段把適合 user 的 items 濾掉。而我們之所以願意冒這個風險，不是直接幫所有 item 算一個之於 user 的興趣分數，其中的原因在於「運算成本」（包含時間與金錢成本）。
如果 item pool 很大，在每個 user 進來時都要幫所有的 item 計算興趣分數，一來會運算很久，讓產品使用者體驗不好；二來也會造成很大的機器負擔，需要用較高規格的機器才有辦法完成運算，這兩點對於系統來說都是不小的成本，因此需要透過召回的步驟讓我們可以在更短的時間用更少的資源完成運算。
粗排與精排
粗排和精排的主要目的都是對召回的 candidates 進行打分和排序。兩者的差異在於 candidates 的數量：粗排的 candidates 數量較多，因此不會使用過於複雜的演算法；而精排的 candidates 數量較少，則可以使用更複雜但精準度更高的演算法
在我們公司的案例中，粗排使用我們訓練好的機器學習模型快速打分，而在精排階段，則利用大型語言模型（LLM）根據 JD 對粗排後的前十名 candidates 進行重新排序
這樣的架構主要考量了幾個因素：
- LLM 的擴展性：可輕鬆實現推薦邏輯的客製化，像是如果想考慮用戶的偏好（e.g. 客戶喜歡有新創背景的 resume），只需要把這個邏輯加到 prompt 就可以，不需要重新訓練模型
- 運算成本：由於 LLM 的計算成本較高，因此不適合用於數量級較大的排序，前面還是需要透過機器學習模型進行初步打分。
需要補充的是，雖然粗排和精排都是在排序，但由於場景不同，表現優異的演算法不一定適用於另一個階段
舉例來說：
推薦的目標是推薦讀者有興趣閱讀的書籍，而在粗排的階段，可能會根據讀者過去閱讀的歷史，推薦一批相同類型或相似主題的書籍，如科幻小說類書籍。在精排的階段，會再根據書籍的熱門程度、近期出版的熱度或書籍的讀者評價做進一步排序
在這個情境下，如果直接把精排的邏輯套用在粗排上，可能會推薦出近期熱門但不符合該讀者個人喜好的書籍，忽略了讀者偏好科幻小說這一粗排的關鍵特徵，導致排序結果不佳
重排
推薦系統的最後一個步驟為重排，主要是為了滿足一些在純排序時無法考慮到的商業目標
舉影片中提到的「多樣性抽樣」為例，之所以需要在排序完後再做多樣性抽樣，主要是希望讓使用者可以看到更多不同類型的內容，這件事有助於長期的留存。如果不做這件事，用戶可能會一直看到相同類型的內容推薦，看久了就容易流失。但有了內容推薦的多樣性後，雖然可以會推出一些用戶不喜歡的內容，犧牲一些短期的指標（如點擊率），但有機會讓用戶發掘新的他有興趣的內容，進而提升留存率以及使用時長，有助於滿足平台的商業目標
謝謝你看到這邊，如果你看完文章後有任何想法或建議，都很歡迎在留言區提出分享！或是歡迎加我的 Linkedin 與我交流
