※ 引述《chucheng (時間太少事情太多)》之銘言：
: 一個隱含的假設是使用者的Personalization不需要考量
: 舉一個我以前犯過錯的例子，
: 用association rule做query recommendation(based on log)
: 大部份的人搜shoe之後會搜high heel，等等
: 後來發現因為女生上網買鞋多，等於間接假設所有user都是女生
: 假設同一個人，比較正確的說法是「personalization」不考慮
有點好奇實務上是怎麼考慮處理這些問題的
遇到無法取得個人資料的狀況
這樣推薦的結果常會差到不能接受嗎？
例如，若70%搜尋shoes的user是女生
若所有搜尋shoes的人都推薦high heels
可能有70%左右的推薦是準確的
剩下的30%也可能因為後續的搜尋而更加準確？
: 另一個有趣的軼聞是
: 當年第一篇paper發表的時候，作者的經典範例是
: beer-->diaper (經典的beer and diaper story)
: 但用同樣的資料集，後人無法 "重製" 這個結果
: 話說有可能演講時只是故意舉個頌動的例子就是了XD
大家小時候上data mining課都被這個故事騙了嗎....XD
: : 像Mahout現成recommendation engine的機制
: : 似乎比較適合Google Play, Netflix這種容易蒐集rating的應用
: : 不知道我是否有什麼疏漏或誤會的地方
: : 或者C大是指使用Mahout底層的矩陣map reduce運算，自行建構推薦演算法？
: 我也遇到一個類似的問題，也有想到一些解法(自以為絕妙的idea XD)
: 做的差不多了，100%會投今年的CIKM (比較可能，因為地點在San Francisco) or ICDM
: 不過因為涉及(尊重)一些公司資料的policy，Approve / Accept前沒辦法談太多
: 應該六月就有結果，之後我可私下mail draft給你參考(如果等不及conf.的話)
: 當然也有很多類似的研究，可以參考一下KDD的Paper or 例年的Challenge
有機會的話希望能早點讀到C大的論文
另外，想請教針對這個特定的情境
（沒有rating而光靠user transaction做recommendation）
還有哪一些指標性的paper或者keyword呢？
: Apriori當資料大時很容易爆掉
: 先試著用Fp-growth，通常10G級數以內可以輕鬆搞定
: 有人有提出parallel的方法http://dl.acm.org/citation.cfm?id=1454027
: 我沒實作過，不過我通常處理的資料級都在100G以內
: 我很垃圾(不要臉)的…這時候我都是…
: 弄台強一點的server丟上去跑好是了，能不碰map-reduce就不碰
: 就算碰也是拿來作資料清理或是encoding這一類的單純工作
: 最後的分析還是拿回單機跑
嗯嗯，之前有看到這篇，但我也沒實作過
我目前也沒把associative mining分散化
只是先假想一下如果長到TB/PB等級時要怎麼做
與其說不要臉，可以說是…
避免over enginnering，造成不必要的開發/運行代價 XD
: 如果你要搞Collaborative Filtering Recommendation
: 我推薦試試看CMU教授Carlos設計的GraphLab
: http://graphlab.org/
: 我還沒認真研究，但其它同行好評不斷
感謝推薦，有空來看看
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.130.149.28