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