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

搜索在很多場景中對于流量的轉化都高于推薦，對于業務的增長也遠遠超過推薦，然而講搜索的文章卻很少。本篇文章中作者介紹了電商APP的智能搜索引擎，講解了AI時代如何做搜索，一起來學習一下。

現在市面上太多人聊推薦，關于推薦的書也有很多很多。

搜索聊的人卻很少很少，但是搜索在很多場景中對于流量的轉化遠遠超過推薦，搜索轉化的提升對于業務的增長要遠遠超過推薦。

知乎和各大博客里面介紹搜索的文章相對于推薦就少太多了，專門開一個系列和大家聊一聊電商APP智能搜索，AI時代如何做搜索。

一、電商APP搜索引擎是什么

首先確定一下我們聊得搜索并不是Baidu、Google這種綜合搜索引擎，而是像淘寶、京東、美團這類電商APP里面的搜索引擎。

用戶通過在搜索框中輸入關鍵詞，然后搜索引擎返回相關商品，并按照一定順序返回展示給用戶。電商APP里的搜索引擎和我們平時使用的Baidu、Google主要有什么差異了：

1.?用戶的Query復雜度差異較大

用戶使用綜合類搜索引擎Query的復雜度很高，很多時候是一種探索式的搜索，比如用戶搜“經典電影”，百度會首先返回百度自身推薦的經典電影，然后后面會有大量含“經典電影”字樣的帖子。很多時候用戶的Query甚至是一種描述性的語句比如“含有愛情的詩句”。

而電商APP里的搜索引擎因為場景固定，用戶搜索目的性很強，Query意圖比較明確如“男鞋”、“長褲”、“可樂”等，一方面用戶目的性強，另一方面用戶也知道該場景下Query過于探索是不會有結果的，用戶有一定的認知判斷。

所以綜合類搜索引擎需要對用戶的搜索意圖識別的很準確，而電商場景的搜索引擎會相對要求低一些。

2. 搜索結果池差異太大

二者背后存儲的數據多樣性差異很大，體量差異更大。

電商APP搜索引擎搜索的結果一定都是呈現在APP上的。但是綜合類搜索引擎完全不是，搜索結果來自于各大網站，很多結果是外部鏈接。內容形式各種各樣：視頻、文字、音頻等等。

綜合類搜索引擎背后存儲著大量的數據，同時數據在不停地增加和更新。而電商APP搜索引擎背后的數據池都僅限于該APP上的商品，即使商家不停地上下架商品，整體數據量和綜合類搜索引擎差距也是巨大的。

二、電商APP中的搜索引擎為什么重要

那么我們為什么說電商APP中的搜索引擎特別重要。

一方面隨著網上購物消費群體的多樣化以及年輕人不斷增強的自主意識，用戶已經從傳統的“被動”接受網站推薦的商品信息，轉變為“主動”去發現商品，發掘自己感興趣的商品。

那么APP中的搜索功能就成為了非常重要的功能，能否識別用戶的意圖并且準確地返回相應的商品就十分關鍵。

另一方面數據顯示：

1. 綜合電商APP

搜索引擎占據的銷售歸因目前普遍在60%以上，搜索占據淘寶的銷售歸因約為70%左右。

銷售歸因即為該平臺上各個流量轉化入口如：搜索入口、分類頁入口、首頁推薦入口等對最終的銷售貢獻占比。通過上面的數據我們可以清晰地得出搜索目前對于整個業務流量的轉化貢獻是最大的。

在綜合類電商APP剛剛開始時，最大的銷售歸因模塊是分類頁，也就是我們看到淘寶上的“女裝”、“手機”、“男裝”等模塊，但現在已經是搜索入口貢獻著最多的流量轉化。

2. 生鮮電商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中的搜索引擎整體框架到底是怎么樣的了？我們用下圖來進行表示：

下面我們針對上圖中的每個模塊一個一個進行詳細介紹。

1. 分析器

分析器的作用就是對用戶的Query進行處理，進行糾錯預處理后，然后再進行切詞、拼音轉漢字、去停用詞等，最后將整個Query分成單個詞組合以后再進行實體識別。

比如用戶輸入了“kangshifu紅燒方便面*% ”，

1）切詞

先對整個query進行切詞，切分為“kangshifu”、“紅燒”、“方便面”、“*”、“%”。切詞這部分功能工業界有一些通用的切詞器，比如ik切詞、hanlp切詞器，但是我們實際使用時都會再加入更多的詞庫進行切詞，不僅僅是使用現成的切詞器。

2）拼音轉漢字

再將拼音kangshifu轉化為康師傅；

3）去停用詞

將“*”、“%”沒有任何意義的停用詞去除掉；

4）實體識別

最后對剩下的“康師傅”、“紅燒”、“方便面”進行實體識別，我們不僅需要把固定搭配的詞切分出來，我們還需要知道這些詞代表的實體含義，最終得到【Brand：康師傅；Taste：紅燒; SPU &CATEGORY：方便面】。很多詞匯并不是只有一個實體，比如這里的“方便面”，它既是一個SPU又是一個CATEGORY。

2. 詞庫

上面提到的一系列操作都離不開詞庫，沒有詞庫分析器寸步難行。我們知道“kangshifu紅燒方便面%”里面的kangshifu應該是“康師傅”，然后Query的斷句應該是“康師傅”、“紅燒”、“方便面”而不是“康”、“師傅”、“紅”、“燒方便面”，就因為我們已經對這些詞匯固定搭配有了一定知識積累，同時“*%”對于查詢是沒有任何意義的，也是基于我們歷史的詞匯和知識積累。

