為什麼知乎的搜索功能如此之爛？

12-28

看來需要修改提問了....最近感覺知乎搜索正常多了.....感謝回答
每次要搜索東西都要找好久，明明剛剛看過的東西搜索就搜索不出來。技術和運作方面都有什麼原因呢？

謝邀！（潛水員終於有可以專業回答的問題了）

利益相關：搜狗搜索工程師，對搜索技術「略懂」

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

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

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

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

1. NLP

1.1 分詞(Word Segmentation)

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

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

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

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

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

a.
對於基於詞典的方法，由於「避谷」是個道家的一個術語，有可能分詞詞典里不包含這個詞。那麼通用搜索通常可以通過挖掘網路語料（例如百科詞條）來補充詞典。

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

1.2 查詢糾錯(Query Correction)

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

有些需要糾錯的case就不那麼容易了。例如「哦泡手機」，原意是找「oppo手機。」人腦能夠非常快速準確的完成這一個糾錯過程，但對於不具備智慧的機器，這個轉換過程並不那麼容易。針對這個case演算法糾錯的過程大致應該是這樣：首先把」哦泡」轉換成拼音「opao「，然後計算「opao」和「oppo」之間的編輯距離（一種度量文本串之間相似程度的方法），然後通過多種數據和模型計算出來「哦泡」糾錯成「oppo」的概率，特別是在上下文為「手機」的條件下「哦泡」糾錯成「oppo」的概率。這裡面的每個步驟都同時需要演算法與數據的支撐，通用搜索麵對更多的數據和更更多的用戶，顯然有非常大的優勢。

1.3 查詢理解(Query Understanding)

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

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

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

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

2. 相關性(relevance)

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

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

3. 排序（ranking）

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

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

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

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

4. 搜索架構

張前川提到了搜索性能與穩定性問題，足以證明他確實是搜索的專業人士。呵呵。大部分用戶會認為搜索效果和搜索性能沒有什麼關係，但實際上兩者是緊密聯繫在一起的。由於服務負載的壓力、用戶響應時間的限制，分給每次用戶查詢的計算資源和時間是非常有限的。底層的檢索的性能越好，所能查找的候選文檔越多，所留給排序優化的時間越多，越能使用更豐富的特徵和更複雜的演算法，達到更好的排序效果。簡而言之，性能越高，效果提升空間越大。

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

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

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

相關利益：知乎基礎產品負責人。目前知乎搜索是我的主要工作。（承認這點需要勇氣。）

第一部分，回答「是不是」

儘管指向「知乎搜索結果很爛」的個案事實可以看到很多，但個案再多也難以得到整體結論。回答「是不是」的問題，我們仍需要想辦法得到一個全面的、定量的結論。

目前，整體衡量搜索服務的效果好壞，或者說相對客觀的比較任意兩個搜索服務，搜索行業中有很多種量化衡量搜索結果的辦法，其中使用最廣泛的兩種是「DCG 評測」和「SBS 感知評測」。參考：搜索引擎評價體系應該分幾個方面？建立怎樣的指標？ - 搜索引擎優化（SEO）前者重點考察單條結果的位置和需求滿足度。即：最好的結果是否被搜索出，是否排前。後者作為「DCG 評測」的補充，把搜索結果頁看成一個整體，除了同樣考察單條相關性之外，額外考察結果綜合體驗、展現豐富度、多樣性等結果展現及結果頁配合等整體效果。作為對這個問題的回答，我們選取相對適合知乎搜索現狀的「DCG
評測」。

讓我們一起看一看，知乎搜索在 DCG 評測中的表現。

樣本：不去重隨機抽取知乎問答搜索詞 200 個。

打分標準：

對每條結果逐個採用 0~3 分 4 檔打分：

