從PC時代到移動互聯網時代，搜索滿足了人們從海量信息中找到有價值信息的需求，進一步提高了用戶的信息消費能力和獲取信息效率。筆者曾做過一個比較簡單的APP站內搜索功能優化，查閱了許多搜索功能設計資料。

于是乎便有了這篇搜索文章，我將從搜索最主要的三步理解用戶搜索意圖、召回內容、排序內容來給大家講講搜索功能設計的那些事。

大綱如下：

1. 搜索是為了解決什么
2. 如何設計站內搜索
3. 理解用戶搜索意圖
4. 召回內容
5. 排序內容
6. query分析
7. 寫在最后

一、搜索是為了解決什么

搜索引擎在PC時代崛起，谷歌、百度通過輸入框和網頁搜索結果來滿足網民的信息消費，幫助網民打破各種信息不對稱。谷歌、百度的搜索信息是相對開放的，用戶能在上面搜到大部分的內容。

隨著移動互聯網的普及，許多APP開始構建自己的內容生態，搭建自身的站內搜索。谷歌、百度等搜索引擎時從搜索到內容，這些站內搜索是從內容到搜索，基于自家的內容生態來搭建搜索功能。

對于用戶來說，用戶搜索內容可分為幾種場景：

• 有明確想搜的內容并記得所有關鍵詞
• 有明確想搜的內容但記不清所有關鍵詞
• 無明確想搜的內容

所以對于用戶來說，搜索是為了解決用戶明確或者不明確的搜索需求，讓用戶能夠搜到想搜的內容。從更深一層來說，搜索提高了用戶獲取信息、內容的效率。

二、如何設計站內搜索

站內搜索對于搜索系統來說，整個流程可以分為三步，分別是：

• 理解用戶搜索意圖
• 召回內容
• 排序內容

整個流程里，第一步理解用戶搜索意圖會涉及到query預處理、分詞技術等技術，第二步召回相關內容一般用到的是索引倒序的技術，召回有相關性的內容，這里會涉及到倒排索引和匹配度問題。第三步排序內容目前常見的有排序策略、機器學習。

產品經理需要做的主要是畫搜索原型圖和制定召回相關性策略和排序策略，其他的主要是靠技術或者第三方去實現。

三、理解用戶搜索意圖

用戶搜索是整個搜索系統的上游，只有理解了用戶的搜索意圖，搜索展現的結果才會是用戶想要的。如果對搜索意圖理解錯了，不論我們的召回率和排序策略多么牛，對用戶來說這次的搜索其實是失敗的。

那么怎么理解用戶的搜索意圖呢？用戶輸入的是關鍵詞，所以我們來分析下怎么理解關鍵詞。（ps:這篇文章只討論搜索方式為輸入文字的方式，不討論語音輸入、圖片、視頻輸入等方式）

3.1 query預處理

3.1.1 拼音轉文字

當用戶在搜索框中輸入拼音時，可以識別出文字。這種搜索場景還是蠻常見的，比如用戶想在微信讀書中搜索“俞軍產品方法論”，那么當用戶在搜索框中輸入”yujunchnapinfangfalun”時能理解出“俞軍產品方法論”，并給出搜索結果。

3.1.2 繁體轉簡體

對于一些有繁體輸入習慣的用戶，需要對用戶輸入的繁體字進行轉化，可以識別出其簡體。具體方案是通過詞表將繁體query轉化為簡體query，后續系統在將簡體query進行召回。

3.1.3 自動糾錯

當用戶在搜索框中輸入“于軍”，其實用戶想搜的是“俞軍”。系統可以對這個query進行判斷，判斷有沒有在索引庫命中文檔，如果沒有，則需要對其進行預處理的自動糾錯。

自動糾錯可以通過維護糾錯表的方式實現。在糾錯表里通過映射原詞給糾錯后的詞，從而實現query改寫。

目前自動糾錯在客戶端顯示上也有幾種不同的形式：

• 強糾錯：直接改寫query，給用戶的提示一般為“已顯示XXX的搜索結果”
• 中糾錯：直接改寫query，給用戶的提示一般為“已顯示XXX的搜索結果，仍然搜索:X原詞XX”
• 弱糾錯：不改寫query,只是給用戶提示“你是不是要搜索：XXX”

3.1.4 同義詞轉換

同義詞轉換從字面上理解就是能夠對query進行同義詞的理解。比如當用戶輸入“首都機場”，可以理解為“北京機場”，用戶輸入“國寶”，可以理解為“大熊貓”。

