推薦系統系列:商品關聯分析

商品關聯分析

關聯
relevance: 主要用在互聯網的內容和文檔上,比如搜索引擎算法文檔中之間的關聯性。

association: 用在實際的事物之上,比如電子商務網站上的商品之間的關聯度。

支持度(support):數據集中包含某幾個特定項的概率。
比如在1000次的商品交易中同時出現了啤酒和尿布的次數是50次,那麼此關聯的支持度爲5%。

置信度(Confidence):在數據集中已經出現A時,B發生的概率,置信度的計算公式是 :A與B同時出現的概率/A出現的概率。


假設有10000個人購買了產品,其中購買A產品的人是1000個,購買B產品的人是2000個,AB同時購買的人是800個。

支持度指的是關聯的產品(假定A產品和B產品關聯)同時購買的人數佔總人數的比例,即800/10000=8%,有8%的用戶同時購買了A和B兩個產品;

可信度指的是在購買了一個產品之後購買另外一個產品的可能性,例如購買了A產品之後購買B產品的可信度=800/1000=80%,即80%的用戶在購買了A產品之後會購買B產品;

提升度就是在購買A產品這個條件下購買B產品的可能性與沒有這個條件下購買B產品的可能性之比,沒有任何條件下購買B產品可能性=2000/10000=20%,那麼提升度=80%/20%=4。


數據關聯是數據庫中存在的一類重要的可被發現的知識。若兩個或多個變量的取值之間存在某種規律性,就稱爲關聯。關聯可分爲簡單關聯、時序關聯、因果關聯等。關聯分析的目的是找出數據庫中隱藏的關聯網。有時並不知道數據庫中數據的關聯函數,或者即使知道也是不確定的,因此關聯分析生成的規則帶有置信度。

關聯規則挖掘的一個典型例子是購物籃分析(MBA,Market Basket Analysis)。關聯規則研究有助於發現交易數據庫中不同商品(項)之間的聯繫,找出顧客購買行爲模式,如購買了某一商品對購買其他商品的影響。分析結果可以應用於商品貨架佈局、貨存安排以及根據購買模式對用戶進行分類。

關聯規則的發現過程可分爲如下兩步:

第一步是迭代識別所有的頻繁項目集(Frequent Itemsets),要求頻繁項目集的支持度不低於用戶設定的最低值;

第二步是從頻繁項目集中構造置信度不低於用戶設定的最低值的規則,產生關聯規則。識別或發現所有頻繁項目集是關聯規則發現算法的核心,也是計算量最大的部分。

最小支持度(min-support)和最小置信度(min-confidence)
支持度和置信度兩個閾值是描述關聯規則的兩個最重要的概念。一項目組出現的頻率稱爲支持度,反映關聯規則在數據庫中的重要性。而置信度衡量關聯規則的可信程度。如果某條規則同時滿足最小支持度(min-support)和最小置信度(min-confidence),則稱它爲強關聯規則。

關聯規則數據挖掘階段

第一階段必須從原始資料集合中,找出所有高頻項目組(Large Itemsets)。高頻的意思是指某一項目組出現的頻率相對於所有記錄而言,必須達到某一水平。以一個包含A與B兩個項目的2-itemset爲例,我們可以求得包含{A,B}項目組的支持度,若支持度大於等於所設定的最小支持度(Minimum Support)門檻值時,則{A,B}稱爲高頻項目組。一個滿足最小支持度的k-itemset,則稱爲高頻k-項目組(Frequent k-itemset),一般表示爲Large k或Frequent k。算法並從Large k的項目組中再試圖產生長度超過k的項目集Large k+1,直到無法再找到更長的高頻項目組爲止。

關聯規則挖掘的第二階段是要產生關聯規則。從高頻項目組產生關聯規則,是利用前一步驟的高頻k-項目組來產生規則,在最小可信度(Minimum Confidence)的條件門檻下,若一規則所求得的可信度滿足最小可信度,則稱此規則爲關聯規則。

例如:經由高頻k-項目組{A,B}所產生的規則,若其可信度大於等於最小可信度,則稱{A,B}爲關聯規則。

