推薦系統之協同過濾概述

⑴ 基於協同過濾的推薦系統的資料庫在什麼環境平台構建

大體試用了一下三個系統，得出了一個比較粗淺的結論： 1、phpcms： phpcms自2007版本開源以後才開始引起廣泛關注，但這次也是頭一次研究。用了幾天，有了一點初步的印象。（以下以2007版為例，2008版尚未正式推出） 粗看起來，phpcms 2007是三者中最為完善的，各項功能考慮的很細致，導致進了新手進了後台先要暈半天才行。各項功能，比如UNIX系統的許可權、模版修改、廣告、商城、信息、單網頁。。。。都做的相當的完備了。 發表文章的關鍵字、作者、來源、自動遠程圖片保存等等，都做的不錯。但是，phpcms發表文章的摘要，似乎是只能自動截取，不能手工設置，靈活性欠佳。 發表的文章可以通過關鍵字來索引相關貼，做的不錯。 支持通行證方式進行論壇和其它系統的整合，可以進行正向和反向兩種方式的整合。但是文檔說的不太清楚，研究了半天才成功。但是反向整合pw5.0.1登錄後自動跳轉不回來。 phpcms 2007的後台安排的太瑣碎，看的頭暈。發一篇文章也要暈半個鍾頭，而且首頁的更新莫不清規律，幻燈片老半天不更新。 phcms盡管功能很強大，但是卻缺少一樣重要的東西：可視化的模版工具，這也是php168和dedecms共同的缺點。在這方面，他們甚至不如剛剛起步的DiyPage好，DiyPage只是一個剛剛具備了雛形的CMS系統，卻擁有一個很方便的後台可視化界面設計工具，即使是菜鳥也可以輕松設計界面（雖然靈活性沒那麼強大，但是足夠你用了）。 phpcms 2007整體以頻道為依據進行組織，即使你不想用頻道，哪也得用，這個已經由不了你了 。所以如果僅僅是一個比較簡單的網站，也用上一個頻道，看起來夠別扭的，這是phpcms 2007最大的缺點，不過看了phpcms 2008beta2發現，phpcms終於解除了這個垃圾限制。 發現phpcms的廣告功能似乎不完善，一個廣告位定義了兩個廣告，不能自動輪換，總是顯示第一個。 phpcms雖然實現了模塊化，但是不管你用不用，一大堆模塊稀里呼嚕就裝上了，看起來很不爽，也不直觀。 phpcms雖然是很早就是商業化運作的軟體，然後開發效率卻是不高，新版本屢屢跳票，影響了它的產品形象，讓開源以來積累的人氣和一些擁躉大失所望。然而最近貼上了六間房以後，資金應該是沒有壓力了，新版本也開始浮出水面，2008beta1已經發布了，可惜問題多多。 phpcms 2008 beta2 在 MySQL4 上還是有使用問題，不過比beta1強一些，beta1直接就安裝不了，不知道正式版是否會正式放棄MySQL4。 phpcms 2008beta2看上去不錯，新功能令人振奮的，界面清爽。以前一團亂麻的後台界面已經打掃干凈了。phpcms 2008的標簽採用了中英文混合的方式，對菜鳥來說更加容易上手，比較新穎。另外，beta2好像是實現了類似php168的可視化模版中的標簽設置方式，雖然不是可視化的設計模版，總歸可以自定義一些元素樣式了。不過這個beta2版也還是頂多算是個預覽版，BUG極多，功能不全。如果准備用phpcms的話，怕是還要大大的等幾天才行。 另外，phpcms官方論壇對免費版的支持很不到位，傷了很多粉絲的心。 2、dedecms 5.1應該是dedecms正式商業化運作以後推出的第一個版本吧？以前的dedecms個體作坊式的發展，由於作者兼職時間和精力不足，導致發展緩慢，新版本頻頻跳票，引起廣大粉絲的強烈不滿，甚至導致柏拉圖和dedecms用家之間的語言沖突。然而dedecms在商業化運作以後，新版本的發布周期大大縮短，產品功能不斷改進，界面美化了很多，人氣和用戶數量大大增長了，現在看發展勢頭不錯。 dedecms的根目錄是最簡單的，只有幾個文件，比以上兩個都強多了，其實這樣不僅看起來清爽，維護起來也方便，值得表揚 dedecms的頻道非常費解，看起來只有頻道模型，要增加頻道就要添加模版文件有點費解，仔細研究發現，這個dedecms其實和php168的方式差不多，任何欄目都可以添加子目錄，綁定域名，其實就和頻道是一個意思，欄目和頻道可以互相轉換。 dedecms的通行證只支持反向整合，就是dedecms可以用服務端的用戶數據登錄。其實所謂整合，一般也就是這樣的。論壇用整站用戶數據的情況恐怕極為少見，對論壇管理也不利。 但是dedecms的通行證整合，需要修改論壇文件，不明白為啥要這樣，是因為論壇的通行證功能還不完善嗎？ dedecms的廣告管理用起來比較麻煩，要先定義標簽，然後手工在模板中插入。好像模版上沒預定義好廣告位置，實在是太不應該了。。。。相當於手動操作，不符合當今歷史潮流啊。而且大家常用的廣告自動輪換功能，也沒有實現。 試用發現，dedecms有時還有一些小毛病，比如遠程附件功能，有時發現無法自動轉存到本地。另外，在模塊數量上，dedecms也無法和php168和phpcms相比，只有文章、下載、圖片、Flash等基本的功能，不知道dedecms 2007發布以後能否有所改觀 dedecms的相關文章、熱點文章等功能，用了靜態生成的方式直接寫入到了HTML文件中，這樣在生成HTML後，無法自動更新，需要經常手工重新生成全部HTML才能更新相關文檔和熱點文檔。但是大量的重復生成所有HTML文件效率太低下了，這方面dedecms不如php168最新添加的相關文章功能，是用JS方式實現的，不需要更新HTML就能自動索取最新的相關文章。但是使用JS方式也存在伺服器效率的問題。 dedecms的首頁、列表頁、還有文章頁都使用了單獨的模板，沒有使用header和footer模板，這樣的好處是可以產生各種風格的頁面（允許首頁、列表頁、內容頁使用不同的風格），但是缺點是修改添加頭部和底部廣告、導航條的時候，相當費勁，要一個一個模板的修改。而且dedecms的版權聲明欄位設置太小，只有250位元組，寫不進去多少內容，頂多能添加個計數器就不錯了。 dedecms起步就用了類似XML標簽方式，而且官方還提供了Dreamweaver的插件來識別標簽，應該說在國內是比較獨到的。但是這種方式也需要新手一定的時間才能適應。同時，dedecms一直缺乏比較完善的文檔，也進一步加大了菜鳥上手的難度。 dedecms最大的問題就是沒有提供類似Diypage的可視化設計方式，因為標簽比較難於上手，對新手來說做模板是很頭疼的問題。 dedecms 5.1比4.0功能有了很多進步，增加DIGG功能，還有類似分類信息之類的功能都實現了。不過也有退步，比如關鍵詞、相關帖功能都嚴重退步了，發帖也很不方便，而且dedecms在商業版本和免費版本之間做功能和代碼區分，也自然會在免費版本上有所縮水。 dedecms商業化發展以後，目前出現的問題是免費版的技術支持做的不太到位，比phpcms強不了多少