但是計算機不知道，我們如何讓計算機知道“康師傅”是一個固定搭配，同時它是一個Brand，這就需要我們建立各種各樣的詞庫了。

電商APP搜索引擎中詞庫是非常重要的，第一詞庫全不全，第二詞庫準不準。不同行業不同領域會有自己專門的詞庫，大部分詞庫都不是通用的。下圖是阿里云Opensearch建立的電商行業的實體詞庫類型。

但其實還有很多實體詞庫類型需要補充，比如生鮮電商業的SPU、口味、包裝等。同時還會存在大量的同義詞庫、近義詞庫、糾錯詞庫、拼音詞庫等等。

計算機如何知道用戶搜索“圣女果”和“小番茄”是一種東西，這就需要同義詞庫。

同義詞庫需要大量的積累，尤其是在生鮮電商領域，同樣一種菜，全國各地叫法都不一樣，但是對應的是同一種菜。同時還存在同一種叫法，對應的是不同種食物，比如“珍珠米”在上海就是玉米粒，在東北是一種大米。

所以詞庫的建立是必不可少的，同時又是一個需要長久積累，且持續更新不斷細化的過程。

3. Recall & Elasticsearch索引

當我們將“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 衛衣 】所以實體與實體之間是存在優先級的，有些實體屬性是要優于其他實體屬性的。

最終我們召回得到搜索結果。

4. Ranking

召回的搜索結果如何進行排序了，一般我們從以下兩個方面進行考慮：

1）相關性排序

商品和Query的相關性程度，比如用戶搜“康師傅紅燒牛肉面100g”那么肯定是“康師傅紅燒牛肉面100g”的商品排序在最前面，“康師傅紅燒牛肉面150g大袋”排序在后；

2）業務規則排序

另外我們也要結合商品歷史的銷量、用戶的喜愛程度、價格、促銷等一系列因素綜合考慮，比如用戶搜索“方便面”，方便面的種類太多：康師傅、統一、湯達人等等。和“方便面”的相關性都是完全一樣的，這時候我們可能會將歷史銷量高的、用戶喜愛程度高的商品排序在前。

通常情況下第一種和第二種我們是綜合在一起進行加分，然后再對商品進行綜合排序。

3）機器學習模型

通過歷史用戶的點擊、購買、收藏、加購數據等，構建機器學習模型，然后模型來進行千人千面的排序，這也是目前市場上主流電商APP的做法，每個人搜索同一個詞，看到的結果是完全不一樣的，

上述整體地介紹了召回和排序模塊，實際應用中召回和排序模塊還有很多細節，后續我們會專門再對這兩個模塊進行詳細介紹。

5. Reranking

上述是一些通用的規則或者模型排序策略，實際業務方還會有一些其他要求，比如最近業務方在對“康師傅”牌的方便面做市場推廣活動，那么在用戶搜索“方便面”時，業務方就希望我們將所有“康師傅”品牌的方便面排序在前。

所以很多時候Ranking的結果還需要經過一層Reranking再排序，這一層主要是業務策略的排序。

6. AB Test

最后就是AB Test實驗臺，很多時候我們線上有很多套搜索策略，為了對比不同策略的用戶點擊效果等，我們需要同時進行AB Test實驗，也就是我們類似我們高中學過的控制變量法，同一時間段線上生產APP，用戶的訪問進行隨機切分到不同的實驗桶中，最終對比二者的效果。

上面就是一個電商APP搜索引擎通常的整體框架了。

四、搜索的效果評估

當我們將搜索引擎搭建好以后，如何去評估搜索引擎的好壞了？通過哪些指標去評估搜索的效果。

1. 線下評估

線下評估對于搜索來說是最難評估的，當搜索引擎沒有上線時我們如何去評估搜索引擎的效果好壞。這個時候我們需要構建測試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指標（評估排序是否合理的指標）

搜索引擎不僅要將所有商品召回，排序也要合理，理論上打分結果最高的結果排序在最前面，打分結果最低的排序在最后面，搜索“康師傅方便面”，不能是“湯達人方便面”排序第一位。具體計算公式如下：

2. 線上評估

線上我們可以使用很多種指標進行多方面效果評估，一般采用如下指標：

1）查詢無結果率

評估召回效果，通常該指標越低越好，說明大部分搜索都是有結果的；

2）平均點擊商品位數

評估排序效果，通常該指標越小越好，說明用戶在結果頁的前面就找到了自己感興趣的商品；

3）CTR

點擊轉化率是綜合評估搜索的效果，用戶搜索后的點擊情況，是否點擊是由召回結果和排序情況共同決定的，CTR越高越好；

4）加購率

加購率也是綜合評估搜索的效果，對于搜索結果是否加購，加購率越高越好；

5）跳失率

進入搜索結果頁后用戶是否沒有任何操作就跳出了，如果該指標很高，說明用戶對于搜索結果不滿意和不感興趣，跳失率越低越好。

上面就是電商APP智能搜索系列的第一講了，主要給大家介紹了整體框架和評估體系，后續會繼續推出：第二講—如何召回搜索結果；第三講—如何排序搜索結果；第四講—搜索引擎的業務效果評估指標；第五講—搜索結果的內容形式和創意形式，對很多模塊進行更加細致的講解～