就“啤酒+尿布”這個案例而言,使用關聯規則挖掘技術,對交易資料庫中的記錄進行資料挖掘,首先必須要設定最小支持度與最小可信度兩個門檻值,在此假設最小支持度min-support=5% 且最小可信度min-confidence=65%。因此符合需求的關聯規則將必須同時滿足以上兩個條件。若經過挖掘所找到的關聯規則 {尿布,啤酒}滿足下列條件,將可接受{尿布,啤酒} 的關聯規則。用公式可以描述爲:

Support(尿布,啤酒)≥5% and Confidence(尿布,啤酒)≥65%。

其中,Support(尿布,啤酒)≥5%於此應用範例中的意義爲:在所有的交易記錄資料中,至少有5%的交易呈現尿布與啤酒這兩項商品被同時購買的交易行爲。Confidence(尿布,啤酒)≥65%於此應用範例中的意義爲:在所有包含尿布的交易記錄資料中,至少有65%的交易會同時購買啤酒。

因此,今後若有某消費者出現購買尿布的行爲,我們將可推薦該消費者同時購買啤酒。這個商品推薦的行爲則是根據{尿布,啤酒}關聯規則而定,因爲就過去的交易記錄而言,支持了“大部分購買尿布的交易,會同時購買啤酒”的消費行爲。

從上面的介紹還可以看出,關聯規則挖掘通常比較適用於記錄中的指標取離散值的情況。

如果原始數據庫中的指標值是取連續的數據,則在關聯規則挖掘之前應該進行適當的數據離散化(實際上就是將某個區間的值對應於某個值),數據的離散化是數據挖掘前的重要環節,離散化的過程是否合理將直接影響關聯規則的挖掘結果。


FP-Growth算法

FP-Growth(頻繁模式增長)算法是韓家煒老師在2000年提出的關聯分析算法,它採取如下分治策略:將提供頻繁項集的數據庫壓縮到一棵頻繁模式樹(FP-Tree),但仍保留項集關聯信息;該算法和Apriori算法最大的不同有兩點:第一,不產生候選集,第二,只需要兩次遍歷數據庫,大大提高了效率。

Apiorio 算法

如果一個項集是非頻繁的,那麼它的超集必然也是非頻繁的。

參考

電商數據挖掘之關聯算法(一)



如何理解皮爾遜相關係數(Pearson Correlation Coefficient)?

LLR

  private double doItemSimilarity(long itemID1, long itemID2, long preferring1, long numUsers) throws TasteException {
    DataModel dataModel = getDataModel();
    long preferring1and2 = dataModel.getNumUsersWithPreferenceFor(itemID1, itemID2);
    if (preferring1and2 == 0) {
      return Double.NaN;
    }
    long preferring2 = dataModel.getNumUsersWithPreferenceFor(itemID2);
    double logLikelihood =
        LogLikelihood.logLikelihoodRatio(preferring1and2,
                                         preferring2 - preferring1and2,
                                         preferring1 - preferring1and2,
                                         numUsers - preferring1 - preferring2 + preferring1and2);
    return 1.0 - 1.0 / (1.0 + logLikelihood);
  }

long preferring1and2 = dataModel.getNumUsersWithPreferenceFor(itemID1, itemID2);
long preferring1 = dataModel.getNumUsersWithPreferenceFor(itemID1);
long preferring2 = dataModel.getNumUsersWithPreferenceFor(itemID2);
long numUsers = dataModel.getNumUsers();

k11: preferring1and2
k12: preferring2 - preferring1and2
k21: preferring1 - preferring1and2
k22: numUsers - preferring1 - preferring2 + preferring1and2

Event A Everything but A
Event B k11 k12
Everything but B k21 k22

LLR = 2 sum(k) (H(k) - H(rowSums(k)) - H(colSums(k)))

