搜索的普遍流程

搜索，推薦，廣告三兄弟，整體的技術棧，流程框架是比較相似的。主要區別在於業務邏輯上的細微不同，但是可以肯定的是，搜索是三兄弟中最重要的。

搜索的整體流程同樣是召回，排序兩大塊。但是除此之外，從一個完備的搜索引擎來看，要處理的事情遠不止這麼簡單。總體來看，整個搜索可以看作這麼幾個階段：

• 數據預處理
• query understanding
• 召回模組
• 排序模組
• 後處理

數據預處理

對於輸入 query 第一步需要預處理為方便操作的形式，以供後續的步驟可以有效進行。常見的操作有：

• 無效內容的過濾：比如標點符號， emoji 表情，奇怪的字元等。
• 簡繁體轉化。
• 長度截斷。
• 數字轉中文，中文數字轉阿拉伯數字等。
• 譯名，別名等轉化。
• 禁搜詞，禁搜內容等過濾。

在預處理後可以獲得一個比較規整的 query 欄位，接下來對相應的 query 進行逐步處理。

QU/query understanding

QU 部分的內容並非一個搜索引擎必須的，但卻是一個想要做好做優秀的搜索引擎必須的。整個 QU 部分的效果會對召回和排序階段都產生巨大影響，而後續的無論召回還是排序都很依賴這一步的結果。

QU 部分的技術棧基本都是 nlp 的一些常見操作，總體來說是比 nlp 要簡單的，因為目的很清晰，用戶的 query 肯定是希望得到某類結果。具體主要是以下內容：

• 分詞。這裡也有常見的不同方法，大家可以針對性去了解對應的內容。
• 糾錯。比如搜索周傑論，我們可能需要給糾正成周杰倫。
• 詞幹提取和詞形還原。
• 命名實體識別。獲得每個詞的實體類型。
• 意圖識別。分析用戶的搜索意圖，這個也要針對業務進行分析，比如電商搜索，音影片的搜索，網頁搜素都不相同。

對於整個 QU 部分來說，為下游的工作起到一個至關重要的作用。這一步的效果在很大程度上決定了接下來的工作能做到的上限，如果你對 query 經過一系列處理，變得很差，那麼後面的搜索步驟也無法取得好的效果。

召回模組

這裡的方法其實主要是三類：

• MySQL，Redis 等 keyword 直接精確匹配。這種方法簡單直接，但是局限性較大。
• ElasticSearch，也就是我們經常聽到的 ES，一些不靠搜索吃飯的公司，基本上用 ES 就可以完成絕大多數需求了。
• 對 query 進行 embedding，然後利用諸如 BM25 等方案進行相似性召回。如果想要做個性化的推薦，就同時也可以考慮用戶的歷史行為作為 embedding 資訊，一起加入進來。

排序模組

有的工程裡面，會將排序再拆分粗排，精排，重排等等，但是本質上都是一樣的，就是將召回拿到的內容，按照用戶輸入的 query 進行一個排序，將用戶可能感興趣的排到前面去。

其實這裡的內容是大家經常看論文比較常見到的部分，各種模型和結構，各種奇思妙想，都基本上是以排序為主。

排序的核心其實主要就是三方面，一個是 query 的 embedding，一個是 item 的embedding，第三個是如何判斷它們之間的相關性。大多數模型的工作也集中在這三點上。

但是就我的經驗來看，實際應用中，簡單的 LR 之類的模型，就可以解決百分之八九十的問題了。要想精益求精，才是接下來需要模型的時候。

其它內容

在搜索的過程中，一些其它輔助功能也很重要。首當其衝的是 suggest，對用戶的輸入進行提示和建議，這部分的內容也可以和糾錯進行結合。

還有包括大數據分析的部分，畢竟搜索還是以 bad case 為驅動的，不像推薦，用戶的容忍度比較高，對於 bad case 的分析和解決也很重要。

總結

這篇文章簡要的介紹了一下一個搜索引擎需要做的工作，可能不接觸這方面的人認為，搜索主要都在做排序演算法方向的研究。通過這篇文章可以幫助大家了解到整個過程需要涉及到的技術，想要嘗試做一些搜索方面工作的小夥伴也可以對照參考補充加技能點。

總的來說，搜索是一個對演算法和工程能力都比較有要求的領域，無論是做演算法還是做開發的朋友，都可以向這方面進行涉獵，也是一個很鍛煉人的方向。

後面有機會我們再繼續詳細介紹相關的內容。