中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：在進行搜索結果召回時，要先清楚用戶經常搜索的Query分為哪幾類，才能建立我們整體的召回策略。那么，根據不同類型的Query，我們應該使用什么樣的召回策略呢？一起來看一下吧。

前言：上一篇為大家介紹完電商APP搜索引擎的整體框架，這一篇為大家詳細介紹如何召回搜索結果。

01 用戶常見Query分類

所有的召回都是根據用戶的Query來的，首先我們要清楚用戶經常搜索的Query分為哪幾類，我們才能夠清晰地根據用戶的Query去構建我們整體的召回策略。我們將用戶的Query分為以下幾個大類：

1. 單實體和多實體

從用戶的Query結構上來講，就是單實體和多實體，上篇文章介紹過經過切詞后的實體識別，最終整個Query被分為幾個實體。

比如“蘋果”就是一個實體，當然它可能有多個實體性質，“蘋果”既可以是一個Brand，也可以是一個SPU?！疤O果電腦”就是多實體，在此Query中“蘋果”是一個Brand，“電腦”是一個SPU，該Query是由兩個實體詞組合而成。

2. 意圖明確、較明確、模糊

實體識別后得到Query的實體詞，用戶Query的意圖也是分為幾個級別：

1）明確

比如“水果”，水果是一個CATEGORY，我們返回蘋果、香蕉、葡萄等是在用戶的意圖以內的。

2）較明確

比如“早餐”、“配菜”、“午飯”，這些詞匯我們能夠猜測到用戶想搜索什么，早餐可以是豆漿、包子等，“配菜”可以是一些醬菜、韓國泡菜，“午飯”可以是一些便當、三明治等。

3）模糊

實際業務中用戶很多的Query單憑字面意思很多時候是無法猜測到用戶的實際意圖， 比如“甜”、“辣”、“干”等，很多單個字的Query。

“甜”到底是甜筒還是甜辣醬，這是完全兩類商品，用戶的本意肯定是只想其中一種。至于為什么用戶會出現這類模糊的Query，一方面可能和用戶的輸入法有關，另外一方面可能是用戶沒有輸入完整；同時這類Query詞在線上出現的頻率很高，針對這類詞我們也需要猜測用戶意圖，盡可能召回相關度高的商品，而不僅僅是搜索無結果。

上述主要為大家介紹用戶的query分為哪些類型，那么針對各種類型的Query我們使用什么樣的召回策略了？

02 召回策略一

簡單Match機制。

很多電商APP在最開始做搜索召回時，采用的都是比較粗暴的做法，就是簡單地將用戶的Query和商品名進行匹配，或者是經歷切詞后再和商品名進行Macth，沒有實體識別這一步。

這就會導致用戶搜索“水”，雖然“礦泉水”、“純凈水”等會被召回，因為含有“水”。但是“水桶”、“水餃”等也含有“水”，在Macth的層面上和“礦泉水”、“純凈水”并沒有差異，搜“米”，“米餅”、“蝦米”和“大米”是完全一樣的。

此類方法雖然實現起來很簡單，但是實際效果很差，召回的結果特別混亂。

此類比較粗暴的方法也慢慢被市場淘汰，目前市場上主要以策略二為主。

03 召回策略二

以實體識別為基礎，進行Query改寫，根據實際業務場景和業務需求，再結合業務運營策略和兜底策略，進行層次性召回。

1. 預處理

預處理就是對Query進行糾錯、切詞、拼音轉漢字、去停用詞等。中文的分詞器目前用的比較廣泛的是hanlp和ES的ik切詞。

假設用戶輸入了“kangshifu紅燒方便面*% ”。

1. 切詞：先對整個query進行切詞，切分為“kangshifu”、“紅燒”、“方便面”、“*”、“%”
2. 拼音轉漢字：再將拼音kangshifu轉化為康師傅
3. 去停用詞：將“*”、“%”沒有任何意義的停用詞去除掉

2. 實體識別

預處理完以后就是進行實體識別了，一般最開始我們需要先建立該領域的實體體系，也就是該領域經常關注的一些屬性等。比如下圖是阿里云關于電商領域建立的實體體系。

而我們對2.21預處理完剩下的“康師傅”、“紅燒”、“方便面”進行實體識別，最終得到【Brand：康師傅；Taste：紅燒；SPU &CATEGORY：方便面】。很多詞匯并不是只有一個實體，比如這里的“方便面”，它既是一個SPU又是一個CATEGORY。

實體識別有三個非常重要的問題：

1）實體識別完全依賴詞庫

對于實體詞庫中不存在的實體詞識別不出。比如用戶搜索“蘋果”，如果“蘋果”這個詞根本沒有被實體詞庫所收集，那么我們的分析器也就識別不了“蘋果”到底是代表什么實體？這就和人類學習一個新詞匯一樣，必須要有人教我們這個新詞匯到底是什么意思，不然我們只能瞎猜。

2）實體識別不出的詞如何進行處理

對于實體識別不出的詞，一般我們也不是直接忽略，而是將這類詞打上一個“OTHER”的性質，用“OTHER”來表示它，也會繼續進入召回階段；還有一種方式就是“瞎猜“，就和人類學習新詞匯，我可以瞎猜一下它的意思。

當然計算機不是瞎猜，一般情況下我們是會對歷史所有的實體詞進行分類，構建一個分類體系，然后基于歷史數據訓練一個分類模型，當一個全新的詞進入時，我們就會通過該分類模型去預測，這個新詞應該是屬于哪個分類下面。

