1. 從啤酒與尿布說起關(guān)聯(lián)規(guī)則到底在解決什么問題很多人第一次聽到關(guān)聯(lián)規(guī)則分析這個詞腦子里浮現(xiàn)的可能是超市購物籃里啤酒和尿布擺在一起的經(jīng)典故事。這個故事流傳太廣以至于不少人以為關(guān)聯(lián)規(guī)則就是用來做商品推薦的。這個理解不算錯但太窄了。關(guān)聯(lián)規(guī)則分析的本質(zhì)是在一堆事件集合里找出哪些事件傾向于一起出現(xiàn)并且用可量化的指標(biāo)去衡量這種一起出現(xiàn)到底有多強(qiáng)、有多可信。我做了這么多年數(shù)據(jù)相關(guān)的工作接觸過的關(guān)聯(lián)規(guī)則場景遠(yuǎn)不止零售。比如運維日志分析里某幾個報錯總是前后腳出現(xiàn)這背后可能指向同一個根因比如內(nèi)容平臺上看了某類視頻的用戶往往接著會看另一類這可以用來做冷啟動推薦再比如制造業(yè)的設(shè)備傳感器告警某些告警組合幾乎必然導(dǎo)致停機(jī)這就是典型的關(guān)聯(lián)模式。所以別把關(guān)聯(lián)規(guī)則局限在購物籃三個字上它是一套通用的共現(xiàn)模式挖掘方法論。那它到底解決什么問題一句話概括從大量事務(wù)數(shù)據(jù)中自動發(fā)現(xiàn)如果出現(xiàn)了A那么很可能也會出現(xiàn)B這類規(guī)則并且給出支持度、置信度、提升度等指標(biāo)讓你判斷這條規(guī)則值不值得信、值不值得用。它解決的是人工拍腦袋找組合效率太低的問題。你不可能靠肉眼從十萬條訂單里看出哪些商品組合有規(guī)律但算法可以。這篇文章我打算按一個完整的實操鏈路來講先講清楚幾個核心指標(biāo)到底怎么算、為什么這么算再講最經(jīng)典的Apriori算法和它為什么慢、FP-Growth怎么救場然后給一套能直接跑的代碼接著重點講參數(shù)怎么調(diào)、結(jié)果怎么篩——這部分是絕大多數(shù)教程不講但實際最要命的最后聊聊我踩過的坑和幾個容易翻車的地方。適合有一定Python基礎(chǔ)、想把這套東西真正用到業(yè)務(wù)里的人純小白也能看懂因為我會盡量用生活化的例子把公式講透。2. 三個核心指標(biāo)支持度、置信度、提升度到底在衡量什么2.1 支持度這個組合到底常不常見支持度Support回答的是一個頻率問題在所有事務(wù)里同時包含A和B的事務(wù)占了多大比例。公式很樸素Support(A→B) 同時包含A和B的事務(wù)數(shù) / 總事務(wù)數(shù)舉個例子假設(shè)一個便利店一天有1000筆訂單其中面包牛奶同時出現(xiàn)的有80筆那這個組合的支持度就是80/1000 8%。它衡量的是這個組合的普遍性。支持度太低說明這個組合太罕見哪怕置信度很高也可能只是偶然沒有推廣價值。這里有個新手特別容易混淆的點支持度既可以指單個項集的支持度也可以指整條規(guī)則的支持度。比如面包這個單項的支持度可能是30%面包牛奶這個二項集的支持度是8%。在Apriori算法里我們通常先設(shè)定一個最小支持度閾值min_support把那些出現(xiàn)頻率太低的項集直接砍掉因為一個低頻項集不可能衍生出高頻的規(guī)則。這個砍枝思想是Apriori能跑起來的關(guān)鍵后面會細(xì)講。提示最小支持度閾值的設(shè)定沒有萬能公式。數(shù)據(jù)集越大閾值應(yīng)該越低。我一般先用0.01到0.05之間試看篩出來的規(guī)則數(shù)量再調(diào)整。如果規(guī)則多到幾千條說明閾值太低如果一條都沒有說明太高。2.2 置信度這條規(guī)則有多可信置信度Confidence回答的是可靠性問題在出現(xiàn)了A的事務(wù)里有多大比例也出現(xiàn)了B。公式是Confidence(A→B) Support(A∪B) / Support(A)還是剛才的例子如果面包單獨出現(xiàn)的支持度是30%300筆面包牛奶的支持度是8%80筆那置信度就是8%/30% ≈ 26.7%。意思是買了面包的人里有大約26.7%也買了牛奶。置信度聽起來很直觀但它有個著名的陷阱如果B本身就是一個超級常見的商品比如礦泉水單獨支持度就有60%那不管A是什么Confidence(A→B)都會很高因為分母小、分子被B的高頻撐起來了。這時候規(guī)則看起來很可信其實毫無意義——買任何東西的人本來就會買礦泉水。這就是為什么光看置信度會翻車必須引入第三個指標(biāo)。2.3 提升度剔除本來就會買的干擾提升度Lift就是來解決上面那個陷阱的。它的公式是Lift(A→B) Confidence(A→B) / Support(B) Support(A∪B) / (Support(A) × Support(B))提升度的含義是在知道A發(fā)生的前提下B發(fā)生的概率相對于B本來發(fā)生的概率提升了多少倍。Lift 1A的出現(xiàn)確實提升了B出現(xiàn)的概率兩者正相關(guān)規(guī)則有價值。Lift 1A和B相互獨立A對B沒有任何影響規(guī)則沒意義。Lift 1A的出現(xiàn)反而抑制了B負(fù)相關(guān)。回到礦泉水那個例子假設(shè)Confidence(面包→礦泉水) 55%而礦泉水本身的支持度是60%那Lift 55%/60% ≈ 0.92小于1。這說明買面包的人買礦泉水的概率其實比普通人還略低一點這條規(guī)則完全是置信度制造的假象。所以我在實際項目里篩規(guī)則第一道硬門檻永遠(yuǎn)是Lift 1通常要求大于1.2甚至1.5才認(rèn)為有實際價值。下面這張表把三個指標(biāo)放在一起對比方便你建立整體認(rèn)知指標(biāo)衡量什么公式判斷標(biāo)準(zhǔn)常見誤區(qū)支持度組合的普遍性P(A∩B)越高越常見設(shè)太高會漏掉長尾規(guī)則置信度規(guī)則可靠性P(A∩B)/P(A)越高越可信被高頻項污染提升度相關(guān)性強(qiáng)度置信度/P(B)1才有正相關(guān)忽略它只看置信度會翻車2.4 為什么必須三個指標(biāo)一起看單獨看任何一個指標(biāo)都會出問題。只看支持度你會得到一堆礦泉水大米這種誰都會買的組合只看置信度你會被高頻項帶偏只看提升度可能選出一個支持度極低、純屬偶然的規(guī)則。所以正確的做法是先用最小支持度砍掉低頻噪聲再用最小置信度保證可靠性最后用提升度1做價值過濾。這三層篩子缺一不可這也是我后面講參數(shù)調(diào)優(yōu)時的核心邏輯。3. Apriori算法那個砍枝思想為什么這么關(guān)鍵3.1 先理解頻繁項集這個概念在講算法之前得先建立一個概念頻繁項集Frequent Itemset。所謂項集就是若干個項的集合比如{面包, 牛奶}是一個二項集{面包, 牛奶, 雞蛋}是一個三項集。如果一個項集的支持度大于等于我們設(shè)定的最小支持度它就是頻繁項集。關(guān)聯(lián)規(guī)則挖掘其實分兩步走第一步找出所有頻繁項集第二步從頻繁項集里生成滿足最小置信度的規(guī)則。第二步相對簡單真正難的是第一步因為項的組合數(shù)量會爆炸。假設(shè)有100種商品理論上可能的項集數(shù)量是2的100次方這個數(shù)字大到宇宙毀滅都算不完。Apriori的貢獻(xiàn)就是用砍枝把這個搜索空間大幅壓縮。3.2 Apriori原理一個項集頻繁它的子集一定也頻繁Apriori的核心是一條聽起來很樸素的定理如果一個項集是頻繁的那么它的所有子集也一定是頻繁的。反過來如果一個項集是非頻繁的那么它的所有超集也一定是非頻繁的。這條定理為什么成立因為一個項集的支持度永遠(yuǎn)不可能超過它任何一個子集的支持度。你想同時包含{面包, 牛奶, 雞蛋}的訂單肯定也同時包含{面包, 牛奶}所以前者的數(shù)量一定小于等于后者。既然{面包, 牛奶}都不夠頻繁那加上雞蛋只會更少更不可能頻繁。這條定理的威力在于它讓我們可以逐層剪枝。先掃描一遍數(shù)據(jù)找出所有頻繁的單項集然后由頻繁單項集兩兩組合生成候選二項集再掃描數(shù)據(jù)驗證哪些二項集真的頻繁接著由頻繁二項集生成候選三項集……每一層都把非頻繁的項集連同它的所有超集一起扔掉搜索空間就被指數(shù)級地壓縮了。3.3 手推一遍Apriori的執(zhí)行過程光講原理太抽象我用一個極簡的例子帶你走一遍。假設(shè)有5筆交易T1: 面包, 牛奶 T2: 面包, 雞蛋 T3: 面包, 牛奶, 雞蛋 T4: 牛奶, 雞蛋 T5: 面包, 牛奶設(shè)最小支持度計數(shù)為2即至少出現(xiàn)2次。第一步統(tǒng)計單項面包出現(xiàn)4次牛奶出現(xiàn)4次雞蛋出現(xiàn)3次全部≥2都是頻繁單項集。第二步生成候選二項集并計數(shù){面包,牛奶}出現(xiàn)3次{面包,雞蛋}出現(xiàn)2次{牛奶,雞蛋}出現(xiàn)3次全部≥2都是頻繁二項集。第三步生成候選三項集{面包,牛奶,雞蛋}出現(xiàn)1次小于2被剪掉。最終頻繁項集就是三個單項集加三個二項集。整個過程只掃描了3遍數(shù)據(jù)。如果不用剪枝光二項集就有C(3,2)3個候選三項集1個雖然這個例子小看不出差距但當(dāng)商品有上千種時剪枝能省下的計算量是天文數(shù)字。3.4 Apriori的致命短板反復(fù)掃描數(shù)據(jù)Apriori最大的問題是它每生成一層候選集就要完整掃描一遍數(shù)據(jù)庫來計數(shù)。如果最長的頻繁項集有k項那就要掃描k遍。對于動輒幾百萬行、幾十個字段的數(shù)據(jù)集每掃一遍都是實打?qū)嵉腎O開銷而且候選集在中間層可能會膨脹得非常大。我早年在一個訂單數(shù)據(jù)集上跑過Apriori數(shù)據(jù)量大概50萬行商品種類3000多最小支持度設(shè)0.005結(jié)果跑了將近20分鐘才出結(jié)果中間內(nèi)存還一度飆到幾個G。那次之后我就開始認(rèn)真研究FP-Growth因為它能從根本上解決反復(fù)掃描這個問題。4. FP-Growth把數(shù)據(jù)壓進(jìn)一棵樹只掃兩遍4.1 FP-Tree的核心思路FP-GrowthFrequent Pattern Growth的思路和Apriori完全不同。它不生成候選集而是把整個數(shù)據(jù)集壓縮成一棵叫FP-Tree的前綴樹結(jié)構(gòu)然后在這棵樹上遞歸地挖掘頻繁項集。整個算法只需要掃描兩遍數(shù)據(jù)第一遍統(tǒng)計每個項的頻次第二遍把每條事務(wù)按頻次排序后插入樹中。這棵樹為什么能壓縮數(shù)據(jù)因為相同前綴的事務(wù)會共享路徑。比如面包,牛奶,雞蛋和面包,牛奶,啤酒這兩條事務(wù)在樹里前兩個節(jié)點是共用的只在第三個節(jié)點分叉。數(shù)據(jù)集里重復(fù)模式越多壓縮效果越好。我見過一些實際數(shù)據(jù)壓縮后內(nèi)存占用只有原始數(shù)據(jù)的幾十分之一。4.2 為什么它比Apriori快這么多關(guān)鍵差異在于Apriori是廣度優(yōu)先、逐層生成候選、反復(fù)掃描FP-Growth是深度優(yōu)先、在樹上遞歸、不生成候選。前者在候選集膨脹時性能斷崖式下跌后者因為數(shù)據(jù)已經(jīng)壓進(jìn)內(nèi)存里的樹挖掘過程基本是純內(nèi)存操作沒有反復(fù)的磁盤IO。不過FP-Growth也不是沒有代價。它需要把整棵樹放進(jìn)內(nèi)存如果數(shù)據(jù)量大到內(nèi)存裝不下就得做分區(qū)處理實現(xiàn)起來更復(fù)雜。所以選型上我的經(jīng)驗是數(shù)據(jù)能裝進(jìn)內(nèi)存、追求速度用FP-Growth數(shù)據(jù)太大或者只需要跑一次、對速度不敏感Apriori也能湊合?，F(xiàn)在主流的庫比如mlxtend兩種都支持切換成本很低。4.3 兩種算法的對比與選型建議維度AprioriFP-Growth掃描次數(shù)每層一次共k次固定2次候選集需要生成可能爆炸不生成內(nèi)存占用較低較高需裝下整棵樹速度慢隨數(shù)據(jù)量急劇下降快通?？煲粋€數(shù)量級實現(xiàn)復(fù)雜度簡單較復(fù)雜適用場景小數(shù)據(jù)、教學(xué)、一次性任務(wù)中等數(shù)據(jù)、需要反復(fù)挖掘我的實際建議很直接只要數(shù)據(jù)量超過幾萬行直接上FP-Growth別在Apriori上浪費時間。除非你是為了理解算法原理做教學(xué)演示否則沒有理由選Apriori。5. 一套能直接跑的完整代碼5.1 環(huán)境準(zhǔn)備與依賴安裝我用的是Python生態(tài)里最順手的mlxtend庫它同時封裝了Apriori和FP-Growth接口統(tǒng)一省得自己造輪子。安裝就一行pip install mlxtend pandas如果你還想做可視化可以再裝個networkx和matplotlib用來畫關(guān)聯(lián)規(guī)則網(wǎng)絡(luò)圖后面會提到。5.2 數(shù)據(jù)準(zhǔn)備從原始記錄到事務(wù)列表關(guān)聯(lián)規(guī)則對數(shù)據(jù)格式有要求每一行是一筆事務(wù)每個事務(wù)是一個項的列表。原始數(shù)據(jù)往往是訂單號-商品這種長表需要先做透視。假設(shè)你有一份CSV字段是order_id和productimport pandas as pd # 讀取原始長表 df pd.read_csv(orders.csv) # 透視成每行一個訂單每列一個商品的0-1矩陣 basket df.groupby(order_id)[product].apply(list).tolist() # 或者用更規(guī)范的獨熱編碼方式 basket_encoded df.pivot_table( indexorder_id, columnsproduct, aggfunclambda x: 1, fill_value0 )這里有個細(xì)節(jié)要注意透視后的矩陣如果商品種類很多會非常稀疏大部分是0內(nèi)存占用可能很大。如果商品超過幾千種建議先用支持度過濾掉低頻商品再做編碼。5.3 用FP-Growth挖掘頻繁項集from mlxtend.frequent_patterns import fpgrowth # 挖掘頻繁項集min_support0.01表示至少1%的訂單包含該項集 frequent_itemsets fpgrowth( basket_encoded, min_support0.01, use_colnamesTrue, max_len3 # 限制項集最大長度避免組合爆炸 ) # 按支持度降序看前20個 print(frequent_itemsets.sort_values(support, ascendingFalse).head(20))max_len這個參數(shù)特別重要。如果不限制算法可能會挖出十幾個項的超長項集這些項集支持度極低、解釋性極差還拖慢速度。我一般限制在2到4之間看業(yè)務(wù)需要。5.4 生成規(guī)則并做第一輪篩選from mlxtend.frequent_patterns import association_rules # 生成規(guī)則min_threshold先設(shè)低一點后面再篩 rules association_rules( frequent_itemsets, metricconfidence, min_threshold0.3 ) # 第一輪篩選提升度大于1.2且支持度不能太低 rules rules[ (rules[lift] 1.2) (rules[support] 0.01) ] # 按提升度排序看結(jié)果 print(rules.sort_values(lift, ascendingFalse)[ [antecedents, consequents, support, confidence, lift] ].head(20))跑完這一步你就能拿到一張規(guī)則表每條規(guī)則都帶著支持度、置信度、提升度三個指標(biāo)。但拿到結(jié)果只是開始真正決定成敗的是下一步——怎么從成百上千條規(guī)則里挑出真正有用的。6. 參數(shù)調(diào)優(yōu)與結(jié)果篩選這一步?jīng)Q定項目成敗6.1 最小支持度怎么定從數(shù)據(jù)規(guī)模倒推最小支持度是影響結(jié)果數(shù)量最敏感的旋鈕。設(shè)得太高長尾的有價值規(guī)則全被砍掉設(shè)得太低規(guī)則多到?jīng)]法看。我的經(jīng)驗做法是先估算你希望一條規(guī)則至少覆蓋多少筆事務(wù)。比如你希望一條規(guī)則至少覆蓋50筆訂單總訂單是1萬筆那min_support就設(shè)0.005。這個從業(yè)務(wù)意義倒推閾值的思路比盲目試數(shù)字靠譜得多。另外支持度閾值和數(shù)據(jù)集大小是反比關(guān)系。1萬行數(shù)據(jù)設(shè)0.01可能剛好100萬行數(shù)據(jù)設(shè)0.01就會篩出海量規(guī)則這時候應(yīng)該降到0.001甚至更低。我一般會先跑一個支持度分布看看數(shù)據(jù)里項集的頻次分布長什么樣再決定閾值。6.2 置信度和提升度的組合篩選策略前面說過置信度會被高頻項污染所以我的篩選順序永遠(yuǎn)是先卡提升度再卡置信度。具體來說提升度 1.2保證正相關(guān)這是硬門檻。置信度 0.5保證規(guī)則足夠可靠。支持度 業(yè)務(wù)最小覆蓋量保證規(guī)則有足夠的樣本支撐。這三個條件同時滿足的規(guī)則通常數(shù)量會從幾千條降到幾十條剩下的基本都是能拿給業(yè)務(wù)方看的。如果還是太多就把提升度門檻提到1.5或者把置信度提到0.6。6.3 怎么判斷一條規(guī)則有沒有業(yè)務(wù)價值指標(biāo)達(dá)標(biāo)不代表有業(yè)務(wù)價值。我判斷一條規(guī)則值不值得用會問三個問題第一這條規(guī)則符不符合常識如果挖出買牙膏的人買牙刷提升度再高也是廢話因為這是常識不需要算法告訴你。真正有價值的是那些反直覺的規(guī)則比如某個冷門配件和某個主產(chǎn)品的強(qiáng)關(guān)聯(lián)。第二這條規(guī)則能不能指導(dǎo)行動如果一條規(guī)則指向的組合你沒法做任何運營動作比如沒法捆綁銷售、沒法做推薦那它再漂亮也只是個數(shù)字。第三這條規(guī)則的樣本量夠不夠支持度0.001意味著只有幾十筆訂單支撐這種規(guī)則很可能是噪聲換個時間段就消失了。我一般要求規(guī)則至少覆蓋幾百筆事務(wù)才敢用。6.4 一個真實的調(diào)參踩坑記錄有次我?guī)鸵粋€內(nèi)容團(tuán)隊做視頻關(guān)聯(lián)分析一開始min_support設(shè)了0.02結(jié)果一條規(guī)則都沒挖出來。我以為是數(shù)據(jù)問題查了半天才發(fā)現(xiàn)是閾值太高——他們的視頻種類有上萬種單個視頻的觀看占比本來就低0.02意味著一個視頻要被2%的用戶看過這幾乎不可能。后來把閾值降到0.001規(guī)則一下就出來了。這個坑的教訓(xùn)是支持度閾值必須和數(shù)據(jù)的項基數(shù)匹配。項的種類越多單項的占比就越低閾值就必須越低。零售場景商品幾千種閾值0.01還行視頻、文章這種內(nèi)容場景動輒幾萬幾十萬項閾值得降到0.001甚至更低。這個規(guī)律我后來總結(jié)成一句話項越多閾值越低沒有例外。7. 那些教程不講的坑我踩過的幾個真實問題7.1 數(shù)據(jù)里的偽關(guān)聯(lián)時間因素被忽略關(guān)聯(lián)規(guī)則只關(guān)心一起出現(xiàn)不關(guān)心先后順序也不關(guān)心時間。這會導(dǎo)致一類隱蔽的偽關(guān)聯(lián)。比如某個促銷活動期間A和B都被大量購買算法會認(rèn)為A和B強(qiáng)關(guān)聯(lián)但實際上它們只是因為促銷才一起出現(xiàn)活動一結(jié)束關(guān)聯(lián)就消失了。解決辦法是做時間切片分析把數(shù)據(jù)按周或按月切分分別挖掘只保留那些在多個時間段都穩(wěn)定出現(xiàn)的規(guī)則。穩(wěn)定出現(xiàn)的才是真關(guān)聯(lián)只在某個時間段出現(xiàn)的很可能是事件驅(qū)動的偽關(guān)聯(lián)。7.2 高頻項的淹沒效應(yīng)前面提過高頻項會污染置信度這里再展開說一個更隱蔽的問題高頻項不僅污染置信度還會淹沒真正有價值的規(guī)則。因為高頻項參與的規(guī)則數(shù)量極多排序時很容易把真正有價值的低頻規(guī)則擠到后面。我的處理辦法是在生成規(guī)則前先把那些支持度超過某個上限比如50%的超級高頻項單獨拎出來要么剔除要么單獨分析。這些項本身太普遍參與任何規(guī)則都會拉高置信度、拉低信息量。7.3 規(guī)則數(shù)量爆炸時怎么收斂當(dāng)數(shù)據(jù)量大、閾值又設(shè)得偏低時規(guī)則數(shù)量可能上萬條人工根本看不過來。這時候有幾個收斂手段限制項集長度max_len只挖2項和3項規(guī)則放棄長規(guī)則。提高提升度門檻比如從1.2提到2.0只留強(qiáng)關(guān)聯(lián)。按前項分組每個前項只保留提升度最高的幾條規(guī)則。做規(guī)則聚類把相似的規(guī)則歸并成一組看組級別的模式。我通常組合使用前三個手段基本能把規(guī)則收斂到可人工審閱的規(guī)模。7.4 結(jié)果的可解釋性別讓業(yè)務(wù)方看不懂技術(shù)人容易犯的一個錯是把frozenset({面包, 牛奶})這種原始輸出直接甩給業(yè)務(wù)方。業(yè)務(wù)方看不懂frozenset也不知道提升度是什么。我的做法是輸出一張人話表格前項、后項、支持度百分比、置信度百分比、提升度再配一句自然語言描述比如購買了面包的顧客中有26.7%也購買了牛奶購買概率是普通顧客的1.5倍。這樣業(yè)務(wù)方一眼就能判斷這條規(guī)則有沒有用。8. 從規(guī)則到行動關(guān)聯(lián)規(guī)則怎么落地8.1 商品捆綁與貨架陳列最經(jīng)典的落地就是捆綁銷售和貨架陳列。把提升度高的商品組合放在一起或者打包成套餐。但這里有個反直覺的點不是所有高提升度組合都適合捆綁。如果兩個商品本來就是互補(bǔ)品比如牙膏和牙刷捆綁效果有限因為顧客本來就會一起買。真正適合捆綁的是那些提升度高但顧客沒意識到的組合用捆綁去提醒他們。8.2 推薦系統(tǒng)的召回層關(guān)聯(lián)規(guī)則在推薦系統(tǒng)里通常用在召回層而不是排序?qū)?。因為?guī)則是硬匹配缺乏個性化。做法是根據(jù)用戶當(dāng)前購物車或瀏覽歷史匹配前項包含這些商品的規(guī)則把后項商品作為候選召回再交給排序模型精排。這樣既利用了關(guān)聯(lián)規(guī)則的強(qiáng)解釋性又彌補(bǔ)了它不夠個性化的短板。8.3 異常檢測與根因分析這個用法比較小眾但很實用。在運維或制造場景把告警組合當(dāng)作事務(wù)來挖關(guān)聯(lián)規(guī)則如果某幾個告警總是同時出現(xiàn)很可能指向同一個根因。提升度特別高的告警組合往往就是需要優(yōu)先排查的對象。我用這個方法幫團(tuán)隊定位過幾次偶發(fā)故障比一個個日志翻效率高多了。8.4 落地時的效果驗證規(guī)則上線后一定要做A/B測試驗證。因為關(guān)聯(lián)規(guī)則是從歷史數(shù)據(jù)挖出來的歷史規(guī)律不一定代表未來有效。我見過挖出來的規(guī)則在測試集上指標(biāo)很漂亮上線后轉(zhuǎn)化率卻沒變化的情況——原因是那些關(guān)聯(lián)本來就是顧客的固有行為你推不推他都會買。所以驗證時要看增量而不是看總量。9. 寫在最后的一點個人體會關(guān)聯(lián)規(guī)則分析這套東西算法本身其實不復(fù)雜Apriori和FP-Growth的原理一兩個小時就能搞明白代碼用mlxtend幾行就能跑通。真正拉開差距的是參數(shù)怎么調(diào)、結(jié)果怎么篩、規(guī)則怎么解釋、落地怎么驗證——這些沒有標(biāo)準(zhǔn)答案全靠一次次踩坑積累。我自己最大的體會是別迷信算法挖出來的結(jié)果要用業(yè)務(wù)常識去交叉驗證。算法能發(fā)現(xiàn)模式但判斷模式有沒有價值還得靠人。那些反直覺又穩(wěn)定、又能指導(dǎo)行動的規(guī)則才是真正值得投入的。至于那些買牙膏的人買牙刷式的規(guī)則讓算法自己留著就好別浪費業(yè)務(wù)方的時間。如果你剛開始做這塊我的建議是先拿一份小數(shù)據(jù)集把整個流程跑通重點體會支持度、置信度、提升度三個指標(biāo)隨參數(shù)變化的感覺。等你能憑經(jīng)驗預(yù)判閾值調(diào)到多少會出多少規(guī)則的時候這套東西就算真正上手了。