轉載自 DataFunTalk 公眾號  http://www.6aiq.com/article/1535003242764

前言

國內搜尋引擎大事記

1998年，Google釋出；2000年，百度釋出；2004年，搜狗釋出；2006年，搜搜釋出；2010年，Google退出中國；2012年，360搜尋釋出；2013年，神馬釋出，搜搜併入搜狗，百度收購91；2017年，微信推出搜一搜。

神馬搜尋簡介

1.關於神馬

神馬搜尋是阿里集團和UC共同推出的移動搜尋引擎。依託於UC瀏覽器超三億的使用者量，以及阿里巴巴強大的技術背景和雲端資源，使得神馬搜尋在移動搜尋的技術性和廣泛性、綜合性等方面具有很大的優勢。國內知名移動網際網路第三方資料探勘及分析研究機構比達諮詢（BDR）釋出《2018上半年度中國移動搜尋市場研究報告》，報告顯示，2018上半年度中國移動搜尋流量市場份額中，神馬搜尋以21.8%的市場份額排名第二，搜尋流量同比增長21.7%，增速排名第一。神馬搜尋作為阿里巴巴大文娛集團重要的智慧諮訊媒體平臺的主要產品之一，背靠阿里生態優勢資源，尤其在資金、技術、人才，以及阿里整個戰略拉通,讓神馬搜尋的未來無限可期。

2.UC國內產品陣列

   UC國內的產品陣列，由UC瀏覽器，UC頭條（UC瀏覽器首頁的feed流新聞），神馬搜尋共同組成，以及我們剛才講的語音助手和問答的APP，以上就是我對神馬的簡單介紹，下面我們分享下技術方面的事情。

神馬搜尋的技術演進

1.神馬搜尋相關性技術演進

其實整個搜尋分為四個階段，從13年之前主要重規則，重特徵的一個階段。大家都知道，谷歌在13年之前是沒有上任何learning to rank的東西，他的特徵計算也許用了機器學習，但排序全都是用規則來做的。大概從13年之後，learning to rank 普遍火了起來，各大公司普遍切換了learning to rank的演算法，那個階段是重規則重特徵的一個階段，就是說模型很重要，但是還會建立大量規則。一直到兩年前，隨著資料量的持續增長，有了大量的自動標註樣本，DNN開始在NLP領域火了起來，並且確實有不俗的效果，所以很多公司開始了機器學習化，把大量的規則遷移到了機器學習演算法，一直到今年。未來呢，我認為會是創新的階段。搜尋這麼一個經典的問題，現在絕大多數競爭對手，都使用的是最新的技術。論文上有的技術，我們基本上都用了，還有工業界我們已知的技術，我們也基本上都用了。這個時候，你想做的比對手好，想從國內做到國際化，你一定要做一些不同的事情，這就是我們神馬未來要做的事情，要做創新。

神馬是一個比較年輕的搜尋引擎，13年剛剛成立，所以神馬直接從重規則，重模型這個階段開始，整個神馬戰略在機器學習的使用方面是更激進的。我經歷過很多家公司，對比之下，神馬這邊是機器學習化程度比較高的公司。

2. 搜尋是天然的AI應用場景

這裡有一個小故事，我做搜尋應該有七年了，中間的時候做了一年AI，做知識圖譜。算上實習的話，也算經歷了百度、微軟、搜狗，最後來到了阿里。上次換工作之前我在想，我做了五年多的搜尋，每天做的事情基本都是一樣的--就是分析bad case，找改進點，實驗改進方法，再實驗一種方法，再換一種方法試試，直到策略顯著勝出或者放棄為止，周而復始。於是幸運的話，一個月改進了千分之一個點，不幸運的話，可能三個月改進萬分之一個點。所以當時我實在是不想做搜尋了。當時就給我一個前輩說，我不想做搜尋了。前輩說那你想做什麼呢，我說我想做AI。然後前輩就愣了一下，說那你還不是想做搜尋嗎？

為什麼這麼說呢，為什麼我最終還是來到了神馬做搜尋。我後來是這麼思考的，想做好AI的話，需要很多前提條件，而搜尋恰恰是天然的AI場景。而且神馬這邊對搜尋的視角很不同，很多公司為了做搜尋而做搜尋，神馬這邊除了做搜尋業務，還要以搜尋為陣地做AI的實踐。

