規劃搜索產品時,我們該如何著手?

4 評論 15378 瀏覽 85 收藏 19 分鐘

編輯導語:我們在進行網上沖浪時,可以直接利用搜索功能查找想要知道的訊息,十分快捷方便;為了方便我們的更快的找到,搜索后會根據系統內部的邏輯進行查找。本文作者從是什么、有什么和如何做三個方面詳細介紹了搜索功能的原理產品架構,供大家一同參考和學習。

搜索,曾經作為PC互聯網時代的流量霸主,有著舉足輕重的地位。即使在如今APP孤島林立的移動互聯時代,站內搜索仍然是提升產品觸達與流量轉化的重要部件,譬如業界有流傳電商App 40%以上的GMV通過搜索貢獻。

那么,當我們要規劃一款搜索產品時,我們主要關注哪些內容,這篇文章希望和你一齊探討。

01 搜索的本質

讓我們先來看看搜索的原理是什么。簡單說,就是用戶的輸入(Query)與系統數據庫中的內容(Content)完成匹配(Match)的過程。

這個過程的實現可以歸納為三步:第一是對用戶query的解讀,即query分析;第二是對系統中存儲的數據內容的理解,即應該與哪些內容進行匹配并召回數據;最后是對召回的結果排序,預測用戶最想要的是什么并予以呈現。

搜索系統流程圖

1.1 Query分析

用戶搜索時輸入的內容往往是一串長句或是一個問題,這樣的自然語言,機器是沒法直接識別的,這個時候就需要對query進行拆解。

首先是分詞,也就是把長句分解成短語或詞組,比如“雙十一全民購物節”會被分解為“雙十一/全民/購物節”,被分解后的詞就可以在系統詞庫中找到。系統詞庫一般可以通過常用詞庫、搜索行為日志、企業產品名稱、商品品牌、類目等構建,定期更新維護。技術上已有一些開源詞庫可以應用,比如jieba、ik等詞庫插件。

但是用戶的query有時候并不總是能精確分詞,譬如輸入了拼音或者錯別字,系統就要把query進行糾錯改寫?;蚴菫榱烁鼫蚀_的命中用戶意圖,就要進行同義詞、語義擴展。一般通過構建query與糾錯詞、同義詞的映射詞庫來實現,數據大多來源于用戶搜索日志及人工維護等。近些年得益于深度學習的發展,如BERT等NLP模型被引入語義擴展應用中,效果得到進一步改善。

另外,query分詞后的信息并不都是重要的,某些時候query中的一個關鍵詞其實才是用戶想要表達的真實意圖,把這個詞提取出來就可以幫助后續的召回排序階段能更快更準的匹配內容,這就是識別及提取關鍵詞的作用了。

以上無論分詞、關鍵詞識別或是語義擴展,目的都是對用戶query的解讀,理解用戶真實意圖,為接下來搜索引擎該從系統中召回哪些數據框定出大致的范圍。

1.2 召回

召回,也就是把用戶query相關的內容從數據庫中篩選出來,在這之前系統有一系列的任務需要處理。首要任務當然是建立搜索系統的數據庫,一般這個過程就是搜索引擎的索引構建

對于一項搜索業務,比如電商類的搜索,引擎會把商品標題、商品簡介、廣告詞、品牌、類目等文本類的字段納入到索引中,并與詞庫詞典建立一種映射關系,這樣query分詞后就能快速進行匹配,把命中的內容全部從數據庫中召回出來。當然,除了標題、簡介等文本類信息,諸如商品的銷量、評論、點擊量等數值類的字段也會被搜索引擎構建到索引中,在接下來的排序階段發揮作用。

1.3 排序

經過搜索召回的數據往往是大量的,那么哪些內容會被優先展示呢?搜索引擎會結合各個因子的價值賦予一定的權重,進行綜合后給每條數據評定優先級分數。影響搜索排序的因子大體可以分為兩類:

  1. 文本相關,主要考慮搜索詞與內容的相關程度,這一塊已有很多成熟的方案,諸如經典的TF-IDF、BM25算法等;
  2. 業務相關,如電商類的價格、銷量、時效性,資訊類的閱讀量、分享量等。排序算法及各因子的權重并不是一成不變的,會隨著數據的積累、badcase分析而迭代優化,最終效果也是考驗對業務的理解。

另外除了相關性排序,大多搜索系統都加入了個性化排序的能力,一般通過搜索日志挖掘、用戶標簽等與數據內容聯合建立點擊率模型,預測用戶偏好的搜索結果。

經過query分析-召回-排序等一系列步驟后,數據內容就按相關性依序呈現到了用戶面前,以上就是搜索實現的基本原理。

02?用戶搜索的故事線

