怎麼讓我的商品被看到?電商的搜索、廣告、推薦系統是怎麼設計的?

搜索、廣告、推薦的相同與不同?召回、排序、重排 分別代表著什麼?

Rice Yang
15 min readJan 4, 2022

之前的文章《Facebook真的會竊聽我嗎?》裡面稍微介紹過了一下推薦系統的運作原理,包括如何用演算法去匹配使用者與物品的興趣度,以及物品與物品、使用者與使用者之間的關聯性。但是對於一個大型的電商系統,例如eBay、Shopee、淘寶裡面的演算法設計,卻沒太大著墨。

這篇文章會試著從技術角度拆解電商系統的商品呈現機制,並且試著回答一個簡單的問題:如何讓我的商品能夠被使用者看到?

電商系統

在電商系統裡面,「搜索」、「廣告」、「推薦」這三個技術是都是為了解決資訊超載 (Information Overload) 的問題,因此很容易混淆不清。在文章最初我們必須要定義一下這三個在電商系統裡分別代表什麼。

搜索 Searching

對電商系統而言,最重要的功能之一就是商品搜索,而搜索背後仰賴的就是搜索演算法。但是要注意,在搜索的結果頁面並非全是搜索結果,有很多部分是廣告。舉例來說,這是我在蝦皮搜索「耳機」的結果:

第一排的圖片右下角都寫著「廣告」,代表這些位置是商家出錢買下來的。當然,買了「耳機」這個廣告位的商家不只有這 5 家,因此怎麼設計出現在廣告位的商品、讓平台的廣告收入最大化是廣告演算法的核心問題。

從第二排開始是搜索演算法的結果。因為我沒有登入蝦皮帳號,所以這裡顯示的是去個人化的搜索結果,會儘量包含各個用戶群體喜歡的類型,例如:低價耳機、熱銷耳機等。與廣告系統不同,搜索系統的展示結果是無限長度的,排序方式也依據平台的目標而定,例如轉化率 (Conversion Rate, CVR)等。

廣告 Advertising

廣告演算法有時候會與搜索結果一起呈現,如上圖的蝦皮搜索;有時候則是會以搜索無關的廣告位呈現,例如 Facebook 的廣告。

兩種廣告演算法的差別在於有無搜索詞 (Query)。對於內嵌在搜索結果裡面的廣告,可以利用搜索詞的結果來進行更精確的廣告置入;而對於 Facebook 這種沒有搜索詞的廣告,要進行精準推薦,吸引使用者點擊的難度就更大了。

但不管有無 Query,廣告演算法的目標都不是為了讓使用者舒服,而是為了讓購買廣告位的廣告主曝光度最高。因為廣告位會根據用戶的點擊廣告的次數收費,因此增加點擊率 (Click Through Rate, CTR) 就變成廣告演算法的主要目標之一。

推薦 Recommendation

廣義來說,只要不是在搜索結果裡面呈現,也不是明標為廣告位的地方呈現的內容,都屬於推薦演算法的範疇。例如 Facebook 的朋友貼文,Youtube 的首頁、Tiktok 的上下滑等。當然,有時搜索演算法為了提供更多元化的搜索結果,也會參雜一些推薦結果在裡面。

推薦演算法在某些影音平台或社交平台裡面幾乎主導了使用者的體驗,如 Tiktok、Facebook。因此對推薦系統而言,個性化 (personalize) 與上下文 (context) 都更為重要。個性化指的就是吸引用戶登入、紀錄用戶的歷史興趣、並且根據用戶的喜好來決定推薦內容。上下文指的是根據用戶用戶最近下單的商品、最近看過的內容等額外資訊來決定推薦內容。

雖然推薦演算法的考量點比搜索與廣告更複雜,但是推薦演算法可以無視長尾內容 (long-tail item)。與必須符合使用者的意圖的搜索演算法不同,也與必須考量所有廣告主的廣告演算法不同,推薦演算法可以只推薦少數高品質的內容就可以了。

Long-tail item。來源:Recommender Systems: What Long-Tail tells ? | by Kadir Yasar | Medium

對於「搜索」、「廣告」、「推薦」這三個演算法而言,技術的架構是差不多的,因為他們都要從一大群資料裡面找到符合使用者興趣的目標。但是因為最終的最佳化目標不一樣,所以三者所考慮的輸入特徵 (input features),以及最終的損失函數 (loss function) 設計都會有點少許不同。在許多技術文章裡面,「搜索」與「推薦」常常不會特別區分,這要特別注意。

搜索推薦系統的基本架構

想像我們今天是搜索系統的設計師,背後我們有上千萬的商品數據,需要在使用者輸入 Query 之後的 0.x 秒內返回搜索結果,並且依照使用者的興趣程度排序。面對這麼大型且複雜的問題,我們該怎麼設計一個高速且有效的演算法?

首先回想一下演算法的基本知識:搜索 Searching 是屬於 O(N) 的演算法,而排序 Sorting 是屬於 O(N logN) 的演算法。在大數據中,Searching 會比 Sorting 快上好幾倍。