3 能基本滿足用戶需求或回答內容對該次搜索用戶有非常高的信息價值。
2 能滿足用戶部分需求或回答內容對該次搜索用戶有較高的信息價值。
1 只可能滿足少數特定用戶需求或回答內容對該次搜索用戶可能有一定信息價值。
0 不相關，不滿足需求，對該次搜索用戶沒有幫助。

計算方法：

簡化版 DCG 演算法，對前列結果得分位置加權，綜合計算總分。1 分為絕對滿分。

評測結論：

知乎搜索得分： 0.39

主流搜索平均得分： 0.63

（主流搜索平均得分：對多個主流通用搜索，用SITE語法，不去重篩選出問答網頁）

所以最後，「爛不爛」這個問題的結論是：——是的，真是很爛。

從這個結論來看，大家對於知乎搜索功能「如此之爛」的評價都非常中肯。而且，確實如大家所說的，在通用搜索使用SITE語法的搜索效果更好。（群眾的眼光雪亮雪亮的）

親愛的知乎用戶們，對不起！

第二部分，回答「為什麼爛」

通過評測看到的具體問題，我們歸納了導致搜索效果爛的幾類原因：

問題 1，自然語言處理（NLP）類問題

CASE #1：避谷

「避谷」是一個獨立詞，居然在某些結果中被切分成「避」和「谷」。

CASE #2：101大廈

問題：前列無相關結果。切詞、丟詞、同義詞問題。

「101 大廈」不可切分，
結果中需要含有 101，
「101 大廈」需要與「台北 101 大樓」作為同義詞或自動糾錯映射。

CASE #3：什麼名字haoting

問題：結果未正確糾錯

問題 1 原因分析：

自然語言處理技術是一個難點，主要的問題是：

各種大規模語料庫的持續積累和建設。分詞、同義詞、糾錯、丟詞等等。
根據具體場景和效果，持續優化的處理演算法和策略。

對比通用搜索引擎，相對年輕的知乎在這方面的積累還是明顯不夠的，對全網語料數據的收集也不是強項。因此，不可避免時不時總會看到一些讓人無語的爛結果。

問題 2，排序演算法類問題

CASE #4：新股

問題：零回答結果排序過於靠前

CASE #5：機油多少里程換一次

問題：1、前列多條命中0贊同回答。2、輪船、摩托車並不是查詢主需求。

CASE #6：為什麼要來北京

問題：第二條結果標題不包含北京，而是法國

問題 2 原因分析：

搜索結果通過「權重」排序。權重一般由兩部分組成。

一部分與「用戶輸入的搜索詞」有關。

比如通常，完全匹配用戶搜索詞的結果，得分比部分匹配的要高。搜索詞中每一個詞語的權重也是不同的，重要詞語的權重更高，例如「為什麼要來北京」中「北京」比「為什麼」重要。

另一部分與「用戶輸入的搜索詞匹配」基礎上，與知乎特點相結合。

比如通常，一個 1000 字，482 贊同的結果，得分天然比一個 20 字 0 贊同的結果要高。

好的搜索可以很好的平衡二者，給出理想的整體排序權重。而知乎搜索目前的排序演算法本身仍然存在不足，在兩種權重因子的計算上都有一些問題。

尤其是第二部分，儘管知乎擁有豐富的用戶內容評價數據，到目前為止的權重策略很不理想，繁複冗餘，沒有最終取得應有的理想效果。

而問題3中的一些原因實際讓這個問題雪上加霜，大幅惡化，導致了大量無答案或者無贊問題排序過於靠前的嚴重問題。

問題 3，性能和穩定性問題

目前知乎平台的優質回答已經達到了千萬量級，包括搜索請求量在內的所有訪問指標都取得了超預期增長。

這種迅猛增長的情況極大考驗了按照之前數據規模和請求規模設計的整體搜索系統。眾多的權重因子隨著規模增加複雜度大幅提升，短期內性能和穩定性成為很大問題。所以最近一段時間為了保證對每次搜索請求都能正常返回結果，我們不得不對權重演算法做了簡化，這也就部分導致了問題2中結果權重出現的問題。

