java協同過濾演算法

1. 推薦演算法的基於協同過濾的推薦

基於協同過濾的推薦演算法理論上可以推薦世界上的任何一種東西。圖片、音樂、樣樣可以。 協同過濾演算法主要是通過對未評分項進行評分 預測來實現的。不同的協同過濾之間也有很大的不同。
基於用戶的協同過濾演算法: 基於一個這樣的假設「跟你喜好相似的人喜歡的東西你也很有可能喜歡。」所以基於用戶的協同過濾主要的任務就是找出用戶的最近鄰居，從而根據最近鄰 居的喜好做出未知項的評分預測。這種演算法主要分為3個步驟：
一，用戶評分。可以分為顯性評分和隱形評分兩種。顯性評分就是直接給項目評分（例如給網路里的用戶評分），隱形評分就是通過評價或是購買的行為給項目評分 （例如在有啊購買了什麼東西）。
二，尋找最近鄰居。這一步就是尋找與你距離最近的用戶，測算距離一般採用以下三種演算法：1.皮爾森相關系數。2.餘弦相似性。3調整餘弦相似性。調整餘弦 相似性似乎效果會好一些。
三，推薦。產生了最近鄰居集合後，就根據這個集合對未知項進行評分預測。把評分最高的N個項推薦給用戶。 這種演算法存在性能上的瓶頸，當用戶數越來越多的時候，尋找最近鄰居的復雜度也會大幅度的增長。
因而這種演算法無法滿足及時推薦的要求。基於項的協同過濾解決了這個問題。 基於項的協同過濾演算法 根基於用戶的演算法相似，只不過第二步改為計算項之間的相似度。由於項之間的相似度比較穩定可以在線下進行，所以解決了基於用戶的協同過濾演算法存在的性能瓶頸。

2. Spark 推薦演算法-協同過濾-java的語句意思

協同過濾(Collaborative Filtering)的基本概念就是把這種方式變成自動化的流程

協同過濾主要是以屬性或興趣相近的用戶經驗與建議作為提供個性化的基礎。透過協同過濾，有助於搜集具有類似偏好或屬性的用戶，並將其意見提供給同一集群中的用戶作為參考，以滿足人們通常在決策之前參考他人意見的心態。

本人認為，協同過濾技術應包括如下幾方面:(1)一種比對和搜集每個用戶興趣偏好的過程;(2)它需要許多用戶的信息去預測個人的興趣偏好;(3)通過對用戶之間興趣偏好相關程度的統計去發展建議那些有相同興趣偏好的用戶。

3. java,我有一個資料庫表userid,bookid,score,用這個表用協同過濾演算法找到愛好相似的用戶

//皮爾遜相關系數分析
//介於-1到1之間。相關系數越接近與1，說明兩個人越相似。
//你先參考下這個雖然裡面只有Python的代碼：

//我用java去做一下試試

importjava.util.*;

publicclassTest{

publicstaticvoidmain(String[]args){
Map<String,HashMap<String,Double>>cri=newHashMap<String,HashMap<String,Double>>();
//模擬資料庫中的數據，實際運用時請靈活變動
getData(cri);
System.out.println(cri.get("Gene").get("LadyintheWater"));
//獲得評價值
System.out.println(getSim(cri,"Gene","Lisa"));
}

//模擬資料庫中的數據
publicstaticvoidgetData(Map<String,HashMap<String,Double>>cri){
HashMap<String,Double>temp=newHashMap<String,Double>();
temp.put("LadyintheWater",2.5);
temp.put("SnakesonaPlane",3.5);
temp.put("JustMyLuck",3.0);
temp.put("SupermanReturns",3.5);
temp.put("You,MeandDupree",2.5);
temp.put("TheNightListener",3.0);
cri.put("Lisa",temp);
HashMap<String,Double>temp1=newHashMap<String,Double>();
temp1.put("LadyintheWater",3.0);
temp1.put("SnakesonaPlane",3.5);
temp1.put("JustMyLuck",1.5);
temp1.put("SupermanReturns",5.0);
temp1.put("You,MeandDupree",3.5);
temp1.put("TheNightListener",3.0);
cri.put("Gene",temp1);
}

publicstaticdoublegetSim(Map<String,HashMap<String,Double>>cri,Stringp1,Stringp2){
HashMap<String,Double>p1m=cri.get(p1);
HashMap<String,Double>p2m=cri.get(p2);

List<String>simBook=newArrayList<String>();
for(Map.Entry<String,Double>entry:p1m.entrySet()){
if(p2m.containsKey(entry.getKey())){
simBook.add(entry.getKey());
}
}
//判斷相同元素的個數
if(simBook.size()==0){
return1;
}
//對所有偏好求和
doublesum1=0d,sum2=0d;
//求平方和
doublesum1Sq=0d,sum2Sq=0d;
//求乘積和
doublepSum=0d;
for(Strings:simBook){
sum1+=p1m.get(s);
sum2+=p2m.get(s);

sum1Sq+=Math.pow(p1m.get(s),2);
sum2Sq+=Math.pow(p2m.get(s),2);

pSum+=p1m.get(s)*p2m.get(s);
}

//計算皮爾遜評價值
doublenum=pSum-(sum1*sum2/simBook.size());
doubleden=Math.sqrt((sum1Sq-Math.pow(sum1,2)/simBook.size())*(sum2Sq-Math.pow(sum2,2)/simBook.size()));

if(den==0){
return0;
}

returnnum/den;
}

}

