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

編輯導語：推薦的目的主要在于依據用戶行為偏好，為用戶推薦可能喜歡的事物；而搜索則是用戶出于一定目的進行檢索，前者為被動獲取，后者為主動獲取。具體而言，推薦系統與搜索系統有何差異？本篇文章里，作者從整體邏輯層面對推薦系統與搜索系統的區別進行了總結，一起來看一下。

根據我平時接觸的推薦和搜索業務，簡單地將2個業務的流程進行梳理以及知識點擴展，便于需要的同學能夠快速地了解2個系統的基本邏輯。

一、推薦系統邏輯

推薦的本質就是為了解決信息過載造成的“選擇困難癥”，便于用戶能夠在自己選物之前，系統已經幫用戶篩選到了最想要的信息。

以下是我按照用戶打開APP進入推薦頁面時，推薦系統返回給該用戶推薦列表的整體流程：

整個流程的重點邏輯主要在召回、排序、重排三層，這一節專門講這一塊，至于AB實驗平臺上的邏輯，后面會有專門的一節進行AB實驗的詳解。

1. 召回

什么是召回？大多數人都會很快解釋：召回是從物料庫中獲取一小部分物料，這一小部分物料會在后續的環節被模型用來進行打分排序。

這里我們再直白一點理解吧，召回就是撈，給用戶推薦的時候，不可能把平臺上所有的item都拿出來走模型排序，這樣的話計算時間會很長，且資源消耗很大、不合理。這個時候就需要去平臺內容庫里把最適合用戶的item撈出來，這就是我們說的召回。

通常都是從億萬級數據或千萬級數據中撈出千百級別的item。召回這一步主要是處理數據量大，需要步驟速度夠快、模型不能太復雜且使用特征相對排序少。

當然，召回也是決定個性化推薦的基礎，目前來看，召回多數是多路召回（這里可以理解為通過不同限制條件去撈）。

多路召回的好處：

• 提高召回率和準確率，這里不對這2個名詞作解釋，可以找相關文章自行查詢；
• 個性化推薦的基礎，用戶多樣性興趣探索，多元化召回；
• 保證線上事故發生時還有存余召回兜底，避免推薦接口沒有返回的數據；
• 貼近業務，各業務需求不一樣，需要進行融合（廣告召回、強插、item冷啟動等）。

常見的召回路徑（策略都是需要數據支持且與場景強相關的）：

1）協同過濾

基于用戶的協同過濾，基于item的協同過濾；簡單來說就是喜歡A內容的用戶，還喜歡B游戲（這種召回方式比較老，現在很少有公司會用）。

協同過濾和用戶及游戲都有關，矩陣，玩過就是1，沒玩就是0，沒玩過的游戲很多，很多都是0，所以會做矩陣分解：用戶矩陣和商品矩陣，每一列就是用戶向量或商品向量。

2）word2vec（詞向量）

（最早用于NLP中）需要拿到用戶的玩游戲序列，每個游戲做one-hot編碼，會有一個神經網絡模型，輸入是A→B→？→D→E，輸出是C，或A→B→C→D去預測E。

模型中間的隱藏層就叫詞向量，和游戲有關，和用戶沒關，拿數據的時候和用戶有關（向量用法：用戶和游戲算相似度：用戶A和游戲B向量做相似度計算；用戶和用戶、游戲和游戲）。

3）內容匹配召回

這一塊主要和標簽（類別）召回有關，比如：用戶玩了王者榮耀，那么可以嘗試召回推薦類似王者榮耀的吃雞游戲，這是基于內容標簽的召回；又或者用戶玩了植物大戰僵尸1，那么也可以嘗試推薦植物大戰僵尸2/3等，這是基于知識儲備的匹配。

4）高熱召回（熱門召回）

這一路召回主要是新用戶用的比較多，新用戶剛來APP，拿不到過多的用戶信息且沒有行為，這種情況下，平臺高熱召回就起了大作用，用來做新用戶冷啟動；用戶冷啟動這里不做過多結束，后面會有專門的一節做介紹。

5）基于上下文的召回

這個和用戶在APP發生行為的時間、地點等場景有關系，例如游戲推薦在白天碎片休息時間推薦小游戲，在晚上休息時間推薦大游戲、游戲時長較長的游戲等；在其他垂類上體現的話，就像打車垂類對于用戶位置信息的敏感，用戶刷新聞的時間等等。

6）級聯召回

一般的召回是用戶點擊做正樣本，級聯是用精排排在前面的游戲做正樣本，排在后面的做負樣本，做召回模型的正負樣本。

7）其他召回

根據業務需求，還會有其他召回，且每路召回的數量也有差異，例如為了讓新用戶快速留下來，新用戶高熱召回占比較大，但老用戶的話，為了挖掘用戶興趣多樣化，高熱召回占比會相對小一點。