我們先來看搜尋是天然的AI場景這句話，先說這句話對不對。大家可以想一下，我們要把AI做好的話，需要哪四個基本的要素：第一，我們要有資料，沒有資料的話，沒有辦法訓練模型，只能靠人工規則，那就只能有多少人工就有多少智慧了，這不是大多數人想做的AI。第二，要有場景，AI要有真實的使用者需求，我們不能偽造使用者的需求，不能只是做出一個漂亮的東西來但沒有人用。比如做出來一個alpha go確實很厲害，但是誰會用alpha go呢？我們需要一個真實的使用者場景，使得我們的AI技術真正的落地。第三，我們需要人才，我們需要有大量經驗的人才。比如我當時做知識圖譜的時候，HR和我說你要招有五年以上工作經驗的人，然而谷歌是在12年才推出知識圖譜的概念，也就是說即使我們當時把谷歌最早的圖譜團隊的人挖過來，也只有4年工作經驗。但是我們做搜尋的話，真的是有工作經驗10年以上的人才，這能夠保證我們在這一個領域，去做一些比較難得事情。第四個是你要有一個商業化變現途徑。一個好的AI應用，一定是既能夠服務好使用者的同時，又可以給公司賺錢，這樣才是一個能夠持續執行下去的生態。那搜尋是一個什麼樣的場景呢，首先我們擁有千億以上的網頁資料，這是絕大多數公司所不具有的。同時，每天都有億級使用者的線上反饋，這樣就產生了大量自動標註的樣本用於深度學習訓練。而且，我們有充足的資金進行標註支援。第二，搜尋有很多AI真實的應用場景，比如說對query的理解，網頁的理解，搜尋的排序，相關推薦等，這些都是非常有難度的NLP應用場景，基於規則很難去做，所以天然對於AI有需求。第三，搜尋積累了很多有經驗的人才。搜尋的話，大家會發現一個好玩的現象，它不僅能夠吸引人才，積累人才，還能夠輸出人才。今天的很多新產品，比如抖音、今日頭條，還有很多智慧化新產品，其實都是搜尋的人才過去做的。第四，搜尋具有很大的市場，國內有千億級人民幣的市場，國際上大概是這個份額的五倍左右，而且南亞和東南亞，有大量的人口，且網際網路剛剛興起，他們就像是下一個中國，這個市場的潛力其實是非常大的。所以說，搜尋真的是天然的AI場景，很幸運的是，我們的公司、戰略決策層面看到了這一點。我們不僅為了做搜尋，還為了鍛鍊我們的AI技術，去積累我們的AI人才。

3. 神馬搜尋的技術棧

做搜尋首先要有一個好的系統框架，否則研發大部分時間可能會是在做系統運維。由於神馬成立的比較晚，所以神馬整個線上系統是基於zookeeper和yarn這種系統架構來做的。這首先可以保證很好的效能，可以從百億級的網頁中，搜尋一個網頁達到毫秒級，其次有很好的可用性，比如世界盃、高考一來，依舊可以提供很好的服務。當然這兩項幾乎所有的商業搜尋公司都可以做到。後面兩項就是神馬做的比較好的。第三是良好的可伸縮性。很多時候公司需要對伺服器進行增添或變更，比如說遷機房/擴容。我曾經經歷過一次擴容，佔用了三四個專家級同事前後兩個月的時間，最後才把機器調整好。這個經常被稱作“在行駛的火車上換輪子”，好像是完成了一件了不起的事情，但實際原因是系統框架無法給予高效的支援。在神馬這邊，基於zookeeper和yarn這種資源管理方法，一個運維，一個按鈕，幾分鐘就可以把事情搞定。我覺得這才是了不起的事情。第四我們的系統有非常好的可擴充套件性，比如說我們想擴充套件一個功能的時候，或者想把大搜遷移給APP搜尋用，或者做一個垂直搜尋，可以非常方便的做到這件事情。以上是系統框架部分。

相關性計算技術是搜尋中的核心技術。包括Learning2Rank的模型，DSSM/CDSSM這種基於深度學習的模型方法，也有傳統的proximity、BM25的計算方法。這只是一部分，其實20年的搜尋積累了非常多的技術。比如在召回方面，除了傳統的詞召回，大家普遍開始嘗試向量召回。這部分後面我們詳細說。

可能沒有一個場景像搜尋一樣這麼依賴自然語言處理，因為它處理的所有東西，都是需要自然語言處理，這裡麵包括Word embedding向量表示方法，DNN/CNN/RNN等深度學習模型，HMM/CRF這些傳統的模型，包括最早積累的一些統計規則。這些都在神馬裡有深入的應用。

第四個是離線計算，包括我們怎麼對DOM tree這種結構化的網頁進行抽取，怎麼進行連結分析，頁面質量分析，爬蟲的排程等。

4. 技術架構

