昨天，搜狗、知乎公布了兩家最近的戰(zhàn)略合作，其中最主要的內容便是搜狗技術支持知乎，大大提升了后者的搜索體驗。那么在這以前，知乎的搜索為什么這么爛呢？來聽聽專業(yè)做搜索的搜狗搜索工程師怎么說。

本文作者許靜芳，系搜狗搜索技術總監(jiān)。原文刊載于知乎，雷鋒網已獲得作者授權。

圖為知乎吉祥物"劉看山"。

特定站點搜索相比通用搜索的技術局限

搜索是技術方向輻射相當廣的一個復雜系統(tǒng)，其技術門檻之高，在眾多的互聯網產品中能與搜索比肩的是少之又少。要想玩轉這套系統(tǒng)，擁有一批最優(yōu)秀且懂搜索的工程師和研究員是必不可少的。我看到之前 @熊辰炎同學也提到說想解決的話，知乎可能需要5個熟練工干大半年。在我看來，這種團隊配置作為站內搜索差不多能解決大部分基礎問題，即達到不被“到處”抱怨。但如果要求再高一點點，能稍”智能”地處理用戶查詢，那么這種團隊配置恐怕還是望塵莫及。

當然搜索也絕不僅僅是一個人力問題，支撐搜索的人工智能技術正在”經驗主義”(以統(tǒng)計學為代表)的道路上享受著大數據（特別是用戶行為數據）的紅利。從一個特定站點出發(fā)，即使是一個格調高、深受用戶喜愛的站點，其能夠接觸到的數據無論是用戶群體行為數據還是全網的信息資源都是十分有限的。用戶對于全網通用搜索和站內搜索的期望差別僅在于搜索范圍從全網變?yōu)檫@個特定站點，但搜索用戶天生的”懶惰”、表達含糊以及對搜索結果智能的期待從未改變過。而且由于用戶對他所喜愛的站點的了解、熟悉程度遠遠超出其對全網的了解，所以用戶對搜索服務所存在的各種問題更為敏感，從而也有更高的要求。正是這種數據局限所帶來的技術水平局限與用戶需求之間的矛盾，使得原生站內搜索注定就是一件不太可能成功的路。

扯遠了，回到作為一個技術人員解釋為什么知乎站內搜索沒有通用搜索(例如百度、搜狗)的site查詢好用吧。

通用搜索背后的技術

@張前川 關于搜索效果的評測解釋得已經比較完善了，下面我就以這幾個case為例解釋一下通用搜索是如何解決背后的技術問題吧。主要分為NLP/相關性計算/排序這幾個方面。

1. NLP

1.1 分詞(Word Segmentation)

搜索中的分詞是指將文本切成多個獨立的語義單元以作為檢索的最小單元，然后分詞后的詞串建立倒排索引以加快檢索服務的速度。這是信息檢索最基本最重要的架構，這里不詳細展開。

先看看張前川提到的“避谷”這個case，正如張前川所說，避谷應該切成一個獨立的詞。為了解釋后面的算法，我把case改成“避谷方法”，更容易說明問題，它的正確切詞方法是【避谷】【方法】。如果把避谷分成【避】【谷】兩個單字，就容易出現知乎站內搜索這種【避】【谷】兩字分開出現的結果，也是我們常說的結果發(fā)生語義漂移。那么如何知道【避谷】應該是個獨立的詞呢？

最經典的分詞方法有基于詞典的前向/后向最大匹配或基于語言模型的分詞等等，其中如何構建準確而全的詞典，用什么語料統(tǒng)計適用的語言模型都是算法成功的關鍵所在。

問：通用搜索如何解決這個問題呢？

答：挖掘網絡語料或用戶行為數據！

a. 對于基于詞典的方法，由于“避谷”是個道家的一個術語，有可能分詞詞典里不包含這個詞。那么通用搜索通?？梢酝ㄟ^挖掘網絡語料（例如百科詞條）來補充詞典。