召回層也是有模型的，尤其是做電商業務，召回的模型會更復雜。

2.?排序——粗排/精排

粗排和精排，都是排序，一個需要快速排序盡量去掉錯誤召回，一個需要貼合用戶和業務需求精細準確排序。

粗排在召回和精排之間，一般需求從召回回來的萬/千級別item集合中選擇出千/百級別更符合業務需求的item送到精排層。平臺內容少時，幾乎很少會做粗排這一步，因為粗排最大的作用就是快速計算并截斷召回量，使召回數據更準更適合推給用戶，一般粗排需要在20ms內完成打分。

如果沒有粗排模型，也可以在召回層和精排層用一些策略進行數量截斷進精排，也是一種粗排手段，例如用點擊轉化率進行截斷。

精排處理數據量少，需要模型做到更準確，通常會上一些復雜模型以及使用較多特征。

粗排和精排層可以是一個模型打分，也可以是多個模型打分融合再進行排序，多數業務需求情況下多數都是多個模型，根據業務需求，模型的目標不一樣，但基本上都會有點擊模型（ctr）。

下面就單獨就點擊模型來講一下模型是怎么打分排序的，講排序之前需要先知道2個概念——label和features，這2個數據，是ctr模型的主要訓練數據。

label：用ctr模型舉例，每個模型都有label（模型的預測目標），ctr模型的label就是用戶對當下曝光的item有沒有點擊行為，有曝光點擊就為正樣本，label=1，有曝光無點擊則為負樣本，label=0。

features：就是特征。特征主要分為3類：用戶特征、item特征、用戶和item的交叉特征。

• 用戶特征：用戶本身的特征，例如年齡、性別、地理位置等、登錄設備（iOS/Android）；
• item特征：item本身的特征，例如標簽、物品ID、天級點擊次數、評論量、熱門排名等；
• 用戶特征和item的交叉特征：例如item天級的點擊次數、周級點擊人數、天級曝光次數等。

可以看出，features是我們在推薦系統都能夠收集到的數據，其中有離散型特征（例如男女、分類、整數等），也有連續型特征（例如點擊率、自然數）。

在計算機只能處理數字編碼的前提下，將這些信息進行編碼轉化，大多數推薦系統對于離散型特征多使用one-hot或embedding，對于連續性特征可以不用處理，或者先分段離散化，再使用one-hot編碼。

（大多數公司使用離散型特征的較多，連續型特征使用較少，有時連續型特征也會做分桶處理——分段，其實就是變相地處理成離散型數據。）

*注，one-hot編碼會將特征處理為[0 0 0 0 1]，embedding會將特征處理為[0.2 0.4 0.6 0.8]

在明確了 features 和 label 的定義之后，會構造對應的訓練樣本：