「知乎的搜索功能如此之爛」的背後的技術原因分析大概就是這些。

綜上，確實沒有做好。所以「被罵也是應該的」。

第三部分，我們為什麼沒有接入 SITE（通用引擎的站內搜索）

儘管線上問題很多，解決起來也不容易，但考慮從知乎搜索能到達的理想狀態，我們仍然不甘心簡單接入一個 SITE 語法搭建的站內搜索了事。

一個重要原因是，知乎搜索是貫穿整個知乎平台的重要基礎功能。用戶在提問時用到，在找人時用到，在邀請回答時用到，在引用答案和公共編輯時也都會用到。搜索對於整個產品的效率都有很大影響。

另外一個重要的原因是：知乎的內容不僅僅是一個個網頁。知乎上用戶與內容之間豐富的互動信息可以幫助搜索引擎識別哪些內容更為重要，數據富集度和準確度遠遠高於「PageRank」，同時，知乎的內容天然有人的屬性，而這應該被用來滿足知乎特有的搜索需求。比如：

個性化

與你相關的內容可以有更好的排序，你曾看過的、點過贊同反對的、關注過的話題里的內容等，搜起來應該更容易。

社會化

你關注的圈子中用戶的贊同、反對、感謝和評論可以更好的幫助你定位你找的內容。

通用引擎的站內搜索確實能簡單快速解決目前很多的搜索痛點問題。但對知乎來說它是沒有生命力，或者說提高空間非常有限的。我們希望知乎上的內容能被更好的搜索，知乎獨有的用戶需求能被更好的滿足，所以我們並沒有選擇這個明顯更為容易，也是一部分網友建議的方案。

第四部分，我們正在做什麼

是的，我們正在醞釀一次搜索改進，針對上面提到的問題，期望能一次性解決大部分。它將是知乎搜索一次比較大的變動，除了使用量最大的問答搜索之外，用戶和話題搜索也在改進範圍之內。

當然，新的搜索只是一個起點，它一開始只是解決了上面提到的搜索效果問題，界面和功能不會發生任何變化，只是搜索效果會變好一些。但我們希望它會在逐步發展中，對知乎內容和知乎用戶的理解更充分，也更為靈活，逐漸明顯不同與「SITE 語法搜索」的效果，讓知乎用戶用起來會更爽。

一切順利的話，新搜索很快會與大家見面。希望各位屆時能再次試用。同時，也懇請知友們繼續多多通過回答、評論或私信向我反饋你遇到的效果不好的搜索詞，這對我們正在進行中的搜索效果整體改進幫助很大。

-----------------------------更新分隔線-------------------------

新搜索效果已上線，參考：這不是文本框，是搜索框 - 知乎產品專欄 - 知乎專欄

希望大家繼續多多關注和吐槽知乎搜索，謝謝！

因為貴: ) 要做到效果不被罵，幾百萬砸下去才能看見些成效吧。

會做搜索的工程師很貴的。能夠帶搜索團隊的leader更貴。
要想做到過得去，不被到處抱怨，起碼要5個熟練工干大半年。
按照4人年工時，每人年的人力成本往低了算按照50萬（對應25萬左右年薪），那也是兩百萬打底。

這還沒算對應的PM和測試的成本。人力成本也算的非常低，在北京這個價格便宜的沒有道理了，知乎如果能夠按照這個價格招到這個水平的開發估計老闆們做夢都笑醒了... 且不要說這種人不好說，基本也就只能去百度和360搜索挖了，核心工程師在兩家都是寶貝，我覺得如果最後整個團隊一個人的一年成本能控制在70-80萬就算是成功。

得，這麼一算奔著500萬去了，這樣還只是搜索效果過得去不被罵，對知乎的核心業務幫助短期來看大概可以忽略吧... 比起提搜索效果，知乎在技術上優先順序更高的項目多了去了...

