[Premium]{class="badge positive" title="檢視Target Premium包含的內容。"}

Target 推薦演算法背後的科學

深入說明中使用的演演算法 Adobe Target Recommendations,包括模型訓練的邏輯和數學細節,以及模型服務的程式。

模型訓練是產生建議的程式, Adobe Target 學習演演算法。 模型服務是如何 Target 會傳送建議給網站訪客(也稱為內容傳送)。

Target 包含下列各種演演算法 Recommendations:

  • 以專案為基礎的演演算法:包括遵循「檢視/購買此專案的人員也檢視/購買這些專案」邏輯的演演算法。 這些演演算法會分組在傘狀術語「專案 — 專案協同篩選」下,以及 具有類似屬性的專案 演演算法。

  • 以使用者為基礎的演演算法:包含 最近檢視的專案 和 為您推薦 演演算法。

  • 基於人氣的演演算法:包含可傳回網站中「最常檢視」或「最常購買」的專案、或依類別或專案屬性之「最常檢視」或「最常購買」專案的演演算法。

  • 購物車型演演算法:包含多專案型建議,且邏輯為「已檢視/購買這些專案的人,也已檢視/購買這些專案」。

  • 自訂條件:包含根據上傳至的自訂檔案的建議 Target.

NOTE
如需有關每種演演算法型別及個別演演算法的詳細一般資訊,請參閱 讓建議以建議索引鍵為依據.

以上列出的許多演演算法都是以一或多個索引鍵的存在為前提。 這些索引鍵會在內容傳送時(產生建議時)用來擷取類似專案。 客戶指定的索引鍵可包含某人正在檢視的目前專案、最後一個已檢視或購買的專案、最常檢視的專案、目前類別,或該訪客最喜愛的類別。 其他演演算法(例如購物車型或使用者型建議)則使用隱含索引鍵(客戶無法設定)。 如需詳細資訊,請參閱 建議索引鍵,在 讓建議以建議索引鍵為依據. 但是請注意,這些鍵值僅在模型服務時間(內容傳送)中相關。 這些索引鍵不會影響「離線」或模型訓練時間邏輯。

以下各節會以與上述演演算法型別稍微不同的方式將演演算法分組。 以下分組是根據模型訓練邏輯的相似性。

料號 — 料號協同篩選

演演算法包括:

  • 瀏覽過此項目、也瀏覽了其他項目的使用者
  • 瀏覽過此項目、但購買了其他項目的使用者
  • 購買了此項目、也購買了其他項目的使用者

料號 — 料號協同篩選建議演演算法所根據的理念是,您應使用許多使用者的行為模式(因此是協同合作),為指定料號提供有用的建議(例如,篩選可能要建議的料號目錄)。 雖然有許多不同的演演算法屬於的一般傘狀結構, 協同篩選,這些演演算法會普遍使用行為資料來源作為輸入。 在 Target Recommendations,這些輸入為使用者對專案的不重複檢視和購買。

針對「檢視/購買此專案的使用者也檢視/購買這些專案」演演算法,目標是計算所有專案配對之間的相似度(A,B)。 接著,系統會針對指定專案A,依其相似度s(A,B)排序排名最前的建議。

這種相似性的一個範例是專案之間的共同發生:購買兩個專案的使用者人數的簡單計數。 雖然此量度直覺式偏好,但偏向於推薦熱門專案,因此這種量度並不實際。 例如,如果大部分人在雜貨店購買麵包,則麵包會與所有專案有很高的共現率,但這不一定是好的建議。 Target 而是使用更複雜的相似性量度,稱為對數似然比(LLR)。 如果兩個專案(A和B)同時發生的機率與其不同時發生的機率非常不同,則此數量會很大。 如需具體資訊,請考量以下案例 瀏覽過此專案、但購買了其他專案的使用者 演演算法。 購買B的可能性時,LLR相似度會很大 無論是否有人檢視A。

例如,若

已檢視/已購買演演算法的公式