b. 對于語言模型或其他統(tǒng)計方法，用戶群體歷史的行為數據就是一種非常有價值的數據。這里僅提一個思路。歷史上搜索“避谷方法”的用戶，所點擊結果的標題中“避”與“谷”很大概率彼此緊鄰，“方“法”很大概率緊鄰，而“谷“與”方法”很小概率緊鄰。由此可以推斷【避谷】【方法】應該相互連接組成一個詞，而“避谷”與”方法”之間切分開來更合適。利用用戶歷史行為數據的方法還有很多，大家也可以打開思路。

1.2 查詢糾錯(Query Correction)

再看“什么名字haoting“這個case，非常直觀，大家都能看出來是用戶把查詢詞的一部分敲成拼音了，需要系統(tǒng)自動糾錯。當然這是個簡單的糾錯，只要找到haoting對應的上下文語言模型概率最大的漢字“好聽”即可糾正過來。

有些需要糾錯的case就不那么容易了。例如“哦泡手機”，原意是找“oppo手機?！比四X能夠非常快速準確的完成這一個糾錯過程，但對于不具備智慧的機器，這個轉換過程并不那么容易。

針對這個case算法糾錯的過程大致應該是這樣：首先把”哦泡”轉換成拼音“opao“，然后計算“opao”和“oppo”之間的編輯距離（一種度量文本串之間相似程度的方法），然后通過多種數據和模型計算出來“哦泡”糾錯成“oppo”的概率，特別是在上下文為“手機”的條件下“哦泡”糾錯成“oppo”的概率。這里面的每個步驟都同時需要算法與數據的支撐，通用搜索面對更多的數據和更更多的用戶，顯然有非常大的優(yōu)勢。

1.3 查詢理解(Query Understanding)

查詢理解這個概念比較廣，廣義上前面提到的分詞、查詢糾錯也可以納入查詢理解的范疇，這里我們主要用查詢理解來概括查詢改寫、詞間緊密度、詞賦權等一系列的對查詢的理解以幫助獲得更好的搜索結果。前川前面給出的“101大廈”就是一個比較綜合的例子，但是這個case我有些不同看法。

首先“101大廈”合在一起表示一個完整語義的實體，所以相關的結果中101和大廈應該緊鄰在一起。前川說應該分成一個詞，但出于搜索查全率的考慮，即盡可能找到更多的相關結果，它們還是分開比較好，因為“101大廈”還有很多種其他的叫法，例如“臺北101””101大樓”等等。挖掘出101大廈的這些等價(或同義)說法對于搜索效果至關重要。這種等價或同義的算法用在搜索中就是查詢改寫一種最常見的形式。

但是“101”和“大樓”之間又存在非常緊密的關系，兩者如果在文檔中相距太遠，結果通常是不相關的。這里涉及的是另一個概念——緊密度，即既需要切成兩個獨立的詞，但又要求結果中這兩個詞之間的距離足夠近，某些情況要求一定緊鄰。

查詢改寫、緊密度同樣依賴于網絡資源的挖掘以及歷史用戶行為的挖掘，例如用戶在同一個session內的主動改寫、用戶查詢后的點擊、具有相似點擊結果的多個query等等…每種數據的合理應用，都能讓搜索效果有所提升。通用搜索正是利用其數千億網頁索引庫以及每日數億次的用戶查詢及后續(xù)行為，在大數據上逐漸積累對查詢理解的智慧。這些恐怕任何一個站點都無法觸及的。

2. 相關性(Relevance)

前面提到的都是NLP相關內容，我們再來看看搜索里另一個核心技術—相關性計算。相關性計算通常指給定一個查詢和一篇文檔，計算兩者是否語義相關。語義相關是個非常大的挑戰(zhàn)，從技術的發(fā)展歷程來看，從早期的統(tǒng)計詞出現的頻率，例如tf.idf、BM25、到language model、proximity等等都試圖從查詢詞在文檔中出現的次數、位置、詞的權重、文檔的長度等等多個角度去估計查詢與文檔之間的相關度。近來在深度學習的影響下，基于深層神經網絡的詞嵌入、語義表示、語義匹配等新興技術的涌現，正在帶領相關性計算由匹配統(tǒng)計邁入“語義計算”的大門。搜狗、百度已經在這這方面取得了階段性的成功，同時這個方向還有很多問題待解決，讓我們拭目以待吧。