⑵ 個性化推薦演算法——協同過濾

有三種：協同過濾
用戶歷史行為
物品相似矩陣

⑶ 協同過濾，基於內容推薦有什麼區別

舉個簡單的小例子，我們已知道
用戶u1喜歡的電影是A，B，C
用戶u2喜歡的電影是A, C, E, F
用戶u3喜歡的電影是B，D
我們需要解決的問題是：決定對u1是不是應該推薦F這部電影
基於內容的做法：要分析F的特徵和u1所喜歡的A、B、C的特徵，需要知道的信息是A（戰爭片），B（戰爭片），C（劇情片），如果F（戰爭片），那麼F很大程度上可以推薦給u1，這是基於內容的做法，你需要對item進行特徵建立和建模。
協同過濾的辦法：那麼你完全可以忽略item的建模，因為這種辦法的決策是依賴user和item之間的關系，也就是這里的用戶和電影之間的關系。我們不再需要知道ABCF哪些是戰爭片，哪些是劇情片，我們只需要知道用戶u1和u2按照item向量表示，他們的相似度比較高，那麼我們可以把u2所喜歡的F這部影片推薦給u1。
根據數據源的不同推薦引擎可以分為三類
1、基於人口的統計學推薦(Demographic-based Recommendation)
2、基於內容的推薦(Content-based Recommendation)
3、基於協同過濾的推薦(Collaborative Filtering-based Recommendation)
基於內容的推薦：
根據物品或內容的元數據，發現物品或內容的相關性，然後基於用戶以前的喜好記錄推薦給用戶相似的物品
基於內容推薦的一個典型的例子，電影推薦系統，首先我們需要對電影的元數據有一個建模，這里只簡單的描述了一下電影的類型；然後通過電影的元數據發現電影間的相似度，因為類型都是「愛情，浪漫」電影 A 和 C 被認為是相似的電影（當然，只根據類型是不夠的，要得到更好的推薦，我們還可以考慮電影的導演，演員等等）；最後實現推薦，對於用戶 A，他喜歡看電影 A，那麼系統就可以給他推薦類似的電影 C。