4. 我想用協同過濾的演算法寫了一個java語言的圖書推薦系統.能跟我講一下大概要怎麼做嗎.有點沒頭緒

針對完全沒有編程經驗的初學者，java入門沒什麼特別好的書，找點視頻看看吧，跟著視頻敲代碼，慢慢就能看懂書了。

----------------------如果堅持要看書的話可以考慮以下----------------------
1. head first java
通俗易懂，重點突出的書，比較薄，適合初學者快速入門，缺點是編輯自以為幽默的加了很多不相乾的段子在裡面，廢話太多。

2. Java A beginner's guide by Herbert Schildt
相比head first java，沒有廢話，語言精煉。

3. 官方的tutorial
免費的，在線閱讀的，也不錯。

4. 瘋狂java講義
如果英文不夠好的話，可以考慮用這本書入門，中文世界裡寫的比較好的

5. Introction to java programming by Y. Daniel Liang
梁勇這本書比較厚，講演算法比較多，如果你時間充足的話可以用這本書入門。

----------------------！！一定要避開這兩個大坑！！----------------------
很多人推薦的core java 和 Thinking in java 其實並不適合初學者(沒有編程經驗的)。
1. core java內容太多太雜，沒有突出重點，並且結構組織的像本字典，適合入門了以後用來系統復習。
2. Thinking in java 沒有編程經驗根本看不懂，過幾年再看吧，不看也沒關系。

5. 協同過濾的演算法細分

這是最早應用協同過濾系統的設計，主要是解決Xerox公司在Palo Alto的研究中心資訊過載的問題。這個研究中心的員工每天會收到非常多的電子郵件卻無從篩選分類，於是研究中心便發展這項實驗性的郵件系統來幫助員工解決這項問題。 其運作機制大致如下：
個人決定自己的感興趣的郵件類型；個人旋即隨機發出一項資訊需求，可預測的結果是會收到非常多相關的文件；從這些文件中個人選出至少三筆資料是其認為有用、會想要看的；系統便將之記錄起來成為個人郵件系統內的過濾器，從此以後經過過濾的文件會最先送達信箱；以上是協同過濾最早的應用，接下來的里程碑為GroupLens。 這個系統主要是應用在新聞的篩選上，幫助新聞的閱聽者過濾其感興趣的新聞內容，閱聽者看過內容後給一個評比的分數，系統會將分數記錄起來以備未來參考之用，假設前提是閱聽者以前感興趣的東西在未來也會有興趣閱聽，若閱聽者不願揭露自己的身分也可以匿名進行評分。 和Tapestry不同之處有兩點，首先，Tapestry專指一個點（如一個網站內、一個系統內）的過濾機制；GroupLens則是跨點跨系統的新聞過濾機制。再來，Tapestry不會將同一筆資料的評比總和起來；GroupLens會將同一筆資料從不同使用者得到的評比加總。
GroupLens具有以下特點：開放性：所有的新聞閱聽者皆可使用，雖然系統委託Better Bit Bureau設計給分的系統，但若有不同的評分機制也適用於GroupLens。方便性：給分並不是一件困難的事情且溝通上非常方便，評分結果容易詮釋。規模性：有可能發展成大規模的系統，一旦發展成大規模，儲存空間與計算成本問題顯得相當棘手。隱密性：如果使用者不想讓別人知道他是誰，別人就不會知道。由此可以看出，現今網路各個推薦系統的雛形已然形成，在GroupLens之後還有性質相近的MovieLens，電影推薦系統；Ringo，音樂推薦系統；Video Recommender，影音推薦系統；以及Jster，笑話推薦系統等等。乃至於今日的YouTube、aNobii皆是相似性值得網路推薦平台，較不同的是經過時間推移，網路越來越發達，使用者越來越多，系統也發展得越來越嚴密。 最著名的電子商務推薦系統應屬亞馬遜網路書店，顧客選擇一本自己感興趣的書籍，馬上會在底下看到一行「Customer Who Bought This Item Also Bought」，亞馬遜是在「對同樣一本書有興趣的讀者們興趣在某種程度上相近」的假設前提下提供這樣的推薦，此舉也成為亞馬遜網路書店為人所津津樂道的一項服務，各網路書店也跟進做這樣的推薦服務如台灣的博客來網路書店。 另外一個著名的例子是Facebook的廣告，系統根據個人資料、周遭朋友感興趣的廣告等等對個人提供廣告推銷，也是一項協同過濾重要的里程碑，和前二者Tapestry、GroupLens不同的是在這里雖然商業氣息濃厚同時還是帶給使用者很大的方便。 以上為三項協同過濾發展上重要的里程碑，從早期單一系統內的郵件、文件過濾，到跨系統的新聞、電影、音樂過濾，乃至於今日橫行互聯網的電子商務，雖然目的不太相同，但帶給使用者的方便是大家都不能否定的。

