來源:北京SEO 時間:2019-04-09
  講起來頭頭是道的文章!全文如下:
 
  一、什么是需求滿足
 
  1.1什么是需求滿足
 
  用戶來搜索“章魚保羅”,就文本相關性而言,搜索引擎只要返回和“章魚保羅”內容相關的結果就可以了,這樣用戶是否滿意呢?
 
  用戶甲:聽說章魚帝掛了,來看看最新結果,怎么全是8月份的,往后翻頁中…
 
  用戶乙:今天同事們在討論章魚哥掛了,章魚哥是啥?我又out了,來搜索一下章魚帝生平事跡是啥,怎么全是最新的結果,沒有章魚哥的介紹啊,變換個query看看
 
  用戶丙:我是鐵桿球迷,看完章魚哥,再看看足球相關的吧,魯尼,杰拉德是否又進球了,怎么連個相關推薦都沒有,還得我親自輸入。
 
  用戶丁:找個章魚哥的頭像用一下吧,一定很拉風,怎么全是結果沒有方圖呢,這么扁的圖怎么用啊
 
  用戶戊:換個章魚哥的壁紙,也許下次買彩票能發大財,咦,怎么全是小尺寸的圖…
 
  (以上信息通過分析2010-10-27用戶session得出。)
 
  籠統的說,用戶向搜索引擎表達他的需求,搜索引擎理解用戶需求,提供各不同的需求下的資源,這整個過程可統稱為需求滿足。簡單說,就是除了基礎文字相關性之外的rank工作,都屬于需求滿足的范疇,也就是說,提供給用戶的檢索結果,不僅僅要求在字面上是和用戶輸入的文字相關的,還要滿足用戶的各種不同需求。
 
  需求滿足在rank體系中所處的位置:
 
  1.2為什么需要需求滿足
 
  用戶通過query表達了自己的需求,而對于大部分query來說,尤其是具有隱含需求的query,僅僅字面匹配的查詢結果未必能夠滿足其需求。目前我們的排序系統是主要是基于文本相關性這個維度的,權值體現了query中的term與obj的相關程度,在這個體系下,相關的結果未必能夠滿足用戶需求。
 
  例如前面提到的“章魚保羅”的例子,顯然,這些需求在文本相關性這個維度下很難解決,尤其涉及到突發時效性需求,泛需求等。
 
  1.3需求滿足包含哪些工作
 
  從上面的例子中,可以看出,需求滿足需要解決時效性需求問題,多需求問題,相關推薦,size需求,素材類需求,瀏覽引導等問題。除了基礎文本相關性以外的rank策略以及為了這些所做的query分析工作可認為屬于需求滿足的工作,另外還包括前端結果展現與用戶引導瀏覽的工作。
 
  Image需求滿足,按照不同的維度,可以劃分為如下幾個方面:
 
  1、需求識別
 
  2、資源建設
 
  3、需求調權
 
  4、結果組織與推薦
 
  5、用戶引導交互
 
  二、需求滿足如何做
 
  需求滿足要解決的核心問題:
 
  需求識別
 
  資源建設
 
  需求調權
 
  2.1需求的識別
 
  2.1.1需求的類型
 
  識別query有哪些需求,以及需求的強弱,是最基礎的工作。首先要有需求的體系,能完備的描述各種需求,其次是如何識別這些需求,把每個query的需求對應到這個體系中去。
 
  通過query分類識別需求:
 
  現在線上query分類體系,是按照話題屬性為依據來建立的。包括風景類,地名類,人物類,汽車類等等,對于每個類別,在一些維度上的需求是不一樣的,比如風景類需要尺寸比較大,比較清晰,不包含人的圖片,而聊天類則需要尺寸較小,最好是動態的gif圖。
 
  這個策略下的項目有:size調權,格式調權,人臉需求,人與非人等。
 
  基于統計的需求識別
 
  通過對大量的數據統計分析,可以識別出query有哪些方面的共性。可供分析的數據很多,比如用戶行為數據,點擊反饋,檢索結果等。
 
  比如:對query的檢索結果,按照某一feature進行聚類,如果某個類別所包含的圖片數很多,超過設定閾值時,則認為這個類別內的圖片,在這個feature上,代表了這個query的需求。線上人臉需求識別就是這樣來做的。
 
  統計用戶反饋來獲取需求是最能反映用戶需求的方式,用戶的反饋包括用戶點擊,query變換等,在這方面我們做的工作不多,經驗也不多,是我們后續工作的重點。
 
  專名&需求詞
 
  判斷query中包含專名或者需求詞等關鍵詞,是最直接的方式。比如“紅色寶馬”,顯示的表達了顏色方面的需求。
 
  時效性需求
 
  時效性需求包括三部分,突發時效性、周期時效性和泛時效性需求,目前線上做的是突發時效性需求。需求的識別,主要是通過檢索量的突發,資源數突發和實效性事件來判斷的。
 
  檢索量的突發,是指累積每個小時的用戶檢索頻率,用連續15天的用戶檢索頻率,計算突發的斜率,根據斜率的大小,來判斷時效性需求的強弱。
 
  上述方法只適合熱門query,對于長尾query,檢索頻率很低,無法通過這種方式識別出來,一般這種query是多term的query,可以通過是否命中關鍵詞來判斷:
 
  通過事件判斷:這種方式,主要是想看關鍵term命中時效性事件的比例。當然這些事件是通過主動挖掘的時效性query,通過聚類后,對每個類別訓練出來的關鍵詞。
 
  2.1.2需求的強弱
 
  要做好需求滿足,不僅要識別query有哪一類型的需求,而且要識別該類型需求的強弱,他直接指導了后續需求調權的力度。
 
  每個維度的需求,必須要有需求的強度,在各維度調權合并時,需求的強度決定了該維度的權值。比如時效性需求,需求的強度很高,要求滿足時效性的資源,一定要排在前面。又比如清晰度飽和度調權,對大部分query而言,需求不是很強烈,調權時的力度就不能太大。
 
  需求強弱的計算,和后面rankmodel的要求相關,理想的狀態是每個query,可以動態的計算在每個維度上的需求強弱,我們在這方面經驗不多,如果暫時不能做到準確的計算的話,暫時可以考慮人工指定的方式,比如針對不同的query分類,人工設定需求維度的強度。目前可以想到的一些方式:
 
  顯式的需求為強需求
 
  用戶通過在query中包含需求詞的方式,表達自己的需求,這樣的為強需求。
 
  比如,最新劉德華圖片,紅色寶馬
 
  基于統計的方式挖掘需求時,判定值超出閾值的比例大小,決定需求的強弱
 
  在用統計挖掘用戶需求的方法時,一般會選取某個維度的屬性,量化后計算它的統計特性,可以根據統計后該數值的分布情況,判斷需求的強弱。比如,時效性需求,某段時間內,該query檢索量突發特別大,是昨天檢索量的100倍,如果我們設定的閾值是2倍的話,那么這個query就可認為時效性需求特別強。
 
  又比如通過用戶點擊數據挖掘size需求,對于頭像類的query,大部分用戶點擊的是100*100的方圖,但是所占總點擊中的比例不是很高,比如只到60%,那么對這個query而言,size需求是一般強度的需求。
 
  2.2需求的滿足
 
  識別出query有哪些需求,下一步的工作就是提供相應的資源。
 
  2.2.1資源的挖掘
 
  如何獲得滿足需求的資源,是需求滿足的另一個核心問題。在資源上,通過某一個或者幾個特征組合,能夠把滿足要求的資源和不滿足要求的資源區分開,找到用戶需求需要的資源,去掉不滿足要求的資源,是主要的工作。
 
  內容屬性特征
 
  對內容屬性維度來說,可以分為底層的物理特征,中層的物體識別和高層的語義特征;對于底層的物理特征,相對比較簡單,我們現在可以利用的,包括尺寸,顏色,格式,清晰度飽和度等,中層特征,我們目前用到的不多,有人與非人的,色情圖片的,整車的識別,手機圖片的識別等;對于高層的語義特征,包括場景的識別,圖片風格的識別,是我們未來發展的方向。
 
  話題屬性維度
 
  類似的query分類的體系,也可以對資源進行相似的話題屬性分類,我們目前只做了站點級別的分類,效果不是很理想,主要原因一是站點粒度太粗了,二是站點分類的召回存在很大的問題。
 
  我們希望能做到obj級別粒度的分類,至少是頁面級別的分類。如果有了話題屬性的分類,和query需求的分類相配合,可以達到事半功倍的效果。
 
  時效性資源的收錄
 
  我們目前時效性資源主要是挖掘的ps的時效性庫,和news的資源,和非時效性資源的區分是比較容易的。
 
  2.2.2需求調權
 
  明確了query的需求,挖掘了滿足需求的資源,那么如何把滿足需求的資源rank到前端呢?
 
  對于各種不同的需求維度,都有自己的調權的策略。比如格式調權,假設query有gif圖需求,對于gif的動態圖,權值乘了1.2,對于靜態圖要降權,權值乘了0.1。又比如時效性需求,直接在前三頁插入的時效性庫的結果,這是因為時效性需求是一個強需求維度,簡單的加權,不能保證結果調整到前三頁。從這些例子中可以看出,目前需求調權的策略就是2種類型:在總權值上調權,在最后排序結果上調序。
 
  目前這種策略直接疊加的調權方式,優點是簡單,直接,缺點也比較多,最大的是不可控,一個維度上的調權,會對最后結果造成多大的影響,在多個調權維度上,他說的話,分量有多大,不知道。
 
  未來的需求調權,首先應該把資源滿足需求的情況,做出細化的分檔,做到有直觀的物理含義,其次,根據該維度需求的強弱,把這個維度的打分反映到最終結果中去,究竟是跨檔調權還是檔內微調,比如:
 
  強需求:符合要求的結果直接調到最高檔,比如時效性需求
 
  一般需求:符合要求的結果,可以根據一定規則,提高自身檔位
 
  弱需求:不能提升檔位,在同一檔內,做權值調整
 
  2.3需求滿足的效果
 
  前面已經完成了query需求識別,資源識別已經需求調權的工作,那么用戶是否滿足了呢?搜索引擎最終是給用戶服務的,用戶覺得爽,才是最重要的目標。那么如何知道用戶是否滿意呢?
 
  用戶接收到搜索引擎的提供的信息后,會對這些信息做出反饋。這些反饋包括了用戶對搜索結果的點擊、對query的主動變換,以及這些行為之后的相關行為。通過對這些數據的分析,可以知道用戶的滿意度。
 
  比如對需求識別的修正,通過用戶點擊反饋,可以知道query需求識別的是否正確,該需求是否該退場。比如時效性需求,被誤判的query或者應該退場的query,都可以通過用戶的反饋,來判定是否應該退場。
 
  當然,這種方式是否合理還有待調研,畢竟用戶不點擊一張圖的原因有很多可能,有可能是需求識別的問題,有可能是該維度強弱識別的問題,也有可能是rank的問題。目前用戶反饋應用只有點擊調權,是否用戶的反饋可以在單獨的維度上有效,還需要詳細的調研分析。
 
  另外,隨著時間的推移,query的需求是在不斷變化的,通過用戶的反饋,可以做出及時的調整。
 
  三、需求滿足的展望
 
  3.1需求滿足體系框架的建立
 
  之前做了很多需求滿足的工作,顏色,格式,尺寸,人臉,表情,頭像等等,分別是casebycase來做的,其實他們之間存在著很多相似的地方。從調研過程來看,可以分為需求識別、資源滿足和需求調權三大部分。
 
  這樣分散的各個點去做,有很多弊端,一是調研重復,效率低;二是前端調權系統像打補丁一樣,越來越亂,沒有形成清晰的體系框架。三是容易造成調權重復。
 
  目前比較好的思路是建立需求滿足的體系框架,包括前端的需求分析和后端需求調權。前端分析清楚query包含哪些需求,以及每個需求的強弱,把這些信息傳遞給后端;后端首先要有各個需求所對應的資源,然后結合上面提到的需求調權,給每個obj一個合適的檔位和權值。
 
  以后再做需求滿足類項目時,只需要調整前端的需求識別即可,如果沒有新增的需求維度,后端的資源和需求調權,都可以不用改動。
 
  3.2更智能的需求識別
 
  1.分析用戶行為數據挖掘需求
 
  用戶在搜索過程中,能夠被我們記錄下來的一切行為,比如點擊,翻頁,query變換,停留時間,去向,來源等等,利用好這些數據,就能更好地理解用戶的意圖。目前在這方面的應用還只有點擊調權,需要挖掘方面的應用還很少,是我們未來工作的重點方向。
 
  2.個性化需求挖掘
 
  通過分析session,可以獲取個性化的用戶個體需求。目前我們結果的展示的好壞,主要是通過分析session,來判斷用戶的需求,而對于高頻query,展示的結果是大規模用戶的行為統計,得出的一個普適的模型,這個模型由于是統計出的,因此具有客觀性,可能會傷害一部分個性用戶。
 
  3.需求強度的識別
 
  每個維度的需求,必須要有需求的強烈度,在各維度調權合并時,需求的強度決定了該維度的權值,比如時效性需求,需求的強度很高,要求滿足時效性的資源,一定要排在前面。又比如清晰度飽和度調權,對大部分query而言,需求不是很強烈,調權時的力度就不能太大。
 
  3.3資源建設
 
  目前我們在query分類,query需求識別,query分析方面做了大量的工作,相比較而言,資源方面的建設,我們做的工作比較少,接下來希望推動obj級別的資源分類,內容屬性上的幾個資源分類:圖標資源識別,地圖資源識別,卡通動漫圖的識別,以及一些截圖的識別。
 
  3.4需求引導
 
  Image是瀏覽型為主的產品,如何引導用戶更加方便的瀏覽,是未來工作的重點之一。
 
  我們已經嘗試了明星結果頁的query分類展示,未來我們希望能對更多類別的query,做主動引導。引用pm對主題式query的定義:“主題式”Query是指:Query指代的人、事、物中包含有多方面內容,具體表現為Query對應目前的檢索結果中存在明顯的多方面內容的混雜情況。其實就是指泛需求、多需求的query。
 
  對于這種泛需求query的結果的展示樣式,這種分tab多結果頁的形式也未必是最優的,如何更好的發揮作用,需要更加深入的調研和創新的思路。
 
  另外,還包括對rs展示優化,動態摘要的顯示和套圖展現等方面的持續升級。
 
  四、結語
 
  Image需求滿足方向才剛剛起步,未來要向智能化,自動化,多樣化方向持續的發展。我們最終的目標是把需求滿足這個方向做沒了,需求挖掘,資源滿足全部自動化,做到“手中無劍心中有劍”。
 
  
羽毛球的规则