⑷ 協同過濾的演算法簡介

電子商務推薦系統的一種主要演算法。
協同過濾推薦（Collaborative Filtering recommendation）是在信息過濾和信息系統中正迅速成為一項很受歡迎的技術。與傳統的基於內容過濾直接分析內容進行推薦不同，協同過濾分析用戶興趣，在用戶群中找到指定用戶的相似（興趣）用戶，綜合這些相似用戶對某一信息的評價，形成系統對該指定用戶對此信息的喜好程度預測。
與傳統文本過濾相比，協同過濾有下列優點:
（1）能夠過濾難以進行機器自動基於內容分析的信息。如藝術品、音樂;
（2）能夠基於一些復雜的，難以表達的概念（信息質量、品位)進行過濾;
（3）推薦的新穎性。
正因為如此，協同過濾在商業應用上也取得了不錯的成績。Amazon，CDNow，MovieFinder，都採用了協同過濾的技術來提高服務質量。
缺點是:
（1）用戶對商品的評價非常稀疏，這樣基於用戶的評價所得到的用戶間的相似性可能不準確（即稀疏性問題）;
（2）隨著用戶和商品的增多，系統的性能會越來越低;
（3）如果從來沒有用戶對某一商品加以評價，則這個商品就不可能被推薦（即最初評價問題）。
因此，現在的電子商務推薦系統都採用了幾種技術相結合的推薦技術。
案例: AMAZON個性化推薦系統先驅 (基於協同過濾)
AMAZON是一個虛擬的網上書店，它沒有自己的店面，而是在網上進行在線銷售。它提供了高質量的綜合節目資料庫和檢索系統，用戶可以在網上查詢有關圖書的信息。如果用戶需要購買的話，可以把選擇的書放在虛擬購書籃中，最後查看購書籃中的商品，選擇合適的服務方式並且提交訂單，這樣讀者所選購的書在幾天後就可以送到家。
AMAZON書店還提供先進的個性化推薦功能，能為不同興趣偏好的用戶自動推薦盡量符合其興趣需要的書籍。 AMAZON使用推薦軟體對讀者曾經購買過的書以及該讀者對其他書的評價進行分析後，將向讀者推薦他可能喜歡的新書，只要滑鼠點一下，就可以買到該書；AMAZON能對顧客購買過的東西進行自動分析，然後因人而異的提出合適的建議。讀者的信息將被再次保存，這樣顧客下次來時就能更容易的買到想要的書。此外，完善的售後服務也是AMAZON的優勢，讀者可以在拿到書籍的30天內，將完好無損的書和音樂光碟退回AMAZON，AMAZON將原價退款。當然AMAZON的成功還不止於此，如果一位顧客在AMAZON購買一本書，下次他再次訪問時，映入眼簾的首先是這位顧客的名字和歡迎的字樣。

⑸ 求基於用戶協同過濾推薦系統的MATLAB代碼！~急用

