問題其實不是最終目的，羅列問題主要是為了找到一些研究的具體方向。作為我自己，就是希望能明確一下接下來深入學習的切入點。推薦系統發展到現在已經得到了廣泛的應用，但還存在一些問題。
熱點核心問題就是資料稀疏性。很容易理解，比如線上有成千上萬部電影，但我們看過的為數不多，評過分的就更少了。在所有使用者集上來看，這個問題就嚴重了。一般使用者-專案矩陣稀疏度都會在99%以上。這對於所有的推薦演算法的計算來說，都會產生很大的影響，降低了推薦的準確度。這個問題就解決來說，常用的方法是填充矩陣。
第二，冷啟動問題。它可以說是資料稀疏性的乙個極端。也就是完全沒有資料。但這在實際系統中是經常會出現的，比如新物品的上架或新使用者的加入。出現這個問題的主要原因是推薦演算法對評分資料的過分依賴。這個問題可以通過利用專案的內容資訊和使用者的個人資訊來緩解。
第三，專案內容特徵描述的複雜性。這個問題突出體現在基於內容屬性推薦演算法上。比如對於多**，諸如**，電影等的準確文字描述是比較困難的，而這些特徵描述決定了推薦的準確性。在這方面，只能不斷改進對於專案特徵提取的技術。或者使用其他的推薦演算法。
第四，伸縮性問題。也可以說是實時性問題。在我做畢業設計過程這個問題尤為突出，由於資料量過大，計算過程很複雜，乙個推薦有時會花好幾分鐘才能計算出來。後來我將演算法中最為耗時的計算專案相似度的部分另外寫了乙個離線計算的程式，單獨執行了五個小時才計算出整個相似度矩陣來。然後在實際推薦中直接讀取就可以了。可以在幾秒鐘內做出推薦。當然，這麼做會損失一定的精度，因為你計算出的資料可能已經不是最新的了。一般是需要一定週期離線更新一次。
第五，概念漂移問題。簡單說就是人的興趣會隨著時間，地點的變化而變化。你童年時的興趣和現在肯定是有很大不同的，你在工作以後和在學校裡也是不同的。推薦系統必須能夠感知到這些變化，從而更準確進行推薦。即要加入時間帶給我們的資訊，進行動態推薦。越近時間的資料會越有價值。
以上就是我目前了解到的一些問題。而研究中，許多學者也是在不斷的解決這些問題。對推薦系統感興趣的同行們，也可以發揮自己的智慧型，提出自己的改進演算法。對於目前的我來說，正在爬上前人的肩膀，然後去看推薦的世界。哈哈
用到了mysql ignore 解決一些問題
insert ignore into userproperty uid,pid,num select id,from user ignore 就是忽略錯誤 在我想給userproperty表修改num欄位的時候遇到了這麼乙個問題。我的需求是 給所有人加上乙個pid 1 的道具 但是有的人本身就已經有...
遇到的一些問題心得
一.專案的版本管理。1 gnu 風格的版本號命名格式 主版本號 子版本號 修正版本號 編譯版本號 major version number.minor version number revision number build number 示例 1.2.1,2.0,5.0.0 build 13124...
ubantu遇到的一些問題
給hackywit可以通過sudo提公升root許可權 hackywit cxb hostname cxbhackywit cxb sudo vim etc hosts sudo hackywit 的密碼 127.0.0.1 localhost cxbhackywit cxb sudo apt ge...