電商搜索技術原理?編輯導語：搜索在很多場景中對于流量的轉化都高于推薦，對于業務的增長也遠遠超過推薦，然而講搜索的文章卻很少本篇文章中作者介紹了電商APP的智能搜索引擎，講解了AI時代如何做搜索，一起來學習一下，我來為大家科普一下關于電商搜索技術原理?下面希望有你要的答案，我們一起來看看吧!
編輯導語：搜索在很多場景中對于流量的轉化都高于推薦，對于業務的增長也遠遠超過推薦，然而講搜索的文章卻很少。本篇文章中作者介紹了電商APP的智能搜索引擎，講解了AI時代如何做搜索，一起來學習一下。
現在市面上太多人聊推薦，關于推薦的書也有很多很多。
搜索聊的人卻很少很少，但是搜索在很多場景中對于流量的轉化遠遠超過推薦，搜索轉化的提升對于業務的增長要遠遠超過推薦。
知乎和各大博客裡面介紹搜索的文章相對于推薦就少太多了，專門開一個系列和大家聊一聊電商APP智能搜索，AI時代如何做搜索。
一、電商APP搜索引擎是什麼首先确定一下我們聊得搜索并不是Baidu、Google這種綜合搜索引擎，而是像淘寶、京東、美團這類電商APP裡面的搜索引擎。
用戶通過在搜索框中輸入關鍵詞，然後搜索引擎返回相關商品，并按照一定順序返回展示給用戶。電商APP裡的搜索引擎和我們平時使用的Baidu、Google主要有什麼差異了：
用戶使用綜合類搜索引擎Query的複雜度很高，很多時候是一種探索式的搜索，比如用戶搜“經典電影”，百度會首先返回百度自身推薦的經典電影，然後後面會有大量含“經典電影”字樣的帖子。很多時候用戶的Query甚至是一種描述性的語句比如“含有愛情的詩句”。
而電商APP裡的搜索引擎因為場景固定，用戶搜索目的性很強，Query意圖比較明确如“男鞋”、“長褲”、“可樂”等，一方面用戶目的性強，另一方面用戶也知道該場景下Query過于探索是不會有結果的，用戶有一定的認知判斷。
所以綜合類搜索引擎需要對用戶的搜索意圖識别的很準确，而電商場景的搜索引擎會相對要求低一些。
二者背後存儲的數據多樣性差異很大，體量差異更大。
電商APP搜索引擎搜索的結果一定都是呈現在APP上的。但是綜合類搜索引擎完全不是，搜索結果來自于各大網站，很多結果是外部鍊接。内容形式各種各樣：視頻、文字、音頻等等。
綜合類搜索引擎背後存儲着大量的數據，同時數據在不停地增加和更新。而電商APP搜索引擎背後的數據池都僅限于該APP上的商品，即使商家不停地上下架商品，整體數據量和綜合類搜索引擎差距也是巨大的。
二、電商APP中的搜索引擎為什麼重要那麼我們為什麼說電商APP中的搜索引擎特别重要。
一方面随着網上購物消費群體的多樣化以及年輕人不斷增強的自主意識，用戶已經從傳統的“被動”接受網站推薦的商品信息，轉變為“主動”去發現商品，發掘自己感興趣的商品。
那麼APP中的搜索功能就成為了非常重要的功能，能否識别用戶的意圖并且準确地返回相應的商品就十分關鍵。
另一方面數據顯示：
搜索引擎占據的銷售歸因目前普遍在60%以上，搜索占據淘寶的銷售歸因約為70%左右。
銷售歸因即為該平台上各個流量轉化入口如：搜索入口、分類頁入口、首頁推薦入口等對最終的銷售貢獻占比。通過上面的數據我們可以清晰地得出搜索目前對于整個業務流量的轉化貢獻是最大的。
在綜合類電商APP剛剛開始時，最大的銷售歸因模塊是分類頁，也就是我們看到淘寶上的“女裝”、“手機”、“男裝”等模塊，但現在已經是搜索入口貢獻着最多的流量轉化。
搜索入口占據的銷售歸因目前普遍在35%-40%左右。
生鮮電商APP為像盒馬、叮咚買菜、每日優鮮這類專門賣生鮮為主的APP。因為生鮮電商整體商品相對于綜合電商APP少很多，用戶每日在APP上面買菜，除了搜索入口，分類頁也占據着生鮮電商APP非常大的銷售歸因，幾乎和搜索入口一樣也在35%-40%左右。
通過上面的數據我們可以直觀地看出搜索功能對于電商APP流量的轉化起到多大的作用。
同時我們再算一筆賬：
2019年淘寶全年成交金額為5150億美金，假設其中70%是由搜索轉化的，也就是說3605億美元是由搜索入口轉化的。
那麼如果我們通過提升搜索體驗，豐富搜索輔助功能等，将70%的搜索銷售歸因轉化淨提升1個點到71%。
淘寶全年的銷售額将增長51.5億美元，這是一個什麼概念？2019年叮咚買菜全年銷售額為50億RMB，大概是7個叮咚買菜的體量。所以互聯網企業都在大力提升搜索的轉化率，轉化率每一個點的提升，帶來的都是全年業務量的巨大增長。
三、搜索的整體框架介紹完搜索的重要性，那麼我們如何去提升搜索的轉化率，如何去搭建一個搜索引擎，在電商APP中的搜索引擎整體框架到底是怎麼樣的了？我們用下圖來進行表示：
下面我們針對上圖中的每個模塊一個一個進行詳細介紹。
分析器的作用就是對用戶的Query進行處理，進行糾錯預處理後，然後再進行切詞、拼音轉漢字、去停用詞等，最後将整個Query分成單個詞組合以後再進行實體識别。
比如用戶輸入了“kangshifu紅燒方便面*% ”，
1）切詞
先對整個query進行切詞，切分為“kangshifu”、“紅燒”、“方便面”、“*”、“%”。切詞這部分功能工業界有一些通用的切詞器，比如ik切詞、hanlp切詞器，但是我們實際使用時都會再加入更多的詞庫進行切詞，不僅僅是使用現成的切詞器。
2）拼音轉漢字
再将拼音kangshifu轉化為康師傅；
3）去停用詞
将“*”、“%”沒有任何意義的停用詞去除掉；
4）實體識别
最後對剩下的“康師傅”、“紅燒”、“方便面”進行實體識别，我們不僅需要把固定搭配的詞切分出來，我們還需要知道這些詞代表的實體含義，最終得到【Brand：康師傅；Taste：紅燒; SPU &CATEGORY：方便面】。很多詞彙并不是隻有一個實體，比如這裡的“方便面”，它既是一個SPU又是一個CATEGORY。
上面提到的一系列操作都離不開詞庫，沒有詞庫分析器寸步難行。我們知道“kangshifu紅燒方便面%”裡面的kangshifu應該是“康師傅”，然後Query的斷句應該是“康師傅”、“紅燒”、“方便面”而不是“康”、“師傅”、“紅”、“燒方便面”，就因為我們已經對這些詞彙固定搭配有了一定知識積累，同時“*%”對于查詢是沒有任何意義的，也是基于我們曆史的詞彙和知識積累。
但是計算機不知道，我們如何讓計算機知道“康師傅”是一個固定搭配，同時它是一個Brand，這就需要我們建立各種各樣的詞庫了。
電商APP搜索引擎中詞庫是非常重要的，第一詞庫全不全，第二詞庫準不準。不同行業不同領域會有自己專門的詞庫，大部分詞庫都不是通用的。下圖是阿裡雲Opensearch建立的電商行業的實體詞庫類型。
但其實還有很多實體詞庫類型需要補充，比如生鮮電商業的SPU、口味、包裝等。同時還會存在大量的同義詞庫、近義詞庫、糾錯詞庫、拼音詞庫等等。
計算機如何知道用戶搜索“聖女果”和“小番茄”是一種東西，這就需要同義詞庫。
同義詞庫需要大量的積累，尤其是在生鮮電商領域，同樣一種菜，全國各地叫法都不一樣，但是對應的是同一種菜。同時還存在同一種叫法，對應的是不同種食物，比如“珍珠米”在上海就是玉米粒，在東北是一種大米。
所以詞庫的建立是必不可少的，同時又是一個需要長久積累，且持續更新不斷細化的過程。
當我們将“kangshifu紅燒方便面*% ”經過分析器處理後，得到【Brand：康師傅；Taste：紅燒; SPU&CATEGOY：方便面】後，我們需要構建召回條件，就是用上述哪些實體去物料庫中進行召回。
1）物料庫結構化梳理
召回的基礎就是電商APP的搜索針對的物料是固定的，也就是當前APP上架的所有商品，背後對應的就是整個APP物料庫。在最開始時我們就需要對整個物料庫進行結構化梳理，數據庫裡面存儲的是結構化數據，而不隻是一個商品名“康師傅紅燒牛肉面100g”。
結構化數據如下圖：
如何對物料進行結構化梳理，一方面就是物料入庫時商品運營需要人為手動地對商品進行CATG1、2、3進行分類，需要分類清楚，相應的規格、産地等等都需要輸入準确，另一方面就是模型根據一定的規則通過商品名進行相關實體的提取，比如口味、SPU等，這個前提建立在商品名是正确且完整的，如果商品名本身沒有該實體信息，模型也是無法提取的。
目前業内通用的分布式搜索引擎是Elasticsearch,查詢速度很快。結構化的物料數據都存儲在Elast
2）召回條件構建
【Brand：康師傅；Taste：紅燒; SPU&CATEGOY：方便面】通常情況下我們會将實體之間通過and關系去物料庫中進行召回，但上述“方便面”存在兩個屬性，所以會兩個屬性分别去進行召回。
同時我們也會加入同義詞，構建新的召回條件，比如“方便面”的同義詞存在“泡面”，同時同義詞性是在SPU這個實體下存在的，所以我們會再構建一個召回條件【Brand：康師傅；Taste：紅燒; SPU：泡面】。
在生鮮電商中召回條件構建比較簡單，但在綜合電商中比如用戶搜索【王一博同款白色衛衣限量版】，我們就需要拆分召回條件，如果用【王一博 and 同款 and 白色 and 衛衣 and 限量版】去索引中進行召回，可能召回的結果就會很少。
所以我們需要重新構建召回條件，進行Query改寫，挑選比較重要的條件去召回，其他條件忽略。我們可以将Query改寫為【王一博 and 白色 and 衛衣 】所以實體與實體之間是存在優先級的，有些實體屬性是要優于其他實體屬性的。
最終我們召回得到搜索結果。
召回的搜索結果如何進行排序了，一般我們從以下兩個方面進行考慮：
1）相關性排序
商品和Query的相關性程度，比如用戶搜“康師傅紅燒牛肉面100g”那麼肯定是“康師傅紅燒牛肉面100g”的商品排序在最前面，“康師傅紅燒牛肉面150g大袋”排序在後；
2）業務規則排序
另外我們也要結合商品曆史的銷量、用戶的喜愛程度、價格、促銷等一系列因素綜合考慮，比如用戶搜索“方便面”，方便面的種類太多：康師傅、統一、湯達人等等。和“方便面”的相關性都是完全一樣的，這時候我們可能會将曆史銷量高的、用戶喜愛程度高的商品排序在前。
通常情況下第一種和第二種我們是綜合在一起進行加分，然後再對商品進行綜合排序。
3）機器學習模型
通過曆史用戶的點擊、購買、收藏、加購數據等，構建機器學習模型，然後模型來進行千人千面的排序，這也是目前市場上主流電商APP的做法，每個人搜索同一個詞，看到的結果是完全不一樣的，
上述整體地介紹了召回和排序模塊，實際應用中召回和排序模塊還有很多細節，後續我們會專門再對這兩個模塊進行詳細介紹。
上述是一些通用的規則或者模型排序策略，實際業務方還會有一些其他要求，比如最近業務方在對“康師傅”牌的方便面做市場推廣活動，那麼在用戶搜索“方便面”時，業務方就希望我們将所有“康師傅”品牌的方便面排序在前。
所以很多時候Ranking的結果還需要經過一層Reranking再排序，這一層主要是業務策略的排序。
最後就是AB Test實驗台，很多時候我們線上有很多套搜索策略，為了對比不同策略的用戶點擊效果等，我們需要同時進行AB Test實驗，也就是我們類似我們高中學過的控制變量法，同一時間段線上生産APP，用戶的訪問進行随機切分到不同的實驗桶中，最終對比二者的效果。
上面就是一個電商APP搜索引擎通常的整體框架了。
四、搜索的效果評估當我們将搜索引擎搭建好以後，如何去評估搜索引擎的好壞了？通過哪些指标去評估搜索的效果。
線下評估對于搜索來說是最難評估的，當搜索引擎沒有上線時我們如何去評估搜索引擎的效果好壞。這個時候我們需要構建測試case，并對這些測試case進行數據标注。
比如我們從用戶曆史搜索詞中随機抽取100個Query，然後人工針對這些Query進行物料标注，每一個Query應該召回哪些商品，每個商品的相關度分數是多少。我們不會對所有物料進行标準，因為工作量太大了，通常标注幾千到1萬個物料。
然後将相關度分為幾個檔次，比如【2，1，-1】三個檔次，2表示強相關，1表示一般相關，-1表示不相關。然後人工根據自己的經驗進行标注。
比如物料是【康師傅方便面、統一方便面、康師傅礦泉水、湯達人方便面】
那麼Query=“方便面”時，我們可以标注為【2，2，-1，2】；
Query=“康師傅方便面”時，可以标注為【2，1，-1，1】；
這些标注都是人工進行标注的，标注員的标準不一樣，可能整個結果完全不一樣，所以最開始就需要大家統一好标準，很多時候我們是根據搜索引擎的策略進行标注。
1）召回率（評估召回結果是否齊全的指标）
用戶搜“方便面”，隻召回了“康師傅方便面”，那麼召回率=1/3；如果三款方便面全部召回了，召回率=3/3=100%；
2）DCG&NDCG指标（評估排序是否合理的指标）
搜索引擎不僅要将所有商品召回，排序也要合理，理論上打分結果最高的結果排序在最前面，打分結果最低的排序在最後面，搜索“康師傅方便面”，不能是“湯達人方便面”排序第一位。具體計算公式如下：
線上我們可以使用很多種指标進行多方面效果評估，一般采用如下指标：
1）查詢無結果率
評估召回效果，通常該指标越低越好，說明大部分搜索都是有結果的；
2）平均點擊商品位數
評估排序效果，通常該指标越小越好，說明用戶在結果頁的前面就找到了自己感興趣的商品；
3）CTR
點擊轉化率是綜合評估搜索的效果，用戶搜索後的點擊情況，是否點擊是由召回結果和排序情況共同決定的，CTR越高越好；
4）加購率
加購率也是綜合評估搜索的效果，對于搜索結果是否加購，加購率越高越好；
5）跳失率
進入搜索結果頁後用戶是否沒有任何操作就跳出了，如果該指标很高，說明用戶對于搜索結果不滿意和不感興趣，跳失率越低越好。
上面就是電商APP智能搜索系列的第一講了，主要給大家介紹了整體框架和評估體系，後續會繼續推出：第二講—如何召回搜索結果；第三講—如何排序搜索結果；第四講—搜索引擎的業務效果評估指标；第五講—搜索結果的内容形式和創意形式，對很多模塊進行更加細緻的講解～
本文由 @King James 原創發布于人人都是産品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