6. 協同過濾java用什麼實現

眾所周知，java在處理數據量比較大的時候，載入到內存必然會導致內存溢出，而在一些數據處理中我們不得不去處理海量數據，在做數據處理中，我們常見的手段是分解，壓縮，並行，臨時文件等方法;例如，我們要將資料庫(不論是什麼資料庫)的數據導出到一個文件，一般是Excel或文本格式的CSV;對於Excel來講，對於POI和JXL的介面，你很多時候沒有法去控制內存什麼時候向磁碟寫入，很惡心，而且這些API在內存構造的對象大小將比數據原有的大小要大很多倍數，所以你不得不去拆分Excel，還好，POI開始意識到這個問題，在3.8.4的版本後，開始提供cache的行數，提供了SXSSFWorkbook的介面，可以設置在內存中的行數，不過可惜的是，他當你超過這個行數，每添加一行，它就將相對行數前面的一行寫入磁碟(如你設置2000行的話，當你寫第20001行的時候，他會將第一行寫入磁碟)，其實這個時候他些的臨時文件，以至於不消耗內存，不過這樣你會發現，刷磁碟的頻率會非常高，我們的確不想這樣，因為我們想讓他達到一個范圍一次性將數據刷如磁碟，比如一次刷1M之類的做法，可惜現在還沒有這種API，很痛苦，我自己做過測試，通過寫小的Excel比使用目前提供刷磁碟的API來寫大文件，效率要高一些，而且這樣如果訪問的人稍微多一些磁碟IO可能會扛不住，因為IO資源是非常有限的，所以還是拆文件才是上策;而當我們寫CSV，也就是文本類型的文件，我們很多時候是可以自己控制的，不過你不要用CSV自己提供的API，也是不太可控的，CSV本身就是文本文件，你按照文本格式寫入即可被CSV識別出來;如何寫入呢？下面來說說。。。在處理數據層面，如從資料庫中讀取數據，生成本地文件，寫代碼為了方便，我們未必要1M怎麼來處理，這個交給底層的驅動程序去拆分，對於我們的程序來講我們認為它是連續寫即可;我們比如想將一個1000W數據的資料庫表，導出到文件;此時，你要麼進行分頁，oracle當然用三層包裝即可，mysql用limit，不過分頁每次都會新的查詢，而且隨著翻頁，會越來越慢，其實我們想拿到一個句柄，然後向下游動，編譯一部分數據(如10000行)將寫文件一次(寫文件細節不多說了，這個是最基本的)，需要注意的時候每次buffer的數據，在用outputstream寫入的時候，最好flush一下，將緩沖區清空下;接下來，執行一個沒有where條件的SQL，會不會將內存撐爆？是的，這個問題我們值得去思考下，通過API發現可以對SQL進行一些操作，例如，通過：PreparedStatementstatement=connection.prepareStatement(sql)，這是默認得到的預編譯，還可以通過設置：PreparedStatementstatement=connection.prepareStatement(sql，ResultSet.TYPE_FORWARD_ONLY，ResultSet.CONCUR_READ_ONLY);來設置游標的方式，以至於游標不是將數據直接cache到本地內存，然後通過設置statement.setFetchSize(200);設置游標每次遍歷的大小;OK，這個其實我用過，oracle用了和沒用沒區別，因為oracle的jdbcAPI默認就是不會將數據cache到java的內存中的，而mysql里頭設置根本無效，我上面說了一堆廢話，呵呵，我只是想說，java提供的標准API也未必有效，很多時候要看廠商的實現機制，還有這個設置是很多網上說有效的，但是這純屬抄襲;對於oracle上面說了不用關心，他本身就不是cache到內存，所以java內存不會導致什麼問題，如果是mysql，首先必須使用5以上的版本，然後在連接參數上加上useCursorFetch=true這個參數，至於游標大小可以通過連接參數上加上：defaultFetchSize=1000來設置，例如：jdbc：mysql：//xxx.xxx.xxx.xxx：3306/abc？zeroDateTimeconvertToNull&useCursorFetch=true&defaultFetchSize=1000上次被這個問題糾結了很久(mysql的數據老導致程序內存膨脹，並行2個直接系統就宕了)，還去看了很多源碼才發現奇跡竟然在這里，最後經過mysql文檔的確認，然後進行測試，並行多個，而且數據量都是500W以上的，都不會導致內存膨脹，GC一切正常，這個問題終於完結了。我們再聊聊其他的，數據拆分和合並，當數據文件多的時候我們想合並，當文件太大想要拆分，合並和拆分的過程也會遇到類似的問題，還好，這個在我們可控制的范圍內，如果文件中的數據最終是可以組織的，那麼在拆分和合並的時候，此時就不要按照數據邏輯行數來做了，因為行數最終你需要解釋數據本身來判定，但是只是做拆分是沒有必要的，你需要的是做二進制處理，在這個二進制處理過程，你要注意了，和平時read文件不要使用一樣的方式，平時大多對一個文件讀取只是用一次read操作，如果對於大文件內存肯定直接掛掉了，不用多說，你此時因該每次讀取一個可控范圍的數據，read方法提供了重載的offset和length的范圍，這個在循環過程中自己可以計算出來，寫入大文件和上面一樣，不要讀取到一定程序就要通過寫入流flush到磁碟;其實對於小數據量的處理在現代的NIO技術的中也有用到，例如多個終端同時請求一個大文件下載，例如視頻下載吧，在常規的情況下，如果用java的容器來處理，一般會發生兩種情況：其一為內存溢出，因為每個請求都要載入一個文件大小的內存甚至於，因為java包裝的時候會產生很多其他的內存開銷，如果使用二進制會產生得少一些，而且在經過輸入輸出流的過程中還會經歷幾次內存拷貝，當然如果有你類似nginx之類的中間件，那麼你可以通過send_file模式發送出去，但是如果你要用程序來處理的時候，內存除非你足夠大，但是java內存再大也會有GC的時候，如果你內存真的很大，GC的時候死定了，當然這個地方也可以考慮自己通過直接內存的調用和釋放來實現，不過要求剩餘的物理內存也足夠大才行，那麼足夠大是多大呢？這個不好說，要看文件本身的大小和訪問的頻率;其二為假如內存足夠大，無限制大，那麼此時的限制就是線程，傳統的IO模型是線程是一個請求一個線程，這個線程從主線程從線程池中分配後，就開始工作，經過你的Context包裝、Filter、攔截器、業務代碼各個層次和業務邏輯、訪問資料庫、訪問文件、渲染結果等等，其實整個過程線程都是被掛住的，所以這部分資源非常有限，而且如果是大文件操作是屬於IO密集型的操作，大量的CPU時間是空餘的，方法最直接當然是增加線程數來控制，當然內存足夠大也有足夠的空間來申請線程池，不過一般來講一個進程的線程池一般會受到限制也不建議太多的，而在有限的系統資源下，要提高性能，我們開始有了newIO技術，也就是NIO技術，新版的裡面又有了AIO技術，NIO只能算是非同步IO，但是在中間讀寫過程仍然是阻塞的(也就是在真正的讀寫過程，但是不會去關心中途的響應)，還未做到真正的非同步IO，在監聽connect的時候他是不需要很多線程參與的，有單獨的線程去處理，連接也又傳統的socket變成了selector，對於不需要進行數據處理的是無需分配線程處理的;而AIO通過了一種所謂的回調注冊來完成，當然還需要OS的支持，當會掉的時候會去分配線程，目前還不是很成熟，性能最多和NIO吃平，不過隨著技術發展，AIO必然會超越NIO，目前谷歌V8虛擬機引擎所驅動的node.js就是類似的模式，有關這種技術不是本文的說明重點;將上面兩者結合起來就是要解決大文件，還要並行度，最土的方法是將文件每次請求的大小降低到一定程度，如8K(這個大小是經過測試後網路傳輸較為適宜的大小，本地讀取文件並不需要這么小)，如果再做深入一些，可以做一定程度的cache，將多個請求的一樣的文件，cache在內存或分布式緩存中，你不用將整個文件cache在內存中，將近期使用的cache幾秒左右即可，或你可以採用一些熱點的演算法來配合;類似迅雷下載的斷點傳送中(不過迅雷的網路協議不太一樣)，它在處理下載數據的時候未必是連續的，只要最終能合並即可，在伺服器端可以反過來，誰正好需要這塊的數據，就給它就可以;才用NIO後，可以支持很大的連接和並發，本地通過NIO做socket連接測試，100個終端同時請求一個線程的伺服器，正常的WEB應用是第一個文件沒有發送完成，第二個請求要麼等待，要麼超時，要麼直接拒絕得不到連接，改成NIO後此時100個請求都能連接上伺服器端，服務端只需要1個線程來處理數據就可以，將很多數據傳遞給這些連接請求資源，每次讀取一部分數據傳遞出去，不過可以計算的是，在總體長連接傳輸過程中總體效率並不會提升，只是相對相應和所開銷的內存得到量化控制，這就是技術的魅力，也許不要太多的演算法，不過你得懂他。類似的數據處理還有很多，有些時候還會將就效率問題，比如在HBase的文件拆分和合並過程中，要不影響線上業務是比較難的事情，很多問題值得我們去研究場景，因為不同的場景有不同的方法去解決，但是大同小異，明白思想和方法，明白內存和體系架構，明白你所面臨的是沈陽的場景，只是細節上改變可以帶來驚人的效果。