同義詞轉換技術對于query意圖理解非常重要，很多時候用戶不能很好地輸出自己想搜索的內容，如果沒有同義詞轉換技術進一步處理，那么召回的內容很有可能并不是用戶想要的。

同義詞轉換技術一般是通過獲取用戶的session日志來分析相關的query。

舉個例子，比如一個用戶輸入”國寶“后，查詢出來的結果不是想要的，從而沒有點擊行為。該用戶接著輸入“大熊貓”，得到了想要的搜索結果并點擊了內容。那么“國寶”和”大熊貓“之間就建立了聯系。

當然，”國寶“也有可能和”國家寶藏”、“國家文物”等建立聯系，基于統計后，可以計算出“國寶”與別的詞的聯系權重。在召回相關性內容時，對關鍵詞和同義詞進行召回，并賦予不同的權重，權重分值可以放在相關性分數上。

3.2 分詞技術

以微信讀書為例子，目前微信讀書的搜索結果內容為書、公眾號文章、公眾號。比如用戶在微信讀書上輸入“無限的游戲”，用戶的意圖是想查找一本名為“有限與無限的游戲”的書，不過記錯為“無限的游戲”。

如果詞典里沒有“無限的游戲”這個詞，那么就無法返回對應的內容，用戶的搜索就到此結束。

詞典的詞是有限的，輸入的關鍵詞是無限的。為了解決這種情況，目前搜索系統主要是通過分詞技術來實現。分詞的意思是將關鍵詞切分成多個詞。

比如“無限的游戲“可以切分為“無限”“的”“游戲”，采用不同的分詞技術出來的分詞結果也不同。比如有了“無限”“的”“游戲”后，分詞會對應到詞典里的詞，有對應的索引內容，召回了“有限與無限的游戲”這本書。

中文分詞目前有三種分詞方法，分別是：

• 基于詞典的分詞
• 基于語法的分詞
• 基于統計的分詞

第一種基于詞典的分詞方法用的比較多，我簡單地為大家介紹一下。

基于詞典的分詞指的就是系統有一個詞典庫，當query的分詞與詞典的詞對應上了，就能召回詞典對應的索引文檔。

分詞的粒度也是至關重要的，目前有許多這方面的規則和算法。比較經典的有正向最大匹配、逆向最大匹配的規則、MMSEG算法。

經過分詞切割后，用戶非標準的query就能被切分成標準的分詞，并能在詞典中匹配到詞，從而能索引回相關的內容。

當然產品經理不需要精通這些技術，了解概念和實現的結果即可。產品經理提出來的需求有可能是技術部門不支持的，或者不是該功能的最優方案。所以了解這些最基本的技術原理，有助于我們更好地設計搜索功能和提合理的搜索需求。

四、召回內容

4.1 倒排索引技術

這一節，我們需要先說下搜索很核心的技術——倒排索引技術。

搜索系統有詞典和內容索引庫（數據庫），詞典里的詞關聯匹配內容索引庫。當用戶輸入關鍵詞后，如果詞典里有這個詞，線上會快速召回內容文檔。如果詞典里沒有這個詞，那這次的搜索行為就沒有結果。

假設內容索引庫一共只有3個內容文檔，分別是：

• doc1：站內搜索從0到1全流程設計
• doc2：搜索應該怎么設計才是對的
• doc3：產品小白怎么入門站內搜索設計

用戶輸入關鍵詞“怎么設計站內的搜索”，經過分詞后，詞典里有這個詞，系統會召回對應的索引文檔。

索引庫如下圖所示：

以新聞搜索來說，一條新聞訊息一般會有標題、簡介、關鍵詞、來源、正文。

在召回內容的時候，會根據新聞的這幾個屬性分別構建倒排索引。當然需要召回的字段屬性是需要考慮的，并非所有屬性都得進行索引召回。

比如可以只對標題和簡介這兩個屬性進行倒排索引召回。召回的時候，我們認為標題跟關鍵詞匹配度高于簡介跟關鍵詞的匹配度，可以先以標題為維度倒排索引進行召回，接著再從簡介進行召回。

這樣的分級索引庫有利于提高檢索效率，同時能較快將優質和匹配度高的內容檢索出來。

五、排序內容

召回相關的內容后，如何排序呢？排序的策略決定了用戶最終看到怎樣的搜索結果，所以這部分是相當重要的，同時也是比較復雜的。

我這里提供兩種排序策略，一種粗排，一種精排（精排、粗排的叫法只是我為了區分兩種排序策略而定義的）。產品經理要根據具體的搜索業務和需求來制定搜索排序策略。