??哥們 你也是研究協同過濾的？ 可以相互探討下

⑹ 誰有基於用戶的推薦系統或者協同過濾的演算法和代碼分析

個大數據的大神給個 基於用戶的推薦系統或者協同過濾的演算法和代碼分析啊
我有部分代碼但是不知道怎麼在Eclipse上實現 求解答啊
1.public class AggregateAndRecommendRecer extends Recer<VarLongWritable,VectorWritable,VarLongWritable,RecommendedItemsWritable>{
...
public viod rece (VarLongWritable key,Iterable<VectorWritable>values,Context context)throws IOException,InterruptedException{
Vector recommendationVector=null;
for(VectorWritable vectorWritable:values){
recommendationVector=recommendationVector==null?
vectorWritable.get();
recommendationVector.plus(bectorWritable.get());
}
Queue<RecommendedItem> topItems=new PriorityQueue<RecommendedItem>(recommendationsPerUser+1,Collections.reverseOrder(.getInstance()));
Iterator<Vector.Element> recommendationVectorIterator=recommendationVector.iterateNonZero();
while(recommendationVectorIterator.hasNext()){
vector.Element element=recommendationVectorIterator.next();
int index=element.index();

⑺ 協同過濾推薦系統的應用領域有哪些

豆瓣，amazon，淘寶，當當等網站都在用，豆瓣的猜你喜歡，音樂推薦，書籍推薦什麼的都是，推薦你看看兩篇文章，探索推薦引擎內部的秘密，第1 部分: 推薦引擎初探 探索推薦引擎內部的秘密，第2 部分: 深入推薦引擎相關演算法- 協同過濾，看完就基本了解了，http://www.ibm.com/search/csass/search/?sn=dw&lang=zh&cc=CN&en=utf&hpp=20&dws=cndw&lo=zh&q=%E6%8E%A2%E7%B4%A2%E6%8E%A8%E8%8D%90%E5%BC%95%E6%93%8E%E5%86%85%E9%83%A8%E7%9A%84%E7%A7%98%E5%AF%86

⑻ 協同過濾和基於內容推薦有什麼區別

舉個簡單的小例子，我們已知道
用戶u1喜歡的電影是A，B，C
用戶u2喜歡的電影是A, C, E, F
用戶u3喜歡的電影是B，D
我們需要解決的問題是：決定對u1是不是應該推薦F這部電影
基於內容的做法：要分析F的特徵和u1所喜歡的A、B、C的特徵，需要知道的信息是A（戰爭片），B（戰爭片），C（劇情片），如果F（戰爭片），那麼F很大程度上可以推薦給u1，這是基於內容的做法，你需要對item進行特徵建立和建模。
協同過濾的辦法：那麼你完全可以忽略item的建模，因為這種辦法的決策是依賴user和item之間的關系，也就是這里的用戶和電影之間的關系。我們不再需要知道ABCF哪些是戰爭片，哪些是劇情片，我們只需要知道用戶u1和u2按照item向量表示，他們的相似度比較高，那麼我們可以把u2所喜歡的F這部影片推薦給u1。
根據數據源的不同推薦引擎可以分為三類
1、基於人口的統計學推薦(Demographic-based Recommendation)
2、基於內容的推薦(Content-based Recommendation)
3、基於協同過濾的推薦(Collaborative Filtering-based Recommendation)
基於內容的推薦：
根據物品或內容的元數據，發現物品或內容的相關性，然後基於用戶以前的喜好記錄推薦給用戶相似的物品
基於內容推薦的一個典型的例子，電影推薦系統，首先我們需要對電影的元數據有一個建模，這里只簡單的描述了一下電影的類型；然後通過電影的元數據發現電影間的相似度，因為類型都是「愛情，浪漫」電影 A 和 C 被認為是相似的電影（當然，只根據類型是不夠的，要得到更好的推薦，我們還可以考慮電影的導演，演員等等）；最後實現推薦，對於用戶 A，他喜歡看電影 A，那麼系統就可以給他推薦類似的電影 C。

⑼ 計算機推薦系統可以分為三類：協同過濾、混合推薦系統還有一個是什麼

基於標簽(Tag)