簡介：什麼是搜索的時效性？有哪些特徵？如何優化？本文分享神馬搜索在搜索排序時效性問題上的實踐和探索，從基礎特徵優化開始，通過標註數據進行排序和召回模型優化，以及時效性排序的召回體系和收錄體系。較長，同學們可收藏後再看。
一 問題定義
如何理解時效性呢？古語云：“四方上下曰宇，往古來今曰宙”。時間貫穿了一切，時間感知的唯一標準是變化。個人理解相對變化越難時間越慢，接近光速的時候時間變慢就是因爲要改變它很困難。
從內容側理解時效性
在信息場景下定義時效性的標準也同樣是變化。
信息的價值會隨時間的延續而變化，一般通常情況下信息的價值是會衰減，會失效的。這個和物理裏面的放射性很像，借用物理裏面的觀點我們對信息定義一個時效性半衰期的概念：信息相對價值衰減一半所需要的時間。對於一篇文章定義一個時間，假設文章剛發表的時候信息量是100，那麼信息量衰減到50的時候需要的時間，就是這篇文章的半衰期。
從需求側理解時效性
在搜索場景下定義時效性的標準也是變化。
搜索的最佳答案會隨着時間的延續而變化。對於不同的query，變化快慢也不一樣。對於需求最佳答案變化的頻率，我們定義一個時間敏感度的概念，用戶對時間的敏感度越高，那麼越希望得到新的內容，內容的時效性和整體的滿意度的相關程度越高。
泛時效性
時效性從需求出現的時間分佈上大概可分成3大類：突發時效性，週期時效性和泛時效性。
具體的分類可以參考下圖，本文核心介紹和解決的是泛時效性。
不同於突發和週期時效性，泛時效性query和普通搜索query時間分佈上基本一致，從時間序列分析上基本屬於平穩序列。
比如，杭州西湖限行，阿里市值，從蕭山機場怎麼去阿里西溪園區方便，今年最流程什麼款式的女裝，杭州有哪些店比較好喫，靈隱寺附件民宿推薦等。
上面介紹到內容側和需求側的時效性相關的兩個量化指標：時效性半衰期和時間敏感度。爲了方便，我們將這兩個指標的強度分類5檔：
二 評估標準
對於任何問題進行優化的前提是必須知道衡量標準，時效性問題也不例外，在進行優化之前先要制定一套合理的評估方案，一是可以用來對現狀摸底，進行Case分類和比例分析進行鍼對性的優化，二是優化完之後通過前後對比得出優化對於整體指標的提升。
在做時效性優化評估之前，搜索本身是有綜合滿意度評估打分的，但是綜合滿意度打分對於時效性並沒有很強的體現，只是在時效性明顯不滿足需求的情況下進行扣分，相對較弱。爲了更好的暴露出時效性的問題，我們單獨構建了時效性滿意度的打分標準，評測時按照兩個標準進行同時打分。
和神馬搜索滿意度類似採用滿分3分，對Top3的結果進行評測，按照結果不滿足需求進行扣分的方式進行時效性滿意度打分。
扣分標準
命中以下規則時進行扣分：
- 時間失效，8年以上，例如：“怎麼知道別人開過我電腦沒，09年的消息。
- 信息失效，網頁內容已經過期，如果頁面是新聞或者招聘、下載等頁面時間敏感較強的頁面，時間上要嚴格一些，保證1-2年內。
- 時間過舊，根據query時間敏感度和結果的更新頻率進行綜合判斷，一般以超過5年結果進行時間是否過舊劃分。
- 時間內容和展示不一致。
- 結果非最新進展。
打分流程
- 進行query和結果敏感度衡量。
- 先判斷時間失效， 然後判斷信息失效，時間過舊，內外時間不一致，事件最新；每條扣1分。
- 死鏈單獨扣分。
- 單純小說query暫時不評，下載需求按照正常評。
注意
- 時間敏感的query根據其敏感程度判定，如“優惠卷使用超出使用日期”，“新問答電腦故障解決-回答是XP系統的方法”信息失效。
- 關於視頻資源播放和下載問題：有時間顯示，有簡介，無論能否播放依照時間打分；無時間顯示，對應簡介，無法播放算信息失效或者低質，還是按照時效性最新算，不扣分。
三 整體打法
在做泛時效性項目之前我們做了突發時效性，經歷了從規則優化->遷移模型->抽象特徵->模型迭代這四個階段。發現一個現象，在做一個項目的時候當我們把整個項目的優化方案定好，然後按照從底層特徵到上層模型，這樣穩步迭代推進的方案，雖然前期特徵設計和優化難有收益，但是後期效果提升反而非常顯著，而且速度很快，層次清晰很有條理，問題定位和優化都很容易。
因爲有了上面的經驗總結，我們覺得就先從基礎特徵優化開始，然後通過標註數據進行排序和召回模型優化。
四 基礎特徵優化
網頁時效性特徵
時間抽取
時間抽取是時效性排序的最爲基礎的特徵，在抽取時間的時候首先要對網頁時間進行定義，網頁時間主要分爲以下幾個類別：網頁內容時間、網頁更新時間、網頁發佈時間和網頁發現時間。
- 網頁內容時間：就是網頁中所描述的內容的時間，比如一個網頁描述的是1945年二戰快要結束的時候的事情，那麼這個網頁的內容時間就是1945年，如果介紹的是2018年北京奧運會開幕式，就是2018年8月8日，目前的網頁內容時間是從網頁內容的所有時間中挑選出一個最能代表內容的時間，是一個基於標註數據的Ranking模型來實現的。
- 網頁發佈時間：一般是指網頁的生成的時間，一般情況下是指網頁的Link創建的時間，對於一些內容頁，比如新聞，二手交易等，網頁發佈時間一般在網頁上會明確給出。
- 網頁更新時間：一般是指網頁主體內容發生最近一次變化的時間，對於一般的新聞和普通的文章頁，一般生成後不會再進行更新，所以最後一次更新時間一般情況下都是網頁的發佈時間。
- 網頁發現時間：一般是指網頁鏈接被搜索引擎爬蟲發現的時間，由於爬蟲Flowlink需要一定的時間窗口還有內容孤島等現象，網頁發現時間有可能嚴重滯後於網頁發佈時間。
- 網頁首次進入索引時間：因爲網頁被爬蟲發現後，網頁並不一定能夠及時的被抓取和解析到，可能首次進入索引的時間會嚴重滯後於網頁發現時間。
- 網頁時間：就是最能代表一個網頁價值的時間，一般情況下是從這5個時間進行選擇，目前我們使用的是一個規則的方法進行時間挑選。
規則的方法主要是：
- 對於新聞等內容頁面，如果網頁發佈時間可以通過模版和規則明確抽取出來，就選擇該時間作爲網頁時間。
- 當多個時間存在嚴重不一致的情況下會優先選擇置信度高的時間，比如網頁發現時間或者網頁首次進入索引時間。
時間敏感度(時效性半衰期)
網頁的時間敏感度，也就是網頁信息衰減的一個速率，我們用一個時效性半衰期來衡量網頁的時間衰減的速率，也就是假設從當前時間開始網頁信息衰減爲當前信息量一半所需要的時間。
半衰期作爲一個明確的時間其實很難定量標註，爲了簡單起見，我們將半衰期進行定性的離散化，通過標註數據來學習網頁的半衰期。
標註數據的GuideLine：
1）時間敏感度標註
在時間敏感度標註的時候，爲了讓標註的同學能夠儘可能的有內容的時效性感知，我們沒有定義很明確的詳細細則，只是有一些例子補充，核心還是希望能夠讓標註的同學去感知內容的時間敏感度，能夠去進行有效的思考，而不是去逼近學習標註細則，從而獲取到更爲優質的數據。
這種粗GuideLine的標註雖然帶來的數據質量上的提升，但是也存在一些問題：
- 標註同學的培訓成本很高，需要消耗大量的時間去培訓標註的成員，同時進行case解釋，這個陸續地持續了大概1個月的時間。
- 標註的擬合率較低，在項目初期5人的跨檔（也就是5個人中有3個以上的人標註的是比鄰的檔位）擬合率不到50%，即使到了項目的最後階段，5人的單檔擬合率（也就是5個人中3個以上的人標註的是相同的檔位）也在60%左右，跨檔擬合率在70%～80%之間波動。
2）時間敏感度的模型
目前我們的模型使用的是Pairwise和PointWise兩個模型。
- Pairwise模型輸出的連續值，分辨率更高，更適合上層排序的基礎特徵。
- PointWise模型輸出的主要是0，1，2及以上，主要是用來進行索引挑選以及上層排序的僞反饋標記特徵，通過統計召回結果時間敏感的網頁的分佈來反推Query的時間敏感度，這個後面會詳細介紹一下。
頁面信息失效
雖然定義了網頁的時間敏感度，對於一些時間敏感的網頁過了一段時間自然價值會變低，這種網頁定義信息失效比較困難，但是對於一些有明確時間邊界的頁面來說信息失效是可以明確定義的。
比如一些信息發佈頁面，類似二手交易、組織活動、房產信息等都具有明確的時間邊界，當交易發生，商品下架，或者活動時間過期等都是可以明確定義的，我們把這種信息稱爲信息失效頁面，這種頁面可以認爲時效性價值爲0，是需要做一些惡劣Case打壓的，這個在後續的排序模塊中也會介紹。
對於這種頁面的識別，目前是通過一些規則的方式，對於不同站點和類型的網頁進行識別的。
需求時效性特徵
需求的時間敏感度
Query的時間敏感度和網頁的時間敏感度是同樣的概念。
Query的時間敏感度: Query需要的網頁的時間敏感度，可以通過召回結果中網頁的時間敏感度來反推時效性的敏感度。
Query的時間敏感度的特徵因爲涉及到時效性結果的召回和時效性粗排，所以線上無法通過召回結果的分析來進行反推，需要直接通過Query端的分析就獲取到Query的時間敏感度。
Query時間敏感度的模型主要是經歷了3個版本的迭代，這裏面簡單介紹一下：
1）第一版：基於時間敏感詞的Attention機制的ABCNN的模型
通過一些時間敏感的Patten做Attention來確定Query是否可以和某些時間敏感的詞進行搭配，如果Query和這些時間敏感詞的搭配比較合理在搜索語料中也比較常見，那麼這個Query是時間敏感的Query的概率自然也會比較高，這些常用的搭配的詞主要是：最新，最近，今年，年份，今天等。
2）第二版：基於僞反饋的蒸餾技術
剛纔上面提到了其實我們已經有一個網頁端的時間敏感度的模型，因爲網頁本身的信息量大，網頁結構特徵多，更容易做的準確。當我們有一個比較準確的網頁時間敏感度的模型的時候，可以通過召回結果的分佈分析，生成大量的僞標註的樣本。通過這些僞標註的樣本可以訓練一個大樣本的CNN的模型，效果對比第一版提升也比較明顯。
3）第三版：基於主動學習的樣本標註的迭代技術
時效性的上層排序的時候需要一個TriggerModel，TriggerModel的作用是用來判斷Query是否需要時效性的調整，以及時效性調整的力度。
這個TriggerModel是基於人工標註數據的Model，這個Model使用的特徵更爲豐富，包括相關搜索的時間敏感詞（因爲用戶有的時候會修改Query，給Query加上時間限詞來進行結果篩選），網頁的時間敏感度的分佈，Query的時間敏感度的分佈，用戶的點擊行爲等特徵，同時通過ActiveLearing進行臨界樣本標註，增加模型的分辨率。
當我們獲取到了一個分辨率和準確率都比較高的Query的時間敏感度的TriggerModel，用這個Model來生成大量的高分辨率的樣本，同時結合強大的Bert語言模型，可以訓練得到一個比較好的時間敏感度的模型。
同時因爲TriggerModel使用了第二版的Query的時間敏感度的特徵，當Query敏感度效果提升的時候TriggerModel可以重訓提升效果，同時新的TriggerModel又可以指導Query的時間敏感度的模型的訓練，這樣迭代訓練同時提升。
時效性需求強度
時效性需求強度是和時間敏感度並列，主要判斷是用戶是否顯示的表達出對結果的時間維度上的需求（比如最新,2020年）。
這個模型相對來說較爲簡單，早期是一個基於規則的模型，來識別Query是否具有顯著的時效性Pattern。後期同樣是通過召回結果和用戶行爲（比如用戶的顯式的query修改的二次查詢，當用戶搜索”杭州限行規則“的時候，如果結果不好用戶會修改query爲“2020杭州限行規則”，“最新杭州限行規則”等）來生成僞標註樣本進行模型的訓練。方法類似於時效性敏感度模型的第二版。
五 數據標註
目前神馬搜索的上層的排序的模型核心是基於標註樣本的LTR Model，所以時效性優化的比較合理的方案是：通過標註樣本的方式，重訓LTR的模型來進行時效性的優化。
要訓練LTR Model需要標註時效性的學習的目標，在迭代的過程中主要經歷的2個階段，第一個階段是嘗試講時效性的目標融入到AC的5檔標註裏面（Prefect, Excelent, Good, Fair, Bad)，後續由於標註的難度的問題，採用二階段的單獨標註的方法。
時效性滿意度融入AC標註
目前神馬搜索的AC標註分爲5檔（Prefect, Good, Excelent, Fair, Bad= 4,3,2,1,0），爲了把時效性的目體現在AC中，我們增加了3檔，分別是2.5,1.5和0.5。
具體的打分的原則主要是：
- 對於時效性特別不好的結果，如果影響到了滿意度，那麼則直接降低1檔或者2檔。
- 對於時效性不是特別理想的結果，但是不影響滿意度，適當降低0.5檔，對於時效性特別好的結果適當提升0.5檔。
由於從原來的5檔提升到了8檔，而且AC的標註是7人擬合導致標註難度大大增加，同時神馬搜索AC的標註標準和標註人員都長期穩定，標註人員形成了一定的任務感知。讓標註人員重新學習新的的標註標註，導致標註人員的擬合率降低比較嚴重，低於60%，多次培訓之後仍然沒有顯著提升，所以後來放棄了把時效性的標註融合神馬搜索AC的標註體系中，啓用了新的單獨的標註原則。
單獨時效性滿意度
單獨時效性的標註原則是，對於神馬搜索已經標註過AC的樣本進行第二個輔助Label的標註。從神馬搜索已經標註的AC樣本中，挑時間敏感的Query，對於該Query的非0檔的Q-U的結果進行時效性滿意度的標註。
時效性滿意度標註的GuideLine：每個query會對應多個url，我們評測人員需要理解query含義——判斷頁面是否滿足用戶需求——判斷頁面時效性的滿足程度。
- 理解query含義，推斷用戶的需求。
- 從用戶需求出發，判斷結果的時效性能多大程度的滿足用戶。
- 根據後邊提到的標準，給出合理打分。
分檔標準2/1/0分檔均在結果相關的情況下判斷。
只要有時間屬性頁面，均以2、1、0打分，與敏感度的區別是，不拋棄變化頁面（按照主體內容的時效性判斷）。
- 2——頁面結果的時效性滿足很好，爲最新/價值高結果。
- 1——頁面結果的時效性的滿足一般，不爲最新/價值結果，但是有一定參考價值。
- 0——頁面結果的時效性滿足很差，爲很舊的結果，或者已經無參考價值。
- 不相關——頁面內容與query完全不相關。
- 死鏈/spam——頁面作弊/內容失效/空白頁。低質。
- 無時效性需求——query明顯無時效性需求（例， 論語全文）。
- 無法判斷——頁面內容不包含時效性因素，無法按照時效性滿足打分（例，百科、長視頻頁面、網站首頁）。
單獨時效性滿意度的標準和時間敏感度的標註一樣，我們沒有設定特別細的GuideLine，核心還是要讓標註的同學進行主要的思考，讓標註的同學去感知時效性的損失對用戶的滿意的影響。前期標註的擬合率也較低，低於60%，後期經過長時間的培訓和case講解，最終擬合的準確率大概在75%～85%之間。
六 排序模型
時效性排序的Model主要分爲四層。
時效性粗排
對於時間敏感的query，在索引召回的層儘可能的將一些時間比較新的結果召回上來。時效性粗排項目進行的比較早，當時還沒有標註數據，主要的方式使用的是特徵增強的方法，來提升新的結果排序靠前的概率。
神馬搜索排序Model加入時效性特徵
AC的部分標準裏面其實是考慮到了時效性的因素的。
- 第一類：比如一些新聞，因爲很多新聞事件，雖然人物、地點等沒有變化但是核心的事情已經變化了，這個就會影響基礎的滿意度，這種在AC標準中有體現。
- 第二類：另外的一種是信息失效，信息失效在AC標準裏面是有明確定義的，屬於無價值內容的，這個是可以直接作用於滿意度的。一般來說信息失效的概率和時間敏感度和網頁離現在的時間成正比，一定量的信息失效的目標可以學習到部分時效性的目標。
其他類型：還有很多其他的類型的比如用戶顯示的說明了年份的，比如“最新的閱兵式”，“51放假安排”等。
因爲時效性敏感的Query的標註的結果是和標註的時間有關係的，所以我們必須要記錄AC樣本標註的時間，這樣才能準確地計算時間特徵，同時在Dump特徵的時候必須把樣本的時間還原到標註時間。爲此我們對神馬搜索的特徵Dump的流程進行了改動，增加了時間還原功能，保證時效性特徵的準確性。
時效性獨立雙Label排序模型
因爲時效性的標註數據是有2個Label的，我們必須開發一套獨立的多Label的排序框架，爲此我們進行了一些的算法改動，升級了原來的LightGBM的工具支持多Lable的訓練。
主要的思想就是LambdaMart在計算交換Doc的PairwiseLoss的時候考慮到2個Label：
- 第一版的方法：當第一個Label的相同的時候，增加輔助Label的作用，計算輔助Label的Loss，後來在應用中發現這種方法存在一定的問題，就是這種情況下輔助Label只能在Label相同的樣本上起作用，Label不同的樣本無法產生Loss。
- 第二版的方法：爲了彌補第一種方法的不足，我們通過Label放大的方法，將原來的Label進行縮放，將AC的標準變成 8，6，4，2，0，然後將時效性的目標3，2，1，0，變成（1，0，-1，-2）。通過這種方式，將時效性的Label增加到AC的Label上，形成了新的Label目標，同時將LightGBM的交換Loss的2^Label 變成2*Label（這裏參考了神馬搜索的做法），這個主要是因爲放大了Lable之後，2^Label會使得頭部的Loss特別的大，導致和線上真實的交換損失不一致。
- 第三版的算法：後來我們在觀察樣本的時候發現，時效性的作用其實和樣本本身的Label有一定的關係，當樣本本身的Label是1的時候，其實用戶不太關心時效性，當Label本身是3的時候時效性起的作用又很小，基本上用戶也不太關心。時效性主要起作用的是標註樣本的2檔這部分，我們通過降低3檔和1檔的時效性作用，增加2檔的時效性作用，來提升時效性特徵目標的區分度。
時效性獨立Model對神馬搜索的Model進行動態矯正
時效性單獨的模型計算出的排序的分數是無法直接對結果進行時效性排序的，因爲要考慮到時間敏感度和時效性需求強度比如：
- 當時間敏感度較低的時候時效性起的作用要弱。
- 當整體相關性水平都不高的時候，其實排序的核心還是相關性。
- 時效性標註的樣本量要遠小於神馬搜索的AC樣本，學習能力要弱於神馬搜索的AC Model。
通過結合這3個方面的考慮，我們設計了一套動態平滑的方法，將時效性模型的分數平滑到神馬搜索的排序分數中：
RankScore = RankScoreAC*Lamda + RackScoreTimeliness*(1-Lambda)核心是Lambda的計算，Lambda的計算我們進行了3個維度的探索和嘗試：
- 早期的第一版：TriggerModel結合人工規則的方式，TriggerModel會計算時間敏感度強弱的特徵（TriggerModel在上面Query信號的地方簡單介紹了一下），然後根據TriggerModel反饋到時間敏感度的分檔信號上，然後人工指定Lambda的值。
- 中期的第二版：在第一種方法的基礎上，將TriggerModel的閾值和Lamba權重之間的關係，進行平滑，設計了一個簡單的調和平均的方法，將Trigger的預測值和Lamda的值進行了關聯，使得調整的維度更爲平滑。
- 正在嘗試的版本：這個是目前排序裏面正在嘗試的多目標融合的算法，通過純Pair的標註樣本，將多個多目標模型（每個多目標模型都學習了AC的目標和一個單獨的子維度）進行模型融合，通過一些全局的統計特徵等來學習不同的多目標模型的權重。
基於IRGAN的泛時效性排序的探索
由於時效性標註樣本的成本比較高，當時業界有一些通過IRGAN的方法進行模型迭代的，同時同組的突發時效性的團隊通過IRGAN的方法在突發時效性的場景下拿到了收益。我們也希望能夠通過IRGAN的方式來獲得時效性的收益，這個進行了一些探索和嘗試。
紅色是已標註的相關文檔，深藍是召回的文檔中未標註的相關文檔，淺藍是召回的文檔中未標註的不相關的文檔。G的訓練就是先給未標註的文檔打分，把得分較高的文檔送給D進行判斷，D對一個pair 進行判斷，判斷其是G挑選的（認爲爲假）還是真實已標註的（認爲爲真），並將其打分返回給G進行修正，如此G最終便能挑選出那些與真實已標註的樣本比較接近的文檔。
G和D現在的網絡結構和預訓練過程都是一樣的，在進行對抗之前是幾乎一模一樣的模型（除了預訓練之前的隨機初始化值不同） 。但對抗訓練G的時候，D認爲 已標註的doc 一直是比G挑出來的Doc要好的，即使G 已經挑到實際上比較好的文檔（ G預訓練之後和D能力一樣，一開始挑的可能已經是非常好的了）這時G反而會越學越差。因此可以考慮D和G採樣不一樣的網絡結構，D要做的只是pair的正逆序判斷，可以簡單點，G要混淆D，可以採用更復雜的網絡。
七 召回
時效性排序的召回體系主要是從通用召回的Query端處理，以及時間限定查詢和獨立時效性索引召回這3個維度進行的。
Query端的處理
我們發現時效性Query下，用戶經常會搜類似這樣的Query：今年，3月份，最新，最近。類似這種Term在原來神馬搜索的召回體系中的Weight一般都比較大，純字面召回很多時候是隻考慮了Term的匹配，而忽略的Term和網頁時間上的不一致。由於沒有考慮到時間上的限制，經常會召回一些Term匹配特別好，但是時間上卻特別老的結果。爲了處理這種Case我們對神馬搜索的Query分析的模塊進行了單獨的處理，增加了TimelinessTermWeightReadjust和TimelinessQueryRewrite的功能，主要是從TermWeight和Query改寫的角度進行召回鏈路上的優化。
TimelinessTermWeightReadjust
目前神馬搜索的核心引擎倒排索引，query分析後會指定AND詞，就是倒排索引拉鍊歸併的時候使用的必須要要包含的命中詞。對於時效性場景下，我們其實不太希望今年，最近，最新等這種詞命中，因爲這次詞的命都是相對時間，相對於網頁發佈的時候可能是最新的結果，但是隨着時間推移，如果網頁內容不變的話，這些信息的價值會大打折扣。
索引查詢的AND邏輯的核心特徵是TermWeight，只要Term的Weighting降低，那麼這個詞大概率就會被Rank掉，不參與拉鍊的歸併。爲此我們挖掘了一批時效性限定詞語，在時效性場景下將這些詞的Weight調低，提升召回的效果。
TimelinessQueryRewrite
對於今年，3月份，用戶隱含的意思就是2020年，2020年3月份。通過Query改寫，增加一路指定絕對時間的獨立查詢邏輯，通過限制時效性的時間強制匹配來保證召回結果的時間維度的滿足。
時間限定查詢
時間限定查詢這個理解起來比較簡單，就是通過query的時間敏感度的半衰期來對召回結果進行時間上的限制，上面的Query的時間敏感度的特徵的說明的時候也提到了，時間敏感度的特徵主要是作用在這個階段。
當我們發現這個query是時間敏感的時候，會單獨的發起一次查詢，該查詢會通過Filter語法的方式來限定召回結果的時間，這個時間就是上面提到的網頁時間。
如果時間敏感度是3，也就是半衰期是1周，那麼我們在查詢引擎的是需要通過Filter語法制定只召回最近一週的結果，同理其他的敏感度的召回按照對應的半衰期來進行查詢的時間限定，保證召回結果的時效性足夠的好。
時效性索引召回
時效性索引召回，這個主要是爲了解決一些業務邏輯的痛點，同時爲了做性能和效果的balance，我們把一些足夠新的內容放在一個單的索引中，查詢的時候單獨查詢時效性索引增加召回。
- 上面的時間限定查詢和TimelinessQueryRewrite都會單獨的發起一次查詢，這個查詢如果用通用庫的話，按照現在泛時效性Query的觸發的標準，那麼索引的查詢量將增加50%，這對索引來說是極具的性能消耗，但是帶來的提升卻並不一定有這麼的大。
- 獨立索引之後，時效性的數據挑選和生效邏輯可以更加的靈活，擺脫神馬搜索索引的各種限制。
- 新聞和強泛時效性下，需要天級別，小時級別，甚至是分鐘級別的數據收錄，在神馬搜索場景下是無法實現的，需要單獨的時效性業務索引來承載這塊。
八 收錄
時效性的收錄體系，收錄其實是排序的最基礎的核心部分，如果鏈接沒有收錄再好的排序的算法也沒有用武之地，目前搜索的收錄體系主要分爲突發和強泛時效性時效性的定向收錄體系和神馬搜索的通用的分層收錄體系。
定向收錄體系
基於種子頁面的新聞場景收錄
強時效性特別是新聞場景下，收錄往往是通過新聞的種子列表頁進行定向Flowlink進行連接發現的，舉個簡單的例子，新浪首頁，新浪NBA首頁，新浪財經首頁，知乎熱門話題頁面，微博熱門話題頁面等。
通過定期的檢查這種種子頁面上是否有新的鏈接來發現新的內容，這種種子頁面一般情況下只Flowlink一層。這個裏面其實涉及到的內容很多，涉及到種子頁面的發現標註，種子頁面抓取的調度算法，種子頁面的定期淘汰機制等，這裏面就不在展開了。
基於時效性需求的定向收錄
目前互聯網的發現的的現狀和未來的趨勢還是封閉，各個網站和APP內的數據很難在網上Flowlink到，同時由於自媒體時代的到來，人人都是可能的種子頁面，原來的通過種子調度的算法不可能這麼龐大的內容進行調度，即使能調度的起來時效性和收益也很難保證。
這種情況下一般都是通過需求定向收錄來做的，簡單來講就是各個網站和App都有自己的搜索接口，我們通過構造時效性需求的查詢請求來抓取這些網站和App的數據來做需求的定向收錄。
通用收錄體系
基於時間敏感度的索引分層收錄
上面收錄的地方介紹過，其實時效性的索引分層是解決時效性業務需求和性能平衡點的最佳解決方案。
原文鏈接：https://developer.aliyun.com/article/766467?
版權聲明：本文中所有內容均屬於阿里雲開發者社區所有，任何媒體、網站或個人未經阿里雲開發者社區協議授權不得轉載、鏈接、轉貼或以其他方式複製發佈/發表。申請授權請郵件[email protected]，已獲得阿里雲開發者社區協議授權的媒體、網站，在轉載使用時必須註明"稿件來源：阿里雲開發者社區，原文作者姓名"，違者本社區將依法追究責任。 如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：[email protected] 進行舉報，並提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。