7. 協同過濾演算法

用戶行為數據在網站上最簡單的存在形式就是日誌，比如用戶在電子商務網站中的網頁瀏覽、購買、點擊、評分和評論等活動。 用戶行為在個性化推薦系統中一般分兩種——顯性反饋行為(explicit feedback)和隱性反饋 行為(implicit feedback)。顯性反饋行為包括用戶明確表示對物品喜好的行為。網站中收集顯性反饋的主要方式就是評分和喜歡/不喜歡。隱性反饋行為指的是那些不能明確反應用戶喜好 的行為。最具代表性的隱性反饋行為就是頁面瀏覽行為。 按照反饋的明確性分，用戶行為數據可以分為顯性反饋和隱性反饋，但按照反饋的方向分， 又可以分為正反饋和負反饋。正反饋指用戶的行為傾向於指用戶喜歡該物品，而負反饋指用戶的 行為傾向於指用戶不喜歡該物品。在顯性反饋中，很容易區分一個用戶行為是正反饋還是負反饋， 而在隱性反饋行為中，就相對比較難以確定。

在利用用戶行為數據設計推薦演算法之前，研究人員首先需要對用戶行為數據進行分析，了解 數據中蘊含的一般規律，這樣才能對演算法的設計起到指導作用。

(1) 用戶活躍度和物品流行度

