做一个好的搜索引擎有多难
文｜見鹿@知乎
本文已獲作者授權，禁止二次轉載
前言
搜索引擎是個極其復雜的系統工程，搜索引擎上并不會大力出奇跡，需要一點點打磨。在搜索引擎上，q-u相關性計算是基礎，但仍需要考慮其他很多因素，其中非常重要的兩點就是權威性和時效性。
不同的query下，一直都會有新的資源產生，但不是說所有query下都需要將新資源排序、展示出來。有一類query，在這些query下用戶期待看到最新的新聞事件搜索結果。搜索引擎需要將這部分突發需求識別出來，并且將其相關的新資源盡可能排上來。
例如：在科比去世（2020-01-27 R.I.P）的背景下，此時當用戶在搜索引擎上搜索"科比"時展示的結果，可能跟幾分鐘前的展示結果差異很大。
或是“武漢爆發新型肺炎”這類query,可能平時沒出現過，屬于低頻冷門詞，但用戶想看的就是最近的結果。
諸如此類的需求變化識別，搜索引擎在自動化識別的過程中，遇到哪些challenge？
注：有一部分query需求也是一直要求"實時新"，如天氣，匯率等需求，這部分query形態比較穩定，并且對這部分query而言“唯一不變的就是變化”，這部分需求識別先不放在本次討論中，我們討論的是這種明確有事件性質的識別，可能結果形態和平時不同的case。
難點與挑戰
基礎指標要求非常高，速度和準召天然的矛盾
召回問題：這類query的占比低，因為如果沒有識別召回，則基本上通篇檢索結果，都不會滿足。假如：科比去世背景下，“科比”如果沒有被識別出來，則通篇不會有其飛機失事的新聞結果。
準確率問題： 由于其有特殊的地位權重，就要求對識別的準確要求也很高。
識別速度： 準召高就好了么？并非如此，因為新聞事件通常生命周期很短，若是事情已經過去1天了才識別出來，熱度的高點都過去了。識別速度也非常關鍵。通常我們是要做到分鐘級識別。
激發多，跳躍性強
一個新聞事件的發生，會激發出好多周邊需求，而這些需求分布很泛很散。
從很多統計信號上，根本不好區分。白百何出軌事件下，“失戀三十三天”頻次pv增加50w...
依賴的下游很多，對效果的影響
快速識別出來不是目的，將真正的優質新結果展現到合理的位置才是。
需要上游分鐘級別的抓取、建庫、流式數據建設，又需要下游的召回、排序、pk機制效果保障。
cache的問題，緩存與新結果識別展現的天然矛盾
每天數十億的pv請求，每次pv又要去數千億的網頁庫中查找召回，再做上層排序，每次開銷是很大的，勢必需要上層對于中高頻的query做cache緩存。
而cache緩存和新結果的識別又是天然矛盾。緩存存在的意義就是不下發查找，而識別依賴查找，總要有一定的機制去指導去做主動更新。
短生命周期，標注難、評估難
通常一個事件，發生事件只在幾天只能，對齊評估標注，需要考慮當時的情景。而且特別是事件剛剛爆發下，需要在分鐘級內對其進行現場錄制比較。
這個評估非常非常的耗費人力物力，超乎一般的想象。
復現歷史問題現場難
對于剛剛發生的事件而言是分鐘級別影響，可能5min之后就是完全另一個效果展示了。因為突發識別的有無、強弱影響很大。“九寨溝地震”背景下，可能就在短短幾分鐘之內搜索“九寨溝”的展示就差別很大。
若是有問題，需要及時抓取記錄，否則無法事后進行分析。
回歸歷史問題難
資源、頻次等都是瞬息萬變的，所以即便做了模型、策略優化。
也很難回歸之前的歷史問題case,需要將很多很多的信號全都dump下來，才有可能去回歸效果。這需要架構方面的大力支持。
最近進展問題
有的事件雖然有識別，搜索引擎也知道它是新聞事件，但若它有最新的進展，則本質上在這個時間點后面的檢索需求又發生了改變。如何識別出這個時間點，已經將這個時間點后面的資源做優質的boost，仍是一個比較大的挑戰。
例如：“歐冠決賽”，假如比賽剛剛結束了，新的結果已經產出，此時的搜索就需要將最新的比方結果給出，而不是上半場的播報，或是半天前的賽前分析了。“無錫高架橋死傷”，若官方出了最新通報，這之前的死傷結果就不是所需要的了。
這部分case真實占比還不算低。
作弊問題，流量問題
在抓取建庫時需要做頁面分析，需要對流量作弊做分鐘級別的控制。但處于實際效率，對于高時效部分的pv在反作弊上的工作有所折衷。anti-spam的一些漏網之魚會給整體識別帶來不小的麻煩。
尤其是一些商品，加盟等有高危影響的方面。
長冷泛化問題
同一個事件，在這么大量級的用戶群體中，會出現成百上千個不同的描述。
如何找到同一事件后相同query間的關系，并利用這個關系，是一個很大的挑戰。
新聞站點下大量非新聞
大的新聞站點，也并不是那么可信。包括熟知的一些非常大的新聞站點。
這超乎了很多的想象。
不信你可以統計你資訊app上推送的內容，以及新聞站點/app上隨機看，看看到底有多少是真正的新聞的比例。或許你就懂了。
地方性、垂直領域性
一些地方性、領域性的事件，甚至對于你而言非常小，但對他而言，有確實是一個新聞事件按需求，我們每個人都會有這樣的需求。
例如某個縣的副縣長xxx被開除黨籍、xxx小區著火，甚至“西二旗路面大坑”，這種很小的、頻次很低需求（不過上面這些case，我們還確實解決了:）
庫種差異
我相信所有的搜索引擎公司的網頁庫，都是漏斗形結構。
這樣的話，同一個query在不同庫種下搜索的結果存在天然的分布不合理。特別中高頻短query。如何解決這個問題，同時又要兼顧真有突發事件的需求不被誤干掉，挑戰同樣存在。
后臺回復關鍵詞【入群】
加入賣萌屋NLP/IR/Rec與求職討論群
后臺回復關鍵詞【頂會】
獲取ACL、CIKM等各大頂會論文集！
總結
以上是生活随笔為你收集整理的做一个好的搜索引擎有多难的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： BERT重计算：用22.5%的训练时间节
- 下一篇： 为什么回归问题用MSE？