在開發搜尋功能時，自動完成（Autocomplete）是一個極其特殊的元件。對使用者來說，每輸入一個字母就觸發一次請求，因此對延遲（Latency）的容忍度幾乎為零。傳統上，為了速度，工程師通常會使用簡單的字面匹配（Lexical Matching）或手寫的規則（Heuristics）來決定建議項目的順序，但這類方法缺乏靈活性，無法根據使用者的即時行為或流行趨勢來調整。
外送平台 Swiggy 針對這個痛點，將其自動完成系統從傳統的規則排序升級為基於機器學習的實時排序（Real-time ML Ranking），在維持極低延遲的同時，大幅提升了搜尋結果的相關性。
從檢索到排序的兩階段架構
為了兼顧速度與精準度，Swiggy 採取了業界常見的兩階段處理流程：候選集生成（Candidate Generation）與重新排序（Ranking）。
第一階段是候選集生成。當使用者輸入文字時，系統會利用 OpenSearch 進行快速檢索。這裡結合了兩種技術：一種是傳統的字面匹配（Lexical Retrieval），確保輸入的字對得起來；另一種是基於嵌入向量的相似度搜尋（Embedding-based Similarity Search），讓系統能理解語義，即使字面上不完全相同也能找到相關項目。此階段的目標是召回率（Recall），也就是在極短時間內抓出所有可能的候選答案。
第二階段則是重新排序。系統將第一階段抓出的候選集交給機器學習模型，根據預測的相關性對結果重新排序。這裡使用了 Learning to Rank (LTR) 技術，這是一種專門為排序任務設計的機器學習方法，旨在預測項目與查詢之間的相對順序，而非單純的分類或數值預測。
將模型整合進搜尋引擎以消除網路開銷
在一般的機器學習架構中，排序通常需要將資料從搜尋引擎傳送到一個獨立的 ML 推理服務（Inference Service），處理完後再傳回來。然而，對於自動完成功能來說，這種額外的網路跳轉（Network Hop）會帶來不可接受的延遲。
Swiggy 的解決方案是直接將 LTR 模型整合在 OpenSearch 內部。透過使用 OpenSearch LTR 框架以及如 XGBoost 等梯度提升樹（Gradient Boosted Tree）模型，排序邏輯在搜尋引擎內部直接完成。這種設計消除了外部 API 呼叫的開銷，讓系統在引入複雜模型後，依然能滿足即時回應的要求。
特徵商店與實時信號的應用
為了讓排序結果更精準，模型需要大量的特徵（Features）作為輸入，例如使用者的歷史互動、點擊行為、查詢上下文以及項目的熱門程度。
為了避免在請求到達時才進行昂貴的即時計算，Swiggy 引入了特徵商店（Feature Store）。特徵商店扮演著緩存與管理中心的角色，它儲存了預先計算好的離線特徵（如項目的長期熱門度）以及透過串流處理產生的即時特徵（如最近一小時的點擊趨勢）。當排序模型需要特徵時，可以直接從商店中快速獲取，確保了推理速度。
持續進化的閉環反饋
機器學習系統最核心的價值在於能夠自我演進。Swiggy 建立了一套完整的反饋循環：系統會持續收集使用者的點擊率（CTR）和最終轉換率（Conversion Rate）等行為數據。
這些數據會被串流回離線訓練管線（Offline Training Pipeline），用來重新訓練模型。訓練完成後，新模型會存入模型註冊表（Model Registry）並部署到線上環境。這意味著系統可以自動適應新的搜尋趨勢或使用者行為改變，而不需要工程師手動修改排序規則。
實務總結與啟發
Swiggy 的實作給工程師三個重要啟發。首先，面對極端延遲要求時，應考慮將模型推向資料端（如整合進 OpenSearch），而非將資料拉向模型端。其次，將檢索與排序分離，可以讓兩個階段獨立優化，在保證召回率的前提下提升精準度。最後，透過特徵商店將計算前置化，是實現實時 ML 推理的關鍵。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。