前言

蘑菇街的願景是讓一半人類更幸福，而讓每位女性使用者能便捷的找到心儀的商品則是搜尋系統的願景。作為重要的流量入口，搜尋系統一直承擔著關鍵的職責：優化商家流量分配和提升使用者體驗，讓最優質和最符合使用者個性化需求的商品排在前面。隨著集團品質升級戰略的深化，演算法排序的不斷升級，對搜尋系統也提出了更高的要求。

本文會先介紹蘑菇街目前的整體搜尋架構，之後以一個線上請求來細化描述搜尋排序實現。

現有搜尋架構

目前的架構圖如下所示： 

整體架構從大的層面可以分為兩部分：線上和離線。線上部分主要是涉及線上請求的系統（運維平臺和排序平臺是的系統，但主要服務線上系統，所以也劃分在線上部分），包括業務層、投放層、精排層、引擎層。離線部分主要是演算法訓練和資料流相關係統（ACM打點、dump等）。

下面介紹下核心系統的功能。

Topn 

topn是搜尋系統的統一入口。向上通過統一的介面和檢索協議對接不同的搜尋業務，業務層只需要關注資料透出結構和來源，不用關注引擎細節和演算法邏輯；向下則對接不同的搜尋引擎和排序系統，這些系統只需關注自身的搜尋及排序邏輯，不需要關心不同的業務接入。同時，topn集成了abtest分流系統及提供演算法配置後臺，使得多個演算法的並行測試和日常上下線非常便捷；另外，通過分組隔離和標準化部署，在可用性和擴充套件性上提供了最大保障。

Abtest

abtest分流系統實現了uuid/hash/人群標籤等多種分流規則，同時也支援自定義分流條件；分層策略能夠讓多層實驗互不干擾。通過統一的實驗控制檯，結合ACM打點資料，能夠實時統計ab資料效果，方便演算法同學進行線上評估。統一的SDK使得有ab需求的業務方整合很方便，目前已覆蓋集團90%以上的流量入口。

QR

QR系統的主要功能是實現query的改寫(Query Rewrite)來擴充套件query。通常使用者輸入的搜尋詞是比較簡單的，會根據演算法的邏輯進行擴充套件，然後帶到引擎中進行召回和計算。典型的改寫功能如切詞、同義義詞擴充套件、類目相關性預測、品牌詞加權等。QR系統實現上也比較靈活，支援演算法的外掛化開發，外掛之間可以根據業務需求靈活組合。

精排系統

精排系統主要支援演算法的個性化排序，以及靈活的演算法業務開發。搜尋引擎主要負責召回粗排結果，而精排則需要載入更多的特徵和更復雜的模型進行排序計算或實時預測。演算法排序業務複雜多變，需要較頻繁地做ab對比實驗，精排通過提供靈活的排序邏輯配置和動態載入機制來支援。實現上精排的底層儲存複用了搜尋引擎的技術，支援高密度的資料儲存和高併發讀取。

搜尋引擎

基於自研的統一底層框架zindex實現的高效能C++搜尋引擎；支援檢索、過濾、統計、排序等標準功能；支援海選和多輪排序，提供外掛化的排序框架，方便演算法同學開發排序演算法；支援靈活的索引結構和召回邏輯等。

UPS

User Profile System，使用者個性化資料儲存系統，包括離線的使用者特徵資料，以及實時的資料特徵（實時點選的商品、實時搜尋詞、實時加購物車等)。主要服務兩大核心業務——搜尋和推薦，提供高效能的使用者特徵資料獲取，用於個性化排序和推薦。新版底層基於搜尋引擎的統一框架實現，目前線上峰值QPS接近10w，單次請求平均rt在3ms內。

引擎運維平臺

提供引擎例項配置、建立、釋出部署、索引構建、服務上下線、監控報警等全流程的運維服務。依託docker虛擬化技術和公司的釋出系統，支援高效的容器化部署和釋出；提供靈活的索引配置和管理；同時提供友好的web控制檯進行操作。

演算法排序平臺

通過統一的視覺化後臺，為演算法同學提供一站式服務，包括快速建立演算法場景、模型、排序策略略、指令碼，以及上線前的評測等。

為演算法同學遮蔽了複雜的線上系統，加快了演算法上線的效率和穩定性。平臺目前已對接推薦和搜尋的多個系統和場景。

dump系統

dump系統的職責是規範和管理搜尋資料流，以統一的方式將上游的資料來源同步到下游的儲存，比如從DB到搜尋引擎。從資料特性和系統需求上，提供三種形式：增量、全量、小全量。增量主要解決實時資料的變更和推送；全量主要提供離線高吞吐的資料構建；而小全量主要解決演算法資料的更新。另外，在資料的可靠性上也提供了有效的保障。

特徵管理平臺

特徵平臺對演算法特徵進行統一的管理，包括規範特徵的定義，演算法訓練特徵生成的統一排程，特徵生成後的統一儲存，特徵的推送上線，特徵校驗和監控等。演算法同學只需專注模型訓練和演算法調優，特徵的上線和複用則交給特徵平臺。