H = function(k) {N = sum(k) ; return (sum(k/N * log(k/N + (k==0)))}

/**
   * Calculates the Raw Log-likelihood ratio for two events, call them A and B.  Then we have:
   * <p/>
   * <table border="1" cellpadding="5" cellspacing="0">
   * <tbody><tr><td>&nbsp;</td><td>Event A</td><td>Everything but A</td></tr>
   * <tr><td>Event B</td><td>A and B together (k_11)</td><td>B, but not A (k_12)</td></tr>
   * <tr><td>Everything but B</td><td>A without B (k_21)</td><td>Neither A nor B (k_22)</td></tr></tbody>
   * </table>
   *
   * @param k11 The number of times the two events occurred together
   * @param k12 The number of times the second event occurred WITHOUT the first event
   * @param k21 The number of times the first event occurred WITHOUT the second event
   * @param k22 The number of times something else occurred (i.e. was neither of these events
   * @return The raw log-likelihood ratio
   *
   * <p/>
   * Credit to http://tdunning.blogspot.com/2008/03/surprise-and-coincidence.html for the table and the descriptions.
   */
  public static double logLikelihoodRatio(long k11, long k12, long k21, long k22) {
    Preconditions.checkArgument(k11 >= 0 && k12 >= 0 && k21 >= 0 && k22 >= 0);
    // note that we have counts here, not probabilities, and that the entropy is not normalized.
    double rowEntropy = entropy(k11 + k12, k21 + k22);
    double columnEntropy = entropy(k11 + k21, k12 + k22);
    double matrixEntropy = entropy(k11, k12, k21, k22);
    if (rowEntropy + columnEntropy < matrixEntropy) {
      // round off error
      return 0.0;
    }
    return 2.0 * (rowEntropy + columnEntropy - matrixEntropy);
  }
  /**
   * Merely an optimization for the common two argument case of {@link #entropy(long...)}
   * @see #logLikelihoodRatio(long, long, long, long)
   */
  private static double entropy(long a, long b) {
    return xLogX(a + b) - xLogX(a) - xLogX(b);
  }

信息熵是衡量分佈的混亂程度或分散程度的一種度量。分佈越分散(或者說分佈越平均),信息熵就越大。分佈越有序(或者說分佈越集中),信息熵就越小。


Information retrieval

Entropy (information theory)

reference
Mahout Recommender Document: non-distributed
機器學習中的相似性度量
Mahout on Spark: What’s New in Recommenders
Mahout on Spark: What’s New in Recommenders, part 2
Intro to Cooccurrence Recommenders with Spark
Mahout: Scala & Spark Bindings
Surprise and Coincidence
How to create and App using Mahout
FAQ for using Mahout with Spark


Mahout on Spark: What’s New in Recommenders, part 2

Here similar means that they were liked by the same people. We’ll use another technique to narrow the items down to ones of the same genre later.


Intro to Cooccurrence Recommenders with Spark

rp = recommendations for a given user
hp = history of purchases for a given user
A = the matrix of all purchases by all users
rp = [A^tA]hp

This would produce reasonable recommendations, but is subject to skewed results due to the dominance of popular items. To avoid that, we can apply a weighting called the log likelihood ratio (LLR), which is a probabilistic measure of the importance of a cooccurrence.

The magnitude of the value in the matrix determines the strength of similarity of row item to the column item. We can use the LLR weights as a similarity measure that is nicely immune to unimportant similarities.

ItemSimilarityDriver

Creating the indicator matrix [AtA] is the core of this type of recommender. We have a quick flexible way to create this using text log files and creating output that’s in an easy form to digest. The job of data prep is greatly streamlined in the Mahout 1.0 snapshot. In the past a user would have to do all the data prep themselves. Translating their own user and item ids into Mahout ids, putting the data into text files, one element per line, and feeding them to the recommender. Out the other end you’d get a Hadoop binary file called a sequence file and you’d have to translate the Mahout ids into something your application could understand. No more.


Part 4: Tuning Your Recommender
兩點改進

MAP

https://www.kaggle.com/wiki/MeanAveragePrecision
What you wanted to know about Mean Average Precision

《基於mahout on spark + elastic search搭建item推薦系統》

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章