則專案B不應與專案A一起建議。已提供此對數似然比相似度計算的完整詳細資料 在此PDF.

實際演演算法實施的邏輯流程如下圖所示:

已檢視/已購買演演算法的示意圖

這些步驟的詳細資訊如下:

  • 輸入資料:行為資料,以您收集時檢視和購買訪客的形式 實作Target or from Adobe Analytics.

  • 模型訓練

    • 資料清理和取樣:針對具有N天回顧的演演算法,會先篩選行為資料以僅包含這N天的資料。 收集規則和全域排除會套用,以移除任何不應建議使用的專案。 最後,任何與1,000個以上專案互動的訪客,其使用資料取樣為僅1,000個專案。
    • 專案相似度計算:此為核心運算步驟:計算所有候選專案配對之間的對數似然比相似度,並依此相似度分數排名專案配對。
    • 離線篩選:最後,會套用任何其他適用的動態篩選器(例如動態類別排除)。 在此步驟後,預先計算的建議會快取至全域,以便提供。
  • 模型服務:Recommendations內容傳送自 Target的 全域「邊緣」網路. 向發出mbox請求時 Target 而且我們決定應將建議內容傳送至所需頁面 專案索引鍵 針對recommendations演演算法,會從請求中剖析,或從使用者設定檔中查詢,然後用於擷取在先前步驟中計算的建議。 此時會在適當的位置之前套用其他動態篩選器 設計 已呈現。

內容相似度

包含的演演算法:

  • 具有類似屬性的專案

在此型別的演演算法中,如果兩個專案的名稱和文字說明在語義上相似,則會將其視為相關。 與大多數必須使用行為資料來源的Recommendations演演算法不同,內容相似度演演算法使用產品目錄中的中繼資料來匯出專案之間的相似度。 Target 因此,能夠在所謂的「冷開始」情境中推動建議,其中未收集任何行為資料(例如,在 Target 活動)。

雖然模型服務與內容傳遞方面屬於 Target的內容相似度演演算法與其他以專案為基礎的演演算法相同,模型訓練步驟截然不同,並涉及一系列自然語言處理和前置處理步驟,如下圖所示。 相似度計算的核心是使用已修改的tf-idf向量餘弦相似度,這些向量代表目錄中的每個專案。

顯示內容相似度流程圖

