導購是指在購物過程中為消費者提供指引和幫助的人或系統，旨在協助用户做出更優的購買決策。在電商平台中，導購通過推薦熱賣商品、促銷活動或個性化內容，顯著提升用户的購物體驗，同時推動銷售額的增長。其核心目標是通過精準的引導，滿足用户需求並促進商業價值最大化。
詞分發：導購的重要組成部分
在電商導購體系中，詞分發作為關鍵環節，主要聚焦於與關鍵詞推薦相關的功能。這些功能包括但不限於下拉詞、底紋詞、熱搜榜單、錦囊詞以及風向標等。這些推薦詞能夠幫助用户快速定位感興趣的商品或服務，降低搜索門檻，提高購物效率。例如，下拉詞可以在用户輸入搜索內容時提供智能提示，而熱搜榜單則能引導用户關注平台上的熱門趨勢。
詞分發平台的價值與功能
為了進一步優化詞推薦的效率與一致性，詞分發平台應運而生。該平台致力於打造一個通用、高效的詞推薦生態系統，通過集成多種算法、工具和通用服務接口，為公司內不同業務域提供靈活的詞推薦支持。其主要優勢包括以下幾點：
- 統一開發，降低成本：詞分發平台通過提供標準化的服務和接口，避免了各業務域重複開發和維護詞推薦功能的成本。不同團隊無需從零開始構建推薦系統，只需調用平台提供的接口即可快速實現定製化的詞推薦功能，大幅節省開發時間和資源。
- 高靈活性，適應多場景：平台的模塊化設計使其能夠根據不同業務場景和需求進行快速調整。例如，針對促銷活動、節假日特輯或特定品類推薦，平台可以動態調整推薦算法和詞庫，確保推薦內容的精準性和時效性。
- 支持業務擴展，提升效率：通過統一的詞分發平台，各業務域能夠更專注於核心業務邏輯的開發，而無需過多關注底層推薦系統的技術細節。這不僅提升了運營效率，還為業務的快速擴展提供了技術保障。
- 優化用户體驗： 詞分發平台通過整合先進的推薦算法和數據分析能力，能夠為用户提供更精準、更個性化的搜索建議。例如，基於用户歷史行為和實時趨勢生成的推薦詞，可以幫助用户更快找到目標商品，從而提升整體購物體驗。
二、已支持場景
已支持社區、交易、營銷30+導購場景。
個別場景示例
三、整體架構
業務架構
平台架構
整體平台架構
平台+腳本化架構
腳本熱部署功能在詞分發搜索推薦引擎中發揮了重要作用，其主要目標是通過動態加載機制處理策略頻繁變更的鏈路。實現這一功能的核心在於定義統一的抽象方法（具備相同出入參），將具體邏輯下放到 SDK 中，並通過後台打包、配置和推送流程，在線服務通過反射機制快速加載實現代碼，再結合 AB 配置選擇適用腳本。這種方法顯著提升了策略調整的靈活性，同時減少了服務器重啓的成本和時間。
在具體實施中，首先需要設計並實現統一的抽象方法，確保接口標準一致。隨後，將具體的實現邏輯封裝到 SDK 中，方便服務器端動態接收和加載。後台則負責提供打包、配置和推送功能，將實現代碼整理為統一的包形式。當鏈路策略需要更新時，開發人員只需將新的實現代碼上傳至後台，完成打包、配置和推送操作。
在線服務在檢測到新推送後，利用反射機制加載具體實現，並根據 AB 配置選擇適用的腳本運行。這種動態加載方式無需重啓服務，即可實現策略的即時切換和優化。整體而言，這一方法不僅提高了系統對策略變更的響應速度，還降低了維護成本，同時增強了系統的可靠性和穩定性，為詞分發搜索推薦引擎的持續優化提供了有力支持。
主工程底座和腳本工程
在業務迭代的代碼編寫中，通常分為兩種類型：主工程底座和腳本工程。
- 主工程底座主要負責實現抽象和通用層的代碼邏輯，注重提供穩定的基礎框架和通用功能，確保系統的整體架構和擴展性。
- 相比之下，腳本工程更貼近具體業務需求和定製化場景，專注於實現與業務邏輯密切相關的功能模塊。通過這種分工，主工程提供通用的技術支持，而腳本工程則靈活應對多樣化的業務需求，從而實現開發效率與業務適配性的平衡。
腳本熱部署架構的存在原因
腳本熱部署架構的存在主要出於以下原因：
- 靈活應對策略變更：通過動態加載腳本，系統能快速適應頻繁更新的業務需求，無需重啓服務。
- 降低維護成本：統一抽象方法和 SDK 實現減少重複開發，後台打包推送簡化更新流程。
- 提升效率：反射機制和 AB 配置實現即時腳本切換，節省時間並優化資源使用。
- 增強穩定性：動態調整策略而不中斷服務，確保系統持續穩定運行。
四、架構演進3.0之圖化
串行架構
之前詞分發業務一般都可以抽象為“預處理->召回->融合->粗排->精排->結果封裝”等固定的幾個階段，每個階段通常是有不同的算法或工程同學進行開發和維護。為了提升迭代效率，通過對推薦流程的抽象，將各階段的邏輯抽象為“組件"+"配置”，整體的流程同樣是一個配置，統一由“編排引擎”進行調度，同時提供統一的埋點/日誌等。讓工程或算法同學可以關注在自己的業務模塊和對應的邏輯，而框架側也可以做統一的優化和升級。
圖化引擎架構演進
那為什麼要去做“圖化”/“DAG”呢？其實要真正要回答的是: 如何應對上面看到的挑戰？如何解決目前發展碰到的問題？
從業界搜推領域可以看到不約而同地在推進“圖化”/“DAG”。 從TensorFlow廣泛採用之後，我們已經習慣把計算和數據通過採用算子（Operation）和數據（Tensor）的方式來表達，可以很好的表達搜索推薦的“召回/融合/粗排/精排/過濾”等邏輯，圖化使得大家可以使用一套“模型”語言去描述業務邏輯。DAG引擎也可以在不同的系統有具體不同的實現，處理業務定製支持或者性能優化等。
通過圖（DAG）來描述我們的業務邏輯，也帶來這些好處：為算法的開發提供統一的接口，採用算子級別的複用，減少相似算子的重複開發；通過圖化的架構，達到流程的靈活定製；算子執行的並行化和異步化可降低RT，提升性能。
圖化是一種將業務邏輯抽象為有向無環圖（DAG）的技術，其中節點代表算子，邊表示數據流。不同的算子可以組合成子圖，起到邏輯更高層封裝的作用，子圖的輸出可供其他子圖或算子引用。通過圖化，策略同學的開發任務得以簡化，轉變為開發算子並抽象業務數據模型，而無需關注“並行化”或“異步化”等複雜邏輯，這些由 DAG 引擎負責調度。算子設計要求以較小粒度支持，通過數據流定義節點間的依賴關係。
圖化引入了全新的業務編排框架，為策略同學提供了“新的開發模式”，可分為三部分：一是定義算子、圖和子圖的標準接口與協議，策略同學通過實現這些接口來構建業務邏輯圖；二是 DAG 引擎，負責解析邏輯圖、調度算子，確保系統的性能和穩定性；三是產品化支持，包括 DAG Debug 助手協助算子、圖和子圖的開發與調試，以及後台提供的可視化管理功能，用於管理算子、子圖和圖。整體架構可參考相關設計圖。
圖化核心設計和協議
節點‘算子’抽象封裝——面向框架測
算子接口定義IDagTaskNodeExecutor<O>
/**
* dag 主節點註解
*/
@Inherited
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface DagNodeMetaProcessor {
/**
* 算子名字
* @return
*/
String name();
/**
* 算子描述
* @return
*/
String desc() default "";
}/**
* 主工程節點任務-執行器
*
* @param <T>
*/
public interface IDagTaskNodeExecutor<T> {
T execute(DagStrategyContext dagStrategyContext);圖配置文件——面向框架測（使用者無需關心）
圖分為圖圖，一個場景可以有多個圖，可按實驗制定不同的圖；圖定位為業務邏輯模版，可以將若干個獨立算子組裝為具有特定業務含義的“圖”，圖和算子一樣可在場景大“圖”中進行配置，即運行時可有多個“實例”，實現邏輯的複用和配置化。
面向業務使用者—如何配置
- 節點自動註冊：面向使用者無需關心JSON複雜的配置化，完全可視化操作。節點有倆種類型分主節點和腳本節點（可視化區分），節點註冊完成框架測實現。
- 業務關心編排關係：業務只需要關心節點之間編排關係即可。編排關係也是完全可視化拖拽實現。
- 線程池隔離：一個服務內，不同場景線程池是隔離的，一個場景內，不同並行節點線程池也可以做到隔離，來區分強弱依賴關係。
- 關聯實驗：一個場景有基礎場景圖，和實驗圖，實驗圖可以基於某個實驗發佈不同於場景的複雜實驗圖。
五、配套工具利器
腳本化開發&灰度發佈CICD
自迭代流程圖
去腳本化後台執行配置，首先選擇對應環境的對應集羣服務 (先預發驗證，驗證沒問題，提merge給工程cr，合併後操作線上集羣)。
腳本配置
如果是新加的腳步，選擇配置，然後在配置頁面對應類型的腳步後面選擇新增，然後添加對應腳本類型的配置（一定要按類型添加，否則加載會失敗），然後點擊添加。
腳本構建
- 配置完成後，選擇cicd，進入cicd頁面，首先選擇新增cicd，然後會彈框，在彈框中選擇你開發的分支，然後選擇構建，這個時候構建記錄會是打包中狀態，然後等1到3分鐘，刷新當前頁面，查看狀態是否為打包成功，如果為打包失敗需要檢查代碼問題，如果是打包成功，操作欄會有同步操作；
- 此次新增：在構建頁面新增了構建日誌和操作人兩列信息。
-
- 構建日誌：點擊詳情會跳轉到gitlab cicd日誌詳情（此次新增功能）
-
- 操作人：會記錄此次操作的具體人員，有問題及時聯繫相應同學（此次新增功能）
腳本發佈
一次性全量發佈（已有能力）
- 當打包成功後，操作欄會有同步操作，點擊同步，將當前打包的版本同步到集羣。
- cicd同步成功後，回到集羣管理頁面，這時點擊操作裏的發佈操作，發佈成功後，發佈會變成同步，然後點擊同步，同步成功後，這是集羣中就已經加載到集羣中，這就需要去ab實驗配置具體的腳本然後驗證。
灰度發佈
- 通過cicd頁面，構建完jar包後，點擊右側【灰度發佈】按鈕。
- 跳轉到灰度發佈頁面
- 基本信息如圖顯示，看圖。
- 發佈間隔：第一批次5%,二批次30%,三批次60%,四批次100%; 當前流量xxx%（白名單驗證）
- 發佈時，可以填寫第一批次灰度IP機器，可選。
- 當發佈到第幾批的時候，頁面顯示高亮。
- 系統一共默認四批次，首次點擊發布是第一批，默認第一批暫停，再次點擊發布，後面三批自動發佈（間隔30s）
- 如果發現異常變多或者RT變高，可馬上回滾，點擊回滾即可回滾上個版本。
- 如果一切正常，第四批就是全部推全操作，灰度jar包覆蓋基礎jar包。
- 發佈過程中，灰度的流量可以進行觀察相應的QPS、RT、ERROR、和各個階段召回、排序、打散等核心模塊的性能和調用量。
- 灰度中的jar包，列表表格狀態顯示灰度流量。
- 在集羣維度，有倆個jar,一個是灰度中的jar, 另外一個是基礎base的jar。 表格顯示如下：
DIFF評估平台
社區搜索評測平台是面向於內部算法、產品、研發同學使用的評測系統，主要用於建設完善得物社區搜索badcase評估標準體系，致力於提升用户搜索體驗和搜索算法問題發現及優化兩方面，提供完善的評測解決方案。
核心功能包含：query數據抽取、快照數據抓取、評測數據導出和評測標註結果效果統計分析。
干預平台
搜索底紋詞、猜搜詞、下拉詞在搜索鏈路的前置環節出現，在用户沒有明確的搜索需求時，對激發用户搜索需求有較大的作用，因此，這些場景既是資源位也需要嚴格把控出詞質量。本需求計劃在上述場景支持干預能力，支持在高熱事件時干預強插，也支持干預下線某些不合適的詞。
召回配置平台
在現代的搜索引擎系統中，多路召回是一個非常重要的組件，其決定了搜索引擎的性能和準確性。因此，多路召回的配置和管理，對於搜索引擎系統的性能、穩定性和可維護性來説是至關重要的。
在以前的詞分發系統中，多路召回的配置是以JSON字符串的形式存在的。每次修改配置都需要對這個JSON進行手動的編輯，該過程非常耗費時間，隨着召回路的增多，配置效率也會越來越低，而且這種方式容易出錯。因此，我們需要一種更加高效、可視化的方法來管理和配置多路召回。
為了提高多路召回的配置效率和準確性，我們需要一種可視化的後台工具來替代手動修改JSON字符串的方式。這樣的後台工具可以將多路召回的配置以更加直觀和可視化的方式展示出來，讓配置人員能夠直接在頁面上進行配置和修改，從而減少手動編輯JSON字符串的錯誤和繁瑣性。
通過使用可視化的後台工具，我們可以方便地管理和配置各種算法和策略，從而大大提高搜索引擎系統的性能和可維護性。可視化的後台工具對於提高搜索引擎的性能和可維護性非常重要，它可以大大簡化配置人員的操作難度和減少錯誤，進一步提高搜索引擎系統的效率、可靠性和靈活性。
單路配置
多路配置
當然還有其他基建和配套工具和基建服務支撐，這裏不一一展開了。
六、未來規劃
詞分發平台作為搜索引擎系統中的核心組成部分，負責管理和分配搜索詞彙的處理與召回流程。其架構以靈活性和擴展性為核心，參考圖示所示，平台通過模塊化設計（如 Java 框架 Spring 容器、詞分發平台主工程、依賴注入 Spring 容器、日誌調試能力等）支持高效運行。為了適應市場需求的不斷變化，未來詞分發平台需從以下幾個方面持續優化：
- 平台建設：進一步完善靈犀平台功能，包括繼承監控大盤，監控維度擴展，召回配置和腳本cicd建設，發佈流水線接入等等。
- 基座框架代碼和工具完善：腳本框架改造2.0，無縫對接spring容器；構建可維護完善算字庫。通過優化現有流程和算法，加速詞彙處理與召回的速度，確保平台性能的持續提升。
- 擴展場景：快速接入更多新場景，如商詳觸達，小藍詞等等。
此外，未來平台將聯合算法團隊，打破詞圈品與品圈詞之間的數據孤島，打通相關鏈路，從而全面提升詞分發平台的智能化與功能性。這一戰略將推動平台更好地服務多樣化業務需求，為用户提供更精準、高效的搜索體驗。
往期回顧
1. R8疑難雜症分析實戰：外聯優化設計缺陷引起的崩潰｜得物技術
2. 可擴展系統設計的黃金法則與Go語言實踐｜得物技術
3. 得物新商品審核鏈路建設分享
4. 營銷會場預覽直通車實踐｜得物技術
5. 基於TinyMce富文本編輯器的客服自研知識庫的技術探索和實踐｜得物技術
文 / 子房
關注得物技術，每週更新技術乾貨
要是覺得文章對你有幫助的話，歡迎評論轉發點贊～
未經得物技術許可嚴禁轉載，否則依法追究法律責任。
