--------點選螢幕右側或者螢幕底部“+訂閱”，關注我，随時分享機器智能最新行業動态及技術幹貨----------
一 問題定義
如何了解時效性呢？古語雲：“四方上下曰宇，往古來今曰宙”。時間貫穿了一切，時間感覺的唯一标準是變化。個人了解相對變化越難時間越慢，接近光速的時候時間變慢就是因為要改變它很困難。
從内容側了解時效性
在資訊場景下定義時效性的标準也同樣是變化。資訊的價值會随時間的延續而變化，一般通常情況下資訊的價值是會衰減，會失效的。這個和實體裡面的放射性很像，借用實體裡面的觀點我們對資訊定義一個時效性半衰期的概念：資訊相對價值衰減一半所需要的時間。對于一篇文章定義一個時間，假設文章剛發表的時候資訊量是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個方面的考慮，我們設計了一套動态平滑的方法，将時效性模型的分數平滑到神馬搜尋的排序分數中：
核心是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://mp.weixin.qq.com/s/WpITPvYmixMHa0ha0MgWVA