所以還是洗洗睡，安心用Baidu/Google的站內搜索吧...

來，一併說了吧

問：搜索哪裡差
1.關鍵字佔百分之九十都搜不出來
2.搜索一個內容，首頁的問題大多都是零答零關注，這樣的搜出來有什麼用？
3.搜索出來的內容不能按相關度/熱度/時間/質量排序，我也不知道知乎是怎麼排序的

問：搜索為什麼這麼差
答：不知道

問：知乎不改進的話俺們怎麼辦呢
1.用百度/谷歌搜索「想要的內容+知乎」
1.百度谷歌『關鍵詞 SITE:http://zhihu.com』
2.搜索相關話題，在話題下看精品答案
3.給黃雞心發私信罵一頓出氣，再改用百度搜索

問：知乎客戶端收到新評論要跋山涉水才能看到，大家都是這樣嗎？
答：是的大家都這樣，如果該回答熱度高，可以考慮關掉評論，或者用電腦登錄查看，可定位

問：為什麼自己的匿名回答一旦發布就再也找不到了？
答：是的，知乎沒有給用戶的匿名回答建立索引。

問：那怎麼找到自己的匿名回答？
1.你可以開啟新贊同/感謝提示，這樣有人給你的匿名回答點贊，你就可以再見它一面。
2.回答了問題，就會自動關注該話題，匿名也關注，如果你沒有取消關注，就可以去關注話題下尋找你的回答。
3.建立一個私密收藏夾，收藏自己的匿名回答。隨時可看。

問：為什麼有時候自己的動態里會顯示自己關注了一些奇奇怪怪的問題？
答：可能你邀請過別人回答此問題，知乎感覺你對這個問題感興趣，因此關注了。但是現在好像沒有了。

問：為什麼時間線首頁經常會重複出現幾天前別人的答題？
答：這是新版首頁的特點，以免你錯過以前的精彩回答。可以在設置中關閉。

問：時間線首頁全被話題新問題佔領了啊！看不見關注的大v的新回答了怎麼辦？
答：這是新版首頁的特點。你可以選擇取消關注一部分話題，也可以在設置中關閉新版首頁。

問：手機客戶端編輯新回答時，手一滑就退出了，怎麼辦？
答：聯網情況下，可以在草稿中找到未發表的內容。只是空格不見了。

問：用手機客戶端編輯回答時，手一滑退出了，再進去發現新編輯的內容不見了！怎麼回事？
答：是的，我碰見過很多次，建議在電腦上修改，或者養成在手機便簽或者印象筆記上編寫回答和修改回答的習慣。再直接複製粘貼發表。

想到別的再補充。

看到這個問題下的2.2K關注，知乎社區老總小周不禁冷笑了一聲:媽的，這個月的活躍度KPI考核壓力又輕了。

兩分鐘後，知乎搜索負責人接到了來自小周的電話:「小王，聽說你們組來了個搜索技術大神？」

小王頓時喜上眉梢，剛挖來的新手沒想到這麼快就被領導知道了，這是要升職加薪的節奏啊。

然而還沒等小王邀功，電話那頭傳來了怒吼聲:「趕緊讓他滾！你他媽還想不想幹了？老子花錢請你不是讓你來認真寫代碼的！」

小王仰頭看了看窗外，兩滴眼淚無力的流了下來，本來搜索組在知乎已經是地位最低的組了，現在……

滴答滴答五分鐘又過去了，小周想了想又撥通了知乎hr的電話:「小陳，誰他媽讓你給搜索組加薪的？！！！」

「可是產品組的員工最低工資都是搜索組工資最高員工2倍多了，我不過給搜索組每人加了10元錢每年而已……」小陳囁嚅道。

「老子花錢不是讓他們來好好寫代碼的！」

……

又是五年過去了，知乎早已成為互聯網最活躍的社區，沒有之一。