下面看一下搜尋引擎技術架構。首先我們要有一個爬蟲系統，要把所有的網頁資訊都爬取儲存下來以供檢索；其次我們要有一個比較好的儲存平臺，我們這邊有很多阿里雲支援的儲存服務；第三個我們要建索引，包括網頁索引，框計算內容索引，還有結構化的知識圖譜索引；在此基礎上，我們就可以應用演算法排序了，比如計算本文的相似度，基礎排序，點選排序，learing2Rank模型, 深度學習模型；有了這些演算法之後，我們還要加一些前端的業務邏輯，比如說搜尋天氣，這不是一個普通網頁，是一個待插入的業務卡片。這就是整個搜尋的架構，下面我們逐個詳細講一下其中比較核心的技術。

神馬搜尋的核心模組和技術挑戰

5. Query理解

    query理解的任務都比較經典了。通過對海量的查詢日誌，點選反饋日誌進行資料探勘，我們可以做很多傳統自然語言處理任務，比如說中文分詞，新詞發現，詞性標註，句法分析。搜尋在這些基礎上，還有其專有的任務。包括query重要度的計算—比如使用者輸入十個詞，其中有些詞必須進行索引求交，有些詞則可以不求交只參與排序。包括同義詞挖掘—“魔獸怎麼開啟“，其實使用者問的是“魔獸世界”。包括語言的糾錯，如果使用者輸入錯了，還需要幫助使用者糾正過來。包括查詢擴充套件，查詢改寫等。雖然這些都是很經典的任務，但還有很多有挑戰的問題值得探討，可以優化的。

Query理解的技術挑戰

1. 如何處理缺少使用者反饋的長尾query?

大家知道query分為長尾和頭部，頭部query有大量的使用者點選，大量的使用者反饋，點了哪個頁面，在哪個頁面上停留了多長時間。我們可以使用這些資料進行機器學習，得到很多的query特徵；但是有很多長尾詞，使用者可能一個月只查一次，或者半年一次，甚至從來沒有出現過。那我們如何處理這些長尾查詢呢？如果用規則的話，長尾詞的需求非常多樣幾乎無法被窮舉；想使用機器學習，卻沒有任何樣本；如何去做，是需要一些創新的想法的。

2. 如何處理NLP與排序優化的目標差異？

之前做NLP轉做搜尋的同學，比較容易遇到這個問題，比如“2019年俄羅斯世界盃”這裡面哪個幾詞比較重要呢？如果從NLP的角度來考慮的話，2019年是一個時間限定詞，世界盃是一個主題，俄羅斯是他的修飾詞，俄羅斯世界盃可能舉辦了很多屆，不一定是哪一屆，但是2019年只有一屆。所以從NLP的角度來看“2019年”和“世界盃”是重要的詞。然而這個query有一個很大的問題，那就是2019年其實沒有世界盃，俄羅斯世界盃是2018年舉行的，使用者輸入錯了。如果搜尋引擎拿著“2019年”+“世界盃”去檢索的話，沒有一個好結果。反而拿著“俄羅斯：+”世界盃“去檢索的話，能得到好結果。這就是NLP問題與目標排序不一致的問題。

3. 如何進行語義召回？

比如我們希望通過“腹部硬”的query召回包含“腹部腫塊”的網頁，從詞級別上“硬”和“腫塊”肯定不是同義詞，但是語義上它們是一個意思。召回有兩個方法可以做這件事情，基於詞的召回可以只保留“腹部”做索引求交，我們也許能召回腹部腫塊，但是要兼顧索引的效率：如果查詢詞只有一個的話，會召回上億個頁面，效能代價很大。第二種方法，可以採用向量召回，如何使用向量召回？我們假如使用DSSM模型通過使用者的點選學習query的向量和title的向量，那我們就可以把query和title做向量化，做相似性計算。但是這種方法有什麼問題呢？由於DSSM需要大量資料，人工標註不太現實，只能用自動標註樣本。如果使用點選資料，這意味著訓練的樣本都是系統已經可以召回的樣本，但是我們做向量召回的目的其實想要召回我們目前無法召回的樣本，如果使用已經能召回的樣本做訓練難免在做重複的勞動。解決這個問題也需要一些創新的想法。

6. 排序模型

所有的搜尋系統都需要經歷索引歸併、粗排、精排、LTR、rerank等流程，可能各個公司叫的名字不一樣，但是意思是一樣的。首先我們要進行索引歸併，比如要查詢ABC的話，我們可能要查詢A and B and C或者A and （B or C）。庫裡有百億級的網頁，經過索引之後大概有百萬級的網頁，但是這個數量還是有點多，需要粗排從裡面篩選出千級/萬級的頁面，然後再進行精排從中選出候選頁面交給LTR做排序，最後經過業務邏輯的重排，最終就是大家看到頁面的前十條結果了。今天主要說LTR部分，這也是對搜尋效果影響最大的部分。

