搜推一體架構設計：搜索與推薦怎麼融合？四層架構與四階段落地
摘要：搜推一體架構的關鍵不是合併兩個系統，而是把資料層、召回層共用到底座上，只在排序與策略層分場景分離；落地順序為統一事件流 → 共用向量召回 → 分場景排序 → 策略聯動。
搜索與推薦各建一套索引、各記一份日誌，是大多數企業的現狀：搜索由技術團隊按查詢相關性維護，推薦由演算法團隊按用戶偏好維護。結果是同一個用戶在同一站點上的行為被切成兩半——搜過「連衣裙」的用戶，推薦位仍在推他三年前買過的品類；推薦位點擊率高的商品，搜索結果裡卻排在第五頁。
本篇邊界：本文是架構與實施篇，只回答「兩套系統怎麼在技術上融合」——四層架構職責、四階段落地與工程側度量。搜索與推薦為什麼要協同、業務價值怎麼算、組織怎麼配，見姊妹篇《搜索推薦一體化：為什麼 1+1>2？》，兩篇合起來才是完整答案。
關鍵要點
- 融合的第一原則是底座共用、策略分離：資料、召回共用，排序目標與干預規則分開。
- 融合的第一件事不是改演算法，而是把兩套系統的用戶行為日誌合併為一份事件流，並統一實體 ID。
- 向量檢索是搜索與推薦共用的天然通道：同一份向量索引既服務語義召回，也服務相似推薦。
- 四層架構職責清晰：資料層保一份事實源、召回層多通道並行、排序層分場景加權、反饋層閉環回流。
- 工程側度量看索引一致性、召回复用率與向量更新延遲；業務側增量看跨入口轉化（見姊妹篇）。
- 落地建議分四階段推進：日誌統一 → 召回共用 → 排序協同 → 策略聯動，每階段獨立驗收。
一、先劃邊界：融合不等於合併
架構設計的第一個決定是劃清「共用什麼」與「分離什麼」。
必須共用的：實體 ID 與商品／內容索引、用戶行為事件流、向量通道、畫像與特徵工程。這些是兩側都要讀的同一份事實，各建一遍等於把基礎設施成本付兩次。信號割裂的代價也來自這裡——用戶搜索「輕薄羽絨服」沒下單，這條強意圖只落在搜索日誌裡，推薦讀不到。
必須分離的：排序目標與干預規則。搜索必須保障「查什麼出什麼」的相關性下限，這是信任基礎；推薦的目標則是轉化與多樣性，需要探索空間。兩側優化目標不同，共用一套排序模型會互相拖累。Netflix 在技術博客中把推薦系統的計算劃分為離線（offline）、近線（nearline）與在線（online）三層，並指出關鍵難點在於「如何把三種計算模式無縫結合管理」——搜索系統同樣面臨這三層結構，但三層之上的目標函數必須各寫各的。
一句話概括：底座共用、策略分離。後文的四層設計都遵循這條線。
二、協同的技術底座：統一索引與共用召回
協同落地的第一層是資料與索引。這一層做紮實，後面的排序協同才有基礎。
2.1 統一用戶事件流
把搜索與推薦的行為日誌合併為一份事件流，至少包含：事件類型（搜索／點擊／加購／收藏／下單／停留）、主體 ID（用戶、商品、內容）、上下文（時間、終端、入口位置）、查詢詞（僅搜索事件有）。
合併的價值在於構造完整的興趣序列：一個用戶「搜索 A → 點擊 A1 → 未購買 → 三天後從推薦位點擊 B → 下單 B」的完整鏈路，只有在事件流統一後才能被看見。這條鏈路既是推薦模型的訓練樣本，也是搜索排序裡「該用戶偏好」的即時信號。
2.2 統一索引與向量通道
第二層是把商品／內容索引收斂為一份，並同時構建倒排索引與向量索引。Elasticsearch 官方文檔將檢索流程劃分為查詢構造、召回與打分三個階段，向量檢索則把文本、圖像等映射為稠密向量後按相似度召回——同一份向量索引，既可以做「搜索詞語義召回」，也可以做「相似商品推薦」，這正是兩者共用的天然通道。
工程上，稠密向量的相似度檢索通常由專門的庫承擔。Meta 開源的 FAISS 提供了大規模向量的聚類與近似最近鄰檢索能力，是這類通道的常見底座選擇。
| 能力 | 搜索側用途 | 推薦側用途 | 是否共用 |
|---|---|---|---|
| 倒排索引 | 關鍵詞精確召回 | 類目／屬性過濾 | ✅ 共用 |
| 向量索引 | 語義召回（搜「保暖外套」出羽絨服） | 相似物品召回（看了又看） | ✅ 共用 |
| 用戶畫像 | 個性化排序權重 | 召回候選源 | ✅ 共用 |
| 行為事件流 | 查詢詞分析與糾錯 | 興趣序列建模 | ✅ 共用 |
| 排序模型 | 相關性優先 | 多樣性 + 轉化優先 | ❌ 分場景 |
| 干預規則 | 必出／屏蔽詞 | 運營置頂／打散 | ❌ 分場景 |
三、一體化架構的四層設計
底座統一之後，一體化架構可以拆成四層：資料層、召回層、排序層、反饋層。每層的職責與協同點如下。
3.1 資料層：一份事實源
資料層負責把商品主資料、內容中繼資料、用戶行為事件、上下文信號匯入同一處，並對外提供一致的讀取介面。關鍵約束是實體 ID 全域唯一——同一件商品在搜索索引與推薦候選池裡必須是同一個 ID，否則跨系統的行為無法歸併。
3.2 召回層：多通道並行
召回層同時開放多路通道：倒排關鍵詞召回、向量語義召回、協同過濾召回、熱銷／新品等規則召回。協同發生在通道復用上——搜索場景調用「關鍵詞 + 向量」兩路，推薦場景調用「協同過濾 + 向量」兩路，向量通道由兩者共用。
3.3 排序層：分場景加權
排序層是必須分開的一層。搜索排序的首要目標是相關性，用戶輸錯了詞就不能給出無關結果；推薦排序的目標是轉化率與多樣性，允許適度探索。
可行的做法是共用底層模型、分場景調整目標權重：搜索場景給相關性特徵更高權重，推薦場景給協同信號與多樣性特徵更高權重。這樣既復用特徵工程與模型訓練基礎設施，又不犧牲各自的目標。
3.4 反饋層：閉環回流
反饋層把曝光、點擊、加購、下單等結果回流到資料層，同時驅動兩類動作：一是刷新用戶畫像與物品畫像，二是調整召回通道的配額。Netflix 提到在線計算響應即時但受限於複雜度、離線計算能力強但容易陳舊，反饋層的設計要點正是區分哪些信號必須即時回流（如曝光去重）、哪些可以批量更新（如長期興趣）。
四、實施路徑：從並行到融合的四個階段
協同不必一步到位。按以下四階段推進，每階段獨立驗收，風險與投入都可控。
階段一：日誌與 ID 統一（2–4 週）。 打通搜索與推薦的行為事件流，統一商品與內容 ID 映射。驗收標準：能按用戶 ID 還原跨系統的完整行為序列，跨系統 ID 映射覆蓋率達到 95% 以上。
階段二：索引與向量通道共用（4–8 週）。 構建統一索引，引入向量召回並同時接入兩側。驗收標準：搜索側語義召回覆蓋率提升，推薦側相似召回复用同一份向量，索引維護成本由兩套降為一套。
階段三：排序協同（6–10 週）。 共用特徵與底層模型，分場景設定目標權重；搜索側引入個性化重排，推薦側引入搜索意圖信號。驗收標準：兩側核心指標（搜索轉化率、推薦點擊率）均不低於改造前基線。
階段四：策略聯動（持續）。 按用戶當前意圖動態分配搜索結果與推薦位的流量配比：明確意圖時以搜索為主、推薦位收窄為同類補充；弱意圖時以推薦探索為主。驗收標準：整體轉化率與人均瀏覽深度同步提升。
五、架構落地怎麼度量
這一層只回答「工程改造成不成立」，業務增量（跨入口轉化、人均 GMV）的口徑見姊妹篇《搜索推薦一體化：為什麼 1+1>2？》，兩層的指標不要混在一張表上算。
建議盯四組工程指標：
| 指標 | 含義 | 階段驗收參考 |
|---|---|---|
| 跨系統 ID 映射覆蓋率 | 同一商品在搜索索引與推薦候選池中是同一個 ID 的比例 | 階段一 ≥ 95% |
| 召回复用率 | 向量／倒排通道被兩側同時調用的比例 | 階段二較改造前提升，索引由兩套降為一套 |
| 向量更新延遲 | 新品／新內容從入庫到可被向量召回的時間 | 階段二控制分鐘級 |
| 兩側核心指標基線 | 搜索轉化率、推薦點擊率不低於改造前 | 階段三逐場景回歸，不降為準 |
前三項決定「底座是否真的共用起來了」，第四項是安全線——架構改造不應以犧牲單側指標為代價。
六、架構落地的四個技術坑
- 雙寫不一致：商品主資料同時寫搜索索引與推薦候選池，任一側失敗就會出現「搜索有、推薦沒有」的幽靈商品。應改為單一事實源 + 兩側訂閱，而不是兩次獨立寫入。
- 向量漂移：向量模型升級後，舊向量與新向量不在同一空間，混檢會讓相似度失真。升級必須全量重建並灰度切換，禁止新舊向量同庫混合召回。
- 延遲預算被吃掉：向量召回疊加在關鍵詞召回之上，首字延遲會上升。多路召回要設並發與超時，超時的通道直接降級為不參與，而不是讓整體等待。
- 排序層被誤共用：把搜索的相關性模型直接拿去排推薦位，相關性高但千篇一律，推薦點擊率反而下降。排序層必須分場景設定目標權重。
這四個坑都屬於工程實現範疇，與姊妹篇講的「業務側誤區」（共用一套評估指標、一次性全量切換等）不在同一層，落地時兩邊都要過一遍。
常見問題
問：搜索和推薦應該合併成一個系統嗎？
答：不建議完全合併。兩者優化目標不同：搜索必須保障「查什麼出什麼」的相關性下限，推薦則需要多樣性與探索空間。正確做法是底座共用（索引、向量、用戶事件流、特徵工程），策略層分離（排序目標、干預規則、評估指標各自獨立）。
問：協同改造先做哪一步性價比最高？
答：先統一用戶行為事件流與實體 ID。這一步投入最小、不涉及演算法改造，但決定了後續所有模型的樣本質量。日誌沒打通就做聯合排序，模型拿到的仍是殘缺樣本，效果上限被資料卡住。
問：向量檢索為什麼適合作為共用通道？
答：因為同一份向量索引天然服務兩種召回：搜索側用語向量做語義召回，解決「詞不匹配但意圖匹配」（搜保暖外套出羽絨服）；推薦側用物品向量做相似召回，解決「看了又看」。一次構建、兩處復用，是協同成本最低的切入點。
問：搜索結果頁裡放推薦位會不會傷害體驗？
答：取決於是否做意圖判斷。用戶查詢詞明確（如具體型號、品類詞）時應以相關性結果為主，推薦位收窄為同類補充或不展示；查詢詞寬泛（如「送女友」、「夏天穿」）或零結果時，推薦位才有明顯增益。不做區分地混排會破壞搜索的可信度。
問：協同之後怎麼判斷帶來的到底是增量還是流量搬家？
答：看跨入口轉化率。統計「從搜索進入、最終在推薦位成交」與「從推薦位進入、最終在搜索成交」的佔比與絕對值。跨入口轉化上升說明兩個入口在互相導流；總轉化上升但跨入口轉化不變，多數只是流量在兩個入口之間重新分配，不是新增量。
問：小團隊沒有演算法工程師，能做一體化嗎？
答：可以從規則層做起。先做三件事：統一行為日誌、用現成的向量檢索能力（如開源向量庫）構建一路語義召回、在搜索無結果或弱結果時降級到推薦位補位。這三項都不需要自研模型，但能覆蓋協同收益中的大部分。
關於通智雲
通智搜尋面向本文描述的搜索與推薦一體化場景，提供統一索引、語義向量召回與分場景排序能力，支援零結果補位與跨入口行為回流。通智雲（TENGENCE）是 AI 時代的企業增長引擎，專注公域引流獲客與私域轉化成交；核心產品為通智 GEO（GEO + SEO 雙引擎）與通智搜尋。
相關閱讀
- 搜尋推薦一體化：為什麼 1+1>2？
- 甚麼是推薦系統？召回、排序、重排三層架構解析
- 什麼是站內搜尋？原理、核心指標與能力框架
- 千人千面推薦的原理：從協同過濾到深度學習
- 電商站內搜尋優化方案：5 步提升搜尋轉化率
資料來源
- Netflix TechBlog《System Architectures for Personalization and Recommendation》：推薦系統的計算劃分為離線、近線、在線三層，在線響應即時但受複雜度限制、離線能力強但易陳舊，關鍵難點在於如何把三種模式無縫結合管理。
- Elasticsearch 官方指南《Search your data》：檢索流程由構造查詢、召回候選與打分排序構成，是搜索側召回與排序分離的權威說明。
- Elasticsearch《What is vector search?》：向量檢索把文本、圖像等非結構化資料映射為稠密向量並按相似度召回，用於語義匹配與相似物品檢索。
- FAISS（Meta AI Research）官方倉庫：提供大規模稠密向量的聚類與近似最近鄰檢索演算法庫，是向量召回通道的常見工程底座。