同時，知乎旗下知乎商城，知乎貼吧，知乎飛車，知乎CF等在同類中已成為數一數二的領先者。

納斯達克慶功會上，面對各色記者的採訪，知乎老總小周一把摟住了搜索組負責人小王感慨道:「這都是小王的功勞啊！！！」

想起了昨天在知乎搜索輸入「周源」兩字，卻彈出了「李彥宏」的個人介紹，眾人紛紛向小王豎起了大拇。

小王終於痛苦的大聲哭出聲來……

完。

覺得在百度搜知乎的內容都比在知乎搜知乎的內容快的多得多。

何止搜索差，不知道是故意的還是我笨啊，收到的評論不能定位，必須自己去翻評論區才能找到，我就奇怪下面幾千個評論回復的你們是怎樣定位可能真的是我笨吧，還有電腦網頁版啊，長答案不能收起來，我勒個去，想看下個答案必須相當注意的往下滾分分鐘就滾過了，我不知道你們是不是可能是我笨吧。說回搜索吧這就真的不是我笨了，搜出來的全是些沒人回答沒人關注的問題，必須要在話題裡面自己慢慢找，
我頂，丟你咩，哪！！！！！！！！

把檢索效果問題歸咎於技術是容易的，畢竟是直接原因。

解決方案也將自然而然，一條路子是技術外包，請別人幫忙解決（似乎知乎已經這麼幹了）。另一個就是自己投入人手做，如 @熊辰炎同學所說：五個熟練工幹個大半年。

還有其它的選擇不？假如只有一兩個人，只有三五個月，能不能讓知乎的搜索做到還不錯的程度？我認為可以。如下是我的方法。

第一，搭建快速的迭代通路：

人要減肥，第一步是買個秤。要做搜索，第一步是把評測基礎設施建好。其中包含評測團隊，評測工具，評測方法與標準等等。這一步之重要程度往往被忽略，但試想，如果技術人員辛苦做出來一個有可能改進效果的方案，根本不能被評測出來，或者一次評測要等待數個周，那他將完全沒有動力去改進效果。更重要的是，評測是揭示效果問題不可缺少的環節，倘若知乎的有一個評測團隊，每周把自己跟競品搜索的DCG分值發給他們的產品技術負責人，效果問題可能早就被重視並試圖解決，不應該等到問題以這樣的方式暴露；

第二，建立以機器學習為核心的排序模塊：

國內估計還有好多公司，以手工的方式做排序。如果我猜的沒錯，知乎的團隊應該也是其中之一。而機器學習方法在排序在效果上，已經徹底被證明是超越人工的。而更加重要的是，機器學習模塊擁有無可比擬的迭代速度優勢，它可以以自動的幫助效果人員挑選排序特徵，折中排序特徵的重要程度，並生成排序邏輯。而效果工作，迭代速度為王。可以用簡單一點的回歸模型，也可以用複雜一點的GBDT，但花一些時間做這件事，一定磨刀不誤砍柴工；

第三，圍繞特徵工程迭代效果：

搜索排序依賴的特徵主要包含幾個類別：文檔重要程度，文本相關度，以及用戶行為數據。絕大多數搜索引擎的優化過程，都外繞這三方面。哪些特徵更好的表示文檔的重要程度？在知乎的產品場景下，我相信用戶的評論數，點贊數等等都有用，甚至可以借用類似PageRank的思想，將文檔質量與用戶質量相互傳播。文本相關度方面，知乎搜索更多的是文本類匹配，那麼IT/IDF，BM25等等都應該有用（還不夠大不了看看Paper嘛）。完善了這兩類特徵，再製作用戶短期行為對應的特徵，這三步都做完了，效果應該就不會太差了。

當然排序不僅僅包含這些，還有各種離線數據挖掘流程，知乎的產品形態也意味著用戶的社交關係也將作為排序重要的參考。而做到最後，還可以基於對用戶需求的深入理解，超脫於基本的文本相關之上，但這些我覺得，還是可以作為有充足資源後的進一步工作了。