上述解決了搜索是什么的問題,接下來我們看看一款搜索產品一般會具備哪些功能。搜索出現的緣由是信息過載,特別是越來越多長尾內容無法有效觸達,用戶需要通過搜索在紛繁的數據中快速找到所需,因此搜索的功能便是基于降低用戶使用成本來規劃的。從用戶視角來看,一次搜索流程的故事線如下圖所示。

用戶搜索故事線

2.1 搜索前

2.1.1 搜索輸入形態

在進入搜索前,一般有幾種交互方式來向系統輸入查找內容。主流的就是文本框搜索了,隨著語音識別技術的發展一些企業已開始逐步引入語音搜索(本質上仍是通過語音轉文字后進行的文本搜索),另外諸多電商產品還有圖片搜索的功能。對這三種輸入形態可以結合團隊實力和業務需要來規劃搜索入口設計。

2.1.2 底紋默認框詞

搜索入口設計成輸入框的形式時,一般都會有底紋默認詞。對用戶這是作為搜索推薦降低選擇的入口,對企業則是營銷推廣、流量分發的廣告位。因此在實現上,通常會結合用戶的行為數據(比如歷史搜索、搜索點擊,甚至于商品購買、瀏覽點贊等搜索外數據)、熱門搜索、人工干預做綜合推薦。

底紋默認詞

2.2 搜索中

從用戶選擇搜索框到輸入搜索詞的過程,也有一些簡化用戶使用的操作。

2.2.1 歷史搜索&熱門搜索

歷史搜索是用戶曾經在搜索頁面查詢過的關鍵詞,一般會按時間由近及遠保留近10條記錄并呈現。

熱門搜索是搜索業務中一大流量分發的廣告位,具有一定的榜單效用從而降低用戶決策提升點擊率,通常由運營人員結合熱點產品在后臺設置推廣詞。進階的做法,會結合用戶之前的行為數據加入個性化推薦的算法,達到一定的千人千面效果。

2.2.2 搜索推薦

用戶在使用搜索時也會有意圖不明確的時候,或者搜索之后無法匹配到系統內容導致沒有結果,這時就可以進行搜索推薦。在搜索動線中植入推薦的場景可以很多,比如無結果推薦與相關性推薦。

1)無結果推薦,就是在用戶搜索后但是沒有搜索內容返回,往往是業務數據偏少或者用戶的query詞條較冷門造成。

無搜索結果是很傷用戶體驗的情境,次數如果出現多的話用戶下次就不會再用搜索功能了。這個時候就可以結合用戶的query進行相似搜索詞的推薦,或者結合用戶與內容的屬性進行產品的推薦。

大眾點評·無少結果推薦

2)相關性推薦,常出現在搜索結果信息流中,以用戶的query詞為基準,推薦更多與他的意圖相關的詞。

需求實現上一般也可以從兩個維度來考慮,即搜索詞的維度與點擊行為的維度。搜索詞維度可以結合用戶的搜索session來分析,什么是用戶搜索session呢?定義的方式有很多種,可以認為從用戶第一次輸入query到產生實際點擊行為為一次搜索session。

當用戶搜索一個詞發現沒有找到,會接著換個詞繼續搜索,最終找到想要的內容。那么就可以把多個用戶相同的query及后續相關搜索詞記錄下來,進行協同過濾推薦了。

點擊行為維度,是把用戶的點擊行為考慮進來,當一條產生了點擊的搜索結果出現在多個query搜索詞的結果列表中,例如搜索‘史記’和‘資治通鑒’的用戶最終都在結果列表中點擊了‘上下五千年叢書’,那么下次就可以把搜‘史記’的關鍵詞推薦給搜‘資治通鑒’的用戶了。

2.2.3 下拉聯想詞

下拉聯想

聯想建議是依據用戶鍵入的文本,系統自動擴充完善,以達到簡化用戶輸入、快速跳轉查詢結果的目的。為了系統建議的內容更準確,一般會對query進行糾錯提示、前綴匹配等。

糾錯提示需要支持漢字拼音混合輸入、拼音大小寫輸入等,比如用戶輸入“華為Rongyao手機”,能將拼音提示為正確的漢字“華為榮耀手機”供用戶點選;另外對于用戶輸入的錯別字系統需要改寫成正確的表達,比如“賣當勞”改寫為“麥當勞”,實現上主要以中文拼音為基礎檢索同音字,結合字詞的編輯距離進行糾錯判斷。

前綴匹配能在用戶開始輸入若干字后快速聯想出相關內容,比如輸入“女裝”,系統聯想“女裝套裝”、“女裝上衣”、“女裝連衣裙”等,把用戶可能的后繼搜索詞都關聯呈現出來。

2.3 搜索后