(2) 用戶活躍度和物品流行度的關系

一般認為，新用戶傾向於瀏覽熱門的物品，因為他 們對網站還不熟悉，只能點擊首頁的熱門物品，而老用戶會逐漸開始瀏覽冷門的物品。如果用橫坐標表示用戶活躍度，縱坐標表示具有某個活躍度的所有用戶評過分的物品的平均流行度。圖中曲線呈明顯下 降的趨勢，這表明用戶越活躍，越傾向於瀏覽冷門的物品。

僅僅基於用戶行為數據設計的推薦演算法一般稱為協同過濾演算法。學術界對協同過濾演算法進行了深入研究，提出了很多方法，比如基於鄰域的方法(neighborhood-based)、隱語義模型 (latent factor model)、基於圖的隨機遊走演算法(random walk on graph)等。在這些方法中， 最著名的、在業界得到最廣泛應用的演算法是基於鄰域的方法，而基於鄰域的方法主要包含下面兩種演算法。

基於用戶的協同過濾演算法 ：這種演算法給用戶推薦和他興趣相似的其他用戶喜歡的物品

基於物品的協同過濾演算法： 這種演算法給用戶推薦和他之前喜歡的物品相似的物品

基於鄰域的演算法是推薦系統中最基本的演算法，該演算法不僅在學術界得到了深入研究，而且在 業界得到了廣泛應用。基於鄰域的演算法分為兩大類，一類是基於用戶的協同過濾演算法，另一類是 基於物品的協同過濾演算法。現在我們所說的協同過濾，基本上就就是指基於用戶或者是基於物品的協同過濾演算法，因此，我們可以說基於鄰域的演算法即是我們常說的協同過濾演算法