• 負樣本 (曝光不點擊)：([**0,0,0,1,0,0,**0.12,0.13,0.05, …, ], 0）
• 正樣本 (曝光點擊)：(**[0,0,1,0,0,0,**0.02,0.08,0.13, …, ], 1）

所以訓練時 CTR 模型輸入即為：特征向量和其對應的 0、 1 標簽。

預測時，輸入只有特征向量，模型輸出一個 0~1 之間的數字，代表預估的 CTR 值，可以用來做排序。所以，建模之后，本質上 CTR 預估問題是一個二分類問題。

這就是其中一個模型的打分邏輯，有多模型打分融合的精排層，會將多個模型的分數進行打分，每個模型的重要性不一樣，因此分數都會有權重，將每個模型的分數進行權重計算后相乘在一起，就是這個item的排序分數，每個item按照分數進行從高到底排序，就會得到精排打分列表。

3.?重排（混排/rerank）

這一步是推薦的最后一步，每個公司的叫法可能存在差異，有的叫重排，有的叫混排，學術一點叫rerank；雖然也是排序，但重排和粗排或精排最大的區別還是在于這一步更貼近業務需求，產品經理發揮的空間也相對多一些。

做一些強插業務的時候，需要召回配合重排層做，例如做新內容冷啟動時，需要給到沒有數據的內容一個曝光的機會，這個時候就需要用到重排強插；或者做一些打散邏輯時，例如連續的7個內容中不能有相似內容，或連續的10個內容中最多有2個相似內容等等。

二、搜索系統邏輯

當你在搜索框中輸入一串搜索詞后，頁面展示出你想要的結果，但其中的邏輯卻是很復雜，這里我認為搜索是比推薦相對復雜的業務：

整個流程的重點邏輯也包含了召回、排序、重排，但更為重要的是query處理部分，因為上面詳細講了 召回——排序——重排部分，因此這里不過多講解，只將重點放在query處理上。

query主要由query預處理、意圖識別、query分詞、query改寫4個部分組成，各公司會依照搜索業務的復雜程度進行部分簡化；（query：用戶搜索詞，例如用戶在搜索框輸入“秋冬連衣裙女”并點擊搜索，那么用戶query就是“秋冬連衣裙女”）。

1）query預處理

這一步主要是針對用戶在搜索框中輸入的搜索詞，進行數據清洗。

搜索詞基本上都會有長度限制，一種是輸入框限制搜索詞長度，一種是query預處理的時候進行搜索詞截斷，例如超過20個字長度的搜索詞只截取前20個字。

因為用戶輸入搜索詞的不規范，且不同的用戶對同一種訴求的表達往往會存在地域、文化程度以及清晰度的差異，因此會對搜索詞進行轉化：大小寫轉換，例如“太空狼人殺3d版”轉換為“太空狼人殺3D版”；簡繁體轉換，例如“太空狼人殺”轉換為“太空狼人殺”；還有全半角轉換，這里就不再展開過多說明。

query預處理這一步都是根據用戶主動輸入的搜索詞，進行高頻query查詢檢索出的常見問題，針對問題進行本質問題本質解。

2）意圖識別

意圖識別的本質就是分類問題，主要是根據業務需求進行用戶意圖分類，分為幾個大類，收集每種意圖類別下的常用詞進行模型訓練，模型準確率越高，意圖識別效果越好。意圖識別在搜索系統中是必不可少的，意圖識別在很大程度上決定了用戶搜索質量的好壞。

*意圖識別的難點：

1. 輸入不規范；就像上面提到的，不同用戶對同一個內容的認知存在差異，輸入的搜索詞也會存在不小的差異；
2. 數據冷啟動，用戶行為較少數據較少，意圖獲取會相對沒那么準；
3. 多意圖識別，無法定位精準意圖，例如用戶搜索“車”，無法知道是想要玩具車還是四輪真車，或者是摩托車；
4. 業界沒有固定的評價標準，只有不同業務直接自己劃分的分類進行的模型分類準確率計算，而一些業務指標例如ctr、cvr、pv等指標，都是評價整個搜索系統的，具體到意圖識別上的量化指標卻沒有。

3）query分詞

query分詞主要是對用戶搜索詞進行切分，根據切分的詞去進行改寫以及后續的召回邏輯，不同業務的切詞方式及自由切詞庫是有差異的。

4）query改寫

這一步主要是針對用戶搜索詞進行糾錯、以及同義詞擴展召回等。需要做糾錯詞表或糾錯模型，例如將“火才人”糾錯為“火柴人”，將“超級貓麗奧”糾錯為“超級馬里奧”，將“校園”擴展為“學?！薄ⅰ袄蠋煛?、“教室”、“同桌”等等，同義詞擴展里面會存在一些干擾詞，需要根據實際業務對頭部搜索詞的同義詞進行自定義切詞表或自定義同義詞表等。

三、推薦和搜索的區別

從上述對推薦系統和搜索系統的整體流程的講述可以看出，推薦和搜索既有緊密聯系，又有不小的差異。

1. 行為主動或被動

本質問題本質解，搜索和推薦都是為了解決信息過載問題，都是獲取信息的方式之一，一個主動獲取——搜索，一個被動獲取——推薦：推薦行為是被動的，需求不是很明確，個性化和多樣性會多一些，而搜索的需求是主動和相對明確的，且查詢范圍相對較小。

2. 使用場景目的

推薦的本質是需要留住用戶在APP中，讓用戶使用的時間變長，并且第二天也能留住用戶，逐漸產生廣告收益和其他收益，讓用戶消費更多，需要通過分析用戶的歷史行為以及當前的實時行為場景等，推薦系統自發生成查詢條件快速給出推薦列表的行為，是一種無聲的搜索。

而搜索更像張小龍早期口中的微信，需要用完即走，搜索的本質是協助用戶快速找到自己需要的結果并完成轉化離開。我理解，好的搜索算法需要做的是讓用戶快速使用，高效查詢并且停留時間更短。

3. 是互相成就

從流程來看，搜索就是限定了條件的推薦，推薦就是自發的主動搜索；從用戶query中可以收集到大量個性化推薦的需求，推薦數據可以推薦用戶搜索內容的相似內容，進行數據融合，而當用戶搜索目的不明確時使用好的推薦，結合意圖識別和推薦模型，實現類目下的更精準推薦，是提升用戶體驗的手段。

以上就是我對推薦和搜索場景在實際項目中的邏輯梳理，如果有感興趣的同學，歡迎私聊。

加油，打工人！

本文由 @王九蛋 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

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