第四，投入一定的運營：

主要為了優化TOP結果，避免在用戶大量搜索的結果中出現顯而易見的Bad
Case。糾錯糾不對，就增加個人工規則，排序實在沒有辦法，就用簡單邏輯調一調。這一塊可以作為補充。

當然，另外還有一個重要的技術板塊是自然語言處理，也可以用類似排序的迭代流程進行優化。記住，我們要做的不過是優化知乎的搜索排序相關的自然語言處理功能，以我的經驗，用不著那麼大的資源投入。

在我司，有兩個月迭代效果的時間，目標就要超過競品，三四個人的小團隊即負責三四條不同產品的效果。我始終都不認為這是正常的，效果工作是一個長期且需要大量投入的東西，是一個不停的解決「剩下的百分之八十」問題的流程，做到好跟做到精湛所需投入可能天差地遠。但，良好的方法論，優秀的技術選型，以及對事物本身的深刻理解將極大的節約成本。有此，小可博大，無此，事倍功半。

我一直是百度的堅定反對者，我一直弄不明白，為何百度這麼爛，但中國的可憐網民卻不得不用。直到我用了知乎搜索，才知道，原來在中國，百度雖然爛，但和它比起來，搜狗、360、bing，更是爛到一塌糊塗，慘不忍睹。

我在知乎上搜索我的問題，直接複製原文都搜不到。我在百度上，一下子就搜到了。居然還有恬不知恥的開發者上知乎為自己辯白，好像搞出這麼爛的搜索引擎，自己一點責任也沒有一樣。

奉勸大家，在中國，用不上谷歌，還是得忍一忍用百度。百度雖然爛到髮指，但還沒爛到十八層地獄去，而以知乎搜索為代表的其餘國產或閹割的國外搜索引擎，已經爛到辣眼睛的程度了。

說個最基本的問題，在知乎app搜索特定用戶id得到的排序一直非常差，這個不能用分詞來解釋了吧？

下圖，k神在哪裡？

我來展示一下它有多爛

對啊，還有評論區的問題。每次別人在評論里回復我的時候，都要一條一條的找。
懷疑，知乎是故意的，這樣流量就都給了知乎了吧。

手機版，別人回複評論，我要從第一條一直往後翻，好累。
除了搜索的問題外還有還有一些BUG，真沒良心_(:_」∠)_

有一次我在一個高票答案下留了個評論，後來過了好幾天，有人給我的評論點了一個贊，然後我想不起來我評論的是什麼，於是手機版的我翻了好幾百條評論才發現我評論的是哈哈哈。感覺我浪費了生命。

我不覺得爛啊。不信你看~

我搜李雲龍的「義大利炮」，結果搜索欄給我建議了這個問題：
和義大利男人約會不到一小時就親了我並且想要我，這到底是約會還是約炮？ - 愛情

真正的義大利炮Σ(っ °Д °;)っ

這隻能是技術問題。其次可能Python上面也沒有什麼好的搜索引擎。
我建議用百度、google後面加site:http://zhihu.com 搜索。效果好的多。

誰說知乎搜索爛了，看圖。

貴乎的辣雞搜索終於一去不復返啦！(o゜▽゜)o☆[BINGO!]

知乎何止搜索爛，整個後台都很爛好吧。
天天刷不出來，畫圈圈，還經常服務區提出了一個問題。
提你妹啊。

知乎是給程序員用的，懂不懂 ~

搜索，這個要求你會用搜索引擎的高級搜索技巧，比如：{ 單身狗 site:http://zhihu.com } ，{ inurl:people intitle:約 site:http://zhihu.com } 之類的，你們還是too young啊。

評論看不到要學會用Ctrl+F以及F3組合鍵，搜索自己ID。

...