5.1 粗排策略

粗排主要是通過維度來將召回的內容進行排序。以某新聞app為例，搜索結果只是新聞（新聞內容包括圖文、純文本、視頻）。召回的范圍是新聞標題和摘要。

召回的內容匹配度分兩個等級：

1. 完全匹配
2. 模糊匹配（前綴、后綴、分詞等）

排序策略：

優先度：新聞標題>摘要，在優先度下按照下方的策略：

I.完全匹配>模糊匹配

II.時效性（以天為單位）

III.閱讀量優先

以上的粗排策略只是為了講解，具體的維度和排序指標不一定是我上面提及的。

5.2 精排策略

精排策略是根據doc分數倒序排序。用戶輸入query后，召回了doc(內容），這些doc怎么排序呈現給用戶呢？答案是根據每個doc的分數倒序呈現給用戶。

doc分數=文本相關性的值*重要度的值。

文本相關性的值用dscore表示、重要度的值用Iscore來表示，則doc分數=dscore*Iscore。

5.2.1 文本相關性

文本相關性的數值怎么計算呢？目前業界計算相關性的方法主要有三種，分別是tf-idf文本相關性、基于統計詞頻的BM25、空間向量模型。

我在這里給大家介紹下非常經典的tf-idf文本相關性方法。這個方法不僅簡單，并且能解決80%以上的搜索結果相關性問題。

5.2.1.1 Tf-idf

Tf-idf中的tf全稱為Term Frequence,指的是詞頻，是指該詞在某文本的占比。Tf越高，說明該詞在文本中越重要。

Idf全稱為Inverse Document Frequence，指的是逆文檔頻率。在說idf前先介紹下df，df是文檔頻率，是將包含該Term的文檔數除以總文檔數。比如一個Term在10個文檔出現，總共有50個文檔，那么df值為10/50（1/5）。

講完df后，我們再聊回idf，還是上面的例子，那么idf值為log（50/10）。由公式可以看出，idf越高，說明有該Term的文本越少，那么該文本越就能代表該Term。

同時用log來表示，還能處理掉一些高頻詞對文本相關性的干擾。比如“的”“了”，這種高頻詞的Tf可能很高，但Idf會很小，接近于0，兩數值相乘后也會很小，能很好的排除這些高頻詞的噪音。

對于較為簡單的文本相關性排序，相關性的分值可以用Tf*idf來表示，分值越高，說明文本相關性越高。

5.2.1.2 詞距與詞序

query被切割分詞成多個term后，term之間的距離與順序跟文本相關性有關。

舉個例子，用戶搜索“產品方法論”，在索引庫里恰好有兩個文檔為“俞軍產品方法論”和“做產品的10個方法”，很明顯召回排序時，“俞軍產品方法論”應該要比“做產品的10個方法”排在更前。

但可能這兩個文檔的Tf*idf值是一樣的，因為“產品”和“方法”這兩個term都有。所以我們需要關注term之間的距離和順序，在計算相關性分值時考慮進來，從而保證緊密度更高的term在召回的文檔中出現距離更近更相關。

5.2.1.3 term位置

不同位置相關性的重要程度會不同，以新聞搜索來說，標題與關鍵詞的相關性是要重要于簡介與關鍵詞的相關性的。一般這種情況下，可以賦予一個系數到Tf*idf，最終dscore=a*Tf*idf（a是系數，比如標題可以賦予1，簡介賦予0.8）

5.2 重要度

重要度指得是doc（內容）的重要程度（優質程度）。相關性得分差不多的內容里會存在優質內容和劣質內容，一般情況下，我們會將優質內容排在更前面。當然也會有商業、廣告或者別的業務的考慮，這種情況下重要度得分就會更加復雜一些。

重要度得分（Tscore）由于跟query沒有直接關系，是每一個doc的實時屬性，所以這一部分的分數可以離線算好。

還是以新聞搜索為例，假設一條新聞最重要的三個指標是閱讀量、評論率、時效性。那么：Tscore=a*f(閱讀量)+b*f(評論量)+c*f(時效性)。

f（閱讀量）、f（評論量）、f（評論量）這三個都是函數。一般來說，這三個函數可以為對數函數（log函數），因為對數函數是遞增函數，但其導數為遞減函數，說明隨著閱讀量增大，f（閱讀量）值也會增大，但增大趨勢在下降，即增大程度越來越小。

這樣有助于冷卻一些優質數據，想要獲得更高分數會越來越困難，使得馬太效應的強度降低一些。

三個對數函數還會存在一個問題，即沒有歸一化。比如閱讀量的值會在0-100000，評論率在0-1之間，時效性以小時來算的話，時效性的值可以在0-8760（以上數值不具備參考意義，單純是為了講解）。

三個指標的值不在同一區間，會嚴重影響最終的重要度得分（Tscore）的真實性。所以需要將三個指標的值歸一化，消除量綱，將數據值按比例縮放。

歸一化有幾種常見的方法，有取分數、min-max標準化、Z-score標準化方法等，通過這些方法將三個指標的取值范圍控制在0~1。（具體歸一化操作大家可自行搜索，不在此展開）

如何確定a、b、c三個值呢？

一般有兩種辦法：

1. 專家、產品自行決定（拍腦袋或者通過多組數據來得出）
2. 通過機器學習來訓練，得出a、b、c的值

驗證這些值是不是對的，可以通過A/Btest、搜索功能上線后的數據來驗證。

六、query分析

搜索功能搭建好之后，如果搜索功能對于整體業務來說很重要，那么我們需要不斷地優化搜索功能。優化搜索功能不單單只是優化搜索策略和算法，還可以通過query分析來提升用戶搜索體驗。

query分析指的是對用戶的查詢進行分析，用戶的搜索軌跡能夠很好的幫助我們了解整體用戶的搜索意圖，也能發現我們目前的搜索滿足了用戶哪些搜索需求，哪些搜索需求還需要完善。

query分析可以分以下幾步來操作：

1、以月份為單位，從query中抽取1000個query樣本

2、針對query意圖進行分類，每個query樣本用兩個需求分類來表征該query的搜索需求

3、統計一類需求、二類需求query個數的占比情況和搜索次數占比情況

query個數占比=分類query個數/query總數

query搜索次數占比=分類query搜索次數/總query搜索次數

4、統計幾個數據：

query召回率=搜索結果在準確的數量/應該被搜索的結果數量

query準確率=搜索結果在準確的數量/返回的結果數量

query需求滿足程度，可以根據搜索結果質量得出query需求滿足程度，分為高中低三等級

通過以上四步，我們能獲得相應的數據統計，接下來就是需要對數據結果進行分析，通過分析來決策下一步搜索需要怎么優化。

舉個例子，比如在query需求滿足度中，分析出需求滿足度低的query需求是哪些，查看搜索結果，分析是什么原因導致。

可能會是數據缺失、搜索結果相關度低等原因引起，那么我們后面如果需要提高這類query需求的用戶搜索體驗的話，那么就需要去解決數據缺失、搜索結果相關度低的問題。

• 如果是數據缺失，那么可以通過引入外面的內容、加大該類內容供給
• 如果是搜索結果相關度低，那么可以改善匹配策略，召回更相關的內容

七、寫在最后

寫到最后才發現寫了這么多，其實一個完整的站內搜索不僅僅只是這些，理解用戶搜索意圖、召回內容、排序內容這三步可以優化的地方實在是太多了。

隨著搜索需求越來越高，傳統的方法無法滿足一些搜索場景和目的。所以我們早已開始從算法工程和機器學習切入，這部分我暫時還未涉及，不過最近有在看算法，看看后面能不能從算法的角度來跟大家講講如何提高對用戶搜索意圖分析、如何提高搜索相關性等。

談到搜索，在中文搜索里繞不開俞軍老師。最后貼一下俞軍老師當年求職搜索工作的求職信，體會下這封至今讀來依舊帶有傳奇色彩的求職信。

搜索引擎9238，男，26歲，上海籍，同濟大學化學系五年制，覽群書，多游歷。97年7月起在一個國營單位籌備進口生產項目。99年4月起在一個代理公司銷售進口化工原料兼報關跟單。2000年1月起在一個垂直網絡公司做分析儀器資料采編。2000年7月起去一個網絡公司應聘搜索引擎產品經理，卻被派去做數據庫策劃，9月起任數據中心經理。長期想踏入搜索引擎業，無奈欲投無門，心下甚急，故有此文。如有公司想做最好的中文搜索，誠意乞一參與機會。

本人熱愛搜索成癡，只要是做搜索，不計較地域(無論天南海北，刀山火海)，不計較職位(無論高低貴賤一線二線，與搜索相關即可)，不計較薪水(可維持個人當地衣食住行即是底線)，不計較工作強度(反正已習慣了每日14小時工作制)。

作者：蘇Eddie，微信公眾號：蘇Eddies

本文由 @蘇Eddie 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。