3）實體存在多性質如何處理

如果是單個實體Query，此時實體識別出來多性質是合理的，比如用戶搜索“蘋果”，它既可能是“Brand”，也可能是“SPU”，二者都存在可能性，所以實體識別出來的最終結果就是多性質。但是對于“蘋果手機”，我們就不能認為“蘋果”既是“SPU”又是“Brand”，因為結合后面的實體“手機”，這里的“蘋果”只能是Brand。

所以在多實體Query中，我們一般每個實體只取一個性質，如果某個詞存在多性質，此時我們會通過模型去計算每個性質的概率，然后取最高概率的那個性質。

3. Query改寫

經過實體識別后，我們需要再對Query進行改寫：

1）同義詞改寫

很多實體詞是存在完全一樣的同義詞，所以召回時我們也需要將同義詞作為召回條件。比如“小番茄”和“圣女果”，“香菜”和“芫荽”。

2）近義詞改寫

很多詞之間并不是完全相同，二者也不是包含關系，但是存在一定的近似性，某種程度上可以進行替代。比如“礦泉水”和“純凈水”，“純牛奶”和“舒化奶”等。

為什么我們還建立近義詞詞庫，是因為某些場景中，比如很多生鮮電商APP中，用戶在定位到某一家門店時，搜索“礦泉水”，假設該門店沒有，我們如果直接展示搜索無結果，那么就是白白浪費了一個銷售機會，但如果我們將“純凈水”也展示出來，其實用戶很多時候也會下單，因為二者差異不大。

當然此部分功能，有些APP會做在“為你推薦”里面，具體展現在哪里不重要，背后的邏輯是一致的。

3）意圖詞改寫

此類詞匯和近義詞不同之處在于，很多時候是存在一種包含關系。比如“蘋果和紅富士”、“早餐和包子、饅頭、豆漿”，用戶搜索“紅富士”時，如果沒有“紅富士”，通過意圖詞我們可能就會展示其他蘋果。用戶搜索“早餐”，當既沒有“早餐”這個CATEGORY，又沒有商品叫做“早餐”時，我們只能通過這一類意圖詞進行關聯。

為什么我們將詞庫拆解的如此細致，分為同義詞、近義詞、意圖詞等等，是因為不同場景下我們需要使用不同的詞庫組合，如果都混合在一起就十分混亂，想拆解時都無法拆解。如何去構建積累上述的詞庫，一方面需要運營通過人工經驗的方式進行添加，另一方面就是機器去歷史用戶的搜索記錄、埋點數據數據等進行挖掘，形成相關詞庫再進行人工審核。

4）實體權重調整

視業務方具體需求。實體權重調整在綜合電商APP使用的是最多的，也是上一篇介紹過的，比如用戶搜索【王一博同款白色衛衣限量版】，我們就需要拆分召回條件，如果用【王一博 and 同款 and 白色 and 衛衣 and 限量版】去索引中進行召回，可能召回的結果就會很少。

所以我們需要重新構建召回條件，進行Query改寫，挑選比較重要的條件去召回，其他條件忽略。我們可以將Query改寫為【王一博 and 白色 and 衛衣 】所以實體與實體之間是存在優先級的，有些實體屬性是要優于其他實體屬性的。

上述四大類Query改寫，同義詞改寫是必須的，近義詞改寫和意圖詞改寫一般情況我們都是用在召回結果比較少的搜索場景下使用，希望盡可能多地展示一些搜索結果，不浪費每一次曝光機會。實體權重調整有時候是召回結果過多，需要精簡；有時候是召回結果過少，希望擴增，具體視業務需求。

4. 業務運營策略

當經過上述一系列實體識別和Query改寫后，我們就會去ES索引里已經結構化好的物料庫進行商品召回。比如用戶搜索“康師傅”，實體識別后為【Brand： 康師傅】，我們就會將所有物料Brand這個Label=“康師傅”的進行召回。如何對物料庫進行結構化處理，可以參考上一篇文章。

但有時候業務方要求用戶搜索某些詞匯時，必須將一些商品召回，這些商品可能上述一整套召回邏輯無法覆蓋。比如用戶搜索“夏日解暑”，這個詞匯可能和任何商品都無法直接形成關聯，但我們通過硬編碼的方式強行讓該搜索詞和“冰棒”、“雪糕”、“冰淇淋”等進行關聯，這樣也可以搜索出結果來。

此策略一般我們都是開發成通用的運營操作界面，由運營在系統頁人工每日進行添加、刪除、修改等，做成一個通用的產品功能。

5. 兜底策略

最后整個召回還會存在一個兜底策略，其實主要就是Part2.1的Match機制，比如用戶只搜索一個“甜”字，也就是我們上文中介紹的實體識別出來是一個“OTHER”性質，我們很難識別用戶的真實意圖，到底是“甜筒”、“甜辣醬”還是“甜玉米”等，這時我們只能通過和商品名Match的機制，將所有商品名中含有“甜”字的商品全部召回。

同時如果該詞匯是一個正常詞匯，但是并沒有收錄到我們的實體詞庫里面，我們也可以通過兜底策略保證有結果可以召回，而不是結果為空。但是召回后這些商品如何進行排序了？這也就是下一篇要為大家介紹的：電商APP智能搜索第三講—如何排序搜索結果。

本文由 @King James 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議