基於以上知識,我們可以想到一種簡單的方法論:我們可以先快速的把商品資料庫裡面簡單比對,把可能是結果的候選商品 (Candidate) 快速搜索出來。接著,我們可以用某一種評分方法 (Score),讓使用者感興趣的商品排在前面,而不感興趣的商品排在後面,然後只保留評分最高的幾項。最後,我們可以再加入一些規則,例如稍微打散商品順序 (Re-ranking),避免 10 個 同款耳機同時在前排的結果,增加用戶下滑的動力,以瀏覽更多商品。

上述的三個步驟,就是一般搜索推薦系統最常用的設計方式。在 Google 的文章《Recommendation System Overview》與微博 AILab 資深專家的文章《推荐系统技术演进趋势》都是以這幾個步驟拆分推薦系統技術:召回 Retrieval、排序 Scoring、重排 Re-ranking

召回、排序(粗排+精排)、重排。圖片來源:推荐系统技术演进趋势

召回 Retrieval

召回作為搜索推薦第一步,必須在最短的時間內過濾出有限的商品集合,並且避免使用者高興趣度的商品在這個階段被過濾。

從實務上的搜索推薦系統來說,第一步是先進行資料庫搜索。而這部分會使用一種技術叫做 查詢詞改寫 Query Rewrite,是一種將使用者的查詢詞改寫成適合資料庫的關鍵字再查詢的技術。這一步的目的是為了將使用者的查詢詞改寫成機器較好懂的查詢詞,例如把「蘋果手機」改寫成「iPhone」。

透過 Query Rewrite 與數據庫查詢搜索出大量的候選商品之後,就可以用一些計算複雜度較低的方法對這些商品進行,留下幾萬個商品作為召回階段的結果。從實務上,召回與排序的目標可以是相同的,兩者的差別在於召回更偏重計算效率,而排序更重視結果精度。

之前的文章《Facebook真的會竊聽我嗎?》中介紹的 Collaborative FilteringContent-based filtering 都很適合在這裡使用,因為這些算法屬於線型模型,計算複雜度較低。除了這些,你也可以直接加入熱門度、用戶興趣標籤等等人工規則來做排序召回,並且把這些召回的結果匯總在一起,確保更高的召回率。這種方式稱之為在中國互聯網業內稱為 多路召回,雖然實作簡單且有效,但是在實際運行的時候需要時刻的調整各路的召回量已確保整體效果與性能。

Collaborative Filtering 協同過濾示意圖。來源:Collaborative filtering — Wikipedia

線型模型的缺點在於很難考慮特徵之間的交互作用。與統計學的手法類似,你可以將各個特徵組合之後變成新的特徵,這樣建構的線型模型就能考慮到特徵之間的相互作用。傳統的 FM (Factorization Machines) 模型也經常被用在推薦系統中。FM 是屬於線型模型的一種,但是對於特徵組合的方法有更可靠的表示方式,對於稀疏的特徵組合有更好的容忍度。

深度學習也被常使用在搜索系統中,經典的通用方法是使用雙塔模型 DSSM (Deep Structured Semantic Model)。DSSM 的精神就是使用兩組模型,把商品與用戶都變成同一個數學空間的向量,成為 Embedding。透過向量比對計算 Embedding 之間的相似度,可以快速的知道那些商品與用戶之間是相近的。這種模型通常會較簡單,MLPRNNTransformer都是不錯的模型選擇。值得注意的是,CNN 不適合用於搜索推薦領域,因為 CNN 假設了特徵之間具有局部關聯性,而推薦領域的特徵順序是無意義的,不符合 CNN 的假設。

DSSM 基本架構,目標是計算 Q 與 D 的相似度。圖片來源:General architecture of the DSSM network

隨著技術的更新,有越來越多的演算法可以用在搜索系統,例如 Knowledge Graph Embedding (KGE), Graph Neural Network (GNN)。下面是 Amazon 的 AWSLab 開源的 DGL-KE,就是屬於 KGE 的一種,有興趣的同學可以參考一下:

排序 Scoring

排序演算法與召回演算法在設計上是大致相同的,但是因為召回階段已經過濾了大部分的選項,因此排序階段允許更多參數、更複雜的模型表示,以取得更好的效果。同時,排序演算法也幾乎決定了最後使用者看到的結果,因此排序演算法會根據搜索、推薦、廣告三者的不同,最終的最佳化目標也不盡相同。

搜索排序

搜索系統要對用戶 Query 達到基本的滿足水平,因此 Query 的匹配程度一定是第一優先級。除此之外,觀看時間、點擊率、下單量也必須納入考量,已滿足平台的最終目標。

如果電商平台以轉化率 CVR 為目標,那麼打折或是優惠商品就比較可能放在搜索結果前面。如果反之以成交额 GMV 為目標,那麼單價較高的商品就可能較靠前。當然,有些電商系統會以用戶停留時間為目標,這時候就更可能以 CTR 或是興趣度作為最佳化目標。

推薦排序