用戶輸入query點擊搜索后,系統會給用戶呈現一系列相關的搜索結果,那么如何幫助用戶更快更好的從結果中找到自己的真實意圖呢,需要在技術算法與產品功能上協同發力。

2.3.1 搜索結果列表

還記得上文提到的排序嗎,搜索結果列表就是其發揮作用的主陣地。模型算法上經歷了從文本相關性到個性化算法再到不斷推陳出新的各種神經網絡,算法能力升級也使搜索結果首屏內容命中用戶query意圖的概率大大增加。

而在產品交互層面,需要結合企業業務與數據內容的特性,分析用戶關注的核心信息以及哪種內容更易促動用戶點擊,以此對搜索結果信息流的圖文呈現、字段展示、業務域模塊劃分進行綜合考量布局。

另外,如果企業/App是具有平臺性質(比如微博、抖音、電商類App)可以為第三方提供廣告接入的服務,在搜索結果信息流中植入廣告feed也是一個重要且復雜的課題,需要考慮廣告與搜索域的原生信息、用戶搜索意圖以及商業目標等的匹配平衡。

2.3.2 搜索直達/結果置頂

搜索直達是指用戶的query命中了特定的關鍵詞,系統會跳過搜索結果列表,直接轉到具體落地頁。比如搜索‘天貓雙11主會場’,直接跳轉至活動頁。搜索直達為運營提供了一種工具,配合營銷大促、節日慶典等重要活動進行宣傳與引流落地。

結果置頂則是為一些爆款商品或者是主流業務產品配置相關關鍵詞,或者通過數據挖掘發現某些query下的高頻點擊結果,當用戶的query匹配時,把相關結果在搜索列表中置頂,提供產品快捷入口。比如微信搜一搜中搜索華為會置頂顯示華為商城,并且還會附帶露出更多效果與組件入口,方便用戶直達服務。

2.3.3 篩選排序

除了系統按文本、權重、語義做的綜合搜索排序,不同品類的業務可以依據業務屬性定制排序及篩選的方式,比如商品的按銷量/價格排序、商戶的距離/好評排序等;篩選是為用戶提供的一套組合過濾器,比如手機品類支持按型號、品牌、類目等篩選,某些時候業務多元且復雜,甚至可以提供接口交由上游業務實現篩選定制化管理與維護。

以上結合用戶搜索的故事線大致梳理了主流搜索業務包含的產品能力,基于自身業務特性完善功能,可以幫助用戶搜索更便利。

03?搜索產品架構

搜索產品歷經迭代,從入口級工具到中臺化引擎,很多時候搜索業務也伴隨著企業的發展而承載更多的能力。最后,我們以中臺化的搜索平臺為定位,淺析搜索產品的架構規劃,主要可以從三個維度考慮:數據層、平臺層、應用層。

1. 數據層

是構建平臺的基礎,中臺炮火強不強,數據‘彈藥庫’得先準備好。也可以拆解為三個方面著手:

一是詞庫的建設,比如基礎詞庫、同義詞庫、糾錯詞庫、聯想詞庫等,拆分多個詞庫的好處是能針對特定搜索功能進行專項優化。詞庫初始化好了以后,還要考慮是否有人工干預維護的機制、系統發現新詞的能力,另外對于某些特定行業諸如金融、醫藥等,還會進行相關專業詞匯的構建。

二是用戶相關數據,包括用戶基本屬性標簽、行為數據、交易數據等,大多時候這些數據都散落在各個業務系統,而這些數據對優化算法模型起到重要作用,那么如何去其他系統取數、需要哪些字段,就需要商定一個機制。

三是垂類數據建設,企業如果具備多元的業務,就可以對不同垂直業務分別取數、建索引存儲,搜索引擎可以設計通用的數據上報接口,為需要接入平臺的業務提供全量/增量數據同步的服務。

2. 平臺層

搭建PaaS化的微服務能力,把query理解、數據召回、內容排序等模塊抽象成API式的接口,以滿足不同業務定制化的需求。

3. 應用層

是最終搜索業務與用戶交互的窗口,秉持‘降低用戶搜索的費力度’與‘提升業務轉化率’的目的,對用戶搜索故事線前、中、后的體驗不斷迭代優化與能力豐富。

以上就是本文基本梳理的搜索業務構建的骨架,市面上的搜索產品大致是上述功能與流程的組合。暫時先總結到這么多吧,搜索的更多細節有機會再進一步分析。

 

作者:策略伽;公眾號:策略伽

本文由 @策略伽 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 非常詳細 很感謝你的分享

    來自上海 回復
  2. 文章質量很高,感謝發表!

    來自中國 回復
  3. 學習了,感謝

    來自上海 回復
  4. 寫的很不錯!

    來自北京 回復