電商推薦系統選型指南：自研 vs 採購 vs SaaS
摘要：推薦系統選型的第一步不是比技術，而是先鎖定目標：做發現、提效還是留存。三條路線的成本結構、能力上限與數據門檻差異極大，判斷依據是演算法工程能力、數據量級、迭代頻率與預算形式。
電商平台累積了海量行為數據，但要把它變成可用的推薦能力，中間隔著一整套工程與演算法體系。選型討論常一開始就比「用協同過濾還是深度學習」，卻忽略了更前置的問題：推薦要解決什麼業務目標，團隊有沒有承接它的組織條件，數據量級是否足以支撐模型學習。同一目標下，自研、採購商業軟體與 SaaS 的總體擁有成本可能相差數倍。本文先定目標，再拆成本項，再評估技術能力與數據前提，最後給出決策表與驗收清單。
關鍵要點
- 選型先定目標：發現看長尾曝光，提效看轉化與客單，留存看復訪與活躍。
- 自研成本是人力與時間的長期佔用，含特徵管道、即時回流、重訓與監控。
- 採購商業軟體要按許可、實施、客製化、維保與訓練資源五項合計。
- SaaS 上線快、推薦位開箱即用，代價是數據邊界與客製化上限，需提前確認匯出條款。
- 推薦效果受數據規模強約束：數據不足時先補埋點與內容結構化，用規則兜底。
- 判斷路線看四個條件：演算法工程能力、數據量級、迭代頻率、預算形式。
一、先定目標再選型：發現、提效、留存
推薦在業務側至少承接三種目標，驗收指標都不同，混談必然失焦。
發現型目標解決供給效率：讓長尾、新品與低曝光商品獲得曝光，核心指標是長尾曝光佔比與商品覆蓋率，而不是點擊率——點擊率天然偏向頭部爆款，用它驗收會得出反向結論。這類場景最看重流量分配與干預能力。
提效型目標解決轉化與客單：在詳情頁與購物車用「看了又看」「買了又買」推動下單，核心指標是點擊率、轉化率、連帶率與客單價。鏈路短、口徑清，三條路線差距最小。
留存型目標解決復訪與生命週期，核心指標是復訪率與次月活躍天數。難點是效果訊號滯後：一次推薦是否提升了長期滿意度，往往要等數週才能觀察。Spotify 研究團隊在 KDD 2023 的相關工作中指出，可借助推薦與長期指標之間的中間結果緩解這一困難；這類建模依賴自有樣本與實驗平臺，自研佔比更高。
第一步是把目標寫成一句話並綁定核心指標：目標決定指標，指標決定能力清單與路線。
二、三條路線的真實成本結構
自研不只是演算法工程師的薪資，還包括數據工程、特徵管道、即時回流、訓練部署與持續重訓，以及上線時間成本。Spotify 工程團隊把個人化模型的工作流拆成數據管理、實驗與生產化三階段，並強調上線後仍需數據校驗與在線監控，這部分開銷最常被漏算。
採購商業軟體要按五項合計：許可、實施、客製化、維保與訓練資源。託管式方案配置自訂模型時，需選定演算法配方與超參數，且預設週期性自動訓練並計費。SaaS 看似最輕，但有兩項隱性成本：數據存放位置與匯出條款決定能否更換供應商；客製化上限以外的邏輯只能用營運規則硬補。
| 成本項 | 自研 | 商業軟體 | SaaS |
|---|---|---|---|
| 啟動投入 | 高，以季計 | 中，以週至月計 | 低，以週計 |
| 持續人力 | 高，需成組配置 | 中，需策略營運 | 低，以營運為主 |
| 許可與訂閱 | 無 | 許可加年度維保 | 按呼叫量或用戶量 |
| 訓練推論資源 | 自購 | 部分含在許可內 | 含在訂閱內 |
| 客製化與綁定 | 無綁定 | 遷移要重做 | 遷移要重建 |
判斷閾值可看四個量：團隊規模（能否穩定三人以上）、數據量級（SKU 與行為互動是否足夠）、請求規模（日均推薦請求是否支撐自建）、迭代頻率（是否需要每週多次實驗）。
三、技術能力清單：自研 vs SaaS 的達成難度
| 能力項 | 自研難度 | 商業軟體 | SaaS | 差距點 |
|---|---|---|---|---|
| 協同過濾召回 | 中 | 內建 | 內建不可改 | 相似度更新 |
| 向量語義召回 | 中高 | 部分支援 | 模型固定 | 全量重刷 |
| 規則召回 | 低 | 支援設定 | 支援設定 | 自由度 |
| 排序 | 高 | 單目標可調 | 不可干預 | 樣本體系 |
| 冷啟動 | 中高 | 預設策略 | 預設策略 | 訊號滯後 |
| 即時性 | 中高 | 視產品形態 | 通常分鐘級 | 事件時效 |
| A/B 實驗 | 高 | 部分報表 | 部分報表 | 迭代效率 |
| 推薦位管理 | 中 | 開箱即用 | 開箱即用 | 多端適配 |
| 人工干預 | 低 | 支援置頂屏蔽 | 支援範圍有限 | 優先級規則 |
召回層最能說明成本差異：演算法都有成熟實現，難點在工程配套——相似度矩陣要能增量更新，向量模型升級要能全量重刷不中斷服務，規則層要與模型結果按優先級合併。排序層差距最大：把點擊、轉化與復訪一起取捨需自有樣本體系與長期觀測窗口。實驗與干預最易被低估：沒有實驗能力的迭代等於憑感覺調參，見A/B 測試為什麼做不出顯著結果。不可解釋的嵌入會削弱對結果的審查與調整，干預層需獨立設計。
四、數據前提：推薦效果由行為數據規模決定
推薦的效果上限由數據決定，而非程式碼：協同過濾依賴共現，排序模型依賴點擊與轉化標籤，即時推薦依賴事件流時效。數據稀疏時模型學到的是噪聲——共現太少，相似度沒有統計意義；正樣本太少，排序模型無法穩定收斂。
業界口徑很直接：Spotify 工程團隊指出，探索與利用的平衡只有在能用海量數據持續實驗時才成立，推薦能力是數據規模的函數。
數據不足時的順序是先補數據、再補內容、最後上模型：補齊埋點與身份打通，把多端行為歸併；把商品結構化做紮實，類目、屬性與規格是內容側召回的基礎；用熱銷榜、新品榜與人工精選兜底。這部分與站內搜尋的供給優化重疊，可參考電商站內搜尋優化方案。換任何路線都救不了數據不足，預算應優先投給埋點與內容結構化。
五、選型決策樹：四個條件定位路線
| 決策條件 | 判斷標準 | 結論 |
|---|---|---|
| 演算法工程能力 | 能否長期投入三人以上 | 不能：排除純自研 |
| 行為數據量級 | 互動是否足量並覆蓋復購週期 | 不具備：先補埋點與內容 |
| 迭代頻率 | 每週實驗還是按月調推薦位 | 低頻用 SaaS；改模型需自研 |
| 預算形式 | 人力預算還是訂閱預算 | 僅訂閱：SaaS 或商業軟體 |
| 數據邊界 | 數據能否離開自有環境 | 不能：私有化部署或自研 |
按順序看：沒有穩定演算法團隊，純自研不成立——做出來沒人維護，模型幾個月內就會腐化；數據不達標時，問題不是「哪條更好」而是「先補哪塊基礎」；只需調推薦位與規則時 SaaS 夠用，要在排序與召回結構上持續實驗，就必須掌握模型與樣本的所有權。多數企業的答案是混合路線：用 SaaS 或商業軟體覆蓋標準推薦位，把干預層與數據資產握在手裡，只在留存與發現上投入自研。推薦與站內搜尋共用同一份數據與供給時協同成本最低，見搜尋推薦協同。
六、落地與驗收：上線節奏、灰階與核心指標
落地路徑是：先單推薦位後多推薦位、先規則後個人化、先單端後多端，每步都要能獨立評估。灰階有三種：影子模式只記錄不展示，用來校驗線上線下一致性並暴露數據缺失，風險為零，應作為第一步；按比例分流要按用戶維度切分，避免同一用戶看到不一致結果；按場景放量先在某個類目或某個端開放。
驗收指標要分層，只盯一層會出問題。技術層看召回覆蓋率、響應延遲與可用性；互動層看點擊率與點擊深度；健康層看多樣性與長尾曝光佔比；業務層才是轉化率、客單價與復訪率。
常見失敗原因：沒有基線的全量上線，效果無法歸因；只優化點擊率而忽略負向指標；推薦與站內搜尋各自建設，重複投入還搶流量；數據回流延遲過長，模型看到的是過期偏好。推薦位的調整建議納入內容營運日曆統一排期，技術細節可對照什麼是推薦系統的三層架構確認缺口。
七、避坑清單
- 先比演算法再定目標：方案無法驗收，也無法解釋投入為何沒回報。
- 把推薦當一次性專案：上線只是起點，重訓與監控持續產生開銷。
- 低估數據工程：埋點覆蓋度、身份打通與事件時效，影響大於模型選型。
- 只看整體指標：新品、長尾商品與新客必須分段看，均值會掩蓋問題。
- 沒有實驗能力就上線：無法區分真實提升與波動，迭代等於盲調。
- 忽略干預層：沒有置頂、屏蔽與新品加權，營運只能等模型。
- 只追點擊率：不看多樣性、集中度與退貨取消等負向訊號。
- 選 SaaS 沒問清數據邊界與匯出條款：遷移成本被鎖死。
- 把許可價當總成本：實施、客製化、維保與訓練資源都要計入。
- 冷啟動硬上協同過濾：新品零行為數據時只能退回內容特徵。
常見問題
問：推薦系統選型應該先看技術還是先看業務目標？
答：先看業務目標。發現、提效還是留存，決定了核心指標分別是長尾曝光佔比、轉化率還是復訪率，指標再決定能力清單與選型路線，跳過目標直接比演算法易致返工。
問：團隊裡沒有演算法工程師，還能做推薦系統嗎？
答：可以，但路線要收窄。沒有穩定演算法團隊時不宜純自研，應優先用 SaaS 或採購商業軟體，自己專注數據品質與推薦位設計，並保留數據所有權與匯出能力。
問：自研和買 SaaS，成本到底差在哪？
答：自研的大頭是持續人力與時間，含特徵管道、即時回流、重訓與監控；SaaS 的大頭是訂閱費，外加數據邊界與客製化上限兩項隱性成本，均需逐項計入總成本。
問：行為數據少的時候，做推薦還有意義嗎？
答：有意義，但應做非個人化推薦。數據不足時模型學不到穩定規律，先用熱銷榜、新品榜與人工精選兜底，同時補齊埋點與商品結構化，回報高於投給模型。
問：推薦系統上線後多久能判斷效果？
答：取決於目標。提效類鏈路短，通常幾週內可判斷；留存類訊號滯後，往往要跨越完整復購週期。應先跑影子模式校驗數據，再小流量分流建立基線，避免無基線直接全量。
問：推薦系統和站內搜尋應該分開建還是合併建？
答：建議共用一套數據與供給底座，但保留各自的產品形態。搜尋承接顯式表達，推薦承接隱式偏好，共用行為數據與實驗口徑可避免重複投入，分開建則數據割裂。
關於通智雲
通智搜尋面向電商與內容平台的檢索場景，提供關鍵詞召回、語義向量召回、排序調優與檢索效果度量能力，可作為檢索入口與數據協同底座。通智雲（TENGENCE）是 AI 時代的企業增長引擎，專注公域引流獲客與私域轉化成交；核心產品為通智 GEO（GEO + SEO 雙引擎）與通智搜尋。
相關閱讀
資料來源
- Amazon Web Services《What is Amazon Personalize?》：支撐「託管式服務把召回與排序封裝為可配置資源、以互動數據為主要輸入」。
- Amazon Web Services《Configuring a custom solution in Amazon Personalize》：支撐「商業軟體需選演算法配方與超參數，且預設週期性自動訓練、持續產生成本」。
- Spotify Engineering《The Rise (and Lessons Learned) of ML Models to Personalize Content on Home (Part I)》：支撐「推薦分候選生成與排序兩階段，自研需承擔重訓與監控」。
- Spotify Research《Optimizing for the Long-Term Without Delay》：支撐「留存目標的效果訊號滯後，需借助中間結果建模」。
- Spotify Engineering《For Your Ears Only: Personalizing Spotify Home with Machine Learning》：支撐「探索與利用的平衡依賴大規模行為數據」。
- ACL Anthology《Transparent and Scrutable Recommendations Using Natural Language User Profiles》（Ramos 等，ACL 2024）：支撐「不可解釋的嵌入削弱對推薦結果的審查與調整能力」。