LTR所使用的特徵有很多，它的特徵除了原始特徵外，也可以是上游機器學習模型的預測結果，包括Qanchor模型、點選指引模型、文字分類模型、質量模型、點選模型。以文字分模型為例，他的輸入為文字匹配相關的特徵，比如傳統的CTR/CQR/BM25資訊匹配特徵，DNN/CNN/RNN算出的query-doc之間的相似度，還包括了相關詞/同義詞/主題挖掘所產生的特徵。這些作為它的特徵，使用文字標註樣本進行模型訓練，輸出的值又作為LTR的輸入。而LTR模型拿到所有這些模型特徵後，使用query-doc相關性樣本進行訓練，得到最終的網頁排序。LTR模型的設計我們單獨展開來說。

（1）機器學習排序

機器學習排序首先是機器學習，但是又不完全一樣。傳統機器學習一般處理這幾類問題：分類、迴歸、聚類。但是搜尋引擎的機器學習解決的是排序問題，比如20條網頁，或者上千條網頁，你要給每一個網頁打一個分，來保證按這個分數排序的網頁順序是對的，而不是保證分數本身是精準的，所以它的學習目標和普通的機器學習目標不一樣。常用的模型包括Gbrank、LambdaMart、Xgboost、LightGBM，這四個模型我們都嘗試過，也都改進過，比如我們在Fine tune、分裂點控制、Dart dropout做了改進。這裡分享一個小經驗，並不是越新的模型，效果越好，大家一定要根據模型的特性進行優化，然後達到最好的效果。但可以肯定的是經過優化之後，學習能力更強的模型，可以拿到更好的效果。

loss function常見的有三種：point-wise 、pair-wise、list-wise。point-wise是以單點誤差作為損失函式，一個query-doc pair打一個分，機器學習就學習這個分數，這可以認為是一個迴歸問題。pair-wise的優化目標是所有的結果逆序數量最小化。比如說ABC三個網頁，A最好BC其次，那ABC的順序就是一個零錯誤的結果。List-wise優化的目標是List總體得分最大化，ABC打一個分,BCD打一個分，優化目標的是讓List分數最高。工業界最常用的是pair-wise或者半pair-wise半list-wise。

樣本方面一般使用多級標註方法。即給query-doc pair打一個0到4的一個離散的分，去根據這個分做機器學習排序。但是訓練集的標註成本比較高，尤其是標註數量越多，往往增量標註的收益越小。我們這裡採用的主動學習的方法，主動選擇有收益的樣本進行增量標註。

排序特徵可以分為Query level、Doc level、query-doc三個類別。

（2）深度學習解決方案

在深度學習方面，我們的解決方案和大多數公司都差不多。輸入分別是query和title，通過word embedding生成向量化表示，這兩個向量然後通過神經網路NN生成sentence embedding。網路型別有多種選擇，每種型別也有不同變種。比如DNN / CNN / RNN / ATTENTION或者對抗網路都可以。有了句子表示，接下來就是相似度的計算，一些常用的方法比如cosine / DNN / bilinear等，最後使用pairwise / listwise / dssm損失函式。這就是多數搜尋公司都在用的深度學習解決方案。

（3）ML/DNN的技術難點

這裡舉兩個例子：

1. 演算法優化的挑戰

之前搜尋引擎由規則做的時候，優化方法很清晰。我們直接通過bad case找到導致bad case的規則進行修改。或者增加缺失的規則來修復bad case。但是換到全部基於模型來做的話，上面的方法就行不通了。影響模型效果的就三個：特徵，樣本，模型。因此機器學習的優化需要比較好的特徵分析，樣本分析和模型分析。如果是LR模型，特徵分析很好做，直接看權重比較高的就可以，通過高權重的特徵又可以追溯問題樣本。但LTR模型多數是較為複雜的模型，這就需要有一套LTR專用的特徵分析和樣本分析方法。模型方面，當然可以使用通用的模型，但是在搜尋場景下損失函式、求解方法、假設空間，是否有優化的空間呢？我們認為是有的，而且也拿到了確實的收益。

2. 業務實施的挑戰

除了演算法本身的分析和優化方法外，具體實施時還會遇到新的問題：比如模型如何debug、如何修復badcase、如何替換長尾規則—既要避免長尾樣本被淹沒，也要避免長尾樣本拉低頭部頁面的排序。這裡面是有很多充滿挑戰的事情需要做的。

7. 點選模型

前面我們所說的方法，都是網頁通過自身特徵證明自己好。還有一個維度：使用者通過選擇證明網頁好。比如說使用者每次搜一個詞，都點那一個網頁。通過使用者的點選、滑動、翻頁、停留時長等特徵反饋網頁好壞。但是點選模型也有自身的問題和挑戰，包括位置偏置、資料稀疏、點選正反饋、真實不相關、點選泛化等問題。

——END