文｜見鹿@知乎
本文已獲作者授權(quán)，禁止二次轉(zhuǎn)載

前言

搜索引擎是個極其復(fù)雜的系統(tǒng)工程，搜索引擎上并不會大力出奇跡，需要一點點打磨。在搜索引擎上，q-u相關(guān)性計算是基礎(chǔ)，但仍需要考慮其他很多因素，其中非常重要的兩點就是權(quán)威性和時效性。

不同的query下，一直都會有新的資源產(chǎn)生，但不是說所有query下都需要將新資源排序、展示出來。有一類query，在這些query下用戶期待看到最新的新聞事件搜索結(jié)果。搜索引擎需要將這部分突發(fā)需求識別出來，并且將其相關(guān)的新資源盡可能排上來。

例如：在科比去世（2020-01-27 R.I.P）的背景下，此時當用戶在搜索引擎上搜索"科比"時展示的結(jié)果，可能跟幾分鐘前的展示結(jié)果差異很大。

或是“武漢爆發(fā)新型肺炎”這類query,可能平時沒出現(xiàn)過，屬于低頻冷門詞，但用戶想看的就是最近的結(jié)果。

諸如此類的需求變化識別，搜索引擎在自動化識別的過程中，遇到哪些challenge？

注：有一部分query需求也是一直要求"實時新"，如天氣，匯率等需求，這部分query形態(tài)比較穩(wěn)定，并且對這部分query而言“唯一不變的就是變化”，這部分需求識別先不放在本次討論中，我們討論的是這種明確有事件性質(zhì)的識別，可能結(jié)果形態(tài)和平時不同的case。

難點與挑戰(zhàn)

基礎(chǔ)指標要求非常高，速度和準召天然的矛盾

召回問題：這類query的占比低，因為如果沒有識別召回，則基本上通篇檢索結(jié)果，都不會滿足。假如：科比去世背景下，“科比”如果沒有被識別出來，則通篇不會有其飛機失事的新聞結(jié)果。

準確率問題： 由于其有特殊的地位權(quán)重，就要求對識別的準確要求也很高。

識別速度： 準召高就好了么？并非如此，因為新聞事件通常生命周期很短，若是事情已經(jīng)過去1天了才識別出來，熱度的高點都過去了。識別速度也非常關(guān)鍵。通常我們是要做到分鐘級識別。

激發(fā)多，跳躍性強

一個新聞事件的發(fā)生，會激發(fā)出好多周邊需求，而這些需求分布很泛很散。

從很多統(tǒng)計信號上，根本不好區(qū)分。白百何出軌事件下，“失戀三十三天”頻次pv增加50w...

依賴的下游很多，對效果的影響

快速識別出來不是目的，將真正的優(yōu)質(zhì)新結(jié)果展現(xiàn)到合理的位置才是。

需要上游分鐘級別的抓取、建庫、流式數(shù)據(jù)建設(shè)，又需要下游的召回、排序、pk機制效果保障。

cache的問題，緩存與新結(jié)果識別展現(xiàn)的天然矛盾

每天數(shù)十億的pv請求，每次pv又要去數(shù)千億的網(wǎng)頁庫中查找召回，再做上層排序，每次開銷是很大的，勢必需要上層對于中高頻的query做cache緩存。

而cache緩存和新結(jié)果的識別又是天然矛盾。緩存存在的意義就是不下發(fā)查找，而識別依賴查找，總要有一定的機制去指導(dǎo)去做主動更新。

短生命周期，標注難、評估難

通常一個事件，發(fā)生事件只在幾天只能，對齊評估標注，需要考慮當時的情景。而且特別是事件剛剛爆發(fā)下，需要在分鐘級內(nèi)對其進行現(xiàn)場錄制比較。

這個評估非常非常的耗費人力物力，超乎一般的想象。

復(fù)現(xiàn)歷史問題現(xiàn)場難

對于剛剛發(fā)生的事件而言是分鐘級別影響，可能5min之后就是完全另一個效果展示了。因為突發(fā)識別的有無、強弱影響很大。“九寨溝地震”背景下，可能就在短短幾分鐘之內(nèi)搜索“九寨溝”的展示就差別很大。

若是有問題，需要及時抓取記錄，否則無法事后進行分析。

回歸歷史問題難

資源、頻次等都是瞬息萬變的，所以即便做了模型、策略優(yōu)化。

也很難回歸之前的歷史問題case,需要將很多很多的信號全都dump下來，才有可能去回歸效果。這需要架構(gòu)方面的大力支持。

最近進展問題

有的事件雖然有識別，搜索引擎也知道它是新聞事件，但若它有最新的進展，則本質(zhì)上在這個時間點后面的檢索需求又發(fā)生了改變。如何識別出這個時間點，已經(jīng)將這個時間點后面的資源做優(yōu)質(zhì)的boost，仍是一個比較大的挑戰(zhàn)。

例如：“歐冠決賽”，假如比賽剛剛結(jié)束了，新的結(jié)果已經(jīng)產(chǎn)出，此時的搜索就需要將最新的比方結(jié)果給出，而不是上半場的播報，或是半天前的賽前分析了。“無錫高架橋死傷”，若官方出了最新通報，這之前的死傷結(jié)果就不是所需要的了。

這部分case真實占比還不算低。

作弊問題，流量問題

在抓取建庫時需要做頁面分析，需要對流量作弊做分鐘級別的控制。但處于實際效率，對于高時效部分的pv在反作弊上的工作有所折衷。anti-spam的一些漏網(wǎng)之魚會給整體識別帶來不小的麻煩。

尤其是一些商品，加盟等有高危影響的方面。

長冷泛化問題

同一個事件，在這么大量級的用戶群體中，會出現(xiàn)成百上千個不同的描述。

如何找到同一事件后相同query間的關(guān)系，并利用這個關(guān)系，是一個很大的挑戰(zhàn)。

新聞?wù)军c下大量非新聞

大的新聞?wù)军c，也并不是那么可信。包括熟知的一些非常大的新聞?wù)军c。

這超乎了很多的想象。

不信你可以統(tǒng)計你資訊app上推送的內(nèi)容，以及新聞?wù)军c/app上隨機看，看看到底有多少是真正的新聞的比例。或許你就懂了。

地方性、垂直領(lǐng)域性

一些地方性、領(lǐng)域性的事件，甚至對于你而言非常小，但對他而言，有確實是一個新聞事件按需求，我們每個人都會有這樣的需求。

例如某個縣的副縣長xxx被開除黨籍、xxx小區(qū)著火，甚至“西二旗路面大坑”，這種很小的、頻次很低需求（不過上面這些case，我們還確實解決了:）

庫種差異

我相信所有的搜索引擎公司的網(wǎng)頁庫，都是漏斗形結(jié)構(gòu)。

這樣的話，同一個query在不同庫種下搜索的結(jié)果存在天然的分布不合理。特別中高頻短query。如何解決這個問題，同時又要兼顧真有突發(fā)事件的需求不被誤干掉，挑戰(zhàn)同樣存在。

后臺回復(fù)關(guān)鍵詞【入群】

加入賣萌屋NLP/IR/Rec與求職討論群

后臺回復(fù)關(guān)鍵詞【頂會】

獲取ACL、CIKM等各大頂會論文集！

總結(jié)

以上是生活随笔為你收集整理的做一个好的搜索引擎有多难的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。