(1) 基於用戶的協同過濾演算法（UserCF）

基於用戶的協同過濾演算法的基本思想是：在一個在線個性化推薦系統中，當一個用戶A需要個性化推薦 時，可以先找到和他有相似興趣的其他用戶，然後把那些用戶喜歡的、而用戶A沒有聽說過的物品推薦給A。

Ø 從上面的描述中可以看到，基於用戶的協同過濾演算法主要包括兩個步驟。 第一步：找到和目標用戶興趣相似的用戶集合。 第二步： 找到這個集合中的用戶喜歡的，且目標用戶沒有聽說過的物品推薦給目標用戶。

這里，步驟1的關鍵是計算兩個用戶的興趣相似度，協同過濾演算法主要利用行為的相似度計算興趣的相似度。給定用戶u和用戶v，令N(u)表示用戶u曾經有過正反饋的物品集合，令N(v) 為用戶v曾經有過正反饋的物品集合。那麼我們可以通過以下方法計算用戶的相似度：

基於餘弦相似度

(2) 基於物品的協同過濾演算法（itemCF）
與UserCF同理
(3) UserCF和itemCF的比 較

首先我們提出一個問題，為什麼新聞網站一般使用UserCF，而圖書、電商網站一般使用ItemCF呢？ 首先回顧一下UserCF演算法和ItemCF演算法的推薦原理。UserCF給用戶推薦那些和他有共同興 趣愛好的用戶喜歡的物品，而ItemCF給用戶推薦那些和他之前喜歡的物品類似的物品。從這個算 法的原理可以看到，UserCF的推薦結果著重於反映和用戶興趣相似的小群體的熱點，而ItemCF 的推薦結果著重於維系用戶的歷史興趣。換句話說，UserCF的推薦更社會化，反映了用戶所在的小型興趣群體中物品的熱門程度，而ItemCF的推薦更加個性化，反映了用戶自己的興趣傳承。 在新聞網站中，用戶的興趣不是特別細化，絕大多數用戶都喜歡看熱門的新聞。個性化新聞推薦更加強調抓住 新聞熱點，熱門程度和時效性是個性化新聞推薦的重點，而個性化相對於這兩點略顯次要。因 此，UserCF可以給用戶推薦和他有相似愛好的一群其他用戶今天都在看的新聞，這樣在抓住熱 點和時效性的同時，保證了一定程度的個性化。同時，在新聞網站中，物品的更新速度遠遠快於新用戶的加入速度，而且 對於新用戶，完全可以給他推薦最熱門的新聞，因此UserCF顯然是利大於弊。

但是，在圖書、電子商務和電影網站，比如亞馬遜、豆瓣、Netflix中，ItemCF則能極大地發 揮優勢。首先，在這些網站中，用戶的興趣是比較固定和持久的。一個技術人員可能都是在購買 技術方面的書，而且他們對書的熱門程度並不是那麼敏感，事實上越是資深的技術人員，他們看 的書就越可能不熱門。此外，這些系統中的用戶大都不太需要流行度來輔助他們判斷一個物品的 好壞，而是可以通過自己熟悉領域的知識自己判斷物品的質量。因此，這些網站中個性化推薦的 任務是幫助用戶發現和他研究領域相關的物品。因此，ItemCF演算法成為了這些網站的首選演算法。 此外，這些網站的物品更新速度不會特別快，一天一次更新物品相似度矩陣對它們來說不會造成 太大的損失，是可以接受的。同時，從技術上考慮，UserCF需要維護一個用戶相似度的矩陣，而ItemCF需要維護一個物品 相似度矩陣。從存儲的角度說，如果用戶很多，那麼維護用戶興趣相似度矩陣需要很大的空間， 同理，如果物品很多，那麼維護物品相似度矩陣代價較大

下表是對二者的一個全面的表較：