就前川提到的“為什么要來北京”這個case，可以從多個角度解決。例如通過查詢理解，我們可以知道“北京”在這個查詢中是個非常重要的詞，而標題包含重要的詞的文檔相比于僅正文包含重要詞的文檔中有更大概率與查詢詞先關。前川提到的第二條結果不相關，”北京”即僅僅出現正文里。解決這個問題的思路還有很多，要想做個搜索，需要從多個維度去闡述查詢與文檔之間的關系，這是一項需要相當深積累的工作。

3. 排序（Ranking）

排序，望文生義即將搜索結果按照滿足用戶需求的程度從高到低排序，以便最滿足用戶需求的結果能夠排在搜索結果列表的最前面，讓用戶能夠最先瀏覽到。排序主要涉及兩大問題：用于排序的多維特征以及多維特征的融合以決定最終的順序。

相關性無疑是搜索排序的一類非常重要的緯度，我們前面也提到相關性自身也需要從多個更細緯度去剖析。正如很多用戶提到的，知乎是問答社區(qū)，有人提問、有人回答、還有人點贊、關注，為什么知乎返回的結果很多都零回答、零關注。其實問題的回答數、關注數、點贊數都是衡量一個文檔質量非?？陀^的指標，這些對于衡量問題是否能夠滿足用戶需求都是非常有價值的，也就是說這些都應該成為排序所考慮的特征。

那么這么多特征相互如何融合來決定最終的順序呢？有很多基于規(guī)則或線性融合的方法，近年來排序學習(Learning to Rank)的方法已經無數次在各種競賽、學術論文、工業(yè)界產品中將排序多特征的融合的結果帶入或逼近局部最優(yōu)解或全局最優(yōu)解。

無論是排序特征的準確與豐富還是排序融合，都是搜索工程師們孜孜不倦地不斷優(yōu)化的方向，經驗與積累也是非常重要的。

4. 搜索架構

大部分用戶會認為搜索效果和搜索性能沒有什么關系，但實際上兩者是緊密聯系在一起的。由于服務負載的壓力、用戶響應時間的限制，分給每次用戶查詢的計算資源和時間是非常有限的。底層的檢索的性能越好，所能查找的候選文檔越多，所留給排序優(yōu)化的時間越多，越能使用更豐富的特征和更復雜的算法，達到更好的排序效果。簡而言之，性能越高，效果提升空間越大。

除了最基本的倒排索引，架構上還有很多可以優(yōu)化的點。例如對歷史數據的批量倒排和針對新數據或更新數據的實時倒排的設計，其次針對標題、正文等重要度不同字段的處理、倒排的壓縮，快速交并算法、靈活的多機分環(huán)架構等等這些都是一個好的搜索架構需要考慮的問題。而好的架構的設計也是來源于對于搜索這個任務足夠深刻的理解，如果沒有對搜索多年的打磨，一名再優(yōu)秀的架構師也是不可能設計出一套完美的搜索架構的。

啰嗦很多，總結一下，知乎搜索體驗不理想，存在多種問題，但這些問題絕不是知乎僅有的問題，也不僅僅是人力投入的問題。搜索一個異常復雜的系統(tǒng)，好的搜索體驗需要技術的沉淀與積累，需要海量數據特別是海量用戶行為數據的支撐。站內搜索就于其在搜索方向的積累、其能接觸到的數據，像知乎這樣面對高標準嚴要求的用戶，注定不易做到用戶滿意。

當然凡是問題，是都能夠被解決的。

（編者注：從昨天的發(fā)布會看，知乎的搜索問題看起來已經解決了大半。搜狗的『知乎搜索』目前也已經上線。）

作者：許靜芳

鏈接：http://www.zhihu.com/question/26617244/answer/70802668

來源：知乎

商業(yè)轉載請聯系作者獲得授權，非商業(yè)轉載請注明出處。

雷峰網版權文章，未經授權禁止轉載。詳情見轉載須知。