一、定義
在電商搜索中，query 推薦是指爲用戶推薦符合其意圖的 query，以方便用戶輸入或者吸引用戶點擊。
1.1 query 推薦的目標
- 引導用戶使用搜索，提升搜索的滲透率。提升搜索滲透率，其實是讓用戶有更多的渠道能夠進入到：“商品詳情頁”。各式各樣的詞功能其本質上是“引流”渠道。（搜索運營關注的3個重點：流量、轉化、客單價）
- 節省用戶的輸入成本，提升用戶搜索效率，預測用戶搜索興趣，幫用戶明確搜索意圖。
1.2 query 推薦的產品形態
底紋詞、熱門搜索詞、sug詞、歷史搜索詞、猜你想搜索……
1.3 query 推薦場景
1.4 query 生效方式
- 展示詞--->搜索詞，展示詞是用戶看到的詞，而當用戶點擊時，背後真正發起搜索的詞稱爲“搜索詞”。比如“小龍蝦 15塊錢一斤”是展示詞，用戶點擊後，發起搜索的詞是：“小龍蝦”。
- 展示詞--->活動H5鏈接，比如“官方補貼”是展示詞，當用戶點擊時，跳轉到一個真正的“官方補貼”活動H5頁面，可理解爲拼xx的百億補貼。在“首頁搜索框底紋詞、引導頁熱門搜索詞”模塊配置時，可起到活動引流的效果。
二、詞的召回
詞的召回規則本質上是解決 query 候選詞從哪裏來的問題，主要有以下幾個方面：
- 取用戶搜索的歷史 query， 再根據一定規則抽取而來，比如按UV_CXR、搜索QV、搜索UV等指標過濾，得到候選 query。或者爲每個 query 預測一個類目，將 query 組織成類目的形式。比如說引導頁的熱門搜索模塊，它的熱詞一般選取“高 search_uv、高轉化”，總之就是高質量的詞作爲候選詞召回。
- 根據商品標題的本質特徵抽取而來，通過本質詞挖掘算法，針對每個 spu 標題挖掘出相應的本質詞，以此本質詞作爲候選 query。這裏的本質詞其實是從商品的“上下位詞”抽取而來，商品的上下位詞是多 level 層級的(山東煙臺紅富士-->紅富士蘋果-->蘋果-->水果)，選其中某個 level 的詞作爲本質詞。
- 其他一些算法策略挖掘的 query
- 人工干預配置的 query
- 業務相關的熱門搜索詞，用於取不到其他來源的詞時，最終兜底
由於詞的數量龐大且一般存儲在業務Hive表中，因此需要數據處理生成候選召回詞。數據處理一般是Hive的離線任務，首先從不同的業務表來源抽取出詞集合，再根據各種規則生成候選召回詞，保存在Hive結果表中，最後通過後臺任務將Hive結果表候選詞處理成取詞訪問的KV形式，保存到緩存中，供線上服務取詞。
從產品形態上看，有些 query 推薦是基於全局的商品spu，有些是基於局部的商品spu。比如“官方補貼”頁面的 query 推薦詞，應當只與官方補貼的商品有關，如何只生成“局部的商品”的 query 推薦詞呢？目前的 query 候選集主要來源於spu本質詞，也即：通過本質詞挖掘算法爲每個 spu 關聯“一組”本質詞，再爲 query 關聯一些特徵，生成最終的 query 候選詞用於詞的召回、過濾、排序等。
三、詞的過濾
- 字面量相同過濾
- 長度過濾，方便頁面展示
- 運營配置強制干預過濾（類目id下不出某些詞）
- 違規敏感詞過濾、合規性過濾(未成年酒類)
- 供給過濾，詞query必須能夠召回商品，分成先驗過濾和後驗過濾。
- 先驗過濾：返回給用戶的 query 詞一定是有供給的，因此在 query 進入候選詞集時，就需要驗證此 query 是否有無搜索結果，將無結果的query過濾掉。
先驗過濾
先驗過濾，是以離線方式過濾掉沒有搜索結果的 query候選詞，對線上取詞流程無影響
候選詞不能太多，太多可能無法在更新週期內將候選詞的供給都驗證完成
如何驗證候選詞有供給？（也即有搜索結果？）是調用線上的搜索接口還是直接讀取索引數據？如果調用線上搜索接口，可能會影響到用戶搜索主流程。如果直接讀取索引數據，要能夠基於索引字段計算出和線上搜索召回一些的結果。如果讀取索引數據，也不能直接讀取ES的索引數據，而是讀取“索引基礎表數據”，又需要要求：上游變更的增量的實時消息接入了“索引基礎表”。
後驗過濾：
後驗過濾的特徵
線上每次取詞時都需要“供給過濾”判斷
對用戶而言，只有第一次點擊某個詞可能無結果（此 query 的結果會被更新到搜索緩存，並進入到黑名單中），後續該詞再被點擊時，就會被過濾掉
不需要定時任務判斷 query 是否有供給，依賴用戶的線上搜索 query 結果來過濾。（商品的售賣是動態的，如果某個商品售罄或者下線了，先驗過濾需要重新判斷 query 候選詞是否有供給）
同義詞過濾
四、詞的排序規則
運營強制位置干預，強制將某個詞插入到第N個位置上，這一般用於 query 詞的營銷場景，比如針對新用戶的活動時，配置“新人專享” query 詞，背後可以是承接的H5落地頁，跳轉到活動界面。
詞的類目相關性，比如商詳頁推薦詞，與商詳頁的商品相關，因此商品本質詞>類目query詞>搜索熱詞
4.1 詞的打散
- 隨機打散
- 根據類目id打散，同類目id query 詞不能連續出現
- 指定位置干預
五、詞的更新
5.1 時間維度
以天維度，每天更新一次。某些場景下可能需要實時更新
供給過濾，返回給用戶曝光的 query，一定是要有搜索結果的，就需要做到實時的 query 供給過濾。
5.2 query維度
在業務初期，通過一些簡單的 Hive 離線處理任務，能夠生產出候選詞，再將詞導入到 MySQL，再通過後臺處理任務組織成KV緩存，週期性更新就能滿足要求。示意圖如下：
- join 連接 query 所需的各類特徵。比如UV_CXR、搜索QV、搜索UV、query的預測類目（流量表、query 類目預測表）
- 當 query 的數量太大，或者需要考慮更多的 query 召回特徵時，可能就需要引入 Spark 等大數據處理工具計算
六、query 推薦相關的搜索指標
參考：https://www.cnblogs.com/hapjin/p/15926194.html
七、一些優化參考資料
7.1 query_base 系統
a) query的生產是煙囪式的，每個產品功能各自使用自己的query詞，以單獨的緩存 category 保存。隨着產品加框的需求越來越多，沒有統一的querybase來追溯各個產品下的query。
b) query目前只存儲在緩存中：無可視化界面，驗證排查問題比較繁雜。此外，query的變更無感知，沒有定時任務失敗/XT任務失敗，則認爲query是更新成功的。但是具體更新了哪些query、更新後的query是怎樣的，系統都無法反饋。
c) query詞的效果監控與評估。雖然詞功能在上線時，產品有AB實驗，但是功能上線之後，候選詞、給用戶下發的詞(曝光)、用戶點了哪些詞(點擊)，都沒有統計數據，可結合埋點結果數據，按天維度計算展示詞的“效果”，以更好地反饋哪些詞的效果好，哪些不好，從而能分析各產品形態下 query 推薦的詞效果，並不斷迭代。
d）query 各維度特徵的存儲與應用（“搜索詞分析”）
7.2 query 推薦優化
a) 召回上，目前的 query 推薦主要是從商品的角度召回詞，沒有考慮用戶的特徵信息。比如類目query詞、本質詞等，都是商品背後的 query 信息。可以根據各種 query 推薦的產品形態，結合用戶 session 信息來進行詞推薦。以商詳頁推薦詞爲例，用戶在團好貨首頁輸入"某個query"搜索，點擊結果卡片進入商詳頁，此時：商詳頁出來的推薦詞可以基於用戶輸入的query來進行推薦（比如用戶輸入 query 的相似 query，可參考論文《Query Clustering Using User Logs》）。再比如，用戶在首頁推薦 feed 流點擊了若干商品卡片進入商詳頁，商詳頁的推薦詞可以基於用戶點擊商品卡片的歷史信息進行 query 推薦。業界也有類似的嘗試，可參考：https://www.6aiq.com/article/1612740439865 、 https://tracholar.github.io/wiki/machine-learning/recommend/interact-rec-taobao.html 、https://arxiv.org/pdf/1907.01639.pdf
b) 排序上，目前的 query 排序是按 search_uv、uv_cxr 或者 類目id 排序（四級類目 query 詞比三級類目 query 詞更準確），這些本質上是規則排序。後續可以引入更多的“排序參數”－用戶側 or 商品側，並結合具體的 query 推薦產品形態所需要的特徵，確定一個優化目標（搜索滲透率 or query 的轉化率）然後基於算法模型來進行 query 排序。
c) query 推薦，更多的應用場景是推薦，需要考慮“search context”下的 query 推薦。