這些步驟的詳細資訊如下:

  • 輸入資料:如前所述,此演演算法完全以目錄資料(擷取至 Target 透過 目錄摘要、實體API或來自頁面上的更新.

  • 模型訓練

    • 屬性擷取:套用一般靜態篩選器、目錄規則和全域排除後,此演演算法會從實體結構中擷取相關文字欄位。 Target 自動使用實體屬性中的名稱、訊息和類別欄位,並嘗試從自訂擷取任何字串欄位 實體屬性. 此程式可透過確保該欄位的大多數值都不可剖析為數字、日期或布林值來完成。

    • 刪除詞幹和停用詞:如需更精確的文字相似度比對,請謹慎移除不會大幅改變專案含義的常見「停止」字詞(例如「was」、「is」、「and」等)。 同樣地,詞幹是指將尾碼不同的字詞還原為根字詞的過程,根字詞具有相同的含義(例如,「connect」、「connecting」和「connection」都擁有相同的根字詞:「connect」)。 Target 使用Snowball詞幹分析器。 Target 首先執行自動語言偵測,最多可以刪除50種語言的stop單字,並為18種語言撰寫詞幹。

    • N元組建立:在先前步驟後,每個字詞都會被視為語彙基元。 將權杖的連續序列組合成單一權杖的過程稱為n字元組建立。 Target的演演算法最多可考慮2克。

    • tf-idf計算:下一個步驟涉及建立tf-idf向量,以反映專案說明中權杖的相對重要性。 對於專案i中的每個Token/詞語t,在目錄D中使用 |D| 專案,會先計算字詞頻率TF(t, i) (字詞出現在專案i中的次數),以及檔案頻率DF(t, D)。 實質上,代號存在的專案數。 則tf-idf測量為

      顯示tf-idf測量值的公式

      Target 使用Apache Spark的 tf-idf 功能化實作,會在幕後將每個權杖雜湊至一個218個權杖的空間。 在此步驟中,也會套用客戶指定的屬性提升與埋藏,方法為根據 條件.

    • 專案相似度計算:最終專案相似度計算會使用近似餘弦相似度來完成。 針對兩個專案, AB,使用向量tA和tB,餘弦相似度的定義如下:

      顯示專案相似度計算的公式

      為避免所有N x N個專案之間運算相似性的重大複雜性, tf-idf 向量被截斷為僅包含其最大的500個專案,然後使用此截斷向量表示來計算專案之間的餘弦相似度。 與其他近似最近鄰(ANN)技術(例如區域性敏感雜湊技術)相比,此方法對於稀疏向量相似度計算更具穩健性。

    • 模型服務:此程式與上節所述的專案 — 專案共同篩選技術相同。

多鍵建議

演演算法包括:

  • 購物車型建議
  • 為您推薦

最近新增至 Target 建議演演算法套裝為 為您推薦 以及一系列購物車型建議演演算法。 這兩種演演算法都使用合作篩選技術來形成個別專案型建議。 接著,在服務時間點,使用者的瀏覽記錄中會顯示多個專案(例如 為您推薦)或使用者目前的購物車(適用於購物車型建議)可用來擷取這些專案型建議,接著會合併形成建議的最終清單。 請注意,存在許多風格個人化推薦演演算法。 多鍵演演算法的選擇表示訪客擁有任何瀏覽歷程記錄後,即可立即使用建議,而建議可以更新,以回應最新的訪客行為。

這些演演算法以「以專案為基礎的建議」區段中說明的基本共同篩選技術為基礎,但也合併超引數調整以確定專案之間的最佳相似度量度。 演演算法會依時間順序對每個使用者的行為資料執行分割,並在較早的資料上訓練建議模型,同時嘗試預測使用者稍後會檢視或購買的專案。 產生最佳值的相似性量度 [平均平均精確度] (接著選擇https://en.wikipedia.org/wiki/Evaluation_measures_(information_retrieval)。

模型訓練和評分步驟的邏輯如下圖所示:

顯示模型訓練和評分步驟邏輯的圖表

這些步驟的詳細資訊如下:

  • 輸入資料:這等同於專案 — 專案共同篩選(CF)方法。 兩者均為您推薦 和購物車型演演算法會使用行為資料,其形式為當您在網站上購物時 實作Target or from Adobe Analytics.

  • 模型訓練

    • 資料清理和取樣:這再次與合作篩選方法相同,後者套用回顧期間以篩選行為資料至適當的日期範圍,然後套用目錄規則和全域排除。 與超過1,000個專案互動的訪客只會考慮其最近的1,000個使用例項。
    • 訓練測試分割:對每個使用者執行使用情形的時間順序分割,將其使用情形的前80%分配給訓練資料,其餘20%分配給測試資料。
    • 專案相似度模型訓練:核心專案相似度計算的差異為 為您推薦 和購物車型演演算法的方式,以建構候選專案向量。 的 為您推薦,專案向量具有維度NUsers,其中每個專案代表該使用者對該專案的隱含評等總和,購買專案的權重為該專案檢視的2倍。 對於購物車型建議,專案向量具有二進位專案;如果只考慮工作階段內的行為,則每個工作階段都會有新專案。 否則,此專案向量中會有每個訪客的專案。

    訓練步驟會計算數種型別的向量相似度: LLR相似度(在此討論)、餘弦相似度(先前定義)和標準化的L2相似度(定義為:

    顯示訓練計算的公式

    • 專案相似度模型評估:模型評估是透過採用上一步驟中產生的建議並對測試資料集做出預測來完成。 模擬線上評分階段的方法是,在測試資料集中依時間順序排序每個使用者的專案使用情形,然後對排序的專案子集提出100個建議,以嘗試預測後續的檢視和購買。 資訊擷取量度, 平均平均精確度可用來評估這些建議的品質。 此量度會考量建議的順序,並偏向建議清單中排名較高的相關專案,這是排名系統的重要屬性。
    • 模型選取:離線評估後,會選取平均平均精確度最高的模型,並計算所有個別專案建議。
    • 離線篩選:模型訓練的最後一個階段是應用任何適用的動態篩選器。 在此步驟後,預先計算的建議會快取至全域,以便提供。
  • 模型服務:不同於先前的演演算法,提供建議需要指定單一索引鍵進行擷取,接著套用商業規則, 為您推薦 和購物車型演演算法會採用更複雜的執行階段程式。

    • 多索引鍵擷取和合併:針對購物車式建議,最多會將購物車中傳遞的10個專案視為擷取的索引鍵,並會平均加權每個專案的建議。 的 為您推薦,最多可將最近五個不重複檢視的專案和最近五個不重複購買的專案視為擷取的索引鍵,其中購買專案產生的建議權重是檢視專案產生的建議的兩倍。 合併建議時,如果某個專案出現在多個個別建議清單中,則會新增其加權相似度分數。 此階段的最終建議清單是重新加權的合併建議清單,依遞減順序排列。
    • 篩選:接著,會套用篩選規則,例如移除先前檢視和/或購買的專案,以及其他動態業務規則。

下圖說明這些程式,其中訪客已檢視專案A並購買專案B。系統會使用每個專案標籤下方顯示的離線相似度分數來擷取個別建議。 擷取後,建議會與加權相似度分數彙總合併。 最後,在客戶已指定必須篩選掉先前檢視和購買專案的情境中,篩選步驟會從建議清單中移除專案A和B。

顯示多鍵演演算法處理程式的圖表

基於人氣

演演算法包括:

  • 全網站檢視次數最多
  • 依類別檢視次數最多
  • 依專案屬性檢視次數最多
  • 全網站最暢銷商品
  • 依類別排名的最暢銷商品
  • 依專案屬性排名的最暢銷商品

Target 針對所有網站或依專案屬性或類別劃分的「檢視次數最多」專案及「最暢銷」專案,提供以人氣為基礎的演演算法。 基於人氣的演演算法會根據在指定時間範圍內檢視或購買該專案的工作階段數來排名專案。

所有這些演演算法都會結合彙總的行為資料,也就是以每小時和每日解析度來記錄檢視和購買專案的工作階段總數。 接著,個別演演算法會針對客戶設定的回顧期間,尋找檢視次數最多或購買次數最多的專案。

個別演演算法的細微差別如下:

  • 全網站檢視次數最多 和 全網站最暢銷商品 依已檢視或購買這些專案的工作階段彙總計數來排名專案。 輸出是建議專案的單一(無索引鍵)清單。
  • 依類別/專案屬性檢視次數最多/最暢銷商品是建議,其中專案會依檢視或購買這些專案的工作階段彙總計數排序,但會依專案類別或特定專案屬性分組。 輸出是建議專案清單,以類別值或專案屬性值作為索引鍵。

最近檢視的專案

「最近檢視的」建議演演算法允許在工作階段中個人化建議。 此演演算法不需要離線「模型訓練」。 而是 Target 使用唯一 訪客資料 維護在指定工作階段中檢視過的專案執行中清單,並可在Recommendations活動中顯示這些專案。 如此可讓您即時更新推薦內容並取得下一頁個人化。

自訂條件

自訂條件允許客戶 上傳自己的建議至 Target,提供重要的彈性,並允許「自攜」模型功能。 自訂條件取代了的「離線訓練」部分 Item-Based recommendations,但其行為類似於線上內容傳遞階段期間的「專案型」建議演演算法,也就是使用單一索引鍵來擷取建議,然後套用商業規則/篩選器。

recommendation-more-help
3d9ad939-5908-4b30-aac1-a4ad253cd654