ACM資料採集系統

ACM採集系統主要解決使用者行為資料的埋點、採集、清洗和追蹤，為演算法的模型訓練和實時報表統計提供可靠的資料來源。

實現上通過統一的打點日誌規範(即自定義的ACM規範)，在服務端進行拼裝，然後在客戶端進行埋點，之後統一收集到資料倉庫，通過清洗後提供給演算法訓練或者做實時統計。

上面主要介紹了搜尋系統整體架構和核心繫統，看起來可能比較抽象。下面以一個真實的線上請求來詳細闡述排序實現。

線上搜尋流程

在蘑菇街app搜尋框上輸入 “nike”，搜尋請求會經過以下鏈路（如下圖）： 

1.topn

topn接收到使用者query，會根據使用者資訊和請求來源等進行判斷，獲取對應的 abtest配置以及後續請求鏈路的配置，比如該請求是否要請求UPS、請求哪個引擎、是否需要精排等 。

線上topn配置示例如下圖所示：

一條典型的配置資訊包括以下內容：

• 排序code，用於指定搜尋引擎的排序外掛；

• Abtest配置，這裡我們用了UUID分流方式，指定某一位對應的值即可；

• SearchEngine配置，會對應不同的業務例項 （比如商品引擎、店鋪引擎）；

• QR配置，是否要請求QR；

• UPS配置，是否請求UPS以及要獲取的欄位；

• ReranConf精排配置，用於指定精排的排序外掛和排序模型；

對照上圖的配置，可以清楚知道哪些流量走哪個排序，對應請求後端的哪些系統。

2.QR

QR的目的是擴充套件query以召回更豐富的商品集，不同的query會觸發不同的改寫外掛。可以看下“nike”這個query經過QR做了哪些改寫：

• nike品牌詞觸發旗艦店加權（商家扶持）。上圖的brankInfo。

• query類目相關性。上圖的categoryInfo，數字表示對應的類目ID和權重。

• 同義詞擴充套件。“nike”有同義詞“耐克”。

• 切詞這裡沒有，因為nike本身就是一個完整的詞。

3.UPS

UPS主要儲存使用者的歷史和實時行為，包括收藏、點選、加購、下單等，這些個性化資訊提供給精排系統做個性化的排序。比如可以獲取使用者最近點選的商品列表，精排系統根據這些點選商品進行相似商品加權。介面提供單個UID+行為的獲取和批量獲取。 比如獲取UID=783207的點選資料，大概結構如下：

4.搜尋引擎

topn在請求QR獲取改寫後的query和UPS獲取使用者個性化資訊後，結合自身的排序配置資訊，拼成最終的query串傳遞給搜尋引擎，做商品召回和粗排。

搜尋引擎的排序是通過排序外掛的方式開放給演算法同學開發的，支援海選和多輪粗排序。topn配置裡的sort=ltr_test_antispam 在引擎中的排序配置如下：

一個演算法(algo)排序對應一輪海選(audition)加多輪粗排(rank)：

• 海選配置的是LTRRanker，是我們基於機器學習的線性排序器(ranker)。一個ranker可以包含多個打分器（scorer)。ranker和scorer的關係圖如下所示，比如我們的線性ranker包含：商品質量分打分器、通用線性模型打分器、文字相關性打分器。多個打分器通過不同的權重進行線性加權生成最終的排序分數。海選的排序和打分邏輯相對通用和簡單，召回效能也高，通常召回的商品數量較大（2w~10w),這些商品再進入到後續的多輪粗排。

• 粗排配置的是三輪排序：QueryCTRRanker、BrandWeightRanker、AntiSpam，分別是基於query點選率預估的排序、品牌加權排序、反作弊過濾。粗排以鏈式執行，上一輪粗排的結果是下一輪粗排的輸入。粗排的計算邏輯要複雜很多，參與排序的商品量也相應少，排序結果透出給精排系統（不需要做個性化重排序的場景下，結果直接返回給前端），粗排召回量通常在千級別（1000~5000）。

5.精排系統

精排系統主要做個性化重排序以及業務重排序，對應的排序模型和演算法隨業務變化較快，對資料和模型的實時性要求也更高。排序邏輯跟引擎類似，也支援多輪排序，典型的排序如同店打散、類目打散等。

精排系統最終返回topK排序結果給前端，整個線上請求完成。

總結

本文主要介紹了目前蘑菇街搜尋系統的整體架構，以及線上請求鏈路的細化分析。

隨著業務的發展，期間經歷過很多次的迭代，才慢慢進化成現在的體系，不過可預計的將來現有架構也將進一步演變，我們的最終目標高效支援業務和演算法。

本文只是囫圇吐棗，讓大家對搜尋系統有個整體印象，架構中的每個系統都有很多有價值的細節可挖，期待在後續的文章中跟大夥繼續分享。另外，也會講講搜尋架構是如何一步步演變過來的，敬請期待。

來源：公眾號：美麗聯合資料技術

版權申明：內容來源網路，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝。

-END-