推薦算法的目標與搜索是相同的,不同的是推薦系統沒有使用者 Query,需要透過使用者的個性化、上下文、興趣標籤、人群區分做輸入做最終的推薦結果。也因為推薦系統沒有 Query,所以可能推薦的結果會更發散,因此目標函數的設計更為重要,通常會使用多目標的損失函數設計,也就是多任務學習 multi-task learning

例如,YouTube 在 2012 年訂下的目標是以用戶觀看時間為衡量,因此 Youtube 的推薦算法裡面就會把影片長度設成主要目標,也有不少 Youtuber 開始改拍更長的影片。但是 Youtube 並沒有因此瘋狂推薦 1 小時的影片給你,因為影片品質、點擊率、興趣度仍然在目標函數的考慮範圍。畢竟,看 10 個 3 分鐘的短片,會比看一個 30 分鐘的長片更讓使用者舒服。

廣告排序

廣告與搜索推薦最大的差別在於 2 個:廣告位有限、廣告主出價 (bid)。對於有 Query 的廣告排序,首先必須在有限的廣告位裡面擺入 bid 較高的廣告商品。其次,在數個商品的 bid 相同的時候,就會儘量促使點擊或成交來提升平台或是廣告主的利益,也就是儘量提升 CTR、CVR。

因此,在廣告裡面預測點擊率 CTR 與成交率 CVR 特別重要,也可能會以 CTR 或 CVR 作為廣告排序的最佳化目標。預估 CTR、CVR 除了用在廣告排序之外,也能用在推薦排序上,以迎合平台的最高目標,例如最大化 CVR。

這裡提供兩篇阿里巴巴發表的 CTR 與 CVR 預估論文給大家參考。

重排 Re-ranking

重排是搜索推薦系統的最終階段,部分的候選項可能會在重排階段被刪除,而這部分也會再對排序的最終結果做更精細的排序。從演算法的部分來說,與召回排序的區別也不大,不同的是這部分可以同時包含人工規則與演算法。

人工規則:有些規則是可以直接被人工定義的,例如剔除最近購買過的商品、剔除郵遞不到的商品。我認為人工規則不放在召回排序而放在重排有 2 個原因:第一是因為越底層的系統就應該越通用,將需要客製化調整的功能設計在上層系統;第二是因為很多人工規則需要查詢額外查詢資料庫,因此必須放在候選項最少的重排階段來做。

演算法:重排必須考慮選項之間的順序。在重排階段,大致會遵照排序的 score 分數進行排序,但是演算法做一些特殊調整,例如避免同商家的商品連續出現、將以前購買過的商品往前排。這個階段的演算法不會用 Point wised——單點給分的方式來做排序——而是會以整個序列做為輸入,再輸出一個重拍序列—— List wisedRNNTransformer 等模型都很適合用在重排。

所以如何讓我的商品被看到?

上述講了這麼多的演算法與設計目標,透過對演算法的理解以及查的一些資料,大致有以下幾種方法:

搜索引擎優化 SEO

SEO, Search Enginge Optimization,是針對搜索引擎做優化的一種技巧。因為搜索引擎是針對 Query 做資料搜索的,因此商品名稱與描述最好能夠與盡可能多的相似 Query 都能匹配到。這也是為什麼許多商品名稱都長得不可思議的理由。

超長名稱也是 SEO 的一種方法。來源:Shopee

除了超長名稱之外,上傳影片、鼓勵使用者留言、打正確的商品標籤,都是可以提告商品曝光率的方法。

購買廣告位

購買廣告位是可以明確讓商品靠前的方法,但也取決於廣告主的出價。比較多的收費方式是 PPC, Pay Per Click,也就是點擊付費廣告,意即用戶透過廣告連結點進了你的商品就收費。對應衡量廣告位是否值得投資,應給多少出價則有一堆經營指標可以參考,詳細的可以參考這篇:

違規的方法:抱大腿攻擊

抱大腿攻擊(我暫時找不到對應的英文)指的是雇用一群網軍,重複點擊熱門商品以及自家商品,騙過推薦系統的協同過濾,以為「喜歡熱門商品的人也喜歡你的商品」,從而讓自己的商品提升被推薦的機率。

作為一篇公開文章,我必須強調這個方式是違規的,也不鼓勵大家使用。事實上阿里也針對這類攻擊做了很多的自動識別與治理工作,在阿里的開放極客競賽《天池》裡面也有專門針對抱大腿攻擊識別的競賽項目:

總結來說,搜索廣告推薦的水真的很深,不是稍微查資料可以查完的。但是從查資料的過程中,我理解這個領域的演算法已經幾乎定型不太變化了,而根據幾位認識的朋友表示,該領域的算法工程師做的工作也比較無聊,大部分是挑選合適的特徵給模型,也就是特徵工程。但是作為支撐電商平台的核心演算法而言,這類工作還是非常核心且重要的。

--

--

Rice Yang
Rice Yang

Written by Rice Yang

A Tech Manager in AI. Experienced in NVIDIA, Alibaba, Pony.ai. Familiar with Deep Learning, Computer Vision, Software Engineering, Autonomous Driving

No responses yet