最近幾年搜索引擎理念可謂滲入人心，對于互聯(lián)網(wǎng)產(chǎn)品設(shè)計(jì)人員來說，張口必言搜索。同事基于搜索技術(shù)的各種產(chǎn)品也在Web2.0的浪潮下如雨后春筍，刷刷往 外冒。在這些林林總總的產(chǎn)品里面，幾乎都能見到“ tag , 相關(guān)新聞, 相似產(chǎn)品 ” 類推薦鏈接的蹤影。稍加留意這些產(chǎn)品的實(shí)現(xiàn)就可以發(fā)現(xiàn)，大多還是基于關(guān)鍵詞的搜索機(jī)制實(shí)現(xiàn)的。很顯然基于關(guān)鍵詞技術(shù)的相關(guān)推薦是最直觀的，似乎也是最有效 的一種實(shí)現(xiàn)方式，如同機(jī)槍中的AK-47，那他沖鋒陷陣總是屢試不爽。
對于文字類產(chǎn)品的推薦，基于關(guān)鍵詞的實(shí)現(xiàn)方式，目前還是主流；但在電子商務(wù)，智能閱讀推薦，商務(wù)搜索方面單純的關(guān)鍵字相關(guān)性實(shí)現(xiàn)機(jī)制還不那么讓人滿意，這也就有了協(xié)同推薦過濾系統(tǒng)。 Collaborative filtering 。
所謂協(xié)同推薦，很顯然彌補(bǔ)了單純依賴關(guān)鍵詞相關(guān)性的不足，把獲取相關(guān)性數(shù)據(jù)的視角放大到數(shù)據(jù)從產(chǎn)生到消費(fèi)的各個(gè)環(huán)節(jié)。
有2種最基礎(chǔ)類型的協(xié)同推薦系統(tǒng)：
1 基于當(dāng)前活躍用戶 和 上一個(gè)用戶的相似性 來進(jìn)行分析（一般是計(jì)算用戶購買或者感興趣的商品來進(jìn)行）；側(cè)重于用戶
2 基于當(dāng)前用戶選擇（或感興趣）的商品 和 上一個(gè)用戶感興趣的商品的相似性來進(jìn)行分析；
這也就是大家所熟知的 user-based 和item-based協(xié)同推薦。
根據(jù)實(shí)現(xiàn)機(jī)制物理載體劃分，以上兩類協(xié)同推薦系統(tǒng)可以分為：內(nèi)存型 和 模式型的協(xié)同推薦。一般內(nèi)存型的都比較直觀，適合于小型的數(shù)據(jù)集合，而模式型的一般都是利用 機(jī)器學(xué)習(xí)的方法，適用于大規(guī)模的數(shù)據(jù)分析，也可以稱之為離線分析。模式型的是我比較關(guān)心的，因?yàn)樽? 基于SEO的日志分析 ，比較適合。
我們在進(jìn)行協(xié)同分析的時(shí)候，要考慮協(xié)同的意義。一般來說協(xié)同就是指多個(gè)用戶或多個(gè)數(shù)據(jù)項(xiàng)的交叉作用。如果數(shù)據(jù)項(xiàng)較多的情況下，如何定義數(shù)據(jù)項(xiàng)的關(guān)系就是個(gè)重要問題了。
下面說一下協(xié)同系統(tǒng)的設(shè)計(jì)要素吧：
1 數(shù)據(jù)項(xiàng) Item
2 項(xiàng)集合 ItemCollection
3 數(shù)據(jù)項(xiàng)的關(guān)系權(quán)重 DirectedEdge
4 數(shù)據(jù)項(xiàng)在數(shù)據(jù)集合中的存儲(chǔ)方式
具體的算法實(shí)現(xiàn)過程，可以參考： Beyond Search 的 推薦系統(tǒng)：關(guān)聯(lián)規(guī)則(2) 。我這里摘錄如下：
Apriori 是一種廣度優(yōu)先算法，通過多次掃描數(shù)據(jù)庫來獲取支持度大于最小支持度的頻繁項(xiàng)集。它的理論基礎(chǔ)是頻繁項(xiàng)集的兩個(gè)單調(diào)性原則：頻繁項(xiàng)集的任一子集一定是頻繁 的；非頻繁項(xiàng)集的任一超集一定是非頻繁的。晦澀的理論我這里就不多寫了，有興趣的可以去看論文。我把里面的例子給翻譯一下，圖文并茂，簡明易懂。
某數(shù)據(jù)庫 DB 里有 4 條事務(wù)記錄，取最小支持度（min support）為 0.5，則計(jì)算頻繁項(xiàng)集的過程如下：
|
掃描DB |
|
取滿足
最小支持度 項(xiàng)集 |
|
||||||||||||||||||||||||||||||||
|
掃描DB |
|
取滿足
最小支持度 項(xiàng)集 |
|
||||||||||||||||||||||||||||||||
|
掃描DB |
|
取滿足
最小支持度 項(xiàng)集 |
|
如上可以看出，在海量數(shù)據(jù)的情況下，Apriori 算法的運(yùn)算過程有 2 個(gè)問題：
- 需要多次掃描數(shù)據(jù)庫，時(shí)間成本很高；
- 運(yùn)算過程中需要產(chǎn)生大量的候選集，空間成本也非常高。
針對 Apriori 算法所做的 改進(jìn) 也基本上是圍繞著解決這兩個(gè)問題進(jìn)行的，如在掃描DB前首先進(jìn)行以便事務(wù)合并和壓縮，數(shù)據(jù)分區(qū)或抽樣等。
Weka 里有 Apriori 算法的 Java 實(shí)現(xiàn)，非常值得一看。
推薦閱讀： 協(xié)同過濾(Collaborative Filtering)
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號(hào)聯(lián)系： 360901061
您的支持是博主寫作最大的動(dòng)力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
